One document matched: draft-chan-dmm-framework-gap-analysis-04.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-04">
<front>
<title abbrev="DMM-framework-gap-analysis">
Framework for Mobility Management Protocol 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>
<author initials="P" surname="Seite" fullname="Pierrick Seite">
<organization>France Telecom - Orange</organization>
<address>
<postal>
<street>4, rue du Clos Courtel, BP 91226, Cesson-Sevigne 35512, France</street>
<street>Email: pierrick.seite@orange-ftgroup.com</street>
</postal>
</address>
</author>
<author initials="K" surname="Pentikousis" fullname="Kostas Pentikousis">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Carnotstr. 4 10587 Berlin, Germany</street>
<street>Email: k.pentikousis@huawei.com</street>
</postal>
</address>
</author>
<author initials="JH" surname="Lee" fullname="Jong-Hyouk Lee">
<organization>Telecom Bretagne</organization>
<address>
<postal>
<street>RSM Department, Telecom Bretagne, Cesson-Sevigne, 35512, France</street>
<street>Email: jh.lee@telecom-bretagne.eu</street>
</postal>
</address>
</author>
<date month="October" year="2012"></date>
<area></area>
<workgroup></workgroup>
<abstract>
<t>
This document introduces a framework
for analyzing mobility management protocols
in terms of their key abstracted logical functions.
The framework is capable of presenting a unified view,
reducing the clutter that obscures a casual reader
from understanding the commonalities
between different approaches in mobility management.
More importantly,
a first order application of this framework
allows us to examine
previously standardized mobility management protocols,
such as MIPv6 and PMIPv6
(as well as several of their extensions),
and describe their core functionality
in terms of different configurations
of the logical functions defined by the framework.
As a result,
we can use the framework
to analyze the gaps between the protocols
needed in a distributed mobility management environment
and the functionality provided
by the current generation of mobility management protocols.
Our analysis points
to the need for a re-configuration of logical functions
identified in the framework
as well as the need for new extensions
which can make distributed mobility management possible in the future.
</t>
</abstract>
</front>
<middle>
<!-- Introduction -->
<section anchor="intro" title="Introduction">
<t>
While there is onging research on new protocols
for distributed mobility management (DMM),
it has also been proposed,
e.g., in [Paper-Distributed.Mobility.PMIP]
and in other publications,
that a distributed mobility management architecture can be designed
using primarily existing mobility management protocols with some extensions.
This is reflected in the requirement
presented in [ID-dmm-requirements]: distributed mobility management
is to first use existing protocols and their extensions
before considering new protocol designs.
</t>
<t>
Mobile IPv6
<xref target="RFC6275"/>,
which is a logically centralized mobility management approach
addressing primarily hierarchical mobile networks,
has numerous variants and extensions
including, just to name a few, PMIPv6
<xref target="RFC5213"/>,
Hierarchical MIPv6 (HMIPv6)
<xref target="RFC5380"/>,
Fast MIPv6 (FMIPv6)
<xref target="RFC4068"/>
<xref target="RFC4988"/>,
Proxy-based FMIPv6 (PFMIPv6)
<xref target="RFC5949"/>.
These variants or extensions of MIPv6
have been developed over the years
owing to the different needs that have been arising
ever since the first specification of MIP came into life.
</t>
<t>
This document argues that
we can gain much more insights into this design space
by abstracting functions of existing mobility management protocols
in terms of logical functions.
Different variants of existing mobility management protocols
can then be expressed
as different design variations
of how these logical functions are put together.
The result is a rich framework
that can express sophisticated functionalities
in a more straightforward manner
and can be used to perform gap analysis of existing protocols.
What is more,
this document shows how to reconfigure these logical functions
towards various distributed mobility management designs.
</t>
<t>
The following subsection presents an overview of this document.
</t>
<section title="Overview">
<t>
Section 3 proposes
to abstract existing mobility management protocol functions
into three logical functions, namely,
home address allocation,
mobility routing and
location management.
Such functional decomposition will enable us
to clearly separate
data plane and the control plane functionality,
and gives us the flexibility in an implementation
to position said logical functions
at their most appropriate places in the system design.
</t>
<t>
Section 4 shows that these logical functions
can indeed perform the same functions
as the major existing mobility protocols.
These functions therefore become the foundation
for a unified framework
upon which
different designs of distributed mobility management may be built upon.
</t>
<t>
Section 6 presents the gap analysis of existing protocols
by comparing them against the DMM requirements
as per [ID-dmm-requirements].
</t>
<t>
Extensions to overcome the gaps are presented in Sections 5 and 7.
Based on the introduced unified framework,
extensions to dynamically provide mobility support are described in Section 7.1
where the home IP address of an MN is generalized to that of an application session.
A distributed database architecture is described in Section 5.1.
Using this distributed architecture,
various route optimizations can be defined as explained in Section 7.2.
</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 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 document uses the following terms:
</t>
<t>
<list style='hanging'>
<t hangText='Mobility routing (MR)'>
is the logical function
that intercepts packets to/from the HoA of a mobile node
and forwards them,
based on internetwork location information,
either directly towards their destination
or to some other network element
that knows how to forward the packets to their ultimate destination.
<vspace blankLines="1" />
</t>
<t hangText='Home address allocation'>
is the logical function
that allocates the home network prefix
or home address to a mobile node.
<vspace blankLines="1" />
</t>
<t hangText='Location management (LM)'>
is the logical function that manages and keeps track of
the internetwork location information of a mobile node,
which includes the mapping of the MN HoA
to the MN routing address
or another network element
that knows where to forward packets destined for the MN.
<vspace blankLines="1" />
</t>
<t hangText='Home network of an application session (or an HoA IP address)'>
is the network that has allocated the IP address
used as the session identifier (HoA)
by the application being run in an MN.
The MN may be attached to more than one home networks.
<vspace blankLines="1" />
</t>
</list>
</t>
</section>
</section>
<!-- 3 Mobility Management Logical Functions -->
<section title="Mobility Management Logical Functions">
<t>
The existing mobility management functions
of MIPv6, PMIPv6, and HMIPv6
ca be abstracted
into the following logical functions:
</t>
<t>
<list style="numbers">
<t>
Anchoring: allocation of home network prefix or HoA
to an MN that registers with the network;
<vspace blankLines="1" />
</t>
<t>
Mobility Routing (MR) function:
packets interception and forwarding to/from the HoA of the MN,
based on the internetwork location information,
either to the destination
or to some other network element
that knows how to forward the packets to their destination;
<vspace blankLines="1" />
</t>
<t>
Internetwork Location Management (LM) function:
managing and keeping track of the internetwork location of an MN,
which includes a mapping of the HoA
to the mobility anchoring point that the MN is anchored to;
<vspace blankLines="1" />
</t>
<t>
Location Update (LU):
provisioning of MN location information to the LM function;
<vspace blankLines="1" />
</t>
<t>
Routing Control (RC):
this logical function configures the forwarding state
of the mobility routing function.
<vspace blankLines="1" />
</t>
</list>
</t>
</section>
<!-- 4 existing mobility protocols -->
<section title="Functional Representation of Existing Mobility Protocols">
<t>
This section shows that
existing mobility management protocols
can be expressed as different configurations
of the logical functions
introduced in Section 3 above.
</t>
<t>
Using these generic logical functions,
we will build up the existing mobility protocols one step at a time
in the following sequence: MIPv6, PMIPv6, HMIPv6, and HAHA.
Functions are added and modified as needed in each step.
</t>
<!-- 4.1 MIPv6 -->
<section title="Mobile IPv6">
<t>
Figure 1 shows Mobile IPv6
<xref target="RFC6275"/>
in a functional representation.
The combination of the logical functions
MR, LM and HoA allocation in network1
is the home agent or the mobility anchor.
The mobile node MN11 was originally attached to Network1
and was allocated the IP prefix for its home address HoA11.
After some time, MN11 moved to Network3,
from which it is allocated a new prefix to configure the IP address IP32.
LM1 maintains the binding HoA11:IP32
so that packets from CN21 in Network2
destined to HoA11 will be intercepted by MR1,
which will then tunnel them to IP32.
MN11 must perform mobility signaling
using the LU function.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network3 Network2
+-----+
| LM1 |
+-----+
location=IP32
HoA1 alc IP3 alc IP2 alc
|
|
+-----+
| MR1 |
+-----+
.
. +----+ +----+ +----+
. |MN31| |MN11| |CN21|
. | | |+LU | | |
. +----+ +----+ +----+
HoA11 IP31 IP32,
HoA11
]]></artwork>
<postamble></postamble>
</figure>
<t>
Figure 1. Functional decomposition of Mobile IPv6.
</t>
</section>
<!-- 4.2 MIPv6 and PMIPv6 -->
<section title="MIPv6 versus PMIPv6">
<t>
MIPv6 and PMIPv6 both employ the same concept
of separating the session identifier from the routing address
into the HoA and CoA, respectively.
Figure 2 contrasts (a) MIPv6 and (b) PMIPv6
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) MIPv6:
+---+ +---+---+ +---+
|HoA| --> |HoA|HoA| |HoA|
| | | |---| |---|
| | | |CoA| ==> |CoA|
+---+ +---+---+ +---+
CN MR MN+LU
(b) PMIPv6:
+---+ +---+---+ +---+---+ +---+
|HoA| --> |HoA|HoA| |HoA|HoA| --> |HoA|
| | | |---| |---| | | |
| | | |CoA| ==> |CoA| | | |
+---+ +---+---+ +---+---+ +---+
CN MR AR+LU 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+LU in MIPv6; and
(b) to the AR+LU in PMIPv6
showing the destination IP address as the packet traverses from the CN to the MN.
</t>
<t>
Figure 2 shows that,
as far as data-plane traffic is concerned,
routing from CN to MN+LU in MIPv6
is similar to the route from CN to AR+LU in PMIPv6.
The difference is in that
the MN with the LU function
is substituted by
the combination of the AR with the LU function and the MN.
While additional signaling is needed
to enable the combination of AR+LU and MN
to behave like MN+LU,
such signaling can be confined between the AR+LU and MN only.
It can therefore be seen under this unified formulation,
that a host-based mobility management protocol
can be translated using this substitution
into a network-based mobility management protocol
and vice versa.
</t>
<t>
MIPv6 and PMIPv6
bundle all three mobility management logical functions:
LM1, IP1 prefix allocation, and MR1
into the home agent (HA) and Local Mobility Anchor (LMA) respectively.
</t>
<t>
The functional representation of Proxy Mobile IPv6
<xref target="RFC5213"/>
is shown in Figure 3.
In PMIPv6, the combination of LM, MR, and HoA allocation
is the Local Mobility Anchor (LMA),
whereas the AR+LU combination together with additional signaling with MN
comprises the Mobile Access Gateway (MAG).
Here MN11 is attached to the access router AR31
which has the IP address IP31 in Network3.
LM1 maintains 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| |CN21|
. |+LU | | |
. +----+ +----+
HoA11 IP31
|
|
+----+
|MN11|
+----+
HoA11
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 3. Functional representation of PMIPv6.
</t>
</section>
<!-- 4.3 HMIPv6 -->
<section title="Hierarchical Mobile IPv6">
<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 |
| | |+ LM |
| | |proxy|
+-----+ +-----+
. / \
. / \
. / \
. +----+ +----+ +----+
. |AR31| |MN11| |CN21|
. |+LU | |+LU | | |
. +----+ +----+ +----+
HoA11 IP31 IP32,
| HoA11
|
+----+
|MN31|
+----+
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 4. Functional representation
of Hierarchical Mobile IPv6.
</t>
<t>
Besides the logical functions: LM1, MR1,
and HoA1 prefix allocation
in Network1 as MIPv6 in Figure 2 and PMIPv6 in Figure 3,
there is an MR function (MR3)
in the visited network (Network3).
MR3 is also a proxy between LM1 and MN11
in the hierarchical LM function LM1--MR3--MN11.
That is, LM1 maintains the LM binding HoA11:MR3
while MR3 keeps the LM binding HoA11:IP32.
The combined function of MR and the LM proxy function
is the Mobility Anchor Point (MAP).
</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
e.g., a home agent in MIPv6
or a local mobility anchor in PMIPv6,
in a single network,
the result is triangular routing
when the MN and the CN are in networks
close to each other
but are far from the anchor point.
</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 for all 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 use the binding HoA11:IP32
to tunnel the packets to MN11.
</t>
<t>
Similarly, traffic originating from MN11
will be served by its nearest MR (MR3).
Triangular routing is therefore avoided.
Yet the synchronization of all home agents
becomes a challenge as discussed in [Paper-SMGI].
In addition, the amount of signaling traffic
needed in synchronizing the home agents
may become excessive
when both the number of mobile nodes
and the number of home agents 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 DMM Functional Scenarios -->
<section title="DMM Functional Scenarios">
<t>
This section covers the functional description of DMM.
Basically, the scenario presents a way
to distribute the logical mobility functions.
Gap analysis will be made on the functional scenarios.
</t>
<!-- 5.1 Flat Network Scenario -->
<section title="Flat Network Scenario">
<t>
In a flat network,
the logical functions in the functional representation
may all be located at the AR as shown in Figures 6 and 7,
respectively. These two figures depict the network- and client-based
distributed mobility management scenarios.
The AR is expected to support the HoA allocation function.
Then,
depending on the mobility situation of the MN,
the AR can run different functions:
</t>
<t>
<list style="numbers">
<t>
the AR can act as a legacy IP router;
<vspace blankLines="1" />
</t>
<t>
the AR can provide the MR function
(i.e. act as mobility anchor);
<vspace blankLines="1" />
</t>
<t>
the AR can provide the LU functions;
<vspace blankLines="1" />
</t>
<t>
the AR can provide both MR and LU functions.
<vspace blankLines="1" />
</t>
</list>
</t>
<t>
For example,
[I-D.seite-dmm-dma] and [I-D.bernardos-dmm-anchoring] are PMIPv6 based implementation of this scenario.
</t>
<!-- 5.1.1 Network-based Mobility Management -->
<section title="Network-based Mobility Management">
<t>
The functional description
of network-based mobility management is depicted on figure 6.
</t>
<t>
In case (1), MN1 attaches to AR1.
AR advertises prefix HoA1 to MN1
and then acts as a legacy IP router.
MN1 initiates a communication with CN11.
</t>
<t>
In case (2),
MN1 performs a handover from AR1 to AR3
while maintaining ongoing IP communication with CN11.
AR1 becomes the mobility anchor
for the MN1-CN11 IP communication:
AR1 runs MR and LM functions for MN1.
AR3 performs LU up to the LM in AR1:
AR3 indicates to AR1 the new location of the MN1.
AR3 allocates a new IP prefix (HoA3) for new IP communications.
HoA3 is supposed to be used for new IP communication,
e.g., if MN1 initiates IP communication with CN21.
AR3 shall act as a legacy IP router for MN1-CN21 communication.
</t>
<t>
In case (3),
MN1 performs a handover from AR1 to AR2
with ongoing IP communication with CN11 and CN21.
AR1 is the mobility anchor for the MN1-CN11 IP communication.
AR3 becomes the mobility anchor for the MN1-CN21 IP communication.
Both AR1 and AR3 run MR and LM functions for MN1,
respectively, anchoring HoA1 and HoA3.
AR2 performs location updates
up to the LMs in AR1 and AR3 for respectively relocate HoA1 and HoA3.
</t>
<!--
<vspace blankLines="1" />
123456789012345678901234567890123456789012345678901234567890123456789012
-->
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network1 Network3
+----+ HoA1 alc +----+ HoA1 alc HoA3 al +----+
|CN11| +-----+ |CN11| +-----+ +-----+ |CN21|
| |------| | | |------| MR1 |------| |------- | |
+----+ | | +----+ | LM1 |------|LU31 | +----+
| AR1 | | AR1 | |AR3 |
| | | | | |
+-----+ +-----+ +-----+
| |
| |
| |
+----+ +----+
|MN1 | |MN1 |
| | | |
+----+ +----+
HoA11 HoA11,
HoA31
(1) (2)
Network2
Network1 HoA2 al
+----+ HoA1 alc +-----+
|CN11| +-----+ | |
| |------| MR1 |-----------------|LU21 |-------+
+----+ | LM1 |-----------------|AR2 | |
| AR1 | | | |
| | Network3 +-----+ |
+-----+ HoA3 al | | +----+
+-----+ | | |MN1 |
+----+ |MR3 |------ | | |
|CN21| |LM3 |-------- +----+
| |------| | HoA11,
+----+ |AR3 | HoA31
+-----+ (3)
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 6. Network-based DMM architecture for a flat network.
</t>
</section>
<!-- 5.1.2 Client-based Mobility Management -->
<section title="Client-based Mobility Management">
<t>
The functional description of client-based mobility management
is depicted in Figure 7.
</t>
<t>
In case (1), MN1 attaches to AR1.
AR advertises the prefix HoA1 to MN1 then acts as a legacy IP router.
MN1 initiates a communication with CN11.
</t>
<t>
In case (2),
MN1 performs a handover from AR1 to AR3
with ongoing IP communication with CN11.
AR1 becomes the mobility anchor for the MN1-CN11 IP communication:
AR1 runs MR and LM functions for MN1.
The MN performs LU directly up to the LM in AR1 or via AR3;
in this case AR3 acts as a proxy locator (pLU)
(e.g. as a FA in MIPv4).
AR3 allocates a new IP prefix (HoA3) for new IP communications.
HoA3 is supposed to be used for new IP communications,
e.g., if MN1 initiates IP communication with CN21.
AR3 shall act as a legacy IP router for MN1-CN21 communication.
</t>
<!--
<vspace blankLines="1" />
123456789012345678901234567890123456789012345678901234567890123456789012
-->
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network1 Network3
+----+ HoA1 alc +----+ HoA1 alc +----+
|CN11| +-----+ |CN | +-----+ +-----+ |CN21|
| |------| | | |------| MR1 |------| |------- | |
+----+ | | +----+ | LM1 |------|pLU31| +----+
| AR1 | | AR1 | |AR31 |
| | | | | |
+-----+ +-----+ +-----+
| |
| |
| |
+----+ +----+
|MN1 | |MN1 |
| | |LU31|
+----+ +----+
HoA11 HoA11,
IP31
(1) (2) ]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 7. Client-based DMM architecture for a flat network.
</t>
</section>
</section>
<!-- 5.2 Fully Distributed Scenario with Separation of Control and Data Planes -->
<section title="Fully distributed scenario with separation of control and data planes">
<t>
This scenario considers multiple MRs and a distributed LM database.
</t>
<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 document
is mainly on separating the data plane from the control plane.
</t>
<t>
Figure 8 shows an example DMM architecture
with the same three networks as in Figure 5.
As is in Figure 5,
each network in Figure 8 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 exchange signaling with each other.
In addition to these features in Figure 5,
the LM function in Figure 8 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|
. |+LU | |+LU | | |
. +----+ +----+ +----+
HoA11 IP31 IP32,
| HoA11
|
+----+
|MN31|
+----+
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 8. A distributed architecture
for 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 the 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 the 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 its handover to the third network,
the database server LM1 maintains a mapping of HoA11 to MR3.
That is,
LM1 points to the third network
and it is the third network
that will keep track of how to reach MN11.
Such a hierarchical mapping
can prevent 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>
<!-- 6 gap analysis -->
<section title="Gap analysis">
<section title="DMM Requirements">
<!-- 6.1.1 gap analysis with REQ4: existing protocols -->
<section title="Considering existing protocols first">
<t>
The fourth DMM requirement is on existing mobility protocols
[ID-dmm-requirements:
</t>
<t>
REQ4: A DMM solution SHOULD
first consider reusing and extending
IETF-standardized 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 DMM requirements can be met.
One needs to check the rest of the requirements
to identify the gaps.
</t>
<t>
In addition,
individual DMM proposals available at the IETF DMM working group
are mostly based on the existing IETF-standardized protocols.
</t>
</section>
<!-- 6.1.2 gap analysis with REQ5-1: compatibility -->
<section title="Compatibility">
<t>
The first part of the fifth DMM requirement is on compatibility:
</t>
<t>
REQ5: (first part) The DMM solution MUST
be able to co-exist
with existing network deployments and end hosts.
For example,
depending on the environment in which DMM is deployed,
DMM solutions
may need to be compatible
with other deployed mobility protocols
or may need to interoperate
with a network or mobile hosts/routers
that do not support DMM protocols.
</t>
<t>
Different deployments using the same abstract functions
can be compatible with each other
if their functions use common message formats
between these functions.
A design principle of the IPv6 message format
accommodates the use of common message formats
as it allows to define extension headers,
e.g., use of mobility header and options.
</t>
</section>
<!-- 6.1.3 gap analysis with REQ3: IPv6 deployment -->
<section title="IPv6 deployment">
<t>
The third DMM requirement on IPv6 deployment is the following.
</t>
<t>
REQ3: DMM solutions SHOULD target IPv6
as the primary deployment environment
and SHOULD NOT be tailored specifically to support IPv4,
in particular in situations
where private IPv4 addresses and/or NATs are used.
</t>
<t>
This is not an issue with MIPv6, PMIPv6 and their extensions.
Using the unified scheme here based on abstracting
these existing protocol functions
will meet the DMM requirements
as these protocols are originally designed for IPv6.
</t>
</section>
<!-- 6.1.4 gap analysis with REQ6: Security considerations -->
<section title="Security considerations">
<t>
The first part of the fourth requirement
as well as the sixth DMM requirement
[ID-dmm-requirements] are as follows:
</t>
<t>
REQ5 (second part):
Furthermore,
a DMM solution SHOULD work across different networks,
possibly operated as separate administrative domains,
when allowed by the trust relationship
between them.
</t>
<t>
REQ6: DMM protocol solutions
MUST consider security aspects,
including confidentiality and integrity.
Examples of aspects to be considered are
authentication and authorization mechanisms
that allow a legitimate mobile host/router
to use the mobility support provided by the DMM solution;
signaling message protection
in terms of authentication,
encryption, etc.;
data integrity and confidentiality;
opt-in or opt-out data confidentiality
to signaling messages
depending on network environments
or user requirements.
</t>
<t>
It is preferred that these security requirements
are considered as an integral part of the DMM design.
</t>
</section>
<!-- 6.1.5 gap analysis with REQ1-1: distributed deployment -->
<section title="Distributed deployment">
<t>
The first DMM requirement has 2 parts.
The first part is on distributed deployment
whereas the second part is on avoiding longer routes.
</t>
<t>REQ1: (part 1)IP mobility, network access and routing solutions
provided by DMM
MUST enable distributed deployment
for mobility management of IP sessions
(part 2)
so that traffic
does not need to traverse centrally deployed
mobility anchors and thus
can be routed
in an optimal manner.
</t>
<t>
With the first part, multiple MRs will become available in MIPv6
by simply having an HA for each home network.
This is illustrated in terms of the logical functions as in Figure 8.
Note that [Paper-Host.based.DMM]
shows an example of a host-based DMM protocol based on MIPv6.
</t>
<t>
With the second part,
one can examine dynamic mobility and route optimization
to be discussed later.
</t>
<t>
Figure 9 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|
. |+LU | |+LU | | |
. +----+ +----+ +----+
HoA11 IP31 IP32,
| HoA11
|
+----+
|MN31|
+----+
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 9. A distributed architecture
of mobility management.
</t>
</section>
<!-- 6.1.6 gap analysis on REQ2: Transparency to Upper Layers when needed -->
<section title="Transparency to Upper Layers when needed">
<t>
To see how to avoid traversing centralized deployed mobility anchors,
let us look at the second requirement on non-optimal routes
[ID-dmm-requirements].
</t>
<t>
REQ2: DMM solutions MUST provide
transparent mobility support above the IP layer
when needed.
Such transparency is needed,
for example, when,
upon change of point of attachment to the Internet,
an application flow cannot cope with a change
in the IP address.
Otherwise, support for
maintaining a stable home IP address or prefix
during handovers 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 association with the HoA of an 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 a need.
There are, however, application sessions
that had originated from a prior network
and that require mobility support.
Longer routes than the natural IP route can therefore emerge.
Route optimization schemes already exist,
but one needs to deal with multiple HA's
when using multiple HA's.
</t>
</section>
<!-- 6.1.7 gap analysis: route optimization -->
<section title="Route optimization">
<t>
The second part of first requirement is on route optimization.
</t>
<t>
REQ1: (part 1)IP mobility, network access and routing solutions
provided by DMM
MUST enable distributed deployment
for mobility management of IP sessions
(part 2)
so that traffic
does not need to traverse centrally deployed
mobility anchors and thus
can be routed
in an optimal manner.
</t>
<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 have a client-server relationship,
with optionally a proxy in between
and the proxy can be co-located 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 other servers
but the database system only needs to know
which data resides on which server.
In addition, each client (i.e., MN) needs to be able to query the database.
</t>
<t>
Existing functions, such as BU and BA messages, can be considered
as a method of database update function for the mobility context of the MN.
Completing the design of messages for the database update functions
will enable the distributed database design for route optimization.
</t>
<t>
In the unified scheme,
complete with database and mobility routing functionalities,
numerous route optimizations can be designed as described in Section 7.2.
</t>
</section>
</section>
<section title="Mobility Potocols Gap Analysis">
<section title="Gap analysis with the unified framework">
<t>
The use of the unified framework meets the following requirements:
</t>
<t>
REQ4: Considering existing protocols first
<vspace blankLines="1" />
REQ5: (first part) compatibility
<vspace blankLines="1" />
REQ3: IPv6 deployment
</t>
<t>
The unified framework
has separated the HA function into an MR and an LM function.
The following is needed in addition:
</t>
<t>
REQ6: Security - Trust between MR and LM is needed
when they are not co-located.
</t>
</section>
<section title="Gap analysis with MIPv6">
<t>
MIPv6 using the unified framework
follows the above gap analysis with the unified framework.
In addition, the following is needed.
</t>
<t>
REQ6: Security consideration
<vspace blankLines="1" />
Trust between MN and MR is needed.
</t>
</section>
<section title="Gap analysis with PMIPv6">
<t>
In terms of the unified framework,
PMIPv6 differs from MIPv6
only in the sense that the combination of an AR and the MN
in the network-based solution
behaves like an MN in the host-based solution.
While the gap analysis with MIPv6 applies here,
the following change is needed:
The trust between MN and MR in MIPv6
is therefore replaced by the trust between AR and MR,
and trust between the AR and the MN is needed.
</t>
<t>
REQ6: Security consideration
<vspace blankLines="1" />
Trust between AR and MR is needed.
<vspace blankLines="1" />
Trust between MN and MR is needed.
</t>
</section>
<section title="Gap analysis with HMIPv6">
<t>
In terms of the unified framework,
HMIPv6 differs from MIPv6 and PMIPv6
only in the addition that packets are routed in the hierarchy
MR(home network) -- MR(visited network)
-- MN in MIPv6 or AR in PMIPv6.
While the gap analysis with MIPv6 and PMIPv6 applies to HMIPv6,
the following additional trust relationship
is needed between the MR's of different networks.
</t>
<t>
REQ6: Security consideration
<vspace blankLines="1" />
Trust between MRs in different networks is needed.
</t>
</section>
<section title="Gap analysis with HAHA">
<t>
The scenario for Migrating Home Agent
can be constructed by using multiple MIPV6 or HMIPv6 networks
and modifying the LM in each network to propagate its data
to all LM servers in all other networks.
Therefore the gap analysis with MIPv6 and HMIPv6 apply.
</t>
<t>With the implementation of the unified framework
in each network,
the MR function is then available in different networks.
The following requirement of distributed deployment is then met.
</t>
<t>
REQ1: Distributed deployment
<vspace blankLines="1" />
The unified framework functions can be deployed in each of the multiple networks.
</t>
<t>
In addition,
trust between the LM servers is needed.
</t>
<t>
REQ6: Security consideration
<vspace blankLines="1" />
Trust among the LM servers is needed.
</t>
</section>
<section title="Gap analysis with Dynamic mobility management">
<t>
In Section 6, the unified framework functions are built
by modifying the HAHA scenario.
The LM servers in different networks
are no longer copying to each other and anycast may not be used.
Therefore the gap analyses with HAHA
except that of copying the LM servers
apply to the dynamic mobility management.
In addition,
</t>
<t>
REQ2: Transparency to upper layers when needed.
<vspace blankLines="1" />
The home network and HoA was previously associated with an MN.
By extending the concept to that of an application
rather than an MN which has multiple applications,
dynamic mobility management can be achieved.
</t>
</section>
<section title="Gap Analysis with Multiple MRs and Distributed LM Database">
<t>
In Section 7, an architecture of distributed mobility management
is constructed from the unified framework functions
and can be seen as an extension of the multiple home network scenario
with dynamic mobility management support.
Therefore the gap analyses for the dynamic mobility management also apply.
In addition, the following gap analysis applies.
</t>
<t>
REQ1: (part 2) Distributed deployment
<vspace blankLines="1" />
The LMs may generalize into a distributed database.
</t>
<t>
REQ6: Security considerations
<vspace blankLines="1" />
Trust between the LM in a different network and the MR is needed.
</t>
</section>
<section title="Gap Analysis with Route Optimization Mechanisms">
<t>
In Section 8, different possibilities to optimize the route
using the architecture in Section 7 is described.
Therefore the gap analyses for the DMM architecture in Section 7 apply.
In addition, the following gap analyses apply.
</t>
<t>
REQ1: (part 2) Distributed deployment
<vspace blankLines="1" />
MR may cache the LM information when needed.
<vspace blankLines="1" />
MR function is needed in the CN's network.
</t>
<t>
REQ6: Security considerations
<vspace blankLines="1" />
Trust between the MR and the LM is needed.
</t>
</section>
</section>
<section title="Gap analysis summary">
<t>
The gap analyses for different protocols are summarized in this section.
</t>
<t>
Table 1. Summary of Gap Analysis
<!--
<vspace blankLines="1" />
123456789012345678901234567890123456789012345678901234567890123456789012
-->
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Upper-
layer
Existing Distri- trans-
proto- IPv6 Security buted parency Route
cols Compati- deploy- consi- deploy- when Optimi-
first bility ment derations ment needed zation
Unified
framework Y Y Y N/A N/A N/A N/A
MIPv6 Y Y Y Y N N N
PMIPv6 Y Y Y Y N N N
(LM-LM)
HMIPv6 Y Y Y Y N N N
(MR-MR)
HAHA Y Y Y Y Y Y Y
(LM-LM)
Multiple
MRs and LM-MR
Distri- in
buted LM different
database Y Y Y networks Y Y
Dynamic Y Y Y Y Y Y most
mobility (HoA of appl) cases
Optimize except
route Y Y Y ditto Y Y 1st pkt
]]></artwork>
<postamble></postamble>
</figure>
</section>
</section>
<!-- 7. DMM analysis -->
<section title="DMM analysis">
<t>
This section analyses how DMM proposals meet above requirements.
</t>
<!-- 7.1 DMM scenarios and Dynamic mobility management requirement -->
<section title="DMM scenarios and Dynamic mobility management requirement">
<t>
The distributed architecture described in Section 5.1,
which has an MR and an HoA allocation function in each network,
enables dynamic mobility management.
</t>
<t>
When new applications are started
after the MN moves 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]
and [Paper-Host.based.DMM].
</t>
<t>
The architecture with multiple mobility routing functions
compared with a centralized approach
is more appropriate for achieving dynamic mobility management.
In Figure 9 above,
the LM function and the IP address allocation function
may be co-located.
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 have,
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 MIPv6 signaling mechanism
so that the LM1 will maintain the binding HoA11:MR3.
MR3 in turn will maintain the binding HoA11:IP33.
Such a hierarchy of binding
with MR3 acting as the proxy location maintenance function
between LM1 and MN11
will also cause MR3 to act as a proxy MR function
between MR1 and MN11
so that packets destined to MR1 will be redirected to MR3.
</t>
<t>
When all ongoing sessions
requiring session continuity terminate,
it is possible for MN11 to deregister from 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 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 dynamic mobility management
using PMIPv6. In that document, MR, LM, and the HoA allocation functions
are co-located at the access router in a flat 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 functions
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>
[Paper-Host.based.DMM]
described fully distributed dynamic mobility management using MIPv6.
An access mobility anchor (AMA)
is introduced as a mobility anchor
that provides the MR, LM, and HoA allocation functions.
As a host-based DMM protocol,
an MN is allowed to signal its movement
to a serving AMA co-located at an access router.
The serving AMA signals to other AMAs
associated to the active sessions of the MN
that enable session continuity
for the sessions anchored to the other AMAs.
No centralized LM server is required.
</t>
<t>
[ID.sarikaya-dmm-dmipv6] also described dynamic mobility management
for a flat 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>
</section>
<!-- 7.2 Route optimization of DMM scenarios -->
<section title="Route optimization of DMM scenarios">
<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 an 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 a PMIPv6 design with a hierarchical network,
the MAG generally 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 proxy function when using PMIPv6.
Yet the logical MR functions are the same.
</t>
<t>
It is again noted that in flattened network,
the access router and the gateway 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 MIPv6 or PMIPv6 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 an MN using PMIPv6,
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>
<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="16" month="July"/>
</front>
<seriesInfo value="draft-seite-dmm-dma-05" name="Internet-Draft"/>
<format target="http://www.ietf.org/internet-drafts/draft-seite-dmm-dma-05.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-anchoring">
<front>
<title>PMIPv6-based distributed anchoring</title>
<author fullname="Carlos Bernardos" surname="Bernardos" initials="CJ">
<organization/> </author>
<author fullname="JC Zuniga" surname="Zuniga" initials="JC">
<organization/> </author>
<date year="2012" day="21" month="September"/>
</front>
<seriesInfo value="draft-bernardos-dmm-distributed-anchoring-01" name="Internet-Draft"/>
<format target="http://www.ietf.org/internet-drafts/draft-bernardos-dmm-distributed-anchoring-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>
<reference anchor="Paper-Host.based.DMM">
<front>
<title>Host-based Distributed Mobility Management Support Protocol for IPv6 Mobile Networks</title>
<author initials="JH" surname="Lee">
<organization />
</author>
<author initials="JM" surname="Bonnin">
<organization />
</author>
<author initials="X" surname="Lagrange">
<organization />
</author>
<date month="October" year="2012" />
</front>
<seriesInfo name="" value="Proceedings of IEEE WiMob, Barcelona, Spain" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:15:44 |