콘텐츠
테이크 아웃 :
라우팅 확장 성은 Border Gateway Protocol에 의해 크게 도움이 될 수있어 패킷을보다 효율적으로 라우팅 할 수 있습니다.
컴퓨터 과학에서 중요한 개념은 확장 성또는 작업 크기가 증가함에 따라 특정 작업을 처리하는 방법이 얼마나 잘 작동 하는지를 나타냅니다. 예를 들어, 종이 조각에 전화 번호를 쓰면 전화 번호를 추적해야 할 때 상당히 효과적입니다. 주어진 번호를 찾는 데 10 초 밖에 걸리지 않습니다. 그러나 인구가 100,000 명인 도시의 경우 이제 숫자를 찾는 데 수십만 초 (약 하루)가 걸립니다. 인구가 100,000 명인 도시의 전화 번호부를 사용하면 이름이 지정된 전화 번호를 찾는 데 약 30 분이 걸립니다. 큰 이점은 책을 사용하는 것이 개별 용지 조각을 사용하는 것보다 훨씬 빠르다는 것이 아니라 문제의 크기를 두 배로 늘릴 때 해결해야 할 작업의 양을 두 배로 늘리지 않는다는 것입니다. 전화를 통한 검색 두 배나 큰 책은 몇 초만 더 걸립니다 : 내가 찾고있는 이름이 후반의 상반기에 있습니까? 두 배나 걸리지 않으므로 전화 번호부는 확장 가능하지만 스크랩은 그렇지 않습니다. 라우팅 확장 성은 인터넷을 통해 패킷을 올바른 대상으로 배달하는 문제에 확장 성의 개념을 적용하고 있습니다.
데이터 라우팅의 확장 성
라우팅 확장 성은 관리 평면과 데이터 평면의 두 가지 문제로 구성됩니다.
데이터 평면은 들어오는 패킷을 가져와 목적지로가는 도중에 다음 라우터로 전달하는 라우터의 중앙 또는 분산 모듈입니다. 이 기능은 전달 된 각 패킷에 대해 전달 테이블에서 다음 홉을 찾아야합니다. 이 작업을 수행하는 두 가지 주요 메커니즘은 TCAM, 검색을위한 내장 하드웨어 지원 기능이있는 특수 메모리 및 고급 알고리즘을 사용하여 검색되는 일반 메모리입니다. 테이블 크기가 증가해도 조회 속도가 떨어지지 않습니다. 그러나 TCAM 또는 메모리 크기는 선형으로 (또는 멀티 레벨 조회보다 약간 빠릅니다) 비용과 전력 사용이 증가합니다. 또한 초당 전달 테이블 조회 수가 증가함에 따라 더 비싸고 전력 소비가 많은 기술을 사용해야합니다. 인터페이스 속도가 증가함에 따라 이러한 증가는 불가피하지만, 평균 또는 최악의 패킷 크기와 특정 라우터 아키텍처에서 장치 또는 블레이드 / 모듈 당 인터페이스 수에 따라 달라집니다.
2006 년 암스테르담에서 열린 Internet Architecture Routing and Addressing 워크숍에서 필요한 메모리 속도가 상용 구성 요소의 성능 향상을 능가한다고 주장했습니다. 특히 별도의 SRAM이 더 이상 널리 사용되지 않고 있습니다. 이전에는 컴퓨터가 고속 SRAM을 메모리 캐시로 사용했지만 요즘에는 그 기능이 CPU 자체에 포함되어 있으므로 더 이상 SRAM을 더 이상 쉽게 사용할 수있는 상용 칩이 아닙니다. 이는 최고급 라우터 비용이 지금까지보다 훨씬 빠르게 증가한다는 것을 의미합니다. 그러나 IAB 라우팅 및 주소 지정 워크숍 이후, 여러 라우터 공급 업체가 대화 및 메일 링리스트에서이 문제가 지금 당장은 아니고 현재 예상 수준의 성장이 예측 가능한 미래에 문제를 일으키지 않을 것이라고 밝혔습니다.
보더 게이트웨이 프로토콜
관리 평면은 BGP 라우팅 프로토콜을 실행하는 라우팅 프로세서와 전달 테이블을 생성하기 위해 라우터가 수행해야하는 관련 작업으로 구성됩니다. BGP는 ISP와 다른 네트워크가 사용되는 IP 주소를 서로에게 알려주기 위해 사용하는 프로토콜이므로 해당 IP 주소로 향하는 패킷을 올바르게 전달할 수 있습니다. BGP 확장 성은 업데이트 통신, 라우터에 저장 및 처리의 필요성에 영향을받습니다. 현재 업데이트 전파를위한 대역폭은 전혀 문제가되지 않습니다. 실제로, 점점 더 큰 BGP 테이블을 저장하기위한 메모리 요구 사항은 문제를 일으킬 수 있습니다. 이는 일반적으로 기술적 인 문제가 아니라 상용 라우터의 구현 제한 때문입니다. 라우트 프로세서는 기본적으로 범용 컴퓨터이며 16 기가 바이트 이상의 RAM으로 쉽게 구축 할 수 있습니다. 현재 Route Views 공용 경로 서버는 1GB RAM으로 실행되며 각각 약 560,000 개의 접두사로 약 40 개의 전체 BGP 피드를 제공합니다 (2015 년 12 월 그림).
그러나 이로 인해 처리가 중단됩니다. BGP에 필요한 처리량은 BGP 업데이트 수와 접두사 수에 따라 다릅니다. 업데이트 당 접두사 수가 적기 때문에 해당 측면을 무시하고 업데이트 수를 살펴 보겠습니다. 아마도 자율적 인 성장과는 별도로 업데이트 수는 접두사 수와 비례하여 증가합니다. BGP 업데이트의 실제 처리는 매우 제한되어 있으므로 병목 현상은 업데이트를 수행하기 위해 메모리에 액세스하는 데 걸리는 시간입니다. 또한 IAB 라우팅 및 어드레싱 작업장에서 DRAM 속도의 증가가 상당히 제한되어 라우팅 테이블 증가를 따라 잡을 수 없다는 정보가 제시되었습니다.
전달 테이블 동기화
별도의 전달 및 데이터 평면 문제 외에도 업데이트 후 전달 테이블을 BGP / 라우팅 테이블과 동기화하는 데 문제가 있습니다. 전달 테이블의 아키텍처에 따라 업데이트하는 데 상대적으로 시간이 오래 걸릴 수 있습니다. BGP는 종종 거리 벡터 프로토콜과 매우 유사한 "경로 벡터"라우팅 프로토콜로 설명됩니다. 따라서 Bellman-Ford 알고리즘의 약간 수정 된 버전을 구현합니다. 이론상 적어도 이론적으로 노드 수와 동일한 수의 반복이 필요합니다 (BGP의 경우 : 외부 자율 시스템 및 내부 iBGP 라우터). )를 그래프에서 빼기 1에서 수렴합니다. 실제로, 수렴은 네트워크의 두 위치 사이에서 가장 긴 경로를 사용하는 실행 가능한 디자인이 아니기 때문에 훨씬 더 빠르게 발생합니다. 그러나 곱셈 효과로 인해 단일 이벤트 후에 처리해야하는 개별 업데이트 형태의 많은 반복이 발생할 수 있습니다. 예를 들어, 2 개의 AS가 2 개의 위치에서 상호 연결되는 경우, 제 1 AS의 1 개의 업데이트는 각각의 상호 연결 링크를 통해 제 2 AS로 2 회 전파 될 것이다. 가능한 옵션은 다음과 같습니다.
버그 없음, 스트레스 없음-인생을 파괴하지 않고 인생을 바꾸는 소프트웨어를 만드는 단계별 가이드
아무도 소프트웨어 품질에 신경 쓰지 않으면 프로그래밍 기술을 향상시킬 수 없습니다.
BGP의 이러한 측면은 많은 사람들에게 명시 적으로 인식되지 않지만 Route Flap Damping과 같은 연구는 인터넷 라우팅 수렴을 악화시킵니다.
위의 사항을 염두에두고 BGP에 일부 확장 문제가 있다고 결론 내릴 수 있습니다. 프로토콜과 라우터를 구현하는 라우터는 BGP에서 5 백만 개 및 5 천만 개의 개별 접두사를 관리해야하는 인터넷에 적합하지 않습니다. 그러나 현재의 성장률은 IPv4의 연간 약 16 %로 비교적 안정적이므로 즉각적인 우려의 원인이 없습니다. 이는 현재 BGP에 25,000 개의 접두사 만있는 IPv6의 경우에 해당됩니다.