기존의 인터넷에서는 호스트에게 망 식별자와 호스트 식별자로 구성되는 하나의 IP(Internet Protocol) 주소가 할당된다. 망 식별자는 호스트가 접속되어 있는 망을 유일하게 나타내기 위한 정보이며, 호스트 식별자는 해당 망에서 호스트를 유일하게 식별하기 위한 정보이다. 호스트는 IP 주소와 전송 계층의 포트 번호를 이용하여 소켓 주소를 만들고, 이러한 소켓 주소를 이용하여 다른 호스트들과 연결을 설정한다. 호스트가 다른 호스트와 연결을 설정하면, 연결이 설정되어 있는 동안에는 동일한 IP 주소가 고정적으로 유지되어야 한다.

만일 호스트가 하나의 망에서 다른 망으로 이동하는 경우에는 망 식별자가 변경되어야 하기 때문에 호스트에 할당된 IP 주소가 변경되어야 한다. IP 주소의 변경은 소켓 주소의 변경을 의미하기 때문에 기존에 설정되어 있는 연결은 해지되며 다시 연결을 시도해야 한다는 단점이 있다. 이와 같이 호스트가 망을 변경하여 인터넷에 접속하는 경우에 발생하는 연결 해지 문제를 해결하기 위하여 이동 노드(Mobile Node: MN)가 자신이 위치를 변경하더라도 기존에 설정되어 있는 연결을 계속 유지할 수 있도록 하기 위한 Mobile IPv6(MIPv6) 기술이 제안되었다. MIPv6 프로토콜에서 노드는 자신이 하나의 망에서 다른 망으로 이동했다는 것을 감지하게 되면 MIPv6 프로토콜에서 정의된 동작을 수행한다. 즉 MIPv6 프로토콜은 노드-기반 이동성 지원 프로토콜이라 할 수 있다. 비록 MIPv6 기술이 표준으로 정의되어 있기는 하지만 현재 사용되고 있는 모든 노드들이 MIPv6 기능을 갖추고 있다고 볼 수는 없으므로, MIPv6 기능을 구현하고 있지 않은 노드는 하나의 망에서 다른 망으로 이동을 할 때마다 기존에 설정되어 있는 연결을 종료하고 새로 개설해야 하는 문제가 발생한다. 이를 방지하기 위하여, MIPv6 기능이 구현되어 있지 않은 노드가 이동을 하더라도 기존에 설정되어 있는 연결이 계속 유지될 수 있도록 액세스 망에서 노드의 이동성을 지원하기 위한 기술이 제안되었으며, 이러한 기술을 네트워크-기반 이동성 관리 기법이라고 한다. 네트워크-기반 이동성 관리 기법은 현재 IETF의 netlmm(Network-based Localized Mobility Management) 워킹 그룹에서 표준화가 진행 중에 있다.

그림 1은 네트워크-기반 이동성 관리를 위하여 고려되는 망 구조를 보여준다. LMA(Localized Mobility Anchor)는 액세스 망 내부에서 MN을 위한 일종의 HA(home agent)로서 동작한다. 또한 MAG(Mobility Access Gateway)는 MN을 대신하여 MN의 이동성을 지원하는 장치이다. 네트워크-기반 이동성 지원 기법의 동작을 설명하면 다음과 같다. MN이 액세스 망에 있는 하나의 MAG(즉, MAG1)에 접속하면, MAG1은 MN에게 네트워크 프리픽스를 광고하고, MN은 이 정보를 이용하여 하나의 IP 주소를 할당 받는다. MAG1은 MN에게 할당한 IP 주소와 MAG1 자신의 IP 주소 정보를 LMA에 등록한다. 이 정보를 이용하여 LMA는 MN의 IP 주소와 MAG1의 주소에 대한 바인딩 정보를 저장한다. 또한 MAG1은 MN의 IP 주소와 LMA 주소에 대한 바인딩 정보를 저장한다. 즉, LMA와 MAG1 사이에는 MN을 위한 터널이 설정되어, MN과 임의의 노드 사이에 교환되는 트래픽은 이 터널을 이용하여 전송된다. 만일 MN이 새로운 망으로 이동을 하게 되면, MN의 MAC 주소와 같은 제 2 계층의 정보를 이용하여 새로운 MAG(즉, MAG2)는 MN이 접속했다는 것을 알게 된다. MAG2는 MAG1이 제공한 것과 동일한 네트워크 프리픽스를 MN에게 광고한다. 이 광고 메시지를 수신한 MN은 비록 자신이 이동을 하였지만, 동일한 네트워크 프리픽스를 수신하였기 때문에 동일한 네트워크 내에 있다고 간주한다. 즉, MN은 동일한 망 내에서의 이동이기 때문에 어떠한 부가적인 동작을 할 필요가 없다. MAG2는 MN의 IP 주소와 자신의 IP 주소를 LMA에게 등록하고, LMA와 MN의 IP 주소에 대한 바인딩 정보를 저장한다. LMA는 이 정보를 이용하여 자신의 바인딩 캐쉬에 있는 MN 관련 엔트리를 MAG1에서 MAG2로 수정한다. 즉, MN을 위한 터널이 LMA-MAG1에서 LMA-MAG2로 변경된다. 이와 같은 방법을 이용하면 MN의 이동과 관련된 부가적인 기능이 MN에 구현되어 있지 않더라도 네트워크에서 MN의 이동성을 제공할 수 있다. 네트워크 기반 이동성 관리 기법은 LMA와 MAG 간 터널을 이용한 데이터 전송 방식은 동일하지만, MN의 정보를 어떻게 관리할 것인가, 그리고 터널을 어떻게 설정할 것인가에 따라 여러 가지 프로토콜들이 제안되었다.

<그림 1> 네트워크-기반 이동성 관리 기법에서 고려되는 망 구조

네트워크 기반 이동성 관리 관련 표준화 동향

IETF의 netlmm WG에서는 네트워크 기반 이동성 관리를 위한 목표와 문제점을 정의한 문서를 작성하였고, 이동성 관리 관련 프로토콜을 제정하기 위하여 디자인 팀을 구성하여 netlmm이라는 제목의 프로토콜을 제안하였다. 그러나 WiMAX와 3GPP2와 같은 표준화 단체에서 PMIPv6(Proxy MIPv6)라는 또 다른 프로토콜을 지지한다는 발표를 해서, netlmm WG을 위한 표준 문서를 위한 기본 도큐먼트로서 어떤 프로토콜을 채택할 것인가에 대한 많은 논의가 있었다. 특히 2006년 11월에 있었던 IETF 67차 회의에서는 네트워크 기반 이동성 관리를 위한 기본 프로토콜로서 디자인 팀에서 제안한 netlmm 프로토콜, DHCP 기반의 프로토콜, 그리고 PMIPv6 프로토콜에 대한 발표와 투표가 있었다. 투표의 결과 PMIPv6는 45명의 지지를, 디자인 팀에서 제안한 프로토콜은 30명의 지지를, 그리고 DHCP 기반의 프로토콜은 3명의 지지를 받았다. 이 투표의 결과로 DHCP 기반 프로토콜은 더 이상의 논의를 하지 않기로 하고, PMIPv6 프로토콜과 디자인 팀의 프로토콜은 지지표의 차이가 많지 않으므로 무엇을 기본 문서로 할 것인가는 메일링 리스트를 통하여 논의를 계속하기로 하였다. 메일링 리스트를 통한 논의 후에 2007년 1월 중순에 netlmm WG의 의장단은 네트워크-기반 이동성 관리를 위한 정식 문서 작성은 PMIPv6 프로토콜을 기반으로 할 것이라는 것을 공표하였다. PMIPv6 프로토콜은 다시 S. Gundavelli 등이 제안한 방법과 A. Singh 등이 제안한 방법의 두 가지 메커니즘이 제안되어서, 2007년 3월 18일부터 23일까지 체코 프라하에서 개최된 IETF 68차 회의에서는 두 가지 메커니즘에 대한 동작과 특징 등에 대한 발표가 있었다.

Proxy MIPv6 프로토콜

S. Gundavelli 등이 제안한 PMIPv6 프로토콜의 동작은 다음과 같다. MN이 켜지거나 또는 PMIPv6 망에 들어오는 경우에 MAG1은 액세스 망에 있는 정책 저장소(Policy store)로부터 MN이 접속하고자 하는 LMA의 주소와 MN의 ID 정보, 그리고 부가적으로 MN에게 할당될 네트워크 프리픽스 등의 정보를 얻는다. 서버로부터 수신한 정보를 이용하여 MAG1은 라우터 광고 메시지를 MN에게 전송하고, MN은 이 정보를 이용하여 자신의 IP 주소를 설정한다. MAG1은 또한 서버로부터 수신한 정보를 이용하여 PBU(Proxy Binding Update) 메시지를 만들어 LMA에게로 전송한다. 이 메시지에는 MN의 ID, MN에게 할당된 네트워크 프리픽스, 그리고 MN의 IP 주소가 포함된다. PBU 메시지를 수신한 LMA는 자신의 바인딩 캐쉬 엔트리에 MN ID에 해당하는 정보가 있는지를 검사하여 만일 없으면 MN에 대한 정보를 추가한다. 그리고 LMA는 MAG1의 주소 정보를 이용하여 LMA와 MAG1 간에 터널을 설정한다. 만일 MN이 이동을 하게 되면, 앞에서 언급한 것과 동일한 방법으로 MAG2는 MN에 대한 정보를 얻게 되고, 이 정보를 이용하여 MN에게 동일한 네트워크 프리픽스 정보를 광고한다. MN이 동일한 네트워크 프리픽스 정보를 수신하게 되면, MN은 자신이 이전과 동일한 네트워크에 계속 접속되어 있다고 간주하게 된다. MAG2는 서버로부터 수신한 MN에 대한 정보를 이용하여 PBU 메시지를 만들어 LMA에게로 전송한다. PBU 메시지를 수신한 LMA는 MN의 ID 정보와 MAG2의 주소 정보를 이용하여 MN이 새로운 망으로 이동했다는 것을 감지하고 MN을 위한 터널을 기존의 LMA-MAG1에서 LMA-MAG2로 변경한다. 이와 같은 방법으로 네트워크 기반 이동성 관리 기능을 MN에게 제공한다.

A. Singh 등이 제안한 PMIPv6 프로토콜의 동작은 다음과 같다. MN이 MAG1에 접속하면, MAG1은 MN에게 라우터 광고 메시지를 전송한다. MN은 수신한 라우터 광고 메시지에 있는 정보를 이용하여 pHoA(Proxy Home Address)를 설정한다. MAG1은 액세스 네트워크 상에 있는 PMIP 클라이언트에게 트리거 메시지를 전송한다. 이 트리거 메시지는 MN의 ID와 pHoA 정보가 포함되어 있다. MAG1으로부터 트리거 메시지를 수신한 PMIP 클라이언트는 MN의 pHoA와 MAG1의 IP 주소, 그리고 MN의 ID를 포함하는 PBU(proxy binding update) 메시지를 만들어 LMA에게로 전송한다. PBU 메시지를 수신한 LMA는 MN의 pHoA를 목적지 주소로 하는 모든 패킷을 MAG1으로 전송하기 위하여 MAG1과의 터널을 설정하고, PMIP클라이언트에게 PBAck(Proxy Binding Acknowledgement) 메시지를 전송한다. PBack 메시지를 수신한 PMIP 클라이언트는 PBack verification status 메시지를 MAG1에게로 전송한다. 이 메시지를 수신한 MAG1은 LMA와의 터널을 설정한다. 만일 MN이 MAG1에서MAG2로 이동을 하게 되면, MAG2는 MN ID, pHoA, 그리고 MN에 대한 정보를 포함하고 있는 PMIP 클라이언트 등에 대한 정보를 MAG1으로부터 수신하고, 트리거 메시지를 PMIP 클라이언트에게 전송한다. PMIP 클라이언트는 이 메시지를 이용하여 MN의 ID와 MAG2의 IP 주소에 대한 바인딩 정보를 포함하는 PBU 메시지를 LMA에게로 전송한다. 이 메시지를 수신한 LMA는 MN의 pHoA에 대한 바인딩 정보를 기존의 MAG1 주소에서 MAG2의 IP 주소로 업데이트하고, MAG2와의 터널을 설정한 후에 PBack 메시지를 PMIP 클라이언트에게로 전송한다. PBack 메시지를 수신한 PMIP 클라이언트는 PBack verification status 메시지를 MAG2에 전송하며, 이 메시지를 수신한 MAG2는 MN을 위한 LMA 간 터널을 설정한다.

두 가지 PMIPv6 프로토콜의 비교 및 전망

S. Gundavelli 등이 제안한 PMIPv6 프로토콜은 MN에 대한 정보를 포함하고 있는 정책 저장소를 정의하고 있고, 액세스 네트워크에 있는 MAG는 이 저장소에 접속하여 MN에 대한 정보를 수신한다. 따라서 이 메커니즘은 WiMAX나 3GPP와 같은 노드에 대한 관리 기능이 있는 네트워크에 적합하다고 할 수 있다. 반면 MN에 대한 바인딩 정보를 각각의 MAG에서 전송하기 때문에 만일 MN이 이동을 하였을 경우에, 새로운 MAG에서 전송되는 바인딩 정보가 이전의 MAG에서 전송되는 바인딩 정보보다 먼저 LMA에 도착하는 경우에는 LMA에 잘못된 정보가 저장될 수 있다. 반면 A. Singh 등이 제안한 프로토콜에서는 LMA와 PMIP 클라이언트간에 바인딩 관련 정보가 교환되기 때문에 바인딩 관련 패킷의 순서 어긋남으로 인한 문제가 발생하지 않는다. 반면 이 방식에서는 PMIP 클라이언트에 고장이 발생하게 되면, MN이 네트워크로부터 이동성 관리 지원을 받지 못하는 문제가 발생한다. 또한 이 방법에서는 MN이 MAG1에서 MAG2로 이동을 하는 경우에 MAG2가 어떻게 MAG1으로부터 MN에 대한 정보를 수신할 수 있는지에 대한 방식이 정의되어 있지 않다.

앞에서 언급한 두 가지의 PMIPv6 프로토콜과 관련하여 WiMAX와 3GPP와 같은 표준화 단체에서는 2007년 3분기까지 표준 문서를 위한 기본 프로토콜이 결정되기를 희망하였다. Netlmm WG에서는 메일링 리스트를 통하여 두 가지 프로토콜의 특성에 대해서 논의한 끝에 2007년 4월에 S. Gundavelli 등이 제안한 프로토콜을 netlmm을 위한 기본 프로토콜로 결정하였다. 이를 기반으로 향후에는 IPv4 지원 방법, PMIPv6와 MIPv6와의 연동 방안 및 고속 핸드오버 제공 등에 대한 표준화가 진행될 전망이다.