One document matched: draft-chan-netext-distributed-lma-01.txt
Differences from draft-chan-netext-distributed-lma-00.txt
NETEXT H. Chan
Internet-Draft F. Xia
Intended status: Standards Track J. Xiang
Expires: July 3, 2010 Huawei Technologies
December 30, 2009
Distributed Local Mobility Anchors
draft-chan-netext-distributed-lma-01
Abstract
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.
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 July 3, 2010 [Page 1]
Internet-Draft Distributed LMA December 2009
This Internet-Draft will expire on July 3, 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 July 3, 2010 [Page 2]
Internet-Draft Distributed LMA December 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Splitting the logical functions of a local mobility
anchor . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Originating local mobility anchor and destination
local mobility anchor . . . . . . . . . . . . . . . . . . 7
2.3. Home local mobility anchor versus visited local
mobility anchor . . . . . . . . . . . . . . . . . . . . . 7
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Overall mechanism . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Visited Network . . . . . . . . . . . . . . . . . . . . . 11
4.4. Mobility routing . . . . . . . . . . . . . . . . . . . . . 12
5. Packet flow . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Sending packets to mobile node . . . . . . . . . . . . . . 13
5.2. Changing MAG without changing V-LMA . . . . . . . . . . . 14
5.3. Changing LMA . . . . . . . . . . . . . . . . . . . . . . . 15
5.4. Sending packets from mobile node . . . . . . . . . . . . . 15
6. Performance . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Round trip time . . . . . . . . . . . . . . . . . . . . . 16
6.2. Call setup delay . . . . . . . . . . . . . . . . . . . . . 16
6.3. Location update signaling overhead . . . . . . . . . . . . 17
6.4. Double move problem . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Chan, et al. Expires July 3, 2010 [Page 3]
Internet-Draft Distributed LMA December 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
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.
Chan, et al. Expires July 3, 2010 [Page 4]
Internet-Draft Distributed LMA December 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 (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.
Chan, et al. Expires July 3, 2010 [Page 5]
Internet-Draft Distributed LMA December 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 (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.
Chan, et al. Expires July 3, 2010 [Page 6]
Internet-Draft Distributed LMA December 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 visited local mobility anchor
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
Chan, et al. Expires July 3, 2010 [Page 7]
Internet-Draft Distributed LMA December 2009
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.
3. Terminology
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.
Chan, et al. Expires July 3, 2010 [Page 8]
Internet-Draft Distributed LMA December 2009
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.
Chan, et al. Expires July 3, 2010 [Page 9]
Internet-Draft Distributed LMA December 2009
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 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.
4.2. Anycast
An example of using anycast for HoA prefixes is shown in Figure 6.
Chan, et al. Expires July 3, 2010 [Page 10]
Internet-Draft Distributed LMA December 2009
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( )
( 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 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
Chan, et al. Expires July 3, 2010 [Page 11]
Internet-Draft Distributed LMA December 2009
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.
4.4. Mobility routing
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.
Chan, et al. Expires July 3, 2010 [Page 12]
Internet-Draft Distributed LMA December 2009
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.
5. Packet flow
5.1. Sending packets to mobile node
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.
Chan, et al. Expires July 3, 2010 [Page 13]
Internet-Draft Distributed LMA December 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 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.
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 a previous MAG to a new MAG. As proxy CoA
subsequently changes, V-LMA updates the mapping between HoA and proxy
Chan, et al. Expires July 3, 2010 [Page 14]
Internet-Draft Distributed LMA December 2009
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.
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
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.
5.4. Sending packets from mobile node
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.
Chan, et al. Expires July 3, 2010 [Page 15]
Internet-Draft Distributed LMA December 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 July 3, 2010 [Page 16]
Internet-Draft Distributed LMA December 2009
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.
6.3. Location update signaling overhead
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.
6.4. 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 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.
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.
Untrusted LMAs make the network vulnerable to various attacks. An
untrusted LMA may also tunnel many packets to a D-LMA causing DOS
Chan, et al. Expires July 3, 2010 [Page 17]
Internet-Draft Distributed LMA December 2009
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].
9. Acknowledgments
The authors would like to thank Hanan Ahmed for valuable comments and
suggestions.
10. References
10.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.
10.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.
Chan, et al. Expires July 3, 2010 [Page 18]
Internet-Draft Distributed LMA December 2009
Authors' Addresses
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
Chan, et al. Expires July 3, 2010 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 04:23:23 |