One document matched: draft-chan-dmm-architecture-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<rfc category="info" ipr="trust200902"
docName="draft-chan-dmm-architecture-00">
<front>
<title abbrev="DMM-Architecture">
A architecture of distributed mobility management using mip and pmip
</title>
<author initials="H" surname="Chan" fullname="H Anthony Chan">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>5340 Legacy Dr. Building 3, Plano, TX 75024, USA</street>
<street>Email: h.a.chan@ieee.org</street>
</postal>
</address>
</author>
<date month="March" year="2012"></date>
<area></area>
<workgroup></workgroup>
<abstract>
<t>
This draft proposes a distributed architecture
of mobility management
in terms of abstracted logical functions.
Mobility management functions
are abstracted into different logical functions:
(1) allocation of home network prefixes
or home addresses to mobile nodes;
(2) location management
which includes managing the IP addresses
and locations of the mobile nodes;
and
(3) mobility routing
which includes intercepting and forwarding packets.
A distributed architecture can be contructed by
providing the mobility routing functions
in multiple networks in the data plane
and a distributed database is used
to host the location management function.
This generalized architecture enables
different distributed mobility designs
using primarily the existing mobility protocols
(MIP and PMIP)
and their extensions.
Several existing distributed mobility management proposals
are briefly reviewed using this framework.
It is expected that
the different proposals,
when expressed in terms of the generalized framework
of logical functions,
can interwork with each other
as well as with the existing hierarchical deployments.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
The family of Mobile IP [RFC6275] protocols,
including Proxy mobile IP [RFC5213]
and various variants of Mobile IP
separate session identifier and routing address
into a home address and a care-of-address respectively
and supports mobility
with a mobility anchor or home agent in the home network.
By routing via the anchor in the home network,
triangle routing is encountered
when a mobile node is far from the anchor
while being much closer to its correspondent node.
</t>
<t>
Centralized mobility management
has naturally been used in existing hierarchical networks,
distributed mobility management
appears more compatible with the flattened networks.
While there are research on new protocols
for distributed mobility management
it has also been proposed,
e.g., in [Paper-Distributed.Mobility.PMIP]
and in many other publications,
that distributed mobility management can be designed
using primarily the existing mobility management protocols.
It will then be helpful to be able to use the same
distributed mobility management tools
in both a distributed and a centralized manner
and to achieve distributed mobility
in both the hierarchical network and the flattened network.
Evolution path and compatibility with different deployments
may then be less of a challenge.
</t>
<t>
[I-D.dmm-approaches] has also suggested that
a framework using mainly
the existing mobility protocols and extensions
may provide the needed solutions
and expected that architecture work
rather than protocol work is needed.
This draft proposes
such a generic architectural framework
to deploy distributed mobility,
which also embodies some other proposed designs.
If also describes another design
of distributed mobility management.
</t>
<section title="Overview">
<t>
Session 3 proposes to decouple the logical functions
of a local mobility anchor
into that of home address allocation,
location management,
and mobility routing.
Such decoupling enables separation
between the data plane and the control plane,
and enables flexibility for the implementation
to place the logical functions
at their most appropriate locations.
When using MIP, PMIP, and their extensions,
the logical functions are a decomposition or classification
of the functions of these existing mobility protocols.
Yet it provides a framework
upon which
different designs of distributed mobility may be constructed.
</t>
<t>
Session 4 describes how to put the logical functions
into a distributed architecture.
In a distributed architecture,
the mobility routing function
may be present in many geographical locations
to support dynamic mobility management
and to route more directly
to avoid triangle routing in the data plane.
However, the internetwork location management function
may be kept only at the network
where the mobile node is running a session
using the IP address allocated from that network.
The individual location management information for a specific mobile node may be acquired whenever needed (Session 4.1).
</t>
<t>
The architectural framework
enables distributed mobility management
addressing the issues in centralized mobility management
(Session 4.2).
It can be used for both client-based
and network-based Mobile IP (Session 4.3).
</t>
<t>
Session 5 explains that
the distributed architecture in terms of the logical functions
enables dynamic mobility management.
Several other proposals of dynamic mobility management
can be considered as different designs
as welll as filling in any protocol gaps when needed.
</t>
<t>
Besides achieving dynamic mobility management,
one can also take advantage of the distributed architecture
to avoid unnecessarily long routes in the data plane.
Such mechanisms are explained in Session 6.
Several different route optimization
in distributed mobility management
are reviewed as different designs
in terms of a common framework,
even though they may use different terminologies.
For example,
the extension of MAG at an access router
to include mobility anchor function
is basically an access router
with the logical function of mobility routing.
Another draft previously submitted to the netext WG,
[I-D.distributed-lma],
had discussed route optimization
but with a somewhat different mechanism
in terms of receiving,
sending, handover, and other scenarios.
In the 00 version of this draft,
the route optimization mechanisms
is explained in terms of the reachability of the MN only
but can be expanded in future.
</t>
<t>
A route optimization design as well as the above framework
is explained in [Paper-Distributed.Mobility.Management].
This design is reproduced in Session 7 of this draft.
</t>
<t>
Part of the contents of this draft
are taking from another draft
previously submitted to the netext wg
but with a different design.
It is expected that expressing different designs
in terms of the logical functions of a common framework
not only provides flexibility
but may enable interworking between the different designs
as well as with the existing centralized deployment.
The other draft [I-D.distributed-lma]
explains how the distributed design
can interwork with the existing
centralized designs of MIP and PMIP.
</t>
</section>
</section>
<section title="Conventions and Terminology">
<section title="Conventions used in this document">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described
in <xref target="RFC2119" />.
</t>
</section>
<section title="Terminology">
<t>All the general mobility-related terms and their acronyms used in this document are to be interpreted
as defined in the Mobile IPv6 base specification [RFC6275] 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 packets to/from the HoA of a mobile node
and to forward 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 hangText='Home address allocation'>
is the logical function
to allocate the home network prefix
or home address to a mobile node.
</t>
<t hangText='Location management'>
(LM)
is the logical function to manage and keep track of
the internetwork location information of a mobile node,
which include a mapping of the HoA of the MN
to the routing address of the MN
or another network element
that knows how to forward packets towards the MN.
</t>
<t hangText='Home network of an application session (or an HoA IP address)'>
(LM)
is the network that has allocated the IP address
used as the session identifier (HoA)
by the application being run in an MN.
Because a MN may run multiple applications
each using a different HoA,
the notion of the home network may be generalized
to that of an application session rather than that of a MN.
</t>
</list>
</t>
</section>
</section>
<section title="Logical functions of mobility management">
<t>
We decouple the mobility management functions
into the following logical functions
to allow a more flexible design to achieve DMM:
<vspace blankLines="1" />
<list style="numbers">
<t>
allocation of home network prefix or HoA
to a MN that registers with the network;
<vspace blankLines="1" />
</t>
<t>
internetwork location management (LM) function:
managing and keeping track of the internetwork location of a MN,
which include a mapping of the HoA
to the mobility anchoring point that the MN is anchored to;
and
<vspace blankLines="1" />
</t>
<t>
mobility routing (MR) function:
intercepting packets to/from the HoA of the MN
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>
</list>
</t>
<t>
Mobile IP and Proxy mobile IP
bundle all these three mobility management functions
into the home agent or mobility anchor.
When all these logical functions are bundled
into one single entity
known as the home agent in Mobile IP
and as the local mobility anchor in Proxy Mobile IP,
having this anchor in only one network
results in triangle routing as shown in Figure 1.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network2 Network3
^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( )
(anchor) ( ) ( )
( ) ( ) ( )
v v v v v v v v v
MN CN
]]></artwork>
<postamble></postamble>
</figure>
<t>
Figure 1. Figure showing the triangle routing problem with a MN and a CN in networks
which may be close to each other
but are far from the anchor points (LMA or HA).
</t>
<t>
A method to solve the triangle routing problem
is to duplicate the anchor points
in many networks (Figure 2)
in different geographic locations.
In [GHAHA],
these anchor points (home agents)
announce the same IP prefixes using anycast.
The traffic originating from the mobile node
will then be served by the nearest anchor point,
and the traffic sent from a correspondent node to the mobile node
will be intercepted by the anchor point
nearest to the correspondent node.
Therefore both traffic will use the anchor point
nearest to where the traffic originates,
so that triangle routing is avoided.
These anchor points may possess identical information
about the mobile nodes [Paper-Migrating.Home.Agents].
Yet the synchronization of all the home agents
will then be a challenge [Paper-SMGI].
In addition, 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>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network2 Network3
^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( )
(anchor) (anchor) (anchor)
( ) ( ) ( )
v v v v v v v v v
MN CN
]]></artwork>
<postamble></postamble>
</figure>
<t>
Figure 2. Figure showing the replication
of mobility anchors in multiple networks.
</t>
<t>
Decoupling the functions of the anchoring point
into the logical functions allow more flexibility.
As illustrated in Figure 3,
having the mobility routing (MR) function
available in multiple networks
will solve the triangle routing problem.
It is also evident that the network
which has allocated the HoA of an MN
may also manage the internetwork location information of the MN.
Yet pushing this internetwork
location management (LM) information
to all the other networks
may be an overkill,
especially when the mobile node
does not always actually communicate
with any CNs in many other networks.
Keeping the location management function
at the home network of the HoA
will eliminate the need
to synchronize the location management information
in a timely and scalable manner.
Each network may then
maintain the location management information of the HoA
for which it has allocated the home network prefix.
The different such information servers in different networks
may work together to constitute a distributed database.
That is, the data in each server of the distributed database
need not be pushed to all the other servers
but the database system only needs to know
which data resides in which server.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network2 Network3
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( )
( LM(HoA) ) ( ) ( )
( MR ) ( MR ) ( MR )
( ) ( ) ( )
v v v v v v v v v v v v
MN(HoA) CN
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 3. Figure
showing the mobility routing (MR) function
available in many networks,
whereas
the dynamic internetwork location management (LM) function
of an MN using an HoA address
resides only in the network
that has allocated the network prefix of the HoA.
</t>
</section>
<section title="A distributed architecture of mobility management">
<section title="Multiple MRs and distributed LM database">
<t>
The different use case scenarios
of distributed mobility management
are described in [I-D.dmm-scenario]
as well as in [Paper-Distributed.Mobility.Review].
The architecture describes in this draft
is mainly on separating the data plane and the control plane.
</t>
<t>
Fig. 4 shows an architecture of DMM.
The figure shows,
as an example, three networks.
Each network has its own IP prefix allocation function
which is not explicitly shown in the figure.
In the data plane,
the mobility routing function
is distributed to multiple locations
at the MRs so that routing can be optimized.
In the control plane,
the MRs may signal with each other,
and the LM function is a distributed database,
with multiple servers,
of the mapping of HoA to CoA.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network2 Network3
+-----+ +-----+ +-----+
| LM1 | | LM2 | | LM3 |
+-----+ +-----+ +-----+
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \/ | \/ / |
| \ / \ | / \ / |
| \/ \|/ \/ |
| /\ /|\ /\ |
| / \ / | \ / \ |
| / /\ | /\ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
+-----+ +-----+ +-----+
| MR1 | | MR2 | | MR3 |
+-----+ +-----+ +-----+
/|\
/ | \
/ | \
/ | \
/ | \
/ | \
+----+ +----+ +----+
|MN31| |MN32| |MN11|
+----+ +----+ +----+
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 4. A distributed architecture
of mobility management.
</t>
<t>
To perform mobility routing,
the MRs need the location information
which is maintained at the LMs.
The MRs are therefore the clients of the LM servers
and may also send location updates to the LM
as the MNs perform handover.
The location information
may either be pulled from the LM servers by the MR
or pushed to the MR by the LM servers.
In addition,
the MR may also cache a limited amount of location information.
</t>
<t>
This figure shows three MRs (MR1, MR2, and MR3)
in three networks.
MN11 has moved from the first network
supported by MR1 and LM1
to the third network supported by MR3 and LM3.
It may use an HoA (HoA11) allocated to it
when it was in the first network
for those application sessions
that had already started when MN11 was attached there
and that require session continuity
after handover to the third network.
When MN11 was in the first network,
no location management is needed
so that LM1 will not keep an entry of HoA11
thereby partly addressing the problem 5 in Session 3
on wasting resources
to support MNs not needing mobility support.
After MN11 has performed handover to the third network,
the database server LM1 keeps a mapping of HoA11 to MR3.
That is,
it points to the third network
and it is the third network
that will keep track of how to reach MN11.
Such an hierarchical of mapping
can avoid frequent update signaling to LM1
as MN11 performs intra-network handover
within the third network.
In other words,
the concept of hierarchical mobile IP [RFC5380]
is applied here
but only in location management
and not in routing in the data plane.
</t>
</section>
<section title="Against the issues of centralized mobility">
<t>
The desired architecture of distributed mobility management
should enable solutions
to address the issues of centralized mobility management
such as those explained in
[Paper-Distributed.Mobility.Review].
The distributed architecture
is examined against the issues
of centralized deployment of mobile IP
as follows:
<vspace blankLines="1" />
<list style="numbers">
<t>
Non-optimized routes
especially with content delivery network (CDN) servers
moved closer to the user:
<vspace blankLines="1" />
The architecture has multiple MRs
so that an MR is available in each network
enables avoiding the non-optimal routes in the data plane.
<vspace blankLines="1" />
</t>
<t>
Non-optimality in evolved network architecture:
<vspace blankLines="1" />
These MRs can be implemented in any network
so that an MR can be closer to the access network
to which an MNs is attached.
Such an architecture can support the more flattened networks
and the CDN networks.
<vspace blankLines="1" />
</t>
<t>
low scalabiltiy of centralized route and mobility context
maintenance:
<vspace blankLines="1" />
The distributed architecture is more scalable
than a centralized one,
as is discussed in [Paper-Distributed.Centralized.Mobility].
<vspace blankLines="1" />
</t>
<t>
Single point of failure and attack:
<vspace blankLines="1" />
This problem is mitigated in a distributed database design
with multiple servers.
In addition, the availability of multiple servers
is compatible with a system to use neighboring servers
to backup the location information of each other.
<vspace blankLines="1" />
</t>
<t>
Wasting resources to support mobile nodes
which are not actively needing mobility support.
<vspace blankLines="1" />
Dynamic mobility management to be discussed in the next session
will avoid providing mobility support
when no application is using the HoA.
<vspace blankLines="1" />
</t>
</list>
</t>
</section>
<section title="DMM for MIP versus DMM for PMIP">
<t>
MIP and PMIP both employ the same concept
of separating session identifier and routing address
into the HoA and CoA respectively.
Figure 5 compares (a) MIP and (b) PMIP
by showing the destination IP address
in the network-layer header
as a packet traverses from a CN to an MN.
</t>
<figure>
<preamble>Subsequent packets</preamble>
<artwork><![CDATA[
(a) MIP:
+---+ +---+---+ +---+
|HoA| --> |HoA|HoA| |HoA|
| | | |---| |---|
| | | |CoA| ==> |CoA|
+---+ +---+---+ +---+
CN anchor MN
(b) PMIP:
+---+ +---+---+ +---+---+ +---+
|HoA| --> |HoA|HoA| |HoA|HoA| --> |HoA|
| | | |---| |---| | | |
| | | |C0A| ==> |CoA| | | |
+---+ +---+---+ +---+---+ +---+
CN anchor MAG MN
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 5. Network layer in the protocol stack of subsequent packets
sent from the CN and tunneled to the MAG
showing the destination IP address as the packet traverses from the CN to the MN.
</t>
<t>
The comparison shows that,
as far as the data-plane traffic is concerned,
the route from CN to MN in MIP
is similar to the route from CN to MAG in PMIP.
The difference is only in replacing the MN in MIP
with the MAG-MN combination.
Therefore, the distributed architecture using MIP
can be adapted to the architecture using PMIP
by replacing the MN with the MAG-MN combination.
</t>
<t>
The DMM architecture shown in Figure 4
therefore applies equally well
to both host-based and network-based mobility management.
The difference in the network-based mobility management
is in inserting a proxy function between the MR and the MN,
and this function may be located at the access router
which then becomes the mobile access gateway
as that defined in PMIP.
</t>
</section>
</section>
<section title="Dynamic mobility management">
<t>
The above distributed architecture,
which has an MR and an HoA allocation function in each network,
enables dynamic mobility management.
</t>
<t>
When new applications are started
after moving to a new network,
the device can simply use a new IP address
allocated by the new network.
Dynamic mobility management,
i.e., invoking mobility management only when needed,
has been proposed in [Paper-Distributed.Dynamic.Mobility].
</t>
<t>
[I-D.dmm-dma] describes the dynamic mobility management
using PMIP. There the MR, LM, and the HoA allocation functions
are co-located at the access router in a flattened network.
</t>
<t>
[Paper-Net.based.DMM],
or equivalently the draft [I-D.dmm-pmip],
also describes dynamic mobility management
in which the MR and the HoA allocation function
are both co-located at the access router
whereas the LM information in each of these access routers
are linked together
under the hierarchy of a centralized LM server.
</t>
<t>
[I-D.dmm-armip] again describes dynamic mobility management
in which the MR and the HoA allocation function
are both co-located at the access router.
</t>
<t>
The distributed mobility architecture
compared with a centralized approach
is more convenient to achieve dynamic mobility management.
In Fig. 6 above,
the LM function and the IP address allocation function
may communicate with each other or may co-locate.
The device MN11 may simply be using a dynamic IP address
which is leased from the network
with a finite lifetime of say 24 hours.
As MN11 leaves the first network
and attaches to the third network,
it may or may not have ongoing sessions
requiring session continuity.
If it does not,
there is no need for LM1 to keep the binding.
If it does,
it may use the existing MIP signaling mechanism
so that the LM1 will keep the binding HoA11:MR3.
When all the ongoing sessions
requiring session continuity have terminated,
it is possible for MN11 to deregister with LM1.
Yet one may not assume
the device will always perform the de-registration.
Alternatively the lease
of the dynamic IP address HoA11 will expire
upon which LM1 will remove the binding.
</t>
<t>
In the event that the ongoing session
outlives the lease of the HoA11,
MN11 will need to renew the lease
with the IP address allocation function in the first network.
</t>
<section title="Home network of an application session">
<t>
Because a MN may run multiple applications
each using a different IP address,
there can be multiple HoAs belong to different networks.
Therefore the notion of home network
may be generalized to that of an application session
or the IP address used by that session as an HoA.
Then the home network of an application session
is simply the network that has allocated the IP address
used as the session identifier (HoA)
by the application run in an MN.
</t>
</section>
</section>
<section title="Route optimization mechanisms">
<t>
The distributed architecture has already enabled
dynamic mobility management,
as is described in [I-D.dmm-dma],
even when the routes are not optimized.
Route optimization mechanism can be achieved
in addition to dynamic mobility.
</t>
<t>
With the above architecture,
there are a number of ways to enable reachability of an MN
by packets sent from a CN
using the mobility routing function.
</t>
<t>
The target to avoid unnecessarily long route
is the direct route instead of a triangular route.
In general,
when a packet is sent from a CN in one network
to a MN in another network,
the direct route consists of the following 3
routing segments (RS):
<vspace blankLines="1" />
<list style="hanging">
<t hangText="RS1.CN-MR(CN):">
the route segment from the CN to the nearest MR;
<vspace blankLines="1" />
</t>
<t hangText="RS2.MR(CN)-MR(MN):">
the route segment from the MR serving
(and therefore being closest to) the CN
to the MR serving the MN; and
<vspace blankLines="1" />
</t>
<t hangText="RS3.MR(MN)-MN:">
the route segment from the MR serving the MN to the MN.
</t>
</list>
</t>
<t>
One may therefore examine the route optimization mechanism
in terms of these 3 routing segments.
In the first segment RS1:CN-MR(CN), the alternatives are:
<vspace blankLines="1" />
<list style="hanging">
<t hangText="RS1.CN-MR(CN).anycast:">
Use anycast to route the packet to the nearest MR function.
Here,
each MR includes all the HoAs in its route announcement
as if each of them is the destination for the HoA.
Such route announcements will affect the routing table
such that the packet destined to an HoA
will be routed to the nearest MR.
The use of anycast to reach the nearest HA
has been used in [Paper-Migrating.Home.Agents]
but with a different distributed architecture
of duplicating many HAs.
It is again proposed in [Paper-Distributed.Mobility.PMIP].
<vspace blankLines="1" />
</t>
<t hangText="RS1.CN-MR(CN).gw/ar:">
Co-locate the MR function at a convenient location
to which the packet will always pass.
Such locations may be the gateway router
or the access router.
This approach will be described later.
</t>
<t>
It is noted here that in PMIP design in a hierchical network,
generally,
the MAG is at the access router
but LMA can be in the gateway router of a network.
Whether a distributed mobility design enhances the MAG
or the LMA may involve quite different mechanisms.
Yet when looking at the logical function,
it is basically the same MR function
whether this function co-locates
with the access router or the gateway router.
This draft therefore put both approaches together.
There is however a difference that the access router
needs to perform proxying function when using PMIP.
Yet the logical MR functions are the same.
</t>
<t>
It is again noted that in flattened network,
the access router and the gatway router may merge together.
With they are merged,
the needed function is again the same logical MR function.
</t>
</list>
</t>
<t>
In the second segment RS2.MR(CN)-MR(MN), the alternatives are:
<vspace blankLines="1" />
<list style="hanging">
<t hangText="RS2.MR(CN)-MR(MN).query:">
The MR query the LM database
and use the result to tunnel the packet
to the MR serving the MN.
In order words,
the MR pulls the needed internetwork location information
from the LM server.
There will be a delay
owing to the time taken
to send this query and to receive the reply.
Optionally, before receiving the reply,
the first packet or the first few packets may be forwarded
using mip or pmip.
Then the first packet may incur a triangle route
rather than to wait for the query reply.
After receiving the reply,
the packet will be tunneled to the MR(MN).
The result may be cached for forwarding subsequent packets.
<vspace blankLines="1" />
</t>
<t hangText="RS2.MR(CN)-MR(MN).push:">
The MR routes the first packet to the home network
using the existing MIP or PMIP mechanism.
It will then be intercepted by the MR of the MN
which, with the help of LM,
knows whether the MN has moved to a different network
and use the mapping in LM
to tunnel the packet to the MR of the MN.
Then the MR of the MN will inform MR of the CN
to tunnel the packet directly to the MR of the MN in future.
In order words,
after MR(CN) has forwarded the first packet to MR(MN),
the MR(MN) is triggered to push the location information
to MR(CN).
The MR of the CN may keep this information
in its cache memory for forwarding subsequent packets.
</t>
</list>
</t>
<t>
In the final segment RS3.MR(MN)-MN,
the MR may keep track of the location of MN
and route to it
using its intra-network mobility management mechanism.
</t>
<t>
Different designs using the above architecture
can be made by taking different combinations
of the different designs in the different route segments.
For example, the overall design of DMM may be:
<vspace blankLines="1" />
<list style="numbers">
<t>
RS1.CN-MR(CN).anycast followed by RS2.MR(CN)-MR(MN).query:
<vspace blankLines="1" />
</t>
<t>
RS1.CN-MR(CN).anycast followed by RS2.MR(CN)-MR(MN).push:
<vspace blankLines="1" />
An example is [Paper-Distributed.Mobility.PMIP] which is explained for network-based mobile IP but is also applicable to host-based mobile IP.
<vspace blankLines="1" />
</t>
<t>
RS1.CN-MR(CN).gw/ar followed by RS2.MR(CN)-MR(MN).query:
<vspace blankLines="1" />
An example is in [I-D.dmm-pmip-based]
in which
the MR function is co-located at the MAG
which is usually at the access router.
Here, when CN is also a MN using PMIP,
the packet sent from it naturally goes to the access router
which takes the logical function of MR
so that it will query the LM, which resides in the LMA.
It then uses the query result to tunnel the packet to the MR(MN),
which resides in the AR/MAG of the destination MN.
The signaling flow and other details
are described in the referenced draft.
<vspace blankLines="1" />
Another example is in [Paper-PMIP.dmc].
In the signal driven approach,
the MR is co-located the access router,
which is considered as an extension of MAG.
The MR, i.e., the extended MAG, serving the CN
queries the LM and cache the result
so that it can tunnel packets
to the MR serving the destination MN.
<vspace blankLines="1" />
[I-D.dmm-nat-phl] also colocates the MR
at the gateways.
The gateway which serves
the network of transmitting node
and where the MR is colocated
is called the Ingress router,
whereas that at the network of the MN
at the receiving side
is called egress router.
Instead of tunneling between these 2 gateways,
header rewrite using NAT is used
to forward the packet
through the internetwork route segment.
<vspace blankLines="1" />
</t>
<t>
RS1.CN-MR(CN).gw/ar followed by RS2.MR(CN)-MR(MN).push:
<vspace blankLines="1" />
Another example will be described in the next Section.
</t>
</list>
</t>
</section>
<section title="Co-locating MR at gateway or access router">
<t>
The mechanism of co-locating MR at the gateway
and routing the first packet to the home network
using existing MIP/PMIP mechanism
is explained further here.
</t>
<t>
Figure 6. shows the mapping hierarchy
of the location information from LM1 to GW
and then to access router (AR).
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network2 Network3
+---+ +---+ +---+
|LM1|Binding |LM3| |LM2|
+---+HoA11:GW3 +---+ +---+
|\\ /|\ //|
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \/ | \/ / |
| \ / \ | / \ / |
| \ / \ | / \ / |
| \/ \|/ \/ |
| /\ /|\ /\ |
| / \ / | \ / \ |
| / \ / | \ / \ |
| / /\ | /\ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
|// \|/ \\|
+---+ +---+ +---+
|MR1| |MR3| |MR2|
|GW1| |GW3| |GW2|
+---+ +---+ +---+
| /|Binding |
| / |HoA11:AR32 |
| / | |
| / | |
| / | |
AR11 AR31 AR32 AR21
. | | |
. | | |
HoA11 MN31 MN11 CN21
]]></artwork>
<postamble></postamble>
</figure>
<t>
Figure 6. Hierarchy of location management information.
</t>
<t>
When the first packet is sent from a correspondent node CN21
to the home address HoA11 of the mobile node MN11,
it first arrives at GW2.
GW2 does not find any location information of the MN
and therefore sends the packet to GW1
in accordance with routing table with the IP prefix of HoA11.
If the MN is in the network served by GW1,
the packet will be forwarded to MN11.
In this case shown in the figure,
MN11 has moved to the network served by GW3,
and LM1 contains the binding of HoA11 to the IP address of GW3.
GW1 therefore tunnels the packet to GW3.
GW3 contains the binding HoA to AR32
and therefore tunnels the packet to AR32
which in turn delivers the packet to MN11.
</t>
<t>
Meanwhile based on the source IP address of the packet,
GW1 finds out that the packet had come from GW2.
It informs GW2 to cache the binding HoA11 to GW3.
When subsequent packets to MN11 reach GW2,
GW2 finds out from its cache memory this binding
so that it will tunnel these subsequent packets
directly to GW3 (Figure 7. ).
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network2 Network3
+---+ +---+ +---+
|LM1|Binding |LM3| |LM2|
+---+HoA11:GW3 +---+ +---+
|\\ /|\ //|
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \/ | \/ / |
| \ / \ | / \ / |
| \ / \ | / \ / |
| \/ \|/ \/ |
| /\ /|\ /\ |
| / \ / | \ / \ |
| / \ / | \ / \ |
| / /\ | /\ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
|// \|/ \\|
+---+ +---+ +---+
|MR1| |MR3|<=============|MR2|
|GW1| |GW3|Binding |GW2|Cache
+---+ +---+HoA11:AR32 +---+HoA11:GW3
| /| |\
| / | | \
| / | | \
| / | | \
| / v | \
AR11 AR31 AR32 AR21 AR22
. | | ^ ^ ^
. | | / | |
. | v / | |
HoA11 MN31 MN11 CN20 CN21 CN22
]]></artwork>
<postamble></postamble>
</figure>
<t>
Figure 7. Subsequent packets destined to HoA11 via GW2.
</t>
<t>
Note that if packets sent to HoA11
from other CNs (CN22 and CN20 in Figure 7) reaches GW2,
GW2 will also use this binding in its cache memory
to tunnel the packet to GW3.
Finally, this cache at GW2 will timeout
when no more such packets are reaching GW2.
</t>
<t>
This session has used the colocation at the gateway router
as an example,
while noting that the colocation
can also be at the access router
and also that the gateway and the access router
may merge in a flattened network.
When the MR is colocated at the access router,
Figure 6 is modified as shown in Figure 8.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network2 Network3
+---+ +---+ +---+
|LM1|Binding |LM3| |LM2|
+---+HoA11:AR3 +---+ +---+
|\\ /|\ //|
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \/ | \/ / |
| \ / \ | / \ / |
| \ / \ | / \ / |
| \/ \|/ \/ |
| /\ /|\ /\ |
| / \ / | \ / \ |
| / \ / | \ / \ |
| / /\ | /\ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
|// \|/ \\|
+---+ +---+ +---+
|MR1| |MR3| |MR2|
|AR1| |AR3| |AR2|
+---+ +---+ +---+
. /|HoA11:link addr |
. / | |
. / | |
. / | |
. / | |
HoA11 MN31 MN11 CN21
]]></artwork>
<postamble></postamble>
</figure>
<t>
Figure 8. Location management information.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network2 Network3
+---+ +---+ +---+
|LM1|Binding |LM3| |LM2|
+---+HoA11:AR3 +---+ +---+
|\\ /|\ //|
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \/ | \/ / |
| \ / \ | / \ / |
| \ / \ | / \ / |
| \/ \|/ \/ |
| /\ /|\ /\ |
| / \ / | \ / \ |
| / \ / | \ / \ |
| / /\ | /\ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
|// \|/ \\|
+---+ +---+ +---+
|MR1| |MR3|<=============|MR2|
|AR1| |AR3| |AR2|Cache
+---+ +---+ +---+HoA11:AR3
. / |HoA11:link addr ^ ^ ^
. / | / | \
. / | / | \
. / v / | \
HoA11 MN31 MN11 CN20 CN21 CN22
]]></artwork>
<postamble></postamble>
</figure>
<t>
Figure 9. Subsequent packets destined to HoA11 via AR2.
</t>
</section>
<section anchor="security" title="Security Considerations">
<t>TBD</t>
</section>
<section title="IANA Considerations">
<t>None</t>
</section>
<section title="Acknowledgments">
<t>
This document has benefited from discussions with
Frank Xia, Justin Xiang, Hanan Ahmed, and others.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
</references>
<references title="Informative References">
<?rfc include="reference.RFC.6275" ?>
<?rfc include="reference.RFC.5213" ?>
<?rfc include="reference.RFC.5380" ?>
<reference anchor="I-D.dmm-scenario">
<front>
<title>Use case scenarios for Distributed Mobility Management</title>
<author initials="H" surname="Yokota" fullname="Hidetoshi Yokota">
<organization />
</author>
<author initials="P" surname="Seite" fullname="Pierrick Seite">
<organization />
</author>
<author initials="E" surname="Demaria" fullname="Elena Demaria">
<organization />
</author>
<author initials="Z" surname="Cao" fullname="Zhen Cao">
<organization />
</author>
<date month="October" year="2010" />
</front>
<seriesInfo name="Internet-Draft" value="draft-yokota-dmm-scenario-00" />
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-yokota-dmm-scenario-00.txt" />
</reference>
<reference anchor="I-D.distributed-lma">
<front>
<title>Distributed Local Mobility Anchors</title>
<author initials="H" surname="Chan" fullname="H Anthony Chan">
<organization>Huawei Technologies</organization>
</author>
<author initials="F" surname="Xia" fullname="Frank Xia">
<organization>Huawei Technologies</organization>
</author>
<author initials="J" surname="Xiang" fullname="Justin Xiang">
<organization>Huawei Technologies</organization>
</author>
<author initials="H" surname="Ahmed" fullname="Hanan Ahmed">
<organization>Huawei Technologies</organization>
</author>
<date month="March" year="2010" />
</front>
<seriesInfo name="Internet-Draft" value="draft-chan-netext-distributed-lma-03" />
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-chan-netext-distributed-lma-03.txt" />
</reference>
<reference anchor="I-D.dmm-dma">
<front>
<title>Distributed Mobility Anchoring</title>
<author initials="P" surname="Seite" fullname="Pierrick Seite">
<organization>France Telecom - Orange</organization>
</author>
<author initials="P" surname="Bertin" fullname="Philippe Bertin">
<organization>France Telecom - Orange</organization>
</author>
<date month="February" year="2012" />
</front>
<seriesInfo name="Internet-Draft" value="draft-seite-dmm-dma-00" />
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-seite-dmm-dma-00.txt" />
</reference>
<reference anchor="I-D.dmm-nat-phl">
<front>
<title>Per-Host Locators for Distributed Mobility Management</title>
<author initials="M" surname="Liebsch" fullname="M. Liebsch">
<organization>NEC</organization>
</author>
<date month="October" year="2011" />
</front>
<seriesInfo name="Internet-Draft" value="draft-liebsch-mext-dmm-nat-phl-00" />
<format type="TXT" target="http://www.ietf.org/internet-draft-liebsch-mext-dmm-nat-phl-00.txt" />
</reference>
<reference anchor="I-D.dmm-armip">
<front>
<title>An AR-level solution support for Distributed Mobility Management</title>
<author initials="Z" surname="Ma" fullname="Zhengming Ma">
<organization>Sun Yat-Sen University</organization>
</author>
<author initials="X" surname="Zhang" fullname="Xun Zhang">
<organization>Sun Yat-Sen University</organization>
</author>
<date month="February" year="2012" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ma-dmm-armip-00" />
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ma-dmm-armip-00.txt" />
</reference>
<reference anchor="I-D.dmm-pmip-based">
<front>
<title>PMIP Based Distributed Mobility Management Approach</title>
<author initials="D" surname="Liu" fullname="Dapeng Liu">
<organization>China Mobile</organization>
</author>
<author initials="J" surname="Song">
<organization>ZTE</organization>
</author>
<author initials="W" surname="Luo">
<organization>ZTE</organization>
</author>
<date month="December" year="2011" />
</front>
<seriesInfo name="Internet-Draft" value="draft-liu-dmm-pmip-based-approach-01" />
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-liu-dmm-pmip-based-approach-01.txt" />
</reference>
<reference anchor="I-D.dmm-pmip">
<front>
<title>A PMIPv6-based solution
for Distributed Mobility Management</title>
<author initials="CJ" surname="Bernardos" fullname="CJ Bernardos">
<organization>UC3M</organization>
</author>
<author initials="A" surname="de la Oliva" fullname="A. de la Oliva">
<organization>UC3M</organization>
</author>
<author initials="F" surname="Giust" fullname="F Giust">
<organization>IMDEA Networks and UC3M</organization>
</author>
<author initials="T" surname="Melia" fullname="T Melia">
<organization>Alcatel-Lucent</organization>
</author>
<date month="January" year="2012" />
</front>
<seriesInfo name="Internet-Draft" value="draft-bernardos-dmm-pmip-00" />
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-bernardos-dmm-pmip-00.txt" />
</reference>
<reference anchor="I-D.dmm-approaches">
<front>
<title>Approaches to Distributed mobility management using Mobile IPv6 and its extensions</title>
<author initials="B" surname="Patil, Ed." fullname="Basavaraj Patil">
<organization>Nokia</organization>
</author>
<author initials="C" surname="Williams" fullname="Carl Williams">
<organization>MCSR Labs</organization>
</author>
<author initials="J" surname="Korhonen" fullname="Jouni Korhonen">
<organization>Nokia Siemens Networks</organization>
</author>
<date month="October" year="2011" />
</front>
<seriesInfo name="Internet-Draft" value="draft-patil-mext-dmm-approaches-02" />
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-patil-mext-dmm-approaches-02.txt" />
</reference>
<reference anchor="I-D.PMIP-dmc">
<front>
<title>Use of Proxy Mobile IPv6 for Distributed Mobility Control</title>
<author initials="S" surname="Koh" fullname="Seok Joo Koh">
<organization />
</author>
<author initials="J" surname="Kim" fullname="Ji In Kim">
<organization />
</author>
<author initials="H" surname="Jung" fullname="Hee Young Jung">
<organization />
</author>
<author initials="Y" surname="Han" fullname="Youn-Hee Han">
<organization />
</author>
<date month="March" year="2011" />
</front>
<seriesInfo name="Internet-Draft" value="draft-sjkoh-mext-pmip-dmc-01" />
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-sjkoh-mext-pmip-dmc-01.txt" />
</reference>
<reference anchor="Paper-Distributed.Dynamic.Mobility">
<front>
<title>A Distributed Dynamic Mobility Management Scheme Designed for Flat IP Architectures</title>
<author initials="P" surname="Bertin">
<organization />
</author>
<author initials="S" surname="Bonjour">
<organization />
</author>
<author initials="J-M" surname="Bonnin">
<organization />
</author>
<date year="2008" />
</front>
<seriesInfo name="" value="Proceedings of 3rd International Conference on New Technologies, Mobility and Security (NTMS)" />
</reference>
<reference anchor="Paper-Net.based.DMM">
<front>
<title>A network-based localized mobility solution
for Distributed Mobility Management</title>
<author initials="F" surname="Giust" fullname="F Giust">
<organization>IMDEA Networks and UC3M</organization>
</author>
<author initials="A" surname="de la Oliva" fullname="A. de la Oliva">
<organization>UC3M</organization>
</author>
<author initials="CJ" surname="Bernardos" fullname="CJ Bernardos">
<organization>UC3M</organization>
</author>
<author initials="R.P.F." surname="Da Costa" fullname="R.P.F. Da Costa">
<organization>UC3M</organization>
</author>
<date month="October" year="2011" />
</front>
<seriesInfo name="" value="Proceedings of 14th International Symposium on Wireless Personal Multimedia Communications (WPMC)" />
</reference>
<reference anchor="Paper-Distributed.Centralized.Mobility">
<front>
<title>Distributed or Centralized Mobility?</title>
<author initials="P" surname="Bertin">
<organization />
</author>
<author initials="S" surname="Bonjour">
<organization />
</author>
<author initials="J-M" surname="Bonnin">
<organization />
</author>
<date month="December" year="2009" />
</front>
<seriesInfo name="" value="Proceedings of Global Communications Conference (GlobeCom)" />
</reference>
<reference anchor="Paper-Migrating.Home.Agents">
<front>
<title>Migrating Home Agents Towards Internet-scale Mobility Deployments</title>
<author initials="R" surname="Wakikawa">
<organization />
</author>
<author initials="G" surname="Valadon">
<organization />
</author>
<author initials="J" surname="Murai">
<organization />
</author>
<date month="December" year="2006" />
</front>
<seriesInfo name="" value="Proceedings of the ACM 2nd CoNEXT Conference on Future Networking Technologies" />
</reference>
<reference anchor="Paper-Distributed.Mobility.Review">
<front>
<title>Distributed and Dynamic Mobility Management in Mobile Internet: Current Approaches and Issues</title>
<author initials="H" surname="Chan">
<organization />
</author>
<author initials="H" surname="Yokota">
<organization />
</author>
<author initials="J" surname="Xie">
<organization />
</author>
<author initials="P" surname="Seite">
<organization />
</author>
<author initials="D" surname="Liu">
<organization />
</author>
<date month="February" year="2011" />
</front>
</reference>
<reference anchor="Paper-Distributed.Mobility.PMIP">
<front>
<title>Proxy Mobile IP with Distributed Mobility Anchors</title>
<author initials="H" surname="Chan">
<organization />
</author>
<date month="December" year="2010" />
</front>
<seriesInfo name="" value="Proceedings of GlobeCom Workshop on Seamless Wireless Mobility" />
</reference>
<reference anchor="Paper-Distributed.Mobility.Management">
<front>
<title>Distributed Mobility Management with Mobile IP</title>
<author initials="H" surname="Chan">
<organization />
</author>
<date month="June" year="2012" />
</front>
<seriesInfo name="" value="Proceedings of IEEE ICC 2012 Workshop on Telecommunications: from Research to Standards" />
</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="Paper-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 05:27:25 |