| TOC |
|
This draft proposes a distributed local mobility anchors architecture. It separates the full functions of a local mobility anchor into different logical functions: (1) allocation of home network prefixes or home addresses to mobile nodes, (2) location management (LM) which includes managing the IP addresses and locations of the mobile nodes and (3) mobility routing (MR) which includes intercepting and forwarding packets. The distributed local mobility anchors architecture provides visited local mobility anchors in different networks with mobility routing function to avoid triangle routing problem in Proxy mobile IP or Mobile IP, but keeps the internetwork location management function at the home local mobility anchors at registered networks. The needed location information of a mobile node is acquired only when a packet is first sent to the mobile node and are then cached at the visited local mobility anchor to enable subsequent optimized mobility routing.
This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 4, 2010.
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
1.
Introduction
2.
Motivation
2.1.
Splitting the logical functions of a local mobility anchor
2.2.
Originating local mobility anchor and destination local mobility anchor
2.3.
Home local mobility anchor versus visited local mobility anchor
3.
Terminology
4.
Overall mechanism
4.1.
Registration
4.2.
Anycast
4.3.
Visited Network
4.4.
Mobility routing
5.
Packet flow
5.1.
Sending packets to mobile node
5.2.
Changing MAG without changing V-LMA
5.3.
Changing LMA
5.4.
Sending packets from mobile node
6.
Performance
6.1.
Round trip time
6.2.
Call setup delay
6.3.
Location update signaling overhead
6.4.
Double move problem
7.
IANA Considerations
8.
Security Considerations
9.
Acknowledgments
10.
References
10.1.
Normative References
10.2.
Informative References
§
Authors' Addresses
| TOC |
Proxy mobile IP [RFC5213] as well as mobile IP [RFC3775] support mobility by using a home address for session and a care-of address for routing but has the problem of triangle routing when the home agent is far from a mobile node and the correspondent.
Unneccessarily long routes may be avoided by having multiple home agents in different geographic locations [GHAHA]. These home agents announce the same IP prefixes using anycast. The traffic originating from the mobile node will then be served by the nearest home agent, and the traffic sent from a correspondent node to the mobile node will be intercepted by the home agent nearest to the correspondent node. Therefore both traffic will use the home agent nearest to where the traffic originates, so that triangle routing is avoided. These home agents may possess identical information about the mobile nodes [MHA]. Yet the synchronization of all the home agents will then be a challenge [SMGI]. In addition, the design needs to scale in deployment, but in synchronizing the home agents the amount of signaling traffic needed may increase with both the number of home agents and the number of mobile nodes.
This draft proposes to decouple the logical functions of a local mobility anchor into that of home address allocation, location management, and mobility routing. The mobility routing function may be present in many geographical locations. However, the home address allocation function and the internetwork location management function may be kept only at the network the mobile node is registered to, and the individual location management information for a specific mobile node may be acquired when needed. Home local mobility anchor and visited local mobility anchor to a mobile node are then defined in terms of these logical mobility functions, each of which may be implemented in one or multiple instances. These two mobility logical functions do not need to physically co-locate leaving flexibility for the implementation to place each in their most appropriate locations.
The concept of proxy home agent and primary home agent has been introduced in [GHAHA], where a proxy home agent closest to a mobile node away from its home agent may perform binding update with the primary home agent on behalf of the mobile node, and also intercept and tunnel messages for the mobile node. This draft also extends this work, applies distributed local mobility anchors to proxy mobile IP, and describes mobility routing and its expected performance.
This draft is written using the definitions of Proxy mobile IP, but the proposal works equally well for mobile IP.
| TOC |
| TOC |
A local mobility anchor, being a home agent, needs to perform the following logical functions: (1) home network prefix or home address allocation function: allocating home network prefix or home address HoA to a mobile node that registers with the network; (2) internetwork location management (LM) function: managing and keeping track of the internetwork location of the mobile node, which include a mapping of the HoA to the mobility anchoring point that the mobile node is anchoring to; and (3) mobility routing (MR) function: intercepting packets to/from the home address of a mobile node and forwarding the packets, based on the internetwork location information, either to the destination or to some other network element that knows how to forward to the destination.
When these logical functions are all bundled into one single entity known as the local mobility anchor LMA, having LMA in only one network results in triangle routing problem as shown in Figure 1.
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
( ) ( LMA ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
v v v v v v v v v v v v v v v v v v
MN CN
Figure 1. Configuration showing the triangle trouting problem with MN and CN in networks which may be close to each other but are far from the local mobility anchor (LMA).
The other extreme is to duplicate the LMAs in many networks (Figure 2) to solve triangle routing problem. Yet the location management information will need to be pushed to all these LMAs.
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
( LMA ) ( LMA ) ( LMA ) ( LMA ) ( LMA ) ( LMA ) ( LMA ) ( LMA ) ( LMA )
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
v v v v v v v v v v v v v v v v v v
MN CN
Figure 2. Configuration showing the replication of LMAs in multiple networks.
This draft proposes to decouple the logical functions of the local mobility anchor. These logical functions do not need to physically co-locate so that each may be located in its most appropriate places. One may then examine which functions should be present in many geographic locations and which functions do not.
As illustrated in Figure 3, having mobility routing (MR) function available in multiple geographic locations will solve triangle routing problem. It is also evident that the home network, which accepts the registration of the mobile node, is responsible for the HoA allocation. This network may therefore also manage the internetwork location information. Yet it appears that pushing the location management (LM) information to the home agents in all networks may be an overkill, and the mobile node does not always actually communicate with CNs from all the other networks. For example, a distributed database may employ different servers to manage different data. The data in each server is not pushed to all the other servers but the database system only needs to know which data resides in which server. Here, keeping the location management function with the individual registered networks only will avoid the need to synchronize the location management information in a timely and scalable manner.
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
( ) ( LM ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
( MR ) ( MR ) ( MR ) ( MR ) ( MR ) ( MR ) ( MR ) ( MR ) ( MR )
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
v v v v v v v v v v v v v v v v v v
MN CN
Figure 3. Configuration showing mobility routing (MR) function available in many networks, whereas the dynamic internetwork location management (LM) function resides in one network only.
| TOC |
The LMA to which MN is anchored to is the destination LMA (D-LMA) (Figure 4). It is capable of delivering incoming packets to the MN.
When a CN sends a packet to MN, the LMA closest to CN needs to intercept the packet to avoid triangle routing. This LMA is the originating LMA (O-LMA) that needs to provide mobility routing function for this packet so that the packet may be routed through the internetworks to reach D-LMA.
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
( ) ( LM ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
( MR ) ( MR ) ( MR ) ( MR ) ( MR ) ( MR ) ( MR ) ( MR ) ( MR )
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
v v v v v v v v v v v v v v v v v v
| |
D-LMA O-LMA
| |
| |
MN CN
Figure 4. Configuration showing O-LMA and D-LMA for a packet sent from CN to MN.
| TOC |
This draft defines home local mobility anchor and visited local mobility anchor as logical functions.
The home local mobility anchor (H-LMA) of a mobile node are the logical mobility functions of home-address allocation, location management, and mobility routing, which are provided by the network to which the mobile node is registered. The visited local mobility anchor (V-LMA) is the logical mobility function provided by a visited network. We use the term visited local mobility anchor irrespective of whether the mobile node actually visits that network or not. To the mobile node, V-LMA provides mobility routing function only.
Although H-LMA performs all the logical mobility functions for a mobile node registered to that network, these logical functions are considered separate and do not need to co-locate. Therefore the local mobility anchor does not need to be one single physical entity. It is possible to have one or multiple physical entities to provide location management function and one or multiple physical entities to provide mobility routing function, and these different entities do not need to be in one-to-one relationship.
To perform HoA allocation, each H-LMA may use its own block of IP prefixes to allocate IP addresses to the MNs registering to its network. The IP prefixes of all the H-LMAs form a super set of IP prefixes. All the H-LMAs and V-LMAs advertize this same super set of IP prefixes using anycast, so that no matther where a mobile node is located, the anycast and the routing algorithm will enable the nearest LMA to serve the mobile node.
To perform dynamic internetwork location management function, H-LMA must know which V-LMA the MN is anhoring to if MN is in a visited network. The H-LMAs in different networks provide a distributed database of such records for all the MNs anchored to these networks.
The LMA to which MN is anchored delivers incoming packets to MN; it is the D-LMA for incoming packets. When MN is in its registered network, it is anchored to H-LMA using an HoA address belonging to the H-LMA. When MN is in a visited network, it is anchored in that network to the V-LMA which is closest to the MN, and MAG does the MIP signaling on behalf of MN.
No matter where a correspondent node is located, any packet sent from CN to HoA is intercepted by the nearest LMA, which is the O-LMA. O-LMA will need to obtain the location information of MN from H-LMA so that it may route the packet to D-LMA. Yet because the HoA of MN belongs to the IP prefix of its registered network, the mapping of HoA to H-LMA does not change often and can therefore be known to all V-LMA. The mobility routing function in V-LMA, before route optimization, is therefore simply to forward a packet from CN to the H-LMA of MN, and H-LMA has the dynamic location information about MN to complete the mobility routing. After route optimization, the packet will need to be forwarded directly from O-LMA to D-LMA.
| TOC |
All the general mobility-related terms and their acronymns used in this document are to be interpreted as defined in the Mobile IPv6 base specification [RFC3775] and in the Proxy mobile IPv6 specification [RFC5213]. These terms include mobile node (MN), correspondent node (CN), home agent (HA), local mobility anchor (LMA), and mobile access gateway (MAG).
In addition, this draft introduces the following terms.
- Mobility routing
- (MR) is the logical function to intercept and forward packets to/from a mobile node.
- Home address allocation
- is the logical function to allocate home address to a mobile node.
- Location management
- (LM) is the logical function to manage the location of a mobile node, which is in terms of the mapping between the HoA and the internetwork location infromation of the mobile node. There are two different mappings to the internetwork location for a mobile node. The mapping to the H-LMA to which the mobile node is registered is usually a static information. The mapping to the local mobility anchor which is serving the mobile node will change when the mobile node changes it mobility anchoring point; H-LMA needs to know about this mapping.
- Home local mobility anchor
- (H-LMA) to a mobile node is the full set of logical functions of a local mobility anchor to the mobile node. It allocates home address (HoA) to the mobile node, manages the location of the mobile node, intercepts messages to/from the mobile node, and forwards these messages. Each mobile node is registed in its home network to a H-LMA, which can download from a home AAA server the profile of the mobile node. If the mobile node is anchored to a visited local mobility anchor (V-LMA), the H-LMA will manage the mapping between HoA and the V-LMA that the mobile node is currently anchoring to. The different logical functions do not need to co-locate, and each of these logical functions may be implemented in one or multiple instances.
- Visited local mobility anchor
- (V-LMA) to a mobile node is a subset of the full logical functions of a local mobility anchor towards the mobile node. It intercepts messages to/from the mobile and forwards messages using the location management information it will acquire from the home local mobility anchor of the mobile node. If the mobile node is anchored to the V-LMA, the V-LMA will inform the H-LMA of the mobile node and may manage the mapping between HoA and proxy-CoA of the mobile node.
- Originating local mobility anchor
- (O-LMA) is the first local mobility anchor that intercepts a message destined to a mobile node.
- Destination local mobility anchor
- (D-LMA) of a mobile node is the local mobility anchor to which the mobile node is currently anchored to. It knows where to deliver packets to reach the mobile node.
| TOC |
The architecture of distributed LMA is shown in Figure 5.
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( )
( Registered) ( Visited ) ( Visited )
( Network ) ( Network-1 ) ( Network-2 )
( ) ( ) ( )
v v v v v v v v v v v v v v v
| | |
H-LMA V-LMA-1 V-LMA-2
| |
| |
| |
| |
MAG |
| |
| |
MN CN
Figure 5. Configuration with MN registered to H-LMA in the registered network, anchored to the V-LMA (V-LMA-1) in visited network-1, and communicating with CN served by the V-LMA (V-LMA-2) in visited network-2.
| TOC |
A mobile node MN will register with a H-LMA in its home network.
The H-LMA can download from a home AAA server the profile of MN.
The H-LMA allocates to the MN a home address HoA belonging to a block of prefixes managed by the H-LMA.
The H-LMA performs mobility routing function for the MN within this registered network.
The H-LMA also performs location management for the MN. If MN has moved to another network and anchored to a V-LMA of the visited network, the V-LMA needs to inform H-LMN so that H-LMN knows which V-LMA the MN is anchoring to.
| TOC |
An example of using anycast for HoA prefixes is shown in Figure 6.
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( )
( LMA of ) ( LMA of ) ( LMA of )
( Network-1 ) ( Network-2 ) ( Network-3 )
( allocates HoA ) ( allocates HoA ) ( allocates HoA )
( with Prefixes ) ( with Prefixes ) ( with Prefixes )
( P1A,P1B ) ( P2A,P2B ) ( P3A,P3C )
( ) ( ) ( )
v v v v v v v v v v v v v v v v v v v v v v v v
/|\ /|\ /|\
/ | \ / | \ / | \
/ | \ / | \ / | \
PA,PB,P3C PA,PB,P3C PA,PB,P3C
Figure 6. Example of Anycast of HoA Prefixes. The LMA in each network broadcasts the superset of prefixes PA, PB, P3C. Here PA is the aggregate of P1A, P2A, and P3A; PB is the aggregate of P1B and P2B
Each LMA in its network owns a set of IP prefixes which it uses to allocate home network prefixes or HoAs to the MNs registered to that network.
The HoA prefixes of all the LMAs form a superset of HoA prefixes. Some prefixes in this superset may be aggregatable, but it is also possible that some may not be aggregatable.
Each LMA advertises the superset of HoA prefixes. An IP packet sent to any HoA will therefore be intercepted by the LMA nearest to the sender.
| TOC |
An MN that has registered with a H-LMA may move to a network other than the home network.
As MN leaves its registered network and enters a visited network, it still receives the prefix advertisement of its HoA from the LMA that uses anycast to advertise the superset of HoA prefixes in the visited network.
A MAG sends binding update to LMA on behalf of MN using the HoA of the MN and its proxy CoA.
To ensure robustness, the LMA looks up which H-LMA the MN has registered to, based on the HoA prefix of the MN. It checks with that H-LMA for uniqueness of that HoA address to complete the binding update. If H-LMA has determined that the HoA is not unique, V-LMA will need to send a registration request to H-LMA to obtain a valid HoA for MN.
This visited LMA (V-LMA) in this visited network has become the new mobility anchoring point of MN.
V-LMA peforms mobility routing function for MN.
V-LMA informs H-LMA that it is the current mobility anchoring point for the MN.
After MN has anchored to a V-LMA (V-LMA-1) in a visited network, it may leave this visited network and move to another visited network. It will then anchor to another V-LMA (V-LMA-2). H-LMA must again be informed that MN is currently anchored to V-LMA-2.
In addition, V-LMA-1 is also informed that MN has anchored to V-LMA-2 so that, for a limited time, if V-LMA-1 receives packets destined to MN, V-LMA-1 may forward these packets to V-LMA-2 according to the forwarding mechanism to be described in the mobility routing section below.
| TOC |
When an originating LMA (O-LMA) has intercepted a packet with destination address HoA of an MN, it checks whether or not there is location information of this HoA in its cache.
If O-LMA has the cache memory of this HoA indicating that MN is currently anchored to the destination LMA (D-LMA), it tunnels the packet to the D-LMA.
If the location information is not in the cache memory of O-LMA, O-LMA tunnels the packet to the H-LMA based on the HoA prefix. Each H-LMA manages a unique set of HoA prefixes, and each LMA knows which HoA prefix is owned by which H-LMA.
When H-LMA has received a packet which is destined to an HoA belonging to its HoA prefix and which is tunneled to it by an O-LMA, but its location information indicates that the MN is currently anchored to another LMA (D-LMA), it tunnels the packet to the D-LMA. Meanwhile it sends this location informations of HoA to O-LMA.
When O-LMA has received from H-LMA that the location information that HoA is currently anchored to a D-LMA, it caches this information.
If O-LMA has no activities of HoA packets, the cache memory of the HoA location information will time out.
If an MN has recently moved from one D-LMA (previous D-LMA) to another D-LMA (new D-LMA), The new D-LMA will send the new location information of HoA to both H-LMA and the previous D-LMA.
When the previous D-LMA is informed that MN has moved to the new D-LMA, it caches this location information. This cache memory will time out when its timer expires.
When the previous D-LMA has received packets for HoA from an O-LMA, it checks its cache memory about the new location information of the MN. If the cache memory has not timed out, it tunnels the packet to the new D-LMA. Meanwhile, it sends to O-LMA the new location information for this HoA.
When an LMA has received packets for an HoA which is not anchored to itself, it drops the packet unless it is the previous D-LMA for this HoA and the cache memory of the new location has not yet expired.
| TOC |
| TOC |
When a node with which MN will communicate, i.e., a correspondent node (CN), first attempts to communicate with MN using the HoA of MN, the packet is intercepted by the LMA nearest to CN because all LMAs are advertizing the same superset of IP prefixes using anycast. We call this originating LMA (O-LMA). This O-LMA uses the HoA to look up the H-LMA of MN and then tunnels the packet to H-LMA. H-LMA receives the packet and de-encapsulates it to read the HoA of MN.
If MN is in a visited network, H-LMN will tunnel the packet to the V-LMA to which MN is currently anchored. V-LMA will de-encapsulate the packet and use the proxy care-of address (proxy CoA) to tunnel the packet to MN or to mobility anchor gateway (MAG). Figure 7 shows the destination address at the network layer of the protocol stack of a first packet sent from CN to MN.
First packets
+---+ +---+-----+ +-----+-----+ +-----+---+ +---+---+ +---+ |HoA|-->|HoA| HoA | | HoA | HoA | | HoA |HoA| |HoA|HoA|-->|HoA| | | | |-----| |-----|-----| |-----|---| |---| | | | | | | |H-LMA|-->|H-LMA|V-LMA|-->|V-LMA|CoA|-->|CoA| | | | +---+ +---+-----+ +-----+-----+ +-----+---+ +---+---+ +---+ CN O-LMA H-LMA V-LMA MAG MN
Figure 7. Network layer in the protocol stack of the first packet sent from CN to MN in a visited network showing the destination IP address as the packet travses from CN to MN
Only the first few packets from CN may encounter triangle routing. When H-LMA has received this first packet from O-LMA and forwards this packet to V-LMA, it will also inform O-LMA that the HoA is currently anchored to V-LMA. The O-LMA keeps this location management information in a cache memory so that it may forward the packet directly to V-LMA in future without going through H-LMA. V-LMA may use the proxy care-of address (proxy CoA) to directly tunnel the packet to MN or to mobile access gateway (MAG) (Figure 8).
Subsequent packets
+---+ +---+-----+ +-----+---+ +---+---+ +---+ |HoA| --> |HoA| HoA | | HoA |HoA| |HoA|HoA| --> |HoA| | | | |-----| |-----|---| |---| | | | | | | |V-LMA| --> |V-LMA|CoA| --> |CoA| | | | +---+ +---+-----+ +-----+---+ +---+---+ +---+ CN O-LMA V-LMA MAG MN
Figure 8. Network layer in the protocol stack of subsequent packets sent from CN and tunneled to V-LMA in a visited network showing the destination IP address as the packet travses from CN to MN
After absence of traffic from O-LMA to HoA for some time, the cache memory in O-LMA may time out.
| TOC |
It is possible for MN to change its mobile access gateway (MAG) and proxy CoA while anchoring to the same V-LMA. With no change of V-LMA, packets forwarded from O-LMA to V-LMA are unaffected.
MAG may change from a previous MAG to a new MAG. As proxy CoA subsequently changes, V-LMA updates the mapping between HoA and proxy CoA.
If O-LMA has been tunneling directly to the previous MAG without going through D-LMA, the previous MAG will need to tunnel the packet to the new MAG. Meanwhile the previous MAG will inform O-LMA to tunnel future packets directly to the new MAG.
| TOC |
When the movement of a mobile node during an onging session necessitates change of its local mobility anchor from a previous D-LMA to a new D-LMA, H-LMA will be notified to ensure it has the correct location information. The other LMA may either forward packets to H-LMA or obtain the optimized routing information. Yet some LMA may have cached the old location information and may continue to tunnel packets to the previous D-LMA. This situation may happen if some CN served by an O-LMA has sent packet to MN earlier and the cache memory has not yet timed out. This situation may also happen when both MN and CN move and change LMAs at the same time.
We add a forwarding mechanism here. When MN moves from the previous D-LMA to the new D-LMA, the new D-LMA may notify the previous D-LMA. Then if the packets for MN reaches the prevous D-LMA, the previous D-LMA will forward these packet to the new D-LMA so that the packet will be able to always reach the serving D-LMA. Meanwhile the previous D-LMA will inform O-LMA to tunnel future packets directly to the new D-LMA.
If O-LMA is already tunneling directly to the previous MAG without going through the previous D-LMA, the previous MAG will need to tunnel the packet to the new MAG. Meanwhile the previous MAG will inform O-LMA to tunnel future packets directly to the new MAG.
| TOC |
It is obvious to see that sending packets from a mobile node does not encounter triangle routing problem. The packet addressed to a correspondent node may not always need to go through LMA. Yet it may choose to go through LMA because of location privacy, and Figure 9 shows the source IP address of such a packet, which is tunneled to O-LMA. This LMA is the closest LMA to which MN is anchoring to and will then send the packet to the correspondent node.
+---+ +---+---+ +---+---+ +---+ |HoA| --> |HoA|HoA| |HoA|HoA| --> |HoA| | | | |---| |---| | | | | | | |CoA| -->|CoA| | | | +---+ +---+---+ +---+---+ +---+ MN MAG O-LMA CN
Figure 9. Network layer showing the source IP address as a packet travses from MN to CN.
| TOC |
| TOC |
In this proposal, O-LMA will behave like a full functioned LMA for MN after it has acquired and cached the location management to optimize routing. The route from CN to MN for later packets are then the same as for migrating home agents. It is therefore reasonable to say that the round trip time after the first packets are comparable to migrating home agents for which the experimentally achieved round trip times had already been shown in their experiments [MHA].
| TOC |
Only the first packet or first few packets may, but not always, encounter triangle routing. It is possible to query the H-LMA before sending the first packet. Yet a V-LMA is not completely at lost of where to route in distributed LMA design. Here, each H-LMA is responsible for its own block of IP addresses in a network to allocate to the mobile nodes registering to that network. Every LMA may be informed of which H-LMA is responsible for which address block.
In other words, O-LMA does not lack routing information even for the first packets. It lacks only optimized-route informing. Without such information, O-LMA already knows which H-LMA is managing the HoA and may therefore immediately forward the first packets to H-LMA without waiting for information acquisition. The routing path going through H-LMA here is comparable to that in mobile IP using home agent in the home network only.
Triangle routing is encountered only for certain configuration with the mobile node being far from the registered network and only for the first packets. This is a small price for not pushing the full location management information to all the other home agents and synchronizing all the home agents.
The possible delay only for the first packets may not always be important, because it may affect only the call setup delay. Many communication applications go through a call set up process to begin a communication session. This call setup delay customarily experienced is usually much longer than the typical packet delay in an ongoing communication session. Compared with pushing mobility management information to all home agents, the distributed local mobility anchors differ only in a possible triangle routing for the first packets which may be a small overhead added only to the call setup delay.
| TOC |
When there are n(MN) mobile nodes, the amount of location update information increases with this number of mobile node. If this location management information is pushed to all the LMAs, the amount of signaling increases also with n(LMA) which is the number of LMAs. Therefore the amount of signaling in pushing the location management information to all the LMAs is proportional to n(MN) x n(LMA).
By keeping the master information at H-LMA without pushing to all LMAs, the amount of signaling is proportional to n(MN) only.
| TOC |
Double move problem refers to that when both source and destination nodes are moving at the same time. In this case, the mobile node has moved from a previous LMA to a new LMA while the correspondent node has also changed its O-LMA. The O-LMA of the correspondent node may be using outdated cache information to route packet to previous D-LMA. Here new D-LMA may inform previous D-LMA to forward these packets to new D-LMA. Meanwhile, the previous D-LMA may inform O-LMA to route future packet directly to the new D-LMA.
| TOC |
This document does not require any IANA actions.
| TOC |
Trust relationship is needed among the LMAs, as in PMIP. When O-LMA tunnels packets back to H-LMA, the security considerations are not different from PMIP.
Untrusted LMAs make the network vulnerable to various attacks. An untrusted LMA may also tunnel many packets to a D-LMA causing DOS attack.
With route optimization, H-LMA may send location information to O-LMA which will use this information to tunnel packets directly to D-LMA. The trust relationship between H-LMA and O-LMA and the protection of these location information messages are important. The protection mechanisms needed are similar to those of proxy binding updates in [GHAHA].
When MN moves from a previous D-LMA to a new D-LMA, lack of secure mechanism in sending location information update from the new D-LMA to the previous D-LMA may enable a rogue LMA to hijack the traffic to HoA. Proper trust relationship among LMAs and secured mechanisms are needed to protect these messages, but these mechanisms are again also needed in [GHAHA].
| TOC |
The authors would like to thank Hanan Ahmed for valuable comments and suggestions.
| TOC |
| TOC |
| [RFC3775] | Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” RFC 3775, June 2004 (TXT). |
| [RFC5213] | Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” RFC 5213, August 2008 (TXT). |
| TOC |
| [GHAHA] | Thubert, P., Wakikawa, R., and V. Devarapalli, “Global HA to HA protocol,” draft-thubert-mext-global-haha-01 (work in progress), July 2009 (TXT). |
| [MHA] | Wakikawa, R., Valadon, G., and J. Murai, “Migrating Home Agents Towards Internet-scale Mobility Deployments,” Proceedings of the ACM 2nd CoNEXT Conference on Future Networking Technologies, Lisboa, Portugal, December 2006. |
| [SMGI] | Zhang, L., Wakikawa, R., and Z. Zhu, “Support Mobility in the Global Internet,” Proceedings of ACM Workshop on MICNET, MobiCom 2009, Beijing, China, September 2009. |
| TOC |
| H Anthony Chan | |
| Huawei Technologies | |
| 1700 Alma Ave | |
| Plano, TX 75075 | |
| USA | |
| Email: | anthonychan@huawei.com |
| Frank Xia | |
| Huawei Technologies | |
| 1700 Alma Ave | |
| Plano, TX 75075 | |
| USA | |
| Email: | xiayangsong@huawei.com |
| Justin Xiang | |
| Huawei Technologies | |
| 1700 Alma Ave | |
| Plano, TX 75075 | |
| USA | |
| Email: | zengjun.xiang@huawei.com |