One document matched: draft-chan-netext-distributed-lma-00.txt
NETEXT H. Chan
Internet-Draft F. Xia
Intended status: Standards Track J. Xiang
Expires: May 16, 2010 Huawei Technologies
November 12, 2009
Distributed Local Mobility Anchors
draft-chan-netext-distributed-lma-00
Abstract
The full functions of a local mobility anchor may be separated into
different logical functions: (1) allocation of home network prefixes
or home addresses to mobile nodes, (2) location management function
which includes managing the IP addresses and locations of the mobile
nodes and (3) mobility routing function which includes intercepting
and forwarding packets. Distributed local mobility anchors provides
visiting 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
visiting local mobility anchor to enable subsequent optimized
mobility routing.
Status of this Memo
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.
Chan, et al. Expires May 16, 2010 [Page 1]
Internet-Draft Distributed LMA November 2009
This Internet-Draft will expire on May 16, 2010.
Copyright Notice
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.
Chan, et al. Expires May 16, 2010 [Page 2]
Internet-Draft Distributed LMA November 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Splitting the logical functions of a local mobility
anchor . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Originating local mobility anchor and destination
local mobility anchor . . . . . . . . . . . . . . . . . . 6
2.3. Home local mobility anchor versus visiting local
mobility anchor . . . . . . . . . . . . . . . . . . . . . 6
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Overall mechanism . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Visited Network . . . . . . . . . . . . . . . . . . . . . 10
4.4. Mobility routing . . . . . . . . . . . . . . . . . . . . . 11
5. Packet flow . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Sending packets to mobile node . . . . . . . . . . . . . . 12
5.2. Changing MAG without changing V-LMA . . . . . . . . . . . 13
5.3. Changing LMA . . . . . . . . . . . . . . . . . . . . . . . 14
5.4. Sending packets from mobile node . . . . . . . . . . . . . 14
6. Performance . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Round trip time . . . . . . . . . . . . . . . . . . . . . 15
6.2. Call setup delay . . . . . . . . . . . . . . . . . . . . . 15
6.3. Double move problem . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Chan, et al. Expires May 16, 2010 [Page 3]
Internet-Draft Distributed LMA November 2009
1. Introduction
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
visiting 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.
Chan, et al. Expires May 16, 2010 [Page 4]
Internet-Draft Distributed LMA November 2009
2. Motivation
2.1. Splitting the logical functions of a local mobility anchor
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 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 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 one network
only 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 mobility routing (MR) function
available in many networks, whereas the dynamic internetwork location
management (LM) function resides in one registered network only.
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.
Chan, et al. Expires May 16, 2010 [Page 5]
Internet-Draft Distributed LMA November 2009
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
( 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 function
available in multiple geographic locations will solve triangle
routing problem. It is also evidvent that the network that 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 information to the home agents in all networks may be an
overkill, and the mobile node does not always actually communicates
with CNs from all the other networks. 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
knows 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.
Chan, et al. Expires May 16, 2010 [Page 6]
Internet-Draft Distributed LMA November 2009
2.2. Originating local mobility anchor and destination local mobility
anchor
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.
2.3. Home local mobility anchor versus visiting local mobility anchor
This draft defines home local mobility anchor and visiting 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 visiting local mobility
anchor (V-LMA) are the logical mobility functions provided by a
visited network. We use the term visiting local mobility anchor
irrespective of whether the mobile node actually visits that network.
To the mobile node, V-LMA provides predominantly 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
Chan, et al. Expires May 16, 2010 [Page 7]
Internet-Draft Distributed LMA November 2009
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 roaming 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 visiting 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.
3. Terminology
All the general mobility-related terms 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].
In addition, this draft introduces the following terms.
Chan, et al. Expires May 16, 2010 [Page 8]
Internet-Draft Distributed LMA November 2009
Mobility routing function is the logical function to intercept and
forward packets to/from a mobile node.
Home address allocation function is the logical function to allocate
home address to a mobile node.
Location management function 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. There
are of cause additional location information about the intra-
network location which the local network needs to route packets to
the mobile node from the local mobility anchor and which is
dependent upon the intra-network mobility mechanism.
Home local mobility anchor (H-LMA) to a mobile node are the full
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 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
visiting 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.
Visiting local mobility anchor (V-LMA) to a mobile node are 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 to a mobile node.
Chan, et al. Expires May 16, 2010 [Page 9]
Internet-Draft Distributed LMA November 2009
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.
4. Overall mechanism
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.
4.1. Registration
A mobile node MN may register with a H-LMA.
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
roamed or handed off to another network and anchored to a V-LMA of
the visited network, H-LMN must know which V-LMA the MN is anchoring
Chan, et al. Expires May 16, 2010 [Page 10]
Internet-Draft Distributed LMA November 2009
to.
4.2. Anycast
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.
4.3. Visited Network
An MN that has registered with a H-LMA may roam or handoff to a
visited 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.
Chan, et al. Expires May 16, 2010 [Page 11]
Internet-Draft Distributed LMA November 2009
An MAG sends binding update to LMA on behalf of MN using the HoA of
the MN and its proxy CoA.
To ensure robustness, LMA looks up which H-LMA the MN has registered
to, based on the HoA prefix of the MN. LMA 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 register MN with H-LMA to obtain a valid HoA.
This visiting 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 roam or handoff 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 anchoring to V-LMA-2.
In addition, V-LMA-1 is also informed that MN has anchored to V-LMA-2
so that if V-LMA-1 has received packets destined to MN, V-LMA-1 may
also forward these packets to V-LMA-2.
4.4. Mobility routing
When an originating LMA (O-LMA) has intercepted a packet with
destination address HoA of an MN, it checks its cache whether there
is location information of this HoA.
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
Chan, et al. Expires May 16, 2010 [Page 12]
Internet-Draft Distributed LMA November 2009
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 (p-LMA) to another D-LMA
(n-LMA), n-LMA will send the new location information of HoA to both
H-LMA and p-LMA.
When p-LMA is informed that MN has moved to another D-LMA (n-LMA), it
caches this location information. This cache memory will time out
when its timer expires.
When p-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 n-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 p-LMA for this HoA and
the cache memory of the new location has not yet expired.
5. Packet flow
5.1. Sending packets to mobile node
When 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 visiting 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.
Chan, et al. Expires May 16, 2010 [Page 13]
Internet-Draft Distributed LMA November 2009
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 packet(s) 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 mobility anchor 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.
5.2. Changing MAG without changing V-LMA
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 p-MAG to n-MAG. As proxy CoA subsequently
Chan, et al. Expires May 16, 2010 [Page 14]
Internet-Draft Distributed LMA November 2009
changes, V-LMA updates the mapping between HoA and proxy CoA.
If O-LMA has been tunneling directly to p-MAG without going through
D-LMA, the previous MAG (p-MAG) will need to tunnel the packet to the
new MAG (n-MAG). Meanwhile p-MAG will inform O-LMA to tunnel future
packets directly to n-MAG.
5.3. Changing LMA
When the movement of a mobile node during an onging session
necessitates change of its local mobility anchor from a previous LMA
(p-LMA) to a new LMA (n-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 p-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 p-LMA to
n-LMA, n-LMA may notify p-LMA. Then if the packets for MN reaches
p-LMA, p-LMA will forward these packet to n-LMA so that the packet
will be able to always reach n-LMA. Meanwhile p-LMA will inform
O-LMA to tunnel future packets directly to n-LMA.
If O-LMA is already tunneling directly to p-MAG without going through
p-LMA, the previous MAG (p-MAG) will need to tunnel the packet to the
new MAG (n-MAG). Meanwhile p-MAG will inform O-LMA to tunnel future
packets directly to n-MAG.
5.4. Sending packets from mobile node
It is trivial 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.
Chan, et al. Expires May 16, 2010 [Page 15]
Internet-Draft Distributed LMA November 2009
+---+ +---+---+ +---+---+ +---+
|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.
6. Performance
6.1. Round trip time
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].
6.2. Call setup delay
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.
Chan, et al. Expires May 16, 2010 [Page 16]
Internet-Draft Distributed LMA November 2009
The possible delay only for the first packets may not always be
important, because it may affects only the call setup delay. Many
communication applications go through a call set up process to begin
a communication session. A short enough packet delay in an ongoing
communication session may be needed, but a relatively longer call
setup delay has been customary. Compared with pushing mobility
management information to all home agents, the distributed local
mobility achors differ only in a possible triangle routing for the
first packets which may be a small overhead only to the call setup
delay.
The amount of signaling in pushing location management to all the
other home agents is proportional to the product of the number of
mobile nodes and the number of home agents. By keeping the master
information at H-LMA, the amount of signaling is proportional to the
number of mobile nodes only.
6.3. Double move problem
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 (p-LMA) to a new LMA (n-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 p-LMA. Here n-LMA may inform p-LMA to forward these
packets to n-LMA. Meanwhile, p-LMA may inform O-LMA to route future
packet directly to n-LMA.
7. IANA Considerations
This document does not require any IANA actions.
8. Security Considerations
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.
Lack of trust relationship among LMAs is 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
Chan, et al. Expires May 16, 2010 [Page 17]
Internet-Draft Distributed LMA November 2009
mechanisms needed are similar to those of proxy binding updates in
[GHAHA].
When MN moves from p-LMA to n-LMA, lack of secure mechanism in
sending location information update from n-LMA to p-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].
9. References
9.1. Normative References
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
9.2. Informative References
[GHAHA] Thubert, P., Wakikawa, R., and V. Devarapalli, "Global HA
to HA protocol", draft-thubert-mext-global-haha-01 (work
in progress), July 2009.
[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.
Authors' Addresses
H Anthony Chan
Huawei Technologies
1700 Alma Ave
Plano, TX 75075
USA
Email: anthonychan@huawei.com
Chan, et al. Expires May 16, 2010 [Page 18]
Internet-Draft Distributed LMA November 2009
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
Chan, et al. Expires May 16, 2010 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 04:25:17 |