One document matched: draft-chan-dmm-framework-gap-analysis-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<rfc category="info" ipr="trust200902"
docName="draft-chan-dmm-framework-gap-analysis-00">
<front>
<title abbrev="DMM-Architecture">
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 design.
</t>
<section title="Overview">
<t>
Session 3 proposes to decouple the logical functions
of a local mobility anchor
into that of home address allocation,
location management,
and mobility routing.
Such decoupling enables separation
between the data plane and the control plane,
and enables flexibility for the implementation
to place the logical functions
at their most appropriate locations.
When using MIP, PMIP, and their extensions,
the logical functions are a decomposition or classification
of the functions of these existing mobility protocols.
Yet it provides a framework
upon which
different designs of distributed mobility may be constructed.
</t>
<t>
Session 4 shows how the different existing protocols
can be expressed as different design configurations
of the generic logical functions.
In a distributed architecture,
the mobility routing function
may be present in many geographical locations
to support dynamic mobility management
and to route more directly
to avoid triangle routing in the data plane.
However, the internetwork location management function
may be kept only at the network
where the mobile node is running a session
using the IP address allocated from that network.
The individual location management information for a specific mobile node may be acquired whenever needed.
</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>
<!-- 3.1 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 1 compares (a) MIP and (b) PMIP
by showing the destination IP address
in the network-layer header
as a packet traverses from a CN to an MN.
</t>
<figure>
<preamble>Subsequent packets</preamble>
<artwork><![CDATA[
(a) MIP:
+---+ +---+---+ +---+
|HoA| --> |HoA|HoA| |HoA|
| | | |---| |---|
| | | |CoA| ==> |CoA|
+---+ +---+---+ +---+
CN anchor MN
(b) PMIP:
+---+ +---+---+ +---+---+ +---+
|HoA| --> |HoA|HoA| |HoA|HoA| --> |HoA|
| | | |---| |---| | | |
| | | |C0A| ==> |CoA| | | |
+---+ +---+---+ +---+---+ +---+
CN anchor MAG MN
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 1. Network layer in the protocol stack of subsequent packets
sent from the CN and tunneled to the MAG
showing the destination IP address as the packet traverses from the CN to the MN.
</t>
<t>
The comparison shows that,
as far as the data-plane traffic is concerned,
the route from CN to MN in MIP
is similar to the route from CN to MAG in PMIP.
The difference is only in replacing the MN in MIP
with the MAG-MN combination.
Therefore, the 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 these three mobility management functions
into the home agent or mobility anchor.
When all these logical functions are bundled
into one single entity
known as the home agent in Mobile IP
and as the local mobility anchor in Proxy Mobile IP,
having this anchor in only one network
results in triangle routing as shown in Figure 2.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network2 Network3
^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( )
(anchor) ( ) ( )
( ) ( ) ( )
v v v v v v v v v
MN CN
]]></artwork>
<postamble></postamble>
</figure>
<t>
Figure 2. Figure showing the triangle routing problem with a MN and a CN in networks
which may be close to each other
but are far from the anchor points (LMA or HA).
</t>
<t>
The DMM architecture such as that shown in Figure 6
therefore applies equally well
to both host-based and network-based mobility management.
The difference in the network-based mobility management
is in inserting a proxy function between the MR and the MN,
and this function may be located at the access router
which then becomes the mobile access gateway
as that defined in PMIP.
</t>
</section>
<!-- 3.2 HAHA -->
<section title="Migrating home agents">
<t>
A method to solve the triangle routing problem
is to duplicate the anchor points
in many networks (Figure 3)
in different geographic locations.
In [GHAHA],
these anchor points (home agents)
announce the same IP prefixes using anycast.
The traffic originating from the mobile node
will then be served by the nearest anchor point,
and the traffic sent from a correspondent node to the mobile node
will be intercepted by the anchor point
nearest to the correspondent node.
Therefore both traffic will use the anchor point
nearest to where the traffic originates,
so that triangle routing is avoided.
These anchor points may possess identical information
about the mobile nodes [Paper-Migrating.Home.Agents].
Yet the synchronization of all the home agents
will then be a challenge [Paper-SMGI].
In addition, the amount of signaling traffic
needed in synchronizing the home agents
may become excessive
when the number of mobile nodes and the number of home agents both increase.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network2 Network3
^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( )
(anchor) (anchor) (anchor)
( ) ( ) ( )
v v v v v v v v v
MN CN
]]></artwork>
<postamble></postamble>
</figure>
<t>
Figure 3. Figure showing the replication
of mobility anchors in multiple networks.
</t>
<t>
Decoupling the functions of the anchoring point
into the logical functions allow more flexibility.
</t>
</section>
<!-- 3.3 separate LM and MR -->
<section title="Separating control and data planes">
<t>
As illustrated in Figure 4,
having the mobility routing (MR) function
available in multiple networks
will solve the triangle routing problem.
It is also evident that the network
which has allocated the HoA of an MN
may also manage the internetwork location information of the MN.
Yet pushing this internetwork
location management (LM) information
to all the other networks
may be an overkill,
especially when the mobile node
does not always actually communicate
with any CNs in many other networks.
Keeping the location management function
at the home network of the HoA
will eliminate the need
to synchronize the location management information
in a timely and scalable manner.
Each network may then
maintain the location management information of the HoA
for which it has allocated the home network prefix.
The different such information servers in different networks
may work together to constitute a distributed database.
That is, the data in each server of the distributed database
need not be pushed to all the other servers
but the database system only needs to know
which data resides in which server.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network2 Network3
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( )
( LM(HoA) ) ( ) ( )
( MR ) ( MR ) ( MR )
( ) ( ) ( )
v v v v v v v v v v v v
MN(HoA) CN
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 4. Figure
showing the mobility routing (MR) function
available in many networks,
whereas
the dynamic internetwork location management (LM) function
of an MN using an HoA address
resides only in the network
that has allocated the network prefix of the HoA.
</t>
</section>
</section>
<section title="Gap analysis">
<section title="Existing mobility protocols">
<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>
<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>
<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 shown in terms of the logical functions as in Figure 5.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network2 Network3
+-----+ +-----+ +-----+
| LM1 | | LM2 | | LM3 |
+-----+ +-----+ +-----+
| | |
| | |
| | |
| | |
| | |
+-----+ +-----+ +-----+
| MR1 | | MR2 | | MR3 |
+-----+ +-----+ +-----+
/|\
/ | \
/ | \
/ | \
/ | \
/ | \
+----+ +----+ +----+
|MN31| |MN32| |MN11|
+----+ +----+ +----+
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 5. A distributed architecture
of mobility management.
</t>
</section>
<section title="Dynamic mobility management">
<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 traveling long routes
after the MN has moved to a new network,
such long routes can be avoided by simply using the new network
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 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 generalization the concept of HoA
to that of an application running on the MN rather than the MN
as will be discussed in Section 6.1 below.
</t>
<t>
Using the dynamic mobility management scheme
has avoid 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>
<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 can co-locate with an MR.
A distributed database
may have different servers to store different data.
Yet, 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 7.
</t>
</section>
<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>
<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>
<!-- 5. 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>
Fig. 6 shows an architecture of DMM.
The figure shows,
as an example, three networks.
Each network has its own IP prefix allocation function
which is not explicitly shown in the figure.
In the data plane,
the mobility routing function
is distributed to multiple locations
at the MRs so that routing can be optimized.
In the control plane,
the MRs may signal with each other,
and the LM function is a distributed database,
with multiple servers,
of the mapping of HoA to CoA.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Network1 Network2 Network3
+-----+ +-----+ +-----+
| LM1 | | LM2 | | LM3 |
+-----+ +-----+ +-----+
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \/ | \/ / |
| \ / \ | / \ / |
| \/ \|/ \/ |
| /\ /|\ /\ |
| / \ / | \ / \ |
| / /\ | /\ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
+-----+ +-----+ +-----+
| MR1 | | MR2 | | MR3 |
+-----+ +-----+ +-----+
/|\
/ | \
/ | \
/ | \
/ | \
/ | \
+----+ +----+ +----+
|MN31| |MN32| |MN11|
+----+ +----+ +----+
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 6. 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>
<!-- 5. 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>
[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>
[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>
The distributed mobility architecture
compared with a centralized approach
is more convenient to achieve dynamic mobility management.
In Fig. 6 above,
the LM function and the IP address allocation function
may communicate with each other or may co-locate.
The device MN11 may simply be using a dynamic IP address
which is leased from the network
with a finite lifetime of say 24 hours.
As MN11 leaves the first network
and attaches to the third network,
it may or may not have ongoing sessions
requiring session continuity.
If it does not,
there is no need for LM1 to keep the binding.
If it does,
it may use the existing MIP signaling mechanism
so that the LM1 will keep the binding HoA11:MR3.
When all the ongoing sessions
requiring session continuity have terminated,
it is possible for MN11 to deregister with LM1.
Yet one may not assume
the device will always perform the de-registration.
Alternatively the lease
of the dynamic IP address HoA11 will expire
upon which LM1 will remove the binding.
</t>
<t>
In the event that the ongoing session
outlives the lease of the HoA11,
MN11 will need to renew the lease
with the IP address allocation function in the first network.
</t>
<section title="Home network of an application session">
<t>
Because a MN may run multiple applications
each using a different IP address,
there can be multiple HoAs belong to different networks.
Therefore the notion of home network
may be generalized to that of an application session
or the IP address used by that session as an HoA.
Then the home network of an application session
is simply the network that has allocated the IP address
used as the session identifier (HoA)
by the application run in an MN.
</t>
</section>
</section>
<section title="Route optimization mechanisms">
<t>
The distributed architecture has already enabled
dynamic mobility management,
as is described in [I-D.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 will be described in the next Section.
</t>
</list>
</t>
</section>
<section anchor="security" title="Security Considerations">
<t>TBD</t>
</section>
<section title="IANA Considerations">
<t>None</t>
</section>
<section title="Acknowledgments">
<t>
This document has benefited from discussions with
Frank Xia, Justin Xiang, Hanan Ahmed, and others.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
</references>
<references title="Informative References">
<?rfc include="reference.RFC.6275" ?>
<?rfc include="reference.RFC.5213" ?>
<?rfc include="reference.RFC.5380" ?>
<?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.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.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:36 |