draft-ietf-dmm-best-practices-gap-analysis-02.txt   draft-ietf-dmm-best-practices-gap-analysis-03.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: April 23, 2014 InterDigital Expires: August 18, 2014 InterDigital
P. Seite P. Seite
Orange Orange
H. Chan H. Chan
Huawei Technologies Huawei Technologies
CJ. Bernardos CJ. Bernardos
UC3M UC3M
October 20, 2013 February 14, 2014
Distributed Mobility Management: Current practices and gap analysis Distributed Mobility Management: Current practices and gap analysis
draft-ietf-dmm-best-practices-gap-analysis-02 draft-ietf-dmm-best-practices-gap-analysis-03
Abstract Abstract
The present document analyses deplyment practices of existing The present document analyzes deployment practices of existing IP
mobility protocols in a distributed mobility management environment. mobility protocols in a distributed mobility management environment.
It also identifies some limitations compared to the expected It then identifies existing limitations when compared to the
functionality of a fully distributed mobility management system. The requirements defined for a distributed mobility management solution.
comparison is made taking into account the identified DMM
requirements.
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 April 23, 2014. This Internet-Draft will expire on August 18, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Functions of existing mobility protocols . . . . . . . . . . . 4 3. Functions of existing mobility protocols . . . . . . . . . . 3
4. DMM practices . . . . . . . . . . . . . . . . . . . . . . . . 5 4. DMM practices . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. IP flat wireless network . . . . . . . . . . . . . . . . . 6 4.2. IP flat wireless network . . . . . . . . . . . . . . . . 5
4.2.1. Host-based IP DMM practices . . . . . . . . . . . . . 8 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 . . . . . . . . . . . 11
4.3. 3GPP network flattening approaches . . . . . . . . . . . . 14 4.3. 3GPP network flattening approaches . . . . . . . . . . . 13
5. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Distributed processing - REQ1 . . . . . . . . . . . . . . 17 5.1. Distributed processing - REQ1 . . . . . . . . . . . . . . 16
5.2. Transparency to Upper Layers - REQ2 . . . . . . . . . . . 19 5.2. Bypassable network-layer mobility support - REQ2 . . . . 18
5.3. IPv6 deployment - REQ3 . . . . . . . . . . . . . . . . . . 19 5.3. IPv6 deployment - REQ3 . . . . . . . . . . . . . . . . . 19
5.4. Existing mobility protocols - REQ4 . . . . . . . . . . . . 20 5.4. Existing mobility protocols - REQ4 . . . . . . . . . . . 19
5.5. Co-existence - REQ5 . . . . . . . . . . . . . . . . . . . 20 5.5. Co-existence - REQ5 . . . . . . . . . . . . . . . . . . . 19
5.6. Security considerations - REQ6 . . . . . . . . . . . . . . 20 5.6. Security considerations - REQ6 . . . . . . . . . . . . . 20
5.7. Multicast - REQ7 . . . . . . . . . . . . . . . . . . . . . 21 5.7. Multicast - REQ7 . . . . . . . . . . . . . . . . . . . . 20
5.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . . 22 8.1. Normative References . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . . 23 8.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The distributed mobility management (DMM) WG has studied the problems The distributed mobility management (DMM) WG has studied the problems
of centralized deployment of mobility management protocols and the of centralized deployment of mobility management protocols and
related requirements [I-D.ietf-dmm-requirements]. In order to guide specified the DMM requirements [I-D.ietf-dmm-requirements]. This
the deployment and before defining any new DMM protocol, the DMM WG document investigates whether it is feasible to deploy current IP
is chartered to investigate first whether it is feasible to deploy mobility protocols in a DMM scenario in a way that can fulfill the
current IP mobility protocols in a DMM scenario in a way that can requirements. It discusses current deployment practices of existing
fullfil the requirements of DMM. This document discusses current mobility protocols in a distributed mobility management environment
deployment practices of existing mobility protocols in a distributed and identifies the limitations (gaps) in these practices with respect
mobility management environment and identifies the limitations in to the DMM functionality, as defined in [I-D.ietf-dmm-requirements].
these practices with respect to the expected functionality.
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 reconfigured 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 flat environment. Section 4 presents the current practices of IP flat
wireless networks and 3GPP architectures. Both network- and host- wireless networks and 3GPP architectures. Both network- and host-
based mobility protocols are considered. Section 5 presents the gap based 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", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. 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] and in the Proxy mobile IPv6 specification
[RFC5213]. These terms include mobile node (MN), correspondent node [RFC5213]. These terms include mobile node (MN), correspondent node
(CN), home agent (HA), local mobility anchor (LMA), and mobile access (CN), home agent (HA), local mobility anchor (LMA), and mobile access
gateway (MAG). gateway (MAG).
In addition, this document uses the following terms: In addition, this document also introduces some definitions of IP
mobility functions in Section 3.
Mobility routing (MR) is the logical function that intercepts
packets to/from the IP address/prefix delegated to the mobile node
and forwards them, based on internetwork location information,
either directly towards their destination or to some other network
element that knows how to forward the packets to their ultimate
destination.
Home address allocation is the logical function that allocates the
IP address/prefix (e.g., home address or home network prefix) to a
mobile node.
Location management (LM) is the logical function that manages and
keeps track of the internetwork location information of a mobile
node, which includes the mapping of the IP address/prefix
delegated to the MN to the MN routing address or another network
element that knows where to forward packets destined for the MN.
Home network of an application session (or an HoA IP address) is the
network that has allocated the IP address used as the session
identifier (home address) by the application being run in an MN.
The MN may be attached to more than one home networks.
In the document, several references to a distributed mobility In this document there are also references to a "distributed mobility
management environment are made. By this term, we refer to an management environment". By this term, we refer to a scenario in
scenario in which the IP mobility, access network and routing which the IP mobility, access network and routing solutions allow for
solutions allow for setting up IP networks so that traffic is setting up IP networks so that traffic is distributed in an optimal
distributed in an optimal way and does not rely on centrally deployed way, without relying on centrally deployed anchors to manage IP
anchors to manage IP mobility sessions. 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 [RFC6275] and its network-based extension,
PMIPv6 [RFC5213], are both logically centralized mobility management PMIPv6 [RFC5213], are both logically centralized mobility management
approaches addressing primarily hierarchical mobile networks. approaches addressing primarily hierarchical mobile networks.
Although they are centralized approaches, they have important Although they are centralized approaches, they have important
mobility management functions resulting from years of extensive work mobility management functions resulting from years of extensive work
to develop and to extend these functions. It is therefore fruitful to develop and to extend these functions. It is therefore useful to
to take these existing functions and examine them in a DMM scenario take these existing functions and examine them in a DMM scenario in
in order to understand how to deploy the existing mobility protocols order to understand how to deploy the existing mobility protocols in
in a distributed mobility management environment. a distributed mobility management environment.
The existing mobility management functions of MIPv6, PMIPv6, and The main mobility management functions of MIPv6, PMIPv6, and HMIPv6
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
addres/prefix (e.g., a HoA or HNP) topologically anchored by the address/prefix (e.g., a Home Address or Home Network Prefix)
delegating node (i.e., the anchor node is able to advertise a topologically anchored by the delegating node (i.e., the anchor
connected route into the routing infrastructure for the delegated node is able to advertise a connected route into the routing
IP prefixes). infrastructure for the delegated IP prefixes). It is a control
plane function.
2. Mobility Routing (MR) function: packets interception and 2. Internetwork Location Management (LM) function: managing and
keeping track of the internetwork location of an MN. The
location information may be a mapping of the IP delegated 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. It is a
control plane function.
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: packet interception and
forwarding to/from the IP address/prefix delegated to the MN, forwarding to/from the IP address/prefix delegated to the MN,
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.
3. Internetwork Location Management (LM) function: managing and RM may optionally be split into the control plane (RM-CP) and
keeping track of the internetwork location of an MN, which data plane (RM-DP).
includes a mapping of the IP delegated address/prefix (e.g., HoA
or HNP) to the mobility anchoring point where the MN is anchored
to;
4. Location Update (LU): provisioning of MN location information to In Mobile IPv6 [RFC6275], the home agent (HA) typically provides the
the LM function; anchoring function (AF); the location management server (LMs) is at
the HA while the location management client (LMc) is at the MN; the
routing management (RM) function is both ends of tunneling at the HA
and the MN.
In Mobile IPv6 [RFC6275], the home agent typically provides the In Proxy Mobile IPv6 [RFC5213], the Local Mobility Anchor (LMA)
anchoring function (AF), Mobility Routing (MR), and Internetwork provides the anchoring function (AF); the location management server
Location Management (LM) functions, while the mobile node provides (LMs) is at the LMA while the location management client (LMc) is at
the Location Update (LU) function. Proxy Mobile IPv6 [RFC5213] the mobile access gateway (MAG); the routing management (RM) function
relies on the function of the Local Mobility Anchor (LMA) to provide is both ends of tunneling at the HA and the MAG.
mobile nodes with mobility support, without requiring the involvement
of the mobile nodes. The required functionality at the mobile node In Hirarchical mobile IPv6 (HMIPv6) [RFC5380], a location management
is provided in a proxy manner by the Mobile Access Gateway (MAG). proxy is at the mobility anchor point (MAP) to proxy between the LMs
With network-based IP mobility protocols, the local mobility anchor at the LMA and the LMc at the MN. The MAP also has RM funtion to
typically provides the anchoring function (AF), Mobility Routing enable tunneling between LMA and itself as well as tunneling between
(MR), and Internetwork Location Management (LM) functions, while the MN and itself.
mobile access gateway provides the Location Update (LU) function.
4. DMM practices 4. DMM practices
This section documents deployment practices of existing mobility This section documents deployment practices of existing mobility
protocols in a distributed mobility management environment. This protocols in a distributed mobility management environment. This
description is divided into two main families of network description is divided into two main families of network
architectures: i) IP flat wireless networks (e.g., evolved WiFi architectures: i) IP flat wireless networks (e.g., evolved Wi-Fi
hotspots) and, ii) 3GPP network flattening approaches. hotspots) and, ii) 3GPP network flattening approaches.
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 will be mobility management functions described in Section 3 are provided, as
provided, as well as some initial hints on the identified gaps with well as some initial hints on the identified gaps with respect to the
respect to the DMM requirement documented in DMM requirements documented in [I-D.ietf-dmm-requirements].
[I-D.ietf-dmm-requirements].
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.
Since this document cannot be too exhaustive, the focus is on current The focus of the gap analysis is on current mobile network
mobile network architectures and standardized IP mobility solutions. architectures and standardized IP mobility solutions, considering any
In order to limit the scope of our analysis of current DMM practices, kind of deployment options which do not violate the original protocol
we consider the following list of technical assumptions: specifications. In order to limit the scope of our analysis of
current DMM practices, we consider the following list of technical
assumptions:
1. Both host- and network-based solutions should be covered. 1. Both host- and network-based solutions SHOULD be considered.
2. Solution should allow selecting and using the most appropriate IP 2. Solutions SHOULD allow selecting and using the most appropriate
anchor among a set of distributed ones. IP anchor among a set of available ones.
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 during the IP address across the different points of attachment (i.e.,
mobility (i.e., provision of IP address continuity). IP flows of provision of IP address continuity).
applications which do not need a constant IP address should not
be handled by DMM. Typically, the a connection manager together
with the operating system configure the source address selection
mechanism of the IP stack. This might involve identifying
application capabilities and triggering the mobility support
accordingly. Further considerations on application management
and source address selection are out of the scope of this
document.
4. Mobility management and traffic redirection should only be Applications which can cope with changes in the MN's IP address do
triggered due to IP mobility reasons, that is when the MN moves not depend on IP mobility management protocols such as DMM.
from the point of attachment where the IP flow was originally Typically, a connection manager together with the operating system
initiated. will configure the source address selection mechanism of the IP
stack. This might involve identifying application capabilities and
triggering the mobility support accordingly. Further considerations
on application management and source address selection are out of the
scope of this document.
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 WiFi an view using common and standardized protocols. We take Wi-Fi as an
exemplary wireless technology, as it is widely known and deployed exemplary wireless technology, since it is widely known and deployed
nowadays. Some representative examples of WiFi deployed nowadays. Some representative examples of Wi-Fi deployment
architectures are depicted on Figure 1. architectures are depicted in Figure 1.
+-------------+ _----_ +-------------+ _----_
+---+ | Access | _( )_ +---+ | Access | _( )_
|AAA|. . . . . . | Aggregation |----------( Internet ) |AAA|. . . . . . | Aggregation |----------( Internet )
+---+ | Gateway | (_ _) +---+ | Gateway | (_ _)
+-------------+ '----' +-------------+ '----'
| | | | | |
| | +-------------+ | | +-------------+
| | | | | |
| | +-----+ | | +-----+
+---------------+ | | AR | +---------------+ | | AR |
| | +--+--+ | | +--+--+
+-----+ +-----+ *----+----* +-----+ +-----+ *----+----*
| RG | | WLC | ( LAN ) | RG | | WLC | ( LAN )
+-----+ +-----+ *---------* +-----+ +-----+ *---------*
. / \ / \ . / \ / \
/ \ +----+ +----+ +----+ +----+ / \ +-----+ +-----+ +-----+ +-----+
MN MN |WiFi| |WiFi| |WiFi| |WiFi| MN MN |Wi-Fi| |Wi-Fi| |Wi-Fi| |Wi-Fi|
| AP | | AP | | AP | | AP | | AP | | AP | | AP | | AP |
+----+ +----+ +----+ +----+ +-----+ +-----+ +-----+ +-----+
. . . .
/ \ / \ / \ / \
MN MN MN MN MN MN MN MN
Figure 1: IP WiFi 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 directly connect to a Residential Gateway
(RG) which is a network device that is located in the customer (RG) which is a network device at the customer premises and provides
premises and provides both wireless layer-2 access connectivity both wireless layer-2 access connectivity (i.e., it hosts the 802.11
(i.e., it hosts the 802.11 Access Point function) with layer-3 Access Point function) and layer-3 routing functions. In the middle
routing functions. In the middle, mobile nodes connect to WiFi of the figure, mobile nodes connect to Wi-Fi Access Points (APs) that
Access Points (APs) that are managed by a WLAN Controller (WLC), are managed by a WLAN Controller (WLC), which performs radio resource
which performs radio resource management on the APs, system-wide management on the APs, system-wide mobility policy enforcement and
mobility policy enforcement and centralized forwarding function for centralized forwarding function for the user traffic. The WLC could
the user traffic. The WLC could also implement layer-3 routing also implement layer-3 routing functions, or attach to an access
functions, or attach to an access router (AR). Last, on the right- router (AR). Last, on the right-hand side of the figure, access
hand side of the figure, access points are directly connected to an points are directly connected to an access router. This can also be
access router, which can also be used a generic connectivity model. used as a generic connectivity model.
In some network architectures, such as the evolved Wi-Fi hotspot, In some network architectures, such as the evolved Wi-Fi hotspot,
operators might make use of IP mobility protocols to provide mobility operators might make use of IP mobility protocols to provide mobility
support to users, for example to allow connecting the IP WiFi network support to users, for example to allow connecting the IP Wi-Fi
to a mobile operator core and support roaming between WLAN and 3GPP network to a mobile operator core and support roaming between WLAN
accesses. Two main protocols can be used: Proxy Mobile IPv6 and 3GPP accesses. Two main protocols can be used: Proxy Mobile IPv6
[RFC5213] or Mobile IPv6 [RFC6275], [RFC5555], with the anchor role
(e.g., local mobility anchor or home agent) typically being played by [RFC5213] or Mobile IPv6 [RFC6275], [RFC5555], with the anchor (e.g.,
the Access Aggregation Gateway or even by an entity placed on the local mobility anchor or home agent) role typically being played by
the Access Aggregation Gateway or even by an entity placed in the
mobile operator's core network. mobile operator's core network.
Although we have adopted in this section the example of WiFi Although this section has adopted the example of Wi-Fi networks,
networks, there are other IP flat wireless network architectures there are other IP flat wireless network architectures specified,
specified, such as WiMAX [IEEE.802-16.2009], which integrates both such as WiMAX [IEEE.802-16.2009], which integrates both host and
host and network-based IP mobility functionality. network-based IP mobility functionality.
Existing IP mobility protocols can also be deployed in a "flatter" Existing IP mobility protocols can also be deployed in a more
way, so the anchoring and access aggregation functions are flattened manner, so that the anchoring and access aggregation
distributed. We next describe several practices for the deployment functions are distributed. We next describe several practices for
of existing mobility protocols in a distributed mobility management the deployment of existing mobility protocols in a distributed
environment. We limit our analysis in this section to protocol mobility management environment. The analysis in this section is
solutions based on existing IP mobility protocols, either host- or limited to protocol solutions based on existing IP mobility
network-based, such as Mobile IPv6 [RFC6275], [RFC5555], Proxy Mobile protocols, either host- or network-based, such as Mobile IPv6
IPv6 [RFC5213], [RFC5844] and NEMO [RFC3963]. Extensions to these [RFC6275], [RFC5555], Proxy Mobile IPv6 [RFC5213], [RFC5844] and NEMO
base protocol solutions are also considered. We pay special [RFC3963]. Extensions to these base protocol solutions are also
attention to the management of the use of care-of-addresses versus considered. We pay special attention to how to efficiently select
home addresses in an efficient manner for different types of the source address (care-of-addresses versus home addresses) for
communications. Finally, and in order to simplify the analysis, we different types of communications. The analysis is divided into two
divide it into two parts: host- and 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 NEMO) networks, the NEMO Basic Support protocol (hereafter, simply referred
[RFC3963] are well-known host-based IP mobility protocols. They to as NEMO) [RFC3963] are well-known host-based IP mobility
heavily rely on the function of the Home Agent (HA), a centralized protocols. They heavily rely on the function of the Home Agent (HA),
anchor, to provide mobile nodes (hosts and routers) with mobility a centralized anchor, to provide mobile nodes (hosts and routers)
support. In these approaches, the home agent typically provides the with mobility support. In these approaches, the home agent typically
anchoring function (AF), Mobility Routing (MR), and Internetwork provides the anchoring function (AF), Routing management (RM), and
Location Management (LM) functions, while the mobile node provides Internetwork Location Management server (LMs) functions. The mobile
the Location Update (LU) function. We next describe some practices node possesses the Location management client (LMc) function and the
on how Mobile IPv6/NEMO and several additional protocol extensions RM function to enable tunneling between HA and itself. We next
can be deployed in a distributed mobility management environment. describe some practices on how MIPv6/NEMO and several additional
protocol extensions can be deployed in a distributed mobility
management environment.
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 to each MN the one closest to its (as shown in Figure 2), and assign the topologically closest anchor
topological location [RFC4640], [RFC5026], [RFC6611]. In the example to each MN [RFC4640], [RFC5026], [RFC6611]. In the example shown in
shown in Figure 2, MN1 is assigned HA1 (and a home address anchored Figure 2, MN1 is assigned HA1 (and a home address anchored by HA1),
by HA1), while MN2 is assigned HA2. Note that Mobile IPv6 / NEMO while MN2 is assigned HA2. Note that MIPv6/NEMO specifications do
specifications do not prevent the simultaneous use of multiple home not prevent the simultaneous use of multiple home agents by a single
agents by a single mobile node. This deployment model could be mobile node. This deployment model could be exploited by a mobile
exploited by a mobile node to meet assumption #4 and use several node to meet assumption #4 of Section 4.1 and use several anchors at
anchors at the same time, each of them anchoring IP flows initiated the same time, each of them anchoring IP flows initiated at a
at different point of attachment. However there is no mechanism different point of attachment. However there is no mechanism
specified by the IETF to enable an efficient dynamic discovery of specified by IETF to enable an efficient dynamic discovery of
available anchors and the selection of the most suitable one. Note available anchors and the selection of the most suitable one. Note
that some of these mechanisms have been defined outside the IETF that some of these mechanisms have been defined outside IETF (e.g.,
(e.g., 3GPP). 3GPP).
<- 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) -------
------- -------
------- -------
| HA2 | ------- | HA2 | -------
------- | AR3 |-(o) zzzz (o) ------- | AR3 |-(o) zzzz (o)
------- | ------- |
------- (MN2 anchored at HA2) ------- ------- (MN2 anchored at HA2) -------
| CN2 | ------- | MN2 | | CN2 | ------- | MN2 |
------- | AR4 |-(o) ------- ------- | AR4 |-(o) -------
------- -------
CN1 CN2 HA1 HA2 AR1 MN1 AR3 MN2 CN1 CN2 HA1 HA2 AR1 MN1 AR3 MN2
| | | | | | | | | | | | | | | |
|<------------>|<=================+=====>| | | BT mode |<------------>|<=================+=====>| | | BT mode
| | | | | | | | | | | | | | | |
| |<----------------------------------------+----->| RO mode | |<----------------------------------------+----->| RO mode
| | | | | | | | | | | | | | | |
Figure 2: Distributed operation of Mobile IPv6 (BT and RO) / NEMO Figure 2: Distributed operation of Mobile IPv6 (BT and RO) / NEMO
Since one of the goals of the deployment of mobility protocols in a Since one of the goals of the deployment of mobility protocols in a
distributed mobility management environment is to avoid the distributed mobility management environment is to avoid the
suboptimal routing caused by centralized anchoring, the Route suboptimal routing caused by centralized anchoring, the Route
Optimization (RO) support provided by Mobile IPv6 can also be used to Optimization (RO) support provided by Mobile IPv6 can also be used to
achieve a flatter IP data forwarding. By default, Mobile IPv6 and achieve a flatter IP data forwarding. By default, Mobile IPv6 and
NEMO use the so-called Bidirectional Tunnel (BT) mode, in which data NEMO use the so-called Bidirectional Tunnel (BT) mode, in which data
traffic is always encapsulated between the MN and its HA before being traffic is always encapsulated between the MN and its HA before being
directed to any other destination. The Route Optimization (RO) mode directed to any other destination. The Route Optimization (RO) mode
allows the MN to update its current location on the CNs, and then use allows the MN to update its current location on the CNs, and then use
the direct path between them. Using the example shown in Figure 2, the direct path between them. Using the example shown in Figure 2,
MN1 is using BT mode with CN2 and MN2 is in RO mode with CN1. MN1 is using BT mode with CN1 and MN2 is in RO mode with CN2.
However, the RO mode has several drawbacks: However, the RO mode has several drawbacks:
o The RO mode is only supported by Mobile IPv6. There is no route o The RO mode is only supported by Mobile IPv6. There is no route
optimization support standardized for the NEMO protocol because of optimization support standardized for the NEMO protocol because of
the security problems posed by extending return routability tests the security problems posed by extending return routability tests
for prefixes, although many different solutions have been for prefixes, although many different solutions have been proposed
proposed. [RFC4889].
o The RO mode requires additional signaling, which adds some o The RO mode requires additional signaling, which adds some
protocol overhead. protocol overhead.
o The signaling required to enable RO involves the home agent, and o The signaling required to enable RO involves the home agent and is
it is repeated periodically because of security reasons [RFC4225]. repeated periodically for security reasons [RFC4225]. This
This basically means that the HA remains as single point of basically means that the HA remains a single point of failure,
failure, because the Mobile IPv6 RO mode does not mean HA-less because the Mobile IPv6 RO mode does not mean HA-less operation.
operation.
o The RO mode requires additional support on the correspondent node o The RO mode requires additional support from the correspondent
(CN). node (CN).
Notwithstanding these considerations, the RO mode does offer the Notwithstanding these considerations, the RO mode does offer the
possibility of substantially reducing traffic through the Home Agent, possibility of substantially reducing traffic through the Home Agent,
in cases when it can be supported on the relevant correspondent in cases when it can be supported by the relevant correspondent
nodes. Note that a mobile node can also use its CoA directly nodes. Note that a mobile node can also use its CoA directly
[RFC5014] when communicating with CNs on the same link or anywhere in [RFC5014] when communicating with CNs on the same link or anywhere in
the Internet, although no session continuity support would be the Internet, although no session continuity support would be
provided by the IP stack in this case. provided by the IP stack in this case.
Hierarchical Mobile IPv6 (HMIPv6) [RFC5380] (as shown in Figure 3),
is another host-based IP mobility extension which can be considered
as a complement to provide a less centralized mobility deployment.
It allows reducing the amount of mobility signaling as well as
improving the overall handover performance of Mobile IPv6 by
introducing a new hierarchy level to handle local mobility. The
Mobility Anchor Point (MAP) entity is introduced as a local mobility
handling node deployed closer to the mobile node. It provides LM
proxy function between the LM server (LMs) at the HA and the LM
client (LMc) at the MN. It also possess RM function to tunnel with
the HA and also to tunnel with the MN.
<- INTERNET -> <- HOME NETWORK -> <------- ACCESS NETWORK -------> <- INTERNET -> <- HOME NETWORK -> <------- ACCESS NETWORK ------->
----- -----
/|AR1|-(o) zz (o) /|AR1|-(o) zz (o)
-------- / ----- | -------- / ----- |
| MAP1 |< ------- | MAP1 |< -------
-------- \ ----- | MN1 | -------- \ ----- | MN1 |
------- \|AR2| ------- ------- \|AR2| -------
| CN1 | ----- HoA anchored | CN1 | ----- HoA anchored
------- ----- at HA1 ------- ----- at HA1
------- /|AR3| RCoA anchored ------- /|AR3| RCoA anchored
skipping to change at page 11, line 37 skipping to change at page 10, line 23
CN1 CN2 HA1 MAP1 AR1 MN1 CN1 CN2 HA1 MAP1 AR1 MN1
| | | | ________|__________ | | | | | ________|__________ |
|<------------------>|<==============>|<________+__________>| HoA |<------------------>|<==============>|<________+__________>| HoA
| | | | | | | | | | | |
| |<-------------------------->|<===================>| RCoA | |<-------------------------->|<===================>| RCoA
| | | | | | | | | | | |
Figure 3: Hierarchical Mobile IPv6 Figure 3: Hierarchical Mobile IPv6
Hierarchical Mobile IPv6 (HMIPv6) [RFC5380] is another host-based IP
mobility extension that can be considered as a complement to provide
a less centralized mobility deployment. It allows reducing the
amount of mobility signaling as well as improving the overall
handover performance of Mobile IPv6 by introducing a new hierarchy
level to handle local mobility. The Mobility Anchor Point (MAP)
entity is introduced as a local mobility handling node deployed
closer to the mobile node.
When HMIPv6 is used, the MN has two different temporal addresses: the When HMIPv6 is used, the MN has two different temporal addresses: the
Regional Care-of Address (RCoA) and the Local Care-of Address (LCoA). Regional Care-of Address (RCoA) and the Local Care-of Address (LCoA).
The RCoA is anchored at one MAP, that plays the role of local home The RCoA is anchored at one MAP, that plays the role of local home
agent, while the LCoA is anchored at the access router level. The agent, while the LCoA is anchored at the access router level. The
mobile node uses the RCoA as the CoA signaled to its home agent. mobile node uses the RCoA as the CoA signaled to its home agent.
Therefore, while roaming within a local domain handled by the same Therefore, while roaming within a local domain handled by the same
MAP, the mobile node does not need to update its home agent (i.e., MAP, the mobile node does not need to update its home agent (i.e.,
the mobile node does not change RCoA). the mobile node does not change its RCoA).
The use of HMIPv6 allows some route optimization, as a mobile node The use of HMIPv6 allows achieving some form of route optimization,
may decide to directly use the RCoA as source address for a since a mobile node may decide to directly use the RCoA as source
communication with a given correspondent node, notably if the MN does address for a communication with a given correspondent node, notably
not expect to move outside the local domain during the lifetime of if the MN does not expect to move outside the local domain during the
the communication. This can be seen as a potential DMM mode of lifetime of the communication. This can be seen as a potential DMM
operation. In the example shown in Figure 3, MN1 is using its global mode of operation. In the example shown in Figure 3, MN1 is using
HoA to communicate with CN1, while it is using its RCoA to its global HoA to communicate with CN1, while it is using its RCoA to
communicate with CN2. communicate with CN2.
Additionally, a local domain might have several MAPs deployed, Additionally, a local domain might have several MAPs deployed,
enabling hence different kind of HMIPv6 deployments (e.g., flat and enabling therefore a different kind of HMIPv6 deployments (e.g., flat
distributed). The HMIPv6 specification supports a flexible selection and distributed). The HMIPv6 specification supports a flexible
of the MAP (e.g., based on the distance between the MN and the MAP, selection of the MAP (e.g., based on the distance between the MN and
taking into consideration the expected mobility pattern of the MN, the MAP, taking into consideration the expected mobility pattern of
etc.). the MN, etc.).
An additional extension that can be used to help deploying a mobility An additional extension that can be used to help deploying a mobility
protocol in a distributed mobility management environment is the the protocol in a distributed mobility management environment is the Home
Home Agent switch specification [RFC5142], which defines a new Agent switch specification [RFC5142], which defines a new mobility
mobility header for signaling a mobile node that it should acquire a header for signaling a mobile node that it should acquire a new home
new home agent. Even though the purposes of this specification do agent. Even though the purposes of this specification do not include
not include the case of changing the mobile node's home address, as the case of changing the mobile node's home address, as that might
that might imply loss of connectivity for ongoing persistent imply loss of connectivity for ongoing persistent connections, it
connections, it could be used to force the change of home agent in could be used to force the change of home agent in those situations
those situations where there are no active persistent data sessions where there are no active persistent data sessions that cannot cope
that cannot cope with a change of home address. with a change of home address.
There other host-based approaches standardized within the IETF that There are other host-based approaches standardized within IETF that
can be used to provide mobility support. For example MOBIKE can be used to provide mobility support. For example MOBIKE
[RFC4555] allows a mobile node encrypting traffic through IKEv2 [RFC4555] allows a mobile node encrypting traffic through IKEv2
[RFC5996] to change its point of attachment while maintaining a [RFC5996] to change its point of attachment while maintaining a
Virtual Private Network (VPN) session. The MOBIKE protocol allows Virtual Private Network (VPN) session. The MOBIKE protocol allows
updating the VPN Security Associations (SAs) in cases where the base updating the VPN Security Associations (SAs) in cases where the base
connection initially used is lost and needs to be re-established. connection initially used is lost and needs to be re-established.
The use of the MOBIKE protocol avoids having to perform an IKEv2 re- The use of the MOBIKE protocol avoids having to perform an IKEv2 re-
negotiation. Similar considerations to those made for Mobile IPv6 negotiation. Similar considerations to those made for Mobile IPv6
can be applied to MOBIKE; though MOBIKE is best suited for situations can be applied to MOBIKE; though MOBIKE is best suited for situations
where the address of at least one endpoint is relatively stable and where the address of at least one endpoint is relatively stable and
can be discovered using existing mechanisms such as DNS. can be discovered using existing mechanisms such as DNS.
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 ([RFC5844] defines some IPv4 mobility protocol specified for IPv6 ([RFC5844] defines some IPv4
extensions). Architecturally, PMIPv6 is similar to MIPv6, as it extensions). With network-based IP mobility protocols, the local
relies on the function of the Local Mobility Anchor (LMA) to provide mobility anchor (LMA) typically provides the anchoring function (AF),
mobile nodes with mobility support, without requiring the involvement Routing management (RM) function, Internetwork Location Management
of the mobile nodes. The required functionality at the mobile node server (LMs) function and RM function. The mobile access gateway
is provided in a proxy manner by the Mobile Access Gateway (MAG). (MAG) provides the Location Management client (LMc) function and
With network-based IP mobility protocols, the local mobility anchor Routing management (RM) function to tunnel with LMA. PMIPv6 is
typically provides the anchoring function (AF), Mobility Routing architecturally similar to MIPv6, as the mobility signaling and
(MR), and Internetwork Location Management (LM) functions, while the routing between LMA and MAG in PMIPv6 is similar to those between HA
mobile access gateway provides the Location Update (LU) function. We and MN in MIPv6. The required mobility functionality at the MN is
next describe some practices on how network-based mobility protocols provided by the MAG so that the involvement in mobility support by
and several additional protocol extensions can be deployed in a the MN is not required.
distributed mobility management environment.
We next describe some practices on how network-based mobility
protocols and several additional protocol extensions can be deployed
in a distributed mobility management environment.
One simple but still suboptimal approach to decentralize Proxy Mobile
IPv6 operation can be to deploy several local mobility anchors and
use some selection criteria to assign LMAs to attaching mobile nodes
(an example of this type of assignment is shown in Figure 4). As per
the client based approach, a mobile node may use several anchors at
the same time, each of them anchoring IP flows initiated at a
different point of attachment. This assignment can be static or
dynamic (as described later in this document). The main advantage of
this simple approach is that the IP address anchor (i.e., the LMA)
could be placed closer to the mobile node. Therefore the resulting
paths are close-to-optimal. On the other hand, as soon as the mobile
node moves, the resulting path will start deviating from the optimal
one.
<- INTERNET -><- HOME NET -><----------- ACCESS NETWORK ------------> <- INTERNET -><- HOME NET -><----------- ACCESS NETWORK ------------>
------- -------
| CN1 | -------- -------- -------- | CN1 | -------- -------- --------
------- -------- | MAG1 | | MAG2 | | MAG3 | ------- -------- | MAG1 | | MAG2 | | MAG3 |
| LMA1 | ---+---- ---+---- ---+---- | LMA1 | ---+---- ---+---- ---+----
------- -------- | | | ------- -------- | | |
| CN2 | (o) (o) (o) | CN2 | (o) (o) (o)
------- -------- x x ------- -------- x x
| LMA2 | x x | LMA2 | x x
skipping to change at page 13, line 39 skipping to change at page 12, line 34
CN1 CN2 LMA1 LMA2 MAG1 MN1 MAG3 MN2 CN1 CN2 LMA1 LMA2 MAG1 MN1 MAG3 MN2
| | | | | | | | | | | | | | | |
|<------------>|<================>|<---->| | | |<------------>|<================>|<---->| | |
| | | | | | | | | | | | | | | |
| |<------------>|<========================>|<----->| | |<------------>|<========================>|<----->|
| | | | | | | | | | | | | | | |
Figure 4: Distributed operation of Proxy Mobile IPv6 Figure 4: Distributed operation of Proxy Mobile IPv6
As with Mobile IPv6, plain Proxy Mobile IPv6 operation cannot be Similar to the host-based IP mobility case, network-based IP mobility
easily decentralized, as in this case there also exists a single has some extensions defined to mitigate the suboptimal routing issues
network anchor point. One simple but still suboptimal approach, can that may arise due to the use of a centralized anchor. The Local
be to deploy several local mobility anchors and use some selection Routing extensions [RFC6705] enable optimal routing in Proxy Mobile
criteria to assign LMAs to attaching mobile nodes (an example of this IPv6 in three cases: i) when two communicating MNs are attached to
type of assignment is shown in Figure 4). As per the client based the same MAG and LMA, ii) when two communicating MNs are attached to
approach, a mobile node may use several anchors at the same time, different MAGs but to the same LMA, and iii) when two communicating
each of them anchoring IP flows initiated at different point of MNs are attached to the same MAG but have different LMAs. In these
attachment. This assignment can be static or dynamic (as described three cases, data traffic between the two mobile nodes does not
later in this document). The main advantage of this simple approach traverse the LMA(s), thus providing some form of path optimization
is that the IP address anchor (i.e., the LMA) could be placed closer since the traffic is locally routed at the edge. The main
to the mobile node, and therefore resulting paths are close-to- disadvantage of this approach is that it only tackles the MN-to-MN
optimal. On the other hand, as soon as the mobile node moves, the communication scenario, and only under certain circumstances.
resulting path would start to deviate from the optimal one.
As for host-based IP mobility, there are some extensions defined to
mitigate the sub-optimal routing issues that might arise due to the
use of a centralized anchor. The Local Routing extensions [RFC6705]
enable optimal routing in Proxy Mobile IPv6 in three cases: i) when
two communicating MNs are attached to the same MAG and LMA, ii) when
two communicating MNs are attached to different MAGs but to the same
LMA, and iii) when two communicating MNs are attached to the same MAG
but have different LMAs. In these three cases, data traffic between
the two mobile nodes does not traverse the LMA(s), thus providing
some form of path optimization since the traffic is locally routed at
the edge. The main disadvantage of this approach is that it only
tackles the MN-to-MN communication scenario, and only under certain
circumstances.
An interesting extension that can also be used to facilitate the An interesting extension that can also be used to facilitate the
deployment of network-based mobility protocols in a distributes deployment of network-based mobility protocols in a distributed
mobility management environment is the LMA runtime assignment mobility management environment is the LMA runtime assignment
[RFC6463]. This extension specifies a runtime local mobility anchor [RFC6463]. This extension specifies a runtime local mobility anchor
assignment functionality and corresponding mobility options for Proxy assignment functionality and corresponding mobility options for Proxy
Mobile IPv6. This runtime local mobility anchor assignment takes Mobile IPv6. This runtime local mobility anchor assignment takes
place during the Proxy Binding Update / Proxy Binding Acknowledgment place during the Proxy Binding Update / Proxy Binding Acknowledgment
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 case when the mobile change the assigned LMA of an MN, for example, in cases when the
node does not have any session active, or when running sessions can mobile node does not have any active session, or when the running
survive an IP address change. Note that several possible dynamic sessions can survive an IP address change. Note that several
local mobility anchor discovery solutions can be used, as described possible dynamic local mobility anchor discovery solutions can be
in [RFC6097]. used, as described in [RFC6097].
4.3. 3GPP network flattening approaches 4.3. 3GPP network flattening approaches
The 3rd Generation Partnership Project (3GPP) is the standard 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 LTE (Long Term Evolution). network and the Evolved Packet System (EPS), which mainly comprises
the Evolved Packet Core (EPC) and a new radio access network,
sometimes 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 we will analyze together. We next describe how 3GPP simplicity will be analyzed together. We next describe how 3GPP
mobility protocols and several additional completed or on-going mobility protocols and several additional completed or ongoing
extensions can be deployed to meet some of the DMM requirements extensions can be deployed to meet some of the DMM requirements
[I-D.ietf-dmm-requirements]. [I-D.ietf-dmm-requirements].
+---------------------------------------------------------+ +---------------------------------------------------------+
| PCRF | | PCRF |
+-----------+--------------------------+----------------+-+ +-----------+--------------------------+----------------+-+
| | | | | |
+----+ +-----------+------------+ +--------+-----------+ +-+-+ +----+ +-----------+------------+ +--------+-----------+ +-+-+
| | | +-+ | | Core Network | | | | | | +-+ | | Core Network | | |
| | | +------+ |S|__ | | +--------+ +---+ | | | | | | +------+ |S|__ | | +--------+ +---+ | | |
skipping to change at page 15, line 41 skipping to change at page 14, line 23
| | +------------------------+ | | | | | k | | | +------------------------+ | | | | | k |
| +---+ Trusted non-3GPP AN +-S2a--------------+ | | | s | | +---+ Trusted non-3GPP AN +-S2a--------------+ | | | s |
| | +------------------------+ | | | | | | | | +------------------------+ | | | | | |
| | | +-+-+ | | | | | | +-+-+ | | |
| +--------------------------S2c--------------------| | | | | +--------------------------S2c--------------------| | | |
| | | | | | | | | | | |
+----+ +--------------------+ +---+ +----+ +--------------------+ +---+
Figure 5: EPS (non-roaming) architecture overview Figure 5: EPS (non-roaming) architecture overview
GPRS Tunnelling Protocol (GTP) [3GPP.29.060] [3GPP.29.281] The GPRS Tunnelling Protocol (GTP) [SDO-3GPP.29.060]
[3GPP.29.274] is a network-based mobility protocol specified for 3GPP [SDO-3GPP.29.281] [SDO-3GPP.29.274] is a network-based mobility
networks (S2a, S2b, S5 and S8 interfaces). Similar to PMIPv6, it can protocol specified for 3GPP networks (S2a, S2b, S5 and S8
handle mobility without requiring the involvement of the mobile interfaces). Similar to PMIPv6, it can handle mobility without
nodes. In this case, the mobile node functionality is provided in a requiring the involvement of the mobile nodes. In this case, the
proxy manner by the Serving Data Gateway (SGW), Evolved Packet Data mobile node functionality is provided in a proxy manner by the
Gateway (ePDG), or Trusted Wireless Access Gateway (TWAG). Serving Data Gateway (SGW), Evolved Packet Data Gateway (ePDG), or
Trusted Wireless Access Gateway (TWAG).
3GPP specifications also include client-based mobility support, based 3GPP specifications also include client-based mobility support, based
on adopting the use of Dual-Stack Mobile IPv6 (DSMIPv6) [RFC5555] for on adopting the use of Dual-Stack Mobile IPv6 (DSMIPv6) [RFC5555] for
the S2c interface. In this case, the UE implements the mobile node the S2c interface. In this case, the User Equipment (UE) implements
functionality, while the home agent role is played by the PGW. the mobile node functionality, while the 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 [3GPP.23.401] allows offloading some IP services at enabled network [SDO-3GPP.23.401] allows offloading some IP services
the local access network, above the Radio Access Network (RAN) or at at the local access network, above the Radio Access Network (RAN) or
the macro, without the need to traverse back to the PGW (see at the macro, without the need to traverse 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 |....................................(Operator's CN)
| Equipm. |.................. | Equipm. |..................
+---------+ . Local IP traffic +---------+ . Local IP traffic
. .
+-----------+ +-----------+
|Residential| |Residential|
|enterprise | |enterprise |
|IP network | |IP network |
+-----------+ +-----------+
Figure 6: LIPA scenario Figure 6: LIPA scenario
SIPTO enables an operator to offload certain types of traffic at a SIPTO enables an operator to offload certain types of traffic at a
network node close to the UE's point of attachment to the access network node close to the UE's point of attachment to the access
network, by selecting a set of GWs (SGW and PGW) that is network, by selecting a set of GWs (SGW and PGW) that are
geographically/topologically close to the UE's point of attachment. geographically/topologically close to the UE's point of attachment.
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 Traffic
+-------+ +------+ +------+ +------+ +-------+ +------+ +------+ +------+
Figure 7: SIPTO architecture Figure 7: SIPTO architecture
LIPA, on the other hand, enables an IP capable UE connected via a LIPA, on the other hand, enables an IP capable UE connected via a
Home eNB (HeNB) to access other IP capable entities in the same Home eNB (HeNB) to access other IP capable entities in the same
residential/enterprise IP network without the user plane traversing residential/enterprise IP network without traversing the mobile
the mobile operator's network core. In order to achieve this, a operator's network core in the user plane. In order to achieve this,
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 connection to an access established by the UE requesting a new PDN connection to an access
point name for which LIPA is permitted, and the network selecting the point name for which LIPA is permitted, and the network selecting the
Local GW associated with the HeNB and enabling a direct user plane Local GW associated with the HeNB and enabling a direct user plane
path between the Local GW and the HeNB. path between the Local GW and the HeNB.
+---------------+-------+ +----------+ +-------------+ ===== +---------------+-------+ +----------+ +-------------+ =====
|Residential | |H(e)NB | | Backhaul | |Mobile | ( IP ) |Residential | |H(e)NB | | Backhaul | |Mobile | ( IP )
|Enterprise |..|-------|..| |..|Operator |..(Network) |Enterprise |..|-------|..| |..|Operator |..(Network)
|Network | |L-GW | | | |Core network | ======= |Network | |L-GW | | | |Core network | =======
+---------------+-------+ +----------+ +-------------+ +---------------+-------+ +----------+ +-------------+
/ /
| |
/ /
+-----+ +-----+
| UE | | UE |
+-----+ +-----+
Figure 8: LIPA architecture Figure 8: LIPA architecture
The 3GPP architecture specifications also provide mechanisms to allow The 3GPP architecture specifications also provide mechanisms to allow
discovery and selection of gateways [3GPP.29.303]. These mechanisms discovery and selection of gateways [SDO-3GPP.29.303]. These
enable taking decisions taking into consideration topological mechanisms enable decisions taking into consideration topological
location and gateway collocation aspects, using heavily the DNS as a location and gateway collocation aspects, using heavily the DNS as a
"location database". "location database".
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-10. In Rel-11, there is currently a in 3GPP specifications up to Rel-12. In a glimpse, LIPA mobility
work item on LIPA Mobility and SIPTO at the Local Network (LIMONET) support is limited to handovers between HeNBs that are managed by the
[3GPP.23.859] that is studying how to provide SIPTO and LIPA same L-GW (i.e., mobility within the local domain), while seamless
mechanisms with some additional, but still limited, mobility support. SIPTO mobility is still limited to the case where the SGW/PGW is at
In a glimpse, LIPA mobility support is limited to handovers between or above Radio Access Network (RAN) level.
HeNBs that are managed by the same L-GW (i.e., mobility within the
local domain), while seamless SIPTO mobility is still limited to the
case where the SGW/PGW is at or above Radio Access Network (RAN)
level.
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 current practices, described in Section 4, with respect to the DMM
expected DMM requirements listed in [I-D.ietf-dmm-requirements]. requirements listed in [I-D.ietf-dmm-requirements].
5.1. Distributed processing - REQ1 5.1. Distributed processing - REQ1
According to requirement #1 stated in [I-D.ietf-dmm-requirements], IP According to requirement #1 stated in [I-D.ietf-dmm-requirements], IP
mobility, network access and routing solutions provided by DMM MUST mobility, network access and routing solutions provided by DMM MUST
enable distributed processing for mobility management so that traffic enable distributed processing for mobility management so that traffic
does not need to traverse centrally deployed mobility anchors and can avoid traversing single mobility anchor far from the optimal
thereby avoid non-optimal routes. 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 processing" usually relying on the the requirement "REQ#1 Distributed processing" usually relying on the
following functions: 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 make this feature "DMM-friendly", some anchors might need to be to make this feature "DMM-friendly", some anchors might need to be
placed closer to the mobile node. placed closer to the mobile node.
o Dynamic anchor assignment/re-location: ability to i) optimally o Dynamic anchor assignment/re-location: ability to i) optimally
assign initial anchor, and ii) dynamically change the initially assign initial anchor, and ii) dynamically change the initially
assigned anchor and/or assign a new one (this may also require to assigned anchor and/or assign a new one (this may also require to
transfer mobility context between anchors). This can be achieved transfer mobility context between anchors). This can be achieved
either by changing anchor for all ongoing sessions, or by either by changing anchor for all ongoing sessions, or by
assigning new anchors just for new sessions. assigning new anchors just for new sessions.
Both the main client- and network-based IP mobility protocols, namely Both the main client- and network-based IP mobility protocols, namely
(DS)MIPv6 and PMIPv6 allows to deploy multiple anchors (i.e., home (DS)MIPv6 and PMIPv6 allow deploying multiple anchors (i.e., home
agents and localized mobility anchors), therefore providing the agents and localized mobility anchors), therefore providing the
multiple anchoring function. However, existing solutions do only multiple anchoring function. However, existing solutions only
provide an optimal initial anchor assignment, a gap being the lack of provide an optimal initial anchor assignment, thus the lack of
dynamic anchor change/new anchor assignment. Neither the HA switch dynamic anchor change/new anchor assignment is a gap. Neither the HA
nor the LMA runtime assignment allow changing the anchor during an switch nor the LMA runtime assignment allow changing the anchor
ongoing session. This actually comprises several gaps: ability to during an ongoing session. This actually comprises several gaps:
perform anchor assignment at any time (not only at the initial MN's ability to perform anchor assignment at any time (not only at the
attachment), ability of the current anchor to initiate/trigger the initial MN's attachment), ability of the current anchor to initiate/
relocation, and ability of transferring registration context between trigger the relocation, and ability to transfer registration context
anchors. between anchors.
Dynamic anchor assignment may lead the MN to manage different Dynamic anchor assignment may lead the MN to manage different
mobility sessions served by different mobility anchors. This is not mobility sessions served by different mobility anchors. This is not
an issue with client based mobility management where the mobility an issue with client based mobility management where the mobility
client natively knows each anchor associated to each mobility client natively knows each anchor associated to each mobility
sessions. However, it may raise issues with network based mobility sessions. However, there is one gap, as the MN should be capable of
management. In this case, the mobile client, located in the network handling IP addresses in a DMM-friendly way, meaning that the MN can
(e.g., MAG), usually retrieves the MN's anchor from the MN's policy perform smart source address selection (i.e., deprecating IP
profile (e.g., Section 6.2 of [RFC5213]). Currently, the MN's policy addresses from previous mobility anchors, so they are not used for
profile implicitly assumes a single serving anchor and, thus, does new sessions). Besides, managing different mobility sessions served
not maintain the association between home network prefix and anchor. by different mobility anchors may raise issues with network based
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
policy profile (e.g., Section 6.2 of [RFC5213]). Currently, the MN's
policy profile implicitly assumes a single serving anchor and, thus,
does not maintain the association between home network prefix and
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, so leading 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 the IETF that Currently, there is no efficient mechanism specified by IETF to allow
allows to dynamically discover the presence of nodes that can play dynamically discovering the presence of nodes that can play the
the role of anchor, discover their capabilities and allow the anchor role, discovering their capabilities and selecting the most
selection of the most suitable one. Note that there are 3GPP suitable one. There is also no mechanism to allow selecting a node
mechanisms providing this functionality defined in [3GPP.29.303]. that is currently anchoring a given home address/prefix (capability
sometimes required to meet REQ#2). There are though some mechanisms
that could help discovering anchors, such as the Dynamic Home Agent
Address Discovery (DHAAD), the use of the Home Agent (H) flag in
Router Advertisements (which indicates that the router sending the
Router Advertisement is also functioning as a Mobile IPv6 home agent
on the link) or the MAP option in Router Advertisements defined by
HMIPv6. Note that there are 3GPP mechanisms providing that
functionality defined in [SDO-3GPP.29.303].
5.2. Transparency to Upper Layers - REQ2 Also note that REQ1 is such that the data plane traffic can avoid
suboptimal route. Distributed processing of the traffic is then
needed only in the data plane. The needed capability in distributed
processing therefore should not contradict with centralized control
plane. Other control plane solutions such as charging, lawful
interception, etc. should not be limited. Yet combining the control
plane and data plane routing management (RM) function may limit the
choice to distributing boht data plane and control plane together.
In order to enable distributing only the data plane without
distributing the control plane, a gap is to split the routing
management function into the control plane (RM-CP) and data plane
(RM-DP).
The need for "transparency to upper layer", introduced in 5.2. Bypassable network-layer mobility support - REQ2
[I-D.ietf-dmm-requirements], requires dynamic mobility management,
which basically leverages the two following functions: The need for "bypassable network-layer mobility support" introduced
in [I-D.ietf-dmm-requirements] will enable dynamic mobility
management. Note that this requirement is not on dynamic mobilitly
itself but only enables it. It therefore leaves flexibility on the
determination of whether network-layer mobility support is needed and
the role to use of not use network-layer mobility support. The
requirement only enables one to use or not use network-layer mobility
support. It only enables the which basically leverages the two
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 require IP continuity support. The MN may only to sessions which uses the network-layer mobility support.
thus manage more than one session; some of them may be associated The MN may thus manage more than one session; some of them may be
with anchored IP address(es), while the others may be associated associated with anchored IP address(es), while the others may be
with local IP address(es). associated with local IP address(es).
o Multiple IP address management: this function is ensued from 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
(from an anchoring point of view) to use on a per-session/ (from an anchoring point of view) to use on a per-session/
application/service basis. application/service basis.
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 need it and while address continuity is guaranteed for sessions that uses such mobility
needed (in some scenarios, the provision of mobility locally within a support (e.g., in some scenarios, the provision of mobility locally
limited area might be enough from the mobile node or the application within a limited area might be enough from the mobile node or the
point of view) at the relocated anchor. This for example implies application point of view) at the relocated anchor. Implicitly, when
having the knowledge of which sessions are active at the mobile node, no applications are using the network-layer mobility support, DMM may
which is something typically known only by the MN e.g., by its releave the needed resources. This may imply having the knowledge of
connection manager). Therefore, (part of) this knowledge might need which sessions at the mobile node are active and are using the
to be transferred to/shared with the network. mobility support. This is something typically known only by the MN
(e.g., by its connection manager). Therefore, (part of) this
knowledge might need to be transferred to/shared with the network.
Multiple IP address management requires the MN to pick-up the correct Multiple IP address management provides the MN with the choice to
address (with mobility support or not) depending on the application pick-up the correct address (provided with mobility support or not)
requirements. When using client based mobility management, the depending on the application requirements. When using client based
mobile node is natively aware about the anchoring capabilities of its mobility management, the mobile node is natively aware about the
assigned IP addresses. This is not the case with network based IP anchoring capabilities of its assigned IP addresses. This is not the
mobility management and current mechanisms does not allow the MN to case with network based IP mobility management and current mechanisms
be aware of the IP addresses properties (i.e. the MN does not know does not allow the MN to be aware of the IP addresses properties
whether the allocated IP addresses are anchored). However, there are (i.e., the MN does not know whether the allocated IP addresses are
ongoing IETF works that are proposing that the network could indicate anchored). However, there are ongoing IETF works that are proposing
the different IP addresses properties during assignment procedures that the network could indicate the different IP addresses properties
during assignment procedures, such as
[I-D.bhandari-dhc-class-based-prefix], [I-D.bhandari-dhc-class-based-prefix],
[I-D.korhonen-6man-prefix-properties]. [I-D.korhonen-6man-prefix-properties] and [I-D.anipko-mif-mpvd-arch].
However, although there exist these individual efforts that could be
be considered as attempts to fix the gap, there is no solution close
to be adopted and standardized in IETF.
5.3. IPv6 deployment - REQ3 5.3. IPv6 deployment - REQ3
This requirement states that DMM solutions SHOULD primariliy 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 SHOULD NOT be tailored specifically to considered mandatory and solutions SHOULD NOT be tailored
support IPv4, in particular in situations where private IPv4 specifically to support IPv4, in particular in situations where
addresses and/or NATs are used. private IPv4 addresses and/or NATs are used.
All analyzed DMM practices support IPv6. Some of them, such as All analyzed DMM practices support IPv6. Some of them, such as MIPv6
MIPv6/NEMO (including the support of dynamic HA selection), MOBIKE, /NEMO (including the support of dynamic HA selection), MOBIKE, SIPTO
SIPTO have also IPv4 support. Additionally, there are also some have also IPv4 support. Additionally, there are also some solutions
solutions that have some limited IPv4 support (e.g., PMIPv6). In that have some limited IPv4 support (e.g., PMIPv6). In conclusion,
conclusion, this requirement is met by existing DMM practices. this requirement is met by existing DMM practices.
5.4. Existing mobility protocols - REQ4 5.4. Existing mobility protocols - REQ4
A DMM solution SHOULD 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 [I-D.ietf-dmm-requirements], a DMM solution could reuse
existing IETF and standardized protocols before specifying new existing IETF and standardized protocols before specifying new
protocols. Besides, Section 4 of this document discusses various protocols. Besides, Section 4 of this document discusses various
ways to flatten and distribute current mobility solutions. Actually, ways to flatten and distribute current mobility solutions. Actually,
nothing prevent the distribution of mobility functions with vanilla nothing prevent the distribution of mobility functions with vanilla
IP mobility protocols. However, as discussed in Section 5.1 and IP mobility protocols. However, as discussed in Section 5.1 and
Section 5.2, limitations exist. The 3GPP data plane anchoring Section 5.2, limitations exist. The 3GPP data plane anchoring
function, i.e., the PGW, can be also be distributed, but with function, i.e., the PGW, can be also be distributed, but with
limitations; e.g., no anchoring relocation, no context transfer limitations; e.g., no anchoring relocation, no context transfer
between anchors, centralized control plane . The 3GPP architecture between anchors, centralized control plane. The 3GPP architecture is
is also going into the direction of flattening with SIPTO and LIPA also going into the direction of flattening with SIPTO and LIPA,
where IP anchoring function, however these solutions are supposed to though they do not provide mobility support.
be deployed do and, thus, do not provide mobility support. In
conclusion this requirement can be met, DMM can reuse existing
mobility solutions, however some limitations exist.
5.5. Co-existence - REQ5 5.5. Co-existence - REQ5
According to [I-D.ietf-dmm-requirements], DMM solution should be able According to [I-D.ietf-dmm-requirements], DMM solution MUST be able
to co-exist with existing network deployments and end hosts. All of to co-exist with existing network deployments, end hosts and routers.
current mobility protocols can co-exist with existing network
All current mobility protocols can co-exist with existing network
deployments and end hosts. There is no gap between existing mobility deployments and end hosts. There is no gap between existing mobility
protocols and this requirement. protocols and this requirement.
5.6. Security considerations - REQ6 5.6. Security considerations - REQ6
As stated in [I-D.ietf-dmm-requirements], a DMM solution MUST NOT As stated in [I-D.ietf-dmm-requirements], a DMM solution MUST NOT NOT
introduce new security risks or amplify existing security risks introduce new security risks, or amplify existing security risks,
against which the existing security mechanisms/protocols cannot offer that cannot be mitigated by existing security mechanisms or
sufficient protection. Current mobility protocols all have security protocols. Current mobility protocols have all security mechanisms
mechanisms. For example, Mobile IPv6 defines security features to in place. For example, Mobile IPv6 defines security features to
protect binding updates both to home agents and correspondent nodes. protect binding updates both to home agents and correspondent nodes.
It also defines mechanisms to protect the data packets transmission It also defines mechanisms to protect the data packets transmission
for Mobile IPv6 users. Proxy Mobile IPv6 and other variation of for Mobile IPv6 users. Proxy Mobile IPv6 and other variation of
mobile IP also have similar security considerations. mobile IP also have similar security considerations.
5.7. Multicast - REQ7 5.7. Multicast - REQ7
It is stated in [I-D.ietf-dmm-requirements] that DMM solutions SHOULD It is stated in [I-D.ietf-dmm-requirements] that DMM solutions SHOULD
consider multicast traffic delivery so that network inefficiency enable multicast solutions to be developed to avoid network
issues, such as duplicate multicast subscriptions towards the inefficiency in multicast traffic delivery.
downstream tunnel entities, can be avoided.
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 MN, tunneling multicast traffic down to the access router, or to the
introduce the so-called "tunnel convergence problem". This means mobile node, introduce the so-called "tunnel convergence problem".
that multiple instances of the same multicast traffic can converge to This means that multiple instances of the same multicast traffic can
the same node, defeating hence the advantage of using multicast converge to the same node, defeating hence the advantage of using
protocols. multicast protocols.
The MULTIMOB WG in IETF has studied the issue, for the specific case The MULTIMOB WG in IETF has studied this issue, for the specific case
of PMIPv6, and has produced a baseline solution [RFC6224] as well as of PMIPv6, and has produced a baseline solution [RFC6224] as well as
a routing optimization solution [RFC7028] to address the problem. a routing optimization solution [RFC7028] to address the problem.
The baseline solution suggests deploying an MLD proxy function at the The baseline solution suggests deploying an MLD proxy function at the
MAG, and either a multicast router or another MLD proxy function at MAG, and either a multicast router or another MLD proxy function at
the LMA. The routing optimization solution describes an architecture the LMA. The routing optimization solution describes an architecture
where a dedicated multicast tree mobility anchor (MTMA) or a direct where a dedicated multicast tree mobility anchor (MTMA) or a direct
routing 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, there are no Besides the solutions proposed in MULTIMOB for PMIPv6, there are no
solutions for other mobility protocols to address the multicast solutions for other mobility protocols to address the multicast
tunnel convergence problem. tunnel convergence problem.
5.8. Summary 5.8. 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 do only provide an optimal initial anchor o Existing solutions do 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.
While MOBIKE could be used to switch from a gateway to another in
the middle of a session from MN side, there is no protocol support
for the network side.
o The mobile node needs to simultaneously use multiple IP addresses, o The mobile node needs to simultaneously use multiple IP addresses,
which requires additional support which might not be available on which requires additional support which might not be available on
the mobile node's stack, especially for the case of network-based the mobile node's stack, especially for the case of network-based
solutions. solutions.
o Currently, there is no efficient mechanism specified by the IETF o Currently, there is no efficient mechanism specified by the IETF
that allows to dynamically discover the presence of nodes that can that allows to dynamically discover the presence of nodes that can
play the role of anchor, discover their capabilities and allow the play the role of anchor, discover their capabilities and allow the
selection of the most suitable one. selection of the most suitable one. There are though some
mechanisms that could help discovering anchors, such as the
Dynamic Home Agent Address Discovery (DHAAD), the use of the Home
Agent (H) flag in Router Advertisements (which indicates that the
router sending the Router Advertisement is also functioning as a
Mobile IPv6 home agent on the link) or the MAP option in Router
Advertisements defined by HMIPv6.
o While existing network-based DMM practices may allow to deploy o While existing network-based DMM practices may allow to deploy
multiple LMAs and dynamically select the best one, this requires multiple LMAs and dynamically select the best one, this requires
to still keep some centralization in the control plane, to access to still keep some centralization in the control plane, to access
on the policy store (as defined in RFC5213). on the policy store (as defined in RFC5213). Currently, there is
a lack of solutions/extensions that support a clear control and
The following table summarizes the previous analysis, indicating the data plane separation for IETF IP mobility protocols.
gaps existing DMM solutions have when compared to the requirements
listed in [I-D.ietf-dmm-requirements].
+------------+------+------+------+------+------+------+------+
| | REQ1 | REQ2 | REQ3 | REQ4 | REQ5 | REQ6 | REQ7 |
+------------+------+------+------+------+------+------+------+
| MIPv6/NEMO | X | X | | | | | X |
| MIPv6 RO | X | | | | | | X |
| HMIPv6 | X | | | | | | X |
| HA sel | X | X | | | | | X |
| MOBIKE | X | X | | | | | X |
| PMIPv6 | X | X | | | | | * |
| LMA sel | X | X | | | | | X |
| LIPA | X | X | | | | | X |
| SIPTO | X | X | | | | | X |
| LIMONET | X | X | | | | | X |
+------------+------+------+------+------+------+------+------+
* MULTIMOB optimizations for PMIPv6 can be used to handle multicast
traffic.
6. Security Considerations 6. Security Considerations
This document does not define any protocol, there is no security This document does not define any protocol, so it does not introduce
considerations. any new security concern.
7. IANA Considerations 7. IANA Considerations
None. None.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References 8.2. Informative References
[3GPP.23.401] [I-D.anipko-mif-mpvd-arch]
3GPP, "General Packet Radio Service (GPRS) enhancements Anipko, D., "Multiple Provisioning Domain Architecture",
for Evolved Universal Terrestrial Radio Access Network draft-anipko-mif-mpvd-arch-05 (work in progress), November
(E-UTRAN) access", 3GPP TS 23.401 10.10.0, March 2013. 2013.
[3GPP.23.859]
3GPP, "Local IP access (LIPA) mobility and Selected IP
Traffic Offload (SIPTO) at the local network", 3GPP
TR 23.859 12.0.1, April 2013.
[3GPP.29.060]
3GPP, "General Packet Radio Service (GPRS); GPRS
Tunnelling Protocol (GTP) across the Gn and Gp interface",
3GPP TS 29.060 3.19.0, March 2004.
[3GPP.29.274]
3GPP, "3GPP Evolved Packet System (EPS); Evolved General
Packet Radio Service (GPRS) Tunnelling Protocol for
Control plane (GTPv2-C); Stage 3", 3GPP TS 29.274 10.11.0,
June 2013.
[3GPP.29.281]
3GPP, "General Packet Radio System (GPRS) Tunnelling
Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0,
September 2011.
[3GPP.29.303]
3GPP, "Domain Name System Procedures; Stage 3", 3GPP
TS 29.303 10.4.0, September 2012.
[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
(work in progress), July 2013. (work in progress), July 2013.
[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", Architectures", draft-gundavelli-v6ops-community-wifi-
draft-gundavelli-v6ops-community-wifi-svcs-06 (work in svcs-06 (work in progress), April 2013.
progress), April 2013.
[I-D.ietf-dmm-requirements] [I-D.ietf-dmm-requirements]
Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen, Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen,
"Requirements for Distributed Mobility Management", "Requirements for Distributed Mobility Management", draft-
draft-ietf-dmm-requirements-09 (work in progress), ietf-dmm-requirements-12 (work in progress), December
September 2013. 2013.
[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", Liu, "IPv6 Prefix Properties", draft-korhonen-6man-prefix-
draft-korhonen-6man-prefix-properties-02 (work in properties-02 (work in progress), July 2013.
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, <http:// Systems", IEEE Standard 802.16, 2009, <http://
standards.ieee.org/getieee802/download/802.16-2009.pdf>. standards.ieee.org/getieee802/download/802.16-2009.pdf>.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol", Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005. RFC 3963, January 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.
[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, bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, September
September 2006. 2006.
[RFC4889] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network
Mobility Route Optimization Solution Space Analysis", RFC
4889, July 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,
skipping to change at page 25, line 12 skipping to change at page 23, line 41
Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
Management", RFC 5380, October 2008. Management", RFC 5380, October 2008.
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", RFC 5555, June 2009. Routers", RFC 5555, June 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)", "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
RFC 5996, September 2010. 5996, September 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, (LMA) Discovery for Proxy Mobile IPv6", RFC 6097, February
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.
[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.
[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, Bootstrapping for the Integrated Scenario", RFC 6611, May
May 2012. 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", Dutta, "Localized Routing for Proxy Mobile IPv6", RFC
RFC 6705, September 2012. 6705, 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]
3GPP, "General Packet Radio Service (GPRS) enhancements
for Evolved Universal Terrestrial Radio Access Network
(E-UTRAN) access", 3GPP TS 23.401 10.10.0, March 2013.
[SDO-3GPP.23.859]
3GPP, "Local IP access (LIPA) mobility and Selected IP
Traffic Offload (SIPTO) at the local network", 3GPP TR
23.859 12.0.1, April 2013.
[SDO-3GPP.29.060]
3GPP, "General Packet Radio Service (GPRS); GPRS
Tunnelling Protocol (GTP) across the Gn and Gp interface",
3GPP TS 29.060 3.19.0, March 2004.
[SDO-3GPP.29.274]
3GPP, "3GPP Evolved Packet System (EPS); Evolved General
Packet Radio Service (GPRS) Tunnelling Protocol for
Control plane (GTPv2-C); Stage 3", 3GPP TS 29.274 10.11.0,
June 2013.
[SDO-3GPP.29.281]
3GPP, "General Packet Radio System (GPRS) Tunnelling
Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0,
September 2011.
[SDO-3GPP.29.303]
3GPP, "Domain Name System Procedures; Stage 3", 3GPP TS
29.303 10.4.0, September 2012.
Authors' Addresses Authors' Addresses
Dapeng Liu (editor) Dapeng Liu (editor)
China Mobile China Mobile
Unit2, 28 Xuanwumenxi Ave, Xuanwu District Unit2, 28 Xuanwumenxi Ave, Xuanwu District
Beijing 100053 Beijing 100053
China China
Email: liudapeng@chinamobile.com Email: liudapeng@chinamobile.com
Juan Carlos Zuniga (editor) Juan Carlos Zuniga (editor)
InterDigital Communications, LLC InterDigital Communications, LLC
1000 Sherbrooke Street West, 10th floor 1000 Sherbrooke Street West, 10th floor
Montreal, Quebec H3A 3G4 Montreal, Quebec H3A 3G4
Canada Canada
Email: JuanCarlos.Zuniga@InterDigital.com Email: JuanCarlos.Zuniga@InterDigital.com
URI: http://www.InterDigital.com/ URI: http://www.InterDigital.com/
Pierrick Seite Pierrick Seite
 End of changes. 108 change blocks. 
533 lines changed or deleted 561 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/