KR20030055670A - 패킷데이터서비스노드 시스템의 라우팅 정보 프로토콜업데이트 방법 - Google Patents

Abstract

본 발명은 PDSN과 같이 다수개의 IP 어드레스를 가지는 시스템에서 라우팅 정보 프로토콜을 사용하려 할 때 서로의 라우팅 테이블에 영향을 주지 않고 업데이트 메시지를 전송하기에 적당하도록 한 패킷데이터서비스노드 시스템의 라우팅 정보 프로토콜 업데이트 방법을 제공하기 위한 것으로, 다수의 아이피(IP) 어드레스를 갖는 시스템내 서로 인접해 있는 프로세서 보드들간에 IP 어드레스 정보가 전송되도록 설정하는 단계와; 자신이 속한 서브넷의 라우팅 수단으로부터 라우팅 정보 업데이트 메시지가 전송되는 경우, 각 프로세서 보드는 전송된 인접 프로세서 보드의 IP 어드레스 정보를 참조하여 라우팅 정보 업데이트 메시지의 원천지가 자신에 인접한 프로세서 보드인지 여부를 확인하는 단계와; 라우팅 정보 업데이트 메시지의 원천지가 자신에 인접한 프로세서 보드인 것으로 판정되면 해당 프로세서 보드는 라우팅 정보 업데이트 메시지를 버려 자신의 라우팅 테이블을 업데이트 하지 않는 단계를 포함하여 이루어지며, PDSN 시스템에 속해 있는 모든 HLP 보드 등의 프로세서 보드들이 자신이 받은 RIP 업데이트 메시지의 원천 어드레스를 검사하여 인접 보드에서 온 업데이트 메시지들은 자신의 라우팅 테이블에 적용하지 않도록 함으로써, 특정한 보드 실패시 다른 보드로 패킷이 올바르지 않게 포워딩 되는 것을 막을 수 있게 된다.

Description

패킷데이터서비스노드 시스템의 라우팅 정보 프로토콜 업데이트 방법 {Method for Routing Information Protocol update in Packet Data Service Node system}

본 발명은 패킷데이터서비스노드(Packet Data Service Node, 또는 PDSN) 시스템의 라우팅 정보 프로토콜(Routing Information Protocol, 또는 RIP) 업데이트에 관한 것으로, 보다 상세하게는 PDSN과 같이 다수개의 IP(Internet Protocol) 어드레스를 가지는 시스템에서 라우팅 정보 프로토콜을 사용하려 할 때 서로의 라우팅 테이블에 영향을 주지 않고 업데이트 메시지를 전송하기에 적당하도록 한 패킷데이터서비스노드 시스템의 라우팅 정보 프로토콜 업데이트 방법에 관한 것이다.

일반적으로 3세대 이동통신망의 구현시 3GPP2(3rd Generation Partnership Project 2)에 따른 동기식 통신망을 구현하는 경우에 PDSN 시스템이 적용된다.

도1은 일반적인 PDSN 시스템의 적용 블록도이다.

일반적인 PDSN 시스템의 데이터 전송시, 사용자의 노트북 컴퓨터 등을 모바일 노드(110) 즉, 이동 단말기에 연결하여 데이터 전송을 시도하면, 해당 모바일 노드(110)에서 이동통신망의 무선망 제어기(120)로 신호를 보내고 이 신호는 PDSN 시스템(130)에서 받아 처리하는 절차를 거친다. 이렇게 PDSN 시스템(130)에서 처리된 데이터는 IP 네트워크(150)를 통해 엔드 호스트로 전달되어진다.

PDSN 시스템(130)은 AAA(Administration, Authorization, and Authentication)(140)를 이용하여 가입자 정보 관리, 인증, 및 과금 정보 수집 등을 수행한다.

IP 네트워크(150)를 기준으로 보면, PDSN 시스템(130)은 외부 에이전트(Foreign Agent, 또는 FA)가 되고, IP 네트워크(150) 내의 사설 IP와 공중 IP를 포함한 바인딩 리스트는 홈 에이전트(Home Agent, 또는 HA)(160)의 바인딩 테이블에 의해 관리된다.

이러한 PDSN 시스템(130)은 심플 IP 프로토콜과 모바일 IP 프로토콜을 지원한다.

한편, 라우팅 정보 프로토콜(RIP)은 기업의 근거리통신망(LAN), 또는 그러한 근거리통신망들이 서로 연결된 그룹과 같은 독립적인 네트워크 내에서 라우팅 정보 관리를 위해 광범위하게 사용되는 프로토콜이다. 라우팅 정보 프로토콜은IETF(Internet Engineering Task Force)에 의해 여러 내부 게이트웨이 프로토콜(IGP) 중의 하나로 분류된다.

라우팅 정보 프로토콜을 사용하면, 라우터 내의 게이트웨이 호스트는 전체 라우팅 테이블을 가장 가까운 인근 호스트에 매 30초마다 보낸다. 인접한 호스트는 자신의 차례가 되면 그 정보를 그 다음 인접한 호스트로 넘기는데, 이러한 전달은 그 네트워크 내의 모든 호스트들이 같은 라우팅 경로 정보를 가질 때까지 계속된다. 라우팅 정보 프로토콜은 네트워크 거리를 결정하는 방법으로 홉의 총계(홉 카운트)를 사용한다(반면, 다른 프로토콜들은 타이밍까지를 포함하는 보다 정교한 알고리즘을 사용한다). 네트워크 내에 라우터를 갖고 있는 각 호스트는 패킷을 전달할 다음 호스트를 결정하기 위해 라우팅 테이블 정보를 사용한다.

이러한 라우팅 정보 프로토콜의 기능 중에 심플 스플리트 허리즌(Simple Split Horizon)이 있다. 이는 어떤 네트워크 N에 인접한 라우터 A가 N에 대한 정보를 라우터 B에게 전송했을 때, 라우터 B는 이 정보를 다시 라우터 A에게 전송할 필요가 없다는 것으로, 이 규칙을 적용하여 인접한 두 라우터가 라우팅 루프에 빠지는 것을 방지할 수 있다.

라우팅 정보 프로토콜은 라우터의 메모리를 적게 사용하며 IP 프로토콜 뿐만 아니라 IPX(Internetwork Packet Exchange) 프로토콜도 라우팅 할 수 있는 반면, 라우팅 정보를 매 30초마다 방송하여야 한다. 네트워크의 변화가 없어도 30초마다 라우팅 정보를 방송하기 때문에 라우팅 정보 발송에 의한 트래픽이 많이 발생하는 편이다.

그리고 라우팅 정보 프로토콜은 VLSM(Variable Length Subnet Mask)를 지원하지 못한다. 따라서 라우팅 정보 프로토콜로 네트워크를 구성할 경우에 서브넷 매스크(Subnet Mask)를 동일하게 설계하여야 한다.

초기 라우팅 정보 프로토콜 버전의 단점을 보완하기 위해 라우팅 정보 프로토콜 버전 2(RIPv2)가 개발되었다. RIPv2는 VLSM을 지원하며 라우팅 정보는 네트워크에 변화가 있을 때에만 전달하는 등의 기능 향상이 보장된다.

그런데 이러한 라우팅 정보 프로토콜의 동작은 RIPv2를 기준으로 할 때 방송 어드레스(Broadcast Address)나 멀티캐스트 어드레스(Multicast Address)를 목적지 어드레스로 사용하게 된다. 따라서 PDSN 시스템(130)에의 적용시 모든 HLP 보드는 인접 HLP 보드의 라우팅 테이블 정보를 자신의 라우팅 테이블에 기록한 후 사용하게 된다.

이처럼 종래기술에서는 하나의 서브넷(홈 IP 네트워크 등)에는 하나의 라우터만 존재하는 것으로 생각하여 심플 스플리트 허리즌 등의 방법으로 올바르지 못한 라우팅 테이블 업데이트를 방지하였으나, PDSN 시스템의 경우에는 하나의 서브넷에 여러 개의 라우터가 올라가게 되어 있으므로 심플 스플리트 허리즌 방법으로는 잘못된 라우팅 테이블 업데이트를 방지할 수 없는 문제가 있다.

따라서 PDSN 시스템에 라우팅 정보 프로토콜을 적용하기 위해서는 잘못된 라우팅 테이블 업데이트를 방지하여야 할 것이 요구된다.

본 발명은 상기와 같은 종래의 문제점을 해소하기 위해 창출된 것으로, 본발명의 목적은 PDSN과 같이 다수개의 IP 어드레스를 가지는 시스템에서 라우팅 정보 프로토콜을 사용하려 할 때 서로의 라우팅 테이블에 영향을 주지 않고 업데이트 메시지를 전송하기에 적당하도록 한 패킷데이터서비스노드 시스템의 라우팅 정보 프로토콜 업데이트 방법을 제공하는 것이다.

상기 목적을 달성하기 위한 본 발명의 패킷데이터서비스노드 시스템의 라우팅 정보 프로토콜 업데이트 방법은, 다수의 아이피(IP) 어드레스를 갖는 시스템내 서로 인접해 있는 프로세서 보드들간에 IP 어드레스 정보가 전송되도록 설정하는 단계와; 자신이 속한 서브넷의 라우팅 수단으로부터 라우팅 정보 업데이트 메시지가 전송되는 경우, 각 프로세서 보드는 상기 전송된 인접 프로세서 보드의 IP 어드레스 정보를 참조하여 상기 라우팅 정보 업데이트 메시지의 원천지가 자신에 인접한 프로세서 보드인지 여부를 확인하는 단계와; 상기 라우팅 정보 업데이트 메시지의 원천지가 자신에 인접한 프로세서 보드인 것으로 판정되면 해당 프로세서 보드는 상기 라우팅 정보 업데이트 메시지를 버려 자신의 라우팅 테이블을 업데이트 하지 않는 단계를 포함하는 것을 그 특징으로 한다.

도1은 일반적인 PDSN 시스템의 적용 블록도.

도2는 본 발명의 실시예가 적용되는 PDSN 시스템과 라우터간 메시지 교환 블록도.

도3은 본 발명의 실시예에 따른 패킷데이터서비스노드 시스템의 라우팅 정보 프로토콜 업데이트 방법의 순서도.

이하, 첨부도면을 참조하여 본 발명에 따른 바람직한 실시예를 설명한다.

도2는 본 발명의 실시예가 적용되는 PDSN 시스템과 라우터간 메시지 교환 블록도이며, 도3은 본 발명의 실시예에 따른 패킷데이터서비스노드 시스템의 라우팅 정보 프로토콜 업데이트 방법의 순서도이다.

도2에 도시된 바와 같이 PDSN 시스템(130)에는 다수의 상위계층프로세서(Higher Layer Processing, 이하 HLP) 보드가 존재한다.

PDSN 시스템(130)에서 HLP 보드(131)(132)는 상위 계층에 대하여 구문해석(Parsing), 프레이밍(framing), 패킷 분류(packet classification), 그리고 개조(modification) 등을 수행한다. 암호화 및 압축 프로세서가 지원되며, 가속을 위한 적정한 프로세서가 구비된다. 더불어 큐 처리 및 트래픽 관리 기능을 통해 패킷을 다른 우선순위 큐에 위치시키고 트래픽 상태에 따라 패킷을 분기시키는 기능을 수행한다.

본 실시예는 하나의 PDSN 시스템(130)에 속해 있는 모든 HLP 보드(131)(132)들이 자신과 인접해 있는 HLP 보드(131)(132)들의 IP 어드레스를 알 수 있기 때문에 자신이 받은 업데이트 메시지의 원천 어드레스를 검사하여 인접 HLP 보드(131)(132)에서 온 업데이트 메시지들은 자신의 라우팅 테이블에 적용하지 않는다.

따라서 HLP 보드(131)(132) 이외의 다른 라우터(200)에 업데이트 메시지를 보낼시 순수하게 자신만의 라우팅 테이블 내용을 보낼 수 있으므로, 만약 특정한 HLP 보드 실패시 다른 HLP 보드로 패킷이 올바르지 않게 포워딩(Forwarding) 되는 것을 막을 수 있다.

RIP는 RFC1058 표준에 따른 도메인내의 라우팅 프로토콜로서 네트워크 구성상 계층은 없고 평면적이다. RIP에서 사용하는 매트릭은 홉 카운트(또는 홉수)(Hop Count)이다.

RIP에서는 홉 카운트를 사용하여 도달할 목적지까지 몇 개의 게이트웨이 즉,라우터(200)를 거치는가 하는 거리를 측정한다.

RIP는 거리값(Distance vector)에 근거한 알고리즘으로서, 이는 목적지까지의 거리가 최적 경로 결정의 판단기준이 됨을 의미한다. 거리값에 근거한 알고리즘은 요청과 응답이라는 2가지 종류의 패킷 형태만이 존재한다. 요청패킷은 라우터(200)가 처음으로 부팅 되었을 때, 혹은 어떤 특정 목적지 정보가 타임아웃 되었을 때 보내지게 되며, 전체 목적지 정보 혹은 특정 부분의 목적지 정보들을 요청할 수 있다. 응답패킷은 실제 목적지에 대한 정보를 담고 있는 패킷으로서, 다음의 3가지 중 하나의 항목에 해당하면 응답패킷을 전송하게 된다.

첫째, RIP는 30초에 한번씩 자기의 목적지 정보 전체를 이웃 라우터(200)에게 전송하도록 되어 있다. 그리고 만약 특정 목적지에 대한 정보가 일정 기간 동안(타임아웃:180초) 이웃 라우터(200)로부터 전송되지 않으면 무효(invalid) 목적지로 간주하며, 이 무효 목적지 정보를 이웃 라우터(200)에 알리기 위한 시간만큼 기다린 다음(Garbage 수집 시간:120초), 특정 목적지 라우터(200)는 라우팅 테이블에서 삭제가 된다. 따라서 각 목적지에 대한 정보는 주기적으로 이웃 라우터(200)에게 전송되어야 한다(라우팅 정보의 변화가 없을 때에도 라우터(200)는 업데이트된 정보를 전송한다).

둘째, 상대 라우터(200)의 요청패킷이 있을 때 이에 대한 응답패킷을 전송하게 된다.

셋째, 이웃 라우터(200)에 전송한 어떤 특정 목적지 정보가 변경되었을 때, 이 변경된 정보를 이웃 라우터(200)에게 알려 준다.

응답패킷을 수신한 경우, 라우터(200)는 수신된 정보를 통해 최적 경로를 결정하게 되는데 수신된 목적지의 거리값(+ 수신 네트워크의 거리값(1))과 현재 유지하고 있는 거리값을 비교하여 작은 것을 목적지에 대한 경로로 유지하게 된다.

만일 새롭게 업데이트된 내용이 라우팅 테이블에 존재하는 엔트리의 소스인 라우터(200)로부터 받게 된다면, 라우터(200)는 그것이 이전보다 더 크다고 할지라도 새로운 홉카운트를 사용하게 될 것이다.

이러한 RIP 업데이트 메시지 처리 과정은 도3에 도시된 바와 같은 흐름을 따른다.

우선, 하나의 라우터(200)가 지원하는 동일 서브넷에 연결되어 있는 PDSN 시스템(130)내의 여러 장의 HLP 보드들이 서로 인접해 있는 HLP 보드(131)(132)의 IP 어드레스를 획득할 수 있도록 설정한다. 즉, 각 HLP 보드(131)(132)마다 고유의 IP 어드레스가 할당되어 이 IP 어드레스 정보를 인접한 HLP 보드들간에 교환되도록 하면 되는데, 이러한 요구는 HLP 보드들간의 신호 전송 방식을 응용하여 용이하게 달성될 수 있다. 예를 들어 패킷 전송이 이루어지는 경우에는 각 HLP 보드(131)(132)가 해당 패킷에 자신의 IP 어드레스를 붙여 인접한 HLP 보드(131)(132)로 전송하고, 이를 수신하는 HLP 보드(131)(132)가 해당 패킷에서 IP 어드레스 정보를 추출하도록 하면 된다. 다른 예를 들어 보면, 각 HLP 보드(131)(132)가 인접 HLP 보드(131)(132)로 전달하는 RIP 업데이트 메시지 자체에 IP 헤더를 붙이는 방식도 가능하다(S31).

IP 어드레스 전송을 위한 설정이 이루어진 상태라면, 라우터(200)가 지원하는 동일 서브넷에 연결된 PDSN 시스템(130)내 여러 장의 HLP 보드(131)(132)는 RIP 세션을 시작하며, RIP 업데이트 메시지를 주기적으로 송수신하게 된다(S32~S33).

이때 일반적인 RIP 처리의 경우에는 인접된 HLP 보드(131)(132)와 라우터(200)는 이 업데이트 메시지를 모두 수신하여 자신의 라우팅 테이블을 업데이트 하게 된다.

그렇게 되면 HLP#1 보드(131)는 HLP#n 보드(132)가 지원하는 서브넷에 대하여 매트릭 2의 값을 가지고 라우팅 테이블을 구성하게 된다. 그리고 이 정보를 라우터(200)로 송신하게 되면 라우터(200)는 HLP#1 보드(131) 실패시 HLP#n 보드(132)를 대체 라우터(200)로 판단하여 HLP#1 보드(131)로 향하는 패킷들을 HLP#n 보드(132)로 보내게 된다.

이 경우에는 실제 패킷을 라우팅해 줄 수 없으면서 네트워크의 자원만 낭비하는 결과를 초래하게 된다.

그래서 본 실시예는 네트워크 자원의 낭비를 막기 위하여 각 HLP 보드(131)(132)들이 PDSN 시스템(130)내 인접 HLP 보드들의 어드레스 정보를 얻은 후, 해당 어드레스에서 들어오는 RIP 업데이트 메시지를 자신의 라우팅 테이블에 업데이트 시키지 않고 버림으로써 잘못된 정보가 라우터(200)에 전달되지 못하도록 한다(S34, S35, S36).

그러면 라우터(200)는 각각의 HLP 보드들이 지원하는 각각의 서브넷 정보만 가지게 되므로, 특정 HLP 보드 실패시 다른 HLP 보드로 패킷을 포워딩하는 잘못된 라우팅을 막을 수 있게 된다.

반면에 단계 S35에서의 판단 결과, RIP 업데이트 메시지의 원천지가 인접 HLP 보드(131)(132)가 아닌 것으로 판정되는 경우에는 종래와 같이 처리하게 된다. 즉, 해당 RIP 업데이트 메시지를 모두 수신하여 자신의 라우팅 테이블을 업데이트 하게 되는 것이다. 따라서 HLP 보드(131)(132)의 라우팅 테이블 업데이트가 이루어진다(S37).

이처럼 본 실시예는 하나의 서브넷에 다수의 라우터가 들어가는 시스템의 경우에 RIP 업데이트 메시지에 따른 잘못된 라우팅 테이블 업데이트를 방지할 수 있게 된다.

이상 설명한 실시예는 본 발명의 다양한 변화, 변경 및 균등물의 범위에 속한다. 따라서 실시예에 대한 기재내용으로 본 발명이 한정되지 않는다.

본 발명의 패킷데이터서비스노드 시스템의 라우팅 정보 프로토콜 업데이트 방법에 따르면, PDSN 시스템에 속해 있는 모든 HLP 보드들이 자신이 받은 업데이트 메시지의 원천 어드레스를 검사하여 인접 HLP 보드에서 온 업데이트 메시지들은 자신의 라우팅 테이블에 적용하지 않도록 함으로써, 특정한 HLP 보드 실패시 다른 HLP 보드로 패킷이 올바르지 않게 포워딩 되는 것을 막을 수 있게 된다.

Claims (4)

1. 다수의 아이피(IP) 어드레스를 갖는 시스템내 서로 인접해 있는 프로세서 보드들간에 IP 어드레스 정보가 전송되도록 설정하는 단계와;

   자신이 속한 서브넷의 라우팅 수단으로부터 라우팅 정보 업데이트 메시지가 전송되는 경우, 각 프로세서 보드는 상기 전송된 인접 프로세서 보드의 IP 어드레스 정보를 참조하여 상기 라우팅 정보 업데이트 메시지의 원천지가 자신에 인접한 프로세서 보드인지 여부를 확인하는 단계와;

   상기 라우팅 정보 업데이트 메시지의 원천지가 자신에 인접한 프로세서 보드인 것으로 판정되면 해당 프로세서 보드는 상기 라우팅 정보 업데이트 메시지를 버려 자신의 라우팅 테이블을 업데이트 하지 않는 단계를 포함하는 것을 특징으로 하는 패킷데이터서비스노드 시스템의 라우팅 정보 프로토콜 업데이트 방법.
2. 제 1항에 있어서,

   상기 다수의 IP 어드레스를 갖는 시스템은 패킷데이터서비스노드(PDSN) 시스템이며, 상기 프로세서 보드들은 상위계층 프로세서(HLP) 보드인 것을 특징으로 하는 패킷데이터서비스노드 시스템의 라우팅 정보 프로토콜 업데이트 방법.
3. 제 1항에 있어서,

   각 프로세서 보드가 상기 시스템내 프로세서 보드 이외의 다른 라우터에 상기 라우팅 정보 업데이트 메시지를 보낼 경우에는 자신만의 라우팅 테이블 내용을 보내도록 하여, 특정 프로세서 보드 실패시 다른 프로세서 보드 패킷이 잘못 포워딩되지 않도록 동작되는 것을 특징으로 패킷데이터서비스노드 시스템의 라우팅 정보 프로토콜 업데이트 방법.
4. 제 1항에 있어서,

   상기 수신되는 라우팅 정보 업데이트 메시지의 원천지가 인접 프로세서 보드가 아닌 것으로 판정되는 경우, 상기 프로세서 보드는 해당 라우팅 정보 업데이트 메시지를 모두 수신하여 자신의 라우팅 테이블을 업데이트 하게 되는 것을 특징으로 패킷데이터서비스노드 시스템의 라우팅 정보 프로토콜 업데이트 방법.