A unified mobility management protocol framework and DMM gap analysis
draft-chan-dmm-framework-gap-analysis-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Anthony Chan | ||
| Last updated | 2012-07-09 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-chan-dmm-framework-gap-analysis-00
Network Working Group H. Chan
Internet-Draft Huawei Technologies
Intended status: Informational July 9, 2012
Expires: January 10, 2013
A unified mobility management protocol framework and DMM gap analysis
draft-chan-dmm-framework-gap-analysis-00
Abstract
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 10, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Chan Expires January 10, 2013 [Page 1]
Internet-Draft DMM-Architecture July 2012
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
2.1. Conventions used in this document . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Logical functions of mobility management . . . . . . . . . . . 5
3.1. MIP versus PMIP . . . . . . . . . . . . . . . . . . . . . 5
3.2. Migrating home agents . . . . . . . . . . . . . . . . . . 7
3.3. Separating control and data planes . . . . . . . . . . . . 8
4. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Existing mobility protocols . . . . . . . . . . . . . . . 9
4.2. Compatibility . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Distributed deployment . . . . . . . . . . . . . . . . . . 10
4.4. Dynamic mobility management . . . . . . . . . . . . . . . 10
4.5. Route optimization . . . . . . . . . . . . . . . . . . . . 11
4.6. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 12
4.7. Security . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Multiple MRs and distributed LM database . . . . . . . . . . . 12
6. Dynamic mobility management . . . . . . . . . . . . . . . . . 14
6.1. Home network of an application session . . . . . . . . . . 15
7. Route optimization mechanisms . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
Chan Expires January 10, 2013 [Page 2]
Internet-Draft DMM-Architecture July 2012
1. Introduction
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.
Mobile IP [RFC6275] , which has primarily been deployed in a
centralized manner for the hierarchical mobile networks, has numerous
variants and extensions including PMIP [RFC5213] , hierarchical MIP
(HMIP) [RFC5380] , Fast MIP (FMIP) [RFC4068] [RFC4988] , Proxy-based
FMIP (PFMIP) [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.
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.
1.1. Overview
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.
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.
Chan Expires January 10, 2013 [Page 3]
Internet-Draft DMM-Architecture July 2012
The individual location management information for a specific mobile
node may be acquired whenever needed.
2. Conventions and Terminology
2.1. Conventions used in this document
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 [RFC2119].
2.2. Terminology
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).
In addition, this draft introduces the following terms.
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.
Home address allocation is the logical function to allocate the home
network prefix or home address to a mobile node.
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.
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.
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
Chan Expires January 10, 2013 [Page 4]
Internet-Draft DMM-Architecture July 2012
an application session rather than that of a MN.
3. Logical functions of mobility management
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:
1. allocation of home network prefix or HoA to a MN that registers
with the network;
2. 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
3. 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;
(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.)
3.1. MIP versus PMIP
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.
Chan Expires January 10, 2013 [Page 5]
Internet-Draft DMM-Architecture July 2012
Subsequent packets
(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
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.
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.
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.
Chan Expires January 10, 2013 [Page 6]
Internet-Draft DMM-Architecture July 2012
Network1 Network2 Network3
^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( )
(anchor) ( ) ( )
( ) ( ) ( )
v v v v v v v v v
MN CN
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).
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.
3.2. Migrating home agents
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.
Chan Expires January 10, 2013 [Page 7]
Internet-Draft DMM-Architecture July 2012
Network1 Network2 Network3
^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( )
(anchor) (anchor) (anchor)
( ) ( ) ( )
v v v v v v v v v
MN CN
Figure 3. Figure showing the replication of mobility anchors in
multiple networks.
Decoupling the functions of the anchoring point into the logical
functions allow more flexibility.
3.3. Separating control and data planes
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.
Chan Expires January 10, 2013 [Page 8]
Internet-Draft DMM-Architecture July 2012
Network1 Network2 Network3
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( )
( LM(HoA) ) ( ) ( )
( MR ) ( MR ) ( MR )
( ) ( ) ( )
v v v v v v v v v v v v
MN(HoA) CN
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.
4. Gap analysis
4.1. Existing mobility protocols
The fifth DMM requirement is on existing mobility protocols.
REQ5: A DMM solution SHOULD first consider reusing and extending the
existing mobility protocols before specifying new protocols.
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.
4.2. Compatibility
The second part of the fourth DMM requirement is on compatibility:
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.
Chan Expires January 10, 2013 [Page 9]
Internet-Draft DMM-Architecture July 2012
4.3. Distributed deployment
The first DMM requirement is on Distributed deployment IP mobility.
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.
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.
Network1 Network2 Network3
+-----+ +-----+ +-----+
| LM1 | | LM2 | | LM3 |
+-----+ +-----+ +-----+
| | |
| | |
| | |
| | |
| | |
+-----+ +-----+ +-----+
| MR1 | | MR2 | | MR3 |
+-----+ +-----+ +-----+
/|\
/ | \
/ | \
/ | \
/ | \
/ | \
+----+ +----+ +----+
|MN31| |MN32| |MN11|
+----+ +----+ +----+
Figure 5. A distributed architecture of mobility management.
4.4. Dynamic mobility management
To see how to avoid traversing centralized deployed mobility anchors,
let us look at the second requirement on non-optimal routes.
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
Chan Expires January 10, 2013 [Page 10]
Internet-Draft DMM-Architecture July 2012
home IP address or prefix during handover may be declined.
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.
The capability to use different IP addresses for different IP
sessions are therefore needed.
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.
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.
4.5. Route optimization
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.
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.
In the unified scheme complete with database function and mobility
routing function, numerous route optimizations can be designed as
described in Section 7.
Chan Expires January 10, 2013 [Page 11]
Internet-Draft DMM-Architecture July 2012
4.6. IPv6 deployment
The third DMM requirement on IPv6 deployment
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.
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.
4.7. Security
The first part of the fourth requirement as well as the sixth DMM
requirement are on security considerations.
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.
are on security. It is preferred that these security requirements be
considered as an integral part of the DMM design.
5. Multiple MRs and distributed LM database
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.
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.
Chan Expires January 10, 2013 [Page 12]
Internet-Draft DMM-Architecture July 2012
Network1 Network2 Network3
+-----+ +-----+ +-----+
| LM1 | | LM2 | | LM3 |
+-----+ +-----+ +-----+
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \/ | \/ / |
| \ / \ | / \ / |
| \/ \|/ \/ |
| /\ /|\ /\ |
| / \ / | \ / \ |
| / /\ | /\ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
+-----+ +-----+ +-----+
| MR1 | | MR2 | | MR3 |
+-----+ +-----+ +-----+
/|\
/ | \
/ | \
/ | \
/ | \
/ | \
+----+ +----+ +----+
|MN31| |MN32| |MN11|
+----+ +----+ +----+
Figure 6. A distributed architecture of mobility management.
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.
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
Chan Expires January 10, 2013 [Page 13]
Internet-Draft DMM-Architecture July 2012
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.
6. Dynamic mobility management
The above distributed architecture, which has an MR and an HoA
allocation function in each network, enables dynamic mobility
management.
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].
[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.
[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.
[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.
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.
Chan Expires January 10, 2013 [Page 14]
Internet-Draft DMM-Architecture July 2012
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.
6.1. Home network of an application session
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.
7. Route optimization mechanisms
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.
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.
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):
RS1.CN-MR(CN): the route segment from the CN to the nearest MR;
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
RS3.MR(MN)-MN: the route segment from the MR serving the MN to the
MN.
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:
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
Chan Expires January 10, 2013 [Page 15]
Internet-Draft DMM-Architecture July 2012
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].
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.
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.
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.
In the second segment RS2.MR(CN)-MR(MN), the alternatives are:
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.
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.
Chan Expires January 10, 2013 [Page 16]
Internet-Draft DMM-Architecture July 2012
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.
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:
1. RS1.CN-MR(CN).anycast followed by RS2.MR(CN)-MR(MN).query:
2. RS1.CN-MR(CN).anycast followed by RS2.MR(CN)-MR(MN).push:
An example is [Paper-Distributed.Mobility.PMIP] which is
explained for network-based mobile IP but is also applicable to
host-based mobile IP.
3. RS1.CN-MR(CN).gw/ar followed by RS2.MR(CN)-MR(MN).query:
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.
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.
[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.
4. RS1.CN-MR(CN).gw/ar followed by RS2.MR(CN)-MR(MN).push:
Another example will be described in the next Section.
Chan Expires January 10, 2013 [Page 17]
Internet-Draft DMM-Architecture July 2012
8. Security Considerations
TBD
9. IANA Considerations
None
10. Acknowledgments
This document has benefited from discussions with Frank Xia, Justin
Xiang, Hanan Ahmed, and others.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References
[I-D.bernardos-dmm-pmip]
Bernardos, C., Oliva, A., Giust, F., Melia, T., and R.
Costa, "A PMIPv6-based solution for Distributed Mobility
Management", draft-bernardos-dmm-pmip-01 (work in
progress), March 2012.
[I-D.distributed-lma]
Chan, H., Xia, F., Xiang, J., and H. Ahmed, "Distributed
Local Mobility Anchors",
draft-chan-netext-distributed-lma-03 (work in progress),
March 2010.
[I-D.dmm-nat-phl]
Liebsch, M., "Per-Host Locators for Distributed Mobility
Management", draft-liebsch-mext-dmm-nat-phl-00 (work in
progress), October 2011.
[I-D.dmm-scenario]
Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case
scenarios for Distributed Mobility Management",
draft-yokota-dmm-scenario-00 (work in progress),
October 2010.
Chan Expires January 10, 2013 [Page 18]
Internet-Draft DMM-Architecture July 2012
[I-D.jikim-dmm-pmip]
Kim, J., Koh, S., Jung, H., and Y. Han, "Use of Proxy
Mobile IPv6 for Distributed Mobility Management",
draft-jikim-dmm-pmip-00 (work in progress), March 2012.
[I-D.liu-dmm-pmip-based-approach]
Liu, D., Song, J., and W. Luo, "PMIP Based DMM
Approaches", draft-liu-dmm-pmip-based-approach-02 (work in
progress), March 2012.
[I-D.luo-dmm-pmip-based-dmm-approach]
Luo, W. and J. Liu, "PMIP Based DMM Approaches",
draft-luo-dmm-pmip-based-dmm-approach-01 (work in
progress), March 2012.
[I-D.ma-dmm-armip]
Ma, Z. and X. Zhang, "An AR-level solution support for
Distributed Mobility Management", draft-ma-dmm-armip-00
(work in progress), February 2012.
[I-D.patil-dmm-issues-and-approaches2dmm]
Patil, B., Williams, C., and J. Korhonen, "Approaches to
Distributed mobility management using Mobile IPv6 and its
extensions", draft-patil-dmm-issues-and-approaches2dmm-00
(work in progress), March 2012.
[I-D.seite-dmm-dma]
Seite, P. and P. Bertin, "Distributed Mobility Anchoring",
draft-seite-dmm-dma-00 (work in progress), February 2012.
[MHA] Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home
Agents Towards Internet-scale Mobility Deployments",
Proceedings of the ACM 2nd CoNEXT Conference on Future
Networking Technologies, Lisboa, Portugal, December 2006.
[Paper-Distributed.Centralized.Mobility]
Bertin, P., Bonjour, S., and J-M. Bonnin, "Distributed or
Centralized Mobility?", Proceedings of Global
Communications Conference (GlobeCom), December 2009.
[Paper-Distributed.Dynamic.Mobility]
Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed
Dynamic Mobility Management Scheme Designed for Flat IP
Architectures", Proceedings of 3rd International
Conference on New Technologies, Mobility and Security
(NTMS), 2008.
[Paper-Distributed.Mobility.Management]
Chan Expires January 10, 2013 [Page 19]
Internet-Draft DMM-Architecture July 2012
Chan, H., "Distributed Mobility Management with Mobile
IP", Proceedings of IEEE ICC 2012 Workshop on
Telecommunications: from Research to Standards, June 2012.
[Paper-Distributed.Mobility.PMIP]
Chan, H., "Proxy Mobile IP with Distributed Mobility
Anchors", Proceedings of GlobeCom Workshop on Seamless
Wireless Mobility, December 2010.
[Paper-Distributed.Mobility.Review]
Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu,
"Distributed and Dynamic Mobility Management in Mobile
Internet: Current Approaches and Issues", February 2011.
[Paper-Migrating.Home.Agents]
Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home
Agents Towards Internet-scale Mobility Deployments",
Proceedings of the ACM 2nd CoNEXT Conference on Future
Networking Technologies, December 2006.
[Paper-Net.based.DMM]
Giust, F., de la Oliva, A., Bernardos, CJ., and RPF. Da
Costa, "A network-based localized mobility solution for
Distributed Mobility Management", Proceedings of 14th
International Symposium on Wireless Personal Multimedia
Communications (WPMC), October 2011.
[Paper-SMGI]
Zhang, L., Wakikawa, R., and Z. Zhu, "Support Mobility in
the Global Internet", Proceedings of ACM Workshop on
MICNET, MobiCom 2009, Beijing, China, September 2009.
[RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005.
[RFC4988] Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers",
RFC 4988, October 2007.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L.
Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
Management", RFC 5380, October 2008.
[RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F.
Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949,
September 2010.
Chan Expires January 10, 2013 [Page 20]
Internet-Draft DMM-Architecture July 2012
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
Author's Address
H Anthony Chan
Huawei Technologies
5340 Legacy Dr. Building 3, Plano, TX 75024, USA
Email: h.a.chan@ieee.org
Chan Expires January 10, 2013 [Page 21]