Internet DRAFT - draft-chan-dmm-architecture
draft-chan-dmm-architecture
Network Working Group H. Chan
Internet-Draft Huawei Technologies
Intended status: Informational March 3, 2012
Expires: September 4, 2012
A architecture of distributed mobility management using mip and pmip
draft-chan-dmm-architecture-00
Abstract
This draft proposes a distributed architecture of mobility management
in terms of abstracted logical functions. Mobility management
functions are abstracted into different logical functions: (1)
allocation of home network prefixes or home addresses to mobile
nodes; (2) location management which includes managing the IP
addresses and locations of the mobile nodes; and (3) mobility routing
which includes intercepting and forwarding packets. A distributed
architecture can be contructed by providing the mobility routing
functions in multiple networks in the data plane and a distributed
database is used to host the location management function. This
generalized architecture enables different distributed mobility
designs using primarily the existing mobility protocols (MIP and
PMIP) and their extensions. Several existing distributed mobility
management proposals are briefly reviewed using this framework. It
is expected that the different proposals, when expressed in terms of
the generalized framework of logical functions, can interwork with
each other as well as with the existing hierarchical deployments.
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 September 4, 2012.
Copyright Notice
Chan Expires September 4, 2012 [Page 1]
Internet-Draft DMM-Architecture March 2012
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
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 . . . . . . . . . . . . . . . . . 5
2.1. Conventions used in this document . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Logical functions of mobility management . . . . . . . . . . . 5
4. A distributed architecture of mobility management . . . . . . 8
4.1. Multiple MRs and distributed LM database . . . . . . . . . 8
4.2. Against the issues of centralized mobility . . . . . . . . 10
4.3. DMM for MIP versus DMM for PMIP . . . . . . . . . . . . . 11
5. Dynamic mobility management . . . . . . . . . . . . . . . . . 12
5.1. Home network of an application session . . . . . . . . . . 13
6. Route optimization mechanisms . . . . . . . . . . . . . . . . 13
7. Co-locating MR at gateway or access router . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
Chan Expires September 4, 2012 [Page 2]
Internet-Draft DMM-Architecture March 2012
1. Introduction
The family of Mobile IP [RFC6275] protocols, including Proxy mobile
IP [RFC5213] and various variants of Mobile IP separate session
identifier and routing address into a home address and a care-of-
address respectively and supports mobility with a mobility anchor or
home agent in the home network. By routing via the anchor in the
home network, triangle routing is encountered when a mobile node is
far from the anchor while being much closer to its correspondent
node.
Centralized mobility management has naturally been used in existing
hierarchical networks, distributed mobility management appears more
compatible with the flattened networks. While there are research on
new protocols for distributed mobility management it has also been
proposed, e.g., in [Paper-Distributed.Mobility.PMIP] and in many
other publications, that distributed mobility management can be
designed using primarily the existing mobility management protocols.
It will then be helpful to be able to use the same distributed
mobility management tools in both a distributed and a centralized
manner and to achieve distributed mobility in both the hierarchical
network and the flattened network. Evolution path and compatibility
with different deployments may then be less of a challenge.
[I-D.dmm-approaches] has also suggested that a framework using mainly
the existing mobility protocols and extensions may provide the needed
solutions and expected that architecture work rather than protocol
work is needed. This draft proposes such a generic architectural
framework to deploy distributed mobility, which also embodies some
other proposed designs. If also describes another design of
distributed mobility management.
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 describes how to put the logical functions into a
distributed architecture. In a distributed architecture, the
mobility routing function may be present in many geographical
Chan Expires September 4, 2012 [Page 3]
Internet-Draft DMM-Architecture March 2012
locations to support dynamic mobility management and to route more
directly to avoid triangle routing in the data plane. However, the
internetwork location management function may be kept only at the
network where the mobile node is running a session using the IP
address allocated from that network. The individual location
management information for a specific mobile node may be acquired
whenever needed (Session 4.1).
The architectural framework enables distributed mobility management
addressing the issues in centralized mobility management (Session
4.2). It can be used for both client-based and network-based Mobile
IP (Session 4.3).
Session 5 explains that the distributed architecture in terms of the
logical functions enables dynamic mobility management. Several other
proposals of dynamic mobility management can be considered as
different designs as welll as filling in any protocol gaps when
needed.
Besides achieving dynamic mobility management, one can also take
advantage of the distributed architecture to avoid unnecessarily long
routes in the data plane. Such mechanisms are explained in Session
6. Several different route optimization in distributed mobility
management are reviewed as different designs in terms of a common
framework, even though they may use different terminologies. For
example, the extension of MAG at an access router to include mobility
anchor function is basically an access router with the logical
function of mobility routing. Another draft previously submitted to
the netext WG, [I-D.distributed-lma], had discussed route
optimization but with a somewhat different mechanism in terms of
receiving, sending, handover, and other scenarios. In the 00 version
of this draft, the route optimization mechanisms is explained in
terms of the reachability of the MN only but can be expanded in
future.
A route optimization design as well as the above framework is
explained in [Paper-Distributed.Mobility.Management]. This design is
reproduced in Session 7 of this draft.
Part of the contents of this draft are taking from another draft
previously submitted to the netext wg but with a different design.
It is expected that expressing different designs in terms of the
logical functions of a common framework not only provides flexibility
but may enable interworking between the different designs as well as
with the existing centralized deployment. The other draft
[I-D.distributed-lma] explains how the distributed design can
interwork with the existing centralized designs of MIP and PMIP.
Chan Expires September 4, 2012 [Page 4]
Internet-Draft DMM-Architecture March 2012
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.
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.
3. Logical functions of mobility management
We decouple the mobility management functions into the following
logical functions to allow a more flexible design to achieve DMM:
1. allocation of home network prefix or HoA to a MN that registers
with the network;
Chan Expires September 4, 2012 [Page 5]
Internet-Draft DMM-Architecture March 2012
2. internetwork location management (LM) function: managing and
keeping track of the internetwork location of a MN, which include
a mapping of the HoA to the mobility anchoring point that the MN
is anchored to; and
3. 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.
Mobile IP and Proxy mobile IP bundle all these three mobility
management functions into the home agent or mobility anchor. When
all these logical functions are bundled into one single entity known
as the home agent in Mobile IP and as the local mobility anchor in
Proxy Mobile IP, having this anchor in only one network results in
triangle routing as shown in Figure 1.
Network1 Network2 Network3
^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( )
(anchor) ( ) ( )
( ) ( ) ( )
v v v v v v v v v
MN CN
Figure 1. Figure showing the triangle routing problem with a MN and
a CN in networks which may be close to each other but are far from
the anchor points (LMA or HA).
A method to solve the triangle routing problem is to duplicate the
anchor points in many networks (Figure 2) in different geographic
locations. In [GHAHA], these anchor points (home agents) announce
the same IP prefixes using anycast. The traffic originating from the
mobile node will then be served by the nearest anchor point, and the
traffic sent from a correspondent node to the mobile node will be
intercepted by the anchor point nearest to the correspondent node.
Therefore both traffic will use the anchor point nearest to where the
traffic originates, so that triangle routing is avoided. These
anchor points may possess identical information about the mobile
nodes [Paper-Migrating.Home.Agents]. Yet the synchronization of all
the home agents will then be a challenge [Paper-SMGI]. In addition,
the amount of signaling traffic needed in synchronizing the home
agents may become excessive when the number of mobile nodes and the
number of home agents both increase.
Chan Expires September 4, 2012 [Page 6]
Internet-Draft DMM-Architecture March 2012
Network1 Network2 Network3
^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( )
(anchor) (anchor) (anchor)
( ) ( ) ( )
v v v v v v v v v
MN CN
Figure 2. Figure showing the replication of mobility anchors in
multiple networks.
Decoupling the functions of the anchoring point into the logical
functions allow more flexibility. As illustrated in Figure 3, having
the mobility routing (MR) function available in multiple networks
will solve the triangle routing problem. It is also evident that the
network which has allocated the HoA of an MN may also manage the
internetwork location information of the MN. Yet pushing this
internetwork location management (LM) information to all the other
networks may be an overkill, especially when the mobile node does not
always actually communicate with any CNs in many other networks.
Keeping the location management function at the home network of the
HoA will eliminate the need to synchronize the location management
information in a timely and scalable manner. Each network may then
maintain the location management information of the HoA for which it
has allocated the home network prefix. The different such
information servers in different networks may work together to
constitute a distributed database. That is, the data in each server
of the distributed database need not be pushed to all the other
servers but the database system only needs to know which data resides
in which server.
Network1 Network2 Network3
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
( ) ( ) ( )
( LM(HoA) ) ( ) ( )
( MR ) ( MR ) ( MR )
( ) ( ) ( )
v v v v v v v v v v v v
MN(HoA) CN
Figure 3. Figure showing the mobility routing (MR) function
available in many networks, whereas the dynamic internetwork location
management (LM) function of an MN using an HoA address resides only
Chan Expires September 4, 2012 [Page 7]
Internet-Draft DMM-Architecture March 2012
in the network that has allocated the network prefix of the HoA.
4. A distributed architecture of mobility management
4.1. 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 describes in this
draft is mainly on separating the data plane and the control plane.
Fig. 4 shows an architecture of DMM. The figure shows, as an
example, three networks. Each network has its own IP prefix
allocation function which is not explicitly shown in the figure. In
the data plane, the mobility routing function is distributed to
multiple locations at the MRs so that routing can be optimized. In
the control plane, the MRs may signal with each other, and the LM
function is a distributed database, with multiple servers, of the
mapping of HoA to CoA.
Chan Expires September 4, 2012 [Page 8]
Internet-Draft DMM-Architecture March 2012
Network1 Network2 Network3
+-----+ +-----+ +-----+
| LM1 | | LM2 | | LM3 |
+-----+ +-----+ +-----+
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \/ | \/ / |
| \ / \ | / \ / |
| \/ \|/ \/ |
| /\ /|\ /\ |
| / \ / | \ / \ |
| / /\ | /\ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
+-----+ +-----+ +-----+
| MR1 | | MR2 | | MR3 |
+-----+ +-----+ +-----+
/|\
/ | \
/ | \
/ | \
/ | \
/ | \
+----+ +----+ +----+
|MN31| |MN32| |MN11|
+----+ +----+ +----+
Figure 4. 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 thereby partly
addressing the problem 5 in Session 3 on wasting resources to support
MNs not needing mobility support. After MN11 has performed handover
to the third network, the database server LM1 keeps a mapping of
Chan Expires September 4, 2012 [Page 9]
Internet-Draft DMM-Architecture March 2012
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.
4.2. Against the issues of centralized mobility
The desired architecture of distributed mobility management should
enable solutions to address the issues of centralized mobility
management such as those explained in [Paper-
Distributed.Mobility.Review]. The distributed architecture is
examined against the issues of centralized deployment of mobile IP as
follows:
1. Non-optimized routes especially with content delivery network
(CDN) servers moved closer to the user:
The architecture has multiple MRs so that an MR is available in
each network enables avoiding the non-optimal routes in the data
plane.
2. Non-optimality in evolved network architecture:
These MRs can be implemented in any network so that an MR can be
closer to the access network to which an MNs is attached. Such
an architecture can support the more flattened networks and the
CDN networks.
3. low scalabiltiy of centralized route and mobility context
maintenance:
The distributed architecture is more scalable than a centralized
one, as is discussed in [Paper-Distributed.Centralized.Mobility].
4. Single point of failure and attack:
This problem is mitigated in a distributed database design with
multiple servers. In addition, the availability of multiple
servers is compatible with a system to use neighboring servers to
backup the location information of each other.
5. Wasting resources to support mobile nodes which are not actively
needing mobility support.
Dynamic mobility management to be discussed in the next session
Chan Expires September 4, 2012 [Page 10]
Internet-Draft DMM-Architecture March 2012
will avoid providing mobility support when no application is
using the HoA.
4.3. DMM for MIP versus DMM for PMIP
MIP and PMIP both employ the same concept of separating session
identifier and routing address into the HoA and CoA respectively.
Figure 5 compares (a) MIP and (b) PMIP by showing the destination IP
address in the network-layer header as a packet traverses from a CN
to an MN.
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 5. Network layer in the protocol stack of subsequent packets
sent from the CN and tunneled to the MAG showing the destination IP
address as the packet traverses from the CN to the MN.
The comparison shows that, as far as the data-plane traffic is
concerned, the route from CN to MN in MIP is similar to the route
from CN to MAG in PMIP. The difference is only in replacing the MN
in MIP with the MAG-MN combination. Therefore, the distributed
architecture using MIP can be adapted to the architecture using PMIP
by replacing the MN with the MAG-MN combination.
The DMM architecture shown in Figure 4 therefore applies equally well
to both host-based and network-based mobility management. The
difference in the network-based mobility management is in inserting a
proxy function between the MR and the MN, and this function may be
located at the access router which then becomes the mobile access
gateway as that defined in PMIP.
Chan Expires September 4, 2012 [Page 11]
Internet-Draft DMM-Architecture March 2012
5. 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.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.dmm-pmip], also
describes dynamic mobility management in which the MR and the HoA
allocation function are both co-located at the access router whereas
the LM information in each of these access routers are linked
together under the hierarchy of a centralized LM server.
[I-D.dmm-armip] again describes dynamic mobility management in which
the MR and the HoA allocation function are both co-located at the
access router.
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.
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.
Chan Expires September 4, 2012 [Page 12]
Internet-Draft DMM-Architecture March 2012
5.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.
6. Route optimization mechanisms
The distributed architecture has already enabled dynamic mobility
management, as is described in [I-D.dmm-dma], even when the routes
are not optimized. Route optimization mechanism can be achieved in
addition to dynamic mobility.
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
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].
Chan Expires September 4, 2012 [Page 13]
Internet-Draft DMM-Architecture March 2012
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.
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.
Chan Expires September 4, 2012 [Page 14]
Internet-Draft DMM-Architecture March 2012
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.dmm-pmip-based] in which the MR function is
co-located at the MAG which is usually at the access router.
Here, when CN is also a MN using PMIP, the packet sent from it
naturally goes to the access router which takes the logical
function of MR so that it will query the LM, which resides in the
LMA. It then uses the query result to tunnel the packet to the
MR(MN), which resides in the AR/MAG of the destination MN. The
signaling flow and other details are described in the referenced
draft.
Another example is in [Paper-PMIP.dmc]. In the signal driven
approach, the MR is co-located the access router, which is
considered as an extension of MAG. The MR, i.e., the extended
MAG, serving the CN queries the LM and cache the result so that
it can tunnel packets to the MR serving the destination MN.
[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.
7. Co-locating MR at gateway or access router
The mechanism of co-locating MR at the gateway and routing the first
packet to the home network using existing MIP/PMIP mechanism is
explained further here.
Chan Expires September 4, 2012 [Page 15]
Internet-Draft DMM-Architecture March 2012
Figure 6. shows the mapping hierarchy of the location information
from LM1 to GW and then to access router (AR).
Network1 Network2 Network3
+---+ +---+ +---+
|LM1|Binding |LM3| |LM2|
+---+HoA11:GW3 +---+ +---+
|\\ /|\ //|
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \/ | \/ / |
| \ / \ | / \ / |
| \ / \ | / \ / |
| \/ \|/ \/ |
| /\ /|\ /\ |
| / \ / | \ / \ |
| / \ / | \ / \ |
| / /\ | /\ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
|// \|/ \\|
+---+ +---+ +---+
|MR1| |MR3| |MR2|
|GW1| |GW3| |GW2|
+---+ +---+ +---+
| /|Binding |
| / |HoA11:AR32 |
| / | |
| / | |
| / | |
AR11 AR31 AR32 AR21
. | | |
. | | |
HoA11 MN31 MN11 CN21
Figure 6. Hierarchy of location management information.
When the first packet is sent from a correspondent node CN21 to the
home address HoA11 of the mobile node MN11, it first arrives at GW2.
GW2 does not find any location information of the MN and therefore
sends the packet to GW1 in accordance with routing table with the IP
prefix of HoA11. If the MN is in the network served by GW1, the
packet will be forwarded to MN11. In this case shown in the figure,
Chan Expires September 4, 2012 [Page 16]
Internet-Draft DMM-Architecture March 2012
MN11 has moved to the network served by GW3, and LM1 contains the
binding of HoA11 to the IP address of GW3. GW1 therefore tunnels the
packet to GW3. GW3 contains the binding HoA to AR32 and therefore
tunnels the packet to AR32 which in turn delivers the packet to MN11.
Meanwhile based on the source IP address of the packet, GW1 finds out
that the packet had come from GW2. It informs GW2 to cache the
binding HoA11 to GW3. When subsequent packets to MN11 reach GW2, GW2
finds out from its cache memory this binding so that it will tunnel
these subsequent packets directly to GW3 (Figure 7. ).
Chan Expires September 4, 2012 [Page 17]
Internet-Draft DMM-Architecture March 2012
Network1 Network2 Network3
+---+ +---+ +---+
|LM1|Binding |LM3| |LM2|
+---+HoA11:GW3 +---+ +---+
|\\ /|\ //|
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \/ | \/ / |
| \ / \ | / \ / |
| \ / \ | / \ / |
| \/ \|/ \/ |
| /\ /|\ /\ |
| / \ / | \ / \ |
| / \ / | \ / \ |
| / /\ | /\ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
|// \|/ \\|
+---+ +---+ +---+
|MR1| |MR3|<=============|MR2|
|GW1| |GW3|Binding |GW2|Cache
+---+ +---+HoA11:AR32 +---+HoA11:GW3
| /| |\
| / | | \
| / | | \
| / | | \
| / v | \
AR11 AR31 AR32 AR21 AR22
. | | ^ ^ ^
. | | / | |
. | v / | |
HoA11 MN31 MN11 CN20 CN21 CN22
Figure 7. Subsequent packets destined to HoA11 via GW2.
Note that if packets sent to HoA11 from other CNs (CN22 and CN20 in
Figure 7) reaches GW2, GW2 will also use this binding in its cache
memory to tunnel the packet to GW3. Finally, this cache at GW2 will
timeout when no more such packets are reaching GW2.
This session has used the colocation at the gateway router as an
example, while noting that the colocation can also be at the access
router and also that the gateway and the access router may merge in a
flattened network. When the MR is colocated at the access router,
Chan Expires September 4, 2012 [Page 18]
Internet-Draft DMM-Architecture March 2012
Figure 6 is modified as shown in Figure 8.
Network1 Network2 Network3
+---+ +---+ +---+
|LM1|Binding |LM3| |LM2|
+---+HoA11:AR3 +---+ +---+
|\\ /|\ //|
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \/ | \/ / |
| \ / \ | / \ / |
| \ / \ | / \ / |
| \/ \|/ \/ |
| /\ /|\ /\ |
| / \ / | \ / \ |
| / \ / | \ / \ |
| / /\ | /\ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
|// \|/ \\|
+---+ +---+ +---+
|MR1| |MR3| |MR2|
|AR1| |AR3| |AR2|
+---+ +---+ +---+
. /|HoA11:link addr |
. / | |
. / | |
. / | |
. / | |
HoA11 MN31 MN11 CN21
Figure 8. Location management information.
Chan Expires September 4, 2012 [Page 19]
Internet-Draft DMM-Architecture March 2012
Network1 Network2 Network3
+---+ +---+ +---+
|LM1|Binding |LM3| |LM2|
+---+HoA11:AR3 +---+ +---+
|\\ /|\ //|
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \/ | \/ / |
| \ / \ | / \ / |
| \ / \ | / \ / |
| \/ \|/ \/ |
| /\ /|\ /\ |
| / \ / | \ / \ |
| / \ / | \ / \ |
| / /\ | /\ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
|// \|/ \\|
+---+ +---+ +---+
|MR1| |MR3|<=============|MR2|
|AR1| |AR3| |AR2|Cache
+---+ +---+ +---+HoA11:AR3
. / |HoA11:link addr ^ ^ ^
. / | / | \
. / | / | \
. / v / | \
HoA11 MN31 MN11 CN20 CN21 CN22
Figure 9. Subsequent packets destined to HoA11 via AR2.
8. Security Considerations
TBD
9. IANA Considerations
None
10. Acknowledgments
This document has benefited from discussions with Frank Xia, Justin
Chan Expires September 4, 2012 [Page 20]
Internet-Draft DMM-Architecture March 2012
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.PMIP-dmc]
Koh, S., Kim, J., Jung, H., and Y. Han, "Use of Proxy
Mobile IPv6 for Distributed Mobility Control",
draft-sjkoh-mext-pmip-dmc-01 (work in progress),
March 2011.
[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-approaches]
Patil, Ed., B., Williams, C., and J. Korhonen, "Approaches
to Distributed mobility management using Mobile IPv6 and
its extensions", draft-patil-mext-dmm-approaches-02 (work
in progress), October 2011.
[I-D.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.dmm-dma]
Seite, P. and P. Bertin, "Distributed Mobility Anchoring",
draft-seite-dmm-dma-00 (work in progress), February 2012.
[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-pmip]
Bernardos, CJ., de la Oliva, A., Giust, F., and T. Melia,
"A PMIPv6-based solution for Distributed Mobility
Management", draft-bernardos-dmm-pmip-00 (work in
Chan Expires September 4, 2012 [Page 21]
Internet-Draft DMM-Architecture March 2012
progress), January 2012.
[I-D.dmm-pmip-based]
Liu, D., Song, J., and W. Luo, "PMIP Based Distributed
Mobility Management Approach",
draft-liu-dmm-pmip-based-approach-01 (work in progress),
December 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.
[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, 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
Chan Expires September 4, 2012 [Page 22]
Internet-Draft DMM-Architecture March 2012
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 R. 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.
[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.
[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 September 4, 2012 [Page 23]
