One document matched: draft-ietf-dmm-best-practices-gap-analysis-04.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC6275 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6275.xml">
<!ENTITY RFC5213 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5213.xml">
<!ENTITY RFC5555 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5555.xml">
<!ENTITY RFC5844 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5844.xml">
<!ENTITY RFC3963 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3963.xml">
<!ENTITY RFC4640 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4640.xml">
<!ENTITY RFC5026 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5026.xml">
<!ENTITY RFC6611 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6611.xml">
<!ENTITY RFC4225 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4225.xml">
<!ENTITY RFC5380 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5380.xml">
<!ENTITY RFC5142 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5142.xml">
<!ENTITY RFC6705 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6705.xml">
<!ENTITY RFC6463 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6463.xml">
<!ENTITY RFC6097 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6097.xml">
<!ENTITY RFC4555 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4555.xml">
<!ENTITY RFC5996 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5996.xml">
<!ENTITY RFC5014 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5014.xml">
<!ENTITY RFC6224 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6224.xml">
<!ENTITY RFC7028 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7028.xml">
<!ENTITY RFC4889 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4889.xml">
<!ENTITY RFC5568 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5568.xml">
<!ENTITY RFC4066 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4066.xml">
<!ENTITY RFC4067 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4067.xml">
<!ENTITY I-D.ietf-dmm-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dmm-requirements.xml">
<!ENTITY I-D.gundavelli-v6ops-community-wifi-svcs SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.gundavelli-v6ops-community-wifi-svcs">
<!ENTITY I-D.bhandari-dhc-class-based-prefix SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bhandari-dhc-class-based-prefix.xml">
<!ENTITY I-D.korhonen-6man-prefix-properties SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.korhonen-6man-prefix-properties.xml">
<!ENTITY I-D.anipko-mif-mpvd-arch SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.anipko-mif-mpvd-arch.xml">
<!ENTITY I-D.ietf-netext-pmip-cp-up-separation SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netext-pmip-cp-up-separation.xml">
<!ENTITY TS29060 SYSTEM "http://xml.resource.org/public/rfc/bibxml5/reference.SDO-3GPP.29.060.xml">
<!ENTITY TS23859 SYSTEM "http://xml.resource.org/public/rfc/bibxml5/reference.SDO-3GPP.23.859.xml">
<!ENTITY TR29281 SYSTEM "http://xml.resource.org/public/rfc/bibxml5/reference.SDO-3GPP.29.281.xml">
<!ENTITY TS29274 SYSTEM "http://xml.resource.org/public/rfc/bibxml5/reference.SDO-3GPP.29.274.xml">
<!ENTITY TS23402 SYSTEM "http://xml.resource.org/public/rfc/bibxml5/reference.SDO-3GPP.23.402.xml">
<!ENTITY TS23401 SYSTEM "http://xml.resource.org/public/rfc/bibxml5/reference.SDO-3GPP.23.401.xml">
<!ENTITY TS29303 SYSTEM "http://xml.resource.org/public/rfc/bibxml5/reference.SDO-3GPP.29.303.xml">
]>
<?rfc strict="yes"?>
<!-- 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-04">
<!-- 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="May" 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 -->
The present 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>
The distributed mobility management (DMM) WG has studied the problems of
centralized deployment of mobility management protocols and specified
the DMM requirements <xref target="I-D.ietf-dmm-requirements" />.
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.
It discusses current deployment practices of existing mobility protocols
and identifies the limitations (gaps) in these practices
from the standpoint of satisfying DMM requirements, as defined in
<xref target="I-D.ietf-dmm-requirements" />.
</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-based 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" /> and
in the Proxy mobile IPv6 specification <xref target="RFC5213" />. These terms
include mobile node (MN), correspondent node (CN), home agent (HA), local
mobility anchor (LMA), and mobile access gateway (MAG).
</t>
<t>
In addition, this document also introduces some definitions of IP mobility
functions in <xref target="sec:mobility_mngnt_functions" />.
<!--
<list style='hanging'>
<t hangText='Mobility routing (MR)'>
is the logical function that intercepts packets to/from the IP address/prefix
advertised to the mobile node and forwards them, based on internetwork location
information, either directly towards their destination or to some other network
element that knows how to forward the packets to their ultimate destination.
<vspace blankLines="1" />
</t>
<t hangText='Home address allocation'>
is the logical function that allocates the IP address/prefix (e.g., home address
or home network prefix) to a mobile node.
<vspace blankLines="1" />
</t>
<t hangText='Location management (LM)'>
is the logical function that manages and keeps track of the internetwork
location information of a mobile node, which includes the mapping of the IP
address/prefix delegated to the MN to the MN routing address or another network
element that knows where to forward packets destined for the MN.
<vspace blankLines="1" />
</t>
<t hangText='Home network of an application session (or an HoA IP
address)'>
is the network that has allocated the IP address used as the session identifier
(home address) by the application being run in an MN. The MN may be attached to
more than one home networks.
<vspace blankLines="1" />
</t>
<t hangText='Hierarchical mobile network'>
has a hierarchy of network elements arranged into multiple
hierarchical levels which are introduced into the data path by the
mobility management system.
<vspace blankLines="1" />
</t>
<t hangText='Flattening mobile network'>
refers to the hierarchical mobile network which is going through
the trend of reducing its number of hierarchical levels.
<vspace blankLines="1" />
</t>
<t hangText='Flatter mobile network'>
has fewer hierarchical levels compared to a hierarchical mobile
network.
<vspace blankLines="1" />
</t>
</list>
-->
</t>
<!-- Carlos: this addresses a comment that Kostas has made several times -->
<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 the reliance on centrally
deployed 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>
description of mobility functions that will be used to give practices (e.g.
traffic anchoring, address allocation, location update, traffic
redirection,...).
</t>
<t>
this section should include less detail than draft- liu, but more than
draft-zuniga (section 4.2). We would need to work out something in-between the
content of the two.
</t>
-->
<t>
Host-based Mobile IPv6 <xref target="RFC6275"/>, its network-based
extension, PMIPv6 <xref target="RFC5213"/>, and HMIPv6
<xref target="RFC5380"/> are all logically centralized mobility
management approaches that primarily address hierarchical mobile
networks. Although they are centralized approaches, 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
(a Home Address (HoA)) or prefix (a Home Network Prefix (HNP)) topologically anchored by the
advertising node (i.e., the anchor node is able to advertise a connected route
into the routing infrastructure for the allocated IP prefixes).
It is a control plane function.
<vspace blankLines="1" />
</t>
<t>
Internetwork Location Management (LM) function: managing and keeping track of the internetwork location of an MN.
The location information may be a mapping of the IP 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 the client (LMc) and the server (LMs).
<vspace blankLines="1" />
</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).
<vspace blankLines="1" />
</t>
</list>
</t>
<t>
In Mobile IPv6, the home agent (HA) typically provides the anchoring function (AF);
the location management server (LMs) is at the HA while the location management client (LMc) is at the MN; the forwarding management (FM) function is both ends of tunneling at the HA and the MN.
</t>
<t>
In Proxy Mobile IPv6, the Local Mobility Anchor (LMA) provides the anchoring function (AF);
the location management server (LMs) is at the LMA while the location management client (LMc) is at the mobile access gateway (MAG);
the forwarding management (FM) function is both ends of tunneling at the HA and the MAG.
</t>
<t>
In Hirarchical mobile IPv6 (HMIPv6) <xref target="RFC5380"/>,
the mobility anchor point (MAP) serves as a location management
aggregator between the LMs at the HA and the LMc at the MN.
The MAP also has 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 Architecture flattening approaches(i.e. fewer levels
of routing hierarchy introduced into the data path by the mobility
management system).
</t>
<t>
While describing the current DMM practices, references to the generic mobility
management functions described in <xref target="sec:mobility_mngnt_functions" />
are provided, as well as some initial hints on the identified gaps with respect
to the DMM requirements documented in
<xref target="I-D.ietf-dmm-requirements" />.
</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-based and network-based solutions should be 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 SCTP or
application-layer mobility.
</t>
<!--
<t>
Mobility management and traffic redirection SHOULD only be triggered due to IP
mobility reasons. Mobility management and traffic redirection operations are
first called when the MN moves from the point of attachment where the IP flow
was originally initiated (i.e., the topological anchor of the MN's IP address,
for example an HA/LMA). Then, every time the MN changes access point/router
(i.e., changes locator/CoA), required mobility operations are also performed.
</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
[RFC-SourceAddrSelection].
</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 )
+-----+ +-----+ *---------*
. / \ / \
/ \ +-----+ +-----+ +-----+ +-----+
MN MN |Wi-Fi| |Wi-Fi| |Wi-Fi| |Wi-Fi|
| AP | | AP | | AP | | AP |
+-----+ +-----+ +-----+ +-----+
. .
/ \ / \
MN MN MN MN
]]></artwork>
</figure>
<t>
In the figure, 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 directly connect to a Residential Gateway (RG) which is
a network device at the customer premises and provides both
wireless layer-2 access connectivity (i.e., it hosts the 802.11 Access Point
function) and layer-3 routing functions. In the middle of the figure, mobile
nodes connect to Wi-Fi Access Points (APs) that are managed by a WLAN 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 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 inter-access mobility
support to users, e.g. handover from Wi-Fi to cellular access. Two kinds
of protocols can be used: Proxy Mobile IPv6 <xref target="RFC5213" />
or Mobile IPv6 <xref target="RFC5555" />, with the mobility anchor
(e.g., local mobility anchor or home agent) role 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 IP flat wireless network architectures specified, such as WiMAX
<xref target="IEEE.802-16.2009" />, which integrates both host and
network-based IP mobility functionality.
</t>
<t>
Existing IP mobility protocols can also be deployed in a more flattened 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-based or network-based, such as Mobile IPv6 <xref target="RFC6275" />,
<xref target="RFC5555" />, Proxy Mobile IPv6 <xref target="RFC5213" />, <xref
target="RFC5844" /> and NEMO <xref target="RFC3963" />. Extensions to these base
protocol solutions are also considered.
The analysis is divided into two parts: host-based 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 upon 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 Management server (LMs) functions.
The mobile node possesses the Location management client (LMc) 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"/>, MN1 is assigned HA1 (and a home address
anchored by HA1), while MN2 is assigned HA2. Note that MIPv6/NEMO
specifications do not prevent the simultaneous use of multiple home agents by a
single mobile node. This deployment model could be exploited by a mobile node
to meet assumption #4 of <xref target="sec:assumptions" /> and use several
anchors at the same time,
each of them anchoring IP flows initiated at a different point of attachment.
However there is no mechanism specified by IETF to
enable an efficient dynamic discovery of available anchors and the selection of
the most suitable one. Note that some of these mechanisms <xref target="SDO-3GPP.23.402"/> have been defined
outside IETF.
</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 |-(o) zzzz (o)
------- | HA1 | ------- |
------- (MN1 anchored at HA1) -------
------- | MN1 |
| AR2 |-(o) -------
-------
-------
| HA2 | -------
------- | AR3 |-(o) zzzz (o)
------- |
------- (MN2 anchored at HA2) -------
| CN2 | ------- | MN2 |
------- | AR4 |-(o) -------
-------
CN1 CN2 HA1 HA2 AR1 MN1 AR3 MN2
| | | | | | | |
|<------------>|<=================+=====>| | | BT mode
| | | | | | | |
| |<----------------------------------------+----->| RO mode
| | | | | | | |
]]></artwork>
</figure>
<t>
Since one of the goals of the deployment of mobility protocols in a distributed
mobility management environment is to avoid the suboptimal routing caused by
centralized anchoring, the Route Optimization (RO) support provided by Mobile
IPv6 can also 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 Route Optimization (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 and 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"/> and, thus, the HA remains a single point of failure.
</t>
<t>
The RO mode requires support from the correspondent node (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 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 reducing the amount of mobility
signaling as well as improving the overall handover performance of Mobile IPv6
by introducing a new hierarchy level to handle local mobility. The Mobility
Anchor Point (MAP) entity is introduced as a local mobility handling node
deployed closer to the mobile node.
It provides LM intermediary function between the LM server (LMs) at the HA and the LM client (LMc) at the MN.
It also performs the FM function using tunneling with the HA and also to tunnel with the MN.
</t>
<figure anchor="fig-MIPv6_HMIPv6" title="Hierarchical Mobile IPv6"
align="center">
<artwork><![CDATA[
<- 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
| | | | ________|__________ |
|<------------------>|<==============>|<________+__________>| 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, that 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. 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 (e.g., flat and distributed).
The HMIPv6
specification supports a flexible selection of the MAP (e.g., based on the
distance between the MN and the MAP, taking into consideration the expected
mobility pattern of the MN, etc.).
</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 within IETF 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>
IETF has defined extensions to the mobility protocol to optimize the handover performance.
Mobile IPv6 Fast Handovers(FMIP) <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.
IETF seamoby working group alos has published Candidate Access Router Discovery(CARD) <xref target="RFC4066"/>
and Context Transfer Protocol (CXTP) <xref target="RFC4067"/> to improve the handover
performance. The DMM deployment pratice discussed in this section can also use
thoes 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, internetwork Location Management server (LMs) function
and RM function.
The mobile access gateway (MAG) provides the Location Management client (LMc) 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 NET -><----------- ACCESS NETWORK ------------>
-------
| CN1 | -------- -------- --------
------- -------- | MAG1 | | MAG2 | | MAG3 |
| LMA1 | ---+---- ---+---- ---+----
------- -------- | | |
| CN2 | (o) (o) (o)
------- -------- x x
| LMA2 | x x
------- -------- (o) (o)
| CN3 | | |
------- ---+--- ---+---
Anchored | MN1 | Anchored | MN2 |
at LMA1 -> ------- at LMA2 -> -------
CN1 CN2 LMA1 LMA2 MAG1 MN1 MAG3 MN2
| | | | | | | |
|<------------>|<================>|<---->| | |
| | | | | | | |
| |<------------>|<========================>|<----->|
| | | | | | | |
]]></artwork>
</figure>
<t>
Similar 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 LMA runtime assignment <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. 3GPP network flattening approaches-->
<section anchor="sec:3gpp" title="3GPP network flattening 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), 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
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="I-D.ietf-dmm-requirements"/>.
</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 Tunnelling 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). Similar 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).
</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. 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) or at the macro,
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 |····| S-GW |········| P-GW |···> 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 (L-GW) collocated with the HeNB is used. LIPA
is established by the UE requesting a new PDN (Public Data Network) 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 | |H(e)NB | | Backhaul | |Mobile | ( IP )
|Enterprise |..|-------|..| |..|Operator |..(Network)
|Network | |L-GW | | | |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, specially in 3GPP
specifications up to Rel-12. Briefly, LIPA mobility support is limited to
handovers between HeNBs that are managed by the same L-GW (i.e., mobility within
the local domain), while seamless mobility is not supported when SIPTO is
performed at or near the RAN level.
</t>
</section>
<!-- END 4.3. 3GPP network flattening approaches -->
</section>
<!-- END 4. DMM practices -->
<!-- BEGIN 5: Gap analysis -->
<section anchor="sec:gap" title="Gap analysis">
<t>
The goal of this section is to identify the limitations in the current
practices, described in <xref target="sec:practices" />, with respect to the
DMM requirements listed in <xref target="I-D.ietf-dmm-requirements" />.
</t>
<!-- BEGIN 5.1: Distributed processing - REQ1 -->
<section anchor="sec:req1" title="Distributed processing - REQ1">
<t>
According to requirement #1 stated in
<xref target="I-D.ietf-dmm-requirements"/>, IP mobility, network access and
routing solutions provided by DMM must enable distributed processing for
mobility management so that traffic can avoid traversing 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 "REQ#1 Distributed processing" 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.
</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 to transfer 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>
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), therefore 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 allow 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 each anchor
associated to each 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 (e.g., 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 by IETF to allow dynamically discovering 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). There are though some mechanisms
that could help discovering anchors, such as the Dynamic Home Agent Address
Discovery (DHAAD), the use of the Home Agent (H) flag in Router Advertisements
(which indicates that the router sending the Router Advertisement is also
functioning as a Mobile IPv6 home agent on the link) or the MAP option in Router
Advertisements defined by HMIPv6. Note that there are 3GPP mechanisms providing
that functionality defined in <xref target="SDO-3GPP.29.303" />.
</t>
<t>
Also note that REQ1 is such that the data plane traffic can avoid suboptimal route.
Distributed processing of the traffic is then needed only in the data plane.
The needed capability in distributed processing therefore
should not contradict with centralized control plane.
Other control plane solutions such as charging, lawful interception, etc.
should not be limited.
Yet combining the control plane and data plane forwarding management (FM) function
may limit the choice to distributing boht data plane and control plane together.
In order to enable distributing only the data plane without distributing the control plane,
a gap is to split the forwarding management function into the control plane (FM-CP) and data plane (FM-DP).
</t>
</section>
<!-- END 5.1: Distributed processing - REQ1 -->
<!-- BEGIN 5.2: Bypassable network-layer mobility support - REQ2 -->
<section anchor="sec:req2" title="On-demand network-layer mobility support - REQ2">
<t>
The need for "on-demand network-layer mobility support" introduced in
<xref target="I-D.ietf-dmm-requirements"/> will enable dynamic mobility
management. management. Flexibility on the
determination of whether network-layer mobility support is needed.
The requirement enables one to choose whether or not use network-layer
mobility support. It only enables the two following functions:
<list style="symbols">
<t>
Dynamically assign/relocate anchor: a mobility anchor is assigned only to
sessions which uses 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>
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). 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-up the correct address
(provided with mobility support or not) 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
(e.g., the MN does not know whether the allocated IP addresses are anchored).
However, there are proposals that the network could
indicate such IP address properties during assignment procedures,
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" />.
Although there exist these
individual efforts that could be 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 SHOULD need proper session
identification in addition to user/device identification.
</t>
</section>
<!-- END 5.2: Bypassable network-layer mobility support - REQ2 -->
<!-- BEGIN 5.3: IPv6 deployment - REQ3 -->
<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 have also IPv4
support. There are also some solutions that have some limited IPv4
support (e.g., PMIPv6). In conclusion, this requirement is met by existing DMM
practices.
</t>
</section>
<!-- END 5.3: IPv6 deployment - REQ3 -->
<!-- BEGIN 5.4: Existing mobility protocols - REQ4 -->
<section anchor="sec:req4" title="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="I-D.ietf-dmm-requirements"/>, 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 prevent
the distribution of mobility functions with in IP mobility protocols.
However, as discussed in <xref target="sec:req1" /> and
<xref target="sec:req2" />, limitations exist. The 3GPP data plane anchoring
function, i.e., the PGW, can be also be distributed, but with limitations;
e.g., no anchoring relocation, no context transfer between anchors, centralized
control plane. The 3GPP architecture is also going into the direction of
flattening with SIPTO and LIPA, though they do not provide mobility
support.
<!--
In conclusion this requirement can be met, DMM can reuse existing
mobility solutions, however some limitations exist.
-->
</t>
</section>
<!-- END 5.4: Existing mobility protocols - REQ4 -->
<!-- BEGIN 5.5: Co-existence - REQ5 -->
<section anchor="sec:req5" title="Co-existence - REQ5">
<t>
According to <xref target="I-D.ietf-dmm-requirements"/>, DMM solution must be
able to co-exist with existing network deployments, end hosts and routers. 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: Co-existence - REQ5 -->
<!-- BEGIN 5.6: Security considerations - REQ6 -->
<section anchor="sec:req6" title="Security considerations - REQ6">
<t>
As stated in <xref target="I-D.ietf-dmm-requirements"/>, a DMM solution
must not introduce new security risks, or amplify existing security
risks, that cannot be mitigated by existing security mechanisms or
protocols. Current mobility protocols have all security mechanisms
in place. 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.6: Security considerations - REQ6 -->
<!-- BEGIN 5.7: Multicast - REQ7 -->
<section anchor="sec:req7" title="Multicast - REQ7">
<t>
It is stated in <xref target="I-D.ietf-dmm-requirements"/> that DMM solutions
should enable multicast solutions to be developed 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>
The MULTIMOB WG in IETF has studied this issue, for the specific case of PMIPv6,
and has produced a baseline solution <xref target="RFC6224"/> as well as a
routing optimization solution <xref target="RFC7028"/> to address the problem.
The baseline solution suggests deploying an 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 (MTMA) or a direct routing option can be used to avoid the
tunnel convergence problem.
</t>
<t>
Besides the solutions proposed in MULTIMOB for PMIPv6 within the IETF, there are no
other solutions
for other mobility protocols to address the multicast tunnel convergence
problem.
</t>
</section>
<!-- END 5.7: Multicast - REQ7 -->
<!-- BEGIN 5.8: Summary -->
<section anchor="sec:req_summary" title="Summary">
<t>
We next list the main gaps identified from the analysis performed above:
<list style="symbols">
<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 allow changing the anchor during an
ongoing session. While MOBIKE could be used to switch from a gateway to another
in the middle of a session from MN side, there is no protocol support for the
network side.
</t>
<t>
The mobile node needs to simultaneously use multiple IP addresses with different properties, which requires to expose this information to the mobile node and to update accordingly the source address selection mechanism of the latter.
</t>
<t>
Currently, there is no efficient mechanism specified by the IETF that allows to
dynamically discover 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 that could help discovering anchors:
</t>
<t>
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
</t>
<t>
the MAP option in Router Advertisements defined by HMIPv6.
</t>
<t>
While existing network-based DMM practices may allow deployment
multiple LMAs and dynamic selection of the best one, doing so requires
some centralization in the control plane, for 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>
</t>
</section>
<!-- END 5.8: Summary -->
</section>
<!-- END 5. Gap analysis -->
<!-- BEGIN 6. Security Considerations -->
<section anchor="sec:security" title="Security Considerations">
<t>
Distributed mobility management systems encounter same security threats as existing centralized IP mobility protocols. 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 must account for the distribution of security associations between additional mobility entities.
</t>
</section>
<!-- END 6. Security Considerations -->
<!-- BEGIN 7. IANA Considerations -->
<section anchor="sec:iana" title="IANA Considerations">
<t>
None.
</t>
</section>
<!-- END 7. IANA Considerations -->
<!-- BEGIN 8. Contributors -->
<section anchor="sec:contributor" title="Contributors">
<t>
The following people have made significant contribution for this document.
</t>
<t>
Charles E. Perkins
<vspace blankLines="0" />
Huawei Technologies
<vspace blankLines="0" />
Email: charliep@computer.org
</t>
</section>
<!-- END 8. Contributors -->
</middle>
<back>
<references title="Normative References">
&RFC2119;
</references>
<references title="Informative References">
&RFC6275;
&RFC5213;
&RFC5555;
&RFC5844;
&RFC3963;
&RFC4640;
&RFC5026;
&RFC6611;
&RFC4225;
&RFC5380;
&RFC5142;
&RFC6705;
&RFC6463;
&RFC4555;
&RFC5996;
&RFC5014;
&RFC6224;
&RFC7028;
&RFC4889;
&RFC4066;
&RFC4067;
&RFC5568;
&I-D.ietf-dmm-requirements;
&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;
&RFC6097;
&TS29060;
&TS23859;
&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>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:26:51 |