Mobile IP (MIP), which is described in IETF RFC 3344, allows users of mobile communications devices to move from one network to another whilst maintaining a permanent IP address, regardless of which network they are in. This allows the user to maintain connections whilst on the move. For example, if a user were participating in a Voice Over IP (VoIP) session and, during the session the user moved from one network to another, without MIP support the user's IP address may change This would lead to problems with the VoIP session.
A Mobile Node (MN) is allocated two IP addresses: a permanent home address and a care-of address (CoA). The CoA is associated with a node in the network that the user is currently visiting. To communicate with the MN, packets are sent to the MN home address. These packets are intercepted by a Home Agent in the home network, which has knowledge of the current CoA. The Home Agent then tunnels the packets to the CoA of the MN with a new IP header, whilst preserving the original IP header. When the packets are received by the MN, it removes the new IP header and obtains the original IP header. The MN sends packets directly to another node via a foreign agent in the visited network. The foreign agent maintains information about visiting MNs, including the CoA of each visiting MN.
Proxy Mobile IP v6 (PMIPv6), IETF draft-sgundave-mip6-proxymip6-01, describes a Proxy Mobile Agent (PMA) function. This function emulates home link properties in order to make a MN behave as though it is on its home network and allows support for mobility on networks that would not otherwise support MIPv6.
A PMA is usually implemented at the access router. The PMA sends and receives mobility related signalling on behalf of a MN. When a MN connects to an access router having a PMA, the MN presents its identity in the form of a Network Access Identifier (NM) as part of an access authentication procedure. Once the MN has been authenticated, the PMA obtains the user's profile from a policy store. The PMA, having knowledge of the user profile and the NAI, can now emulate the MN's home network. The MN subsequently obtains its home address from the PMA. The PMA also informs the MN's Home Agent of the current location of the MN using a Binding Update message. The Binding Update message uses the NAI of the MN. Upon receipt of the Binding Update message, the Home Agent sets up a tunnel to the PMA and sends a binding acknowledgement to the PMA. On receipt of the Binding Acknowledgement, the PMA sets up a tunnel to the Home Agent. All traffic from the MN is routed to the Home Agent via the tunnel.
The Home Agent receives any packet that is sent to the MN, and forwards the received packet to the PMA through the tunnel. On receipt of the packet, the PMA removes the tunnel header and sends the packet to the MN. The PMA acts as a default router on the access link. Any packets sent from the MN are sent via the PMA to the Home Agent, which then sends the packet on to its ultimate destination.
Mobility Support in IPv6 (IETF RFC 3775 June 2004) describes route optimization initiated by the MN for messages sent from and to the MN. However, the Proxy MIPv6 specification, which is a variant of MIPv6, doesn't assume any mobility management protocol in the MN. The techniques for route optimization specified in MIPv6 cannot be applied to PMIPv6 without modification.
As PMIPv6 does not assume mobility management protocol in the MN, the PMA processes the signals defined in MIPv6 on behalf of the MN. The PMA is therefore well placed to process route optimization signalling on behalf of the MN, although to date there has been no suggestion or description of how the PMA should perform route optimization. A trivial solution would be to apply the principles of route optimization specified in MIPv6. As illustrated in FIG. 1, using this solution, the PMA (PMA1 in this case) sends a route optimization request (e.g., MIPv6 Binding Update) to a Corresponding Node (CN, a node with which the MN is communicating) containing the IPv6 address of PMA1 as the Care-of Address.
As illustrated in FIG. 2, a problem arises with this solution when a user with a MN moves from one access network to another access network, and therefore no longer connects to the network via the old PMA (PMA1), but connects via a new PMA (PMA2). The route optimization was performed whilst the MN was connecting via PMA1. In MIPv6, the MN is aware of the handover and can request a new route optimization. However, where the MN is connected via a PMA the PMA emulates the MN's HA, and so the MN is unaware of the handover and so does not request a new route optimization after handover to PMA2. Downlink packets from the CN to the MN have a source address of CN and destination address of MN, and so are sent to PMA1. The MN is therefore unreachable by the CN.
Using MIPv6, the MN is aware of the handover, and can initiate a new route optimization. Using PMIPv6, if the PMA is not aware of the handover of the MN, then the PMA cannot initiate a new route optimization. Provided the MN moves within the PMIPv6 domain, the MN's IP address remains unchanged, and so even if the MN is a MIPv6 client, the MN will not send a signal for a new request of route optimization or for cancellation of the current route optimization to the CN.
Another problem with handover of the MN from PMA1 to PMA2 is packet loss. Packet loss during a handover is a problem for all mobile protocols, and sending packets over an optimized route increases the risk of packet loss because the anchor point (the HA) does not have control of the optimized route taken by packets.
USPTO Backgrounds
USPTO Backgrounds