PMIPv6(Proxy Mobile IPv6) 프로토콜은 PMIPv6 도메인에 접속되어 있는 이동 노드(MN: Mobile node)가 하나의 네트워크에서 다른 네트워크로 이동을 하더라도 자신에게 설정된 IPv6 주소의 변경 없이 기존에 설정된 연결을 계속 유지할 수 있도록 네트워크에서 MN의 이동을 지원하는 네트워크-기반 이동성 관리 기법이며 인터넷 관련 표준 제정 기관인 IETF의 RFC 5213 표준문서로 정의되어 있다.

PMIPv6 프로토콜에서는 MN을 대신하여 MN의 이동성을 지원하기 위한 MAG(Mobile Access Gateway)가 정의된다. MAG는 MN이 접속되어 있는 액세스 망에서 기본 게이트웨이로 동작한다. 또한 PMIPv6 도메인 내에서 MN을 위한 일종의 HA(Home Agent)로 동작하는 LMA(Localized Mobility Anchor)가 정의된다. <그림 1>은 PMIPv6 프로토콜을 이용하여 네트워크에서 MN의 이동성을 지원하기 위한 기법을 보여준다. 여기에서 MN이 처음 PMIPv6 도메인에 들어와서 MAG(즉, MAG1)에 접속하면, MAG1은 MN-ID를 포함하는 PBU(Proxy Binding Update) 메시지를 LMA에게 전송한다. PBU 메시지를 수신한 LMA는 자신의 BCE(Binding Cache Entry)에 MN에 대한 정보가 있는 지를 확인한 후에 만일 없으면 MN-ID와 MN에게 할당할 프리픽스(HNP: Home Network Prefix) 정보, 그리고 MAG1의 주소인 Proxy-CoA1 주소를 포함하는 엔트리를 추가한 후에 MN에게 광고할 HNP를 포함하는 PBA(Proxy Binding Acknowledgement) 메시지를 MAG1에게 전송한다. 이 이후부터 LMA와 MAG1 간에는 MN을 위한 터널이 설정된다. PBA 메시지를 수신한 MAG1은 HNP를 포함하는 RA(Router Advertisement) 메시지를 MN에게 전송하며, MN은 HNP를 이용하여 자신의 인터페이스에 주소를 설정하고, 이 이후부터 MN은 인터넷 상의 임의의 노드와 통신할 수 있다.

그런데 PMIPv6 프로토콜에는 서로 다른 MN이 서로 다른 CN과 통신하기 위하여 LMA와 같은 하나의 중앙 집중 장치를 거쳐야 하기 때문에, 트래픽 집중으로 인한 성능 저하 및 혼잡 발생 가능성, LMA에 고장이 발생하는 경우에는 통신이 두절되는 single-node failure 문제, 그리고 MN과 CN이 서로 가까운 곳에 위치하고 있다 하더라도 서로간의 통신은 항상 LMA를 거치도록 함으로써 발생하는 비최적화된 경로로 인한 성능 저하 등의 문제를 가지고 있다. 이러한 문제를 해결하기 위하여 IETF dmm(distributed mobility management) 워킹 그룹이 결성되었으며, dmm 워킹 그룹에서는 PMIPv6와 MIPv6와 같은 중앙 집중형 프로토콜의 문제점과 이를 해결하기 위한 기법에 필요한 사항들, 분산 이동성 관리 환경에서 기존 프로토콜을 실제로 적용하는 경우에 dmm의 관점에서 발생하는 문제점과 제약점, 그리고 이러한 문제점과 제약점을 해결하기 위한 기존 프로토콜의 확장 등을 목표로 하고 있다.

<그림 1> PMIPv6 구조

2012년 3월 25일부터 3월 31일까지 프랑스 파리에서 개최된 IETF 83차 회의에서는 PMIPv6 환경에서 dmm을 제공하기 위한 확장 기법에 대한 논의가 있었다. <그림 2>는 PMIPv6 환경에서 dmm을 제공하기 위하여 LMA의 기능을 MAG로 분산하는 경우의 예를 보여주며, 이 경우는 완전 분산 이동성 지원 기법이라 할 수 있다. 여기에서 MN이 처음 PMIPv6 도메인에 들어와서 처음 접속하는 MAG가 MN의 LMA가 된다. 즉, 서로 다른 MN이 서로 다른 MAG에 접속하는 경우에는 해당 MAG가 MN의 LMA가 되기 때문에 LMA가 분산된다고 할 수 있다. 또한 MAG가 MN의 기본 게이트웨이가 되기 때문에 MN과 CN간에 전송되는 트래픽은 최적화된 경로를 따르게 되며, 만일 MAG에 고장이 발생하더라도 해당 MAG를 자신의 LMA로 설정한 MN들만 통신에 장애가 발생할 뿐 다른 MN들에게는 지속적으로 통신서비스가 제공될 수 있다는 장점이 있다. 그렇지만 MN이 이동하여 자신의 위치를 변경하는 경우에는 문제가 발생할 수 있다. 만일 MN이 이동하여 MAG1에서 MAG2로 자신의 위치를 변경하는 경우에는 MAG2는 MN이 처음 PMIPv6 도메인에 들어와서 자신과 처음 접속한 호스트인지를 판별하는 과정이 필요하고 또한 만일 MN이 이미 PMIPv6에 들어와서 다른 MAG(여기에서는 MAG1)를 자신의 LMA로 설정한 경우에는 MAG2는 MN의 LMA로 설정된 MAG1의 주소를 알아야 하는 과정이 필수적이라 할 수 있다. 이를 위한 방법으로 애니캐스트나 멀티캐스트를 이용하는 방법이 있을 수 있지만, 이 방식에서는 MN의 LMA를 찾기 위하여 PMIPv6 도메인에 과도한 제어 트래픽의 증가로 인한 혼잡이 발생할 가능성이 생긴다.

<그림 2> DMM을 위한 PMIPv6 구조 - 완전 분산 이동성 지원 기법

<그림 3>은 LMA의 기능을 분리하여 주소 관련 정보를 저장하고 검색해주는 CMD(Central Mobility Database)를 두는 부분 분산 이동성 지원 기법을 보여준다. 여기에서 CMD는 MN의 주소와 MN의 LMA에 대한 정보를 저장한다. MN이 처음 PMIPv6 도메인에 들어와서 MAG1에 접속하면, MAG1은 MN에게 할당할 하나의 HNP를 임시로 지정한 후에 MN-ID와 HNP를 포함하는 PBU 메시지를 CMD에게 전송한다. PBU 메시지를 수신한 CMD는 자신의 BCE에 MN에 대한 정보가 있는 지를 확인한 후에 만일 없으면 MN이 PMIPv6 도메인에 처음 접속하는 것이라 간주하고 BCE에 MN-ID와 HNP, 그리고 MAG1의 주소인 Proxy-CoA1 정보를 저장한 후에 MAG1에게 PBA 메시지를 전송한다. CMD로부터 전송된 PBA 메시지를 수신한 MAG1은 HNP를 포함하는 RA(Router Advertisement) 메시지를 MN에게 전송하며, 이 이후부터 MAG1은 MN의 기본 게이트웨이의 역할뿐만 아니라 MN을 위한 LMA의 기능도 수행한다. 만일 MN이 이동하여 MAG2와 접속하면, MAG2는 앞에서 언급한 절차를 이용하여 PBU 메시지를 CMD에게로 전송한다. MAG2로부터 전송된 PBU 메시지를 수신한 CMD는 자신의 BCE를 검색하여 이미 MN이 등록되어 있다는 것을 확인하고 MN에 대한 BCE를 갱신한 후에 PBU 메시지를 MAG1에게 전달한다. CMD를 통하여 MAG2로부터 전송된 PBU 메시지를 수신한 MAG1은 자신이 MN에 대한 LMA라는 것을 알려주기 위한 PBA 메시지를 CMD를 통하여 MAG2에게로 전송하고 이 이후부터 MAG1과 MAG2 사이에는 MN을 위한 터널이 설정되며 MN으로부터 전송되는 패킷은 MAG2와 MAG1을 거쳐 CN에게 전송되며, CN으로부터 전송되는 패킷은 MAG1과 MAG2를 거쳐 MN에게로 전송된다.

<그림 3> DMM을 위한 PMIPv6 구조 - 부분 분산 이동성 지원 기법

IETF 83차 회의에서는 PMIPv6 환경에서 dmm을 제공하기 위한 기법 외에도 dmm을 제공하기 위한 구조, 요구사항 및 제안 프로토콜, dmm을 제공하기 위한 주소 체계 등에 대해서 논의되었다. IETF 83차 회의에서 논의되었던 요구 사항에 대한 구체적인 항목이 이메일을 통하여 논의되고 있으며 2012년 7월 29일부터 8월 3일까지 캐나다 벤쿠버에서 개최되는 IETF 84차 회의에서 구조 및 요구사항에 대한 추가적인 논의가 이루어질 예정이다. 그렇지만 앞에서 언급한 완전 분산 이동성 지원 기법의 경우에는 확장성의 문제가, 부분 분산 이동성 지원 기법의 경우에는 CMD의 고장으로 인한 통신 두절 문제가 발생할 수 있으며 아직까지 dmm을 제공하기 위한 기법의 표준화는 초기 단계라 할 수 있다. 따라서 다양한 경우에서 발생할 수 있는 문제점을 고려하여 최적의 성능을 제공할 수 있는 프로토콜을 제안하고 표준화할 수 있는 방안이 모색되어야 할 것이다.