draft-ietf-dmm-best-practices-gap-analysis-06.txt   draft-ietf-dmm-best-practices-gap-analysis-07.txt 
DMM D. Liu, Ed. DMM D. Liu, Ed.
Internet-Draft China Mobile Internet-Draft China Mobile
Intended status: Informational JC. Zuniga, Ed. Intended status: Informational JC. Zuniga, Ed.
Expires: January 5, 2015 InterDigital Expires: March 14, 2015 InterDigital
P. Seite P. Seite
Orange Orange
H. Chan H. Chan
Huawei Technologies Huawei Technologies
CJ. Bernardos CJ. Bernardos
UC3M UC3M
July 4, 2014 September 10, 2014
Distributed Mobility Management: Current practices and gap analysis Distributed Mobility Management: Current practices and gap analysis
draft-ietf-dmm-best-practices-gap-analysis-06 draft-ietf-dmm-best-practices-gap-analysis-07
Abstract Abstract
The present document analyzes deployment practices of existing IP This document analyzes deployment practices of existing IP mobility
mobility protocols in a distributed mobility management environment. protocols in a distributed mobility management environment. It then
It then identifies existing limitations when compared to the identifies existing limitations when compared to the requirements
requirements defined for a distributed mobility management solution. defined for a distributed mobility management solution.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 5, 2015. This Internet-Draft will expire on March 14, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 21
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Functions of existing mobility protocols . . . . . . . . . . 3 3. Functions of existing mobility protocols . . . . . . . . . . 3
4. DMM practices . . . . . . . . . . . . . . . . . . . . . . . . 5 4. DMM practices . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. IP flat wireless network . . . . . . . . . . . . . . . . 6 4.2. IP flat wireless network . . . . . . . . . . . . . . . . 6
4.2.1. Host-based IP DMM practices . . . . . . . . . . . . . 7 4.2.1. Host-based IP DMM practices . . . . . . . . . . . . . 7
4.2.2. Network-based IP DMM practices . . . . . . . . . . . 12 4.2.2. Network-based IP DMM practices . . . . . . . . . . . 12
4.3. 3GPP network flattening approaches . . . . . . . . . . . 14 4.3. Flattening 3GPP mobile network approaches . . . . . . . . 14
5. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Distributed mobility management - REQ1 . . . . . . . . . 17 5.1. Distributed mobility management - REQ1 . . . . . . . . . 17
5.2. Bypassable network-layer mobility support for each 5.2. Bypassable network-layer mobility support for each
application session - REQ2 . . . . . . . . . . . . . . . 19 application session - REQ2 . . . . . . . . . . . . . . . 19
5.3. IPv6 deployment - REQ3 . . . . . . . . . . . . . . . . . 20 5.3. IPv6 deployment - REQ3 . . . . . . . . . . . . . . . . . 21
5.4. Existing mobility protocols - REQ4 . . . . . . . . . . . 21 5.4. Existing mobility protocols - REQ4 . . . . . . . . . . . 21
5.5. Coexistence with deployed networks/hosts and operability 5.5. Coexistence with deployed networks/hosts and operability
across different networks- REQ5 . . . . . . . . . . . . . 21 across different networks- REQ5 . . . . . . . . . . . . . 21
5.6. Operation and management considerations - REQ6 . . . . . 22 5.6. Operation and management considerations - REQ6 . . . . . 22
5.7. Security considerations - REQ7 . . . . . . . . . . . . . 22 5.7. Security considerations - REQ7 . . . . . . . . . . . . . 23
5.8. Multicast - REQ8 . . . . . . . . . . . . . . . . . . . . 23 5.8. Multicast - REQ8 . . . . . . . . . . . . . . . . . . . . 23
5.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Normative References . . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.2. Informative References . . . . . . . . . . . . . . . . . 25 9.1. Normative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 9.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
The distributed mobility management (DMM) WG has studied the problems The centralized deployment of mobility anchors to manage IP sessions
of centralized deployment of mobility management protocols and pose several problems. In order to address these problems, a
specified the DMM requirements [I-D.ietf-dmm-requirements]. This distributed mobility management (DMM) architecture has been proposed.
document investigates whether it is feasible to deploy current IP This document investigates whether it is feasible to deploy current
mobility protocols in a DMM scenario in a way that can fulfill the IP mobility protocols in a DMM scenario in a way that can fulfill the
requirements. It discusses current deployment practices of existing requirements as defined in [RFC7333]. It discusses current
mobility protocols and identifies the limitations (gaps) in these deployment practices of existing mobility protocols and identifies
practices from the standpoint of satisfying DMM requirements, as the limitations (gaps) in these practices from the standpoint of
defined in [I-D.ietf-dmm-requirements]. satisfying DMM requirements.
The rest of this document is organized as follows. Section 3 The rest of this document is organized as follows. Section 3
analyzes existing IP mobility protocols by examining their functions analyzes existing IP mobility protocols by examining their functions
and how these functions can be configured and used to work in a DMM and how these functions can be configured and used to work in a DMM
environment. Section 4 presents the current practices of IP wireless environment. Section 4 presents the current practices of IP wireless
networks and 3GPP architectures. Both network- and host-based networks and 3GPP architectures. Both network- and host-based
mobility protocols are considered. Section 5 presents the gap mobility protocols are considered. Section 5 presents the gap
analysis with respect to the current practices. analysis with respect to the current practices.
2. Terminology 2. 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 All general mobility-related terms and their acronyms used in this
document are to be interpreted as defined in the Mobile IPv6 base document are to be interpreted as defined in the Mobile IPv6 base
specification [RFC6275] and in the Proxy mobile IPv6 specification specification [RFC6275], in the Proxy mobile IPv6 specification
[RFC5213]. These terms include mobile node (MN), correspondent node [RFC5213], and in the Distributed Management Requirements [RFC7333].
(CN), home agent (HA), local mobility anchor (LMA), and mobile access These terms include mobile node (MN), correspondent node (CN), home
gateway (MAG). agent (HA), local mobility anchor (LMA), mobile access gateway (MAG),
centrally depoyed mobility anchors, distributed mobility management,
hierarchical mobile network, flatter mobile network, and flattening
mobile network.
In addition, this document also introduces some definitions of IP In addition, this document also introduces some definitions of IP
mobility functions in Section 3. mobility functions in Section 3.
In this document there are also references to a "distributed mobility In this document there are also references to a "distributed mobility
management environment". By this term, we refer to a scenario in management environment". By this term, we refer to a scenario in
which the IP mobility, access network and routing solutions allow for which the IP mobility, access network and routing solutions allow for
setting up IP networks so that traffic is distributed in an optimal setting up IP networks so that traffic is distributed in an optimal
way, without the reliance on centrally deployed anchors to manage IP way, without the reliance on centrally deployed mobility anchors to
mobility sessions. manage IP mobility sessions.
3. Functions of existing mobility protocols 3. Functions of existing mobility protocols
The host-based Mobile IPv6 [RFC6275] and its network-based extension, The host-based Mobile IPv6 (MIPv6) [RFC6275] and its network-based
PMIPv6 [RFC5213], even HMIPv6 [RFC5380] are logically centralized extension, Proxy Mobile IPv6 (PMIPv6) [RFC5213], even Hierarchical
mobility management approaches addressing primarily hierarchical Mobile IPv6 (HMIPv6) [RFC5380] are logically centralized mobility
mobile networks. Although these two are centralized approaches, they management approaches addressing primarily hierarchical mobile
have important mobility management functions resulting from years of networks. Although these two are centralized approaches, they have
important mobility management functions resulting from years of
extensive work to develop and to extend these functions. It is extensive work to develop and to extend these functions. It is
therefore useful to take these existing functions and examine them in therefore useful to take these existing functions and examine them in
a DMM scenario in order to understand how to deploy the existing a DMM scenario in order to understand how to deploy the existing
mobility protocols to provide distributed mobility management. mobility protocols to provide distributed mobility management.
The main mobility management functions of MIPv6, PMIPv6, and HMIPv6 The main mobility management functions of MIPv6, PMIPv6, and HMIPv6
are the following: are the following:
1. Anchoring function (AF): allocation to a mobile node of an IP 1. Anchoring function (AF): allocation to a mobile node of an IP
address (a Home Address (HoA)) or prefix (a Home Network Prefix address (a Home Address, HoA) or prefix (a Home Network Prefix,
(HNP)) topologically anchored by the advertising node (i.e., the HNP) topologically anchored by the advertising node (i.e., the
anchor node is able to advertise a connected route into the anchor node is able to advertise a connected route into the
routing infrastructure for the allocated IP prefixes). It is a routing infrastructure for the allocated IP prefixes). It is a
control plane function. control plane function.
2. Internetwork Location Information (LI) function: managing and 2. Internetwork Location Information (LI) function: managing and
keeping track of the internetwork location of an MN. The keeping track of the internetwork location of an MN. The
location information may be a binding of the IP advertised location information may be a binding of the IP advertised
address/prefix (e.g., HoA or HNP) to the IP routing address of address/prefix (e.g., HoA or HNP) to the IP routing address of
the MN or of a node that can forward packets destined to the MN. the MN or of a node that can forward packets destined to the MN.
It is a control plane function. It is a control plane function.
skipping to change at page 4, line 32 skipping to change at page 4, line 35
based on the internetwork location information, either to the based on the internetwork location information, either to the
destination or to some other network element that knows how to destination or to some other network element that knows how to
forward the packets to their destination. forward the packets to their destination.
FM may optionally be split into the control plane (FM-CP) and FM may optionally be split into the control plane (FM-CP) and
data plane (FM-DP). data plane (FM-DP).
In Mobile IPv6, the home agent (HA) typically provides the anchoring In Mobile IPv6, the home agent (HA) typically provides the anchoring
function (AF); the location information server (LIs) is at the HA function (AF); the location information server (LIs) is at the HA
while the location information client (LIc) is at the MN; the while the location information client (LIc) is at the MN; the
forwarding management (FM) function is both ends of tunneling at the forwarding management (FM)function is both ends of tunneling at the
HA and the MN. HA and the MN.
In Proxy Mobile IPv6, the Local Mobility Anchor (LMA) provides the In Proxy Mobile IPv6, the Local Mobility Anchor (LMA) provides the
anchoring function (AF); the location information server (LIs) is at anchoring function (AF); the location information server (LIs) is at
the LMA while the location information client (LIc) is at the mobile the LMA while the location information client (LIc) is at the mobile
access gateway (MAG); the forwarding management (FM) function is both access gateway (MAG); the forwarding management (FM) function is both
ends of tunneling at the HA and the MAG. ends of tunneling at the HA and the MAG.
In Hierarchical mobile IPv6 (HMIPv6) [RFC5380], the mobility anchor In Hierarchical Mobile IPv6 (HMIPv6) [RFC5380], the mobility anchor
point (MAP) serves as a location information aggregator between the point (MAP) serves as a location information aggregator between the
LIs at the HA and the LIc at the MN. The MAP also has FM function to LIs at the HA and the LIc at the MN. The MAP also has FM function to
enable tunneling between HA and itself as well as tunneling between enable tunneling between HA and itself as well as tunneling between
MN and itself. MN and itself.
4. DMM practices 4. DMM practices
This section documents deployment practices of existing mobility This section documents deployment practices of existing mobility
protocols to satisfy distributed mobility management requirement. protocols to satisfy distributed mobility management requirements.
This description considers both IP wireless (e.g., evolved Wi-Fi This description considers both IP wireless (e.g., evolved Wi-Fi
hotspots) and 3GPP Architecture flattening approaches(i.e. fewer hotspots) and 3GPP flattening mobile network.
levels of routing hierarchy introduced into the data path by the
mobility management system).
While describing the current DMM practices, references to the generic While describing the current DMM practices, references to the generic
mobility management functions described in Section 3 are provided, as mobility management functions described in Section 3 are provided, as
well as some initial hints on the identified gaps with respect to the well as some initial hints on the identified gaps with respect to the
DMM requirements documented in [I-D.ietf-dmm-requirements]. DMM requirements documented in [RFC7333].
4.1. Assumptions 4.1. Assumptions
There are many different approaches that can be considered to There are many different approaches that can be considered to
implement and deploy a distributed anchoring and mobility solution. implement and deploy a distributed anchoring and mobility solution.
The focus of the gap analysis is on certain current mobile network The focus of the gap analysis is on certain current mobile network
architectures and standardized IP mobility solutions, considering any architectures and standardized IP mobility solutions, considering any
kind of deployment options which do not violate the original protocol kind of deployment options which do not violate the original protocol
specifications. In order to limit the scope of our analysis of DMM specifications. In order to limit the scope of our analysis of DMM
practices, we consider the following list of technical assumptions: practices, we consider the following list of technical assumptions:
1. Both host- and network-based solutions should be considered. 1. Both host- and network-based solutions are considered.
2. Solutions should allow selecting and using the most appropriate 2. Solutions should allow selecting and using the most appropriate
IP anchor among a set of available candidates. IP anchor among a set of available candidates.
3. Mobility management should be realized by the preservation of the 3. Mobility management should be realized by the preservation of the
IP address across the different points of attachment (i.e., IP address across the different points of attachment (i.e.,
provision of IP address continuity). This is in contrast to provision of IP address continuity). This is in contrast to
certain transport-layer based approaches such as SCTP or certain transport-layer based approaches such as Stream Control
application-layer mobility. Transmission Protocol (SCTP) [RFC4960] or application-layer
mobility.
Applications which can cope with changes in the MN's IP address do Applications which can cope with changes in the MN's IP address do
not depend on IP mobility management protocols such as DMM. not depend on IP mobility management protocols such as DMM.
Typically, a connection manager together with the operating system Typically, a connection manager together with the operating system
will configure the source address selection mechanism of the IP will configure the source address selection mechanism of the IP
stack. This might involve identifying application capabilities and stack. This might involve identifying application capabilities and
triggering the mobility support accordingly. Further considerations triggering the mobility support accordingly. Further considerations
on application management and source address selection are out of the on application management and source address selection are out of the
scope of this document, but the reader might consult [RFC- scope of this document, but the reader might consult [RFC6724].
SourceAddrSelection].
4.2. IP flat wireless network 4.2. IP flat wireless network
This section focuses on common IP wireless network architectures and This section focuses on common IP wireless network architectures and
how they can be flattened from an IP mobility and anchoring point of how they can be flattened from an IP mobility and anchoring point of
view using common and standardized protocols. We take Wi-Fi as an view using common and standardized protocols. We take Wi-Fi as an
useful wireless technology, since it is widely known and deployed useful wireless technology, since it is widely known and deployed
nowadays. Some representative examples of Wi-Fi deployment nowadays. Some representative examples of Wi-Fi deployment
architectures are depicted in Figure 1. architectures are depicted in Figure 1.
skipping to change at page 6, line 30 skipping to change at page 6, line 30
| | +-------------+ | | +-------------+
| | | | | |
| | +-----+ | | +-----+
+---------------+ | | AR | +---------------+ | | AR |
| | +--+--+ | | +--+--+
+-----+ +-----+ *----+----* +-----+ +-----+ *----+----*
| RG | | WLC | ( LAN ) | RG | | WLC | ( LAN )
+-----+ +-----+ *---------* +-----+ +-----+ *---------*
. / \ / \ . / \ / \
/ \ +-----+ +-----+ +-----+ +-----+ / \ +-----+ +-----+ +-----+ +-----+
MN MN |Wi-Fi| |Wi-Fi| |Wi-Fi| |Wi-Fi| / \ |Wi-Fi| |Wi-Fi| |Wi-Fi| |Wi-Fi|
| AP | | AP | | AP | | AP | MN1 MN2 | AP1 | | AP2 | | AP3 | | AP4 |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
. . . .
/ \ / \ / \ / \
MN MN MN MN / \ / \
MN3 MN4 MN5 MN6
Figure 1: IP Wi-Fi network architectures Figure 1: IP Wi-Fi network architectures
In the figure, three typical deployment options are shown In the figure, three typical deployment options are shown
[I-D.gundavelli-v6ops-community-wifi-svcs]. On the left hand side of [I-D.gundavelli-v6ops-community-wifi-svcs]. On the left hand side of
the figure, mobile nodes directly connect to a Residential Gateway the figure, mobile nodes MN1 and MN2 directly connect to a
(RG) which is a network device at the customer premises and provides Residential Gateway (RG) which is a network device at the customer
both wireless layer-2 access connectivity (i.e., it hosts the 802.11 premises and provides both wireless layer-2 access connectivity
Access Point function) and layer-3 routing functions. In the middle (i.e., it hosts the 802.11 Access Point function) and layer-3 routing
of the figure, mobile nodes connect to Wi-Fi Access Points (APs) that functions. In the middle of the figure, mobile nodes MN3 and MN4
are managed by a WLAN Controller (WLC), which performs radio resource connect to Wi-Fi Access Points (APs) AP1 and AP2 that are managed by
management on the APs, domain-wide mobility policy enforcement and a WLAN Controller (WLC), which performs radio resource management on
centralized forwarding function for the user traffic. The WLC could the APs, domain-wide mobility policy enforcement and centralized
also implement layer-3 routing functions, or attach to an access forwarding function for the user traffic. The WLC could also
router (AR). Last, on the right-hand side of the figure, access implement layer-3 routing functions, or attach to an access router
points are directly connected to an access router. This can also be (AR). Last, on the right-hand side of the figure, access points AP3
and AP4 are directly connected to an access router. This can also be
used as a generic connectivity model. used as a generic connectivity model.
IP mobility protocols can be used to provide inter-access mobility IP mobility protocols can be used to provide inter-access mobility
support to users, e.g. handover from Wi-Fi to cellular access. Two support to users, e.g., handover from Wi-Fi to cellular access. Two
kind of protocols can be used: Proxy Mobile IPv6 [RFC5213] or Mobile kind of protocols can be used: Proxy Mobile IPv6 [RFC5213] or Mobile
IPv6 [RFC5555], with the mobility anchor (e.g., local mobility anchor IPv6 [RFC5555], with the mobility anchor (e.g., local mobility anchor
or home agent) role typically being played by the edge router of the or home agent) role typically being played by the edge router of the
mobile network [SDO-3GPP.23.402]. mobile network [SDO-3GPP.23.402].
Although this section has made use of the example of Wi-Fi networks, Although this section has made use of the example of Wi-Fi networks,
there are other IP flat wireless network architectures specified, there are other IP flat wireless network architectures specified,
such as WiMAX [IEEE.802-16.2009], which integrates both host and such as WiMAX [IEEE.802-16.2009], which integrates both host and
network-based IP mobility functionality. network-based IP mobility functionality.
Existing IP mobility protocols can also be deployed in a more Existing IP mobility protocols can also be deployed in a flatter
flattened manner, so that the anchoring and access aggregation manner, so that the anchoring and access aggregation functions are
functions are distributed. We next describe several practices for distributed. We next describe several practices for the deployment
the deployment of existing mobility protocols in a distributed of existing mobility protocols in a distributed mobility management
mobility management environment. The analysis in this section is environment. The analysis in this section is limited to protocol
limited to protocol solutions based on existing IP mobility solutions based on existing IP mobility protocols, either host- or
protocols, either host- or network-based, such as Mobile IPv6 network-based, such as Mobile IPv6 [RFC6275], [RFC5555], Proxy Mobile
[RFC6275], [RFC5555], Proxy Mobile IPv6 [RFC5213], [RFC5844] and NEMO IPv6 (PMIPv6) [RFC5213], [RFC5844] and Network Mobility Basic Support
[RFC3963]. Extensions to these base protocol solutions are also protocol (NEMO) [RFC3963]. Extensions to these base protocol
considered. The analysis is divided into two parts: host- and solutions are also considered. The analysis is divided into two
network-based practices. parts: host- and network-based practices.
4.2.1. Host-based IP DMM practices 4.2.1. Host-based IP DMM practices
Mobile IPv6 (MIPv6) [RFC6275] and its extension to support mobile Mobile IPv6 (MIPv6) [RFC6275] and its extension to support mobile
networks, the NEMO Basic Support protocol (hereafter, simply referred networks, the NEMO Basic Support protocol (hereafter, simply referred
to as NEMO) [RFC3963] are well-known host-based IP mobility to as NEMO) [RFC3963] are well-known host-based IP mobility
protocols. They depend upon the function of the Home Agent (HA), a protocols. They depend upon the function of the Home Agent (HA), a
centralized anchor, to provide mobile nodes (hosts and routers) with centralized anchor, to provide mobile nodes (hosts and routers) with
mobility support. In these approaches, the home agent typically mobility support. In these approaches, the home agent typically
provides the anchoring function (AF), forwarding management (FM), and provides the anchoring function (AF), forwarding management (FM), and
skipping to change at page 8, line 5 skipping to change at page 8, line 8
One approach to distribute the anchors can be to deploy several HAs One approach to distribute the anchors can be to deploy several HAs
(as shown in Figure 2), and assign the topologically closest anchor (as shown in Figure 2), and assign the topologically closest anchor
to each MN [RFC4640], [RFC5026], [RFC6611]. In the example shown in to each MN [RFC4640], [RFC5026], [RFC6611]. In the example shown in
Figure 2, MN1 is assigned HA1 (and a home address anchored by HA1), Figure 2, MN1 is assigned HA1 (and a home address anchored by HA1),
while MN2 is assigned HA2. Note that MIPv6/NEMO specifications do while MN2 is assigned HA2. Note that MIPv6/NEMO specifications do
not prevent the simultaneous use of multiple home agents by a single not prevent the simultaneous use of multiple home agents by a single
mobile node. In this deployment model, the mobile node can use mobile node. In this deployment model, the mobile node can use
several anchors at the same time, each of them anchoring IP flows several anchors at the same time, each of them anchoring IP flows
initiated at a different point of attachment. However there is no initiated at a different point of attachment. However there is no
mechanism specified by IETF to enable an efficient dynamic discovery mechanism specified to enable an efficient dynamic discovery of
of available anchors and the selection of the most suitable one. available anchors and the selection of the most suitable one. Note
Note that some of these mechanisms [SDO-3GPP.23.402] have been that some of these mechanisms [SDO-3GPP.23.402] have been defined in
defined outside IETF. other standards organizations.
<- INTERNET -> <- HOME NETWORK -> <---- ACCESS NETWORK ----> <- INTERNET -> <- HOME NETWORK -> <---- ACCESS NETWORK ---->
------- ------- ------- -------
| CN1 | ------- | AR1 |-(o) zzzz (o) | CN1 | ------- | AR1 |-(o) zzzz (o)
------- | HA1 | ------- | ------- | HA1 | ------- |
------- (MN1 anchored at HA1) ------- ------- (MN1 anchored at HA1) -------
------- | MN1 | ------- | MN1 |
| AR2 |-(o) ------- | AR2 |-(o) -------
------- -------
------- -------
skipping to change at page 11, line 8 skipping to change at page 11, line 8
mobile node may decide to directly use the RCoA as source address for mobile node may decide to directly use the RCoA as source address for
a communication with a given correspondent node, particularly if the a communication with a given correspondent node, particularly if the
MN does not expect to move outside the local domain during the MN does not expect to move outside the local domain during the
lifetime of the communication. This can be seen as a potential DMM lifetime of the communication. This can be seen as a potential DMM
mode of operation,though it fails to provide session continuity if mode of operation,though it fails to provide session continuity if
and when the MN moves outside the local domain. In the example shown and when the MN moves outside the local domain. In the example shown
in Figure 3, MN1 is using its global HoA to communicate with CN1, in Figure 3, MN1 is using its global HoA to communicate with CN1,
while it is using its RCoA to communicate with CN2. while it is using its RCoA to communicate with CN2.
Furthermore, a local domain might have several MAPs deployed, Furthermore, a local domain might have several MAPs deployed,
enabling therefore a different kind of HMIPv6 deployments (e.g., flat enabling therefore a different kind of HMIPv6 deployments (e.g.,
and distributed). The HMIPv6 specification supports a flexible flattening and distributed). The HMIPv6 specification supports a
selection of the MAP (e.g., based on the distance between the MN and flexible selection of the MAP (e.g., based on the distance between
the MAP, taking into consideration the expected mobility pattern of the MN and the MAP, taking into consideration the expected mobility
the MN, etc.). pattern of the MN, etc.).
Another extension that can be used to help distributing mobility Another extension that can be used to help distributing mobility
management functions is the Home Agent switch specification management functions is the Home Agent switch specification
[RFC5142], which defines a new mobility header for signaling a mobile [RFC5142], which defines a new mobility header for signaling a mobile
node that it should acquire a new home agent. [RFC5142] does not node that it should acquire a new home agent. [RFC5142] does not
specify the case of changing the mobile node's home address, as that specify the case of changing the mobile node's home address, as that
might imply loss of connectivity for ongoing persistent connections. might imply loss of connectivity for ongoing persistent connections.
Nevertheless, that specification could be used to force the change of Nevertheless, that specification could be used to force the change of
home agent in those situations where there are no active persistent home agent in those situations where there are no active persistent
data sessions that cannot cope with a change of home address. data sessions that cannot cope with a change of home address.
There are other host-based approaches standardized within IETF that There are other host-based approaches standardized that can be used
can be used to provide mobility support. For example MOBIKE to provide mobility support. For example MOBIKE [RFC4555] allows a
[RFC4555] allows a mobile node encrypting traffic through IKEv2 mobile node encrypting traffic through IKEv2 [RFC5996] to change its
[RFC5996] to change its point of attachment while maintaining a point of attachment while maintaining a Virtual Private Network (VPN)
Virtual Private Network (VPN) session. The MOBIKE protocol allows session. The MOBIKE protocol allows updating the VPN Security
updating the VPN Security Associations (SAs) in cases where the base Associations (SAs) in cases where the base connection initially used
connection initially used is lost and needs to be re-established. is lost and needs to be re-established. The use of the MOBIKE
The use of the MOBIKE protocol avoids having to perform an IKEv2 re- protocol avoids having to perform an IKEv2 re-negotiation. Similar
negotiation. Similar considerations to those made for Mobile IPv6 considerations to those made for Mobile IPv6 can be applied to
can be applied to MOBIKE; though MOBIKE is best suited for situations MOBIKE; though MOBIKE is best suited for situations where the address
where the address of at least one endpoint is relatively stable and of at least one endpoint is relatively stable and can be discovered
can be discovered using existing mechanisms such as DNS. using existing mechanisms such as DNS.
IETF has defined extensions to the mobility protocol to optimize the Extensions have been defined to the mobility protocol to optimize the
handover performance. Mobile IPv6 Fast Handovers (FMIPv6) [RFC5568] handover performance. Mobile IPv6 Fast Handovers (FMIPv6) [RFC5568]
is the extension to optimize handover latency. It defines new access is the extension to optimize handover latency. It defines new access
router discovery mechanism before handover to reduce the new network router discovery mechanism before handover to reduce the new network
discovery latency. It also defines a tunnel between the previous discovery latency. It also defines a tunnel between the previous
access router and the new access router to reduce the packet loss access router and the new access router to reduce the packet loss
during handover. IETF seamoby working group also has published during handover. The Candidate Access Router Discovery (CARD)
Candidate Access Router Discovery (CARD) [RFC4066] and Context [RFC4066] and Context Transfer Protocol (CXTP) [RFC4067] protocols
Transfer Protocol (CXTP) [RFC4067] to improve the handover were standardized to improve the handover performance. The DMM
performance. The DMM deployment practice discussed in this section deployment practice discussed in this section can also use those
can also use those extensions to improve the handover performance. extensions to improve the handover performance.
4.2.2. Network-based IP DMM practices 4.2.2. Network-based IP DMM practices
Proxy Mobile IPv6 (PMIPv6) [RFC5213] is the main network-based IP Proxy Mobile IPv6 (PMIPv6) [RFC5213] is the main network-based IP
mobility protocol specified for IPv6. Proxy Mobile IPv4 [RFC5844] mobility protocol specified for IPv6. Proxy Mobile IPv4 [RFC5844]
defines some IPv4 extensions. With network-based IP mobility defines some IPv4 extensions. With network-based IP mobility
protocols, the local mobility anchor (LMA) typically provides the protocols, the local mobility anchor (LMA) typically provides the
anchoring function (AF), Forwarding management (FM) function, and anchoring function (AF), Forwarding management (FM) function, and
Internetwork Location Information server (LIs) function. The mobile Internetwork Location Information server (LIs) function. The mobile
access gateway (MAG) provides the Location Information client (LIc) access gateway (MAG) provides the Location Information client (LIc)
skipping to change at page 14, line 11 skipping to change at page 14, line 11
message exchange between a mobile access gateway and a local mobility message exchange between a mobile access gateway and a local mobility
anchor. While this mechanism is mainly aimed for load-balancing anchor. While this mechanism is mainly aimed for load-balancing
purposes, it can also be used to select an optimal LMA from the purposes, it can also be used to select an optimal LMA from the
routing point of view. A runtime LMA assignment can be used to routing point of view. A runtime LMA assignment can be used to
change the assigned LMA of an MN, for example, in cases when the change the assigned LMA of an MN, for example, in cases when the
mobile node does not have any active session, or when the running mobile node does not have any active session, or when the running
sessions can survive an IP address change. Note that several sessions can survive an IP address change. Note that several
possible dynamic local mobility anchor discovery solutions can be possible dynamic local mobility anchor discovery solutions can be
used, as described in [RFC6097]. used, as described in [RFC6097].
4.3. 3GPP network flattening approaches 4.3. Flattening 3GPP mobile network approaches
The 3rd Generation Partnership Project (3GPP) is the standards The 3rd Generation Partnership Project (3GPP) is the standards
development organization that specifies the 3rd generation mobile development organization that specifies the 3rd generation mobile
network and the Evolved Packet System (EPS), which mainly comprises network and the Evolved Packet System (EPS), which mainly comprises
the Evolved Packet Core (EPC) and a new radio access network, usually the Evolved Packet Core (EPC) and a new radio access network, usually
referred to as LTE (Long Term Evolution). referred to as LTE (Long Term Evolution).
Architecturally, the 3GPP Evolved Packet Core (EPC) network is Architecturally, the 3GPP Evolved Packet Core (EPC) network is
similar to an IP wireless network running PMIPv6 or MIPv6, as it similar to an IP wireless network running PMIPv6 or MIPv6, as it
relies on the Packet Data Gateway (PGW) anchoring services to provide relies on the Packet Data Gateway (PGW) anchoring services to provide
mobile nodes with mobility support (see Figure 5). There are client- mobile nodes with mobility support (see Figure 5). There are client-
based and network-based mobility solutions in 3GPP, which for based and network-based mobility solutions in 3GPP, which for
simplicity will be analyzed together. We next describe how 3GPP simplicity will be analyzed together. We next describe how 3GPP
mobility protocols and several other completed or ongoing extensions mobility protocols and several other completed or ongoing extensions
can be deployed to meet some of the DMM requirements can be deployed to meet some of the DMM requirements [RFC7333].
[I-D.ietf-dmm-requirements].
+---------------------------------------------------------+ +---------------------------------------------------------+
| PCRF | | PCRF |
+-----------+--------------------------+----------------+-+ +-----------+--------------------------+----------------+-+
| | | | | |
+----+ +-----------+------------+ +--------+-----------+ +-+-+ +----+ +-----------+------------+ +--------+-----------+ +-+-+
| | | +-+ | | Core Network | | | | | | +-+ | | Core Network | | |
| | | +------+ |S|__ | | +--------+ +---+ | | | | | | +------+ |S|__ | | +--------+ +---+ | | |
| | | |GERAN/|_|G| \ | | | HSS | | | | | | | | | |GERAN/|_|G| \ | | | HSS | | | | | |
| +-----+ UTRAN| |S| \ | | +---+----+ | | | | E | | +-----+ UTRAN| |S| \ | | +---+----+ | | | | E |
skipping to change at page 16, line 14 skipping to change at page 16, line 14
Equipment (UE) implements the binding update functionality, while the Equipment (UE) implements the binding update functionality, while the
home agent role is played by the PGW. home agent role is played by the PGW.
A Local IP Access (LIPA) and Selected IP Traffic Offload (SIPTO) A Local IP Access (LIPA) and Selected IP Traffic Offload (SIPTO)
enabled network [SDO-3GPP.23.401] allows offloading some IP services enabled network [SDO-3GPP.23.401] allows offloading some IP services
at the local access network, above the Radio Access Network (RAN) or at the local access network, above the Radio Access Network (RAN) or
at the macro, without the need to travel back to the PGW (see at the macro, without the need to travel back to the PGW (see
Figure 6). Figure 6).
+---------+ IP traffic to mobile operator's CN +---------+ IP traffic to mobile operator's CN
| User |....................................(Operator's CN) | User |.........................\C2
| Equipm. |.................. \B7.........(Opera
r's CN)
| Equipm. |.........
....
.\C2
\B7
+---------+ . Local IP traffic +---------+ . Local IP traffic
. .
+-----------+ +-----------+
|Residential| |Residential|
|enterprise | |enterprise |
|IP network | |IP network |
+-----------+ +-----------+
Figure 6: LIPA scenario Figure 6: LIPA scenario
skipping to change at page 16, line 40 skipping to change at page 16, line 45
SIPTO Traffic SIPTO Traffic
| |
. .
. .
+------+ +------+ +------+ +------+
|L-PGW | ---- | MME | |L-PGW | ---- | MME |
+------+ / +------+ +------+ / +------+
| / | /
+-------+ +------+ +------+/ +------+ +-------+ +------+ +------+/ +------+
| UE |.....|eNB |....| S-GW |........| P-GW |...> CN Traffic | UE |.....|eNB |....| S-GW |........| P-GW
...> CN Traf
c
+-------+ +------+ +------+ +------+ +-------+ +------+ +------+ +------+
Figure 7: SIPTO architecture Figure 7: SIPTO architecture
LIPA, on the other hand, enables an IP addressable UE connected via a LIPA, on the other hand, enables an IP addressable UE connected via a
Home eNB (HeNB) to access other IP addressable entities in the same Home eNB (HeNB) to access other IP addressable entities in the same
residential/enterprise IP network without traversing the mobile residential/enterprise IP network without traversing the mobile
operator's network core in the user plane. In order to achieve this, operator's network core in the user plane. In order to achieve this,
a Local GW (L-GW) collocated with the HeNB is used. LIPA is a Local GW (L-GW) collocated with the HeNB is used. LIPA is
established by the UE requesting a new PDN (Public Data Network) established by the UE requesting a new PDN (Public Data Network)
skipping to change at page 17, line 37 skipping to change at page 17, line 45
Both SIPTO and LIPA have a very limited mobility support, specially Both SIPTO and LIPA have a very limited mobility support, specially
in 3GPP specifications up to Rel-12. Briefly, LIPA mobility support in 3GPP specifications up to Rel-12. Briefly, LIPA mobility support
is limited to handovers between HeNBs that are managed by the same is limited to handovers between HeNBs that are managed by the same
L-GW (i.e., mobility within the local domain). There is no guarantee L-GW (i.e., mobility within the local domain). There is no guarantee
of IP session continuity for SIPTO. of IP session continuity for SIPTO.
5. Gap analysis 5. Gap analysis
The goal of this section is to identify the limitations in the The goal of this section is to identify the limitations in the
current practices, described in Section 4, with respect to the DMM current practices, described in Section 4, with respect to the DMM
requirements listed in [I-D.ietf-dmm-requirements]. requirements listed in [RFC7333].
5.1. Distributed mobility management - REQ1 5.1. Distributed mobility management - REQ1
According to requirement #1 stated in [I-D.ietf-dmm-requirements], IP According to requirement #1 stated in [RFC7333], IP mobility, network
mobility, network access and forwarding solutions provided by DMM access and forwarding solutions provided by DMM must enable traffic
must enable traffic to avoid traversing single mobility anchor far to avoid traversing single mobility anchor far from the optimal
from the optimal route. route.
From the analysis performed in Section 4, a DMM deployment can meet From the analysis performed in Section 4, a DMM deployment can meet
the requirement "REQ#1 Distributed mobility management" usually the requirement "REQ#1 Distributed mobility management" usually
relying on the following functions: relying on the following functions:
o Multiple (distributed) anchoring: ability to anchor different o Multiple (distributed) anchoring: ability to anchor different
sessions of a single mobile node at different anchors. In order sessions of a single mobile node at different anchors. In order
to provide improved routing, some anchors might need to be placed to provide improved routing, some anchors might need to be placed
closer to the mobile node or the corresponding node. closer to the mobile node or the corresponding node.
skipping to change at page 18, line 47 skipping to change at page 19, line 5
mobility management. In this case, the mobile client, located in the mobility management. In this case, the mobile client, located in the
network (e.g., MAG), usually retrieves the MN's anchor from the MN's network (e.g., MAG), usually retrieves the MN's anchor from the MN's
policy profile (e.g., Section 6.2 of [RFC5213]). Currently, the MN's policy profile (e.g., Section 6.2 of [RFC5213]). Currently, the MN's
policy profile implicitly assumes a single serving anchor and, thus, policy profile implicitly assumes a single serving anchor and, thus,
does not maintain the association between home network prefix and does not maintain the association between home network prefix and
anchor. anchor.
The consequence of the distribution of the mobility anchors is that The consequence of the distribution of the mobility anchors is that
there might be more than one available anchor for a mobile node to there might be more than one available anchor for a mobile node to
use, which leads to an anchor discovery and selection issue. use, which leads to an anchor discovery and selection issue.
Currently, there is no efficient mechanism specified by IETF to allow Currently, there is no efficient mechanism specified to allow
dynamically discovering the presence of nodes that can play the dynamically discovering the presence of nodes that can play the
anchor role, discovering their capabilities and selecting the most anchor role, discovering their capabilities and selecting the most
suitable one. There is also no mechanism to allow selecting a node suitable one. There is also no mechanism to allow selecting a node
that is currently anchoring a given home address/prefix (capability that is currently anchoring a given home address/prefix (capability
sometimes required to meet REQ#2). There are though some mechanisms sometimes required to meet REQ#2). There are though some mechanisms
that could help discovering anchors, such as the Dynamic Home Agent that could help discovering anchors, such as the Dynamic Home Agent
Address Discovery (DHAAD), the use of the Home Agent (H) flag in Address Discovery (DHAAD), the use of the Home Agent (H) flag in
Router Advertisements (which indicates that the router sending the Router Advertisements (which indicates that the router sending the
Router Advertisement is also functioning as a Mobile IPv6 home agent Router Advertisement is also functioning as a Mobile IPv6 home agent
on the link) or the MAP option in Router Advertisements defined by on the link) or the MAP option in Router Advertisements defined by
skipping to change at page 19, line 30 skipping to change at page 19, line 36
re-authentication process after a change of anchor. Note that some re-authentication process after a change of anchor. Note that some
extensions might be needed in the context of DMM, as these protocols extensions might be needed in the context of DMM, as these protocols
were designed in the context of centralized client IP mobility, were designed in the context of centralized client IP mobility,
focusing on the access re-attachment and authentication. focusing on the access re-attachment and authentication.
Also note that REQ1 is such that the data plane traffic can avoid Also note that REQ1 is such that the data plane traffic can avoid
suboptimal route. Distributed processing of the traffic is then suboptimal route. Distributed processing of the traffic is then
needed only in the data plane. The needed capability in distributed needed only in the data plane. The needed capability in distributed
processing therefore should not contradict with centralized control processing therefore should not contradict with centralized control
plane. Other control plane solutions such as charging, lawful plane. Other control plane solutions such as charging, lawful
interception, etc. should not be limited. Yet combining the control interception, etc. should not be limited. Yet combining the control
plane and data plane forwarding management (FM) function may limit plane and data plane forwarding management (FM) function may limit
the choice to distributing both data plane and control plane the choice to distributing both data plane and control plane
together. In order to enable distributing only the data plane together. In order to enable distributing only the data plane
without distributing the control plane, a gap is to split the without distributing the control plane, a gap is to split the
forwarding management function into the control plane (FM-CP) and forwarding management function into the control plane (FM-CP) and
data plane (FM-DP). data plane (FM-DP).
5.2. Bypassable network-layer mobility support for each application 5.2. Bypassable network-layer mobility support for each application
session - REQ2 session - REQ2
The need for "bypassable network-layer mobility support for each The need for "bypassable network-layer mobility support for each
application session" introduced in [I-D.ietf-dmm-requirements] application session" introduced in [RFC7333] requires flexibility on
requires flexibility on determining whether network-layer mobility determining whether network-layer mobility support is needed. The
support is needed. The requirement enables one to choose whether or requirement enables one to choose whether or not use network-layer
not use network-layer mobility support. It only enables the two mobility support. It only enables the two following functions:
following functions:
o Dynamically assign/relocate anchor: a mobility anchor is assigned o Dynamically assign/relocate anchor: a mobility anchor is assigned
only to sessions which uses the network-layer mobility support. only to sessions which uses the network-layer mobility support.
The MN may thus manage more than one session; some of them may be The MN may thus manage more than one session; some of them may be
associated with anchored IP address(es), while the others may be associated with anchored IP address(es), while the others may be
associated with local IP address(es). associated with local IP address(es).
o Multiple IP address management: this function is related to the o Multiple IP address management: this function is related to the
preceding and is about the ability of the mobile node to preceding and is about the ability of the mobile node to
simultaneously use multiple IP addresses and select the best one simultaneously use multiple IP addresses and select the best one
skipping to change at page 20, line 24 skipping to change at page 20, line 28
The dynamic anchor assignment/relocation needs to ensure that IP The dynamic anchor assignment/relocation needs to ensure that IP
address continuity is guaranteed for sessions that uses such mobility address continuity is guaranteed for sessions that uses such mobility
support (e.g., in some scenarios, the provision of mobility locally support (e.g., in some scenarios, the provision of mobility locally
within a limited area might be enough from the mobile node or the within a limited area might be enough from the mobile node or the
application point of view) at the relocated anchor. Implicitly, when application point of view) at the relocated anchor. Implicitly, when
no applications are using the network-layer mobility support, DMM may no applications are using the network-layer mobility support, DMM may
release the needed resources. This may imply having the knowledge of release the needed resources. This may imply having the knowledge of
which sessions at the mobile node are active and are using the which sessions at the mobile node are active and are using the
mobility support. This is something typically known only by the MN mobility support. This is something typically known only by the MN
(e.g., by its connection manager). Therefore, (part of) this (e.g., by its connection manager), and would also typically require
knowledge might need to be transferred to/shared with the network. some signaling support (e.g., socket API extensions) from
applications to indicate the IP stack whether mobility support is
required or not in. Therefore, (part of) this knowledge might need
to be transferred to/shared with the network.
Multiple IP address management provides the MN with the choice to Multiple IP address management provides the MN with the choice to
pick-up the correct address (provided with mobility support or not) pick-up the correct address (provided with mobility support or not)
depending on the application requirements. When using client based depending on the application requirements. When using client based
mobility management, the mobile node is itself aware of the anchoring mobility management, the mobile node is itself aware of the anchoring
capabilities of its assigned IP addresses. This is not necessarily capabilities of its assigned IP addresses. This is not necessarily
the case with network based IP mobility management; current the case with network based IP mobility management; current
mechanisms do not allow the MN to be aware of the properties of its mechanisms do not allow the MN to be aware of the properties of its
IP addresses (e.g., the MN does not know whether the allocated IP IP addresses (e.g., the MN does not know whether the allocated IP
addresses are anchored). However, there are proposals that the addresses are anchored). However, there are proposals that the
network could indicate such IP address properties during assignment network could indicate such IP address properties during assignment
procedures, such as [I-D.bhandari-dhc-class-based-prefix], procedures, such as [I-D.bhandari-dhc-class-based-prefix],
[I-D.korhonen-6man-prefix-properties] and [I-D.anipko-mif-mpvd-arch]. [I-D.korhonen-6man-prefix-properties] and [I-D.anipko-mif-mpvd-arch].
Although there exist these individual efforts that could be be Although there exist these individual efforts that could be be
considered as attempts to fix the gap, there is no solution adopted considered as attempts to fix the gap, there is no solution adopted
as a work item within any IETF working group. as a work item within any IETF working group.
The handling of mobility management to the granularity of an The handling of mobility management to the granularity of an
individual session of a user/device SHOULD need proper session individual session of a user/device needs proper session
identification in addition to user/device identification. identification in addition to user/device identification.
5.3. IPv6 deployment - REQ3 5.3. IPv6 deployment - REQ3
This requirement states that DMM solutions should primarily target This requirement states that DMM solutions should primarily target
IPv6 as the primary deployment environment. IPv4 support is not IPv6 as the primary deployment environment. IPv4 support is not
considered mandatory and solutions should not be tailored considered mandatory and solutions should not be tailored
specifically to support IPv4. specifically to support IPv4.
All analyzed DMM practices support IPv6. Some of them, such as All analyzed DMM practices support IPv6. Some of them, such as
MIPv6/NEMO (including the support of dynamic HA selection), MOBIKE, MIPv6/NEMO (including the support of dynamic HA selection), MOBIKE,
SIPTO have also IPv4 support. There are also some solutions that SIPTO have also IPv4 support. There are also some solutions that
have some limited IPv4 support (e.g., PMIPv6). In conclusion, this have some limited IPv4 support (e.g., PMIPv6). In conclusion, this
requirement is met by existing DMM practices. requirement is met by existing DMM practices.
5.4. Existing mobility protocols - REQ4 5.4. Existing mobility protocols - REQ4
A DMM solution must first consider reusing and extending IETF- A DMM solution must first consider reusing and extending IETF-
standardized protocols before specifying new protocols. standardized protocols before specifying new protocols.
As stated in [I-D.ietf-dmm-requirements], a DMM solution could reuse As stated in [RFC7333], a DMM solution could reuse existing IETF and
existing IETF and standardized protocols before specifying new standardized protocols before specifying new protocols. Besides,
protocols. Besides, Section 4 of this document discusses various Section 4 of this document discusses various ways to flatten and
ways to flatten and distribute current mobility solutions. Actually, distribute current mobility solutions. Actually, nothing prevent the
nothing prevent the distribution of mobility functions with in IP distribution of mobility functions with in IP mobility protocols.
mobility protocols. However, as discussed in Section 5.1 and However, as discussed in Section 5.1 and Section 5.2, limitations
Section 5.2, limitations exist. exist.
The 3GPP data plane anchoring function, i.e., the PGW, can be also be The 3GPP data plane anchoring function, i.e., the PGW, can be also be
distributed, but with limitations; e.g., no anchoring relocation, no distributed, but with limitations; e.g., no anchoring relocation, no
context transfer between anchors and centralized control plane. The context transfer between anchors and centralized control plane. The
3GPP architecture is also going into the direction of flattening with 3GPP architecture is also going into the direction of flattening with
SIPTO and LIPA, though they do not provide full mobility support. SIPTO and LIPA, though they do not provide full mobility support.
For example, mobility support for SIPTO traffic can be rather For example, mobility support for SIPTO traffic can be rather
limited, and offloaded traffic cannot access operator services. limited, and offloaded traffic cannot access operator services.
Thus, the operator must be very careful in selecting which traffic to Thus, the operator must be very careful in selecting which traffic to
offload. offload.
5.5. Coexistence with deployed networks/hosts and operability across 5.5. Coexistence with deployed networks/hosts and operability across
different networks- REQ5 different networks- REQ5
According to [I-D.ietf-dmm-requirements], DMM implementations must be According to [RFC7333], DMM implementations are required to co-exist
able to co-exist with existing network deployments, end hosts and with existing network deployments, end hosts and routers.
routers, and a DMM solution SHOULD work across different networks, Additionally, DMM solutions are expected to work across different
possibly operated as separate administrative domains, when the needed networks, possibly operated as separate administrative domains, when
mobility management signaling, forwarding, and network access are the needed mobility management signaling, forwarding, and network
allowed by the trust relationship between them. All current mobility access are allowed by the trust relationship between them. All
protocols can co-exist with existing network deployments and end current mobility protocols can co-exist with existing network
hosts. There is no gap between existing mobility protocols and this deployments and end hosts. There is no gap between existing mobility
requirement. protocols and this requirement.
5.6. Operation and management considerations - REQ6 5.6. Operation and management considerations - REQ6
As stated in [I-D.ietf-dmm-requirements], (1) a DMM solution needs to This requirement actually comprises several aspects, as summarized
consider configuring a device, monitoring the current operational below.
state of a device, responding to events that impact the device,
possibly by modifying the configuration and storing the data in a o A DMM solution needs to consider configuring a device, monitoring
format that can be analyzed later. (2) a DMM solution MUST describe the current operational state of a device, responding to events
in what environment and how it can be scalably deployed and managed. that impact the device, possibly by modifying the configuration
(3) a DMM solution MUST support mechanisms to test if the DMM and storing the data in a format that can be analyzed later.
solution is working properly. (4) a DMM solution SHOULD expose the
operational state of DMM to the administrators of the DMM entities. o A DMM solution has to describe in what environment and how it can
(5) a DMM solution, which supports flow mobility, SHOULD support be scalably deployed and managed.
means to correlate the flow routing policies and the observed
forwarding actions. (6) a DMM solution SHOULD support mechanisms to o A DMM solution has to support mechanisms to test if the DMM
check the liveness of forwarding path. (7) a DMM solution MUST solution is working properly.
provide fault management and monitoring mechanisms to manage
situations where update of the mobility session or the data path o A DMM solution is expected to expose the operational state of DMM
fails. (8) a DMM solution SHOULD be able to monitor usage of DMM to the administrators of the DMM entities.
protocol. (9) DMM solutions SHOULD support standardized
configuration with NETCONF [RFC6241], using YANG [RFC6020] modules, o A DMM solution, which supports flow mobility, is also expected to
which SHOULD be created for DMM when needed for such configuration. support means to correlate the flow routing policies and the
observed forwarding actions.
o A DMM solution is expected to support mechanisms to check the
liveness of forwarding path.
o A DMM solution has to provide fault management and monitoring
mechanisms to manage situations where update of the mobility
session or the data path fails.
o A DMM solution is expected to be able to monitor the usage of the
DMM protocol.
o DMM solutions have to support standardized configuration with
NETCONF [RFC6241], using YANG [RFC6020] modules, which are
expected to be created for DMM when needed for such configuration.
Existing mobility management protocols have not thoroughly documented Existing mobility management protocols have not thoroughly documented
the above list of operation and management considerations. Each of the above list of operation and management considerations. Each of
the above needs to be considered from the begining in a DMM solution. the above needs to be considered from the beginning in a DMM
solution.
Management information base (MIB) objects are currently defined in Management information base (MIB) objects are currently defined in
[RFC4295] for MIPv6 and in [RFC6475] for PMIPv6. Standardized [RFC4295] for MIPv6 and in [RFC6475] for PMIPv6. Standardized
configuration with NETCONF [RFC6241], using YANG [RFC6020] modules is configuration with NETCONF [RFC6241], using YANG [RFC6020] modules is
needed. needed.
5.7. Security considerations - REQ7 5.7. Security considerations - REQ7
As stated in [I-D.ietf-dmm-requirements], a DMM solution MUST support As stated in [RFC7333], a DMM solution has to support any security
any security protocols and mechanisms needed to secure the network protocols and mechanisms needed to secure the network and to make
and to make continuous security improvements. In addition, with continuous security improvements. In addition, with security taken
security taken into consideration early in the design, a DMM solution into consideration early in the design, a DMM solution cannot
MUST NOT introduce new security risks, or amplify existing security introduce new security risks, or amplify existing security risks,
risks, that cannot be mitigated by existing security protocols and that cannot be mitigated by existing security protocols and
mechanisms. mechanisms.
Current mobility protocols have all security mechanisms in place. Current mobility protocols have all security mechanisms in place.
For example, Mobile IPv6 defines security features to protect binding For example, Mobile IPv6 defines security features to protect binding
updates both to home agents and correspondent nodes. It also defines updates both to home agents and correspondent nodes. It also defines
mechanisms to protect the data packets transmission for Mobile IPv6 mechanisms to protect the data packets transmission for Mobile IPv6
users. Proxy Mobile IPv6 and other variations of mobile IP also have users. Proxy Mobile IPv6 and other variations of mobile IP also have
similar security considerations. similar security considerations.
5.8. Multicast - REQ8 5.8. Multicast - REQ8
It is stated in [I-D.ietf-dmm-requirements] that DMM solutions should It is stated in [RFC7333] that DMM solutions are expected to enable
enable multicast solutions to be developed to avoid network multicast solutions to be developed to avoid network inefficiency in
inefficiency in multicast traffic delivery. multicast traffic delivery.
Current IP mobility solutions address mainly the mobility problem for Current IP mobility solutions address mainly the mobility problem for
unicast traffic. Solutions relying on the use of an anchor point for unicast traffic. Solutions relying on the use of an anchor point for
tunneling multicast traffic down to the access router, or to the tunneling multicast traffic down to the access router, or to the
mobile node, introduce the so-called "tunnel convergence problem". mobile node, introduce the so-called "tunnel convergence problem".
This means that multiple instances of the same multicast traffic can This means that multiple insta ces of the same multicast traffic can
converge to the same node, diminishing the advantage of using converge to the same node, diminishing the advantage of using
multicast protocols. multicast protocols.
The MULTIMOB WG in IETF has studied this issue, for the specific case [RFC6224] documents a baseline solution for the previous issue, and
of PMIPv6, and has produced a baseline solution [RFC6224] as well as [RFC7028] a routing optimization solution. The baseline solution
a routing optimization solution [RFC7028] to address the problem. suggests deploying an MLD proxy function at the MAG, and either a
The baseline solution suggests deploying an MLD proxy function at the multicast router or another MLD proxy function at the LMA. The
MAG, and either a multicast router or another MLD proxy function at routing optimization solution describes an architecture where a
the LMA. The routing optimization solution describes an architecture dedicated multicast tree mobility anchor (MTMA) or a direct routing
where a dedicated multicast tree mobility anchor (MTMA) or a direct option can be used to avoid the tunnel convergence problem.
routing option can be used to avoid the tunnel convergence problem.
Besides the solutions proposed in MULTIMOB for PMIPv6 within the Besides the solutions highlighted before, there are no other
IETF, there are no other solutions for other mobility protocols to mechanisms for mobility protocols to address the multicast tunnel
address the multicast tunnel convergence problem. convergence problem.
5.9. Summary 5.9. Summary
We next list the main gaps identified from the analysis performed We next list the main gaps identified from the analysis performed
above: above:
o Existing solutions only provide an optimal initial anchor o Existing solutions only provide an optimal initial anchor
assignment, a gap being the lack of dynamic anchor change/new assignment, a gap being the lack of dynamic anchor change/new
anchor assignment. Neither the HA switch nor the LMA runtime anchor assignment. Neither the HA switch nor the LMA runtime
assignment allow changing the anchor during an ongoing session. assignment allow changing the anchor during an ongoing session.
skipping to change at page 24, line 36 skipping to change at page 24, line 52
authentication, a malicious node could forge signaling messages and authentication, a malicious node could forge signaling messages and
redirect traffic from its legitimate path. This would amount to a redirect traffic from its legitimate path. This would amount to a
denial of service attack against the specific node or nodes for which denial of service attack against the specific node or nodes for which
the traffic is intended. Distributed mobility anchoring, while the traffic is intended. Distributed mobility anchoring, while
keeping current security mechanisms, might require more security keeping current security mechanisms, might require more security
associations to be managed by the mobility management entities, associations to be managed by the mobility management entities,
potentially leading to scalability and performance issues. Moreover, potentially leading to scalability and performance issues. Moreover,
distributed mobility anchoring makes mobility security problems more distributed mobility anchoring makes mobility security problems more
complex, since traffic redirection requests might come from complex, since traffic redirection requests might come from
previously unconsidered origins, thus leading to distributed points previously unconsidered origins, thus leading to distributed points
of attack. Consequently, the DMM security design must account for of attack. Consequently, the DMM security design needs to account
the distribution of security associations between additional mobility for the distribution of security associations between additional
entities. mobility entities.
7. IANA Considerations 7. IANA Considerations
None. None.
8. References 8. Contributors
8.1. Normative References
[I-D.ietf-dmm-requirements] This document has benefited to valuable contributions from
Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen,
"Requirements for Distributed Mobility Management", draft-
ietf-dmm-requirements-17 (work in progress), June 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Charles E. Perkins
Requirement Levels", BCP 14, RFC 2119, March 1997. Huawei Technologies
EMail: charliep@computer.org
[RFC4295] Keeni, G., Koide, K., Nagami, K., and S. Gundavelli, who had produced a matrix to compare the different mobility protocols
"Mobile IPv6 Management Information Base", RFC 4295, April and extensions against a list of desired DMM properties. They were
2006. useful inputs in the early work of gap analysis. He had continued to
give suggestions as well as extensive review comments to this
documents.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 9. References
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 9.1. Normative References
Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011.
[RFC6475] Keeni, G., Koide, K., Gundavelli, S., and R. Wakikawa, [RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen,
"Proxy Mobile IPv6 Management Information Base", RFC 6475, "Requirements for Distributed Mobility Management", RFC
May 2012. 7333, August 2014.
8.2. Informative References 9.2. Informative References
[I-D.anipko-mif-mpvd-arch] [I-D.anipko-mif-mpvd-arch]
Anipko, D., "Multiple Provisioning Domain Architecture", Anipko, D., "Multiple Provisioning Domain Architecture",
draft-anipko-mif-mpvd-arch-05 (work in progress), November draft-anipko-mif-mpvd-arch-05 (work in progress), November
2013. 2013.
[I-D.bhandari-dhc-class-based-prefix] [I-D.bhandari-dhc-class-based-prefix]
Systems, C., Halwasia, G., Gundavelli, S., Deng, H., Systems, C., Halwasia, G., Gundavelli, S., Deng, H.,
Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class
based prefix", draft-bhandari-dhc-class-based-prefix-05 based prefix", draft-bhandari-dhc-class-based-prefix-05
skipping to change at page 25, line 46 skipping to change at page 26, line 8
[I-D.gundavelli-v6ops-community-wifi-svcs] [I-D.gundavelli-v6ops-community-wifi-svcs]
Gundavelli, S., Grayson, M., Seite, P., and Y. Lee, Gundavelli, S., Grayson, M., Seite, P., and Y. Lee,
"Service Provider Wi-Fi Services Over Residential "Service Provider Wi-Fi Services Over Residential
Architectures", draft-gundavelli-v6ops-community-wifi- Architectures", draft-gundavelli-v6ops-community-wifi-
svcs-06 (work in progress), April 2013. svcs-06 (work in progress), April 2013.
[I-D.ietf-netext-pmip-cp-up-separation] [I-D.ietf-netext-pmip-cp-up-separation]
Wakikawa, R., Pazhyannur, R., Gundavelli, S., and C. Wakikawa, R., Pazhyannur, R., Gundavelli, S., and C.
Perkins, "Separation of Control and User Plane for Proxy Perkins, "Separation of Control and User Plane for Proxy
Mobile IPv6", draft-ietf-netext-pmip-cp-up-separation-05 Mobile IPv6", draft-ietf-netext-pmip-cp-up-separation-07
(work in progress), July 2014. (work in progress), August 2014.
[I-D.korhonen-6man-prefix-properties] [I-D.korhonen-6man-prefix-properties]
Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D. Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D.
Liu, "IPv6 Prefix Properties", draft-korhonen-6man-prefix- Liu, "IPv6 Prefix Properties", draft-korhonen-6man-prefix-
properties-02 (work in progress), July 2013. properties-02 (work in progress), July 2013.
[IEEE.802-16.2009] [IEEE.802-16.2009]
"IEEE Standard for Local and metropolitan area networks "IEEE Standard for Local and metropolitan area networks
Part 16: Air Interface for Broadband Wireless Access Part 16: Air Interface for Broadband Wireless Access
Systems", IEEE Standard 802.16, 2009, Systems", IEEE Standard 802.16, 2009,
skipping to change at page 26, line 27 skipping to change at page 26, line 38
Shim, "Candidate Access Router Discovery (CARD)", RFC Shim, "Candidate Access Router Discovery (CARD)", RFC
4066, July 2005. 4066, July 2005.
[RFC4067] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, [RFC4067] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli,
"Context Transfer Protocol (CXTP)", RFC 4067, July 2005. "Context Transfer Protocol (CXTP)", RFC 4067, July 2005.
[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP Version 6 Route Optimization Security Nordmark, "Mobile IP Version 6 Route Optimization Security
Design Background", RFC 4225, December 2005. Design Background", RFC 4225, December 2005.
[RFC4295] Keeni, G., Koide, K., Nagami, K., and S. Gundavelli,
"Mobile IPv6 Management Information Base", RFC 4295, April
2006.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006. (MOBIKE)", RFC 4555, June 2006.
[RFC4640] Patel, A. and G. Giaretta, "Problem Statement for [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for
bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, September bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, September
2006. 2006.
[RFC4889] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network [RFC4889] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network
Mobility Route Optimization Solution Space Analysis", RFC Mobility Route Optimization Solution Space Analysis", RFC
4889, July 2007. 4889, July 2007.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC
4960, September 2007.
[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6
Socket API for Source Address Selection", RFC 5014, Socket API for Source Address Selection", RFC 5014,
September 2007. September 2007.
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
Bootstrapping in Split Scenario", RFC 5026, October 2007. Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, [RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf,
"Mobility Header Home Agent Switch Message", RFC 5142, "Mobility Header Home Agent Switch Message", RFC 5142,
January 2008. January 2008.
skipping to change at page 27, line 22 skipping to change at page 27, line 39
[RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, July [RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, July
2009. 2009.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", RFC 5844, May 2010. Mobile IPv6", RFC 5844, May 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
5996, September 2010. 5996, September 2010.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC6097] Korhonen, J. and V. Devarapalli, "Local Mobility Anchor [RFC6097] Korhonen, J. and V. Devarapalli, "Local Mobility Anchor
(LMA) Discovery for Proxy Mobile IPv6", RFC 6097, February (LMA) Discovery for Proxy Mobile IPv6", RFC 6097, February
2011. 2011.
[RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
Deployment for Multicast Listener Support in Proxy Mobile Deployment for Multicast Listener Support in Proxy Mobile
IPv6 (PMIPv6) Domains", RFC 6224, April 2011. IPv6 (PMIPv6) Domains", RFC 6224, April 2011.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011. in IPv6", RFC 6275, July 2011.
[RFC6463] Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui, [RFC6463] Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui,
"Runtime Local Mobility Anchor (LMA) Assignment Support "Runtime Local Mobility Anchor (LMA) Assignment Support
for Proxy Mobile IPv6", RFC 6463, February 2012. for Proxy Mobile IPv6", RFC 6463, February 2012.
[RFC6475] Keeni, G., Koide, K., Gundavelli, S., and R. Wakikawa,
"Proxy Mobile IPv6 Management Information Base", RFC 6475,
May 2012.
[RFC6611] Chowdhury, K. and A. Yegin, "Mobile IPv6 (MIPv6) [RFC6611] Chowdhury, K. and A. Yegin, "Mobile IPv6 (MIPv6)
Bootstrapping for the Integrated Scenario", RFC 6611, May Bootstrapping for the Integrated Scenario", RFC 6611, May
2012. 2012.
[RFC6697] Zorn, G., Wu, Q., Taylor, T., Nir, Y., Hoeper, K., and S. [RFC6697] Zorn, G., Wu, Q., Taylor, T., Nir, Y., Hoeper, K., and S.
Decugis, "Handover Keying (HOKEY) Architecture Design", Decugis, "Handover Keying (HOKEY) Architecture Design",
RFC 6697, July 2012. RFC 6697, July 2012.
[RFC6705] Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A. [RFC6705] Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A.
Dutta, "Localized Routing for Proxy Mobile IPv6", RFC Dutta, "Localized Routing for Proxy Mobile IPv6", RFC
6705, September 2012. 6705, September 2012.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012.
[RFC7028] Zuniga, JC., Contreras, LM., Bernardos, CJ., Jeon, S., and [RFC7028] Zuniga, JC., Contreras, LM., Bernardos, CJ., Jeon, S., and
Y. Kim, "Multicast Mobility Routing Optimizations for Y. Kim, "Multicast Mobility Routing Optimizations for
Proxy Mobile IPv6", RFC 7028, September 2013. Proxy Mobile IPv6", RFC 7028, September 2013.
[SDO-3GPP.23.401] [SDO-3GPP.23.401]
3GPP, "General Packet Radio Service (GPRS) enhancements 3GPP, "General Packet Radio Service (GPRS) enhancements
for Evolved Universal Terrestrial Radio Access Network for Evolved Universal Terrestrial Radio Access Network
(E-UTRAN) access", 3GPP TS 23.401 10.10.0, March 2013. (E-UTRAN) access", 3GPP TS 23.401 10.10.0, March 2013.
[SDO-3GPP.23.402] [SDO-3GPP.23.402]
 End of changes. 71 change blocks. 
215 lines changed or deleted 256 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/