One document matched: draft-chan-netext-distributed-lma-02.txt
Differences from draft-chan-netext-distributed-lma-01.txt
NETEXT H. Chan
Internet-Draft F. Xia
Intended status: Standards Track J. Xiang
Expires: July 26, 2010 H. Ahmed
Huawei Technologies
January 22, 2010
Distributed Local Mobility Anchors
draft-chan-netext-distributed-lma-02
Abstract
This draft proposes a distributed local mobility anchors
architecture. It splits the 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 consists of home local mobility anchors (H-LMA)
at the registered networks and visited local mobility anchors (V-LMA)
at the visited networks. The V-LMA provides mobility routing
function to avoid triangle routing problem in Proxy mobile IP,
whereas the H-LMA keeps the location management function. The needed
location information of a mobile node is acquired by a V-LMA from the
H-LMA only when a packet is first sent to the mobile node via the
V-LMA and are then cached at the V-LMA to enable optimized mobility
routing for packets subsequently sent to the mobile node.
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.
Chan, et al. Expires July 26, 2010 [Page 1]
Internet-Draft Distributed LMA January 2010
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 26, 2010.
Copyright Notice
Copyright (c) 2010 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 26, 2010 [Page 2]
Internet-Draft Distributed LMA January 2010
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 . . . . . . . . . . . . . . . . . . . . . . . . . 11
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. Simultaneous moving problem . . . . . . . . . . . . . . . 17
7. Interworking with legacy LMAs . . . . . . . . . . . . . . . . 17
7.1. Reachability from CN outside MN's domain . . . . . . . . . 18
7.2. Sending packet to CN in a different distributed-LMA
domain . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.3. Sending packet to a CN in a legacy PMIP domain . . . . . . 19
7.4. Sending packet to CN running MIP outside MN's
distributed-LMA domain . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Chan, et al. Expires July 26, 2010 [Page 3]
Internet-Draft Distributed LMA January 2010
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 a mobile
node is far from its home agent while being much closer to its
correspondent node.
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. Yet the amount of signaling traffic needed in
synchronizing the home agents may become excessive when the number of
mobile nodes and the number of home agents both increase.
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 where the mobile node is registered.
The individual location management information for a specific mobile
node may be acquired whenever 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 them at 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 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 26, 2010 [Page 4]
Internet-Draft Distributed LMA January 2010
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 anchored 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 26, 2010 [Page 5]
Internet-Draft Distributed LMA January 2010
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
( 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. Therefore, each may be located in its most appropriate
place. 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 the 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 function. This network may also manage the
internetwork location information. Yet pushing the location
management (LM) information to the home agents in different networks
may be an overkill, especially when the mobile node does not always
actually communicate with CNs in all the other networks. Data
coherency may be managed using different methods. 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 at the
home network will eliminate 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 26, 2010 [Page 6]
Internet-Draft Distributed LMA January 2010
2.2. Originating local mobility anchor and destination local mobility
anchor
The LMA to which the 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 that 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 consists of
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 the 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
the location management function and one or multiple physical
Chan, et al. Expires July 26, 2010 [Page 7]
Internet-Draft Distributed LMA January 2010
entities to provide mobility routing function. In addition, 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 advertise this same super set of
IP prefixes using anycast. Then, no matter 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 when the
MN is in a visited network, H-LMA must know which V-LMA the MN is
anhored to. 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 the MN is anchored, delivers incoming packets to
the MN; it is the D-LMA for incoming packets. When the MN is in its
home network, it is anchored to H-LMA using an HoA address belonging
to the H-LMA. When the MN is in a visited network, it is anchored in
that network to the nearest V-LMA, and MAG does the MIP signaling on
behalf of the MN.
No matter where a correspondent node (CN) is located, any packet sent
from the CN to the HoA is intercepted by the nearest LMA. This LMA
is the O-LMA. The O-LMA will need to obtain the location information
of the MN from the H-LMA in order to route the packets to the D-LMA.
Because the HoA of the MN belongs to the IP prefix of its home
network, the mapping of the HoA to the H-LMA does not change often
and can therefore be known to all V-LMAs. The mobility routing
function in the V-LMA before route optimization is simply to forward
a packet from the CN to the H-LMA of the MN, and the H-LMA has the
dynamic location information about the MN to complete the mobility
routing. After route optimization the packets will need to be
forwarded directly from the O-LMA to the 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 26, 2010 [Page 8]
Internet-Draft Distributed LMA January 2010
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 the home address (HoA) to the mobile node,
manages the location of the mobile node, intercepts packets to/
from the mobile node, and forwards these packets. Each mobile
node is registered in its home network to a H-LMA, which can
download the profile of the mobile node from a home AAA server.
If the mobile node is anchored to a visited local mobility anchor
(V-LMA), the H-LMA will manage the mapping between the HoA and the
V-LMA that the mobile node is currently anchored 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 packets to/from the mobile node
and forwards packets using the location management information it
acquires 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
the HoA and the proxy-CoA of the mobile node.
Originating local mobility anchor (O-LMA) is the first local
mobility anchor that intercepts a packet 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. It knows where to deliver packets to reach the mobile
node.
Chan, et al. Expires July 26, 2010 [Page 9]
Internet-Draft Distributed LMA January 2010
Distributed-LMA domain is a domain consisting of networks supporting
distributed LMA mechanism. Security association can be set up
between the LMA's, and the IP prefixes in each LMA is anycasted by
the rest of the LMA's in the same domain.
4. Overall mechanism
The architecture of the 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 home
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 the profile of the MN from the home AAA
server.
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
home network.
The H-LMA also performs location management for the MN. If the MN
has moved to another network and is anchored to a V-LMA of a visited
Chan, et al. Expires July 26, 2010 [Page 10]
Internet-Draft Distributed LMA January 2010
network, the V-LMA needs to update the H-LMN of the new location of
the MN, i.e., the new V-LMA the MN is anchored 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 the PA
is the aggregate of P1A, P2A, and P3A; while 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 the MN leaves its home 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 July 26, 2010 [Page 11]
Internet-Draft Distributed LMA January 2010
A MAG sends binding update to the LMA on behalf of the 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 the H-LMA has determined that the HoA is not unique,
V-LMA will need to send a registration request to the H-LMA to obtain
a valid HoA for the MN.
The visited LMA (V-LMA) in this visited network has become the new
mobility anchoring point of MN.
The V-LMA performs mobility routing function for the MN.
The V-LMA informs the H-LMA that it is the current mobility anchoring
point for the MN.
After the 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). The H-LMA
must again be informed of the new anchoring point.
In addition, the V-LMA-1 is also informed that the MN has anchored to
V-LMA-2 so that, for a limited time, if V-LMA-1 receives packets
destined to MN, the V-LMA-1 may forward these packets to the V-LMA-2
according to the forwarding mechanism which will be described in the
mobility routing section below.
4.4. Mobility routing
When an originating LMA (O-LMA) has intercepted a packet with a
destination address HoA of an MN, it checks whether or not there is
location information for this HoA in its cache.
If the HoA information in the cache memory of the O-LMA indicates
that the 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 the O-LMA,
the 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 the H-LMA receives 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.
Chan, et al. Expires July 26, 2010 [Page 12]
Internet-Draft Distributed LMA January 2010
It also sends this location information of HoA to the O-LMA.
When the O-LMA receives the new location information from the H-LMA
indicating that the HoA is currently anchored to a D-LMA, it caches
this information.
If the O-LMA has no activities related to this HoA, this location
information in the cache memory 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 the HoA to both the H-LMA and the previous D-LMA.
When the previous D-LMA is informed that the MN has moved to another
D-LMA, it caches this location information. This cache memory will
time out when its timer expires.
When the previous D-LMA receives packets for the 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 packets to
the new D-LMA. Meanwhile, it sends this new location information to
the O-LMA.
When an LMA receives 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 expired.
5. Packet flow
5.1. Sending packets to mobile node
When a correspondent node (CN) first attempts to communicate with the
MN using the HoA of that MN, the packet is intercepted by the LMA
nearest to that CN because all LMAs are advertising 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 the MN and then
tunnels the packet to the H-LMA. The H-LMA receives the packet and
de-capsulates it to read the HoA of the MN.
If the MN is in a visited network, the H-LMN will tunnel the packets
to the V-LMA to which the MN is currently anchored. The V-LMA will
de-capsulate the packet and use the proxy care-of address (proxy CoA)
to tunnel the packet to the MN or to the mobile access gateway (MAG).
Figure 7 shows the destination address at the network layer of the
protocol stack of a first packet sent from the CN to the MN.
Chan, et al. Expires July 26, 2010 [Page 13]
Internet-Draft Distributed LMA January 2010
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 a CN to a MN in a visited network showing the destination
IP address as the packet traverses from the CN to the MN
Only the first few packets from the CN may encounter triangle
routing. When the H-LMA receives this first packet from the O-LMA
and forwards this packet to the V-LMA, it will also inform the O-LMA
that the HoA is currently anchored to the V-LMA. The O-LMA keeps
this location management information in a cache memory so that it may
forward the packet directly to the V-LMA in future without going
through the H-LMA. The V-LMA may use the proxy care-of address
(proxy CoA) to directly tunnel the packets to the MN or to the 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
In the absence of traffic from the O-LMA to the HoA, the cache memory
in the O-LMA may time out after a predefined period.
5.2. Changing MAG without changing V-LMA
It is possible for an 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 the O-LMA to the V-LMA are unaffected.
The MAG may change from a previous MAG to a new MAG. As proxy CoA
Chan, et al. Expires July 26, 2010 [Page 14]
Internet-Draft Distributed LMA January 2010
subsequently changes, the V-LMA updates the mapping between HoA and
proxy CoA.
If the O-LMA has been tunneling directly to the previous MAG without
going through the D-LMA, the previous MAG will need to tunnel the
packet to the new MAG. Meanwhile, the previous MAG will inform the
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 a change in its local mobility anchor from a previous
D-LMA to a new D-LMA, the H-LMA will be notified to ensure that it
has the correct location information. Any other LMA which is serving
as an O-LMA may either forward packets to H-LMA or obtain the
optimized routing information. Yet some LMA's 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 the MN earlier and the cache memory has not
yet timed out. This situation may also happen when both the MN and
the CN move and change LMAs at the same time.
We add a forwarding mechanism here. When the MN moves from one D-LMA
to a new D-LMA, the new D-LMA may notify the previous D-LMA. If any
packets destined to the MN reach the prevous D-LMA, the previous
D-LMA will forward these packet to the new D-LMA. Meanwhile, the
previous D-LMA will inform the O-LMA to tunnel future packets
directly to the new D-LMA.
If the 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 packets to the new MAG. Meanwhile, the previous MAG
will inform the O-LMA to tunnel future packets directly to the new
MAG.
5.4. Sending packets from mobile node
It is obvious that sending packets from a mobile node does not
encounter the triangle routing problem. The packets addressed to a
correspondent node may not always need to go through the LMA.
However, it may go through the LMA to preserve location privacy.
Figure 9 shows the source IP address of such a packet, which is
tunneled to the O-LMA. This LMA is the closest LMA to which the MN
is anchored to and will then send the packet to the correspondent
node.
Chan, et al. Expires July 26, 2010 [Page 15]
Internet-Draft Distributed LMA January 2010
+---+ +---+---+ +---+---+ +---+
|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, the O-LMA will behave like a full functioned LMA
for the MN once it has acquired and cached the location management
information to optimize routing. The route from the CN to the MN for
later packets is the same as for migrating home agents. It is
therefore reasonable to say that the round trip time after the first
packets is comparable to that of migrating home agents; and
experiments with migrating home agents had already reported round
trip times approaching that of direct routes between CN and MN [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. Alternately, a V-LMA may simply route the
first packet to the packet's H-LMA.
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, the 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 the H-LMA without waiting for information
acquisition. The routing path going through the H-LMA here is
comparable to that in the case of mobile IP using the home agent in
the home network only.
Triangle routing is encountered only for the first packets and only
for certain configurations where the mobile node and the
corresponding node are both far from the home network but are close
to each other. This is a small price for not pushing the full
Chan, et al. Expires July 26, 2010 [Page 16]
Internet-Draft Distributed LMA January 2010
location management information to all the other home agents for
synchronization purpose.
The possible delay for the first packets 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 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
Consider that there are n mobile nodes and m LMAs. If the location
management information is pushed to all the LMAs, the amount of
signaling in pushing the location management information to all the
LMAs is proportional to n x m.
By keeping the master information at the H-LMA without pushing it to
all the LMAs, the amount of signaling is proportional to n only.
6.4. Simultaneous moving problem
Because both the source and the destination nodes may be mobile, they
may be changing their LMA's 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
packets to previous D-LMA. The new D-LMA may inform the previous
D-LMA to forward these packets to the new D-LMA. Meanwhile, the
previous D-LMA may inform the O-LMA to route any future packets
directly to the new D-LMA.
7. Interworking with legacy LMAs
The use of anycast and the need for trust relationship among the
H-LMA's and V-LMA's in distributed LMA may be less challenging in a
domain where the networks belong to one autonomous system or to one
service provider. The service provider network may cover large and
fragmented geographical areas. The MN in this domain will be
reachable from any CN within this same domain. However, the CN may
belong to a different domain or to a legacy network not supporting
distributed LMA. This section addresses these interworking issues.
Chan, et al. Expires July 26, 2010 [Page 17]
Internet-Draft Distributed LMA January 2010
7.1. Reachability from CN outside MN's domain
Figure 10 shows a configuration in which a CN is in a network outside
the distributed-LMA domain of a MN. When the CN sends a packet to
the MN, the CN's network recognizes that the IP prefix of the
destination address belongs to a different domain. The network may
find the shortest path for the packet to exit itself (hot potato
routing) and let the packet be routed through the transit core
network to the MN's domain. As it enters the MN's domain, the use of
anycast in this distributed-LMA domain will cause the packet to reach
the nearest LMA. This LMA is now serving as originating LMA (O-LMA)
to route the packet to the MN.
CN
|
|
v
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( ) ( ) ( ) ( ) ( )
( ) ( ) ( ) ( ) ( ) ( ) ( )
v v V v v v v v v v v v v v v v v v v v v
\
\
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
( ) ( 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
|
|
v
MN
Figure 10. Configuration showing O-LMA and D-LMA for a packet sent
by CN from a network outside the domain of MN.
Because routing is based on the destination address and as long as
the CN is outside MN's distributed LMA domain, the above process is
the same regardless of whether the CN is in a different distributed
LMA domain, is in a different PMIP domain, is running MIP, or is a
fixed node.
Chan, et al. Expires July 26, 2010 [Page 18]
Internet-Draft Distributed LMA January 2010
7.2. Sending packet to CN in a different distributed-LMA domain
Figure 11 shows a configuration in which the CN is in a different
distributed-LMA domain than that of the MN. For a packet sent from
the MN to the CN, the MN's domain recognizes that the IP prefix of
the destination address belongs to a different domain. The network
may also find the shortest path for the packet to exit itself (hot
potato routing) and let the packet be routed through the transit core
network to the CN's domain. As it enters the CN's domain, the use of
anycast in this distributed-LMA domain will cause the packet to reach
the nearest LMA. This LMA is now serving as O-LMA to route the
packet to the LMA closest to the CN, which is the D-LMA serving the
CN.
CN
^
|
|
O-LMA D-LMA
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( ) ( ) ( ) ( ) ( )
( LM ) ( ) ( ) ( ) ( ) ( ) ( )
( 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 v v v
/
/
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
( ) ( 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
Figure 11. Configuration showing O-LMA and D-LMA for a packet sent
by MN to CN in a different distributed LMA domain.
7.3. Sending packet to a CN in a legacy PMIP domain
Figure 12 shows a configuration in which CN is in a PMIP domain not
supporting distributed LMA. The CN may be physically located inside
or outside the MN's distributed LMA domain. If the CN is in a
network outside MN's distributed LMA domain, for a packet sent from
Chan, et al. Expires July 26, 2010 [Page 19]
Internet-Draft Distributed LMA January 2010
the MN to the CN, the MN's domain recognizes that the IP prefix of
the destination address belongs to a different domain. The network
may also find the shortest path for the packet to exit itself (hot
potato routing) and let the packet be routed to the CN's network
domain through the transit core network. As it enters the CN's PMIP
domain, the packet will follow the PMIP routing in that domain. It
may encounter triangle routing. If it uses route optimization in the
PMIP domain, the CN may lose its location privacy to the MN.
It may be possible that the CN's access network is in both the MN's
distributed LMA domain and the CN's own PMIP domain. Yet CN's IP
prefix address is derived from the legacy LMA in CN's PMIP domain.
The network will therefore route the packet to this legacy LMA, which
does not support distributed LMA. It may again encounter triangle
routing. If it uses route optimization in the PMIP domain, the CN
may not be able to hide its location from the MN.
CN
^
|
|
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( ) ( ) ( ) ( ) ( )
( LMA ) ( ) ( ) ( ) ( ) ( ) ( )
( ) ( ) ( ) ( ) ( ) ( ) ( )
v v V v v v v v v v v v v v v v v v v v v
/
/
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
( ) ( 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
Figure 12. Configuration of sending packet from MN from a
distributed-LMA domain to CN belonging to a legacy PMIP domain.
7.4. Sending packet to CN running MIP outside MN's distributed-LMA
domain
Figure 13 shows a configuration in which the CN is running MIP. The
IP address of the CN is derived from the CN's home network. The CN
Chan, et al. Expires July 26, 2010 [Page 20]
Internet-Draft Distributed LMA January 2010
may be physically located inside or outside the MN's distributed-LMA
domain. In either case, the packet is routed to the CN's home
network where it is intercepted by the CN's HA. Again, the packet
may encounter triangle routing. If it uses route optimization
defined in MIP, the CN may not be able to hide its location from the
MN.
CN
^
|
|
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( ) ( ) ( ) ( ) ( )
( HA ) ( ) ( ) ( ) ( ) ( ) ( )
( ) ( ) ( ) ( ) ( ) ( ) ( )
v v V v v v v v v v v v v v v v v v v v v
/
/
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
( ) ( 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
Figure 13. Configuration of sending packet from MN to CN running MIP
but not supporting distributed LMA.
8. IANA Considerations
This document does not require any IANA actions.
9. Security Considerations
As in PMIP, a trust relationship is needed among the LMAs. When the
O-LMA tunnels packets back to the H-LMA, the security considerations
are not different from that in PMIP.
Untrusted LMAs make the network vulnerable to various attacks. An
untrusted LMA may tunnel many packets to the D-LMA causing DOS
attacks.
Chan, et al. Expires July 26, 2010 [Page 21]
Internet-Draft Distributed LMA January 2010
With route optimization, the H-LMA may send location information to
the O-LMA which will use this information to tunnel packets directly
to the D-LMA. The trust relationship between the H-LMA and the O-LMA
and the protection of the location information messages are
important. The protection mechanisms needed are similar to those of
proxy binding updates in [GHAHA].
When the MN moves from one D-LMA to a new D-LMA, the 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.
Proper trust relationships among LMAs and secured mechanisms are
needed to protect these messages. These mechanisms are similar to
those needed in [GHAHA].
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 26, 2010 [Page 22]
Internet-Draft Distributed LMA January 2010
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
Hanan Ahmed
Huawei Technologies
10180 Telesis Ct. Suite 365
San Diego, CA 92121
USA
Email: ahanan@huawei.com
Chan, et al. Expires July 26, 2010 [Page 23]
| PAFTECH AB 2003-2026 | 2026-04-24 04:23:39 |