One document matched: draft-ietf-dmm-best-practices-gap-analysis-08.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!--
<!ENTITY RFC2119 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
-->
<!ENTITY RFC6275 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6275.xml">
<!ENTITY RFC5213 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5213.xml">
<!ENTITY RFC5555 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5555.xml">
<!ENTITY RFC5844 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5844.xml">
<!ENTITY RFC3963 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3963.xml">
<!ENTITY RFC4640 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4640.xml">
<!ENTITY RFC5026 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5026.xml">
<!ENTITY RFC6611 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6611.xml">
<!ENTITY RFC4225 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4225.xml">
<!ENTITY RFC5380 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5380.xml">
<!ENTITY RFC5142 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5142.xml">
<!ENTITY RFC6705 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6705.xml">
<!ENTITY RFC6463 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6463.xml">
<!ENTITY RFC6097 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6097.xml">
<!ENTITY RFC4555 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4555.xml">
<!ENTITY RFC5996 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5996.xml">
<!ENTITY RFC5014 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5014.xml">
<!ENTITY RFC6224 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6224.xml">
<!ENTITY RFC7028 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7028.xml">
<!ENTITY RFC4889 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4889.xml">
<!ENTITY RFC5568 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5568.xml">
<!ENTITY RFC4066 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4066.xml">
<!ENTITY RFC4067 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4067.xml">
<!ENTITY RFC6697 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6697.xml">
<!ENTITY RFC4960 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4960.xml">
<!ENTITY RFC6724 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6724.xml">
<!ENTITY RFC4295 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4295.xml">
<!ENTITY RFC6020 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml">
<!ENTITY RFC6241 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY RFC6475 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6475.xml">
<!ENTITY RFC7333 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7333.xml">
<!ENTITY I-D.gundavelli-v6ops-community-wifi-svcs PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.gundavelli-v6ops-community-wifi-svcs.xml">
<!ENTITY I-D.bhandari-dhc-class-based-prefix PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.bhandari-dhc-class-based-prefix.xml">
<!ENTITY I-D.korhonen-6man-prefix-properties PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.korhonen-6man-prefix-properties.xml">
<!ENTITY I-D.anipko-mif-mpvd-arch PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.anipko-mif-mpvd-arch.xml">
<!ENTITY I-D.ietf-netext-pmip-cp-up-separation PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netext-pmip-cp-up-separation.xml">
<!ENTITY TS29060 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml5/reference.SDO-3GPP.29.060.xml">
<!ENTITY TS23859 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml5/reference.SDO-3GPP.23.859.xml">
<!ENTITY TR29281 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml5/reference.SDO-3GPP.29.281.xml">
<!ENTITY TS29274 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml5/reference.SDO-3GPP.29.274.xml">
<!ENTITY TS23402 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml5/reference.SDO-3GPP.23.402.xml">
<!ENTITY TS23401 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml5/reference.SDO-3GPP.23.401.xml">
<!ENTITY TS29303 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml5/reference.SDO-3GPP.29.303.xml">
]>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes"?>
<!-- sort the reference entries alphabetically -->
<?rfc iprnotified="no"?>
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<rfc category="info" ipr="trust200902" docName="draft-ietf-dmm-best-practices-gap-analysis-08">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header- it is only
necessary if the full title is longer than 39 characters -->
<title abbrev="DMM-best-practices-gap-analysis">
Distributed Mobility Management: Current practices and gap analysis
</title>
<author initials="D" role="editor" surname="Liu" fullname="Dapeng Liu">
<organization>China Mobile</organization>
<address>
<postal>
<street>Unit2, 28 Xuanwumenxi Ave, Xuanwu District</street>
<city>Beijing</city>
<code>100053</code>
<country>China</country>
</postal>
<email>liudapeng@chinamobile.com</email>
</address>
</author>
<author initials="JC." role="editor" surname="Zuniga" fullname="Juan Carlos Zuniga">
<organization abbrev="InterDigital">InterDigital Communications, LLC</organization>
<address>
<postal>
<street>1000 Sherbrooke Street West, 10th floor</street>
<city>Montreal, Quebec</city>
<code> H3A 3G4</code>
<country>Canada</country>
</postal>
<email>JuanCarlos.Zuniga@InterDigital.com</email>
<uri>http://www.InterDigital.com/</uri>
</address>
</author>
<author initials="P" surname="Seite" fullname="Pierrick Seite">
<organization>Orange</organization>
<address>
<postal>
<street>4, rue du Clos Courtel, BP 91226</street>
<city>Cesson-Sevigne</city>
<code>35512</code>
<country>France</country>
</postal>
<email>pierrick.seite@orange.com</email>
</address>
</author>
<author initials="H" surname="Chan" fullname="H Anthony Chan">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>5340 Legacy Dr. Building 3</street>
<city>Plano, TX</city>
<code>75024</code>
<country>USA</country>
</postal>
<email>h.a.chan@ieee.org</email>
</address>
</author>
<author fullname="Carlos J. Bernardos" initials="CJ." surname="Bernardos">
<organization abbrev="UC3M">Universidad Carlos III de Madrid</organization>
<address>
<postal>
<street>Av. Universidad, 30</street>
<city>Leganes, Madrid</city>
<code>28911</code>
<country>Spain</country>
</postal>
<phone>+34 91624 6236</phone>
<email>cjbc@it.uc3m.es</email>
<uri>http://www.it.uc3m.es/cjbc/</uri>
</address>
</author>
<date month="September" year="2014"></date>
<!-- If the month and year are both specified and are the current ones,
xml2rfc will fill in the current day for you. If only the current
year is specified, xml2rfc will fill in the current day and month
for you. If the year is not the current one, it is necessary to
specify at least a month (xml2rfc assumes day="1" if not specified
for the purpose of calculating the expiry date). With drafts it is
normally sufficient to specify just the year. -->
<!-- Meta-data Declarations -->
<area>Internet</area>
<workgroup>DMM</workgroup>
<abstract>
<t>
<!-- TODO: needs to be extended -->
This document analyzes deployment practices
of existing IP mobility protocols
in a distributed mobility management environment.
It then identifies existing limitations
when compared to the requirements
defined for a distributed mobility management solution.
</t>
</abstract>
</front>
<middle>
<!-- BEGIN 1. Introduction -->
<section anchor="sec:intro" title="Introduction">
<t>
Existing network-layer mobility management protocols
have primarily employed a mobility anchor
to ensure connectivity of a mobile node
by forwarding packets destined to,
or sent from,
the mobile node
after the node has moved to a different network.
The mobility anchor has been centrally deployed
in the sense that the traffic of millions of mobile nodes
in an operator network is typically managed by the same anchor.
This centralized deployment of mobility anchors
to manage IP sessions poses several problems.
In order to address these problems,
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 <xref target="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.
</t>
<t>
The rest of this document is organized as follows. <xref
target="sec:mobility_mngnt_functions" /> analyzes existing IP mobility protocols
by examining their functions and how these functions can be configured and used
to work in a DMM environment. <xref target="sec:practices" /> presents the
current practices of IP wireless networks and 3GPP architectures. Both
network- and host-based mobility protocols are considered.
<xref target="sec:gap" /> presents the gap analysis with respect to the current
practices.
</t>
</section>
<!-- END 1. Introduction -->
<!-- BEGIN 2. Terminology -->
<section anchor="sec:terminology" title="Terminology">
<!--
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described
in <xref target="RFC2119" />.
</t>
-->
<t>
All general mobility-related terms and their acronyms used in this document are
to be interpreted as defined in the Mobile IPv6 base specification
<xref target="RFC6275" />, in the Proxy Mobile IPv6 specification
<xref target="RFC5213" />,
and in the Distributed Mobility Management Requirements
<xref target="RFC7333" />.
These terms include mobile node (MN),
correspondent node (CN),
home agent (HA),
Local Mobility Anchor (LMA),
Mobile Access Gateway (MAG),
centrally depoyed mobility anchors,
distributed mobility management,
hierarchical mobile network,
flatter mobile network,
and
flattening mobile network.
</t>
<t>
In addition, this document also introduces some definitions of IP mobility
functions in <xref target="sec:mobility_mngnt_functions" />.
</t>
<t>
In this document
there are also references to a "distributed mobility management environment."
By this term,
we refer to a scenario in which the IP mobility,
access network and routing solutions allow for setting up IP networks
so that traffic is distributed in an optimal way,
without relying on
centrally deployed mobility anchors to manage IP mobility sessions.
</t>
</section>
<!-- END 2. Terminology -->
<!-- BEGIN 3. Functions of existing mobility protocols -->
<section anchor="sec:mobility_mngnt_functions" title="Functions of existing mobility protocols">
<t>
The host-based Mobile IPv6 (MIPv6)
<xref target="RFC6275"/>
and its network-based extension,
Proxy Mobile IPv6 (PMIPv6)
<xref target="RFC5213"/>,
as well as Hierarchical Mobile IPv6 (HMIPv6)
<xref target="RFC5380"/>
are logically centralized mobility management approaches
addressing primarily hierarchical mobile networks.
Although these approaches are centralized,
they have important mobility management functions
resulting from years of extensive work to develop and to extend these functions.
It is therefore useful to take these existing functions
and examine them in a DMM scenario
in order to understand
how to deploy the existing mobility protocols
to provide distributed mobility management.
</t>
<t>
The main mobility management functions of MIPv6, PMIPv6, and HMIPv6 are the
following:
<list style="numbers">
<t>
Anchoring Function (AF):
allocation to a mobile node of an IP address,
i.e., Home Address (HoA),
or prefix,
i.e., Home Network Prefix (HNP)
topologically anchored by the advertising node.
That is, the anchor node is able to advertise a connected route
into the routing infrastructure for the allocated IP prefixes.
This function is a control plane function.
</t>
<t>
Internetwork Location Information (LI) function:
managing and keeping track of the internetwork location of an MN.
The location information
may be a binding of the IP advertised address/prefix,
e.g., HoA or HNP,
to the IP routing address of the MN
or of a node that can forward packets destined to the MN.
It is a control plane function.
<vspace blankLines="1" />
In a client-server protocol model,
location query and update messages
may be exchanged between a location information client (LIc)
and a location information server (LIs).
</t>
<t>
Forwarding Management (FM) function:
packet interception and forwarding
to/from the IP address/prefix assigned to the MN,
based on the internetwork location information,
either to the destination or to some other network element
that knows how to forward the packets to their destination.
<vspace blankLines="1" />
FM may optionally be split
into the control plane (FM-CP) and data plane (FM-DP).
</t>
</list>
</t>
<t>
In Mobile IPv6,
the home agent (HA) typically provides the anchoring function (AF);
the location information server (LIs) is at the HA
whereas the location information client (LIc) is at the MN;
the Forwarding Management (FM) function
resides in both ends of the tunnel at the HA and the MN.
</t>
<t>
In Proxy Mobile IPv6,
the Local Mobility Anchor (LMA) provides the anchoring function (AF);
the location information server (LIs) is at the LMA
whereas the location information client (LIc)
is at the mobile access gateway (MAG);
the Forwarding Management (FM) function
resides in both ends of the tunnel at the HA and the MAG.
</t>
<t>
In Hierarchical Mobile IPv6 (HMIPv6) <xref target="RFC5380"/>,
the Mobility Anchor Point (MAP) serves as a location information aggregator
between the LIs at the HA and the LIc at the MN.
The MAP also provides the FM function to enable tunneling
between HA and itself as well as tunneling between MN and itself.
</t>
</section>
<!-- END 3. Functions of existing mobility protocols -->
<!-- BEGIN 4. DMM practices -->
<section anchor="sec:practices" title="DMM practices">
<t>
This section documents deployment practices of existing mobility protocols
to satisfy distributed mobility management requirements.
This description considers both IP wireless, e.g., evolved Wi-Fi hotspots, and 3GPP flattening mobile network.
</t>
<t>
While describing the current DMM practices,
the section provides references to the generic mobility management functions
described in <xref target="sec:mobility_mngnt_functions" />
as well as some initial hints on the identified gaps with respect
to the DMM requirements documented in
<xref target="RFC7333" />.
</t>
<!-- BEGIN 4.1 Assumptions -->
<section anchor="sec:assumptions" title="Assumptions">
<t>
There are many different approaches that can be considered
to implement and deploy a distributed anchoring and mobility solution.
The focus of the gap analysis
is on certain current mobile network architectures
and standardized IP mobility solutions,
considering any kind of deployment options
which do not violate the original protocol specifications.
In order to limit the scope of our analysis of DMM practices,
we consider the following list of technical assumptions:
<list style="numbers">
<t>
Both host- and network-based solutions are considered.
</t>
<t>
Solutions should allow selecting and using the most appropriate IP anchor among
a set of available candidates.
</t>
<t>
Mobility management should be realized by the preservation of the IP address
across the different points of attachment (i.e., provision of IP address
continuity). This is in contrast to certain transport-layer based approaches
such as Stream Control Transmission Protocol (SCTP) <xref target="RFC4960" />
or application-layer mobility.
</t>
</list>
Applications which can cope with changes in the MN's IP address do not
depend on IP mobility management protocols such as DMM. Typically, a connection
manager together with the operating system will configure the source address
selection mechanism of the IP stack. This might involve identifying application
capabilities and triggering the mobility support accordingly. Further
considerations on application management and source address selection are out
of the scope of this document, but the reader might consult
<xref target="RFC6724" />.
</t>
</section>
<!-- END 4.1 Assumptions -->
<!-- BEGIN 4.2. IP flat wireless network -->
<section anchor="sec:IP_flat_wireless" title="IP flat wireless network">
<t>
This section focuses on common IP wireless network architectures and how they
can be flattened from an IP mobility and anchoring point of view using common
and standardized protocols. We take Wi-Fi as an useful wireless technology,
since it is widely known and deployed nowadays. Some representative examples of
Wi-Fi deployment architectures are depicted in <xref target="fig:Wi-Fi_arch" />.
</t>
<figure anchor="fig:Wi-Fi_arch" title="IP Wi-Fi network architectures" >
<artwork><![CDATA[
+-------------+ _----_
+---+ | Access | _( )_
|AAA|. . . . . . | Aggregation |----------( Internet )
+---+ | Gateway | (_ _)
+-------------+ '----'
| | |
| | +-------------+
| | |
| | +-----+
+---------------+ | | AR |
| | +--+--+
+-----+ +-----+ *----+----*
| RG | | WLC | ( LAN )
+-----+ +-----+ *---------*
. / \ / \
/ \ +-----+ +-----+ +-----+ +-----+
/ \ |Wi-Fi| |Wi-Fi| |Wi-Fi| |Wi-Fi|
MN1 MN2 | AP1 | | AP2 | | AP3 | | AP4 |
+-----+ +-----+ +-----+ +-----+
. .
/ \ / \
/ \ / \
MN3 MN4 MN5 MN6
]]></artwork>
</figure>
<t>
In <xref target="fig:Wi-Fi_arch"/>,
three typical deployment options are shown
<xref target="I-D.gundavelli-v6ops-community-wifi-svcs"/>.
On the left hand side of the figure,
mobile nodes MN1 and MN2 directly connect to a Residential Gateway (RG)
at the customer premises.
The RG hosts the 802.11 Access Point (AP) function
to enable wireless layer-2 access connectivity
and also provides layer-3 routing functions.
In the middle of the figure,
mobile nodes MN3 and MN4 connect to Wi-Fi Access Points (APs) AP1 and AP2
that are managed by a Wireless LAN Controller (WLC),
which performs radio resource management on the APs,
domain-wide mobility policy enforcement
and centralized forwarding function for the user traffic.
The WLC could also implement layer-3 routing functions,
or attach to an access router (AR).
Last, on the right-hand side of the figure,
access points AP3 and AP4 are directly connected to an access router.
This can also be used as a generic connectivity model.
</t>
<t>
IP mobility protocols can be used
to provide heterogeneous network mobility support to users,
e.g., handover from Wi-Fi to cellular access.
Two kind of protocols can be used:
Proxy Mobile IPv6 <xref target="RFC5213" />
or Mobile IPv6 <xref target="RFC5555" />,
with the role of mobility anchor, e.g., Local Mobility Anchor or home agent,
typically being played by the edge router of the mobile network
<xref target="SDO-3GPP.23.402" />.
</t>
<t>
Although this section has made use of the example of Wi-Fi networks,
there are other flattening mobile network architectures specified,
such as WiMAX
<xref target="IEEE.802-16.2009" />,
which integrates both host- and network-based IP mobility functions.
</t>
<t>
Existing IP mobility protocols can also be deployed in a flatter manner,
so that the anchoring and access aggregation functions are distributed.
We next describe several practices
for the deployment of existing mobility protocols
in a distributed mobility management environment.
The analysis in this section is limited to protocol solutions
based on existing IP mobility protocols,
either host- or network-based,
such as Mobile IPv6
<xref target="RFC6275" />,
<xref target="RFC5555" />,
Proxy Mobile IPv6 (PMIPv6)
<xref target="RFC5213" />,
<xref target="RFC5844" />
and Network Mobility Basic Support protocol (NEMO)
<xref target="RFC3963" />.
Extensions to these base protocol solutions are also considered.
The analysis is divided into two parts: host- and network-based practices.
</t>
<!-- BEGIN 4.2.1. Host-based IP DMM practices -->
<section anchor="sec:host_dmm" title="Host-based IP DMM practices">
<t>
Mobile IPv6 (MIPv6) <xref target="RFC6275"/>
and its extension to support mobile networks,
the NEMO Basic Support protocol
(hereafter, simply referred to as NEMO)
<xref target="RFC3963"/>
are well-known host-based IP mobility protocols.
They depend on the function of the Home Agent (HA),
a centralized anchor,
to provide mobile nodes (hosts and routers) with mobility support.
In these approaches,
the Home Agent typically provides the Anchoring Function (AF),
Forwarding Management (FM),
and Internetwork Location Information server (LIs) functions.
The mobile node possesses the Location Information client (LIc) function
and the FM function to enable tunneling between HA and itself.
We next describe some practices
that show how MIPv6/NEMO and several other protocol extensions
can be deployed in a distributed mobility management environment.
</t>
<t>
One approach to distribute the anchors can be to deploy several HAs
(as shown in <xref target="fig-MIPv6_multiple_HAs"/>),
and assign the topologically closest anchor to each MN
<xref target="RFC4640"/>,
<xref target="RFC5026"/>,
<xref target="RFC6611"/>.
In the example shown in
<xref target="fig-MIPv6_multiple_HAs"/>,
the mobile node MN1 is assigned to the home agent HA1
and uses a home address anchored by HA1
to communicate with the correspondent node CN1.
Similarly, the mobile node MN2 is assigned to the home agent HA2
and uses a home address anchored by HA2
to communicate with the correspondent node CN2.
Note that MIPv6/NEMO specifications
do not prevent the simultaneous use of multiple home agents
by a single mobile node.
In this deployment model,
the mobile node can use several anchors at the same time,
each of them anchoring IP flows
initiated at a different point of attachment.
However, 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.
</t>
<figure anchor="fig-MIPv6_multiple_HAs" align="center"
title="Distributed operation of Mobile IPv6 (BT and RO) / NEMO">
<artwork><![CDATA[
<-INTERNET-> <- HOME NETWORK -> <------- ACCESS NETWORK ------->
+-----+ +-----+ +--------+
| CN1 |--- ===| AR1 |=======| MN1 |
+-----+ \ +-----------+ // +-----+ |(FM,LMc)|
---| HA1 |=== +--------+
|(AF,FM,LMs)| +-----+ (anchored
+-----------+ | AR2 | at HA1)
+-----+ +-----+
| CN2 |--------------
+-----+ \ +-----+ +--------+
-------------| AR3 |-------| MN2 |
+-----------+ +-----+ |(FM,LMc)|
| HA2 | +--------+
|(AF,FM,LMs)| +-----+ (anchored
+-----------+ | AR4 | at HA2)
+-----+
CN1 CN2 HA1 HA2 AR1 AR3 MN1 MN2
| | | | | | | |
|<-------------->|<================+=============>| | BT mode
| | | | | | | |
| |<---------------------------------+-------------->| RO mode
| | | | | | | |
]]></artwork>
</figure>
<t>
One goal of the deployment of mobility protocols
in a distributed mobility management environment
is to avoid the suboptimal routing caused by centralized anchoring.
Here, the Route Optimization (RO) support provided by Mobile IPv6
can be used to achieve a flatter IP data forwarding.
By default,
Mobile IPv6 and NEMO use the so-called Bidirectional Tunnel (BT) mode,
in which data traffic is always encapsulated between the MN and its HA
before being directed to any other destination.
The RO mode allows the MN
to update its current location on the CNs,
and then use the direct path between them.
Using the example shown in <xref target="fig-MIPv6_multiple_HAs"/>,
MN1 is using BT mode with CN1,
while MN2 is in RO mode with CN2.
However, the RO mode has several drawbacks:
<list style="symbols">
<t>
The RO mode is only supported by Mobile IPv6.
There is no route optimization support standardized for the NEMO protocol
because of the security problems
posed by extending return routability tests for prefixes,
although many different solutions have been proposed
<xref target="RFC4889"/>.
</t>
<t>
The RO mode requires signaling that adds some protocol overhead.
</t>
<t>
The signaling required to enable RO involves the home agent
and is repeated periodically for security reasons <xref target="RFC4225"/>.
Therefore the HA remains a single point of failure.
</t>
<t>
The RO mode requires support from the CN.
</t>
</list>
</t>
<t>
Notwithstanding these considerations,
the RO mode does offer the possibility
of substantially reducing traffic through the Home Agent,
in cases when it can be supported by the relevant correspondent nodes.
Note that a mobile node can also use its care-of-address (CoA) directly
<xref target="RFC5014" />
when communicating with CNs on the same link or anywhere in the Internet,
although no session continuity support would be provided
by the IP stack in this case.
</t>
<t>
Hierarchical Mobile IPv6 (HMIPv6)
<xref target="RFC5380"/>
(as shown in <xref target="fig-MIPv6_HMIPv6"/>),
is another host-based IP mobility extension
which can be considered as a complement
to provide a less centralized mobility deployment.
It allows the reduction of the amount of mobility signaling
as well as improving the overall handover performance of Mobile IPv6
by introducing a new hierarchy level to handle local mobility.
The Mobility Anchor Point (MAP) entity
is introduced as a local mobility handling node
deployed closer to the mobile node.
It provides LI intermediary function
between the LI server (LIs) at the HA
and the LI client (LIc) at the MN.
It also performs the FM function
to tunnel with the HA and also with the MN.
</t>
<figure anchor="fig-MIPv6_HMIPv6" title="Hierarchical Mobile IPv6"
align="center">
<artwork><![CDATA[
<INTERNET> <- HOME NETWORK -> <---------- ACCESS NETWORK ---------->
LCoA anchored
at AR1
+---+ +--------+
===|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
| | | | | |
]]></artwork>
</figure>
<t>
When HMIPv6 is used, the MN has two different temporary addresses:
the Regional Care-of Address (RCoA) and the Local Care-of Address (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 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 same MAP,
the mobile node does not need to update its home agent,
i.e., the mobile node does not change its RCoA.
</t>
<t>
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 a communication with a given correspondent node,
particularly if 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 mode of operation,
though it fails to provide session continuity
if and when the MN moves outside the local domain.
In the example shown in
<xref target="fig-MIPv6_HMIPv6"/>,
MN1 is using its global HoA to communicate with CN1,
while it is using its RCoA to communicate with CN2.
</t>
<t>
Furthermore, a local domain might have several MAPs deployed,
enabling therefore a different kind of HMIPv6 deployments
which are flattening and distributed.
The HMIPv6 specification supports a flexible selection of the MAP,
including those based on the distance between the MN and the MAP,
or taking into consideration the expected mobility pattern of the MN.
</t>
<t>
Another extension that can be used
to help distributing mobility management functions
is the Home Agent switch specification <xref target="RFC5142"/>,
which defines a new mobility header for signaling a mobile node
that it should acquire a new home agent.
<xref target="RFC5142"/> does not specify
the case of changing the mobile node's home address,
as that might imply loss of connectivity
for ongoing persistent connections.
Nevertheless, that specification could be used
to force the change of home agent in those situations
where there are no active persistent data sessions
that cannot cope with a change of home address.
</t>
<t>
There are other host-based approaches standardized
that can be used to provide mobility support.
For example MOBIKE <xref target="RFC4555" />
allows a mobile node encrypting traffic
through IKEv2 <xref target="RFC5996" />
to change its point of attachment
while maintaining a Virtual Private Network (VPN) session.
The MOBIKE protocol allows updating the VPN Security Associations (SAs)
in cases where the base connection initially used is lost
and needs to be re-established.
The use of the MOBIKE protocol
avoids having to perform an IKEv2 re-negotiation.
Similar considerations to those made for Mobile IPv6
can be applied to MOBIKE;
though MOBIKE is best suited for situations
where the address of at least one endpoint is relatively stable
and can be discovered using existing mechanisms such as DNS.
</t>
<t>
Extensions have been defined to the mobility protocol
to optimize the handover performance.
Mobile IPv6 Fast Handovers (FMIPv6) <xref target="RFC5568"/>
is the extension to optimize handover latency.
It defines new access router discovery mechanism before handover
to reduce the new network discovery latency.
It also defines a tunnel
between the previous access router and the new access router
to reduce the packet loss during handover.
The Candidate Access Router Discovery (CARD)
<xref target="RFC4066"/>
and Context Transfer Protocol (CXTP)
<xref target="RFC4067"/> protocols
were standardized to improve the handover performance.
The DMM deployment practice discussed in this section
can also use those extensions to improve the handover performance.
</t>
</section>
<!-- END 4.2.1. Host-based IP DMM practices -->
<!-- BEGIN 4.2.2. Network-based IP DMM practices -->
<section anchor="sec:net_dmm" title="Network-based IP DMM practices">
<t>
Proxy Mobile IPv6 (PMIPv6) <xref target="RFC5213"/>
is the main network-based IP mobility protocol specified for IPv6.
Proxy Mobile IPv4 <xref target="RFC5844"/> defines some IPv4 extensions.
With network-based IP mobility protocols,
the Local Mobility Anchor (LMA)
typically provides the Anchoring Function (AF),
Forwarding Management (FM) function,
and Internetwork Location Information server (LIs) function.
The mobile access gateway (MAG) provides
the Location Information client (LIc) function
and Forwarding Management (FM) function to tunnel with LMA.
PMIPv6 is architecturally almost identical to MIPv6,
as the mobility signaling and routing between LMA and MAG in PMIPv6
is similar to those between HA and MN in MIPv6.
The required mobility functionality at the MN is provided by the MAG
so that the involvement in mobility support by the MN is not required.
</t>
<t>
We next describe some practices
that show how network-based mobility protocols
and several other protocol extensions
can be deployed in a distributed mobility management environment.
</t>
<t>
One way to decentralize Proxy Mobile IPv6 operation
can be to deploy several Local Mobility Anchors
and use some selection criteria to assign LMAs to attaching mobile nodes.
An example of this type of assignment is shown in
<xref target="fig-PMIPv6_multiple_LMAs"/>.
As with the client based approach,
a mobile node may use several anchors at the same time,
each of them anchoring IP flows initiated at a different point of attachment.
This assignment can be static or dynamic.
The main advantage of this simple approach is that the IP address anchor,
i.e., the LMA,
could be placed closer to the mobile node.
Therefore the resulting paths are close-to-optimal.
On the other hand, as soon as the mobile node moves,
the resulting path will start deviating from the optimal one.
</t>
<figure anchor="fig-PMIPv6_multiple_LMAs" align="center"
title="Distributed operation of Proxy Mobile IPv6">
<artwork><![CDATA[
<INTERNET> <--- HOME NETWORK ---> <------ ACCESS NETWORK ------->
+--------+ +---+
=======| MAG1 |------|MN1|
+-----+ +-----------+ // |(FM,LMc)| +---+
| CN1 |-------| LMA1 |======= +--------+
+-----+ |(AF,FM,LMs)|
+-----------+ +--------+
+-----+ | MAG2 |
| CN2 |--- |(FM,LMc)|
+-----+ \ +-----------+ +--------+
---| LMA2 |=======
+-----+ |(AF,FM,LMs)| \\ +--------+ +---+
| CN3 | +-----------+ =======| MAG3 |------|MN2|
+-----+ |(FM,LMs)| +---+
+--------+
CN1 CN2 LMA1 LMA2 MAG1 MAG3 MN1 MN2
| | | | | | | |
|<-------------->|<=========================>|<----------->| |
| | | | | | | |
| |<-------------->|<========================>|<----------->|
| | | | | | | |
]]></artwork>
</figure>
<t>
In a similar way to the host-based IP mobility case,
network-based IP mobility has some extensions defined to mitigate the
suboptimal routing issues that may arise due to the use of a centralized
anchor.
The Local Routing extensions <xref target="RFC6705"/> enable optimal
routing in Proxy Mobile IPv6 in three cases: i) when two communicating MNs are
attached to the same MAG and LMA, ii) when two communicating MNs are attached to
different MAGs but to the same LMA, and iii) when two communicating MNs are
attached to the same MAG but have different LMAs. In these three cases, data
traffic between the two mobile nodes does not traverse the LMA(s), thus
providing some form of path optimization since the traffic is locally routed at
the edge. The main disadvantage of this approach is that it only tackles the
MN-to-MN communication scenario, and only under certain circumstances.
</t>
<t>
An interesting extension that can also be used
to facilitate the deployment of network-based mobility protocols
in a distributed mobility management environment
is the support of LMA runtime assignment described in
<xref target="RFC6463"/>.
This extension specifies
a runtime Local Mobility Anchor assignment functionality
and corresponding mobility options for Proxy Mobile IPv6.
This runtime Local
Mobility Anchor assignment takes place
during the Proxy Binding Update
/ Proxy Binding Acknowledgment message exchange
between a mobile access gateway and a local mobility anchor.
While this mechanism is mainly aimed for load-balancing purposes,
it can also be used to select an optimal LMA
from the routing point of view.
A runtime LMA assignment can be used to change the assigned LMA of an MN,
for example,
in cases when the mobile node does not have any active session,
or when the running sessions can survive an IP address change.
Note that several possible dynamic Local Mobility Anchor discovery solutions
can be used,
as described in <xref target="RFC6097"/>.
</t>
</section>
<!-- END 4.2.2. Network-based IP DMM practices -->
</section>
<!-- END 4.2. IP flat wireless network -->
<!-- BEGIN 4.3. flattening 3GPP mobile network approaches-->
<section anchor="sec:3gpp" title="Flattening 3GPP mobile network approaches">
<t>
The 3rd Generation Partnership Project (3GPP)
is the standards development organization
that specifies the 3rd generation mobile network
and the Evolved Packet System (EPS)
<xref target="SDO-3GPP.23.402" />,
which mainly comprises the Evolved Packet Core (EPC) and a
new radio access network, usually referred to as LTE (Long Term Evolution).
</t>
<t>
Architecturally, the 3GPP Evolved Packet Core (EPC) network
is similar to an IP wireless network running PMIPv6 or MIPv6,
as it relies on the Packet Data Network Gateway (PGW) anchoring services
to provide mobile nodes with mobility support
(see <xref target="fig:eps_arch" />).
There are client-based and network-based mobility solutions in 3GPP,
which for simplicity will be analyzed together.
We next describe how 3GPP mobility protocols
and several other completed or ongoing extensions
can be deployed to meet some of the DMM requirements
<xref target="RFC7333" />.
</t>
<figure anchor="fig:eps_arch" title="EPS (non-roaming) architecture
overview" >
<artwork><![CDATA[
+---------------------------------------------------------+
| PCRF |
+-----------+--------------------------+----------------+-+
| | |
+----+ +-----------+------------+ +--------+-----------+ +-+-+
| | | +-+ | | Core Network | | |
| | | +------+ |S|__ | | +--------+ +---+ | | |
| | | |GERAN/|_|G| \ | | | HSS | | | | | |
| +-----+ UTRAN| |S| \ | | +---+----+ | | | | E |
| | | +------+ |N| +-+-+ | | | | | | | x |
| | | +-+ /|MME| | | +---+----+ | | | | t |
| | | +---------+ / +---+ | | | 3GPP | | | | | e |
| +-----+ E-UTRAN |/ | | | AAA | | | | | r |
| | | +---------+\ | | | SERVER | | | | | n |
| | | \ +---+ | | +--------+ | | | | a |
| | | 3GPP AN \|SGW+----- S5---------------+ P | | | l |
| | | +---+ | | | G | | | |
| | +------------------------+ | | W | | | I |
| UE | | | | | | P |
| | +------------------------+ | | +-----+ |
| | |+-------------+ +------+| | | | | | n |
| | || Untrusted +-+ ePDG +-S2b---------------+ | | | e |
| +---+| non-3GPP AN | +------+| | | | | | t |
| | |+-------------+ | | | | | | w |
| | +------------------------+ | | | | | o |
| | | | | | | r |
| | +------------------------+ | | | | | k |
| +---+ Trusted non-3GPP AN +-S2a--------------+ | | | s |
| | +------------------------+ | | | | | |
| | | +-+-+ | | |
| +--------------------------S2c--------------------| | | |
| | | | | |
+----+ +--------------------+ +---+
]]></artwork>
</figure>
<t>
The GPRS Tunneling Protocol (GTP)
<xref target="SDO-3GPP.29.060"/>
<xref target="SDO-3GPP.29.281"/>
<xref target="SDO-3GPP.29.274"/>
is a network-based mobility protocol
specified for 3GPP networks (S2a, S2b, S5 and S8 interfaces).
In a similar way to PMIPv6,
it can handle mobility without requiring the involvement of the mobile nodes.
In this case,
the mobile node functionality is provided
in a proxy manner by the Serving Data Gateway (SGW),
Evolved Packet Data Gateway (ePDG),
or Trusted Wireless Access Gateway
(TWAG <xref target="SDO-3GPP.23.402" />) .
</t>
<t>
3GPP specifications also include client-based mobility support,
based on adopting the use of Dual-Stack Mobile IPv6 (DSMIPv6)
<xref target="RFC5555" />
for the S2c interface <xref target="SDO-3GPP.24.303" />.
In this case,
the User Equipment (UE) implements the binding update functionality,
while the home agent role is played by the PGW.
</t>
<t>
A Local IP Access (LIPA)
and Selected IP Traffic Offload (SIPTO) enabled network
<xref target="SDO-3GPP.23.401" />
allows offloading some IP services at the local access network
above the Radio Access Network (RAN)
without the need to travel back to the PGW
(see <xref target="fig:lipa" />).
</t>
<figure anchor="fig:lipa" title="LIPA scenario">
<artwork><![CDATA[
+---------+ IP traffic to mobile operator's CN
| User |....................................(Operator's CN)
| Equipm. |..................
+---------+ . Local IP traffic
.
+-----------+
|Residential|
|enterprise |
|IP network |
+-----------+
]]></artwork>
</figure>
<t>
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,
by selecting a set of GWs (SGW and PGW)
that are geographically/topologically
close to the UE's point of attachment.
</t>
<figure anchor="fig:sipto" title="SIPTO architecture">
<artwork><![CDATA[
SIPTO Traffic
|
.
.
+-------+ +------+
| L-PGW | ---- | MME |
+-------+ / +------+
| /
+------+ +-----+ +-----+/ +-----+
| UE |.....| eNB |....| SGW |........| PGW |.... CN Traffic
+------+ +-----+ +-----+ +-----+
]]></artwork>
</figure>
<t>
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 residential/enterprise IP network
without traversing the mobile operator's network core in the user plane.
In order to achieve this,
a Local GW (LGW) collocated with the HeNB is used.
LIPA is established by the UE
requesting a new Public Data Network (PDN) connection
to an access point name for which LIPA is permitted,
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.
</t>
<figure anchor="fig:lipa_arch" title="LIPA architecture">
<artwork><![CDATA[
+---------------+------+ +----------+ +-------------+ =====
|Residential | | HeNB | | Backhaul | |Mobile | ( IP )
|Enterprise |..|------|..| |..|Operator |..(Network)
|Network | | LGW | | | |Core network | =======
+---------------+------+ +----------+ +-------------+
/
|
/
+-----+
| UE |
+-----+
]]></artwork>
</figure>
<t>
The 3GPP architecture specifications
also provide mechanisms to allow discovery and selection of gateways
<xref target="SDO-3GPP.29.303" />.
These mechanisms enable decisions
taking into consideration topological location
and gateway collocation aspects,
relying upon the DNS as a "location database."
</t>
<t>
Both SIPTO and LIPA have a very limited mobility support,
especially in 3GPP specifications up to Rel-12.
Briefly,
LIPA mobility support is limited to handovers between HeNBs
that are managed by the same LGW
(i.e., mobility within the local domain).
There is no guarantee of IP session continuity for SIPTO.
</t>
</section>
<!-- END 4.3. Flattening 3GPP mobile network approaches -->
</section>
<!-- END 4. DMM practices -->
<!-- BEGIN 5: Gap analysis -->
<section anchor="sec:gap" title="Gap analysis">
<t>
This section identifies the limitations in the current practices,
described in <xref target="sec:practices" />,
with respect to the DMM requirements listed in <xref target="RFC7333" />.
</t>
<!-- BEGIN 5.1: GAP1:
Distributed mobility management -->
<section anchor="sec:req1"
title="
Distributed mobility management
- REQ1
">
<t>
According to requirement REQ1 stated in
<xref target="RFC7333" />,
IP mobility,
network access and forwarding solutions provided by DMM
must make it possible for traffic
to avoid traversing a single mobility anchor far from the optimal route.
</t>
<t>
From the analysis performed in <xref target="sec:practices"/>,
a DMM deployment can meet the requirement
"REQ1 Distributed mobility management"
usually relying on the following functions:
<list style="symbols">
<t>
Multiple (distributed) anchoring:
ability to anchor different sessions
of a single mobile node at different anchors.
In order to provide improved routing,
some anchors might need to be placed
closer to the mobile node or the corresponding node.
</t>
<t>
Dynamic anchor assignment/re-location:
ability to
i) assign the initial anchor, and
ii) dynamically change the initially assigned anchor
and/or assign a new one
(this may also require the transfer of mobility context between anchors).
This can be achieved
either by changing anchor for all ongoing sessions
or by assigning new anchors just for new sessions.
</t>
</list>
</t>
<t>
<list style="format GAP1-%d:" counter="G1_count">
<t>
Both the main client- and network-based IP mobility protocols,
namely (DS)MIPv6 and PMIPv6 allow deploying multiple anchors
(i.e., home agents and localized mobility anchors),
thereby providing the multiple anchoring function.
However,
existing solutions only provide an initial anchor assignment,
thus the lack of dynamic anchor change/new anchor assignment is a gap.
Neither the HA switch nor the LMA runtime assignment
allows changing the anchor during an ongoing session.
This actually comprises several gaps:
ability to perform anchor assignment at any time
(not only at the initial MN's attachment),
ability of the current anchor to initiate/trigger the relocation,
and ability to transfer registration context between anchors.
</t>
<t>
Dynamic anchor assignment may lead the MN
to manage different mobility sessions
served by different mobility anchors.
This is not an issue with client based mobility management
where the mobility client natively knows the anchor
associated with each of its mobility sessions.
However, there is one gap,
as the MN should be capable of handling IP addresses in a DMM-friendly way,
meaning that the MN can perform smart source address selection
(i.e., deprecating IP addresses from previous mobility anchors,
so they are not used for new sessions).
Besides,
managing different mobility sessions served by different mobility anchors
may raise issues with network based mobility management.
In this case, the mobile client located in the network, e.g., MAG,
usually retrieves the MN's anchor from the MN's policy profile
as described in Section 6.2 of <xref target="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.
</t>
<t>
The consequence of the distribution of the mobility anchors
is that there might be more than one available anchor
for a mobile node to use,
which leads to an anchor discovery and selection issue.
Currently, there is no efficient mechanism specified
to allow the dynamic discovery of the presence of nodes
that can play the anchor role,
discovering their capabilities and selecting the most suitable one.
There is also no mechanism to allow selecting a node
that is currently anchoring a given home address/prefix
(capability sometimes required to meet REQ#2).
However, there are some mechanisms that could help to discover anchors,
such as the Dynamic Home Agent Address Discovery (DHAAD)
<xref target="RFC6275"/>,
the use of the home agent flag (H) in Router Advertisements
(which indicates that the router sending the Router Advertisement
is also functioning as a Mobile IPv6 home agent on the link)
or the MAP option in Router Advertisements defined by HMIPv6.
Note that there are 3GPP mechanisms providing that functionality
defined in
<xref target="SDO-3GPP.29.303" />.
</t>
</list>
</t>
<t>
Regarding the ability to transfer registration context between anchors, there
are already some solutions that could be reused or adapted to fill that gap,
such as Fast Handovers for Mobile IPv6 <xref target="RFC5568" /> -- to enable
traffic redirection from the old to the new anchor --, the Context Transfer
protocol <xref target="RFC4067" /> -- to enable the required transfer of
registration information between anchors --, or the Handover Keying architecture
solutions <xref target="RFC6697" />, to speed up the re-authentication process
after a change of anchor. Note that some extensions might be needed in the
context of DMM, as these protocols were designed in the context of centralized
client IP mobility, focusing on the access re-attachment and authentication.
</t>
<t>
<list style="format GAP1-%d:" counter="G1_count">
<t>
Also note that REQ1 is intended to prevent the data plane traffic
from taking a suboptimal route.
Distributed processing of the traffic may then be
needed only in the data plane.
Provision of this capability for distributed processing
should not conflict with the use of a centralized control plane.
Other control plane solutions such as charging,
lawful interception, etc.
should not be constrained by the DMM solution.
On the other hand
combining the control plane
and data plane forwarding management (FM) function
may limit the choice of solutions
to those that distribute both data plane and control plane 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.
</t>
</list>
</t>
</section>
<!-- END 5.1: GAP1 - Distributed processing -->
<!-- BEGIN 5.2: GAP2:
Bypassable network-layer mobility support for each application session -->
<section anchor="sec:req2"
title="
Bypassable network-layer mobility support for each application session
- REQ2
">
<t>
The requirement REQ2 for
"bypassable network-layer mobility support for each application session"
introduced in <xref target="RFC7333" />
requires flexibility in determining
whether network-layer mobility support is needed.
This requirement enables one to choose
whether or not to use network-layer mobility support.
The following two functions are also needed:
<list style="symbols">
<t>
Dynamically assign/relocate anchor: a mobility anchor is assigned only to
sessions which use the network-layer mobility support. 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 local IP address(es).
</t>
<t>
Multiple IP address management: this function is related to the preceding and is
about the ability of the mobile node to simultaneously use multiple IP addresses
and select the best one (from an anchoring point of view) to use on a
per-session/application/service basis. This requires MN to acquire information
regarding the properties of the available IP addresses.
</t>
</list>
</t>
<t>
<list style="format GAP2-%d:" counter="G2_count">
<t>
The dynamic anchor assignment/relocation needs to ensure
that IP address continuity is guaranteed
for sessions that uses such mobility support
(e.g., in some scenarios,
the provision of mobility locally within a limited area
might be enough from the mobile node or the application point of view)
at the relocated anchor.
Implicitly,
when no applications are using the network-layer mobility support,
DMM may release the needed resources.
This may imply having the knowledge of
which sessions at the mobile node are active
and are using the mobility support.
This is something typically known only by the MN,
e.g., by its connection manager,
and would also typically require some signaling support
such as socket API extensions
from 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.
</t>
<t>
Multiple IP address management
provides the MN with the choice to pick the correct address,
e.g., from those provided or not provided with mobility support,
depending on the application requirements.
When using client based mobility management,
the mobile node is itself aware of the anchoring capabilities
of its assigned IP addresses.
This is not necessarily the case with network based IP mobility management;
current mechanisms do not allow the MN to be aware of the properties
of its IP addresses.
For example, the MN does not know
whether the allocated IP addresses are anchored.
However, there are proposals, such as
<xref target="I-D.bhandari-dhc-class-based-prefix"/>,
<xref target="I-D.korhonen-6man-prefix-properties"/> and
<xref target="I-D.anipko-mif-mpvd-arch" />
that the network could indicate 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.
</t>
<t>
The handling of mobility management
to the granularity of an individual session of a user/device
needs proper session identification
in addition to user/device identification.
</t>
</list>
</t>
</section>
<!-- END 5.2: GAP2 - Bypassable network-layer mobility support -->
<!-- BEGIN 5.3: GAP3:
IPv6 deployment -->
<section anchor="sec:req3"
title="
IPv6 deployment
- REQ3
">
<t>
This requirement states that DMM solutions should primarily target IPv6
as the primary deployment environment.
IPv4 support is not considered mandatory and
solutions should not be tailored specifically to support IPv4.
</t>
<t>
All analyzed DMM practices support IPv6.
Some of them, such as MIPv6/NEMO
including the support of dynamic HA selection,
MOBIKE,
SIPTO also have IPv4 support.
Some solutions, e.g., PMIPv6,
also have some limited IPv4 support.
In conclusion, this requirement is met by existing DMM practices.
</t>
</section>
<!-- END 5.3: GAP3 - deployment -->
<!-- BEGIN 5.4: GAP4:
Considering existing mobility protocols -->
<section anchor="sec:req4"
title="
Considering existing mobility protocols
- REQ4
">
<t>
A DMM solution must first consider reusing and extending IETF-standardized
protocols before specifying new protocols.
</t>
<t>
As stated in <xref target="RFC7333" />, a DMM solution could
reuse existing IETF and standardized protocols before specifying new protocols.
Besides, <xref target="sec:practices" /> of this document discusses various ways
to flatten and distribute current mobility solutions.
Actually, nothing prevents the distribution of mobility functions
within IP mobility protocols.
However, as discussed in <xref target="sec:req1" /> and
<xref target="sec:req2" />, limitations exist.
</t>
<t>
The 3GPP data plane anchoring function, i.e., the PGW,
can also be distributed, but with limitations;
e.g., no anchoring relocation,
no context transfer between anchors and centralized control plane.
The 3GPP architecture
is also going in the direction of flattening with SIPTO and LIPA,
though they do not provide full mobility support.
For example, mobility support for SIPTO traffic can be rather limited,
and offloaded traffic cannot access operator services.
Thus, the operator must be very careful
in selecting which traffic to offload.
</t>
</section>
<!-- END 5.4: GAP4 - Existing mobility protocols -->
<!-- BEGIN 5.5: GAP5:
Coexistence with deployed networks/hosts
and operability across different networks -->
<section anchor="sec:req5"
title="
Coexistence with deployed networks/hosts
and operability across different networks
- REQ5
">
<t>
According to <xref target="RFC7333" />, DMM implementations
are required to co-exist with existing network deployments, end hosts and
routers. Additionally, DMM solutions are expected to work across different
networks, possibly operated as separate administrative domains,
when the necessary mobility management signaling,
forwarding,
and network access are allowed by the trust relationship between them.
All current mobility protocols can co-exist
with existing network deployments and end hosts.
There is no gap between existing mobility protocols and this requirement.
</t>
</section>
<!-- END 5.5: GAP5 - Co-existence -->
<!-- BEGIN 5.6: GAP6:
Operation and management considerations -->
<section anchor="sec:req6"
title="
Operation and management considerations
- REQ6
">
<t>
This requirement actually comprises several aspects, as summarized below.
<list style="symbols">
<t>
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.
</t>
<t>
A DMM solution has to describe in what environment and how it can be scalably
deployed and managed.
</t>
<t>
A DMM solution has to support mechanisms to test if the DMM solution is
working properly.
</t>
<t>
A DMM solution is expected to expose the operational state of DMM to the
administrators of the DMM entities.
</t>
<t>
A DMM solution, which supports flow mobility, is also expected to support means
to correlate the flow routing policies and the observed forwarding actions.
</t>
<t>
A DMM solution is expected to support mechanisms to check the liveness of
the forwarding path.
</t>
<t>
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.
</t>
<t>
A DMM solution is expected to be able to monitor the usage of the DMM protocol.
</t>
<t>
DMM solutions have to support standardized configuration with NETCONF
<xref target="RFC6241"/>, using YANG <xref target="RFC6020"/> modules, which
are expected to be created for DMM when needed for such configuration.
</t>
</list>
</t>
<t>
<list style="format GAP6-%d:" counter="G6_count">
<t>
Existing mobility management protocols have not thoroughly documented
how, or whether, they support the above list
of operation and management considerations.
Each of the above needs to be considered
from the beginning in a DMM solution.
</t>
<t>
Management information base (MIB) objects are currently defined in
<xref target="RFC4295"/> for MIPv6 and in <xref target="RFC6475"/> for PMIPv6.
Standardized configuration with NETCONF <xref target="RFC6241"/>, using YANG
<xref target="RFC6020"/> modules is lacking.
</t>
</list>
</t>
</section>
<!-- END 5.6: GAP6 - Operation and management considerations -->
<!-- BEGIN 5.7: GAP7:
Security considerations -->
<section anchor="sec:req7"
title="
Security considerations
- REQ7
">
<t>
As stated in <xref target="RFC7333" />, a DMM solution has to
support any security protocols and mechanisms
needed to secure the network and to make continuous security improvements.
In addition, with security taken into consideration early in the design,
a DMM solution cannot introduce new security risks,
or amplify existing security risks,
that cannot be mitigated by existing security protocols and mechanisms.
</t>
<t>
Any solutions that are intended to fill in gaps
identified in this document need to meet this requirement.
At present,
it does not appear that using existing solutions to support DMM
has introduced any new security issues.
For example,
Mobile IPv6 defines security features to protect binding updates
both to home agents and 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.
</t>
</section>
<!-- END 5.7: GAP7 - Security considerations -->
<!-- BEGIN 5.8: GAP8:
Multicast -->
<section anchor="sec:req8"
title="
Multicast
- REQ8
">
<t>
It is stated in <xref target="RFC7333" /> that DMM solutions
are expected to allow the development of multicast solutions
to avoid network inefficiency in multicast traffic delivery.
</t>
<t>
Current IP mobility solutions
address mainly the mobility problem for unicast traffic.
Solutions relying on the use of an anchor point
for tunneling multicast traffic down to the access router,
or to the mobile node,
introduce the
so-called "tunnel convergence problem."
This means that multiple instances of the same multicast traffic
can converge to the same node,
diminishing the advantage of using multicast protocols.
</t>
<t>
<xref target="RFC6224"/> documents a baseline solution for the previous issue,
and <xref target="RFC7028"/> a routing optimization solution. The baseline
solution suggests deploying a Multicast Listener Discovery (MLD) proxy function at the MAG, and either a
multicast router or another MLD proxy function at the LMA. The routing
optimization solution describes an architecture where a dedicated multicast tree
mobility anchor or a direct routing option can be used to avoid the
tunnel convergence problem.
</t>
<t>
Besides the solutions highlighted before, there are no other mechanisms for
mobility protocols to address the multicast tunnel convergence problem.
</t>
</section>
<!-- END 5.8: GAP8 - Multicast -->
<!-- BEGIN 5.9: Summary -->
<section anchor="sec:req_summary" title="Summary">
<t>
We next list the main gaps identified from the analysis performed above:
<list style="format GAP1-%d:" counter="S1_count">
<t>
Existing solutions only provide an optimal initial anchor assignment,
a gap being the lack of dynamic anchor change/new anchor assignment.
Neither the HA switch nor the LMA runtime assignment
allows changing the anchor during an ongoing session.
MOBIKE allows change of GW
but its applicability has been scoped to a very narrow use case.
</t>
<t>
The MN needs to be able to perform source address selection.
Proper mechanism to inform the MN is lacking
to provide the basis for the proper selection.
</t>
<t>
Currently, there is no efficient mechanism specified by the IETF
that allows the dynamic discovery
of the presence of nodes that can play the role of anchor,
discover their capabilities and allow the selection of the most suitable one.
However, the following mechanisms could help discovering anchors:
<vspace blankLines="1" />
Dynamic Home Agent Address Discovery (DHAAD):
the use of the home agent (H) flag
in Router Advertisements (which indicates that the router sending the Router
Advertisement is also functioning as a Mobile IPv6 home agent on the link) and
the MAP option in Router Advertisements defined by HMIPv6.
</t>
<t>
While existing network-based DMM practices
may allow the deployment of multiple LMAs
and dynamically select the best one,
this requires to still keep some centralization in the control plane,
to access the policy database (as defined in RFC5213).
Although <xref target="I-D.ietf-netext-pmip-cp-up-separation"/>
allows a MAG to perform splitting of its control and user planes,
there is a lack of solutions/extensions
that support a clear control and data plane separation
for IETF IP mobility protocols in a DMM context.
</t>
</list>
<list style="format GAP2-%d:" counter="S2_count">
<t>
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.
</t>
<t>
The mobile node needs to simultaneously use multiple IP addresses
with different properties.
There is a lack of mechanism
to expose this information to the mobile node
which can then update accordingly its source address selection mechanism.
</t>
<t>
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.
</t>
</list>
<list style="format GAP6-%d:" counter="S6_count">
<t>
Mobility management protocols have not thoroughly documented
how, or whether, they support the following list
of operation and management considerations:
<list style="symbols">
<t>
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.
</t>
<t>
A DMM solution has to describe in what environment and how it can be scalably
deployed and managed.
</t>
<t>
A DMM solution has to support mechanisms to test if the DMM solution is
working properly.
</t>
<t>
A DMM solution is expected to expose the operational state of DMM to the
administrators of the DMM entities.
</t>
<t>
A DMM solution, which supports flow mobility, is also expected to support means
to correlate the flow routing policies and the observed forwarding actions.
</t>
<t>
A DMM solution is expected to support mechanisms to check the liveness of
the forwarding path.
</t>
<t>
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.
</t>
<t>
A DMM solution is expected to be able to monitor the usage of the DMM protocol.
</t>
<t>
DMM solutions have to support standardized configuration with NETCONF
<xref target="RFC6241"/>, using YANG <xref target="RFC6020"/> modules, which
are expected to be created for DMM when needed for such configuration.
</t>
</list>
</t>
<t>
Management information base (MIB) objects are currently defined in
<xref target="RFC4295"/> for MIPv6 and in <xref target="RFC6475"/> for PMIPv6.
Standardized configuration with NETCONF <xref target="RFC6241"/>, using YANG
<xref target="RFC6020"/> modules is lacking.
</t>
</list>
</t>
</section>
<!-- END 5.9: Summary -->
</section>
<!-- END 5. Gap analysis -->
<!-- BEGIN 6. Security Considerations -->
<section anchor="sec:security" title="Security Considerations">
<t>
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.
</t>
</section>
<!-- END 6. Security Considerations -->
<section title="Contributors">
<t>This document has benefited
to valuable contributions from
<figure><artwork><![CDATA[
Charles E. Perkins
Huawei Technologies
EMail: charliep@computer.org
]]></artwork></figure>
who had produced a matrix to compare the different mobility protocols and extensions
against a list of desired DMM properties.
They were useful inputs in the early work of gap analysis.
He had continued to give suggestions
as well as extensive review comments to this documents.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<!-- &RFC2119; -->
&RFC7333;
</references>
<references title="Informative References">
&RFC4295;
&RFC6020;
&RFC6241;
&RFC6475;
&RFC6275;
&RFC5213;
&RFC5555;
&RFC5844;
&RFC3963;
&RFC4640;
&RFC5026;
&RFC6611;
&RFC4225;
&RFC5380;
&RFC5142;
&RFC6705;
&RFC6463;
&RFC4555;
&RFC5996;
&RFC5014;
&RFC6224;
&RFC7028;
&RFC4889;
&RFC4066;
&RFC4067;
&RFC5568;
&RFC6697;
&RFC6097;
&RFC4960;
&RFC6724;
&I-D.gundavelli-v6ops-community-wifi-svcs;
&I-D.bhandari-dhc-class-based-prefix;
&I-D.korhonen-6man-prefix-properties;
&I-D.anipko-mif-mpvd-arch;
&I-D.ietf-netext-pmip-cp-up-separation;
&TS29060;
&TR29281;
&TS29274;
&TS23401;
&TS23402;
&TS29303;
<reference anchor="IEEE.802-16.2009"
target="http://standards.ieee.org/getieee802/download/802.16-2009.pdf">
<front>
<title>
IEEE Standard for Local and metropolitan area networks Part 16: Air Interface
for Broadband Wireless Access Systems
</title>
<author>
<organization/>
</author>
<date month="" year="2009"/>
</front>
<seriesInfo name="IEEE" value="Standard 802.16"/>
</reference>
<reference anchor="SDO-3GPP.24.303">
<front>
<title>
Mobility management based on Dual-Stack Mobile IPv6; Stage 3
</title>
<author>
<organization>3GPP</organization>
</author>
<date day="27" month="June" year="2013"/>
</front>
<seriesInfo name="3GPP TS" value="24.303 10.0.0"/>
<format type="HTML" target="http://www.3gpp.org/ftp/Specs/html-info/24303.htm"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:26:52 |