One document matched: draft-chan-dmm-framework-gap-analysis-02.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-framework-gap-analysis-02">
<front>
<title abbrev="DMM-framework-gap-analysis">
A unified mobility management protocol framework and DMM gap analysis
</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="July" year="2012"></date>
<area></area>
<workgroup></workgroup>
<abstract>
<t>
This draft proposes a unified framework
of mobility management
in terms of abstracted logical functions.
It is shown that mip, pmip, and several of their extensions
can be expressed in terms of different configurations
of these logical functions.
Such a unified framework provides a convenient view
on gap analysis of existing protocols,
and also on the needed re-configurations of the logical functions
as well as the needed extensions towards distributed mobility management.
</t>
</abstract>
</front>
<middle>
<!-- Introduction -->
<section anchor="intro" title="Introduction">
<t>
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 with extensions.
A requirement in distributed mobility management
is to first use existing protocols and their extensions
before considering new protocol design.
</t>
<t>
Mobile IP
<xref target="RFC6275"/>
,
which has primarily been deployed in a centralized manner
for the hierarchical mobile networks,
has numerous variants and extensions
including PMIP
<xref target="RFC5213"/>
, hierarchical MIP (HMIP)
<xref target="RFC5380"/>
, Fast MIP (FMIP)
<xref target="RFC4068"/>
<xref target="RFC4988"/>
, Proxy-based FMIP (PFMIP)
<xref target="RFC5949"/>
and more.
These different modifications or extensions of MIP
have been developed over the years
owing to the different needs that are found afterwards.
</t>
<t>
It is convenient to abstract the functions of existing mobility management protocols in terms of logical functions.
Different variants of existing mobility management protocols are then
different design variations of how the logical functions are configured.
The result is a convenient framework
to perform gap analysis of the existing protocols,
and to reconfigure these logical functions
towards various distributed mobility management designs.
</t>
<section title="Overview">
<t>
Section 3 proposes
to abstract the existing mobility management protocols functions
into the logical functions of home address allocation,
mobility routing,
location management,
and proxy.
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.
</t>
<t>
Section 4 shows that the logical functions
can indeed perform the same functions
as the major existing mobility protocols.
These functions therefore enables a unified framework
upon which
different designs of distributed mobility may be constructed.
</t>
<t>
Section 5 presents the gap analysis of the existing protocols
by comparing them against the DMM requirements
of first taking advantage of existing protocols,
compatibility,
distributed deployment,
dynamically providing mobility support,
route optimization, IPv6 deployment,
and security considerations.
</t>
<t>
Extensions to overcome the gaps are illustrated in Sections 6-8.
With the unified framework,
extensions to dynamically provide mobility support is described in Section 6
where the home IP address of an MN is generalized to that of an application session.
A distributed database architecture is described in Section 7.
Using this distributed architecture,
various route optimization can be achieved as is described in Section 8.
</t>
</section>
</section>
<!-- 2 Conventions and definitions -->
<section title="Conventions and Terminology">
<!-- 2.1 Conventions -->
<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>
<!-- 2.2 Definitions -->
<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.
<vspace blankLines="1" />
</t>
<t hangText='Home address allocation'>
is the logical function
to allocate the home network prefix
or home address to a mobile node.
<vspace blankLines="1" />
</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.
<vspace blankLines="1" />
Optionally, one (or more) proxy may exist between LM and MN
so that the LM function is maintained in the hierarchy LM-proxy-MN.
Then to the LM, the proxy behaves like the MN;
to the MN, the proxy behaves like the LM.
<vspace blankLines="1" />
</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.
<vspace blankLines="1" />
</t>
</list>
</t>
</section>
</section>
<!-- 3 Logical functions -->
<section title="Logical functions of mobility management">
<t>
The existing mobility management functions
of MIP, PMIP, and HMIP
may be abstracted
into the following logical functions
to provide a unified framework
of existing mobility management
and to allow a more flexible design to achieve DMM.
These logical functions are as follows:
</t>
<t>
<list style="numbers">
<t>
allocation of home network prefix or HoA
to a MN that registers with the network;
<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.
and
<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;
<vspace blankLines="1" />
(Optionally, one (or more) proxy may exist between LM and MN
so that the LM function is maintained in the hierarchy LM-proxy-MN.
Then to the LM, the proxy behaves like the MN;
to the MN, the proxy behaves like the LM.)
<vspace blankLines="1" />
</t>
</list>
</t>
</section>
<!-- 4 existing mobility protocols -->
<section title="Functional represenation of existing mobility protocols">
<t>
This section shows that
the existing mobility management protocols
can be expressed as different configurations
of the above logical functions
in a unified framework.
</t>
<!-- 4.1 MIP -->
<section title="Mobile IP">
<t>
Figure 1 shows Mobile IPv6
<xref target="RFC6275"/>
in the functional representation.
A mobile node MN11 was originally attached to the first network (Network1)
and was allocated the IP prefix for HoA11.
Now, MN11 has moved to Network3,
from which it is allocated a new IP address IP32.
LM1 keeps the binding HoA11: IP32
so that packets from CN21 in Network2
destined to HoA11 will be intercepted by MR1,
which will then tunnel the packet to IP32.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network3 Network2
+-----+
| LM1 |
+-----+
HoA1 alc IP3 alc IP2 alc
|
|
+-----+
| MR1 |
+-----+
.
. +----+ +----+ +----+
. |MN31| |MN11| |CN21|
. +----+ +----+ +----+
HoA11 IP31 IP32,
HoA11
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 1. Functional representation of Mobile IP.
</t>
</section>
<!-- 4.2 MIP and PMIP -->
<section title="MIP versus PMIP">
<t>
MIP and PMIP both employ the same concept
of separating session identifier and routing address
into the HoA and CoA respectively.
Figure 2 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>
<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 2. Network layer in the protocol stack of packets
sent from the CN and tunneled
(a) to the MN in MIP; and
(b) to the MAG in PMIP
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 in PMIP.
Therefore, the architecture using MIP
can be adapted to the architecture using PMIP
by replacing the MN with the MAG-MN combination.
</t>
<t>
Mobile IP and Proxy mobile IP
bundle all the three mobility management logical functions:
LM1, IP1 prefix allocation, and MR1
into the home agent and local mobility anchor respectively.
</t>
<t>
The functional representation of Proxy mobile IPv6
<xref target="RFC5213"/>
is shown in Figure 3.
Here MN11 is attached to the access router AR31
which has the IP address IP31 in Network3.
LM1 keeps the binding HoA11:IP31.
The access router AR31 also behaves like a home link to MN11
so that MN11 can use its original IP address HoA11.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network3 Network2
+-----+
| LM1 |
+-----+
HoA1 alc IP3 alc IP2 alc
|
|
+-----+
| MR1 |
+-----+
.
. +----+ +----+ +----+
. |AR31| |MN32| |CN21|
. +----+ +----+ +----+
HoA11 IP31 IP32
|
|
+----+
|MN11|
+----+
HoA11
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 3. Functional representation of PMIP.
</t>
</section>
<!-- 4.3 HMIP -->
<section title="Hierarchical Mobile IP">
<t>
The functional representation of Hierarchical Mobile IPv6
<xref target="RFC5380"/>
is shown in Figure 4.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network3 Network2
+-----+
| LM1 |
+-----+
HoA1 alc IP3 alc IP2 alc
|
|
+-----+ +-----+
| MR1 | | MR3 |
+-----+ +-----+
. / \
. / \
. / \
. +----+ +----+ +----+
. |AR31| |MN11| |CN21|
. +----+ +----+ +----+
HoA11 IP31 IP32,
| HoA11
|
+----+
|MN31|
+----+
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 4. Functional representation
of Hierarchical Mobile IP.
</t>
<t>
Besides the logical functions: LM1, MR1,
and HoA1 prefix allocation
in Network1 as MIP in Figure 2 and PMIP in Figure 3,
there is an MR function (MR3)
in the visited network (Network3).
The MR3 is also a proxy between LM1 and MN11
in the hierchical LM function LM1--MR3--MN11.
That is, LM1 keeps the LM binding HoA11:MR3
and MR3 keeps the LM binding HoA11:IP32.
</t>
<t>
In Figure 4,
if MN11 takes the place of MN31
which is attached to AR31,
the resulting mobility management becomes network-based.
</t>
</section>
<!-- 4.4 HAHA -->
<section title="Migrating home agents">
<t>
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
when the MN and the CN are in networks
close to each other
but are far from the anchor points.
</t>
<t>
A method to solve the triangle routing problem
is to duplicate the anchor points
in many networks
in different geographic locations
as in
[Paper-Migrating.Home.Agents].
A functional representation of Migrating Home Agents
is shown in Figure 5.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network3 Network2
+-----+ +-----+ +-----+
| LM0 |------| LM0 |------| LM0 |
+-----+ +-----+ +-----+
HoA1 alc HoA3 alc HoA2 alc
| | |
| | |
+-----+ +-----+ +-----+
| MR1 | | MR3 | | MR2 |
+-----+ +-----+ +-----+
. / \
. / \
. / \
. +----+ +----+ +----+
. |AR31| |MN11| |CN21|
. +----+ +----+ +----+
HoA11 IP31 IP32,
| HoA11
|
+----+
|MN31|
+----+
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 5. Functional representation
of Migrating Home Agents.
</t>
<t>
Here, the MR function is available in each of the three networks
Network1, Network2, and Network3?
the LM function in each network (LM0)
contains the LM information of all the networks.
Each MR in each network advertises
the HoA IP prefixes of all these networks
using anycast.
Traffic from CN21 in Network2 destined to HoA11
will therefore be intercepted by the MR nearest to CN,
which is MR2.
Using the LM information in LM0
MR2 will using the binding HoA11:IP32
to tunnel the packet to MN11.
</t>
<t>
Similarly, traffic originating from MN11
will be served by its nearest MR (MR3).
Trianle routing is therefore avoided.
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>
<t>
As before,
if MN11 in Figure 5 takes the place of MN31
which is attached to AR31,
the resulting mobility management becomes network-based.
</t>
</section>
</section>
<!-- 5 gap analysis -->
<section title="Gap analysis">
<!-- 5.1 gap analysis: existing protocols -->
<section title="Considering existing protocols first">
<t>
The fifth DMM requirement is on existing mobility protocols.
</t>
<t>
REQ5: A DMM solution SHOULD first consider reusing and extending the
existing mobility protocols before specifying new protocols.
</t>
<t>
Abstracting the existing protocol functions
into logical functions in this draft
is a way to see how one can maximize the use of existing protocols.
It remains to be seen whether all the DMM requirements can be met.
One needs to check the rest of the requirements
to check for gaps.
</t>
</section>
<!-- 5.2 gap analysis: compatibility -->
<section title="Compatibility">
<t>
The second part of the fourth DMM requirement is on compatibility:
</t>
<t>
REQ4: The DMM solution SHOULD be able to work between trusted
administrative domains when allowed by the security measures
deployed between these domains. Furthermore, the DMM solution
MUST be able to co-exist with existing network deployment and
end hosts so that the existing deployment can continue to be
supported. For example, depending on the environment in which
dmm is deployed, the dmm solutions may need to be compatible
with other existing mobility protocols that are deployed in
that environment or may need to be interoperable with the
network or the mobile hosts/routers that do not support the
dmm enabling protocol.
</t>
</section>
<!-- 5.3 gap analysis: distributed deployment -->
<section title="Distributed deployment">
<t>
The first DMM requirement is on Distributed deployment
IP mobility.
</t>
<t>REQ1:network access and routing solutions provided by
DMM MUST enable a distributed deployment of mobility
management of IP sessions so that the traffic can be routed in
an optimal manner without traversing centrally deployed
mobility anchors.
</t>
<t>
Multiple MRs are allowed in MIP
by simply having an HA for each home network.
It is illustrated in terms of the logical functions as in Figure 6.
</t>
<t>
The figure shows,
as an example, three networks.
Each network has its own IP prefix allocation function.
The mobility routing function
is distributed to multiple locations
at the MRs so that routing can be optimized.
Again, the resulting mobility management becomes network-based
if MN takes the position of MN31.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
+-----+ +-----+ +-----+
| LM1 | | LM2 | | LM3 |
+-----+ +-----+ +-----+
HoA1 alc HoA3 alc HoA2 alc
| | |
| | |
+-----+ +-----+ +-----+
| MR1 | | MR3 | | MR2 |
+-----+ +-----+ +-----+
. / \
. / \
. / \
. +----+ +----+ +----+
. |AR31| |MN11| |CN21|
. +----+ +----+ +----+
HoA11 IP31 IP32,
| HoA11
|
+----+
|MN31|
+----+
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 6. A distributed architecture
of mobility management.
</t>
</section>
<!-- 5.4 gap analysis: dynamically providing mobility support -->
<section title="Dynamically providing mobility support">
<t>
To see how to avoid traversing centralized deployed mobility anchors,
let us look at the second requirement on non-optimal routes.
</t>
<t>
REQ2: The DMM solutions MUST provide transparency above the IP layer
when needed. Such transparency is needed, when the mobile
hosts or entire mobile networks [RFC3963] change their point
of attachment to the Internet, for the application flows that
cannot cope with a change of IP address. Otherwise the
support to maintain a stable home IP address or prefix during
handover may be declined.
</t>
<t>
In order to avoid traversing long routes
after the MN has moved to a new network,
the new network can simply be used
as the home network for new sessions.
The sessions that had already started in the previous network
would still need to use the original network
in which the session had started
as the home network.
There may then be different IP sessions
using different IP prefixes/addresses in the same MN.
</t>
<t>
The capability to use different IP addresses for different IP sessions
are therefore needed.
</t>
<t>
The assoication with the HoA of a MN
is not sufficient to support the above use of IP for an application.
This gap can be overcome by generalizing the concept of
the HoA of the MN
to the HoA of an application running on the MN
as will be discussed in Section 7.1 below.
</t>
<t>
Using the dynamic mobility management scheme
has avoided routing back to the home network
when the application does not have such need.
There are however application sessions
that had originated from a prior network
and that also requires mobility support.
Longer routes than the natural IP route can be encountered.
Route optimization schemes already exist,
but one needs to deal with multiple HA's
when using multiple HA's.
</t>
</section>
<!-- 5.5 gap analysis: route optimization -->
<section title="Route optimization">
<t>
One generalization in terms of the unified framework
is that the LM functions can be considered
as a distributed database as will be shown in the next section.
There, the MN and the LM has a client-server relationship,
with optionally a proxy in between
and the proxy which can co-locate with an MR.
A distributed database
may have different servers to store different data.
The data in each server need not be pushed to all the other servers
but the database system only needs to know
which data resides in which server.
In addition, each client needs to be able to query the database.
</t>
<t>
The existing functions such as BU and BA can be considered
as the database function to update a record.
Completing the design of messages of the database functions
will enable the distributed database design.
</t>
<t>
In the unified scheme
complete with database function and mobility routing function,
numerous route optimizations can be designed as described in Section 8.
</t>
</section>
<!-- 5.6 gap analysis: IPv6 deployment -->
<section title="IPv6 deployment">
<t>
The third DMM requirement on IPv6 deployment
</t>
<t>
REQ3: The DMM solutions SHOULD target IPv6 as primary deployment and
SHOULD NOT be tailored specifically to support IPv4, in
particular in situations where private IPv4 addresses and/or
NATs are used.
</t>
<t>
is not an issue with the MIPv6, PMIPv6 and their extensions.
Using the unified scheme here based on abstracting
these existing protocol functions
will meet the DMM requirements.
</t>
</section>
<!-- 5.7 gap analysis: security considerations -->
<section title="Security">
<t>
The first part of the fourth requirement
as well as the sixth DMM requirement are on security considerations.
</t>
<t>
REQ6: The protocol solutions for DMM MUST consider security, for
example authentication and authorization mechanisms that allow
a legitimate mobile host/router to access to the DMM service,
protection of signaling messages of the protocol solutions in
terms of authentication, data integrity, and data
confidentiality, opti-in or opt-out data confidentiality to
signaling messages depending on network environments or user
requirements.
</t>
<t>
are on security.
It is preferred that these security requirements
be considered as an integral part of the DMM design.
</t>
</section>
</section>
<!-- 6. Dynamic mobility management -->
<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>
The architecture with multiple mobility routing functions
compared with a centralized approach
is more convenient to achieve dynamic mobility management.
In Figure 6 above,
the LM function and the IP address allocation function
may co-locate.
The device MN11 originally attached to the first network (Network1)
may simply be using a dynamic IP address HoA11
which is leased from Network1
with a finite lifetime of say 24 hours.
As MN11 leaves the first network
and attaches to the third network (Network3),
it acquires a new IP address IP33 from Network3.
MN11 may or may not have ongoing sessions
requiring session continuity.
If it does not,
there is no need for LM1 to keep a binding
for the home address HoA11 of MN11.
If it does,
it may use the existing MIP signaling mechanism
so that the LM1 will keep the binding HoA11:MR3.
MR3 in turn will keep the binding HoA11:IP33.
Such a hierchy of binding
with MR3 acting as the proxy location maintenance function
between LM1 and MN11
will also cause MR3 to act as a proxy mobility routing function
between MR1 and MN11
so that packets destined to MR1 will be redirected to MR3.
</t>
<t>
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>
<t>
More details on dynamically providing mobility support are found in
[ID.seite-dmm-dma],
[ID.liu-dmm-dynamic-anchor-discussion],
[ID.bernardos-dmm-pmip],
[I-D.ma-dmm-armip],
and
[ID.sarikaya-dmm-dmipv6].
</t>
<t>
[I-D.seite-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.seite-dmm-dma],
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>
[ID.sarikaya-dmm-dmipv6] also described dynamic mobility management
for a flattened network, with separate data plane and control plane.
The needed authentication is also described.
</t>
<t>
[ID.bernardos-dmm-pmip] co-locates the home prefix allocation function
and the mobility routing function at the access router,
which is then named Mobility Anchor and Access Router (MAAR) in that draft.
The LM function is centralized and is named Central Mobility Database (CMD).
</t>
<t>
[I-D.ma-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>
[ID.liu-dmm-dynamic-anchor-discussion]
describes the gaps and extensions
needed to accomplish dynamic mobility management.
</t>
<!-- 6.1 Home network of an application session -->
<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>
<!-- 7. Multiple MRs and distributed database -->
<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 described in this draft
is mainly on separating the data plane and the control plane.
</t>
<t>
Figure 7 shows an architecture of DMM
with an example of the same three networks in Figure 6.
As is in Figure 6,
each network in Figure 7 has its own IP prefix allocation function.
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.
In addition to these features in Figure 6,
the LM function in Figure 7 is a distributed database,
with multiple servers,
of the mapping of HoA to CoA.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network3 Network2
+-----+ +-----+ +-----+
| LM1 | | LM3 | | LM2 |
+-----+ +-----+ +-----+
HoA1 alc HoA3 alc HoA2 alc
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \/ | \/ / |
| \ / \ | / \ / |
| \/ \|/ \/ |
| /\ /|\ /\ |
| / \ / | \ / \ |
| / /\ | /\ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
+-----+ +-----+ +-----+
| MR1 |------| MR3 |------| MR2 |
+-----+ +-----+ +-----+
. / \
. / \
. / \
. +----+ +----+ +----+
. |AR31| |MN11| |CN21|
. +----+ +----+ +----+
HoA11 IP31 IP32,
| HoA11
|
+----+
|MN31|
+----+
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 7. 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.
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>
<!-- 8. Route optimization -->
<section title="Route optimization mechanisms">
<t>
The distributed architecture has already enabled
dynamic mobility management,
as is described in [I-D.seite-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.luo-dmm-pmip-based-dmm-approach]
or [I-D.liu-dmm-pmip-based-dmm-approach]
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 [I-D.jikim-dmm-pmip].
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 is described in
[Paper-Distributed.Mobility.Management].
</t>
</list>
</t>
</section>
<section anchor="security" title="Security Considerations">
<t>TBD</t>
</section>
<section title="IANA Considerations">
<t>None</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" ?>
<?rfc include="reference.RFC.5949" ?>
<?rfc include="reference.RFC.4068" ?>
<?rfc include="reference.RFC.4988" ?>
<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.seite-dmm-dma">
<front>
<title>Distributed Mobility Anchoring</title>
<author fullname="Pierrick Seite" surname="Seite" initials="P">
<organization/> </author>
<author fullname="Philippe Bertin" surname="Bertin" initials="P">
<organization/> </author>
<date year="2012" day="3" month="February"/>
</front>
<seriesInfo value="draft-seite-dmm-dma-00" name="Internet-Draft"/>
<format target="http://www.ietf.org/internet-drafts/draft-seite-dmm-dma-00.txt" type="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.ma-dmm-armip">
<front>
<title>An AR-level solution support for Distributed Mobility Management</title>
<author fullname="Zhengming Ma" surname="Ma" initials="Z">
<organization/> </author>
<author fullname="Xun Zhang" surname="Zhang" initials="X">
<organization/> </author>
<date year="2012" day="22" month="February"/>
</front>
<seriesInfo value="draft-ma-dmm-armip-00" name="Internet-Draft"/>
<format target="http://www.ietf.org/internet-drafts/draft-ma-dmm-armip-00.txt" type="TXT"/>
</reference>
<reference anchor="I-D.liu-dmm-pmip-based-approach">
<front>
<title>PMIP Based DMM Approaches</title>
<author fullname="Dapeng Liu" surname="Liu" initials="D">
<organization/> </author>
<author fullname="Jun Song" surname="Song" initials="J">
<organization/> </author>
<author fullname="Wen Luo" surname="Luo" initials="W">
<organization/> </author>
<date year="2012" day="12" month="March"/>
</front>
<seriesInfo value="draft-liu-dmm-pmip-based-approach-02" name="Internet-Draft"/>
<format target="http://www.ietf.org/internet-drafts/draft-liu-dmm-pmip-based-approach-02.txt" type="TXT"/>
</reference>
<reference anchor="I-D.luo-dmm-pmip-based-dmm-approach">
<front>
<title>PMIP Based DMM Approaches</title>
<author fullname="Wen Luo" surname="Luo" initials="W">
<organization/> </author>
<author fullname="Juan Liu" surname="Liu" initials="J">
<organization/> </author>
<date year="2012" day="8" month="March"/>
</front>
<seriesInfo value="draft-luo-dmm-pmip-based-dmm-approach-01" name="Internet-Draft"/>
<format target="http://www.ietf.org/internet-drafts/draft-luo-dmm-pmip-based-dmm-approach-01.txt" type="TXT"/>
</reference>
<reference anchor="I-D.bernardos-dmm-pmip">
<front>
<title>A PMIPv6-based solution for Distributed Mobility Management</title>
<author fullname="Carlos Bernardos" surname="Bernardos" initials="C">
<organization/> </author>
<author fullname="Antonio de la Oliva" surname="Oliva" initials="A">
<organization/> </author>
<author fullname="Fabio Giust" surname="Giust" initials="F">
<organization/> </author>
<author fullname="Telemaco Melia" surname="Melia" initials="T">
<organization/> </author>
<author fullname="Rui Costa" surname="Costa" initials="R">
<organization/> </author>
<date year="2012" day="12" month="March"/>
</front>
<seriesInfo value="draft-bernardos-dmm-pmip-01" name="Internet-Draft"/>
<format target="http://www.ietf.org/internet-drafts/draft-bernardos-dmm-pmip-01.txt" type="TXT"/>
</reference>
<reference anchor="I-D.sarikaya-dmm-dmipv6">
<front>
<title>Distributed Mobile IPv6</title>
<author fullname="Behcet Sarikaya" surname="Sarikaya" initials="B">
<organization/> </author>
<date year="2012" day="1" month="February"/>
</front>
<seriesInfo value="draft-sarikaya-dmm-dmipv6-00" name="Internet-Draft"/>
<format target="http://www.ietf.org/internet-drafts/draft-sarikaya-dmm-dmipv6-00.txt" type="TXT"/>
</reference>
<reference anchor="I-D.liu-dmm-dynamic-anchor-discussion">
<front>
<title>DMM Dynamic Anchor Discussion</title>
<author fullname="Dapeng Liu" surname="Liu" initials="D">
<organization/> </author>
<author fullname="Hui Deng" surname="Deng" initials="H">
<organization/> </author>
<author fullname="Wen Luo" surname="Luo" initials="W">
<organization/> </author>
<date year="2012" day="4" month="March"/>
</front>
<seriesInfo value="draft-liu-dmm-dynamic-anchor-discussion-00" name="Internet-Draft"/>
<format target="http://www.ietf.org/internet-drafts/draft-liu-dmm-dynamic-anchor-discussion-00.txt" type="TXT"/>
</reference>
<reference anchor="I-D.patil-dmm-issues-and-approaches2dmm">
<front>
<title>Approaches to Distributed mobility management using Mobile IPv6 and its extensions</title>
<author fullname="Basavaraj Patil" surname="Patil" initials="B">
<organization/> </author>
<author fullname="Carl Williams" surname="Williams" initials="C">
<organization/> </author>
<author fullname="Jouni Korhonen" surname="Korhonen" initials="J">
<organization/> </author>
<date year="2012" day="5" month="March"/>
</front>
<seriesInfo value="draft-patil-dmm-issues-and-approaches2dmm-00" name="Internet-Draft"/>
<format target="http://www.ietf.org/internet-drafts/draft-patil-dmm-issues-and-approaches2dmm-00.txt" type="TXT"/>
</reference>
<reference anchor="I-D.xue-dmm-routing-optimization">
<front>
<title>Routing optimization in DMM</title>
<author fullname="Kaiping Xue" surname="Xue" initials="K">
<organization/> </author>
<author fullname="Lin Li" surname="Li" initials="L">
<organization/> </author>
<author fullname="Peilin Hong" surname="Hong" initials="P">
<organization/> </author>
<author fullname="Pete McCann" surname="McCann" initials="P">
<organization/> </author>
<date year="2012" day="30" month="June"/>
</front>
<seriesInfo value="draft-xue-dmm-routing-optimization-00" name="Internet-Draft"/>
<format target="http://www.ietf.org/internet-drafts/draft-xue-dmm-routing-optimization-00.txt" type="TXT"/>
</reference>
<reference anchor="I-D.jikim-dmm-pmip">
<front>
<title>Use of Proxy Mobile IPv6 for Distributed Mobility Management</title> <author fullname="Ji Kim" surname="Kim" initials="J">
<organization/> </author>
<author fullname="Seok Koh" surname="Koh" initials="S">
<organization/> </author>
<author fullname="Hee Jung" surname="Jung" initials="H">
<organization/> </author>
<author fullname="Youn-Hee Han" surname="Han" initials="Y">
<organization/> </author>
<date year="2012" day="4" month="March"/>
</front>
<seriesInfo value="draft-jikim-dmm-pmip-00" name="Internet-Draft"/>
<format target="http://www.ietf.org/internet-drafts/draft-jikim-dmm-pmip-00.txt" type="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 fullname="Fabio Giust" surname="Giust" initials="F">
<organization>IMDEA Networks and UC3M</organization>
</author>
<author fullname="Antonio De La Oliva" surname="de la Oliva" initials="A">
<organization>UC3M</organization>
</author>
<author fullname="Carlos J Bernardos" surname="Bernardos" initials="CJ">
<organization>UC3M</organization>
</author>
<author fullname="Rui Pedro Ferreira Da Costa" surname="Da Costa" initials="RPF">
<organization>Alcatel-Lucent Bell Labs</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 08:15:39 |