One document matched: draft-chan-netext-distributed-lma-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC3775 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3775.xml'>
<!ENTITY RFC5213 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5213.xml'>
<!ENTITY GTEST PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-thubert-mext-global-haha-01.xml'>
]>
<rfc category="std" ipr="trust200811" docName="draft-chan-netext-distributed-lma-02">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt'?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<front>
<title abbrev="Distributed LMA">Distributed Local Mobility Anchors</title>
<author fullname="H Anthony Chan" initials="H" surname="Chan">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>1700 Alma Ave</street>
<city>Plano, TX 75075</city>
<country>USA</country>
</postal>
<email>anthonychan@huawei.com</email>
</address>
</author>
<author fullname="Frank Xia" initials="F" surname="Xia">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>1700 Alma Ave</street>
<city>Plano, TX 75075</city>
<country>USA</country>
</postal>
<email>xiayangsong@huawei.com</email>
</address>
</author>
<author fullname="Justin Xiang" initials="J" surname="Xiang">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>1700 Alma Ave</street>
<city>Plano, TX 75075</city>
<country>USA</country>
</postal>
<email>zengjun.xiang@huawei.com</email>
</address>
</author>
<author fullname="Hanan Ahmed" initials="H" surname="Ahmed">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>10180 Telesis Ct. Suite 365</street>
<city>San Diego, CA 92121</city>
<country>USA</country>
</postal>
<email>ahanan@huawei.com</email>
</address>
</author>
<!-- month and day will be generated automatically by XML2RFC;
be sure the year is current.-->
<date year="2010" />
<area>Internet Area</area>
<workgroup>NETEXT</workgroup>
<keyword>Mobility Management</keyword>
<keyword>MIPv6</keyword>
<keyword>PMIPv6</keyword>
<!--add additional keywords here for IETF website search engine -->
<abstract>
<t> 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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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.
</t>
<t>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.
</t>
<t>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.
</t>
<t>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.
</t>
<t>This draft is written using the definitions of Proxy mobile IP,
but the proposal works equally well for mobile IP.
</t>
</section>
<section title="Motivation">
<section title="Splitting the logical functions of a local mobility anchor">
<t>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.
</t>
<t>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.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
( ) ( LMA ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
v v v v v v v v v v v v v v v v v v
MN CN
]]></artwork>
<postamble></postamble>
</figure>
<t>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).
</t>
<t>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.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
( 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
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 2. Configuration showing the replication of LMAs in multiple networks.
</t>
<t>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.
</t>
<t>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.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
( ) ( 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
]]></artwork>
<postamble></postamble>
</figure>
<t>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.
</t>
</section>
<section title="Originating local mobility anchor and destination local mobility anchor">
<t>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.
</t>
<t>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.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
( ) ( 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
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 4. Configuration showing O-LMA and D-LMA for a packet sent from CN to MN.
</t>
</section>
<section title="Home local mobility anchor versus visited local mobility anchor">
<t>This draft defines home local mobility anchor and visited local mobility anchor as logical functions.
</t>
<t>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.
</t>
<t>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 entities to provide mobility routing function.
In addition, these different entities do not need to be in one-to-one relationship.
</t>
<t>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.
</t>
<t>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.
</t>
<t>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.
</t>
<t>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.
</t>
</section>
</section>
<section title="Terminology">
<t>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).
</t>
<t>In addition, this draft introduces the following terms.
</t>
<t>
<list style='hanging'>
<t hangText='Mobility routing'>(MR)
is the logical function to intercept and forward packets to/from a mobile node.
</t>
<t hangText='Home address allocation'>
is the logical function to allocate home address to a mobile node.
</t>
<t hangText='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.
</t>
<t hangText='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.
</t>
<t hangText='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.
</t>
<t hangText='Originating local mobility anchor'>
(O-LMA) is the first local mobility anchor that intercepts a packet destined to a mobile node.
</t>
<t hangText='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.
</t>
<t hangText='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.
</t>
</list>
</t>
</section>
<section title="Overall mechanism">
<t>The architecture of the distributed LMA is shown in Figure 5.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( )
( 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
]]></artwork>
<postamble></postamble>
</figure>
<t>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.
</t>
<section title="Registration">
<t>A mobile node MN will register with a H-LMA in its home network.
</t>
<t>The H-LMA can download the profile of the MN from the home AAA server.
</t>
<t>The H-LMA allocates to the MN a home address HoA belonging to a block of prefixes managed by the H-LMA.
</t>
<t>The H-LMA performs mobility routing function for the MN within this home network.
</t>
<t>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 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.
</t>
</section>
<section title="Anycast">
<t>An example of using anycast for HoA prefixes is shown in Figure 6.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( )
( 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
]]></artwork>
<postamble></postamble>
</figure>
<t>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
</t>
<t>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.
</t>
<t>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.
</t>
<t>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.
</t>
</section>
<section title="Visited Network">
<t>An MN that has registered with a H-LMA may move to a network other than the home network.
</t>
<t>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.
</t>
<t>A MAG sends binding update to the LMA on behalf of the MN using the HoA of the MN and its proxy CoA.
</t>
<t>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.
</t>
<t>The visited LMA (V-LMA) in this visited network has become the new mobility anchoring point of MN.
</t>
<t>The V-LMA performs mobility routing function for the MN.
</t>
<t>The V-LMA informs the H-LMA that it is the current mobility anchoring point for the MN.
</t>
<t>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.
</t>
<t>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.
</t>
</section>
<section title="Mobility routing">
<t>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.
</t>
<t>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.
</t>
<t>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.
</t>
<t>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.
It also sends this location information of HoA to the O-LMA.
</t>
<t>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.
</t>
<t>If the O-LMA has no activities related to this HoA,
this location information in the cache memory will time out.
</t>
<t>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.
</t>
<t>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.
</t>
<t>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.
</t>
<t>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.
</t>
</section>
</section>
<section title="Packet flow">
<section title="Sending packets to mobile node">
<t>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.
</t>
<t>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.
</t>
<figure>
<preamble>First packets</preamble>
<artwork><![CDATA[
+---+ +---+-----+ +-----+-----+ +-----+---+ +---+---+ +---+
|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
]]></artwork>
<postamble></postamble>
</figure>
<t>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
</t>
<t>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).
</t>
<figure>
<preamble>Subsequent packets</preamble>
<artwork><![CDATA[
+---+ +---+-----+ +-----+---+ +---+---+ +---+
|HoA| --> |HoA| HoA | | HoA |HoA| |HoA|HoA| --> |HoA|
| | | |-----| |-----|---| |---| | | |
| | | |V-LMA| --> |V-LMA|CoA| --> |CoA| | | |
+---+ +---+-----+ +-----+---+ +---+---+ +---+
CN O-LMA V-LMA MAG MN
]]></artwork>
<postamble></postamble>
</figure>
<t>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
</t>
<t>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.
</t>
</section>
<section title="Changing MAG without changing V-LMA">
<t>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.
</t>
<t>The MAG may change from a previous MAG to a new MAG.
As proxy CoA subsequently changes, the V-LMA updates the mapping between HoA and proxy CoA.
</t>
<t>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.
</t>
</section>
<section title="Changing LMA">
<t>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.
</t>
<t>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.
</t>
<t>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.
</t>
</section>
<section title="Sending packets from mobile node">
<t>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.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
+---+ +---+---+ +---+---+ +---+
|HoA| --> |HoA|HoA| |HoA|HoA| --> |HoA|
| | | |---| |---| | | |
| | | |CoA| -->|CoA| | | |
+---+ +---+---+ +---+---+ +---+
MN MAG O-LMA CN
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 9. Network layer showing the source IP address
as a packet travses from MN to CN.
</t>
</section>
</section>
<section title="Performance">
<section title="Round trip time">
<t>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].
</t>
</section>
<section title="Call setup delay">
<t>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.
</t>
<t>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.
</t>
<t>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 location management information
to all the other home agents for synchronization purpose.
</t>
<t>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.
</t>
</section>
<section title="Location update signaling overhead">
<t>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.
</t>
<t>
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.
</t>
</section>
<section title="Simultaneous moving problem">
<t>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.
</t>
</section>
</section>
<section title="Interworking with legacy LMAs">
<t>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.
</t>
<section title="Reachability from CN outside MN's domain">
<t>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.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
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
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 10. Configuration showing O-LMA and D-LMA for a packet sent by CN
from a network outside the domain of MN.
</t>
<t>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.
</t>
</section>
<section title="Sending packet to CN in a different distributed-LMA domain">
<t>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.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
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
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 11. Configuration showing O-LMA and D-LMA for a packet sent by MN
to CN in a different distributed LMA domain.
</t>
</section>
<section title="Sending packet to a CN in a legacy PMIP domain">
<t>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 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.
</t>
<t>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.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
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
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 12. Configuration of sending packet from MN from a distributed-LMA domain to CN
belonging to a legacy PMIP domain.
</t>
</section>
<section title="Sending packet to CN running MIP outside MN's distributed-LMA domain">
<t>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 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.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
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
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 13. Configuration of sending packet from MN to CN
running MIP but not supporting distributed LMA.
</t>
</section>
</section>
<section title="IANA Considerations">
<t>This document does not require any IANA actions.
</t>
</section>
<section title="Security Considerations">
<t>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.
</t>
<t>Untrusted LMAs make the network vulnerable to various attacks.
An untrusted LMA may tunnel many packets to the D-LMA causing DOS attacks.
</t>
<t>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].
</t>
<t>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].
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC3775;
&RFC5213;
</references>
<references title="Informative References">
<reference anchor='GHAHA'>
<front>
<title>Global HA to HA protocol</title>
<author initials='P' surname='Thubert' fullname='Pascal Thubert'>
<organization />
</author>
<author initials='R' surname='Wakikawa' fullname='Ryuji Wakikawa'>
<organization />
</author>
<author initials='V' surname='Devarapalli' fullname='Vijay Devarapalli'>
<organization />
</author>
<date month='July' day='3' year='2009' />
</front>
<seriesInfo name='Internet-Draft' value='draft-thubert-mext-global-haha-01' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-thubert-mext-global-haha-01.txt' />
</reference>
<reference anchor="MHA" target="">
<front>
<title>Migrating Home Agents Towards Internet-scale Mobility Deployments</title>
<author initials="R" surname="Wakikawa" fullname="">
<organization />
</author>
<author initials="G" surname="Valadon" fullname="">
<organization />
</author>
<author initials="J" surname="Murai" fullname="">
<organization />
</author>
<date month="December" year="2006" />
</front>
<seriesInfo name="" value="Proceedings of the ACM 2nd CoNEXT Conference on Future Networking Technologies,
Lisboa, Portugal" />
</reference>
<reference anchor="SMGI">
<front>
<title>Support Mobility in the Global Internet</title>
<author initials="L" surname="Zhang">
<organization />
</author>
<author initials="R" surname="Wakikawa">
<organization />
</author>
<author initials="Z" surname="Zhu">
<organization />
</author>
<date month="September" year="2009" />
</front>
<seriesInfo name="" value="Proceedings of ACM Workshop on MICNET, MobiCom 2009, Beijing, China" />
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 04:20:39 |