KR100666996B1 - 라우팅 시스템 및 라우트 업데이트 방법 - Google Patents

Abstract

본 발명은 라우팅 시스템 및 라우트 업데이트 방법에 관한 것으로, 라우팅 테이블 내 각 엔트리에 라우팅 프로토콜별 라우트 삽입 순서에 관한 정보를 저장하였다가, 라우팅 모듈의 재가동시 상기 저장된 라우트 삽입 순서에 따라 프리픽스 탐색을 수행하고, 프리픽스 탐색 수행 결과 프리픽스 매칭이 발생하는 경우 해당 라우팅 엔트리를 업데이트하되, 프리픽스 매칭이 되지 않는 경우에는 일반적인 트라이 구조에 따라 탐색을 수행하도록 함으로써, 라우트 업데이트시 라우트 탐색 횟수 감소 효과를 기대할 수 있다.

Description

라우팅 시스템 및 라우트 업데이트 방법{Routing System and Route Update Method}

도 1은 본 발명이 적용되는 IP 라우팅 테이블 업데이트를 위한 패트리샤 트라이(Trie) 구조의 일 예를 나타낸 도면.

도 2는 본 발명이 적용되는 IP 라우팅 테이블 업데이트를 위한 여러 트라이(Trie) 구조를 나타낸 도면.

도 3은 본 발명에 따른 라우팅 시스템의 블록 구성을 나타낸 도면.

도 4는 본 발명에 따른 라우팅 트라이의 구조를 나타낸 도면.

*도면의 주요 부분에 대한 부호의 설명*

300 : 라우팅 시스템 310 : RIP 라우팅 모듈

320 : OSPF 라우팅 모듈 330 : BGP 라우팅 모듈

340 : 라우팅 테이블 411 : 프로토콜별 삽입 순서

본 발명은 라우팅 시스템 및 라우트 업데이트 방법에 관한 것으로, 보다 구체적으로는 트라이(Trie) 구조의 라우팅 관리에 있어서 트라이 탐색을 수행하기 전에 라우팅 프로토콜별 삽입 순서에 따른 탐색을 먼저 수행하도록 하는 라우팅 시스템 및 라우트 업데이트 방법에 관한 것이다.

라우팅 시스템은 3계층 주소에 따라 패킷을 목적지까지 최적 경로상에 있는 다음 노드로 전송하는 역할을 담당한다. 라우팅 시스템은 일반적으로 여러 개의 라인카드, 백플레인(backplane), 그리고 CPU 부분으로 구성된다. 라인카드는 다양한 링크 기술을 채택한 서로 다른 네트워크를 라우팅 시스템과 물리적으로 연결한다. CPU는 라우팅 프로토콜을 수행하고, 라우팅 테이블을 생성, 관리하며 망관리 시스템과의 인터페이싱을 수행한다. 백플레인은 여러 개의 라인카드들과 CPU간을 상호 연결한다.

라우팅 시스템은 규모와 용도에 따라 다양한 종류가 있으나 공통적으로 다음과 같은 동작을 수행한다.

우선, 외부로부터 패킷을 수신한 라우팅 시스템의 라인카드가 해당 링크 계층을 종단시키고 수신된 패킷의 이상 여부를 검사한다. 예를 들어, 이더넷의 경우에는 CRC(Cyclic Redundancy Code) 검사를 한다거나, ATM의 경우 수신된 셀을 패킷으로 조합하는 등의 행위가 그것이다. 다음으로, IP 헤더에 대한 에러를 검사하고 목적지 IP 주소를 읽은 후, 라우팅 테이블에서 출력 포트 정보를 알기 위해 롱기스 트 프리픽스 매칭(Longest Prefix Matching) 룩업(lookup)을 수행한다. 여기서, 롱기스트 프리픽스 매칭은 수신된 패킷의 목적지 IP 주소를 라우팅 테이블의 모든 엔트리와 비교함에 있어, 라우팅 엔트리의 네트워크 주소의 프리픽스 부분이 목적지 주소와 일치하는 모든 엔트리를 찾고, 그 중 프리픽스 길이가 가장 긴 것을 그 패킷의 라우팅 정보로 선택하는 방법을 말한다.

일단 라우팅 시스템이 IP 어드레스 룩업에 성공했다면 IP 헤더의 TTL(Time To Live) 값을 순차적으로 감소시켜 새로운 헤더 체크섬(Header Checksum)을 계산하여 헤더를 수정한다. 그 이후에는 백플레인을 통해 패킷을 출력 포트로 전송하며, 출력 라인카드에서는 패킷에 링크 계층 헤더를 부착하고 다음 라우팅 시스템(또는 목적지 호스트)로 패킷을 전송한다. 만일 이러한 과정을 성공적으로 끝내지 못한다면 ICMP(Internet Control Message Protocol) 에러 메시지를 패킷의 출생지 호스트로 전송하여 라우팅에 실패하였음을 알리게 된다.

라우팅 시스템의 성능을 향상시키기 위해 여러 연구가 진행되어 왔으며, IP 포워딩 과정에서 고속화의 목표가 되는 것 중 하나인 IP 주소 룩업 절차에 대해서도 많은 연구들이 있어 왔다. 그 중 대표적인 것으로 Trie 기반 방법, 해싱(Hashing) 기반 방법, 이진 탐색(binary search) 기반 방법, 그리고 하드웨어 기반 방법 등으로 구분할 수 있다.

Trie 기반의 방법은 1 비트당 한 레벨을 구성하는 원래의 Trie를 멀티 비트당 하나의 레벨로 압축하여 레벨의 수를 줄임으로써 메모리 액세스 회수의 감소를 꾀한다. Trie에서는 가장 긴 경로의 레벨 개수가 최대 메모리 액세스 회수이다.

이진 탐색 기법은 exact 매칭에 사용되는 것으로, LPM을 위해서는 프리픽스를 일부 변형해서 정렬된 배열(sorted array)을 만들어서 사용한다. 하드웨어 기반 방법 중에는 CAM(Content-Addressable Memory)을 이용하는 방법이 대표적이다. 이 방법은 가장 빠르지만 가격이 비싸고, 라우팅 엔트리의 수가 수K 미만이라는 것이 단점이다.

패트리샤-트라이는 라우트(route)를 추가하거나 삭제하는 경우에 포워딩을 효율적으로 수행하는 데에도 이용된다. OSPF(Open Shortest Path First) 또는 BGP(Border Gateway Protocol)와 같은 라우팅 수행 모듈이 재가동(restart)되는 경우, 라우팅 테이블에 있는 엔트리 중 재가동한 라우팅 수행 모듈에서 업데이트된 라우팅 엔트리들은 그 내용이 유효한지 검사해야 한다. 이때, OSPF나 BGP 등이 프로토콜은 graceful-restart를 지원하기 위해 일정 시간 동안 모든 라우트 엔트리들을 유효한 라우트 엔트리로 인정하다 라우트 정보를 다른 외부 라우팅 시스템로부터 수신하여 갱신된 라우트 엔트리만을 사용한다. 여기서, Graceful Restart는 재가동하는 라우팅 모듈의 영향을 최소화하는 기능을 말하며, Graceful Restart 없이는 라우팅 모듈이 재가동할 때, 라우트 재산정 및 광범위한 라우트 업데이트로 인해 바람직하지 못한 네트워크 동작 상태를 초래한다.

한편, Trie 기반의 라우팅 관리에 있어서는 n 개의 라우트 정보가 이전에 있었다면, OSPF 또는 BGP 등에 의하여 업데이트 되는 라우트 정보를 탐색하는 시간 Ο(log n)이 필요하다. 이는 새로운 라우트가 추가 또는 삭제되는 경우에도 마찬가지이며, 해당 프로토콜로 인한 많은 라우트 엔트리들이 존재한다면 시스템의 성능 을 저하시키게 되는 문제점이 발생한다.

본 발명은 상기의 문제점을 해결하기 위해, 트라이 탐색을 수행하기 전에 라우팅 프로토콜별 삽입 순서에 따른 탐색을 먼저 수행하고 삽입 순서에 따른 탐색에 실패한 경우 기존의 트라이 탐색을 수행하도록 하는 라우팅 시스템 및 라우트 업데이트 방법을 제공하는 것을 그 목적으로 한다.

상기의 목적을 달성하기 위한 본 발명의 일 측면에 따른 라우트 업데이트 방법은, 라우팅 테이블 내 각 엔트리에 라우팅 프로토콜별 라우트 삽입 순서에 관한 정보를 저장하는 단계; 라우팅 모듈의 재가동시 상기 저장된 라우트 삽입 순서에 따라 프리픽스 탐색을 수행하는 단계; 및 상기 프리픽스 탐색 수행 결과, 프리픽스 매칭이 발생하는 경우 해당 라우팅 엔트리를 업데이트하는 단계를 포함한다.

상기 프리픽스 탐색 수행 결과 프리픽스 매칭이 성공하지 못한 경우, 상기 트라이 구조에 따라 탐색을 수행하는 단계를 더 포함할 수 있다.

상기 라우팅 프로토콜은, RIP(Routing Information Protocol), OSPF(Open Shortest Path First), BGP(Border Gateway Protocol) 중 적어도 하나를 포함한다.

상기 라우팅 테이블 내 각 엔트리는, 프로토콜별 삽입 순서상의 이전, 이후의 엔트리와의 연결 정보를 포함한다.

상기 연결 정보는, 더블 링크드 리스트(double linked list) 형태로 표현된다.

상기 트라이 구조는, 이진(Binary) 트라이, 패트리샤(Patricia) 트라이, 경로 압축 트라이, 멀티비트 트라이, LC-트라이 중 어느 하나이다.

본 발명의 다른 측면에 따른 라우트 업데이트 방법은, 라우팅 테이블 내 각 엔트리에 라우팅 프로토콜별 라우트 삽입 순서에 관한 정보를 저장하는 단계; 라우팅 모듈의 재가동시 상기 저장된 라우트 삽입 순서에 따라 프리픽스 탐색을 수행하는 단계; 및 상기 프리픽스 탐색 수행 결과, 프리픽스 매칭이 발생하는 경우 해당 라우팅 엔트리를 업데이트하고, 프리픽스 매칭이 성공하지 못한 경우 상기 트라이 구조에 따른 탐색을 수행하는 단계를 포함한다.

본 발명의 또 다른 측면에 따른 라우팅 시스템은, 각 엔트리마다 프로토콜별 라우트 삽입 순서에 관한 정보를 트라이 구조로 저장하는 라우팅 테이블과 재가동시 상기 저장된 라우트 삽입 순서에 따라 프리픽스 탐색을 수행하고, 상기 프리픽스 탐색 수행 결과, 프리픽스 매칭이 발생하는 경우 해당 라우팅 엔트리를 업데이트하는 라우팅 모듈을 포함한다.

이하, 본 발명에 따른 바람직한 실시예를 도면을 살펴보면서 구체적으로 설명하기로 한다.

도 1은 본 발명이 적용되는 IP 라우팅 테이블 업데이트를 위한 패트리샤 트라이(Trie) 구조의 일 예를 도시한다.

트라이에 기반한 대표적 알고리즘으로 도 1에 도시한 패트리샤-트라이(Patricia-trie)를 들 수 있다. 패트리샤-트라이는 BSD(Berkeley Software Distribution) 계열의 유닉스와 기존의 많은 라우팅 시스템이 사용하고 있는 방법이다. 패트리샤-트라이는 라우팅 테이블을 트리(tree) 구조로 만들어, 트리의 루트(root)로부터 한 잎(leaf)까지의 경로가 하나의 라우팅 엔트리가 되도록 한다. 여기서, 패킷의 목적지 IP 주소와 매칭되는 가장 긴 경로(path)를 찾으면 그것이 LPM(Longest Prefix Matching)이 된다. 패트리샤-트라이는 메모리 사용을 크게 줄이고, IPv4의 경우 최대 32회의 메모리 액세스가 필요하고, IPv6의 경우 최대 128번의 메모리 액세스가 필요하다.

도 1은 IP 주소가 비트32부터 비트63에 해당하는 패킷을 패트리샤 트라이 구조를 이용한 라우팅 테이블 룩업 절차를 나타내며, 직각사각형은 내부 노드(internal node)를, 둥근 사각형은 리프 노드(leaf node)를 의미한다. 룩업 과정은 입력된 패킷의 비트 32와 도 1의 패트리샤 트라이 구조의 최상위부터 순차적으로 비교하여 리프 노드에 이르면 그 리프 노드 값과 수신 패킷의 IP 주소 값을 비교하고 매칭되는 경우 해당 노드를 이용하여 IP 패킷을 포워딩할 네트워크 인터페이스를 찾을 수 있게 된다.

도 2는 본 발명이 적용되는 IP 라우팅 테이블 업데이트를 위한 여러 트라이 (Trie) 구조를 도시한다.

도 2의 각 트라이는 동일한 샘플 프리픽스를 이용하여 구성된 것이다.

도 2a는 이진 트라이(Binary Trie) 구조이며, 프리픽스를 Trie의 노드에 저장하는 방식이다. 이진 트라이의 경우 Ο(W)의 메모리 검색횟수가 필요하다. 도 2b는 "경로 압축 트라이(Path Compressed Trie) 구조로, 비어 있는 노드이면서 하나의 차일드(child)를 갖는 노드를 압축시켜 최대 메모리 접근 횟수를 줄이고자 한 방식이다. 도 2c의 "멀티비트 트라이"는 메모리 접근 횟수를 줄이기 위해 하나의 노드가 가질 수 있는 차일드의 개수를 늘리는 방법이다. 이 방법의 경우 K-비트 트라이라고 할 때 메모리 접근 횟수는 Ο(W/K)로 감소하나 Trie의 저장 방법이 복잡해지는 단점이 있다. 그림 2d의 LC(Level Compressed)-Trie의 경우 기존의 트라이에 비해 좀더 컴팩트(compact)한 구성이 가능해졌으나 여전히 최대 Ο(W/K)의 메모리 접근이 필요하다.

도 1과 도 2를 통해 살펴본 바와 같이, 일반적인 트라이 기반 알고리즘은 1 비트당 한 레벨을 구성하는 원래의 트라이를 멀티비트당 하나의 레벨로 압축하여 레벨의 수를 줄임으로써 메모리 액세스 회수의 감소를 꾀한다. 트라이 구조에서는 가장 긴 경로의 레벨 개수가 최대 메모리 액세스 회수가 된다.

이러한 트라이 구조는 라우팅 룩업 과정 뿐 아니라 라우트 엔트리의 업데이트 과정에도 동일한 원리로 적용된다.

도 3은 본 발명에 따른 라우팅 시스템의 블록 구성을 나타낸다.

본 발명에 따른 라우팅 시스템은 RIP 라우팅 모듈(310), OSPF 라우팅 모듈(320), BGP 라우팅 모듈(330) 및 라우팅 테이블(340)을 포함하여 구성된다.

RIP 라우팅 모듈(310)은 라우팅 테이블(340)을 참조하여 RIP 라우팅을 수행한다. 여기서, RIP((Routing Information Protocol)는 기업의 근거리통신망, 또는 그러한 랜들이 서로 연결된 그룹과 같은 독립적인 네트웍 내에서 라우팅 정보 관리를 위해 광범위하게 사용된 프로토콜이다. RIP를 사용하면, 라우팅 시스템 내의 게이트웨이 호스트는 전체 라우팅 테이블을 가장 가까운 인근 호스트에 매 30초마다 보낸다. 인접한 호스트는 자신의 차례가 되면 그 정보를 그 다음 인접한 호스트로 넘기는데, 이러한 전달은 그 네트웍 내의 모든 호스트들이 같은 라우팅 경로 정보를 가질 때까지 계속된다. RIP는 네트웍 거리를 결정하는 방법으로 홉의 총계를 사용한다 (다른 프로토콜들은 타이밍까지를 포함하는 보다 정교한 알고리즘을 사용한다). 네트웍 내에 라우팅 시스템을 갖고 있는 각 호스트는 패킷을 전달할 다음 호스트를 결정하기 위해 라우팅 테이블 정보를 사용한다. RIP는 소규모 동종의 네트웍에서는 유효한 해결방안이라고 간주되나, 보다 복잡하고 규모가 큰 네트웍에서 RIP가 전체의 라우팅 테이블을 매 30초마다 전송하는 것은 네트웍 내에 엄청난 양의 추가 부담을 주는 단점이 있다.

OSPF 라우팅 모듈(320)은 라우팅 테이블을 참조하여 OSPF 라우팅 프로토콜에 따라 라우팅을 수행하는 블록이다.

여기서, OSPF 프로토콜의 전반적인 동작에 대해 살펴보면 아래와 같다. 1980년대 중반에 RIP가 더 이상 대규모의 이질적인 망 사이의 라우팅을 수행하기에 는 한계에 이르자 IETF(Internet Engineering Task Force)에서는 SPF(Shortest Path First) 알고리즘에 기반한 인터넷에 적용하기 위한 IP 네트워크용 라우팅 알고리즘을 개발하게 되었고 이의 결과로 OSPF(Open Shortest Path First)가 탄생하게 되었다.

OSPF를 사용하면, 라우팅 테이블의 변경 사실이나, 네트웍 내의 어떤 변화를 감지한 호스트는, 즉시 그 정보를 네트웍 내의 다른 모든 호스트들에게 알림으로써, 모두 같은 라우팅 정보를 가질 수 있도록 한다. 라우팅 테이블 전체를 보내는 RIP과는 달리, OSPF를 사용하는 호스트는 오직 변경된 부분만을 보낸다. RIP에서는 매 30초마다 라우팅 테이블을 인접한 호스트에 보내지만, OSPF는 변경이 생겼을 때에만 변경된 정보를 멀티캐스트 한다.

단순히 홉 수를 세는 것보다 OSPF는 추가적인 네트웍 정보를 참작한 링크상태 상에서 그것의 경로 등급을 기반으로 한다. OSPF는 또한 사용자가 자신의 선호도에 따라 몇몇 경로들에 대해 우선권을 부여할 수 있도록, 특정 호스트 라우터를 설정할 수 있게 한다. OSPF는 하나의 네트웍이 다시 세분될 수 있도록, 다양한 네트웍 서브넷 마스크를 지원한다. OSPF 내에서 라우터와 종단국 사이의 통신을 위해 RIP이 지원된다. 이미 많은 네트웍들이 RIP를 사용하고 있기 때문에, 라우터 제작업체들은 본래 OSPF를 위해 설계된 라우터 내에 RIP의 지원도 함께 포함하는 경향이 있다.

OSPF는 그 말이 표현하는 대로 모든 사양이 개방(Open)되어 있고, 이런 OSPF의 사양은 RFC 1247(후에 RFC 1583; OSPF Version 2로 대체)로 발표되었다.

OSPF에서는 RIP와 달리 라우팅 알고리즘을 적용하기 위한 계층을 가지고 있다. 가장 큰 계층으로서 AS(Autonomous System)가 있는데, 이는 공통적인 라우팅 전략을 공유하면서 하나의 관리 체제에 의해 관리되는 망들의 집합으로 정의된다. 하나의 AS는 다시 여러 개의 지역(AREA)로 나누어지는데, 이는 연속적인 망 및 접속된 시스템들의 집합으로 표현된다. 하나의 AS내에서 이러한 지역들을 연결해주는 망을 백본망이라 부르며, 이러한 계층에 따라 라우터의 종류가 구분되는데, 내부 라우터, 지역 경계 라우터, 백본 라우터, AS 경계 라우터 등이 있다.

내부 라우터(Internal Router)는 어떤 한 지역에 속한 망에 직접 접속한 라우터를 말하며, 백본망에 접속한 라우터도 이 범주에 속한다. 지역 경계 라우터(Area Border Router)는 지역과 백본망을 연결시켜주는 라우터를 말하며, 이 라우터는 접속된 지역에 대한 경로 정보를 요약하여 백본망에 전달하면 백본망을 통해 이 정보가 다른 지역 경계 라우터에게 분배된다. (그림1: 라우터 4,10,11 및 12))

또한, 백본 라우터(Backbone Router)는 백본망에 접속한 모든 라우터를 말하며, 여기에는 지역 경계 라우터 및 백본망에 속한 내부 라우터가 포함된다. AS 경계 라우터(AS Boundary Router)는 다른 AS에 속한 라우터와 경로 정보를 교환하는 라우터를 말하며, 이러한 경로 정보는 AS 외부 경로로서 전 AS에 전달된다. 이러한 AS 경계 라우터에 대한 경로는 AS에 속한 모든 라우터에 알려지게 된다.

OSPF 라우터는 처음 부팅시, 헬로(Hello) 패킷을 교환함으로써, 이웃한 라우터를 서로 인식할 수 있게 된다. 이를 통해 어떤 망에 접속된 복수 개의 라우터 중 그 망을 대표하여 그 망에 대한 경로 정보를 생성 및 분배하는 책임을 지는 대표 (Designated) 라우터를 선정하게 된다. 이 대표 라우터는 새로 인식된 라우터와 경로 정보를 교환하여 동기를 맞추게 된다. OSPF 라우터는 자신의 경로 테이블에 대한 정보를 LSA(Link State Advertisement)라는 자료 구조를 통하여 주기적으로 혹은 라우터의 상태가 변할 때 전송하게 되는데, 이 LSA는 해당 지역의 모든 라우터에게 알려지게 된다. 이를 통해 한 지역에 속한 모든 라우터는 같은 정보를 공유하게 되는 것이다.

지역간의 정보 공유는 다음과 같이 수행된다. 지역 경계 라우터는 AS의 백본 망에 연결되어 있으므로, 다른 지역 경계 라우터와 지역에 대한 요약(Summary) 정보를 교환함으로써 AS의 위상(Topology)과 다른 지역에 대한 정보를 획득할 수 있다. 이를 통해 자신의 지역에 속하지 않은 모든 목적지에 대한 경로를 계산할 수 있고 이를 내부 라우터에게 전송한다. 이를 통해 내부 라우터는 다른 지역에 속하는 목적지로 전송할 때 어느 지역 경계 라우터로 패킷을 전송할 지를 결정할 수 있다.

다른 AS에 대한 외부 경로 정보를 알고 있는 AS 경계 라우터는 AS를 경유하여 정보를 전송할 수 있으므로 이러한 외부 경로 정보는 스텁(Stub) 지역을 제외하고는 전 지역 경계 라우터에 의해 지역 요약 정보 형태로 내부 라우터에게 전송된다. 이와 같은 이유로 다른 AS와 연결하는 AS 경계라우터의 위치는 스텁 지역에 속한 라우터를 제외하고는 모두 알려지게 되며 이를 통해 AS 외부로 정보를 전송할 수 있게 된다.

OSPF 라우터는 상술한 바와 같은 방식으로 지역 내부, 지역 외부, AS 외부의 경로에 대한 정보를 얻어 위상 데이터베이스를 구축한다. 이와 같은 위상 데이터베이스에 SPF 알고리즘을 적용하여 모든 경로에 대해 자신으로부터의 최단경로트리(Shortest Path Tree)를 계산하여 이를 경로 테이블에 유지하며 이를 통해 패킷의 중계를 수행한다.

BGP 라우팅 모듈(330)은 도메인간의 라우팅 프로토콜인 BGP 프로토콜에 따라 라우팅을 수행하는 모듈이다.

여기서, BGP(Border Gateway Protocol)의 동작 방식은 아래와 같다.

먼저 서로 다른 AS(관리 도메인)에 속한 BGP 라우터가 통신하기 위해서는 다른 망의 중계 없이 하나의 망으로 직접 연결되어 있어야 하며, 한 AS내에 복수 개의 BGP 라우터가 있는 경우, BGP 라우터들은 그 AS에 대한 일관된 정보와 AS 외부 통로로서의 역할을 수행하기 위해 서로를 인식하고 정보를 교환해야 한다.

초기에 BGP 라우터가 상대와 연결될 때에는, 자기가 가지고 있는 전체 경로 테이블의 내용을 교환하고, 이후에는 변화된 것만을 교환한다. 이때, BPG 라우터는 특정 목적지에 대한 모든 타당한 경로를 유지하고 있지만 경로 갱신 전문에는 최적의 경로만을 전송한다. 이러한 정보의 교환은 TCP(Transmission Control Protocol)를 통해 신뢰성 있게 수행된다.

BGP는 RIP와 같은 거리값(Distance Vector)에 기본한 라우팅 알고리즘이나, 목적지까지의 경로값을 전송하는 것이 아니고, 목적지까지 도달하는데 경유하는 AS의 순서를 전송하므로, 거리값 알고리즘이 가지고 있는 무한 경로값(Counting to Infinity)의 단점을 가지고 있지 않다.

상술한 RIP 라우팅 모듈(310), OSPF 라우팅 모듈(320), BGP 라우팅 모듈(330)은 재가동(restart)하는 경우 라우팅 테이블에 있는 엔트리 중 해당 프로토콜에 의해 업데이트된 엔트리에 대해서 그 유효성을 검사한다. 그런데, 이들 라우팅 모듈은 재가동시, graceful-restart를 지원하기 위해 일정 시간 동안 모든 라우트 엔트리를 유효한 라우트 엔트리로 인정하다가 다른 외부 라우터로부터 수신하여 갱신된 라우트 엔트리만을 사용하게 된다. 따라서, 이러한 graceful-restart 기능으로 인해 외부로부터 수신한 라우트 엔트리는 기존에 보유하던 라우트 엔트리의 삽입 순서와 일치할 확률이 높다.

따라서, 본 발명에 따른 라우팅 모듈들, 즉 RIP 라우팅 모듈(310), OSPF 라우팅 모듈(320), BGP 라우팅 모듈(330)은, 이진 탐색을 수행하기 전에 프로토콜 별로 라우트 엔트리가 삽입된 순서를 저장하고, 이후에 프로토콜이 재가동되는 경우 이진 탐색을 수행하기 전, 이전 라우트 엔트리가 다음에 삽입된 라우트 엔트리와의 비교를 우선적으로 수행하여 두 엔트리가 동일하면 이진 탐색을 수행하지 않도록 한다.

이를 위해 라우팅 테이블(340)의 각 라우팅 엔트리는 라우팅 프로토콜별로 라우팅 엔트리가 추가된 순서에 대한 정보를 포함한다. 그리고, 더블 링크드 리스트(double linked list)로 이전에 추가된 라우트 엔트리와 연결관계를 형성한다.

도 4는 본 발명에 따른 라우팅 트라이의 구조를 나타낸다.

도 4에서 보는 바와 같이 라우팅 테이블은 기존의 라우팅 테이블이 가지고 있는 정보 외에 프로토콜(401)별로 라우팅 엔트리가 삽입된 순서에 관한 정보(411)를 저장한다. 즉, 도 4의 트라이 구조의 최상위에 위치하는 프리픽스 (i)에 대한 라우팅 엔트리는 BGP 프로토콜에 의해 삽입된 엔트리이고, BGP 프로토콜에 의한 삽입 순서는 (i)번째임을 알 수 있다. 도 4의 트라이 구조는 가장 일반적인 이진 트라이일 수도 있으며, 앞서 상술한 패트리샤 트라이, 경로 압축 트라이, 멀티비트 트라이, LC-트라이 등이 될 수도 있다.

따라서, 프리픽스(k-1)이 OSPF 라우팅 모듈에 의해 (k-1)번째로 업데이트된 라우트 엔트리라고 한다면, 다음 번 OSPF 프로토콜에 의한 라우트 엔트리가 추가되는 경우, 트라이 탐색(이진 탐색 또는 그 변형 탐색) 등을 이용하여 검색하는 대신 프리픽스 k에 대한 라우트 엔트리 위치 정보를 이용하여 먼저 검색을 수행하게 된다.

만약, 삽입 순서를 이용한 라우트 엔트리 검색이 실패한다면, 기존의 방법인 트라이 탐색을 이용하여 탐색을 수행하게 된다. 이 경우, 탐색 횟수가 1회 증가하는 것으로, 삽입 순서 정보를 이용하지 않는 경우의 평균적인 비교 횟수가 t라면, 삽입 순서 정보를 이용한 경우에 있어서의 비교 횟수가 t+1이 되는 것이다. 하지만 삽입 순서 정보를 이용하여 성공하는 경우까지 고려한다면 통계적인 비교 횟수는 t보다 훨씬 줄어든 값을 가지게 될 것이다.

본 발명은, 새로운 라우트 엔트리의 라우팅 프로토콜별 삽입 순서를 저장하 였다가 라우팅 모듈의 재 가동시 이를 이용하여 라우팅 엔트리를 업데이트 함으로써, 라우팅 탐색에 소요되는 시간을 줄일 수 있다.

Claims (14)

1. 트라이 구조를 가지는 라우팅 테이블의 라우트 업데이트 방법에 있어서,

   라우팅 테이블 내 각 엔트리에 라우팅 프로토콜별 라우트 삽입 순서에 관한 정보를 저장하는 단계;

   라우팅 모듈의 재가동시 상기 저장된 라우트 삽입 순서에 따라 프리픽스 탐색을 수행하는 단계; 및

   상기 프리픽스 탐색 수행 결과, 프리픽스 매칭이 발생하는 경우 해당 라우팅 엔트리를 업데이트하는 단계를 포함하는 라우트 업데이트 방법.
2. 제 1항에 있어서,

   상기 프리픽스 탐색 수행 결과 프리픽스 매칭이 성공하지 못한 경우,

   상기 트라이 구조에 따른 탐색을 수행하는 단계를 더 포함하는 라우트 업데이트 방법.
3. 제 1항에 있어서,

   상기 라우팅 프로토콜은,

   RIP(Routing Information Protocol), OSPF(Open Shortest Path First), BGP(Border Gateway Protocol) 중 적어도 하나를 포함하는 라우트 업데이트 방법.
4. 제 1항에 있어서,

   상기 라우팅 테이블 내 각 엔트리는,

   프로토콜별 삽입 순서상의 이전, 이후의 엔트리와의 연결 정보를 포함하는 라우트 업데이트 방법.
5. 제 4항에 있어서,

   상기 연결 정보는,

   더블 링크드 리스트(double linked list) 형태로 표현되는 라우트 업데이트 방법.
6. 제 1항에 있어서,

   상기 트라이 구조는,

   이진(Binary) 트라이, 패트리샤(Patricia) 트라이, 경로 압축 트라이, 멀티비트 트라이, LC-트라이 중 하나인 것을 특징으로 하는 라우트 업데이트 방법.
7. 트라이 구조를 가지는 라우팅 테이블의 라우트 업데이트 방법에 있어서,

   라우팅 테이블 내 각 엔트리에 라우팅 프로토콜별 라우트 삽입 순서에 관한 정보를 저장하는 단계;

   라우팅 모듈의 재가동시 상기 저장된 라우트 삽입 순서에 따라 프리픽스 탐색을 수행하는 단계; 및

   상기 프리픽스 탐색 수행 결과, 프리픽스 매칭이 발생하는 경우 해당 라우팅 엔트리를 업데이트하고, 프리픽스 매칭이 성공하지 못한 경우 상기 트라이 구조에 따른 탐색을 수행하는 단계를 포함하는 라우트 업데이트 방법.
8. 제 7항에 있어서,

   상기 라우팅 테이블 내 각 엔트리는,

   프로토콜별 삽입 순서상의 이전, 이후의 엔트리와의 연결 정보를 포함하는 라우트 업데이트 방법.
9. 각 엔트리마다 프로토콜별 라우트 삽입 순서에 관한 정보를 트라이 구조로 저장하는 라우팅 테이블; 과

   재가동시 상기 저장된 라우트 삽입 순서에 따라 프리픽스 탐색을 수행하고, 상기 프리픽스 탐색 수행 결과, 프리픽스 매칭이 발생하는 경우 해당 라우팅 엔트리를 업데이트하는 라우팅 모듈을 포함하는 라우팅 시스템.
10. 제 9항에 있어서,

    상기 라우팅 모듈은,

    RIP 프로토콜에 따라 상기 라우팅 테이블의 각 엔트리에 대한 업데이트를 수행하는 RIP 라우팅 모듈;

    OSPF 프로토콜에 따라 상기 라우팅 테이블의 각 엔트리에 대한 업데이트를 수행하는 OSPF 라우팅 모듈; 및

    BGP 프로토콜에 따라 상기 라우팅 테이블의 각 엔트리에 대한 업데이트를 수행하는 BGP 라우팅 모듈을 포함하는 라우팅 시스템.
11. 제 9항에 있어서,

    상기 라우팅 모듈은,

    상기 프리픽스 탐색 수행 결과 프리픽스 매칭이 성공하지 못한 경우, 상기 트라이 구조에 따라 탐색을 수행하는 라우팅 시스템.
12. 제 9항에 있어서,

    상기 라우팅 테이블은,

    라우팅 프로토콜별 삽입 순서상의 이전, 이후의 엔트리와의 연결 정보를 포함하는 적어도 하나의 엔트리를 포함하는 라우팅 시스템.
13. 제 12항에 있어서,

    상기 연결 정보는,

    더블 링크드 리스트(double linked list) 형태로 표현되는 라우팅 시스템.
14. 제 9항에 있어서,

    상기 트라이 구조는,

    이진(Binary) 트라이, 패트리샤(Patricia) 트라이, 경로 압축 트라이, 멀티비트 트라이, LC-트라이 중 하나인 것을 특징으로 하는 라우팅 시스템.

Images