PMIPv6에서의 local routing

PMIPv6에서의 local routing
(Proxy Mobile IPv6)

1. 개요

PMIPv6는 2008년 8월에 RFC 5213에서 표준화가 완료된 이동성 프로토콜로써 MIPv6(mobile IPv6)와 같이 MN(mobile node)가 핸드오버와 관련된 시그널링 절차를 수행하지 않고 네트워크 기반으로 이동성을 관리할 수 있도록 설계된 프로토콜이다. PMIPv6는 구성요소로는 LMA(local mobility anchor)와 MAG(mobile access gateway)가 있다. LMA는 PMIPv6 도메인 내에서 이루어지는 모든 이동성 절차를 관리하여 일종의 HA(home agent)라 볼 수 있고, MAG는 LMA와 MN 사이에 위치하여 MN의 이동을 감지하고 LMA와 이동성 절차를 통해 MN가 사용할 prefix를 RA(router advertisement) 메시지를 통해 전달하는 역할을 한다. 행여 PMIPv6에 대해 익숙하지 않다면 [1]과 [3]을 참고하길 바란다.

기본적으로 PMIPv6에서 모든 메시지는 LMA를 통해 전달된다. 이러한 점은 그림 1과 같이 MN와 CN(correspondent node)가 같은 PMIPv6 도메인 내에 있을 때 반드시 LMA를 거쳐야함으로 인해 불필요한 지연시간을 발생시키는 삼각 라우팅 문제를 발생시킨다. 삼각 라우팅 문제는 [2]에서도 역시 존재하는데, [2]에서는 HA(home agent)를 거치지 않고 MN와 CN 간에 직접 터널링을 형성하여 전송 지연시간을 줄일 수 있는 route optimization 기법을 사용하게 된다. PMIPv6에서도 마찬가지로 MN와 CN이 하나의 PMIPv6 도메인 내에 있을 경우 LMA를 거치지 않고 MAG 간에 직접 터널링을 형성하여 지연시간을 줄일 수 있는 route optimization 혹은 local routing 기법이 있는 데 이에 대해 설명하도록 하겠다.

 

그림 1). PMIPv6에서의 삼각 라우팅

2. Local Routing

2.1. 개요

1 장에서도 설명했듯이 PMIPv6에서는 모든 메시지가 LMA를 거침으로 인해 MN와 CN이 같은 도메인에 있을 때 지연시간을 발생시킬 뿐만 아니라 도메인 내 트래픽이 많을 경우 LMA에서 트래픽 과부하를 발생시켜 도메인 전체에서 지연시간을 발생시킬 수 있다. 이러한 점을 보완하고자 route optimization 혹은 local routing 이라는 이름으로 여러 기법이 제시되고 있는 데, 그 중 LRI(local routing indication)과 LRA(local routing acknowledgement) 메시지를 사용하여 MAG 간에 터널링을 형성하는 방식에 대해 살펴보도록 한다.

그림 2는 local routing이 사용되는 시나리오를 나타낸 그림이다. MN와 CN이 하나의 PMIPv6 도메인 내에서 통신을 하면, LMA에서는 BCE(binding cache entry)를 보고 MN와 CN이 자신이 속한 같은 도메인 내에 있다는 것을 알게 된다. 따라서 LMA에서는 각 MAG1과 MAG2 사이에 터널링 형성될 수 있도록 local routing을 trigger하며 MAG1과 MAG2 사이에 터널링이 형성되면서 local routing을 하게 된다. 본 문서에서는 local routing이 적용된 상황에서 그림과 같이 MN가 LMA 내 또 다른 MAG3으로 핸드오버하게 될 때 메시지 절차와 시나리오에 대해 설명한다.

 

그림 2). Local routing 시나리오

2.2. 용어

2.2.1. LRI

LRI는 [4]에서 정의하고 있는 메시지로 local routing을 trigger하고자 할 때 LMA나 peer MAG에서 MAG으로 전송할 수 있다. 본 소절에서는 메시지의 기능만 소개하고 메시지 형식과 같은 자세한 사항은 뒤에 설명하도록 한다.

2.2.2. LRA

LRA 역시 [4]에서 정의하고 있는 메시지로 LRI 메시지에 대해 응답할 때 MAG가 LMA나 peer MAG에게 보내는 메시지이다.

2.3. 동작 절차

2.3.1. Local routing initialization

LMA가 MN와 CN 사이에 local routing이 필요하다고 인지하게 되면 LMA는 LRI 메시지를 각 MAG에게 전송하게 된다. 이 때 LRI 메시지에는 MN과 CN을 식별할 수 있는 정보와 상대방 노드의 MAG인 target MAG에 대한 정보를 제공하게 된다. 이외에도 MAG 간에 보안 절차(security association)나 터널링 설정과 관련된 정보를 포함시킬 수 있다. MAG에서 LMA가 보낸 LRI 메시지를 받으면 local routing을 하겠다는 응답으로 LRA 메시지를 LMA로 전송하게 되면서 MAG 간에 터널링이 형성된다. 이 시점에서 MAG와 LMA 간에 설정됐던 기존의 터널링은 현재 local routing 하고 있는 노드가 아닌 다른 노드와의 통신을 위해 해제하지 않는다. 그리고 LMA는 local routing 세션을 맺고 있는 MAG와 MN이 있다는 것을 기록하고 있어야 한다. 이에 대한 자세한 사항은 현재 표준화가 진행중이다. 그림 3은 지금까지 설명했던 것을 그림으로 나타낸 것이다.

 

그림 3). Local routing initialization

2.3.2. Handover

Local routing initialization이 적용된 상황에서 MN2가 MAG3으로 이동하게 될 때의 절차에 대해 살펴보겠다. 그림 4는 기존에 MAG1과 MAG2간에 local routing으로 설정된 상태에서 MN2가 MAG3로 핸드오버할 때의 local routing 적용 방안을 나타낸 것이다. MN2가 MAG3으로 핸드오버 하기 위한 결정을 내렸으면 L2 핸드오버 절차인 HO_Init 메시지를 MAG2에게 전달하여 MAG3로 핸드오버하게 될 것이라는 것을 알리게 된다. 그리고 MAG2에서는 MAG1과 MAG3간에 터널링을 형성하도록 하기 위해 LRI 메시지를 MAG1과 MAG3에 각각 전송하게 된다. 이를 수행하기 위해서는 각 MAG 사이에 SA(security association)를 필요로 하는데, 이는 LRI와 LRA 메시지를 교환하는 데 사용된다. 이후에 MAG1과 MAG3는 local routing 세션이 만들어지게 되고 MAG3가 LMA와 PBU/PBA 절차를 통해 터널링을 형성하게 되면 MN2는 다시 통신을 할 수 있게 된다.

여기서 MAG2와 MAG3 간에 일시적인 터널링 생성을 위해서 MAG2가 MAG3에게 LRI 메시지만 보내는 것도 가능하다. 그래서 핸드오버 동안에는 MAG1-MAG2-MAG3로 메시지가 전달이 되고, 핸드오버를 완료하고 local routing이 적용된 MAG1-MAG3로 메시지 전달이 가능하다.

 

그림 4). Handover 절차

2.4. 메시지 포맷

LRI와 LRA는 mobility header(MH)를 사용한다. Local routing type이 1로 설정되면 LRI 메시지를 말하고 2로 설정되면 LRA 메시지를 말한다. 다음은 local routing 메시지의 포맷을 나타낸 것이다. Local routing message data에는 LRI 및 LRA 메시지에서 정의한 포맷이 들어가게 된다.

 

그림 5). Local routing message

2.4.1. Local routing indication message

LRI 메시지는 local routing 메시지의 LR type이 1로 설정되며 메시지 포맷은 그림 6과 같고 각 필드에 대한 설명은 다음과 같다.

 

그림 6). Local routing indication message

• Acknowledge bit(A)

LMA나 target MAG으로부터 LRA 메시지를 요청하기 위해서는 1로 설정이 되어 있어야 한다.

• Reserved

예약을 위한 필드로 0으로 설정되어 있다.

• Sequence #

16비트 필드로서 LMA나 MAG가 LRI 메시지나 LRA 메시지가 제대로 도착했는지 확인할 때 이용될 수 있는 필드이다. 예를 들어 pMAG에서 보낸 LRI 메시지의 sequence 번호가 10번이였으면, 이에 대해 nMAG에서 보내는 LRA 메시지의 sequence 번호 역시 10번이어야 한다. 이를 통해 pMAG에서는 LRI 메시지에 대한 LRA가 제대로 도착했는지 확인할 수 있게 된다.

• Lifetime

16비트 필드로서 local routing session이 유지될 수 있는 시간을 말한다.

• Mobility option

유동적인 비트의 필드로서 최소한 source MN's address, destination MN's address, target MAG address를 제공할 수 있는 mobility option을 포함해야 한다. 이외에도 security나 tunneling mode operation과 같은 option 또한 포함될 수 있다.

2.4.2. Local routing acknowledgement message

Target MAG에서 보내지며 LRI 메시지에 대한 응답인 LRA 메시지는 local routing 메시지의 LR type이 2로 설정되며 그림 7은 메시지 포맷을 나타낸 것이고 각 필드에 대한 설명은 다음과 같다.

 

그림 7). Local routing acknowledgement message

• Reserved

예약을 위한 필드로 0으로 설정되어 있다.

• Sequence #

16비트 필드로서 LRI 메시지에서 사용된 sequence 번호와 같아야 한다.

• Lifetime

16비트 필드로서 local routing session이 유지될 수 있는 시간을 말한다.

• Mobility option

LRI 메시지에 포함된 option을 그대로 LRA 메시지에 복사해서 포함시켜야 한다.

2.5. Security consideration

LMA와 MAG 간 메시지인 PBU(proxy binding update)와 PBA(proxy binding acknowledgement)는 security association을 이용해 교환된다. 만약 inter-MAG 간 메시지가 교환된다면 임의의 노드가 local routing session에 악영향을 줄 수 있기 때문에 반드시 security association 과정을 MAG 간에 거쳐야한다. Local routing에 관련된 표준화 드래프트 문서는 많이 나오고 있지만, local routing에서의 security와 관련된 표준화는 아직 진행되고 있지 않은 실정이기에 이에 대한 많은 연구가 필요할 것으로 보인다.