PMIPv6 Description

Proxy MIPv6 is built from MIPv6 to provide mobility support for MNs – without requiring their participation in mobility management and IP signalling. It provides mobility support to all the MNs, irrespective of whether the mobile node implements MIPv6 functionality, or not. The protocol introduces network functional elements, namely: Local Mobility Anchor (LMA) and Mobile Access Gateways (MAGs) [17], which handle the mobility of the MN. The LMA is an HA in the PMIPv6 domain; and it runs on a domain gateway – whereas the MAG is the logical function running in the access router of the MN.

The MAGs are responsible for tracking the MNs movements, (i.e., their attachment and detachment events) on the access link, and for performing the signalling operation on their behalf.

In PMIPv6, the LMA assigns a unique HNP to each MN, which registers in the PMIPv6 domain. The MN uses the assigned HNP to configure an IP address, (an HoA), which remains the same, while it roams within the domain [42], because the MN continues receiving the router advertisement (RA) from MAGs containing the same HNP. So, the MN does not need to configure a new IP address when it roams in a PMIPv6 domain. This reduces the time needed to perform IP configuration, and hence reduces the handover delay. The HoA is used by an MN in all of its communications – as the session identifier.

When the MN moves from the initially attached link to a new link, the MAG located in the new link authenticates the MN through an Authentication, Authorization and Accounting (AAA) server. Next, the MAG registers the MN to the LMA on its behalf – by sending the proxy

binding update (PBU) message. Hence, the MNs are not involved in mobility management operations. The binding update message informs the LMA about the current location to which the MN is attached. Such information helps the LMA to generate or update the binding entry for the MN in the binding cache. The binding cache entry associates the MN with the current serving MAG information that enables it to reach a particular MN.

The LMA then replies to MAG with a proxy binding acknowledgement (PBA) message, implying successful update or creation of the MN‟s binding entry, which also includes the HNP initially assigned to the MN. Thereafter, the LMA and the MAG establish a bidirectional tunnel, and update the routing entry to allow the MN to use the address configured from the HNP. Moreover, the MAG, upon receiving the PBA message, sends a router advisement message to MN containing the same HNP previously assigned to MN; that is, the MAG emulates the home network of the MN at the access link [43]. This makes the MN unaware of its movement, because it cannot detect any IP layer change.

Figure 2-2 illustrates the basic protocol operation of the PMIPv6.

HoA1 -> MAG1 HoA1->MAG2 MN MN HoA1 HoA1 movement MAG1 MAG2 location bindi ng update signaling

LMA’s binding cache LMA CN1 IPv6-in-IPv 6 tunnel PMIPv6 domain Internet CN3 MAG3 Signaling messages MN communication with CN1 MN communication with CN3

Figure 2-2 Mobility management in PMIPv6: an overview

As shown in Figure 2-2, the MN initially attaches to MAG1; and it establishes a communication with the correspondent nodes, CN1 and CN3; and it then undergoes handover to MAG2. As the MN attaches to the MAG2 network, MAG2 detects the attachment of the MN.

Then, it exchanges the proxy registration signalling, PBU and PBA messages, with the LMA to register the current location of the MN, MAG2 IP address called proxy CoA. Thereafter, the LMA updates the MN‟s location in the binding caches with a new entry pointing to MAG2; and a bidirectional tunnel is established between LMA and MAG2. Now, all the MN‟s traffic is received by the LMA, which uses the binding cache to locate MAG2 (which is currently serving the MN); and it then encapsulates packets with the MAG2 IP address as the destination address over the tunnel between LMA and MAG2.

Upon receiving the packets, MAG2 then strips off the additional IP header, created by encapsulation, from the received packets, and forwards them to the MN. The packets coming from the MN to the CN1 are tunnelled – by serving MAG, MAG2, in a bidirectional tunnel towards LMA. LMA then decapsulates and forwards them to CN1, the final destination. Similarly, the packets sent by the MN to the CN3 are encapsulated by MAG2, and decapsulated by LMA, which then encapsulates them to MAG3. MAG3 then delivers the packets to CN, after decapsulation.

Although PMIPv6 solves the host-based mobility issues of MIPv6, the MN‟s HoA is topologically anchored at the LMA. Consequently, all communication of the MN traverses the LMA, irrespective of the point of attachment of the MN and the CN(s), as shown in Figure 2-2. The routing path through the LMA may not be optimal [44], which can increase the communication delay. For example, both MN and CN may be located at the same MAG, or located to MAGs that are closer to each other in the same PMIPv6 domain; yet, the packets traverse the LMA. Furthermore, the binding states for all registered MNs are stored in LMA; and all the MAGs forward the MN‟s packets to LMA, which makes the LMA a single point of failure ; while to scale up (as the number of MNs and the data traffic volume grow) is difficult.

In principle, the LMA is a centralized anchor point in the PMIPv6 domain, in that the mobility management approach used in PMIPv6 is centralized in both control and data planes [12].

In order to overcome the limitations of PMIPv6 in terms of inefficient routing, various enhancement efforts are happening in the Network-Based Mobility Extensions working group [45] in IETF; and these efforts are briefly introduced in the following sub-section. There have also been recent efforts in the IETF aimed at addressing the centralized mobility management

issues in IP mobility management – instead of looking only at the inefficiency in routing. A new working group, called distributed mobility management (DMM) [21], has been formed to enhance the centralized IP mobility management with a distributed mobility management approach, whereby PMIPv6 is also included. The detail of DMM approach is discussed in Section 2.4.