Internet DRAFT - draft-chan-dmm-framework
draft-chan-dmm-framework
DMM H. Chan
Internet-Draft Huawei Technologies
Intended status: Informational P. Seite
Expires: April 24, 2014 France Telecom - Orange
K. Pentikousis
EICT GmbH
A. Dutta
ATT
October 21, 2013
Distributed Mobility Management Framework
draft-chan-dmm-framework-03
Abstract
This document introduces a framework for mobility management
protocols in terms of their key, abstract logical functions. We
explain how the framework is capable of presenting a unified view,
reducing the clutter that prevents a casual reader from understanding
the commonalities between different approaches in mobility
management. A first order application of this framework is to enable
us to examine previously standardized mobility management protocols,
such as MIPv6 and PMIPv6 (as well as several of their extensions),
and describe their core functionality in terms of different
configurations of the logical functions defined by the framework.
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 April 24, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Chan, et al. Expires April 24, 2014 [Page 1]
Internet-Draft DMM Framework October 2013
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
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Mobility Management Logical Functions . . . . . . . . . . . . 4
4. Mobility Protocol Functional Decomposition . . . . . . . . . . 6
4.1. Decomposing Mobile IPv6 . . . . . . . . . . . . . . . . . 6
4.2. From MIPv6 to PMIPv6 . . . . . . . . . . . . . . . . . . . 7
4.3. Hierarchical Mobile IPv6 . . . . . . . . . . . . . . . . . 9
4.4. Distributing Mobility Anchors . . . . . . . . . . . . . . 10
4.5. Migrating Home Agents . . . . . . . . . . . . . . . . . . 11
5. DMM Functional Decomposition Scenarios . . . . . . . . . . . . 12
5.1. Flat Network Scenario . . . . . . . . . . . . . . . . . . 13
5.1.1. Network-based Mobility Management . . . . . . . . . . 13
5.1.2. Client-based Mobility Management . . . . . . . . . . . 14
5.2. DMM with Control and Data Plane Separation . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Comparing against DMM requirements . . . . . . . . . 19
A.1. First DMM requirement: distributed processing . . . . . . 19
A.2. Second DMM requirement: Transparency to upper layers
when needed . . . . . . . . . . . . . . . . . . . . . . . 20
A.3. Third DMM requirement: IPv6 deployment . . . . . . . . . 20
A.4. Fourth DMM requirement: Existing mobility protocols . . . 20
A.5. Fifth DMM requirement: co-existence . . . . . . . . . . . 20
A.6. Sixth DMM requirement: Security considerations . . . . . 20
A.7. Seventh DMM requirement: multicast . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Chan, et al. Expires April 24, 2014 [Page 2]
Internet-Draft DMM Framework October 2013
1. Introduction
While there is ongoing research on new protocols for distributed
mobility management (DMM), it has also been proposed, e.g., in
[Paper-Distributed.Mobility.PMIP] and in other publications, that a
DMM architecture can be designed using primarily existing mobility
management protocols with some extensions. This is reflected in the
requirement included in [I-D.ietf-dmm-requirements]: distributed
mobility management is to first use existing protocols and their
extensions before considering new protocol designs. Although this a
key requirement as we move forward, it does not point to which
extensions are needed let alone how to devise them.
Mobile IPv6 [RFC6275], for instance, which is a logically centralized
mobility management approach addressing primarily hierarchical mobile
networks, has numerous variants and extensions including, PMIPv6
[RFC5213], Hierarchical MIPv6 (HMIPv6) [RFC5380], Fast MIPv6 (FMIPv6)
[RFC5568] [RFC4988], Proxy-based FMIPv6 (PFMIPv6) [RFC5949], just to
name a few. These variants or extensions of MIPv6 have been
developed over the years owing to the different needs that have been
arising ever since the first MIP specification came into life. This
document argues that we can gain much more insight into the design
space of DMM protocols by abstracting the functionality of existing
mobility management protocols in terms of logical functions.
Different variants of existing mobility management protocols can then
be expressed as different design variations of how these logical
functions are put together. The result is a rich framework that can
express sophisticated functionalities in a more straightforward
manner. What is more, this document shows how to reconfigure these
logical functions towards various distributed mobility management
designs.
The rest of this document is organized as follows. After setting the
stage with conventions and terminology in the following section,
Section 3 introduces the framework abstractions, based on common
functionality we observe in the current crop of mobility management
protocols. This includes three logical functions, namely, home
address allocation, routing management and location management. Such
functional decomposition will enable us to clearly separate data and
control plane functionality, and gives us the flexibility in an
implementation to position said logical functions at their most
appropriate places in the system design. Next, Section 4 shows that
these logical functions can indeed perform the same functions as
major existing mobility protocols. These functions therefore become
the foundation for a unified framework upon which different designs
of distributed mobility management may be built upon. Finally,
Section 5 presents scenarios where the functional aspects of the
framework are illustrated.
Chan, et al. Expires April 24, 2014 [Page 3]
Internet-Draft DMM Framework October 2013
2. Conventions and Terminology
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].
All general mobility-related terms and their acronyms used in this
document are to be interpreted as defined in the Mobile IPv6 base
specification [RFC6275] and in the Proxy Mobile IPv6 specification
[RFC5213]. This includes terms such as mobile node (MN),
correspondent node (CN), home agent (HA), home address (HoA), care-
of-address (CoA), local mobility anchor (LMA), and mobile access
gateway (MAG).
In addition, this document uses the following term:
Home network of an application session (or of an HoA) is the network
that has allocated the IP address (HoA) used for the session
identifier by the application running in an MN. An MN may be
running multiple application sessions, and each of these sessions
can have a different home network.
3. Mobility Management Logical Functions
Functional entity (FE) decomposition is an often-used engineering
approach that enables us to look at the similarities and differences
of complex systems while keeping track of their important operational
aspects. Earlier work, for instance, in the European research
project Ambient Networks investigated how to create an advanced and
forward-looking architecture aiming primarily for mobile and wireless
networks [Book-AN]. A key goal was to design mechanisms that can be
deployed in a variety of settings (ad-hoc or operator-controlled) and
scale from small home networks with little human supervision to
sensor networks deployed over large geographical areas with limited
resources, to large professionally-managed infrastructure networks.
The project put forward the concept of the Ambient Control Space
(ACS) which relies on only three interfaces; interested readers can
find more details in [Book-AN].
Within the ACS, novel mobility management mechanisms were developed
based on the concept of self-containing Functional Entities (FEs)
which featured well-defined interfaces and interactions with each
other. This systematic decomposition enabled the development of
several mobility management mechanisms which put emphasis on
different aspects. Examples of these approaches include the Generic
Link Layer [Paper-GLL], Multi-radio Resource Management [Paper-MRRM],
and [Paper-NODEID], which has some similarities with HIP. Later work
Chan, et al. Expires April 24, 2014 [Page 4]
Internet-Draft DMM Framework October 2013
in this area capitalized on the established FEs within the ACS to
define new mechanisms, that were not originally envisioned, such as
[Paper-ANHASA].
Following this tradition, this document applies a similar approach to
logically decomposing mobility management functions. This way we can
establish a common framework that will enable us to reason about DMM
functionality with well-defined and well-understood FEs or logical
functions. As a first step, the DMM Framework presented in this
document demonstrates that the existing mobility management functions
of MIPv6, PMIPv6, and HMIPv6 can be abstracted into the following
logical functions:
1. Session identification (SID): An MN may use an SID to enable
session continuity for an application during handover.
Alternatively, a separate IP address different from the routing
IP address, such as that used previously in the home network
where the application was initiated, may be used as the SID.
Then, this function is tied to the IP prefix function at the home
network. In addition, an MN with multiple ongoing applications
may use multiple prefixes. This function is able to associate
each prefix with the applications actively using the prefix and
release the prefix when no application needs to use it anymore.
2. Location management (LM): The LM function keeps track of the
internetwork location of an MN which may change its IP address as
it moves. The information may associate with each SID, the IP
routing address of the MN, or of a node that can forward packets
destined to the MN.
In a client-server model of the system, location query and update
messages may be exchanged between the client (LMc) and the server
(LMs). Optionally, one (or more) proxy may exist between the LMs
and the LMc, i.e., LMs-proxy-LMc. Then, to the LMs, the proxy
behaves like the LMc; to the LMc, the proxy behaves like the LMs.
3. Routing Management (RM) function: In principle, it is possible to
update the routing tables according to the LM information. Yet
it is sometimes not practical or not scalable to update the
routing tables dynamically to reflect the fast changes of
locations especially when a very large number of MNs are in the
Internet. The RM function is then an additional routing function
beyond those provided by the routing tables, such as forwarding
packets using a tunnel, rewriting a packet header to route using
another IP address. It is often sufficient to have this
additional function in only a limited number of special routers.
Then, the RM function in these routers will need to intercept the
packets to/from the MN and forward the packets, based on the
Chan, et al. Expires April 24, 2014 [Page 5]
Internet-Draft DMM Framework October 2013
internetwork location information, either to the destination or
to some other network element that knows how to forward the
packets to the destination.
In addition, the Access Router (AR) logical function provides first-
hop network access and includes functionality below the network
layer, e.g. radio communication facilities. An AR may provide home
address allocation as well as act as RM.
4. Mobility Protocol Functional Decomposition
This section shows that existing mobility management protocols can be
expressed as different configurations of the logical functions
introduced in Section 3 above. Using these generic logical
functions, we will build up the existing mobility protocols one step
at a time in the following sequence: MIPv6, PMIPv6, HMIPv6, and HAHA.
Functions are added and modified as needed in each step.
4.1. Decomposing Mobile IPv6
Fig. 1 illustrates the Mobile IPv6 [RFC6275] functional decomposition
using the logical functions introduced in Section 3. The combination
of the RM, LM and HoA allocation logical functions in Network1
effectively defines the home agent or the mobility anchor. In the
depicted network scenario, the mobile node designated as MN11 was
originally attached to Network1 and was allocated an IP prefix for
its home address (HoA11). At a later stage, MN11 moves to Network3,
where it is allocated a new prefix to configure the IP address IP32.
LM1 maintains the binding HoA11:IP32 so that packets from its
correspondent node CN21 in Network2 destined to HoA11 can be
intercepted by RM1, which will then tunnel them to IP32. MN11 must
perform mobility signaling using the LU function.
Chan, et al. Expires April 24, 2014 [Page 6]
Internet-Draft DMM Framework October 2013
Network1 Network3 Network2
SID11,IP32
+-----+
| LM1 |
+-----+
location=IP32
HoA1 alc IP3 alc IP2 alc
|
|
+-----+
| RM1 |
+-----+
.
. +----+ +----+ +----+
. | | |MN11| | |
. |MN31| |+RM | |CN21|
. | | |+LMc| | |
. +----+ +----+ +----+
SID11 IP31 IP32,
=IP11 SID11
Figure 1. Functional decomposition of Mobile IPv6
4.2. From MIPv6 to PMIPv6
The functional decomposition of Proxy Mobile IPv6 [RFC5213] according
to the proposed framework is shown in Fig. 2. In PMIPv6, the
combination of LM, RM, and HoA allocation effectively defines the
Local Mobility Anchor (LMA). The combination of AR and LU together
with additional signaling with MN comprises the Mobile Access Gateway
(MAG). In the figure, MN11 is attached to the access router AR31
which has the IP address IP31 in Network3. LM1 maintains the binding
HoA11:IP31. The access router AR31 also behaves like a home link to
MN11 so that MN11 can use its original IP address HoA11.
Chan, et al. Expires April 24, 2014 [Page 7]
Internet-Draft DMM Framework October 2013
Network1 Network3 Network2
SID11,IP31
+-----+
| LM1 |
+-----+
HoA1 alc IP3 alc IP2 alc
|
|
+-----+
| RM1 |
+-----+
.
. +----+ +----+
. |AR31| | |
. |+RM | |CN21|
. |+LMc| | |
. +----+ +----+
SID11 IP31
=IP11 |
|
+----+
|MN11|
+----+
SID11
=IP11
Figure 2. Functional decomposition of PMIPv6
MIPv6 and PMIPv6 both employ the same concept of separating the
session identifier (HoA) from the routing address (CoA). Fig. 3
contrasts (a) MIPv6 with (b) PMIPv6 by illustrating the destination
IP address in the network-layer header as a packet traverses the
network from the CN to the MN. Note that MIPv6 and PMIPv6 bundle
three mobility management logical functions, namely, LM1, IP1 prefix
allocation and RM1 into the home agent (HA) and Local Mobility Anchor
(LMA), respectively.
Fig. 3 shows that, as far as data-plane traffic is concerned, routing
from CN to MN+LU in MIPv6 is similar to the route from CN to AR+LU in
PMIPv6. The difference is in that in the former case, the MN with
the LU function is substituted by the combination of the AR with the
LU function and the MN. While additional signaling is needed to
enable the combination of AR+LU and MN to behave like MN+LU in MIPv6,
such signaling can be confined between the AR+LU and the MN only. It
can therefore be seen under this unified formulation, that a host-
based mobility management protocol can be translated using this
substitution into a network-based mobility management protocol and
Chan, et al. Expires April 24, 2014 [Page 8]
Internet-Draft DMM Framework October 2013
vice versa.
(a) MIPv6:
+---+ +---+---+ +---+
|SID| --> |SID|SID| |SID|
| | | |---| |---|
| | | |IP | ==> |IP |
+---+ +---+---+ +---+
CN RM MN+RM+LMc
(b) PMIPv6:
+---+ +---+---+ +---+---+ +---+
|SID| --> |SID|SID| |SID|SID| --> |SID|
| | | |---| |---| | | |
| | | |IP | ==> |IP | | | |
+---+ +---+---+ +---+---+ +---+
CN RM AR+RM+LMc MN
Figure 3. Network layer in the protocol stack of packets sent from
the CN and tunneled (a) to the MN+RM+LMc in MIPv6; and (b) to the AR+
RM+LMc in PMIPv6 showing the destination IP address as the packet
traverses from the CN to the MN.
4.3. Hierarchical Mobile IPv6
The functional decomposition of Hierarchical Mobile IPv6 [RFC5380] is
shown in Fig. 4. Besides the logical functions LM1, RM1, and HoA1
prefix allocation in Network1, as we have seen above for MIPv6 and
PMIPv6, there is an RM function (RM3) in the visited network
(Network3). RM3 acts also as a proxy between LM1 and MN11 in the
hierarchical LM function LM1--RM3--MN11. That is, LM1 maintains the
LM binding HoA11:RM3 while RM3 tracks the LM binding HoA11:IP32. The
combined function of RM and the LM proxy function is the Mobility
Anchor Point (MAP).
Chan, et al. Expires April 24, 2014 [Page 9]
Internet-Draft DMM Framework October 2013
Network1 Network3 Network2
+-----+
| LM1 |
+-----+
HoA1 alc IP3 alc IP2 alc
|
|
+-----+ +-----+
| RM1 | | RM3 |
| | |+ LM |
| | |proxy|
+-----+ +-----+
. / \
. / \
. / \
. +----+ +----+ +----+
. |AR31| |MN11| | |
. |+RM | |+RM | |CN21|
. |+LMc| |+LMc| | |
. +----+ +----+ +----+
SID11 IP31 SID11,
=IP11 | IP32
|
+----+
|MN31|
+----+
SID11
=IP11
Figure 4. Functional decomposition of Hierarchical Mobile IPv6
Note that as depicted in Fig. 4, if MN11 takes the place of MN31
which is attached to AR31, the resulting mobility management becomes
network-based.
4.4. Distributing Mobility Anchors
As we have seen so far, the framework is sufficiently expressive to
enable us to decompose the major MIPv6 variants. It is possible to
replicate the mobility anchoring function for any of MIPv6, PMIPv6,
or HMIPv6, in multiple networks as shown in Fig. 5 which illustrates
such an example with three networks.
Chan, et al. Expires April 24, 2014 [Page 10]
Internet-Draft DMM Framework October 2013
Network1 Network3 Network2
+-----+ +-----+ +-----+
| LM1 | | LM3 | | LM2 |
+-----+ +-----+ +-----+
HoA1 alc HoA3 alc HoA2 alc
| | |
| | |
+-----+ +-----+ +-----+
| RM1 | | RM3 | | RM2 |
+-----+ +-----+ +-----+
. / \
. / \
. / \
. +----+ +----+ +----+
. |AR31| |MN11| |CN21|
. |+RM | |+RM | | |
. |+LMc| |+LMc| | |
. +----+ +----+ +----+
SID11 IP31 SID11,
=IP11 | IP32
|
+----+
|MN31|
+----+
SID11
=IP11
Figure 5. Distributing mobility anchors using the DMM Framework
logical functions
4.5. Migrating Home Agents
When all logical functions of the Framework are bundled into a single
entity e.g., a home agent in MIPv6 or a local mobility anchor in
PMIPv6, in a single network, the result is triangular routing when
the MN and the CN are in networks close to each other but are far
from the anchor point. A method to solve the triangle routing
problem is to duplicate the anchor points in many networks in
different geographic locations as advocated in
[Paper-Migrating.Home.Agents]. A functional decomposition of
Migrating Home Agents is shown in Fig. 6: the RM function is
available in each of the three networks Network1, Network2, and
Network3. The LM function in each network (LM0) contains the LM
information for all three networks. Each RM in each network
advertises the HoA IP prefixes of all these networks using anycast.
Traffic from CN21 in Network2 destined to HoA11 will therefore be
intercepted by the RM nearest to the CN, i.e. RM2 in the example of
Fig. 6. Using the LM information in LM0, RM2 will use the binding
Chan, et al. Expires April 24, 2014 [Page 11]
Internet-Draft DMM Framework October 2013
HoA11:IP32 to tunnel the packets to MN11.
Network1 Network3 Network2
+-----+ +-----+ +-----+
| LM0 |------| LM0 |------| LM0 |
+-----+ +-----+ +-----+
HoA1 alc HoA3 alc HoA2 alc
| | |
| | |
+-----+ +-----+ +-----+
| RM1 | | RM3 | | RM2 |
+-----+ +-----+ +-----+
. / \
. / \
. / \
. +----+ +----+ +----+
. |AR31| |MN11| | |
. |+RM | |+RM | |CN21|
. |+LMc| |+LMc| | |
. +----+ +----+ +----+
SID11 IP31 SID11,
=IP11 | IP32
|
+----+
|MN31|
+----+
SID11
=IP11
Figure 6. Functional decomposition of Migrating Home Agents
Similarly, traffic originating from MN11 will be served by its
nearest RM (RM3). Triangular routing is therefore avoided. Yet the
synchronization of all home agents becomes a challenge as discussed
in [Paper-SMGI]. In addition, the amount of signaling traffic
necessary for synchronizing the home agents may become excessive when
both the number of mobile nodes and the number of home agents
increase.
As before, if MN11 in Fig. 6 takes the place of MN31 which is
attached to AR31, the resulting mobility management becomes network-
based.
5. DMM Functional Decomposition Scenarios
This section covers the functional description of DMM. Basically,
Chan, et al. Expires April 24, 2014 [Page 12]
Internet-Draft DMM Framework October 2013
the scenarios present a way to distribute the logical mobility
functions.
5.1. Flat Network Scenario
In a flat network, the logical functions may all be located at the AR
as shown in Figs. 7 and 8, respectively. For example,
[I-D.seite-dmm-dma] and [I-D.bernardos-dmm-distributed-anchoring] are
PMIPv6-based implementations of this scenario. These two figures
depict the network- and client-based distributed mobility management
scenarios, respectively. AR is expected to support the HoA
allocation function. Then, depending on the mobility situation of
the MN, the AR can run different functions:
1. AR can act as a standard IP router;
2. AR can provide the RM function (i.e. act as mobility anchor);
3. AR can provide the LU function;
4. AR can provide both RM and LU functions.
5.1.1. Network-based Mobility Management
The functional decomposition of network-based mobility management is
depicted in Fig. 7. In case (1), MN1 attaches to AR1. AR advertises
the prefix HoA1 to MN1 and then acts as a legacy IP router. MN1
initiates a communication with CN11.
In case (2), MN1 performs a handover from AR1 to AR3 while
maintaining ongoing IP communication with CN11. AR1 becomes the
mobility anchor for the MN1-CN11 IP communication: AR1 runs RM and LM
functions on behalf of MN1. AR3 performs LU up to the LM in AR1: AR3
indicates to AR1 the new location of the MN1. AR3 allocates a new IP
prefix (HoA3) for new IP communications. That is, HoA3 is used for
all new IP communications, e.g., if MN1 initiates IP communication
with CN21. AR3 shall act as a legacy IP router for MN1-CN21
communication.
In case (3), MN1 performs a handover from AR1 to AR2 with ongoing IP
communication with CN11 and CN21. AR1 is the mobility anchor for the
MN1-CN11 IP communication. AR3 becomes the mobility anchor for the
MN1-CN21 IP communication. Both AR1 and AR3 run RM and LM functions
for MN1, respectively, anchoring HoA1 and HoA3. AR2 performs
location updates up to the LMs in AR1 and AR3 for respectively
relocate HoA1 and HoA3.
Chan, et al. Expires April 24, 2014 [Page 13]
Internet-Draft DMM Framework October 2013
Network1 Network1 Network3
+----+ HoA1 alc +----+ HoA1 alc HoA3 al +----+
|CN11| +-----+ |CN11| +-----+ +-----+ |CN21|
| |------| | | |------| RM1 |------| |------- | |
+----+ | | +----+ | LM1 |------|LU31 | +----+
| AR1 | | AR1 | |AR3 |
| | | | | |
+-----+ +-----+ +-----+
| |
| |
| |
+----+ +----+
|MN1 | |MN1 |
| | | |
+----+ +----+
HoA11 HoA11,
HoA31
(1) (2)
Network2
Network1 HoA2 al
+----+ HoA1 alc +-----+
|CN11| +-----+ | |
| |------| RM1 |-----------------|LU21 |-------+
+----+ | LM1 |-----------------|AR2 | |
| AR1 | | | |
| | Network3 +-----+ |
+-----+ HoA3 al | | +----+
+-----+ | | |MN1 |
+----+ |RM3 |------ | | |
|CN21| |LM3 |-------- +----+
| |------| | HoA11,
+----+ |AR3 | HoA31
+-----+ (3)
Figure 7. Network-based DMM architecture for a flat network
5.1.2. Client-based Mobility Management
The functional decomposition of client-based mobility management is
depicted in Fig. 8. In case (1), MN1 attaches to AR1. AR advertises
the prefix HoA1 to MN1 and then acts as a legacy IP router. MN1
initiates a communication with CN11.
In case (2), MN1 performs a handover from AR1 to AR3 while
maintaining ongoing IP communication with CN11. AR1 becomes the
mobility anchor for the MN1-CN11 IP communication: AR1 runs RM and LM
functions for MN1. The MN performs LU directly up to the LM in AR1
Chan, et al. Expires April 24, 2014 [Page 14]
Internet-Draft DMM Framework October 2013
or via AR3; in this case AR3 acts as a proxy locator (pLU) (e.g. as a
FA in MIPv4). AR3 allocates a new IP prefix (HoA3) for new IP
communications. HoA3 is supposed to be used for new IP
communications, e.g., if MN1 initiates IP communication with CN21.
AR3 shall act as a legacy IP router for MN1-CN21 communication.
Network1 Network1 Network3
+----+ HoA1 alc +----+ HoA1 alc +----+
|CN11| +-----+ |CN | +-----+ +-----+ |CN21|
| |------| | | |------| RM1 |------| |------- | |
+----+ | | +----+ | LM1 |------|pLU31| +----+
| AR1 | | AR1 | |AR31 |
| | | | | |
+-----+ +-----+ +-----+
| |
| |
| |
+----+ +----+
|MN1 | |MN1 |
| | |LU31|
+----+ +----+
HoA11 HoA11,
IP31
(1) (2)
Figure 8. Client-based DMM architecture for a flat network
5.2. DMM with Control and Data Plane Separation
This section considers a scenario which involves multiple RMs and a
distributed LM database. The different use case scenarios of
distributed mobility management are described in
[I-D.yokota-dmm-scenario] as well as in
[Paper-Distributed.Mobility.Review]. The functional decomposition
described in this document can be used to understand better the data
and control plane separation.
Fig. 9 shows an example DMM topology with the same three networks we
have been using in Fig. 5. As in Fig. 5, each network in Fig. 9 has
its own IP prefix allocation function. In the data plane, the
routing management function is distributed to multiple locations at
the RMs so that routing can be optimized. In the control plane, the
RMs may exchange information with each other.
In addition to these features, the LM function in Fig. 9 is a
distributed database, possibly implemented with multiple virtual or
physical servers, handling the mapping of HoA to CoA. To perform
Chan, et al. Expires April 24, 2014 [Page 15]
Internet-Draft DMM Framework October 2013
routing management, the RMs need the location information which is
maintained at LM1, LM2, and LM3. The RMs are, therefore, the clients
of the LM servers and may also send location updates to the LM as the
MNs perform the handover. The location information may either be
pulled from the LM servers by the RM, or pushed to the RM by the LM
servers. In addition, the RM may also cache a limited amount of
location information.
Network1 Network3 Network2
+-----+ +-----+ +-----+
| LM1 | | LM3 | | LM2 |
+-----+ +-----+ +-----+
HoA1 alc HoA3 alc HoA2 alc
| \ \ / | \ / / |
| \ \ / | \ / / |
| \ \/ | \/ / |
| \ / \ | / \ / |
| \/ \|/ \/ |
| /\ /|\ /\ |
| / \ / | \ / \ |
| / /\ | /\ \ |
| / / \ | / \ \ |
| / / \ | / \ \ |
+-----+ +-----+ +-----+
| RM1 |------| RM3 |------| RM2 |
+-----+ +-----+ +-----+
. / \
. / \
. / \
. +----+ +----+ +----+
. |AR31| |MN11| | |
. |+RM | |+RM | |CN21|
. |+LMc| |+LMc| | |
. +----+ +----+ +----+
SID11 IP31 SID11,
=IP11 | IP32
|
+----+
|MN31|
+----+
SID11
=IP11
Figure 9. DMM with Control and Data Plane Separation
Fig. 9 illustrates three RMs (RM1, RM2, and RM3) in three networks.
In this scenario we take that MN11 has moved from Network1 supported
Chan, et al. Expires April 24, 2014 [Page 16]
Internet-Draft DMM Framework October 2013
by RM1 and LM1 to Network3 supported by RM3 and LM3. MN11 may use
the homa address (HoA11) allocated to it when it was directly
connected to the former network for those application sessions that
were started when the mobile node was attached there and do require
session continuity after the handover to the latter network. When
MN11 is connected to Network1, no location management is needed; LM1
will not keep an entry for HoA11. After MN11 handovers to Network3,
the LM1 server maintains a mapping of HoA11 to RM3. That is, LM1
points to Network3 and it is this network that will keep track of how
to reach MN11. Such a hierarchical mapping can prevent frequent
signaling updates to LM1, as MN11 performs intra-network handover(s)
within the Network3 domain. In other words, the concept of
hierarchical mobile IP [RFC5380] is applied here for location
management only but not for data plane routing.
6. Security Considerations
TBD
7. IANA Considerations
This document presents no IANA considerations.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[Book-AN] Niebert, N., Schieder, A., Zander, J., and R. Hancock
(Eds.), "Ambient networks: co-operative mobile networking
for the wireless world.", Wiley, 2007.
[I-D.bernardos-dmm-distributed-anchoring]
Bernardos, CJ. and JC. Zuniga, "PMIPv6-based distributed
anchoring", draft-bernardos-dmm-distributed-anchoring-01
(work in progress), September 2012.
[I-D.ietf-dmm-requirements]
Chan (Ed.) et al., H., "Requirements for Distributed
Mobility Management", draft-ietf-dmm-requirements-06 (work
in progress), December 2012.
Chan, et al. Expires April 24, 2014 [Page 17]
Internet-Draft DMM Framework October 2013
[I-D.seite-dmm-dma]
Seite, P., Bertin, P., and JH. Lee, "Distributed Mobility
Anchoring", draft-seite-dmm-dma-06 (work in progress),
January 2013.
[I-D.yokota-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.
[Paper-ANHASA]
Pentikousis, K., Aguero, R., Gebert, J., Galache, J.,
Blume, O., and P. Paakkonen, "The Ambient Networks
heterogeneous access selection architecture", Mobility,
Multiaccess, and Network Management (M2NM) 2007. First
Ambient Networks Workshop on. Sydney, Australia, October
2007, pp. 49-54, October 2007.
[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-GLL]
Koudouridis, G., Aguero, R., Alexandri, E., Choque, J.,
Dimou, K., Karimi, H., Lederer, H., Sachs, J., and R.
Sigle, "Generic link layer functionality for multi-radio
access networks", Proc. IST Mobile and Wireless
Communication Summit 2005., 2005.
[Paper-MRRM]
Berggren, F., Bria, A., Badia, L., Karla, I., Litjens, R.,
Magnusson, P., Meago, F., Tang, H., and R. Veronesi,
"Multi-radio resource management for ambient networks",
Personal, Indoor and Mobile Radio Communications (PIMRC)
2005. IEEE 16th International Symposium on. Vol. 2, pp.
942-946, 2005.
[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
Chan, et al. Expires April 24, 2014 [Page 18]
Internet-Draft DMM Framework October 2013
Networking Technologies, December 2006.
[Paper-NODEID]
Ahlgren, B., Eggert, L., Ohlman, B., and A. Schieder,
"Ambient networks: Bridging heterogeneous network
domains", Personal, Indoor and Mobile Radio
Communications (PIMRC) 2005. IEEE 16th International
Symposium on. Vol. 2, pp. 937-941, 2005.
[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.
[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.
[RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568,
July 2009.
[RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F.
Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949,
September 2010.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
Appendix A. Comparing against DMM requirements
This section examines how the framework meets the DMM requirements.
A.1. First DMM requirement: distributed processing
The framework has defined a set of mm functions which can be
implemented in a distributed fashion. As further evidence, the
document explains how the mm functions can be used to implement in a
distributed manner the major mm protocols (MIPv6, PMIPv6, HMIP, DMA,
MHA).
Chan, et al. Expires April 24, 2014 [Page 19]
Internet-Draft DMM Framework October 2013
A.2. Second DMM requirement: Transparency to upper layers when needed
In the framework, transparency depends on how the RM functions is
implemented. This draft has already shown that using the framework
one can express, for example, PMIP and DMA, which are transparent to
the upper layers.
A.3. Third DMM requirement: IPv6 deployment
The framework is not tied to a particular IP version, and therefore
supports IPv6 deployment.
A.4. Fourth DMM requirement: Existing mobility protocols
This draft has already described how to express the functionality of
several mm protocols (MIPv6, PMIPv6, HMIP, DMA, MHA). More cases can
be added as feedback is received.
A.5. Fifth DMM requirement: co-existence
The framework enables the expression of existing protocols in
functions that can be extended to provide distributed mobility
support, and can be made backwards compatible with existing
implementations.
A.6. Sixth DMM requirement: Security considerations
Security risks are associated with the particular DMM solution. The
framework is flexible and does not restrict DMM solutions in a way
that the DMM solution can increase security risks.
A.7. Seventh DMM requirement: multicast
It appears possible to extend the framework by decomposing multimob
solutions with the framework.
Authors' Addresses
H Anthony Chan
Huawei Technologies
5340 Legacy Dr. Building 3
Plano, TX 75024
USA
Email: h.a.chan@ieee.org
Chan, et al. Expires April 24, 2014 [Page 20]
Internet-Draft DMM Framework October 2013
Pierrick Seite
France Telecom - Orange
4, rue du Clos Courtel, BP 91226
Cesson-Sevigne 35512
France
Email: pierrick.seite@orange-ftgroup.com
Kostas Pentikousis
EICT GmbH
Email: k.pentikousis@eict.de
Ashutosh Dutta
ATT
200 Laurel Ave S
Middletown, NJ 07748
USA
Email: ashutosh.dutta@ieee.org
Chan, et al. Expires April 24, 2014 [Page 21]
