KR100462864B1

KR100462864B1 - 아이피브이6에서 인터페이스 아이디를 이용한 라우팅테이블 관리 방법

Info

Publication number: KR100462864B1
Application number: KR10-2002-0073232A
Authority: KR
Inventors: 최병구; 고은숙
Original assignee: 삼성전자주식회사
Priority date: 2002-11-22
Filing date: 2002-11-22
Publication date: 2004-12-17
Also published as: EP1422886A2; JP3878597B2; CN1503539A; US20040120266A1; CN100521682C; KR20040045188A; JP2004312683A; EP1422886A3; US7292539B2

Abstract

본 발명은 RIPng (Routing Information Protocol for next generation)을 지원하는 IPv6 라우터는 하나의 인터페이스에 여러 주소가 지정될 수 있어 라우팅 테이블 관리상에 어려움을 초래하고 있는바 이를 극복하기 위해서 각각의 인터페이스마다 고유한 인터페이스 ID를 사용하여 라우팅 테이블을 관리할 수 있도록 함으로써 다중 소스 주소에 의한 라우팅 테이블 관리상의 혼란을 방지할 수 있도록 하는 IPv6에서 인터페이스 ID를 이용한 라우팅 테이블 관리 방법에 관한 것이다.

또한, 본 발명에 따르면, 제1 라우터가 라우트 엔트리의 제1 필드에 소정값을 지정하고, 제2 필드에 인터페이스 ID값을 지정하여 생성된 라우팅 정보를 포함한 라우팅 정보 패킷을 제2 라우터로 전송하고, 상기 제2 라우터가 상기 제1 라우터로부터 수신한 라우팅 정보 패킷의 제1 필드값을 추출하여 추출된 필드값이 소정값이면, 제2 필드값을 추출하며, 상기 추출된 제2 필드값과 동일한 인터페이스 ID값을 갖는 라우트 엔트리의 라우팅 정보를 수신된 라우팅 정보 패킷의 라우팅 정보로 갱신한다.

Description

아이피브이6에서 인터페이스 아이디를 이용한 라우팅 테이블 관리 방법{Routing table Management Method using Interface ID in the IPv6}

본 발명은 IPv6에서 라우팅 테이블 관리 방법에 관한 것으로서, 특히 RIPng (Routing Information Protocol for next generation)을 지원하는 IPv6 라우터는 하나의 인터페이스에 여러 주소가 지정될 수 있어 라우팅 테이블 관리상에 어려움을 초래하고 있는바 이를 극복하기 위해서 각각의 인터페이스마다 고유한 인터페이스 ID를 사용하여 라우팅 테이블을 관리할 수 있도록 함으로써 다중 소스 주소에 의한 라우팅 테이블 관리상의 혼란을 방지할 수 있도록 하는 IPv6에서 인터페이스 ID를 이용한 라우팅 테이블 관리 방법에 관한 것이다.

컴퓨터의 인터넷(Internet) 통신을 제공하는 표준 프로토콜인 TCP/IP (Transport Control Protocol/Internet Protocol)는 다른 네트워크 프로토콜과 마찬가지로 계층으로 이루어져 있는데, 이를 프로토콜 스택(stack), 프로토콜 슈트(suite) 또는 프로토콜 구조라고 한다.

TCP/IP 프로토콜 스택은 TCP와 IP라는 2개의 가장 중요한 프로토콜을 기반으로 이루어져 있는데, IP 프로토콜은 OSI (Open Systems Interface) 계층 3에 해당하는 프로토콜로 현재 버전 4 (IPv4)가 주로 사용되고 있으며, 물리적인 서브네트워킹들의 연결과 목적지 IP 주소를 찾아가는 경로를 선택하는 기능이 있다.

이를 위해 IP 프로토콜은 인터넷에 연결된 많은 단말(terminals)이나 노드(node; IP 프로토콜을 구현하는 장치)들의 송신 주소와 수신 주소를 부여하고 해석한다. 현재 인터네트워크 층에서는 32-비트 IP 주소를 사용하여 네트워크 상의 호스트들 간에 상호 통신을 한다. IP 주소는 네트워크 IP와 노드 IP(호스트 IP)를 사용하여 특정 노드를 구별한다.

90년대 이후 인터넷 사용의 폭발적인 증가로 IPv4 프로토콜은 할당 가능한 자원의 부족, 이동성(mobility) 결여, 보안성 결여 등의 단점으로 개선의 필요성이 요구되었고, 이러한 단점을 해결하기 위한 새로운 표준 프로토콜인 IP 버전 6 (IPv6)이 개발되었다.

차세대 IP(IPng; Internet Protocol next generation)라고도 불리는 IPv6 프로토콜은 RFC 2460 표준문서에 기술되어 있다. IPv6 프로토콜은 IP 주소의 길이를 기존의 32-비트에서 128-비트로 확장했기 때문에 인터넷 주소 자원 고갈 문제를 해결할 수 있으며, 멀티미디어 데이터를 실시간으로 처리할 수 있도록 하고, IPv4 프로토콜에서는 보안기능을 위해 'Ipsec(Internet Protocol Security Protocol)'이라는 패치(patch) 형태의 프로토콜을 별도로 설치해야 했던 문제를 해결해 IPsec을 프로토콜 내에 탑재함으로써 보안 기능을 강화할 수 있도록 하는 등의 장점이 있다.

그런데, IPv6 프로토콜은 IPv4 프로토콜과 서로 다른 헤더 구조를 가지고 있기 때문에, 두 프로토콜 사이에는 호환성이 없다. 따라서, 향후에는 IPv4 망이 점차 IPv6 망이나 IPv4와 IPv6를 동시에 지원하는 망으로 대체될 전망이다. 또한, 최근에는 IPv6 프로토콜이 다양한 시험망과 일부 상용망을 통해 그 사용이 점차 확대되고 있다.

IPv6 응용 TCP/IP 표준 프로토콜은 응용 계층(Application Layer)과 TCP 또는 UDP(User Datagram Protocol)로 구현되는 전송 계층(Transport Layer), IPv6 및/또는 ICMPv6 (Internet Control Message Protocol for IPv6)로 구현되는 인터네트워크 계층(Internetwork Layer) 및 물리 계층(Physical Layer)으로 구성된다.

IPv6 데이터그램은 IPv4와 마찬가지로 헤더와 페이로드(payload) 2개 부분으로 구성된다. 페이로드는 2개의 호스트 사이에서 전송될 데이터를 전달하는 부분이다. IPv6 헤더는 40-바이트의 고정 크기를 가지며, IPv4에서 심각한 병목으로 밝혀진 헤더 체크섬 필드를 가지지 않는다. IPv6 프로토콜은 IPv4 프로토콜에서는 지원하지 않는 이동성 지원, 보안성 지원, 멀티미디어 응용의 품질 보장 등을 위한 헤더 구조를 가진다.

그리고, IPv6 표준 프로토콜의 헤더는 4-비트의 버전 필드, 8-비트의 트래픽 클래스 필드, QoS (Quality of Service)와 관련된 20-비트의 흐름 라벨 필드, 내용물의 길이를 나타내는 16-비트의 무부호 정수 페이로드 길이 필드, IPv6 헤더에서 다음에 이어지는 헤더의 유형을 정의하는 8-비트의 NH(Next Header) 필드, 패킷을 포워드하는 각각의 노드에서 1씩 감소하는 8-비트의 무부호 정수 홉 필드, 패킷 전송자의 128-비트 주소를 나타내는 발신지 주소 필드, 패킷 수신자의 128-비트 주소를 나타내는 목적지 주소 필드를 기본 헤더 필드로 포함한다.

IPv6을 완벽하게 구현하기 위해서 포함되는 확장 헤더 필드는 홉-바이-홉 옵션 필드, 목적지 옵션 헤더, 라우팅 헤더, 프레그먼트 헤더, 인증 헤더, ESP (Encapsulating Security Payload) 헤더 등을 포함한다.

그런데, 이러한 IPv6 표준 프로토콜은 주로 PC를 사용하는 환경에 적합하도록 소프트웨어로 구현되어 있으며, 보통은 윈도(Windows), 리눅스(Linux), 리얼타임(Real-time) OS 등과 같은 운영체제에 의해 처리되고 있다.

한편, 라우팅 프로토콜은 두가지의 일반적인 범주, 즉 내부 게이트웨이 프로토콜(IGP : Interior Gateway Protocol)과 외부 게이트웨이 프로토콜(EGP : Exterior Gateway Protocol)로 나눌 수 있다.

IGP는 한 도메인내에서 사용되는 라우팅 프로토콜로서, IPv4에서 현재 사용되는 대표적인 IGP용 프로토콜로는 RIP(Routing Information Protocol), OSPF(Open Shortest Path First), IS-IS 등이 있다.

EGP는 서로 다른 도메인간, 특히 AS간에 라우팅 정보를 교환하기 위해 사용되는 프로토콜로서, IPv4의 대표적인 EGP용 프로토콜로는 BGP등이 있다.

IGP는 EGP가 라우팅 정보를 하나 이상의 AS 사이에서 라우팅 정보를 전달하는 동안 AS내에서 라우팅 정보를 전달한다.

원론적으로 IPv6라우팅 기술은 기존의 IPv4와 다른점이 없다. 다만 라우팅 정책면에서 IPv4보다는 루트(route) 집합화(aggregation) 등 IPv6 어드레싱에 따른 엄격한 규정을 정의하고, 이에 맞게 라우팅 프로토콜을 설정하고 운용해야 한다는 점이 다를 뿐이다.

현재 표준화되었거나 표준화 중인 IPv6를 지원하는 라우팅 프로토콜은 다음과 같다.

◎IPv6 용 IGP 프로토콜

ㆍRIPng

ㆍOSPFv6

ㆍIPv6 지원 IS-IS

◎IPv6 용 EGP 프로토콜

ㆍBGP4+

RIP는 거리 벡터(distance Vector)기반의 알고리즘으로 구현된 현재 가장 많이 사용되고 있는 IGP용 프로토콜이다.

1988년에 최초로 이 프로토콜에 대한 정의가 내려졌고 RFC 1058에서 표준화가 되었다.

RIP는 거리 벡터 알고리즘에 기반한 프로토콜로서, 프로토콜 자체는 간단한 반면에 중소규모 네트워크를 위하여 설계되었으며, 다음과 같은 프로토콜 자체의 한계를 가지고 있다.

ㆍ가장 긴 경로는 15홉인 네트워크에 한정된다.

ㆍ라우팅 루프 등의 상황을 해결하기 위해 "무한대까지 카운팅"이라고 불리는 프로세스를 사용한다. 이 프로세스는 문제가 해결되기 전에 많은 양의 네트워크 자원을 소모하게 된다.

ㆍ지연, 신뢰도 또는 부하 등의 실시간 파라미터에 대해 고려는 하지 않고 대체 경로들을 비교하기 위해 고정된 측정 기준을 사용한다.

RIP 프로토콜은 RFC 1723(RIPv2)에 이어 RFC 2080(IPv6를 지원하는 RIPng 규격)이 정의되어 있다.

RIPng가 관리하는 IPv6용 라우팅 테이블 엔트리는 도 1을 참조하면, 목적지의 IPv6 프리픽스(prefix)(10), 목적지까지 데이터그램을 전송하는데 소요되는 전체 비용(cost)을 표시해주는 메트릭(metric)(16), 넥스트홉(nexthop)을 나타내는 next router의 IPv6 주소(24), 최근에 라우터가 변화했는지의 여부에 대한 정보를 나타내는 경로 변화 플래그(flag)(18), 라우팅 테이블 정보를 이웃 라우터에게 전송하는데 필요한 30초 타이머 (timer)(20, 22)의 정보를 가져야 한다.

RIPng는 UDP 기반의 프로토콜로서 UDP 포트번호 521 상에서 패킷을 송수신한다. RIPng 패킷은 커멘드(요청 또는 응답), 버전 그리고 경로 테이블 엔트리의 3가지 필드를 포함하고 있다.

각각의 경로 테이블 엔트리는 IPv6 프리픽스, 경로 태그(외부 라우터로부터 내부 라우터를 분리시키는), 프리픽스 길이 필드(프리픽스 내의 중요한 비트 수를 결정하는), 그리고 미터기(현재의 목적지 미터를 정의하는)를 포함하고 있다.

이 외에 RIPng는 패킷을 위해 즉각적인 다음 홉 IPv6 주소를 명시하는 기능을 제공한다. 다음 홉은 특정 RTE(Route Table Entry) 패킷과 Next Hop RTE(Route Table Entry) 패킷을 통해 지정된다.

Next Hop RTE(Route Table Entry) 패킷은 메트릭 필드에서 FFH 값에 의해 식별된다. 경로 태크와 프리픽스 길이는 송신시 제로로 설정되며 수신시에는 무시된다.

이 때 RIPng의 넥스트홉은 수신한 RIPng 패킷의 넥스트홉 필드(field)에 명시될 수도 있고 그렇지 않을 수도 있다.

보통은 0:0:0:0:0:0:0:0으로 지정되며, 수신한 RIPng패킷의 넥스트홉이 0:0:0:0:0:0:0:0일 때, 그 패킷을 송신한 라우터의 주소를 넥스트홉 주소로 지정한다.

만일 넥스트홉 주소가 명시되어 있을 경우, 이 주소는 반드시 링크 로컬 주소(link-local address)여야 한다.

왜냐하면 RIPng는 IPv4 버전인 RIP가 디자인 되었을 때 내부 게이트웨이 프로토콜(IGP : Interior Gateway Protocol)로 디자인되어 directly-connected 네트워크에서만 그 정보가 유효하고 링크 로컬 범위(link-local scope)에서 사용되기 때문에 링크 로컬 주소만을 사용한다.

즉, RIPng에서는 데이터그램의 IPv6 소스 주소 (source address)는 반드시 링크 로컬 주소여야 한다.

RIPng 버전 1은 요청과 응답이라는 두 가지 커맨드를 지원한다. 요청은 라우팅 테이블 전부 또는 일부를 요구하는데 사용된다. 대부분의 경우 요청은 RIPng(포트 521)로부터 멀티캐스터로서 송신된다.

단지 라우터 하나에 대한 정보가 필요할 경우 요청은 RIPng포트 이외에 다른 포터에서 그 라우터에 직접 송신될 것이다.

응답에는 특정 질의에 대한 응답, 모든 인접한 라우터에 30초마다 송신되는 응답인 규칙적인 업데이트, 그리고 라우터 변화가 일으키는 업데이트의 세가지 응답 타입이 있다.

요청과 응답 패킷 처리에 대한 특정 상세 사항은 RFC2080, RFC2081에서 설명되어 있다.

RFC2080에 따르면, RIPng에서 응답 메시지를 발생하는데 있어서, RIPng포트가 아닌 다른 포트의 유니캐스트 요구 메시지에 대해 응답하는 경우 이외에는 IPv6 소스 어드레스로 송신측 라우터 인터페이스의 사용 가능한 링크 로컬 어드레스가 사용되어야 한다.

유니 캐스트 요구 메시지에 대한 응답의 경우에 사용하는 소스 어드레스는 글로벌하게 유효한 주소(globaly valid address)여야 한다.

그리고 라우터의 사용가능한 링크 로컬 어드레스를 IPv6 소스 어드레스로 사용하는 것은 응답 메시지를 수신한 수신측 라우터가 라우팅 테이블의 다음 홉으로 소스 어드레스를 사용하기 때문이다.

만약 잘못된 소스 어드레스를 사용하게 되면, 다른 라우터는 데이터 그램을 라우팅 할 수 없다.

때때로 라우터는 다수개의 IPv6 어드레스를 하나의 물리적인 인터페이스를 위한 어드레스로 사용한다.

통상 이것은 여러개의 논리적인 IPv6의 네트워크가 하나의 물리적인 매체에 의해 구현될 수 있음을 의미한다.

하나의 라우터가 하나의 물리적인 인터페이스를 위해 다수의 링크 로컬 주소를 사용하는 것이 가능하다.

도 2는 일반적인 IPv6 라우터의 인터페이스에 지정된 다중 소스 주소의 예시도로서, IPv6 라우터의 하나의 인터페이스에 다중의 글로벌 IPv6 주소(multiple global IPv6 addresses)가 지정되거나 다중의 링크 로컬 IPv6 주소(multiple link-local IPv6 addresses)의 지정이 가능함을 보여준다.

도 2을 참조하면 IPv6 라우터의 인터페이스 eth0에는 다중의 IPv6 링크 로컬 주소가, IPv6 라우터의 인터페이스 eth1에 다중의 IPv6 글로벌 주소가 지정되어 있다.

이처럼 IPv6 라우터의 하나의 인터페이스에 다중 소스 주소가 지정되는 이유는 여러 개의 소스 주소와 목적지 주소 중 최적의 주소를 선택해 사용함으로써 목적지까지의 가장 효율적인 라우팅 경로를 찾기 위한 것이다.

이를 위해 최적의 소스 주소와 목적지 주소를 선택하기 위한 기법들이 현재 활발히 연구 중에 있다.

한편, 이처럼 하나의 라우터가 하나의 물리적인 인터페이스를 위해 다수의 링크 로컬 주소를 사용하는 경우에 라우터는 인터페이스를 위하여 정의된 링크 로컬 어드레스중에서 하나의 소스 어드레스를 사용하여 응답 메시지를 생성해야 한다.

그리고, 현재 사용중인 로컬 어드레스가 유효하지 않은 경우에 다른 로컬 어드레스로 교체하여 사용하게 된다.

그리고 이러한 소스 어드레스의 교체는 응답 메시지를 수신한 수신측 노드가 소스 주소로 송신측을 구별하기 위하여 사용하기 때문에 필요하다.

만약 동일한 라우터로부터 다른 소스 어드레스를 사용한 멀티 패킷을 라우터가 수신하게 되면 라우터는 멀티 패킷이 서로 다른 라우터로부터 수신된 것으로 추측하게 되어 바람직하지 않은 동작을 유발하게 된다.

즉, 같은 라우터로부터 수신한 여러 개의 패킷들이 각각 다른 링크 로컬 주소를 소스 주소로 지정하고 있다면, 패킷을 수신한 RIPng 라우터는 이 패킷들이 각각 다른 라우터로부터 수신한 것으로 처리한다.

그리고, 네트워크 프리픽스를 포함하고 있는 패킷을 전송하는 라우터가 지금까지 사용하던 링크 로컬 주소가 더 이상 유효하지 않게 되어 새로운 링크 로컬 주소를 소스 주소로 지정하여 전송한다 하더라도, 수신하는 라우터측에서는 이 패킷을 다른 라우터로부터 수신한 것으로 처리하게 된다.

예를 들어, R1 라우터가 I1 인터페이스에 지정된 fe80::1:2:3:4/10 이라는 링크 로컬 주소를 소스 주소로 R2 라우터에게 메트릭이 3인 10.0.0.0/8에 관한 라우팅 정보를 전송한 후 다음 업데이트 주기 내에 fe80::1:2:3:4/10 주소가 유효하지 않게 되어 fe80::5:6:7:8/10 주소를 소스 주소로 선택하고 메트릭이 5로 바뀌어 R2 라우터에게 10.0.0.0/8에 관한 업데이트 패킷을 전송한다.

이 때, R2 라우터는 이전에 수신한 라우팅 정보와 두 번째 수신한 라우팅 정보가 서로 다른 소스 라우터로부터 수신한 것이라고 생각하고 이에 대한 Decision Processing과정을 수행한다.

그 결과, 두 번째로 수신한 메트릭이 5이고 프리픽스가 10.0.0.0/8인 라우팅 정보는 무시된다. 즉, IPv6 라우터는 다중의 링크 로컬 주소를 사용함으로써 소스주소 선택에 있어 혼돈을 가져올 수 있으며, 수신측 라우터에서는 잘못된 라우팅 정보를 라우팅 테이블에 가지고 있을 수 있다.

그리고, 위에서 언급한 예와 같이 RIPng 라우터의 잘못된 동작을 방지하기 위해 소스 주소 선택에 관한 여러 알고리즘들이 연구 중에 있다. 그러나 이 알고리즘들은 다중의 주소 중 어느 주소를 소스 주소로 선택할 것인가에 관한 기법으로, 알고리즘에 따라 소스 주소를 선택하던 중 소스 주소가 바뀌는 경우에는 마찬가지로 RIPng 라우터에 혼돈을 야기할 수 있다.

따라서, 본 발명은 상기와 같은 문제점을 해결하기 위해서 안출된 것으로서, RIPng(Routing Information Protocol for next generation)을 지원하는 IPv6 라우터의 인터페이스에 다중 소스 주소가 지정되어 라우팅 테이블을 관리하는데 있어서 발생하는 혼란을 방지할 수 있도록 하는 IPv6에서 인터페이스 ID를 이용한 라우팅 테이블 관리 방법을 제공하는 것을 그 목적으로 한다.

도 1은 일반적인 RIPng의 라우팅 테이블의 구조도.

도 2는 일반적인 IPv6 라우터의 인터페이스에 지정된 다중 소스 주소의 예시도.

도 3은 본 발명이 적용되는 다수의 라우터의 연결 상태도.

도 4a는 일반적인 RIPng 패킷 포맷이고, 도 4b는 라우터 테이블 엔트리 포맷.

도 5는 수정된 RIPng의 라우팅 테이블 구조도.

도 6은 본 발명의 일실시예에 따른 송신측 라우터의 라우팅 정보를 포함한 패킷의 생성 및 전송 과정을 나타내는 흐름도.

도 7은 본 발명의 일실시예에 따른 수신측 라우터의 라우팅 정보를 포함한 수신 패킷의 처리 과정을 나타내는 흐름도.

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

RA~RE : 라우터 HA, HB : 호스트

상기와 같은 목적을 달성하기 위한 본 발명은, 다수개의 라우터와 다수개의 호스트로 이루어진 네트워크에 적용되는 라우팅 테이블 관리 방법에 있어서, 제1 라우터가 라우트 엔트리의 제1 필드에 소정값을 지정하고, 제2 필드에 인터페이스 ID값을 지정하여 생성된 라우팅 정보를 포함한 라우팅 정보 패킷을 제2 라우터로전송하는 제1 단계; 상기 제2 라우터가 상기 제1 라우터로부터 수신한 라우팅 정보 패킷의 제1 필드값을 추출하여 추출된 필드값이 소정값이면, 제2 필드값을 추출하는 제 2 단계; 및 상기 추출된 제2 필드값과 동일한 인터페이스 ID값을 갖는 라우트 엔트리의 라우팅 정보를 수신된 라우팅 정보 패킷의 라우팅 정보로 갱신하는 제 3 단계를 포함하여 이루어진 것을 특징으로 한다.

이제, 도 3 이하의 도면을 참조하여 본 발명의 바람직한 일실시예를 상세히 설명하면 다음과 같다.

도 3은 본 발명이 적용되는 다수의 라우터의 연결 상태도로서, 다중의 IPv6 링크 로컬 주소가 지정되어 있는 인터페이스를 가지고 있고 수정된 RIPng를 탑재하고 있는 다수의 IPv6 라우터(RA~RE)와, 다수의 라우터(RA~RE)에 연결되어 있는 다수의 IPv6 호스트(HA, HB)를 구비하고 있으며, 라우터들(RA~RE)과 호스트들(HA, HB)은 같은 네트워크상에 설치되어 있어야 한다.

수정된 RIPng를 탑재하고 있는 소스 라우터(RA~RE)는 이웃하는 라우터(RA~RE)로 라우팅 정보를 포함한 패킷을 전송하는 경우에 소스 주소 대신에 사용할 인터페이스 ID를 전송한다.

인터페이스 ID는 각 인터페이스마다 유일한 ID로서 하나의 인터페이스에 다중의 IPv6 링크 로컬 주소가 지정되어 있다 하더라도 맥어드레스를 이용하여 인터페이스 ID를 생성하기 때문에 인터페이스 ID는 단 하나만 존재한다. 본 발명에서는 설명의 편의를 위해서 인터페이스 ID를 생성하는데 맥어드레스를 사용하는 이더넷을 예로 들었지만 이더넷 이외의 다른 link의 경우에도 표준으로 정의되어 있는 바에 따라 인터페이스 ID를 생성할 수 있는데, ATM(Asynchronous Transfer Mode)의 경우에는 RFC2492에, 토큰링의 경우에는 RFC2470에, FrameRelay의 경우에는 RFC2590에, FDDI(Fiber Distributed Data Interface)의 경우에는 RFC2467에, NBMA(Non Broadcast Multi Access)의 경우에는 RFC2491에 각각 그 표준이 규정되어 있다.

도 1에서 인터페이스 eth0의 링크 로컬 주소는 2개가 지정되어 있는데, 이중 fe80::204:76ff:fe6f:7c1f/10에서 fe80은 프리픽스(prefix) 주소이고, 204:76ff:fe6f:7c1f가 인터페이스 ID이다.

도 4a는 일반적인 RIPng 패킷 포맷이고, 도 4b는 라우터 테이블 엔트리 포맷이다.

도면을 참조하면 일반적인 RIPng 패킷 포맷은 커멘드(command)(30), 버전(32), 다수의 라우트 테이블 엔트리(40a~40n)로 이루어져 있으며, 라우트 테이블 엔트리(40a~40n)는 IPv6 프리픽스(50), 라우트 태크(52), 메트릭(56)으로 구성되어 있다.

여기에서 소스 주소 대신 사용할 인터페이스 ID는 패킷당 하나만 있으면 되기 때문에 RIPng 패킷의 메트릭값이 0xFF일 경우에 프리픽스(50)에는 인터페이스 ID가 지정되어 있는 것으로 할 수 있다. 여기에서 0xFF값을 사용한 것은 메트릭값으로 1바이트(Byte)가 사용가능하며, 그중에서 0~16까지가 현재 사용되고 있기 때문에 17~255까지가 본 발명과 관련하여 사용가능하고 17~255중에서 255를 선택한 것이다.

한편, 수정된 RIPng를 탑재하고 있는 라우터(RA~RE)의 라우팅 테이블에는 소스 라우터(RA~RE)의 인터페이스 ID값을 저장하기 위해 인터페이스 ID필드를 구비해야 하며, 도 5는 수정된 RIPng의 라우팅 테이블 구조는 별도의 인터페이스 ID 필드가 구비되어 있음을 보여준다.

도면을 참조하면, 수정된 RIPng의 라우팅 테이블에는 RIPng의 라우팅 테이블 (routing table)은 목적지의 IPv6 프리픽스(prefix)(60), 목적지까지의 거리를 나타내는 메트릭(metric)(66), 플래그 (flag)(68), 타이머(timer)(70, 72), 넥스트홉 (nexthop)을 나타내는 next router의 IPv6 주소(74)를 가지고 있으며 추가적으로 인터페이스 ID값을 저장할 수 있는 인터페이스 ID 필드(76)를 가지고 있다.

수정된 RIPng를 탑재하고 있는 라우터(RA~RE)는 라우팅 정보를 포함하고 있는 패킷을 수신하면 수신된 패킷의 라우트 테이블 엔트리(40a~40n)중에 메트릭값이 0xFF인 라우트 테이블 엔트리가 있는 경우에 프리픽스(50)에는 인터페이스 ID가 저장되어 있음으로 프리픽스 필드의 값을 그 패킷의 소스 라우터(RA~RE)의 인터페이스 ID 필드(76)에 저장한다.

그리고, 라우터(RA~RE)는 라우트 엔트리를 처리하는 경우에 인터페이스 ID가 동일한지 여부를 비교해서 같은 경우에는 같은 소스 라우터(RA~RE)로부터 수신한 라우트 엔트리로 처리한다. 왜냐하면 인터페이스 ID는 인터페이스마다 유일한 값이기 때문이다.

이때, 라우터(RA~RE)는 패킷 수신시 소스 주소가 다를 경우에 인터페이스 ID를 비교해서 같은 경우에, 같은 소스 라우터(RA~RE)로부터 수신한 엔트리로 처리한다. 그 전에 라우팅 테이블의 넥스트 홉은 새 소스 주소로 업데이트 한다.

또한, 라우팅 테이블을 검색할 때 인터페이스 ID가 같은 엔트리를 먼저 검색한 후에 일치하는 프리픽스를 선택하며 이때는 소스 주소는 검색할 필요가 없다.

왜냐하면 인터페이스 ID가 일치하면 소스 주소가 다르다 하더라도 같은 라우터(RA~RE)로부터 수신한 라우트 엔트리 정보이기 때문이다.

도 6은 본 발명의 일실시예에 따른 송신측 라우터의 라우팅 정보를 포함한 패킷의 생성 및 전송 과정을 나타내는 흐름도이다.

도면을 참조하면, 송신측 라우터는 인터페이스 정보에서 고유한 인터페이스 ID를 추출하여(단계 S100), 패킷 생성시 최상위 라우트 엔트리의 메트릭 필드에 0xFF값을 지정하여(단계 S102), 라우트 엔트리의 프리픽스에 인터페이스 ID가 지정되어 있음을 표시한다.

다음에, 송신측 라우터는 메트릭 필드에 0xFF값이 지정되어 있는 라우트 엔트리의 프리픽스에 인터페이스 ID값을 지정하고(단계 S104), 기존의 RIPng 패킷 생성 과정을 거쳐 패킷 생성을 완료하며(단계 S106), 생성된 RIPng 패킷을 타 라우터로 전송한다(단계 S108).

도 7은 본 발명의 일실시예에 따른 수신측 라우터의 라우팅 정보를 포함한 수신 패킷의 처리 과정을 나타내는 흐름도이다.

도면을 참조하면, 수신측 라우터는 RIPng 패킷을 수신하면(단계 S210), 라우트 엔트리의 메트릭 필드값이 0xFF인지를 판단한다(단계 S212).

판단 결과, 메트릭 필드값이 0xFF값이 아니면 기존 RIPng에 따른 프로세스를진행하고(단계 S214), 메트릭 필드값이 0xFF값이면 프리픽스 필드에 소스 라우터의 인터페이스 ID값이 지정되어 있음으로 프리픽스 값을 추출하여(단계 S216), 인터페이스 ID값이 같은 라우팅 테이블이 존재하는지를 판단한다(단계 S218).

판단 결과, 인터페이스 ID가 같은 라우팅 테이블이 존재하면 라우팅 테이블을 업데이트하고(단계 S220), 인터페이스 ID가 같은 라우팅 테이블이 존재하지 않으면 소스 라우터의 인터페이스 ID값으로 저장한다(단계 S222).

한편, 여기에서는 IPv6를 위한 라우팅 프로토콜로서 RIP(Routing Information Protocol)에 있어서 다루었지만 OSPF(Open Shortest Path First)와 IS-IS(Intermediate System to Intermediate System)등 소규모의 네트워크에 사용되는 IGP(Interior Gateway Protocol)에서 사용 가능하다.

본 발명의 기술사상은 상기 바람직한 실시예에 따라 구체적으로 기술되었으나, 상기한 실시예는 그 설명을 위한 것이며, 그 제한을 위한 것이 아님을 주의하여야 한다. 또한, 본 발명의 기술분야의 통상의 전문가라면 본 발명의 기술사상의 범위에서 다양한 실시예가 가능함을 이해할 수 있을 것이다.

상기와 같은 본 발명에 따르면, 하나의 인터페이스에 다중의 IPv6 링크 로컬 주소가 지정됨으로써 발생할 수 있는 라우팅 문제를 해결할 수 있도록 하는 효과가 있다.

또한, 본 발명에 따르면 디폴트 주소 선택 기법 (default address selection mechanism)에 있어서 아직도 응용 레벨(application level)에서 해결할 것인지 아닌지에 대한 논의가 계속해서 이루어지고 있는 실정이나 여기서 응용 레벨(application level)보다 하위 레벨(level)에서 이를 제어한다 하더라도 물리적인 인터페이스(physical interface)의 고유 ID를 사용한다면, 소스 어드레스가 무엇이건 상관없이 RIPng를 사용할 수 있도록 하는 효과가 있다.

Claims

다수개의 라우터와 다수개의 호스트로 이루어진 네트워크에 적용되는 라우팅 테이블 관리 방법에 있어서,

제1 라우터가 라우트 엔트리의 제1 필드에 소정값을 지정하고, 제2 필드에 인터페이스 ID값을 지정하여 생성된 라우팅 정보를 포함한 라우팅 정보 패킷을 제2 라우터로 전송하는 제1 단계;

상기 제2 라우터가 상기 제1 라우터로부터 수신한 라우팅 정보 패킷의 제1 필드값을 추출하여 추출된 필드값이 소정값이면, 제2 필드값을 추출하는 제 2 단계; 및

상기 추출된 제2 필드값과 동일한 인터페이스 ID값을 갖는 라우트 엔트리의 라우팅 정보를 수신된 라우팅 정보 패킷의 라우팅 정보로 갱신하는 제 3 단계를 포함하여 이루어진 라우팅 테이블 관리 방법.
제 1 항에 있어서,

상기 제2 필드에 지정되는 인터페이스 ID는, 맥어드레스를 사용하여 생성된 것을 특징으로 하는 라우팅 테이블 관리 방법.
제 1 항에 있어서,

상기 제 1 단계는,

상기 제1 라우터가 인터페이스 정보에서 인터페이스 ID를 추출하는 제 1-1 단계;

상기 제1 라우터가 라우트 엔트리의 제1 필드에 소정값을 지정하는 제 1-2 단계;

상기 제1 라우터가 라우트 엔트리의 제2 필드에 상기 제 1-1 단계에서 추출한 인터페이스 ID를 지정하는 제 1-3 단계;

상기 제 1-2 단계에 의해 소정값이 지정된 제1 필드와 상기 제 1-3 단계에 의해 인터페이스 ID가 지정된 제2 필드를 포함하고, 라우팅 정보를 포함한 라우팅 정보 패킷을 생성하는 제 1-4 단계; 및

상기 제1 라우터가 상기 제 1-4 단계에서 생성된 라우팅 정보 패킷을 상기 제2 라우터로 전송하는 제 1-5 단계를 포함하여 이루어진 라우팅 테이블 관리 방법.
제 1 항에 있어서,

상기 제 3 단계는,

상기 제 2 단계에서 추출한 인터페이스 ID값과 동일한 인터페이스 ID값을 갖는 라우트 엔트리가 라우팅 테이블에 존재하는지를 판단하는 제 3-1 단계;

상기 제 3-1 단계의 판단 결과, 인터페이스 ID가 같은 라우트 엔트리가 라우팅 테이블에 존재하면 라우트 엔트리의 라우팅 정보를 수신된 라우팅 정보 패킷의 라우팅 정보로 업데이트하는 제 3-2 단계; 및

상기 제 3-1 단계의 판단 결과, 인터페이스 ID가 같은 라우트 엔트리가 라우팅 테이블에 존재하지 않으면 소스 라우터의 인터페이스 ID값으로 수신된 인터페이스 ID값을 지정하고 수신된 라우팅 정보 패킷의 라우팅 정보를 이용하여 라우트 엔트리를 생성하는 제 3-3 단계를 포함하여 이루어진 라우팅 테이블 관리 방법.
제1 항 내지 제 4 항 중 어느 한 항에 있어서,

상기 제1 라우터와 제2 라우터간의 라우팅 프로토콜로 IGP(Interior Gateway Protocol)가 사용되는 것을 특징으로 하는 라우팅 테이블 관리 방법.
제1 항 내지 제 4 항 중 어느 한 항에 있어서,

상기 제1 라우터와 제2 라우터간의 라우팅 프로토콜로 RIPng (Routing Information Protocol for next generation)가 사용되는 것을 특징으로 하는 라우팅 테이블 관리 방법.
제 6 항에 있어서,

상기 제1 필드는 메트릭 지정 필드이고, 상기 제2 필드는 프리픽스 필드인 것을 특징으로 하는 라우팅 테이블 관리 방법.
제 7 항에 있어서,

상기 메트릭 지정 필드의 필드값으로 17~255중 하나가 사용되는 것을 특징으로 하는 라우팅 테이블 관리 방법.