draft-ietf-dmm-best-practices-gap-analysis-07.txt   draft-ietf-dmm-best-practices-gap-analysis-08.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: March 14, 2015 InterDigital Expires: April 2, 2015 InterDigital
P. Seite P. Seite
Orange Orange
H. Chan H. Chan
Huawei Technologies Huawei Technologies
CJ. Bernardos CJ. Bernardos
UC3M UC3M
September 10, 2014 September 29, 2014
Distributed Mobility Management: Current practices and gap analysis Distributed Mobility Management: Current practices and gap analysis
draft-ietf-dmm-best-practices-gap-analysis-07 draft-ietf-dmm-best-practices-gap-analysis-08
Abstract Abstract
This document analyzes deployment practices of existing IP mobility This document analyzes deployment practices of existing IP mobility
protocols in a distributed mobility management environment. It then protocols in a distributed mobility management environment. It then
identifies existing limitations when compared to the requirements identifies existing limitations when compared to the requirements
defined for a distributed mobility management solution. defined for a distributed mobility management solution.
Status of This Memo Status of This Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 March 14, 2015. This Internet-Draft will expire on April 2, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Functions of existing mobility protocols . . . . . . . . . . 3 3. Functions of existing mobility protocols . . . . . . . . . . 3
4. DMM practices . . . . . . . . . . . . . . . . . . . . . . . . 5 4. DMM practices . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. IP flat wireless network . . . . . . . . . . . . . . . . 6 4.2. IP flat wireless network . . . . . . . . . . . . . . . . 6
4.2.1. Host-based IP DMM practices . . . . . . . . . . . . . 7 4.2.1. Host-based IP DMM practices . . . . . . . . . . . . . 7
4.2.2. Network-based IP DMM practices . . . . . . . . . . . 12 4.2.2. Network-based IP DMM practices . . . . . . . . . . . 11
4.3. Flattening 3GPP mobile network approaches . . . . . . . . 14 4.3. Flattening 3GPP mobile network approaches . . . . . . . . 13
5. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Distributed mobility management - REQ1 . . . . . . . . . 17 5.1. Distributed mobility management - REQ1 . . . . . . . . . 16
5.2. Bypassable network-layer mobility support for each 5.2. Bypassable network-layer mobility support for each
application session - REQ2 . . . . . . . . . . . . . . . 19 application session - REQ2 . . . . . . . . . . . . . . . 19
5.3. IPv6 deployment - REQ3 . . . . . . . . . . . . . . . . . 21 5.3. IPv6 deployment - REQ3 . . . . . . . . . . . . . . . . . 20
5.4. Existing mobility protocols - REQ4 . . . . . . . . . . . 21 5.4. Considering existing mobility protocols - REQ4 . . . . . 20
5.5. Coexistence with deployed networks/hosts and operability 5.5. Coexistence with deployed networks/hosts and
across different networks- REQ5 . . . . . . . . . . . . . 21 operability across different networks - REQ5 . . . . . . 21
5.6. Operation and management considerations - REQ6 . . . . . 22 5.6. Operation and management considerations - REQ6 . . . . . 21
5.7. Security considerations - REQ7 . . . . . . . . . . . . . 23 5.7. Security considerations - REQ7 . . . . . . . . . . . . . 22
5.8. Multicast - REQ8 . . . . . . . . . . . . . . . . . . . . 23 5.8. Multicast - REQ8 . . . . . . . . . . . . . . . . . . . . 22
5.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.1. Normative References . . . . . . . . . . . . . . . . . . 26
9.1. Normative References . . . . . . . . . . . . . . . . . . 25 8.2. Informative References . . . . . . . . . . . . . . . . . 26
9.2. Informative References . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
The centralized deployment of mobility anchors to manage IP sessions Existing network-layer mobility management protocols have primarily
pose several problems. In order to address these problems, a employed a mobility anchor to ensure connectivity of a mobile node by
distributed mobility management (DMM) architecture has been proposed. forwarding packets destined to, or sent from, the mobile node after
This document investigates whether it is feasible to deploy current the node has moved to a different network. The mobility anchor has
IP mobility protocols in a DMM scenario in a way that can fulfill the been centrally deployed in the sense that the traffic of millions of
requirements as defined in [RFC7333]. It discusses current mobile nodes in an operator network is typically managed by the same
deployment practices of existing mobility protocols and identifies anchor. This centralized deployment of mobility anchors to manage IP
the limitations (gaps) in these practices from the standpoint of sessions poses several problems. In order to address these problems,
satisfying DMM requirements. a distributed mobility management (DMM) architecture has been
proposed. This document investigates whether it is feasible to
deploy current IP mobility protocols in a DMM scenario in a way that
can fulfill the requirements as defined in [RFC7333]. It discusses
current deployment practices of existing mobility protocols and
identifies the limitations (gaps) in these practices from the
standpoint of satisfying DMM requirements. The analysis is primarily
towards IPv6 deployment, but can be seen to also apply to IPv4
whenever there are IPv4 counterparts equivalent to the IPv6 mobility
protocols.
The rest of this document is organized as follows. Section 3 The rest of this document is organized as follows. Section 3
analyzes existing IP mobility protocols by examining their functions analyzes existing IP mobility protocols by examining their functions
and how these functions can be configured and used to work in a DMM and how these functions can be configured and used to work in a DMM
environment. Section 4 presents the current practices of IP wireless environment. Section 4 presents the current practices of IP wireless
networks and 3GPP architectures. Both network- and host-based networks and 3GPP architectures. Both network- and host-based
mobility protocols are considered. Section 5 presents the gap mobility protocols are considered. Section 5 presents the gap
analysis with respect to the current practices. analysis with respect to the current practices.
2. Terminology 2. Terminology
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], in the Proxy mobile IPv6 specification specification [RFC6275], in the Proxy Mobile IPv6 specification
[RFC5213], and in the Distributed Management Requirements [RFC7333]. [RFC5213], and in the Distributed Mobility Management Requirements
These terms include mobile node (MN), correspondent node (CN), home [RFC7333]. These terms include mobile node (MN), correspondent node
agent (HA), local mobility anchor (LMA), mobile access gateway (MAG), (CN), home agent (HA), Local Mobility Anchor (LMA), Mobile Access
centrally depoyed mobility anchors, distributed mobility management, Gateway (MAG), centrally depoyed mobility anchors, distributed
hierarchical mobile network, flatter mobile network, and flattening mobility management, hierarchical mobile network, flatter mobile
mobile network. network, and flattening mobile network.
In addition, this document also introduces some definitions of IP In addition, this document also introduces some definitions of IP
mobility functions in Section 3. mobility functions in Section 3.
In this document there are also references to a "distributed mobility In this document there are also references to a "distributed mobility
management environment". By this term, we refer to a scenario in management environment." By this term, we refer to a scenario in
which the IP mobility, access network and routing solutions allow for which the IP mobility, access network and routing solutions allow for
setting up IP networks so that traffic is distributed in an optimal setting up IP networks so that traffic is distributed in an optimal
way, without the reliance on centrally deployed mobility anchors to way, without relying on centrally deployed mobility anchors to manage
manage IP mobility sessions. IP mobility sessions.
3. Functions of existing mobility protocols 3. Functions of existing mobility protocols
The host-based Mobile IPv6 (MIPv6) [RFC6275] and its network-based The host-based Mobile IPv6 (MIPv6) [RFC6275] and its network-based
extension, Proxy Mobile IPv6 (PMIPv6) [RFC5213], even Hierarchical extension, Proxy Mobile IPv6 (PMIPv6) [RFC5213], as well as
Mobile IPv6 (HMIPv6) [RFC5380] are logically centralized mobility Hierarchical Mobile IPv6 (HMIPv6) [RFC5380] are logically centralized
management approaches addressing primarily hierarchical mobile mobility management approaches addressing primarily hierarchical
networks. Although these two are centralized approaches, they have mobile networks. Although these approaches are centralized, they
important mobility management functions resulting from years of have important mobility management functions resulting from years of
extensive work to develop and to extend these functions. It is extensive work to develop and to extend these functions. It is
therefore useful to take these existing functions and examine them in therefore useful to take these existing functions and examine them in
a DMM scenario in order to understand how to deploy the existing a DMM scenario in order to understand how to deploy the existing
mobility protocols to provide distributed mobility management. mobility protocols to provide distributed mobility management.
The main mobility management functions of MIPv6, PMIPv6, and HMIPv6 The main mobility management functions of MIPv6, PMIPv6, and HMIPv6
are the following: are the following:
1. Anchoring function (AF): allocation to a mobile node of an IP 1. Anchoring Function (AF): allocation to a mobile node of an IP
address (a Home Address, HoA) or prefix (a Home Network Prefix, address, i.e., Home Address (HoA), or prefix, i.e., Home Network
HNP) topologically anchored by the advertising node (i.e., the Prefix (HNP) topologically anchored by the advertising node.
anchor node is able to advertise a connected route into the That is, the anchor node is able to advertise a connected route
routing infrastructure for the allocated IP prefixes). It is a into the routing infrastructure for the allocated IP prefixes.
control plane function. This function is a control plane function.
2. Internetwork Location Information (LI) function: managing and 2. Internetwork Location Information (LI) function: managing and
keeping track of the internetwork location of an MN. The keeping track of the internetwork location of an MN. The
location information may be a binding of the IP advertised location information may be a binding of the IP advertised
address/prefix (e.g., HoA or HNP) to the IP routing address of address/prefix, e.g., HoA or HNP, to the IP routing address of
the MN or of a node that can forward packets destined to the MN. the MN or of a node that can forward packets destined to the MN.
It is a control plane function. It is a control plane function.
In a client-server protocol model, location query and update In a client-server protocol model, location query and update
messages may be exchanged between a location information client messages may be exchanged between a location information client
(LIc) and a location information server (LIs). (LIc) and a location information server (LIs).
3. Forwarding Management (FM) function: packet interception and 3. Forwarding Management (FM) function: packet interception and
forwarding to/from the IP address/prefix assigned to the MN, forwarding to/from the IP address/prefix assigned 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.
FM may optionally be split into the control plane (FM-CP) and FM may optionally be split into the control plane (FM-CP) and
data plane (FM-DP). data plane (FM-DP).
In Mobile IPv6, the home agent (HA) typically provides the anchoring In Mobile IPv6, the home agent (HA) typically provides the anchoring
function (AF); the location information server (LIs) is at the HA function (AF); the location information server (LIs) is at the HA
while the location information client (LIc) is at the MN; the whereas the location information client (LIc) is at the MN; the
forwarding management (FM)function is both ends of tunneling at the Forwarding Management (FM) function resides in both ends of the
HA and the MN. tunnel at the HA and the MN.
In Proxy Mobile IPv6, the Local Mobility Anchor (LMA) provides the In Proxy Mobile IPv6, the Local Mobility Anchor (LMA) provides the
anchoring function (AF); the location information server (LIs) is at anchoring function (AF); the location information server (LIs) is at
the LMA while the location information client (LIc) is at the mobile the LMA whereas the location information client (LIc) is at the
access gateway (MAG); the forwarding management (FM) function is both mobile access gateway (MAG); the Forwarding Management (FM) function
ends of tunneling at the HA and the MAG. resides in both ends of the tunnel at the HA and the MAG.
In Hierarchical Mobile IPv6 (HMIPv6) [RFC5380], the mobility anchor In Hierarchical Mobile IPv6 (HMIPv6) [RFC5380], the Mobility Anchor
point (MAP) serves as a location information aggregator between the Point (MAP) serves as a location information aggregator between the
LIs at the HA and the LIc at the MN. The MAP also has FM function to LIs at the HA and the LIc at the MN. The MAP also provides the FM
enable tunneling between HA and itself as well as tunneling between function to enable tunneling between HA and itself as well as
MN and itself. tunneling between MN and itself.
4. DMM practices 4. DMM practices
This section documents deployment practices of existing mobility This section documents deployment practices of existing mobility
protocols to satisfy distributed mobility management requirements. protocols to satisfy distributed mobility management requirements.
This description considers both IP wireless (e.g., evolved Wi-Fi This description considers both IP wireless, e.g., evolved Wi-Fi
hotspots) and 3GPP flattening mobile network. hotspots, and 3GPP flattening mobile network.
While describing the current DMM practices, references to the generic While describing the current DMM practices, the section provides
mobility management functions described in Section 3 are provided, as references to the generic mobility management functions described in
well as some initial hints on the identified gaps with respect to the Section 3 as well as some initial hints on the identified gaps with
DMM requirements documented in [RFC7333]. respect to the DMM requirements documented in [RFC7333].
4.1. Assumptions 4.1. Assumptions
There are many different approaches that can be considered to There are many different approaches that can be considered to
implement and deploy a distributed anchoring and mobility solution. implement and deploy a distributed anchoring and mobility solution.
The focus of the gap analysis is on certain current mobile network The focus of the gap analysis is on certain current mobile network
architectures and standardized IP mobility solutions, considering any architectures and standardized IP mobility solutions, considering any
kind of deployment options which do not violate the original protocol kind of deployment options which do not violate the original protocol
specifications. In order to limit the scope of our analysis of DMM specifications. In order to limit the scope of our analysis of DMM
practices, we consider the following list of technical assumptions: practices, we consider the following list of technical assumptions:
skipping to change at page 6, line 40 skipping to change at page 6, line 40
/ \ |Wi-Fi| |Wi-Fi| |Wi-Fi| |Wi-Fi| / \ |Wi-Fi| |Wi-Fi| |Wi-Fi| |Wi-Fi|
MN1 MN2 | AP1 | | AP2 | | AP3 | | AP4 | MN1 MN2 | AP1 | | AP2 | | AP3 | | AP4 |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
. . . .
/ \ / \ / \ / \
/ \ / \ / \ / \
MN3 MN4 MN5 MN6 MN3 MN4 MN5 MN6
Figure 1: IP Wi-Fi network architectures Figure 1: IP Wi-Fi network architectures
In the figure, three typical deployment options are shown In Figure 1, 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 MN1 and MN2 directly connect to a the figure, mobile nodes MN1 and MN2 directly connect to a
Residential Gateway (RG) which is a network device at the customer Residential Gateway (RG) at the customer premises. The RG hosts the
premises and provides both wireless layer-2 access connectivity 802.11 Access Point (AP) function to enable wireless layer-2 access
(i.e., it hosts the 802.11 Access Point function) and layer-3 routing connectivity and also provides layer-3 routing functions. In the
functions. In the middle of the figure, mobile nodes MN3 and MN4 middle of the figure, mobile nodes MN3 and MN4 connect to Wi-Fi
connect to Wi-Fi Access Points (APs) AP1 and AP2 that are managed by Access Points (APs) AP1 and AP2 that are managed by a Wireless LAN
a WLAN Controller (WLC), which performs radio resource management on Controller (WLC), which performs radio resource management on the
the APs, domain-wide mobility policy enforcement and centralized APs, domain-wide mobility policy enforcement and centralized
forwarding function for the user traffic. The WLC could also forwarding function for the user traffic. The WLC could also
implement layer-3 routing functions, or attach to an access router implement layer-3 routing functions, or attach to an access router
(AR). Last, on the right-hand side of the figure, access points AP3 (AR). Last, on the right-hand side of the figure, access points AP3
and AP4 are directly connected to an access router. This can also be and AP4 are directly connected to an access router. This can also be
used as a generic connectivity model. used as a generic connectivity model.
IP mobility protocols can be used to provide inter-access mobility IP mobility protocols can be used to provide heterogeneous network
support to users, e.g., handover from Wi-Fi to cellular access. Two mobility support to users, e.g., handover from Wi-Fi to cellular
kind of protocols can be used: Proxy Mobile IPv6 [RFC5213] or Mobile access. Two kind of protocols can be used: Proxy Mobile IPv6
IPv6 [RFC5555], with the mobility anchor (e.g., local mobility anchor [RFC5213] or Mobile IPv6 [RFC5555], with the role of mobility anchor,
or home agent) role typically being played by the edge router of the e.g., Local Mobility Anchor or home agent, typically being played by
mobile network [SDO-3GPP.23.402]. the edge router of the mobile network [SDO-3GPP.23.402].
Although this section has made use of the example of Wi-Fi networks, Although this section has made use of the example of Wi-Fi networks,
there are other IP flat wireless network architectures specified, there are other flattening mobile network architectures specified,
such as WiMAX [IEEE.802-16.2009], which integrates both host and such as WiMAX [IEEE.802-16.2009], which integrates both host- and
network-based IP mobility functionality. network-based IP mobility functions.
Existing IP mobility protocols can also be deployed in a flatter Existing IP mobility protocols can also be deployed in a flatter
manner, so that the anchoring and access aggregation functions are manner, so that the anchoring and access aggregation functions are
distributed. We next describe several practices for the deployment distributed. We next describe several practices for the deployment
of existing mobility protocols in a distributed mobility management of existing mobility protocols in a distributed mobility management
environment. The analysis in this section is limited to protocol environment. The analysis in this section is limited to protocol
solutions based on existing IP mobility protocols, either host- or solutions based on existing IP mobility protocols, either host- or
network-based, such as Mobile IPv6 [RFC6275], [RFC5555], Proxy Mobile network-based, such as Mobile IPv6 [RFC6275], [RFC5555], Proxy Mobile
IPv6 (PMIPv6) [RFC5213], [RFC5844] and Network Mobility Basic Support IPv6 (PMIPv6) [RFC5213], [RFC5844] and Network Mobility Basic Support
protocol (NEMO) [RFC3963]. Extensions to these base protocol protocol (NEMO) [RFC3963]. Extensions to these base protocol
solutions are also considered. The analysis is divided into two solutions are also considered. The analysis is divided 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 referred networks, the NEMO Basic Support protocol (hereafter, simply referred
to as NEMO) [RFC3963] are well-known host-based IP mobility to as NEMO) [RFC3963] are well-known host-based IP mobility
protocols. They depend upon the function of the Home Agent (HA), a protocols. They depend on the function of the Home Agent (HA), a
centralized anchor, to provide mobile nodes (hosts and routers) with centralized anchor, to provide mobile nodes (hosts and routers) with
mobility support. In these approaches, the home agent typically mobility support. In these approaches, the Home Agent typically
provides the anchoring function (AF), forwarding management (FM), and provides the Anchoring Function (AF), Forwarding Management (FM), and
Internetwork Location Information server (LIs) functions. The mobile Internetwork Location Information server (LIs) functions. The mobile
node possesses the Location Information client (LIc) function and the node possesses the Location Information client (LIc) function and the
FM function to enable tunneling between HA and itself. We next FM function to enable tunneling between HA and itself. We next
describe some practices that show how MIPv6/NEMO and several other describe some practices that show how MIPv6/NEMO and several other
protocol extensions can be deployed in a distributed mobility protocol extensions can be deployed in a distributed mobility
management environment. 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 the topologically closest anchor (as shown in Figure 2), and assign the topologically closest anchor
to each MN [RFC4640], [RFC5026], [RFC6611]. In the example shown in to each MN [RFC4640], [RFC5026], [RFC6611]. In the example shown in
Figure 2, MN1 is assigned HA1 (and a home address anchored by HA1), Figure 2, the mobile node MN1 is assigned to the home agent HA1 and
while MN2 is assigned HA2. Note that MIPv6/NEMO specifications do uses a home address anchored by HA1 to communicate with the
not prevent the simultaneous use of multiple home agents by a single correspondent node CN1. Similarly, the mobile node MN2 is assigned
mobile node. In this deployment model, the mobile node can use to the home agent HA2 and uses a home address anchored by HA2 to
several anchors at the same time, each of them anchoring IP flows communicate with the correspondent node CN2. Note that MIPv6/NEMO
initiated at a different point of attachment. However there is no specifications do not prevent the simultaneous use of multiple home
mechanism specified to enable an efficient dynamic discovery of agents by a single mobile node. In this deployment model, the mobile
available anchors and the selection of the most suitable one. Note node can use several anchors at the same time, each of them anchoring
that some of these mechanisms [SDO-3GPP.23.402] have been defined in IP flows initiated at a different point of attachment. However,
other standards organizations. there is currently no mechanism specified in IETF to enable an
efficient dynamic discovery of available anchors and the selection of
the most suitable one.
<- INTERNET -> <- HOME NETWORK -> <---- ACCESS NETWORK ----> <-INTERNET-> <- HOME NETWORK -> <------- ACCESS NETWORK ------->
------- ------- +-----+ +-----+ +--------+
| CN1 | ------- | AR1 |-(o) zzzz (o) | CN1 |--- ===| AR1 |=======| MN1 |
------- | HA1 | ------- | +-----+ \ +-----------+ // +-----+ |(FM,LMc)|
------- (MN1 anchored at HA1) ------- ---| HA1 |=== +--------+
------- | MN1 | |(AF,FM,LMs)| +-----+ (anchored
| AR2 |-(o) ------- +-----------+ | AR2 | at HA1)
------- +-----+ +-----+
------- | CN2 |--------------
| HA2 | ------- +-----+ \ +-----+ +--------+
------- | AR3 |-(o) zzzz (o) -------------| AR3 |-------| MN2 |
------- | +-----------+ +-----+ |(FM,LMc)|
------- (MN2 anchored at HA2) ------- | HA2 | +--------+
| CN2 | ------- | MN2 | |(AF,FM,LMs)| +-----+ (anchored
------- | AR4 |-(o) ------- +-----------+ | AR4 | at HA2)
------- +-----+
CN1 CN2 HA1 HA2 AR1 MN1 AR3 MN2 CN1 CN2 HA1 HA2 AR1 AR3 MN1 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 One goal of the deployment of mobility protocols in a distributed
distributed mobility management environment is to avoid the mobility management environment is to avoid the suboptimal routing
suboptimal routing caused by centralized anchoring, the Route caused by centralized anchoring. Here, the Route Optimization (RO)
Optimization (RO) support provided by Mobile IPv6 can also be used to support provided by Mobile IPv6 can be used to achieve a flatter IP
achieve a flatter IP data forwarding. By default, Mobile IPv6 and data forwarding. By default, Mobile IPv6 and NEMO use the so-called
NEMO use the so-called Bidirectional Tunnel (BT) mode, in which data Bidirectional Tunnel (BT) mode, in which data traffic is always
traffic is always encapsulated between the MN and its HA before being encapsulated between the MN and its HA before being directed to any
directed to any other destination. The Route Optimization (RO) mode other destination. The RO mode allows the MN to update its current
allows the MN to update its current location on the CNs, and then use location on the CNs, and then use the direct path between them.
the direct path between them. Using the example shown in Figure 2, Using the example shown in Figure 2, MN1 is using BT mode with CN1,
MN1 is using BT mode with CN1 and MN2 is in RO mode with CN2. while MN2 is in RO mode with CN2. However, the RO mode has several
However, the RO mode has several drawbacks: 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 proposed for prefixes, although many different solutions have been proposed
[RFC4889]. [RFC4889].
o The RO mode requires signaling that adds some protocol overhead. o The RO mode requires signaling that adds some protocol overhead.
o The signaling required to enable RO involves the home agent and is o The signaling required to enable RO involves the home agent and is
repeated periodically for security reasons [RFC4225] and, thus, repeated periodically for security reasons [RFC4225]. Therefore
the HA remains a single point of failure. the HA remains a single point of failure.
o The RO mode requires support from the correspondent node (CN). o The RO mode requires support from the 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 by 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 care-of-address
[RFC5014] when communicating with CNs on the same link or anywhere in (CoA) directly [RFC5014] when communicating with CNs on the same link
the Internet, although no session continuity support would be or anywhere in the Internet, although no session continuity support
provided by the IP stack in this case. would be provided by the IP stack in this case.
Hierarchical Mobile IPv6 (HMIPv6) [RFC5380] (as shown in Figure 3), Hierarchical Mobile IPv6 (HMIPv6) [RFC5380] (as shown in Figure 3),
is another host-based IP mobility extension which can be considered is another host-based IP mobility extension which can be considered
as a complement to provide a less centralized mobility deployment. as a complement to provide a less centralized mobility deployment.
It allows reducing the amount of mobility signaling as well as It allows the reduction of the amount of mobility signaling as well
improving the overall handover performance of Mobile IPv6 by as improving the overall handover performance of Mobile IPv6 by
introducing a new hierarchy level to handle local mobility. The introducing a new hierarchy level to handle local mobility. The
Mobility Anchor Point (MAP) entity is introduced as a local mobility Mobility Anchor Point (MAP) entity is introduced as a local mobility
handling node deployed closer to the mobile node. It provides LI handling node deployed closer to the mobile node. It provides LI
intermediary function between the LI server (LIs) at the HA and the intermediary function between the LI server (LIs) at the HA and the
LI client (LIc) at the MN. It also performs the FM function using LI client (LIc) at the MN. It also performs the FM function to
tunneling with the HA and also to tunnel with the MN. tunnel with the HA and also with the MN.
<- INTERNET -> <- HOME NETWORK -> <------- ACCESS NETWORK ------->
-----
/|AR1|-(o) zz (o)
-------- / ----- |
| MAP1 |< -------
-------- \ ----- | MN1 |
------- \|AR2| -------
| CN1 | ----- HoA anchored
------- ----- at HA1
------- /|AR3| RCoA anchored
| HA1 | -------- / ----- at MAP1
------- | MAP2 |< LCoA anchored
-------- \ ----- at AR1
\|AR4|
------- -----
| CN2 | -----
------- /|AR5|
-------- / -----
| MAP3 |<
-------- \ -----
\|AR6|
-----
CN1 CN2 HA1 MAP1 AR1 MN1 <INTERNET> <- HOME NETWORK -> <---------- ACCESS NETWORK ---------->
| | | | ________|__________ | LCoA anchored
|<------------------>|<==============>|<________+__________>| HoA at AR1
| | | | | | +---+ +--------+
| |<-------------------------->|<===================>| RCoA ===|AR1|==| MN1 |
| | | | | | +-----+ +-----------+ +----------+ // +---+ |(FM,LMc)|
| CN1 |----| HA1 |======| MAP1 |=== +--------+
+-----+ |(AF,FM,LMs)| /|(AF,FM,LM)| +---+ HoA,
+-----------+ / +----------+ |AR2| RCoA,
HoA anchored / RCoA anchored +---+ LCoA
at HA1 / at MAP1
/ +---+
/ |AR3|
+-----+ / +----------+ +---+
| CN2 |---------------- | MAP2 |
+-----+ |(AF,FM,LM)| +---+
+----------+ |AR4|
+---+
CN1 CN2 HA1 MAP1 AR1 MN1
| | | | | |
|<-------------->|<===============>|<======================>| HoA
| | | | | |
| |<-------------------------->|<======================>| RCoA
| | | | | |
Figure 3: Hierarchical Mobile IPv6 Figure 3: Hierarchical Mobile IPv6
When HMIPv6 is used, the MN has two different temporary addresses: When HMIPv6 is used, the MN has two different temporary addresses:
the Regional Care-of Address (RCoA) and the Local Care-of Address the Regional Care-of Address (RCoA) and the Local Care-of Address
(LCoA). The RCoA is anchored at one MAP, that plays the role of (LCoA). The RCoA is anchored at one MAP, which plays the role of
local home agent, while the LCoA is anchored at the access router local home agent, while the LCoA is anchored at the access router
level. The mobile node uses the RCoA as the CoA signaled to its home level. The mobile node uses the RCoA as the CoA signaled to its home
agent. Therefore, while roaming within a local domain handled by the agent. Therefore, while roaming within a local domain handled by the
same MAP, the mobile node does not need to update its home agent same MAP, the mobile node does not need to update its home agent,
(i.e., the mobile node does not change its RCoA). i.e., the mobile node does not change its RCoA.
The use of HMIPv6 enables some form of route optimization, since a The use of HMIPv6 enables some form of route optimization, since a
mobile node may decide to directly use the RCoA as source address for mobile node may decide to directly use the RCoA as source address for
a communication with a given correspondent node, particularly if the a communication with a given correspondent node, particularly if the
MN does not expect to move outside the local domain during the MN does not expect to move outside the local domain during the
lifetime of the communication. This can be seen as a potential DMM lifetime of the communication. This can be seen as a potential DMM
mode of operation,though it fails to provide session continuity if mode of operation, though it fails to provide session continuity if
and when the MN moves outside the local domain. In the example shown and when the MN moves outside the local domain. In the example shown
in Figure 3, MN1 is using its global HoA to communicate with CN1, in Figure 3, MN1 is using its global HoA to communicate with CN1,
while it is using its RCoA to communicate with CN2. while it is using its RCoA to communicate with CN2.
Furthermore, a local domain might have several MAPs deployed, Furthermore, a local domain might have several MAPs deployed,
enabling therefore a different kind of HMIPv6 deployments (e.g., enabling therefore a different kind of HMIPv6 deployments which are
flattening and distributed). The HMIPv6 specification supports a flattening and distributed. The HMIPv6 specification supports a
flexible selection of the MAP (e.g., based on the distance between flexible selection of the MAP, including those based on the distance
the MN and the MAP, taking into consideration the expected mobility between the MN and the MAP, or taking into consideration the expected
pattern of the MN, etc.). mobility pattern of the MN.
Another extension that can be used to help distributing mobility Another extension that can be used to help distributing mobility
management functions is the Home Agent switch specification management functions is the Home Agent switch specification
[RFC5142], which defines a new mobility header for signaling a mobile [RFC5142], which defines a new mobility header for signaling a mobile
node that it should acquire a new home agent. [RFC5142] does not node that it should acquire a new home agent. [RFC5142] does not
specify the case of changing the mobile node's home address, as that specify the case of changing the mobile node's home address, as that
might imply loss of connectivity for ongoing persistent connections. might imply loss of connectivity for ongoing persistent connections.
Nevertheless, that specification could be used to force the change of Nevertheless, that specification could be used to force the change of
home agent in those situations where there are no active persistent home agent in those situations where there are no active persistent
data sessions that cannot cope with a change of home address. data sessions that cannot cope with a change of home address.
skipping to change at page 12, line 10 skipping to change at page 11, line 49
[RFC4066] and Context Transfer Protocol (CXTP) [RFC4067] protocols [RFC4066] and Context Transfer Protocol (CXTP) [RFC4067] protocols
were standardized to improve the handover performance. The DMM were standardized to improve the handover performance. The DMM
deployment practice discussed in this section can also use those deployment practice discussed in this section can also use those
extensions to improve the handover performance. extensions to improve the handover performance.
4.2.2. Network-based IP DMM practices 4.2.2. Network-based IP DMM practices
Proxy Mobile IPv6 (PMIPv6) [RFC5213] is the main network-based IP Proxy Mobile IPv6 (PMIPv6) [RFC5213] is the main network-based IP
mobility protocol specified for IPv6. Proxy Mobile IPv4 [RFC5844] mobility protocol specified for IPv6. Proxy Mobile IPv4 [RFC5844]
defines some IPv4 extensions. With network-based IP mobility defines some IPv4 extensions. With network-based IP mobility
protocols, the local mobility anchor (LMA) typically provides the protocols, the Local Mobility Anchor (LMA) typically provides the
anchoring function (AF), Forwarding management (FM) function, and Anchoring Function (AF), Forwarding Management (FM) function, and
Internetwork Location Information server (LIs) function. The mobile Internetwork Location Information server (LIs) function. The mobile
access gateway (MAG) provides the Location Information client (LIc) access gateway (MAG) provides the Location Information client (LIc)
function and Forwarding management (FM) function to tunnel with LMA. function and Forwarding Management (FM) function to tunnel with LMA.
PMIPv6 is architecturally almost identical to MIPv6, as the mobility PMIPv6 is architecturally almost identical to MIPv6, as the mobility
signaling and routing between LMA and MAG in PMIPv6 is similar to signaling and routing between LMA and MAG in PMIPv6 is similar to
those between HA and MN in MIPv6. The required mobility those between HA and MN in MIPv6. The required mobility
functionality at the MN is provided by the MAG so that the functionality at the MN is provided by the MAG so that the
involvement in mobility support by the MN is not required. involvement in mobility support by the MN is not required.
We next describe some practices that show how network-based mobility We next describe some practices that show how network-based mobility
protocols and several other protocol extensions can be deployed in a protocols and several other protocol extensions can be deployed in a
distributed mobility management environment. distributed mobility management environment.
One way to decentralize Proxy Mobile IPv6 operation can be to deploy One way to decentralize Proxy Mobile IPv6 operation can be to deploy
several local mobility anchors and use some selection criteria to several Local Mobility Anchors and use some selection criteria to
assign LMAs to attaching mobile nodes (an example of this type of assign LMAs to attaching mobile nodes. An example of this type of
assignment is shown in Figure 4). As with the client based approach, assignment is shown in Figure 4. As with the client based approach,
a mobile node may use several anchors at the same time, each of them a mobile node may use several anchors at the same time, each of them
anchoring IP flows initiated at a different point of attachment. anchoring IP flows initiated at a different point of attachment.
This assignment can be static or dynamic. The main advantage of this This assignment can be static or dynamic. The main advantage of this
simple approach is that the IP address anchor (i.e., the LMA) could simple approach is that the IP address anchor, i.e., the LMA, could
be placed closer to the mobile node. Therefore the resulting paths 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 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. moves, the resulting path will start deviating from the optimal one.
<- INTERNET -><- HOME NET -><----------- ACCESS NETWORK ------------> <INTERNET> <--- HOME NETWORK ---> <------ ACCESS NETWORK ------->
------- +--------+ +---+
| CN1 | -------- -------- -------- =======| MAG1 |------|MN1|
------- -------- | MAG1 | | MAG2 | | MAG3 | +-----+ +-----------+ // |(FM,LMc)| +---+
| LMA1 | ---+---- ---+---- ---+---- | CN1 |-------| LMA1 |======= +--------+
------- -------- | | | +-----+ |(AF,FM,LMs)|
| CN2 | (o) (o) (o) +-----------+ +--------+
------- -------- x x +-----+ | MAG2 |
| LMA2 | x x | CN2 |--- |(FM,LMc)|
------- -------- (o) (o) +-----+ \ +-----------+ +--------+
| CN3 | | | ---| LMA2 |=======
------- ---+--- ---+--- +-----+ |(AF,FM,LMs)| \\ +--------+ +---+
Anchored | MN1 | Anchored | MN2 | | CN3 | +-----------+ =======| MAG3 |------|MN2|
at LMA1 -> ------- at LMA2 -> ------- +-----+ |(FM,LMs)| +---+
+--------+
CN1 CN2 LMA1 LMA2 MAG1 MN1 MAG3 MN2 CN1 CN2 LMA1 LMA2 MAG1 MAG3 MN1 MN2
| | | | | | | | | | | | | | | |
|<------------>|<================>|<---->| | | |<-------------->|<=========================>|<----------->| |
| | | | | | | | | | | | | | | |
| |<------------>|<========================>|<----->| | |<-------------->|<========================>|<----------->|
| | | | | | | | | | | | | | | |
Figure 4: Distributed operation of Proxy Mobile IPv6 Figure 4: Distributed operation of Proxy Mobile IPv6
Similar to the host-based IP mobility case, network-based IP mobility In a similar way to the host-based IP mobility case, network-based IP
has some extensions defined to mitigate the suboptimal routing issues mobility has some extensions defined to mitigate the suboptimal
that may arise due to the use of a centralized anchor. The Local routing issues that may arise due to the use of a centralized anchor.
Routing extensions [RFC6705] enable optimal routing in Proxy Mobile The Local Routing extensions [RFC6705] enable optimal routing in
IPv6 in three cases: i) when two communicating MNs are attached to Proxy Mobile IPv6 in three cases: i) when two communicating MNs are
the same MAG and LMA, ii) when two communicating MNs are attached to attached to the same MAG and LMA, ii) when two communicating MNs are
different MAGs but to the same LMA, and iii) when two communicating attached to different MAGs but to the same LMA, and iii) when two
MNs are attached to the same MAG but have different LMAs. In these communicating MNs are attached to the same MAG but have different
three cases, data traffic between the two mobile nodes does not LMAs. In these three cases, data traffic between the two mobile
traverse the LMA(s), thus providing some form of path optimization nodes does not traverse the LMA(s), thus providing some form of path
since the traffic is locally routed at the edge. The main optimization since the traffic is locally routed at the edge. The
disadvantage of this approach is that it only tackles the MN-to-MN main disadvantage of this approach is that it only tackles the MN-to-
communication scenario, and only under certain circumstances. 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 distributed deployment of network-based mobility protocols in a distributed
mobility management environment is the LMA runtime assignment mobility management environment is the support of LMA runtime
[RFC6463]. This extension specifies a runtime local mobility anchor assignment described in [RFC6463]. This extension specifies a
assignment functionality and corresponding mobility options for Proxy runtime Local Mobility Anchor assignment functionality and
Mobile IPv6. This runtime local mobility anchor assignment takes corresponding mobility options for Proxy Mobile IPv6. This runtime
place during the Proxy Binding Update / Proxy Binding Acknowledgment Local Mobility Anchor assignment takes place during the Proxy Binding
message exchange between a mobile access gateway and a local mobility Update / Proxy Binding Acknowledgment message exchange between a
anchor. While this mechanism is mainly aimed for load-balancing mobile access gateway and a local mobility anchor. While this
purposes, it can also be used to select an optimal LMA from the mechanism is mainly aimed for load-balancing purposes, it can also be
routing point of view. A runtime LMA assignment can be used to used to select an optimal LMA from the routing point of view. A
change the assigned LMA of an MN, for example, in cases when the runtime LMA assignment can be used to change the assigned LMA of an
mobile node does not have any active session, or when the running MN, for example, in cases when the mobile node does not have any
sessions can survive an IP address change. Note that several active session, or when the running sessions can survive an IP
possible dynamic local mobility anchor discovery solutions can be address change. Note that several possible dynamic Local Mobility
used, as described in [RFC6097]. Anchor discovery solutions can be used, as described in [RFC6097].
4.3. Flattening 3GPP mobile network approaches 4.3. Flattening 3GPP mobile network approaches
The 3rd Generation Partnership Project (3GPP) is the standards The 3rd Generation Partnership Project (3GPP) is the standards
development organization that specifies the 3rd generation mobile development organization that specifies the 3rd generation mobile
network and the Evolved Packet System (EPS), which mainly comprises network and the Evolved Packet System (EPS) [SDO-3GPP.23.402], which
the Evolved Packet Core (EPC) and a new radio access network, usually mainly comprises the Evolved Packet Core (EPC) and a new radio access
referred to as LTE (Long Term Evolution). network, usually 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 Network Gateway (PGW) anchoring services to
mobile nodes with mobility support (see Figure 5). There are client- provide mobile nodes with mobility support (see Figure 5). There are
based and network-based mobility solutions in 3GPP, which for client-based and network-based mobility solutions in 3GPP, which for
simplicity will be analyzed together. We next describe how 3GPP simplicity will be analyzed together. We next describe how 3GPP
mobility protocols and several other completed or ongoing extensions mobility protocols and several other completed or ongoing extensions
can be deployed to meet some of the DMM requirements [RFC7333]. can be deployed to meet some of the DMM requirements [RFC7333].
+---------------------------------------------------------+ +---------------------------------------------------------+
| PCRF | | PCRF |
+-----------+--------------------------+----------------+-+ +-----------+--------------------------+----------------+-+
| | | | | |
+----+ +-----------+------------+ +--------+-----------+ +-+-+ +----+ +-----------+------------+ +--------+-----------+ +-+-+
| | | +-+ | | Core Network | | | | | | +-+ | | Core Network | | |
skipping to change at page 15, line 43 skipping to change at page 14, line 43
| | +------------------------+ | | | | | | | | +------------------------+ | | | | | |
| | | +-+-+ | | | | | | +-+-+ | | |
| +--------------------------S2c--------------------| | | | | +--------------------------S2c--------------------| | | |
| | | | | | | | | | | |
+----+ +--------------------+ +---+ +----+ +--------------------+ +---+
Figure 5: EPS (non-roaming) architecture overview Figure 5: EPS (non-roaming) architecture overview
The GPRS Tunneling Protocol (GTP) [SDO-3GPP.29.060] [SDO-3GPP.29.281] The GPRS Tunneling Protocol (GTP) [SDO-3GPP.29.060] [SDO-3GPP.29.281]
[SDO-3GPP.29.274] is a network-based mobility protocol specified for [SDO-3GPP.29.274] is a network-based mobility protocol specified for
3GPP networks (S2a, S2b, S5 and S8 interfaces). Similar to PMIPv6, 3GPP networks (S2a, S2b, S5 and S8 interfaces). In a similar way to
it can handle mobility without requiring the involvement of the PMIPv6, it can handle mobility without requiring the involvement of
mobile nodes. In this case, the mobile node functionality is the mobile nodes. In this case, the mobile node functionality is
provided in a proxy manner by the Serving Data Gateway (SGW), Evolved provided in a proxy manner by the Serving Data Gateway (SGW), Evolved
Packet Data Gateway (ePDG), or Trusted Wireless Access Gateway (TWAG Packet Data Gateway (ePDG), or Trusted Wireless Access Gateway (TWAG
[SDO-3GPP.23.402]) . [SDO-3GPP.23.402]) .
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 [SDO-3GPP.24.303]. In this case, the User the S2c interface [SDO-3GPP.24.303]. In this case, the User
Equipment (UE) implements the binding update functionality, while the Equipment (UE) implements the binding update functionality, while the
home agent role is played by the PGW. home agent role is played by the PGW.
A Local IP Access (LIPA) and Selected IP Traffic Offload (SIPTO) A Local IP Access (LIPA) and Selected IP Traffic Offload (SIPTO)
enabled network [SDO-3GPP.23.401] allows offloading some IP services enabled network [SDO-3GPP.23.401] allows offloading some IP services
at the local access network, above the Radio Access Network (RAN) or at the local access network above the Radio Access Network (RAN)
at the macro, without the need to travel back to the PGW (see without the need to travel back to the PGW (see Figure 6).
Figure 6).
+---------+ IP traffic to mobile operator's CN +---------+ IP traffic to mobile operator's CN
| User |.........................\C2 | User |....................................(Operator's CN)
\B7.........(Opera | Equipm. |..................
r's CN)
| Equipm. |.........
....
.\C2
\B7
+---------+ . Local IP traffic +---------+ . Local IP traffic
. .
+-----------+ +-----------+
|Residential| |Residential|
|enterprise | |enterprise |
|IP network | |IP network |
+-----------+ +-----------+
Figure 6: LIPA scenario Figure 6: LIPA scenario
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 are 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 | UE |.....| eNB |....| SGW |........| PGW |.... CN Traffic
...> CN Traf +------+ +-----+ +-----+ +-----+
c
+-------+ +------+ +------+ +------+
Figure 7: SIPTO architecture Figure 7: SIPTO architecture
LIPA, on the other hand, enables an IP addressable UE connected via a LIPA, on the other hand, enables an IP addressable UE connected via a
Home eNB (HeNB) to access other IP addressable entities in the same Home eNB (HeNB) to access other IP addressable entities in the same
residential/enterprise IP network without traversing the mobile residential/enterprise IP network without traversing the mobile
operator's network core in the user plane. In order to achieve this, operator's network core in the user plane. In order to achieve this,
a Local GW (L-GW) collocated with the HeNB is used. LIPA is a Local GW (LGW) collocated with the HeNB is used. LIPA is
established by the UE requesting a new PDN (Public Data Network) established by the UE requesting a new Public Data Network (PDN)
connection to an access point name for which LIPA is permitted, and connection to an access point name for which LIPA is permitted, and
the network selecting the Local GW associated with the HeNB and the network selecting the Local GW associated with the HeNB and
enabling a direct user plane path between the Local GW and the HeNB. enabling a direct user plane path between the Local GW and the HeNB.
+---------------+-------+ +----------+ +-------------+ ===== +---------------+------+ +----------+ +-------------+ =====
|Residential | |H(e)NB | | Backhaul | |Mobile | ( IP ) |Residential | | HeNB | | Backhaul | |Mobile | ( IP )
|Enterprise |..|-------|..| |..|Operator |..(Network) |Enterprise |..|------|..| |..|Operator |..(Network)
|Network | |L-GW | | | |Core network | ======= |Network | | LGW | | | |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 [SDO-3GPP.29.303]. These discovery and selection of gateways [SDO-3GPP.29.303]. These
mechanisms enable decisions taking into consideration topological mechanisms enable decisions taking into consideration topological
location and gateway collocation aspects, relying upon the DNS as a location and gateway collocation aspects, relying upon 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, especially
in 3GPP specifications up to Rel-12. Briefly, LIPA mobility support in 3GPP specifications up to Rel-12. Briefly, LIPA mobility support
is limited to handovers between HeNBs that are managed by the same is limited to handovers between HeNBs that are managed by the same
L-GW (i.e., mobility within the local domain). There is no guarantee LGW (i.e., mobility within the local domain). There is no guarantee
of IP session continuity for SIPTO. of IP session continuity for SIPTO.
5. Gap analysis 5. Gap analysis
The goal of this section is to identify the limitations in the This section identifies the limitations in the current practices,
current practices, described in Section 4, with respect to the DMM described in Section 4, with respect to the DMM requirements listed
requirements listed in [RFC7333]. in [RFC7333].
5.1. Distributed mobility management - REQ1 5.1. Distributed mobility management - REQ1
According to requirement #1 stated in [RFC7333], IP mobility, network According to requirement REQ1 stated in [RFC7333], IP mobility,
access and forwarding solutions provided by DMM must enable traffic network access and forwarding solutions provided by DMM must make it
to avoid traversing single mobility anchor far from the optimal possible for traffic to avoid traversing a single mobility anchor far
route. from the optimal route.
From the analysis performed in Section 4, a DMM deployment can meet From the analysis performed in Section 4, a DMM deployment can meet
the requirement "REQ#1 Distributed mobility management" usually the requirement "REQ1 Distributed mobility management" usually
relying on the following functions: relying on the following functions:
o Multiple (distributed) anchoring: ability to anchor different o Multiple (distributed) anchoring: ability to anchor different
sessions of a single mobile node at different anchors. In order sessions of a single mobile node at different anchors. In order
to provide improved routing, some anchors might need to be placed to provide improved routing, some anchors might need to be placed
closer to the mobile node or the corresponding node. closer to the mobile node or the corresponding node.
o Dynamic anchor assignment/re-location: ability to i) assign the o Dynamic anchor assignment/re-location: ability to i) assign the
initial anchor, and ii) dynamically change the initially assigned initial anchor, and ii) dynamically change the initially assigned
anchor and/or assign a new one (this may also require to transfer anchor and/or assign a new one (this may also require the transfer
mobility context between anchors). This can be achieved either by of mobility context between anchors). This can be achieved either
changing anchor for all ongoing sessions or by assigning new by changing anchor for all ongoing sessions or by assigning new
anchors just for new sessions. anchors just for new sessions.
Both the main client- and network-based IP mobility protocols, namely GAP1-1: Both the main client- and network-based IP mobility
(DS)MIPv6 and PMIPv6 allow deploying multiple anchors (i.e., home protocols, namely (DS)MIPv6 and PMIPv6 allow deploying
agents and localized mobility anchors), therefore providing the multiple anchors (i.e., home agents and localized mobility
multiple anchoring function. However, existing solutions only anchors), thereby providing the multiple anchoring function.
provide a initial anchor assignment, thus the lack of dynamic anchor However, existing solutions only provide an initial anchor
change/new anchor assignment is a gap. Neither the HA switch nor the assignment, thus the lack of dynamic anchor change/new
LMA runtime assignment allow changing the anchor during an ongoing anchor assignment is a gap. Neither the HA switch nor the
session. This actually comprises several gaps: ability to perform LMA runtime assignment allows changing the anchor during an
anchor assignment at any time (not only at the initial MN's ongoing session. This actually comprises several gaps:
attachment), ability of the current anchor to initiate/trigger the ability to perform anchor assignment at any time (not only
relocation, and ability to transfer registration context between at the initial MN's attachment), ability of the current
anchors. anchor to initiate/trigger the relocation, and ability to
transfer registration context between anchors.
Dynamic anchor assignment may lead the MN to manage different GAP1-2: Dynamic anchor assignment may lead the MN to manage
mobility sessions served by different mobility anchors. This is not different mobility sessions served by different mobility
an issue with client based mobility management where the mobility anchors. This is not an issue with client based mobility
client natively knows each anchor associated to each mobility management where the mobility client natively knows the
sessions. However, there is one gap, as the MN should be capable of anchor associated with each of its mobility sessions.
handling IP addresses in a DMM-friendly way, meaning that the MN can However, there is one gap, as the MN should be capable of
perform smart source address selection (i.e., deprecating IP handling IP addresses in a DMM-friendly way, meaning that
addresses from previous mobility anchors, so they are not used for the MN can perform smart source address selection (i.e.,
new sessions). Besides, managing different mobility sessions served deprecating IP addresses from previous mobility anchors, so
by different mobility anchors may raise issues with network based they are not used for new sessions). Besides, managing
mobility management. In this case, the mobile client, located in the different mobility sessions served by different mobility
network (e.g., MAG), usually retrieves the MN's anchor from the MN's anchors may raise issues with network based mobility
policy profile (e.g., Section 6.2 of [RFC5213]). Currently, the MN's management. In this case, the mobile client located in the
policy profile implicitly assumes a single serving anchor and, thus, network, e.g., MAG, usually retrieves the MN's anchor from
does not maintain the association between home network prefix and the MN's policy profile as described in Section 6.2 of
anchor. [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 GAP1-3: The consequence of the distribution of the mobility anchors
there might be more than one available anchor for a mobile node to is that there might be more than one available anchor for a
use, which leads to an anchor discovery and selection issue. mobile node to use, which leads to an anchor discovery and
Currently, there is no efficient mechanism specified to allow selection issue. Currently, there is no efficient mechanism
dynamically discovering the presence of nodes that can play the specified to allow the dynamic discovery of the presence of
anchor role, discovering their capabilities and selecting the most nodes that can play the anchor role, discovering their
suitable one. There is also no mechanism to allow selecting a node capabilities and selecting the most suitable one. There is
that is currently anchoring a given home address/prefix (capability also no mechanism to allow selecting a node that is
sometimes required to meet REQ#2). There are though some mechanisms currently anchoring a given home address/prefix (capability
that could help discovering anchors, such as the Dynamic Home Agent sometimes required to meet REQ#2). However, there are some
Address Discovery (DHAAD), the use of the Home Agent (H) flag in mechanisms that could help to discover anchors, such as the
Router Advertisements (which indicates that the router sending the Dynamic Home Agent Address Discovery (DHAAD) [RFC6275], the
Router Advertisement is also functioning as a Mobile IPv6 home agent use of the home agent flag (H) in Router Advertisements
on the link) or the MAP option in Router Advertisements defined by (which indicates that the router sending the Router
HMIPv6. Note that there are 3GPP mechanisms providing that Advertisement is also functioning as a Mobile IPv6 home
functionality defined in [SDO-3GPP.29.303]. 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].
Regarding the ability to transfer registration context between Regarding the ability to transfer registration context between
anchors, there are already some solutions that could be reused or anchors, there are already some solutions that could be reused or
adapted to fill that gap, such as Fast Handovers for Mobile IPv6 adapted to fill that gap, such as Fast Handovers for Mobile IPv6
[RFC5568] -- to enable traffic redirection from the old to the new [RFC5568] -- to enable traffic redirection from the old to the new
anchor --, the Context Transfer protocol [RFC4067] -- to enable the anchor --, the Context Transfer protocol [RFC4067] -- to enable the
required transfer of registration information between anchors --, or required transfer of registration information between anchors --, or
the Handover Keying architecture solutions [RFC6697], to speed up the the Handover Keying architecture solutions [RFC6697], to speed up the
re-authentication process after a change of anchor. Note that some re-authentication process after a change of anchor. Note that some
extensions might be needed in the context of DMM, as these protocols extensions might be needed in the context of DMM, as these protocols
were designed in the context of centralized client IP mobility, were designed in the context of centralized client IP mobility,
focusing on the access re-attachment and authentication. focusing on the access re-attachment and authentication.
Also note that REQ1 is such that the data plane traffic can avoid GAP1-4: Also note that REQ1 is intended to prevent the data plane
suboptimal route. Distributed processing of the traffic is then traffic from taking a suboptimal route. Distributed
needed only in the data plane. The needed capability in distributed processing of the traffic may then be needed only in the
processing therefore should not contradict with centralized control data plane. Provision of this capability for distributed
plane. Other control plane solutions such as charging, lawful processing should not conflict with the use of a centralized
interception, etc. should not be limited. Yet combining the control control plane. Other control plane solutions such as
plane and data plane forwarding management (FM) function may limit charging, lawful interception, etc. should not be
the choice to distributing both data plane and control plane constrained by the DMM solution. On the other hand
together. In order to enable distributing only the data plane combining the control plane and data plane forwarding
without distributing the control plane, a gap is to split the management (FM) function may limit the choice of solutions
forwarding management function into the control plane (FM-CP) and to those that distribute both data plane and control plane
data plane (FM-DP). together. In order to enable distribution of only the data
plane without distributing the control plane, it would be
necessary to split the forwarding management function into
the control plane (FM-CP) and data plane (FM-DP) components;
there is currently a gap here.
5.2. Bypassable network-layer mobility support for each application 5.2. Bypassable network-layer mobility support for each application
session - REQ2 session - REQ2
The need for "bypassable network-layer mobility support for each The requirement REQ2 for "bypassable network-layer mobility support
application session" introduced in [RFC7333] requires flexibility on for each application session" introduced in [RFC7333] requires
determining whether network-layer mobility support is needed. The flexibility in determining whether network-layer mobility support is
requirement enables one to choose whether or not use network-layer needed. This requirement enables one to choose whether or not to use
mobility support. It only enables the two following functions: network-layer mobility support. The following two functions are also
needed:
o Dynamically assign/relocate anchor: a mobility anchor is assigned o Dynamically assign/relocate anchor: a mobility anchor is assigned
only to sessions which uses the network-layer mobility support. only to sessions which use the network-layer mobility support.
The MN may thus manage more than one session; some of them may be The MN may thus manage more than one session; some of them may be
associated with anchored IP address(es), while the others may be associated with anchored IP address(es), while the others may be
associated with local IP address(es). associated with local IP address(es).
o Multiple IP address management: this function is related to the o Multiple IP address management: this function is related to the
preceding and is about the ability of the mobile node to preceding and is about the ability of the mobile node to
simultaneously use multiple IP addresses and select the best one simultaneously use multiple IP addresses and select the best one
(from an anchoring point of view) to use on a per-session/ (from an anchoring point of view) to use on a per-
application/service basis. This requires MN to acquire session/application/service basis. This requires MN to acquire
information regarding the properties of the available IP information regarding the properties of the available IP
addresses. addresses.
The dynamic anchor assignment/relocation needs to ensure that IP GAP2-1: The dynamic anchor assignment/relocation needs to ensure
address continuity is guaranteed for sessions that uses such mobility that IP address continuity is guaranteed for sessions that
support (e.g., in some scenarios, the provision of mobility locally uses such mobility support (e.g., in some scenarios, the
within a limited area might be enough from the mobile node or the provision of mobility locally within a limited area might be
application point of view) at the relocated anchor. Implicitly, when enough from the mobile node or the application point of
no applications are using the network-layer mobility support, DMM may view) at the relocated anchor. Implicitly, when no
release the needed resources. This may imply having the knowledge of applications are using the network-layer mobility support,
which sessions at the mobile node are active and are using the DMM may release the needed resources. This may imply having
mobility support. This is something typically known only by the MN the knowledge of which sessions at the mobile node are
(e.g., by its connection manager), and would also typically require active and are using the mobility support. This is
some signaling support (e.g., socket API extensions) from something typically known only by the MN, e.g., by its
applications to indicate the IP stack whether mobility support is connection manager, and would also typically require some
required or not in. Therefore, (part of) this knowledge might need signaling support such as socket API extensions from
to be transferred to/shared with the network. applications to indicate to the IP stack whether mobility
support is required or not. Therefore, (part of) this
knowledge might need to be transferred to/shared with the
network.
Multiple IP address management provides the MN with the choice to GAP2-2: Multiple IP address management provides the MN with the
pick-up the correct address (provided with mobility support or not) choice to pick the correct address, e.g., from those
depending on the application requirements. When using client based provided or not provided with mobility support, depending on
mobility management, the mobile node is itself aware of the anchoring the application requirements. When using client based
capabilities of its assigned IP addresses. This is not necessarily mobility management, the mobile node is itself aware of the
the case with network based IP mobility management; current anchoring capabilities of its assigned IP addresses. This
mechanisms do not allow the MN to be aware of the properties of its is not necessarily the case with network based IP mobility
IP addresses (e.g., the MN does not know whether the allocated IP management; current mechanisms do not allow the MN to be
addresses are anchored). However, there are proposals that the aware of the properties of its IP addresses. For example,
network could indicate such IP address properties during assignment the MN does not know whether the allocated IP addresses are
procedures, such as [I-D.bhandari-dhc-class-based-prefix], anchored. However, there are proposals, such as
[I-D.korhonen-6man-prefix-properties] and [I-D.anipko-mif-mpvd-arch]. [I-D.bhandari-dhc-class-based-prefix],
Although there exist these individual efforts that could be be [I-D.korhonen-6man-prefix-properties] and
considered as attempts to fix the gap, there is no solution adopted [I-D.anipko-mif-mpvd-arch] that the network could indicate
as a work item within any IETF working group. such IP address properties during assignment procedures.
Although these individual efforts exist and they could be
considered as attempts to fix the gap, there is no solution
adopted as a work item within any IETF working group.
The handling of mobility management to the granularity of an GAP2-3: The handling of mobility management to the granularity of an
individual session of a user/device needs proper session individual session of a user/device needs proper session
identification in addition to user/device identification. identification in addition to user/device identification.
5.3. IPv6 deployment - REQ3 5.3. IPv6 deployment - REQ3
This requirement states that DMM solutions should primarily target This requirement states that DMM solutions should primarily target
IPv6 as the primary deployment environment. IPv4 support is not IPv6 as the primary deployment environment. IPv4 support is not
considered mandatory and solutions should not be tailored considered mandatory and solutions should not be tailored
specifically to support IPv4. specifically to support IPv4.
All analyzed DMM practices support IPv6. Some of them, such as All analyzed DMM practices support IPv6. Some of them, such as
MIPv6/NEMO (including the support of dynamic HA selection), MOBIKE, MIPv6/NEMO including the support of dynamic HA selection, MOBIKE,
SIPTO have also IPv4 support. There are also some solutions that SIPTO also have IPv4 support. Some solutions, e.g., PMIPv6, also
have some limited IPv4 support (e.g., PMIPv6). In conclusion, this have some limited IPv4 support. In conclusion, this requirement is
requirement is met by existing DMM practices. met by existing DMM practices.
5.4. Existing mobility protocols - REQ4 5.4. Considering existing mobility protocols - REQ4
A DMM solution must first consider reusing and extending IETF- A DMM solution must first consider reusing and extending IETF-
standardized protocols before specifying new protocols. standardized protocols before specifying new protocols.
As stated in [RFC7333], a DMM solution could reuse existing IETF and As stated in [RFC7333], a DMM solution could reuse existing IETF and
standardized protocols before specifying new protocols. Besides, standardized protocols before specifying new protocols. Besides,
Section 4 of this document discusses various ways to flatten and Section 4 of this document discusses various ways to flatten and
distribute current mobility solutions. Actually, nothing prevent the distribute current mobility solutions. Actually, nothing prevents
distribution of mobility functions with in IP mobility protocols. the distribution of mobility functions within IP mobility protocols.
However, as discussed in Section 5.1 and Section 5.2, limitations However, as discussed in Section 5.1 and Section 5.2, limitations
exist. exist.
The 3GPP data plane anchoring function, i.e., the PGW, can be also be The 3GPP data plane anchoring function, i.e., the PGW, can also be
distributed, but with limitations; e.g., no anchoring relocation, no distributed, but with limitations; e.g., no anchoring relocation, no
context transfer between anchors and centralized control plane. The context transfer between anchors and centralized control plane. The
3GPP architecture is also going into the direction of flattening with 3GPP architecture is also going in the direction of flattening with
SIPTO and LIPA, though they do not provide full mobility support. SIPTO and LIPA, though they do not provide full mobility support.
For example, mobility support for SIPTO traffic can be rather For example, mobility support for SIPTO traffic can be rather
limited, and offloaded traffic cannot access operator services. limited, and offloaded traffic cannot access operator services.
Thus, the operator must be very careful in selecting which traffic to Thus, the operator must be very careful in selecting which traffic to
offload. offload.
5.5. Coexistence with deployed networks/hosts and operability across 5.5. Coexistence with deployed networks/hosts and operability across
different networks- REQ5 different networks - REQ5
According to [RFC7333], DMM implementations are required to co-exist According to [RFC7333], DMM implementations are required to co-exist
with existing network deployments, end hosts and routers. with existing network deployments, end hosts and routers.
Additionally, DMM solutions are expected to work across different Additionally, DMM solutions are expected to work across different
networks, possibly operated as separate administrative domains, when networks, possibly operated as separate administrative domains, when
the needed mobility management signaling, forwarding, and network the necessary mobility management signaling, forwarding, and network
access are allowed by the trust relationship between them. All access are allowed by the trust relationship between them. All
current mobility protocols can co-exist with existing network 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. Operation and management considerations - REQ6 5.6. Operation and management considerations - REQ6
This requirement actually comprises several aspects, as summarized This requirement actually comprises several aspects, as summarized
below. below.
skipping to change at page 22, line 29 skipping to change at page 21, line 47
solution is working properly. solution is working properly.
o A DMM solution is expected to expose the operational state of DMM o A DMM solution is expected to expose the operational state of DMM
to the administrators of the DMM entities. to the administrators of the DMM entities.
o A DMM solution, which supports flow mobility, is also expected to o A DMM solution, which supports flow mobility, is also expected to
support means to correlate the flow routing policies and the support means to correlate the flow routing policies and the
observed forwarding actions. observed forwarding actions.
o A DMM solution is expected to support mechanisms to check the o A DMM solution is expected to support mechanisms to check the
liveness of forwarding path. liveness of the forwarding path.
o A DMM solution has to provide fault management and monitoring o A DMM solution has to provide fault management and monitoring
mechanisms to manage situations where update of the mobility mechanisms to manage situations where update of the mobility
session or the data path fails. session or the data path fails.
o A DMM solution is expected to be able to monitor the usage of the o A DMM solution is expected to be able to monitor the usage of the
DMM protocol. DMM protocol.
o DMM solutions have to support standardized configuration with o DMM solutions have to support standardized configuration with
NETCONF [RFC6241], using YANG [RFC6020] modules, which are NETCONF [RFC6241], using YANG [RFC6020] modules, which are
expected to be created for DMM when needed for such configuration. expected to be created for DMM when needed for such configuration.
Existing mobility management protocols have not thoroughly documented GAP6-1: Existing mobility management protocols have not thoroughly
the above list of operation and management considerations. Each of documented how, or whether, they support the above list of
the above needs to be considered from the beginning in a DMM operation and management considerations. Each of the above
solution. needs to be considered from the beginning in a DMM solution.
Management information base (MIB) objects are currently defined in GAP6-2: Management information base (MIB) objects are currently
[RFC4295] for MIPv6 and in [RFC6475] for PMIPv6. Standardized defined in [RFC4295] for MIPv6 and in [RFC6475] for PMIPv6.
configuration with NETCONF [RFC6241], using YANG [RFC6020] modules is Standardized configuration with NETCONF [RFC6241], using
needed. YANG [RFC6020] modules is lacking.
5.7. Security considerations - REQ7 5.7. Security considerations - REQ7
As stated in [RFC7333], a DMM solution has to support any security As stated in [RFC7333], a DMM solution has to support any security
protocols and mechanisms needed to secure the network and to make protocols and mechanisms needed to secure the network and to make
continuous security improvements. In addition, with security taken continuous security improvements. In addition, with security taken
into consideration early in the design, a DMM solution cannot into consideration early in the design, a DMM solution cannot
introduce new security risks, or amplify existing security risks, introduce new security risks, or amplify existing security risks,
that cannot be mitigated by existing security protocols and that cannot be mitigated by existing security protocols and
mechanisms. mechanisms.
Current mobility protocols have all security mechanisms in place. Any solutions that are intended to fill in gaps identified in this
For example, Mobile IPv6 defines security features to protect binding document need to meet this requirement. At present, it does not
updates both to home agents and correspondent nodes. It also defines appear that using existing solutions to support DMM has introduced
mechanisms to protect the data packets transmission for Mobile IPv6 any new security issues. For example, Mobile IPv6 defines security
users. Proxy Mobile IPv6 and other variations of mobile IP also have features to protect binding updates both to home agents and
similar security considerations. correspondent nodes. It also defines mechanisms to protect the data
packets transmission for Mobile IPv6 users. Proxy Mobile IPv6 and
other variations of mobile IP also have similar security
considerations.
5.8. Multicast - REQ8 5.8. Multicast - REQ8
It is stated in [RFC7333] that DMM solutions are expected to enable It is stated in [RFC7333] that DMM solutions are expected to allow
multicast solutions to be developed to avoid network inefficiency in the development of multicast solutions to avoid network inefficiency
multicast traffic delivery. in multicast traffic delivery.
Current IP mobility solutions address mainly the mobility problem for Current IP mobility solutions address mainly the mobility problem for
unicast traffic. Solutions relying on the use of an anchor point for unicast traffic. Solutions relying on the use of an anchor point for
tunneling multicast traffic down to the access router, or to the tunneling multicast traffic down to the access router, or to the
mobile node, introduce the so-called "tunnel convergence problem". mobile node, introduce the so-called "tunnel convergence problem."
This means that multiple insta ces of the same multicast traffic can This means that multiple instances of the same multicast traffic can
converge to the same node, diminishing the advantage of using converge to the same node, diminishing the advantage of using
multicast protocols. multicast protocols.
[RFC6224] documents a baseline solution for the previous issue, and [RFC6224] documents a baseline solution for the previous issue, and
[RFC7028] a routing optimization solution. The baseline solution [RFC7028] a routing optimization solution. The baseline solution
suggests deploying an MLD proxy function at the MAG, and either a suggests deploying a Multicast Listener Discovery (MLD) proxy
multicast router or another MLD proxy function at the LMA. The function at the MAG, and either a multicast router or another MLD
routing optimization solution describes an architecture where a proxy function at the LMA. The routing optimization solution
dedicated multicast tree mobility anchor (MTMA) or a direct routing describes an architecture where a dedicated multicast tree mobility
option can be used to avoid the tunnel convergence problem. anchor or a direct routing option can be used to avoid the tunnel
convergence problem.
Besides the solutions highlighted before, there are no other Besides the solutions highlighted before, there are no other
mechanisms for mobility protocols to address the multicast tunnel mechanisms for mobility protocols to address the multicast tunnel
convergence problem. convergence problem.
5.9. Summary 5.9. Summary
We next list the main gaps identified from the analysis performed We next list the main gaps identified from the analysis performed
above: above:
o Existing solutions only provide an optimal initial anchor GAP1-1: Existing solutions only provide an optimal initial anchor
assignment, a gap being the lack of dynamic anchor change/new assignment, a gap being the lack of dynamic anchor change/
anchor assignment. Neither the HA switch nor the LMA runtime new anchor assignment. Neither the HA switch nor the LMA
assignment allow changing the anchor during an ongoing session. runtime assignment allows changing the anchor during an
MOBIKE allows change of GW but its applicability has been scoped ongoing session. MOBIKE allows change of GW but its
to very narrow use case. applicability has been scoped to a very narrow use case.
o The mobile node needs to simultaneously use multiple IP addresses GAP1-2: The MN needs to be able to perform source address selection.
with different properties, which requires to expose this Proper mechanism to inform the MN is lacking to provide the
information to the mobile node and to update accordingly the basis for the proper selection.
source address selection mechanism of the latter.
o Currently, there is no efficient mechanism specified by the IETF GAP1-3: Currently, there is no efficient mechanism specified by the
that allows to dynamically discover the presence of nodes that can IETF that allows the dynamic discovery of the presence of
play the role of anchor, discover their capabilities and allow the nodes that can play the role of anchor, discover their
selection of the most suitable one. However, the following capabilities and allow the selection of the most suitable
mechanisms that could help discovering anchors: one. However, the following mechanisms could help
discovering anchors:
o Dynamic Home Agent Address Discovery (DHAAD): the use of the Home Dynamic Home Agent Address Discovery (DHAAD): the use of the
Agent (H) flag in Router Advertisements (which indicates that the home agent (H) flag in Router Advertisements (which
router sending the Router Advertisement is also functioning as a indicates that the router sending the Router Advertisement
Mobile IPv6 home agent on the link) and the MAP option in Router is also functioning as a Mobile IPv6 home agent on the link)
Advertisements defined by HMIPv6. and the MAP option in Router Advertisements defined by
HMIPv6.
o While existing network-based DMM practices may allow to deploy GAP1-4: While existing network-based DMM practices may allow the
multiple LMAs and dynamically select the best one, this requires deployment of multiple LMAs and dynamically select the best
to still keep some centralization in the control plane, to access one, this requires to still keep some centralization in the
the policy database (as defined in RFC5213). Although control plane, to access the policy database (as defined in
[I-D.ietf-netext-pmip-cp-up-separation] allows a MAG to perform RFC5213). Although [I-D.ietf-netext-pmip-cp-up-separation]
splitting of its control and user planes, there is a lack of allows a MAG to perform splitting of its control and user
solutions/extensions that support a clear control and data plane planes, there is a lack of solutions/extensions that support
separation for IETF IP mobility protocols in a DMM context. a clear control and data plane separation for IETF IP
mobility protocols in a DMM context.
6. Security Considerations GAP2-1: The information of which sessions at the mobile node are
active and are using the mobility support need to be
transferred to or shared with the network. Such mechanism
has not been defined.
Distributed mobility management systems encounter same security GAP2-2: The mobile node needs to simultaneously use multiple IP
threats as existing centralized IP mobility protocols. Without addresses with different properties. There is a lack of
authentication, a malicious node could forge signaling messages and mechanism to expose this information to the mobile node
redirect traffic from its legitimate path. This would amount to a which can then update accordingly its source address
denial of service attack against the specific node or nodes for which selection mechanism.
the traffic is intended. Distributed mobility anchoring, while
keeping current security mechanisms, might require more security
associations to be managed by the mobility management entities,
potentially leading to scalability and performance issues. Moreover,
distributed mobility anchoring makes mobility security problems more
complex, since traffic redirection requests might come from
previously unconsidered origins, thus leading to distributed points
of attack. Consequently, the DMM security design needs to account
for the distribution of security associations between additional
mobility entities.
7. IANA Considerations GAP2-3: The handling of mobility management has not been to the
granularity of an individual session of a user/device
before. The combination of session identification and user/
device identification may be lacking.
None. GAP6-1: Mobility management protocols have not thoroughly documented
how, or whether, they support the following list of
operation and management considerations:
8. Contributors * A DMM solution needs to consider configuring a device,
monitoring the current operational state of a device,
responding to events that impact the device, possibly by
modifying the configuration and storing the data in a
format that can be analyzed later.
* A DMM solution has to describe in what environment and
how it can be scalably deployed and managed.
* A DMM solution has to support mechanisms to test if the
DMM solution is working properly.
* A DMM solution is expected to expose the operational
state of DMM to the administrators of the DMM entities.
* A DMM solution, which supports flow mobility, is also
expected to support means to correlate the flow routing
policies and the observed forwarding actions.
* A DMM solution is expected to support mechanisms to check
the liveness of the forwarding path.
* A DMM solution has to provide fault management and
monitoring mechanisms to manage situations where update
of the mobility session or the data path fails.
* A DMM solution is expected to be able to monitor the
usage of the DMM protocol.
* DMM solutions have to support standardized configuration
with NETCONF [RFC6241], using YANG [RFC6020] modules,
which are expected to be created for DMM when needed for
such configuration.
GAP6-2: Management information base (MIB) objects are currently
defined in [RFC4295] for MIPv6 and in [RFC6475] for PMIPv6.
Standardized configuration with NETCONF [RFC6241], using
YANG [RFC6020] modules is lacking.
6. Security Considerations
The deployment of DMM using existing IP mobility protocols raises
similar security threats as those encountered in centralized mobility
management systems. Without authentication, a malicious node could
forge signaling messages and redirect traffic from its legitimate
path. This would amount to a denial of service attack against the
specific node or nodes for which the traffic is intended.
Distributed mobility anchoring, while keeping current security
mechanisms, might require more security associations to be managed by
the mobility management entities, potentially leading to scalability
and performance issues. Moreover, distributed mobility anchoring
makes mobility security problems more complex, since traffic
redirection requests might come from previously unconsidered origins,
thus leading to distributed points of attack. Consequently, the DMM
security design needs to account for the distribution of security
associations between additional mobility entities.
7. Contributors
This document has benefited to valuable contributions from This document has benefited to valuable contributions from
Charles E. Perkins Charles E. Perkins
Huawei Technologies Huawei Technologies
EMail: charliep@computer.org EMail: charliep@computer.org
who had produced a matrix to compare the different mobility protocols who had produced a matrix to compare the different mobility protocols
and extensions against a list of desired DMM properties. They were and extensions against a list of desired DMM properties. They were
useful inputs in the early work of gap analysis. He had continued to useful inputs in the early work of gap analysis. He had continued to
give suggestions as well as extensive review comments to this give suggestions as well as extensive review comments to this
documents. documents.
9. References 8. References
9.1. Normative References 8.1. Normative References
[RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen, [RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen,
"Requirements for Distributed Mobility Management", RFC "Requirements for Distributed Mobility Management", RFC
7333, August 2014. 7333, August 2014.
9.2. Informative References 8.2. Informative References
[I-D.anipko-mif-mpvd-arch] [I-D.anipko-mif-mpvd-arch]
Anipko, D., "Multiple Provisioning Domain Architecture", Anipko, D., "Multiple Provisioning Domain Architecture",
draft-anipko-mif-mpvd-arch-05 (work in progress), November draft-anipko-mif-mpvd-arch-05 (work in progress), November
2013. 2013.
[I-D.bhandari-dhc-class-based-prefix] [I-D.bhandari-dhc-class-based-prefix]
Systems, C., Halwasia, G., Gundavelli, S., Deng, H., Systems, C., Halwasia, G., Gundavelli, S., Deng, H.,
Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class
based prefix", draft-bhandari-dhc-class-based-prefix-05 based prefix", draft-bhandari-dhc-class-based-prefix-05
 End of changes. 99 change blocks. 
479 lines changed or deleted 555 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/