< draft-ietf-dmm-best-practices-gap-analysis-03.txt   draft-ietf-dmm-best-practices-gap-analysis-03cep-v2.txt >
CEP: Need to avoid the presumption that only 3GPP and 802.11 matter
= Host route / BGP solutions also should be considered for gaps
= IoT is coming
= 802.15 is not out of the running
= Danger of overlooking a viable alternative solution
= Should also compare against FMIP.
CEP: Should point out the role of identity management / authentication
CEP: Do existing approaches to DMM properly handle flow management?
CEP: "distributed mobility management environment" ... *not*
= should use, e.g., "from the standpoint of satisfying DMM requirements"
CEP: "delegate" may be inaccurate; as used here, "advertise" or "assigned"
seems better
CEP: Does not seem wise to invite arguments about whether configuration and
advertisement of routing prefixes happens on control plan or management
plane.
CEP: need to define "flatness", flatten, flat network, etc.
CEP: Probably better to consider "client location management" and
"server location management" separately. Even better, this
concept could be substantially reworked to emphasize the role of
both parties in managing the "mobility association" or "binding".
For instance, "LMs" ==> "binding manager" and
"LMc" ==> "location reporter"
CEP: Why is the concept of "proxy" introduced in this discussion? Does
it help with any of the gap analysis? MAP is not a proxy because it
is a signaling partner for the mobile node.
CEP: Replace "Routing Management" by "Forwarding Management".
CEP: Should avoid the presumption that all readers are "3GPP-literate"...
CEP: Security Considerations are needed. Distributed processing quite
often introduces complicated security problems, which deserve attention
in this document. In fact, distributed security should rightfully
considered a "gap" insofar as current mechanisms are geared towards
centralized solutions.
DMM D. Liu, Ed. DMM D. Liu, Ed.
Internet-Draft China Mobile Internet-Draft China Mobile
Intended status: Informational JC. Zuniga, Ed. Intended status: Informational JC. Zuniga, Ed.
Expires: August 18, 2014 InterDigital Expires: August 18, 2014 InterDigital
P. Seite P. Seite
Orange Orange
H. Chan H. Chan
Huawei Technologies Huawei Technologies
CJ. Bernardos CJ. Bernardos
UC3M UC3M
February 14, 2014 February 14, 2014
Distributed Mobility Management: Current practices and gap analysis Distributed Mobility Management: Current practices and gap analysis
draft-ietf-dmm-best-practices-gap-analysis-03 draft-ietf-dmm-best-practices-gap-analysis-03
Abstract Abstract
The present document analyzes deployment practices of existing IP Deployment practices of certain existing IP mobility protocols are
mobility protocols in a distributed mobility management environment. analyzed to determine whether or not requirements for
It then identifies existing limitations when compared to the distributed mobility management solution are satisfied.
requirements defined for a distributed mobility management solution. It identifies existing limitations (gaps) when compared to those
requirements.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
skipping to change at page 3, line 15 skipping to change at page 3, line 15
environment. Section 4 presents the current practices of IP flat environment. Section 4 presents the current practices of IP flat
wireless networks and 3GPP architectures. Both network- and host- wireless networks and 3GPP architectures. Both network- and host-
based mobility protocols are considered. Section 5 presents the gap based mobility protocols are considered. Section 5 presents the gap
analysis with respect to the current practices. analysis with respect to the current practices.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
CEP: Would prefer not to use this...
All general mobility-related terms and their acronyms used in this All general mobility-related terms and their acronyms used in this
document are to be interpreted as defined in the Mobile IPv6 base document are to be interpreted as defined in the Mobile IPv6 base
specification [RFC6275] and in the Proxy mobile IPv6 specification specification [RFC6275] and in the Proxy mobile IPv6 specification
[RFC5213]. These terms include mobile node (MN), correspondent node [RFC5213]. These terms include mobile node (MN), correspondent node
(CN), home agent (HA), local mobility anchor (LMA), and mobile access (CN), home agent (HA), local mobility anchor (LMA), and mobile access
gateway (MAG). gateway (MAG).
In addition, this document also introduces some definitions of IP In addition, this document also introduces some definitions of IP
mobility functions in Section 3. mobility functions in Section 3.
In this document there are also references to a "distributed mobility In this document there are also references to a "distributed mobility
management environment". By this term, we refer to a scenario in management environment". By this term, we refer to a scenario in
which the IP mobility, access network and routing solutions allow for which the IP mobility, access network and routing solutions allow for
setting up IP networks so that traffic is distributed in an optimal setting up IP networks so that traffic is distributed in an optimal
way, without relying on centrally deployed anchors to manage IP way, reducing the reliance on centrally deployed anchors to manage IP
mobility sessions. mobility sessions.
3. Functions of existing mobility protocols 3. Functions of existing mobility protocols
The host-based Mobile IPv6 [RFC6275] and its network-based extension, The host-based Mobile IPv6 [RFC6275] and its network-based extension,
PMIPv6 [RFC5213], are both logically centralized mobility management PMIPv6 [RFC5213], are both logically centralized mobility management
approaches addressing primarily hierarchical mobile networks. approaches addressing primarily hierarchical mobile networks.
Although they are centralized approaches, they have important Although these two are centralized approaches, they have important
mobility management functions resulting from years of extensive work mobility management functions. It is therefore useful to
to develop and to extend these functions. It is therefore useful to take these existing functions and examine them in
take these existing functions and examine them in a DMM scenario in order to understand how to deploy the existing mobility protocols to
order to understand how to deploy the existing mobility protocols in provide distributed mobility management. We also consider HMIPv6[RFC5380]
a distributed mobility management environment. since it enables distributed anchor management.
The main mobility management functions of MIPv6, PMIPv6, and HMIPv6 The main mobility management functions of MIPv6, PMIPv6, and HMIPv6
are the following: are the following:
1. Anchoring function (AF): allocation to a mobile node of an IP 1. Anchoring function (AF): allocation to a mobile node of an IP
address/prefix (e.g., a Home Address or Home Network Prefix) address (a Home Address (HoA))/ or prefix (a Home Network Prefix(HNP))
topologically anchored by the delegating node (i.e., the anchor topologically anchored by the advertising node (i.e., the anchor
node is able to advertise a connected route into the routing node is able to advertise a connected route into the routing
infrastructure for the delegated IP prefixes). It is a control infrastructure for the allocated IP prefixes).
plane function.
2. Internetwork Location Management (LM) function: managing and 2. Internetwork Location Management (LM) function: managing and
keeping track of the internetwork location of an MN. The keeping track of the internetwork location of an MN. The
location information may be a mapping of the IP delegated address 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 /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 of a node that can forward packets destined to the MN. It is a
control plane function. control plane function.
In a client-server model of the system, location query and update In a client-server protocol model, location query and update
messages may be exchanged between the client (LMc) and the server messages may be exchanged between the client (LMc) and the server
(LMs). (LMs).
Optionally, one (or more) proxy may exist between the LMs and the One or more proxy agents may exist between the LMs and the
LMc, i.e., LMs-proxy-LMc. Then, to the LMs, the proxy behaves LMc, i.e., LMs-proxy-LMc. Then, to the LMs, the proxy behaves
like the LMc; to the LMc, the proxy behaves like the LMs. like the LMc; to the LMc, the proxy behaves like the LMs.
3. Routing management (RM) function: packet interception and 3. Routing management (RM) function: packet interception and
forwarding to/from the IP address/prefix delegated to the MN, forwarding to/from the IP address/prefix assigned to the MN,
based on the internetwork location information, either to the based on the internetwork location information, either to the
destination or to some other network element that knows how to destination or to some other network element that knows how to
forward the packets to their destination. forward the packets to their destination.
RM may optionally be split into the control plane (RM-CP) and RM may optionally be split into the control plane (RM-CP) and
data plane (RM-DP). data plane (RM-DP).
In Mobile IPv6 [RFC6275], the home agent (HA) typically provides the In Mobile IPv6, the home agent (HA) typically provides the
anchoring function (AF); the location management server (LMs) is at anchoring function (AF); the location management server (LMs) is at
the HA while the location management client (LMc) is at the MN; the the HA while the location management client (LMc) is at the MN; the
routing management (RM) function is both ends of tunneling at the HA routing management (RM) function is both ends of tunneling at the HA
and the MN. and the MN.
In Proxy Mobile IPv6 [RFC5213], the Local Mobility Anchor (LMA) In Proxy Mobile IPv6, the Local Mobility Anchor (LMA)
provides the anchoring function (AF); the location management server provides the anchoring function (AF); the location management server
(LMs) is at the LMA while the location management client (LMc) is at (LMs) is at the LMA while the location management client (LMc) is at
the mobile access gateway (MAG); the routing management (RM) function the mobile access gateway (MAG); the routing management (RM) function
is both ends of tunneling at the HA and the MAG. is both ends of tunneling at the HA and the MAG.
In Hirarchical mobile IPv6 (HMIPv6) [RFC5380], a location management In Hirarchical Mobile IPv6 (HMIPv6), the mobility anchor point (MAP)
proxy is at the mobility anchor point (MAP) to proxy between the LMs serves as a location management aggregator between the LMs
at the LMA and the LMc at the MN. The MAP also has RM funtion to at the HA and the LMc at the MN. The MAP also has RM function to
enable tunneling between LMA and itself as well as tunneling between enable tunneling between HA and itself as well as tunneling between
MN and itself. MN and itself.
4. DMM practices 4. DMM practices
This section documents deployment practices of existing mobility This section documents deployment practices of existing mobility
protocols in a distributed mobility management environment. This protocols in a distributed mobility management environment. This
description is divided into two main families of network description is divided into two main families of network
architectures: i) IP flat wireless networks (e.g., evolved Wi-Fi architectures: i) IP flat wireless networks (e.g., evolved Wi-Fi
hotspots) and, ii) 3GPP network flattening approaches. hotspots) and, ii) 3GPP network flattening approaches.
While describing the current DMM practices, references to the generic While describing the current DMM practices, references to the generic
mobility management functions described in Section 3 are provided, as mobility management functions described in Section 3 are provided, as
well as some initial hints on the identified gaps with respect to the well as some initial hints on the identified gaps with respect to the
DMM requirements documented in [I-D.ietf-dmm-requirements]. DMM requirements documented in [I-D.ietf-dmm-requirements].
4.1. Assumptions 4.1. Assumptions
There are many different approaches that can be considered to There are many different approaches that can be considered to
implement and deploy a distributed anchoring and mobility solution. implement and deploy a distributed anchoring and mobility solution.
The focus of the gap analysis is on current mobile network The focus of the gap analysis is on certain current mobile network
architectures and standardized IP mobility solutions, considering any architectures and standardized IP mobility solutions, considering any
kind of deployment options which do not violate the original protocol kind of deployment options which do not violate the original protocol
specifications. In order to limit the scope of our analysis of specifications. In order to limit the scope of our analysis of
current DMM practices, we consider the following list of technical DMM practices, we consider the following list of technical
assumptions: assumptions:
1. Both host- and network-based solutions SHOULD be considered. 1. Both host- and network-based solutions should be considered.
2. Solutions SHOULD allow selecting and using the most appropriate 2. Solutions should allow selecting and using the most appropriate
IP anchor among a set of available ones. IP anchor among a set of available candidates.
3. Mobility management SHOULD be realized by the preservation of the 3. Mobility management should be realized by the preservation of the
IP address across the different points of attachment (i.e., IP address across the different points of attachment (i.e.,
provision of IP address continuity). provision of IP address continuity). This is in contrast to
certain transport-layer based approaches such as SCTP or
application-layer mobility.
Applications which can cope with changes in the MN's IP address do Applications which can cope with changes in the MN's IP address do
not depend on IP mobility management protocols such as DMM. not depend on IP mobility management protocols such as DMM.
Typically, a connection manager together with the operating system Typically, a connection manager together with the operating system
will configure the source address selection mechanism of the IP will configure the source address selection mechanism of the IP
stack. This might involve identifying application capabilities and stack. This might involve identifying application capabilities and
triggering the mobility support accordingly. Further considerations triggering the mobility support accordingly. Further considerations
on application management and source address selection are out of the on application management and source address selection are out of the
scope of this document. scope of this document, but the reader might consult
[RFC-SourceAddrSelection].
4.2. IP flat wireless network 4.2. IP flat wireless network
This section focuses on common IP wireless network architectures and This section focuses on common IP wireless network architectures and
how they can be flattened from an IP mobility and anchoring point of how they can be flattened from an IP mobility and anchoring point of
view using common and standardized protocols. We take Wi-Fi as an view using common and standardized protocols. We take Wi-Fi as an
exemplary wireless technology, since it is widely known and deployed useful wireless technology, since it is widely known and deployed
nowadays. Some representative examples of Wi-Fi deployment nowadays. Some representative examples of Wi-Fi deployment
architectures are depicted in Figure 1. architectures are depicted in Figure 1.
+-------------+ _----_ +-------------+ _----_
+---+ | Access | _( )_ +---+ | Access | _( )_
|AAA|. . . . . . | Aggregation |----------( Internet ) |AAA|. . . . . . | Aggregation |----------( Internet )
+---+ | Gateway | (_ _) +---+ | Gateway | (_ _)
+-------------+ '----' +-------------+ '----'
| | | | | |
| | +-------------+ | | +-------------+
skipping to change at page 6, line 40 skipping to change at page 6, line 40
Figure 1: IP Wi-Fi network architectures Figure 1: IP Wi-Fi network architectures
In the figure, three typical deployment options are shown In the figure, three typical deployment options are shown
[I-D.gundavelli-v6ops-community-wifi-svcs]. On the left hand side of [I-D.gundavelli-v6ops-community-wifi-svcs]. On the left hand side of
the figure, mobile nodes directly connect to a Residential Gateway the figure, mobile nodes directly connect to a Residential Gateway
(RG) which is a network device at the customer premises and provides (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 both wireless layer-2 access connectivity (i.e., it hosts the 802.11
Access Point function) and layer-3 routing functions. In the middle Access Point function) and layer-3 routing functions. In the middle
of the figure, mobile nodes connect to Wi-Fi Access Points (APs) that of the figure, mobile nodes connect to Wi-Fi Access Points (APs) that
are managed by a WLAN Controller (WLC), which performs radio resource are managed by a WLAN Controller (WLC), which performs radio resource
management on the APs, system-wide mobility policy enforcement and management on the APs, domain-wide mobility policy enforcement and
centralized forwarding function for the user traffic. The WLC could centralized forwarding function for the user traffic. The WLC could
also implement layer-3 routing functions, or attach to an access also implement layer-3 routing functions, or attach to an access
router (AR). Last, on the right-hand side of the figure, 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 points are directly connected to an access router. This can also be
used as a generic connectivity model. used as a generic connectivity model.
In some network architectures, such as the evolved Wi-Fi hotspot, In some network architectures, such as the evolved Wi-Fi hotspot[CITATION!],
operators might make use of IP mobility protocols to provide mobility operators might make use of IP mobility protocols to provide mobility
support to users, for example to allow connecting the IP Wi-Fi support to users, for example to allow connecting the IP Wi-Fi
network to a mobile operator core and support roaming between WLAN network to a mobile operator core and support roaming between WLAN
and 3GPP accesses. Two main protocols can be used: Proxy Mobile IPv6 and 3GPP accesses. Two main protocols can be used: Proxy Mobile IPv6
[RFC5213] or Mobile IPv6 [RFC6275], [RFC5555], with the anchor (e.g., [RFC5213] or Mobile IPv6 [RFC6275], [RFC5555],
CEP: that's three, not two...
with the anchor (e.g.,
local mobility anchor or home agent) role typically being played by local mobility anchor or home agent) role typically being played by
the Access Aggregation Gateway or even by an entity placed in the the Access Aggregation Gateway or even by an entity placed in the
mobile operator's core network. CEP: *what* entity?
mobile operator's core network[CITATION!].
Although this section has adopted the example of Wi-Fi networks, Although this section has made use of the example of Wi-Fi networks,
there are other IP flat wireless network architectures specified, there are other IP flat wireless network architectures specified,
such as WiMAX [IEEE.802-16.2009], which integrates both host and such as WiMAX [IEEE.802-16.2009], which integrates both host and
network-based IP mobility functionality. network-based IP mobility functionality.
Existing IP mobility protocols can also be deployed in a more Existing IP mobility protocols can also be deployed in a more
flattened manner, so that the anchoring and access aggregation flattened manner, so that the anchoring and access aggregation
functions are distributed. We next describe several practices for functions are distributed.
CEP: The claimed consequence does not follow...
We next describe several practices for
the deployment of existing mobility protocols in a distributed the deployment of existing mobility protocols in a distributed
mobility management environment. The analysis in this section is mobility management environment. The analysis in this section is
limited to protocol solutions based on existing IP mobility limited to protocol solutions based on existing IP mobility
protocols, either host- or network-based, such as Mobile IPv6 protocols, either host- or network-based, such as Mobile IPv6
[RFC6275], [RFC5555], Proxy Mobile IPv6 [RFC5213], [RFC5844] and NEMO [RFC6275], [RFC5555], Proxy Mobile IPv6 [RFC5213], [RFC5844] and NEMO
[RFC3963]. Extensions to these base protocol solutions are also [RFC3963]. Extensions to these base protocol solutions are also
considered. We pay special attention to how to efficiently select considered. We pay special attention to how to efficiently select
the source address (care-of-addresses versus home addresses) for the source address (care-of-addresses versus home addresses) for
different types of communications. The analysis is divided into two different types of communications.
CEP: This contradicts the statement at the end of section 4.1.
The analysis is divided into two
parts: host- and network-based practices. parts: host- and network-based practices.
4.2.1. Host-based IP DMM practices 4.2.1. Host-based IP DMM practices
Mobile IPv6 (MIPv6) [RFC6275] and its extension to support mobile Mobile IPv6 (MIPv6) [RFC6275] and its extension to support mobile
networks, the NEMO Basic Support protocol (hereafter, simply referred networks, the NEMO Basic Support protocol (hereafter, simply referred
to as NEMO) [RFC3963] are well-known host-based IP mobility to as NEMO) [RFC3963] are well-known host-based IP mobility
protocols. They heavily rely on the function of the Home Agent (HA), protocols. They depend upon the function of the Home Agent (HA),
a centralized anchor, to provide mobile nodes (hosts and routers) a centralized anchor, to provide mobile nodes (hosts and routers)
with mobility support. In these approaches, the home agent typically with mobility support. In these approaches, the home agent typically
provides the anchoring function (AF), Routing management (RM), and provides the anchoring function (AF), Routing management (RM), and
Internetwork Location Management server (LMs) functions. The mobile Internetwork Location Management server (LMs) functions. The mobile
node possesses the Location management client (LMc) function and the node possesses the Location management client (LMc) function and the
RM function to enable tunneling between HA and itself. We next RM function to enable tunneling between HA and itself. We next
describe some practices on how MIPv6/NEMO and several additional describe some practices that show how MIPv6/NEMO and several other
CEP: Strange to cite NEMO as "host-based" mobility... perhaps "client-based"?
protocol extensions can be deployed in a distributed mobility protocol extensions can be deployed in a distributed mobility
management environment. management environment.
One approach to distribute the anchors can be to deploy several HAs One approach to distribute the anchors can be to deploy several HAs
(as shown in Figure 2), and assign the topologically closest anchor (as shown in Figure 2), and assign the topologically closest anchor
to each MN [RFC4640], [RFC5026], [RFC6611]. In the example shown in to each MN [RFC4640], [RFC5026], [RFC6611]. In the example shown in
Figure 2, MN1 is assigned HA1 (and a home address anchored by HA1), Figure 2, MN1 is assigned HA1 (and a home address anchored by HA1),
while MN2 is assigned HA2. Note that MIPv6/NEMO specifications do while MN2 is assigned HA2. Note that MIPv6/NEMO specifications do
not prevent the simultaneous use of multiple home agents by a single not prevent the simultaneous use of multiple home agents by a single
mobile node. This deployment model could be exploited by a mobile mobile node. This deployment model could be exploited by a mobile
node to meet assumption #4 of Section 4.1 and use several anchors at node to meet assumption #4 of Section 4.1 and use several anchors at
the same time, each of them anchoring IP flows initiated at a the same time, each of them anchoring IP flows initiated at a
different point of attachment. However there is no mechanism different point of attachment. However there is no mechanism
specified by IETF to enable an efficient dynamic discovery of specified by IETF to enable an efficient dynamic discovery of
available anchors and the selection of the most suitable one. Note available anchors and the selection of the most suitable one.
that some of these mechanisms have been defined outside IETF (e.g., Some of these mechanisms[cite] have been defined outside IETF.
3GPP).
<- INTERNET -> <- HOME NETWORK -> <---- ACCESS NETWORK ----> <- INTERNET -> <- HOME NETWORK -> <---- ACCESS NETWORK ---->
------- ------- ------- -------
| CN1 | ------- | AR1 |-(o) zzzz (o) | CN1 | ------- | AR1 |-(o) zzzz (o)
------- | HA1 | ------- | ------- | HA1 | ------- |
------- (MN1 anchored at HA1) ------- ------- (MN1 anchored at HA1) -------
------- | MN1 | ------- | MN1 |
| AR2 |-(o) ------- | AR2 |-(o) -------
------- -------
------- -------
skipping to change at page 9, line 8 skipping to change at page 9, line 8
the direct path between them. Using the example shown in Figure 2, the direct path between them. Using the example shown in Figure 2,
MN1 is using BT mode with CN1 and MN2 is in RO mode with CN2. MN1 is using BT mode with CN1 and MN2 is in RO mode with CN2.
However, the RO mode has several drawbacks: However, the RO mode has several drawbacks:
o The RO mode is only supported by Mobile IPv6. There is no route o The RO mode is only supported by Mobile IPv6. There is no route
optimization support standardized for the NEMO protocol because of optimization support standardized for the NEMO protocol because of
the security problems posed by extending return routability tests the security problems posed by extending return routability tests
for prefixes, although many different solutions have been proposed for prefixes, although many different solutions have been proposed
[RFC4889]. [RFC4889].
o The RO mode requires additional signaling, which adds some o The RO mode requires signaling that adds some protocol overhead.
protocol overhead.
o The signaling required to enable RO involves the home agent and is o The signaling required to enable RO involves the home agent and is
repeated periodically for security reasons [RFC4225]. This repeated periodically for security reasons [RFC4225]. This
basically means that the HA remains a single point of failure, basically means that the HA remains a single point of failure,
because the Mobile IPv6 RO mode does not mean HA-less operation. because the Mobile IPv6 RO mode does not mean HA-less operation.
CEP: HA-less operation was intended to be enabled, but disallowed due
to security considerations. If DMM wants HA-less operation, the
same security vulnerabilities will have to be mitigated.
o The RO mode requires additional support from the correspondent o The RO mode requires support from the correspondent node (CN).
node (CN).
Notwithstanding these considerations, the RO mode does offer the Notwithstanding these considerations, the RO mode does offer the
possibility of substantially reducing traffic through the Home Agent, possibility of substantially reducing traffic through the Home Agent,
in cases when it can be supported by the relevant correspondent in cases when it can be supported by the relevant correspondent
nodes. Note that a mobile node can also use its CoA directly nodes. Note that a mobile node can also use its CoA directly
[RFC5014] when communicating with CNs on the same link or anywhere in [RFC5014] when communicating with CNs on the same link or anywhere in
the Internet, although no session continuity support would be the Internet, although no session continuity support would be
provided by the IP stack in this case. provided by the IP stack in this case.
Hierarchical Mobile IPv6 (HMIPv6) [RFC5380] (as shown in Figure 3), Hierarchical Mobile IPv6 (HMIPv6) [RFC5380] (as shown in Figure 3),
is another host-based IP mobility extension which can be considered is another host-based IP mobility extension which can be considered
as a complement to provide a less centralized mobility deployment. as a complement to provide a less centralized mobility deployment.
It allows reducing the amount of mobility signaling as well as It allows reducing the amount of mobility signaling as well as
improving the overall handover performance of Mobile IPv6 by improving the overall handover performance of Mobile IPv6 by
introducing a new hierarchy level to handle local mobility. The introducing a new hierarchy level to handle local mobility. The
Mobility Anchor Point (MAP) entity is introduced as a local mobility Mobility Anchor Point (MAP) entity is introduced as a local mobility
handling node deployed closer to the mobile node. It provides LM handling node deployed closer to the mobile node. It provides LM
proxy function between the LM server (LMs) at the HA and the LM intermediary function between the LM server (LMs) at the HA and the LM
client (LMc) at the MN. It also possess RM function to tunnel with client (LMc) at the MN. It also performs the RM function using tunneling
the HA and also to tunnel with the MN. with the HA and also with the MN.
<- INTERNET -> <- HOME NETWORK -> <------- ACCESS NETWORK -------> <- INTERNET -> <- HOME NETWORK -> <------- ACCESS NETWORK ------->
----- -----
/|AR1|-(o) zz (o) /|AR1|-(o) zz (o)
-------- / ----- | -------- / ----- |
| MAP1 |< ------- | MAP1 |< -------
-------- \ ----- | MN1 | -------- \ ----- | MN1 |
------- \|AR2| ------- ------- \|AR2| -------
| CN1 | ----- HoA anchored | CN1 | ----- HoA anchored
------- ----- at HA1 ------- ----- at HA1
skipping to change at page 10, line 20 skipping to change at page 10, line 20
-------- \ ----- -------- \ -----
\|AR6| \|AR6|
----- -----
CN1 CN2 HA1 MAP1 AR1 MN1 CN1 CN2 HA1 MAP1 AR1 MN1
| | | | ________|__________ | | | | | ________|__________ |
|<------------------>|<==============>|<________+__________>| HoA |<------------------>|<==============>|<________+__________>| HoA
| | | | | | | | | | | |
| |<-------------------------->|<===================>| RCoA | |<-------------------------->|<===================>| RCoA
| | | | | | | | | | | |
CEP: Is this intended to show a secondary encapsulation between MAP and MN?
Figure 3: Hierarchical Mobile IPv6 Figure 3: Hierarchical Mobile IPv6
When HMIPv6 is used, the MN has two different temporal addresses: the When HMIPv6 is used, the MN has two different temporary addresses: the
Regional Care-of Address (RCoA) and the Local Care-of Address (LCoA). Regional Care-of Address (RCoA) and the Local Care-of Address (LCoA).
The RCoA is anchored at one MAP, that plays the role of local home The RCoA is anchored at one MAP, that plays the role of local home
agent, while the LCoA is anchored at the access router level. The agent, while the LCoA is anchored at the access router level. The
mobile node uses the RCoA as the CoA signaled to its home agent. mobile node uses the RCoA as the CoA signaled to its home agent.
Therefore, while roaming within a local domain handled by the same Therefore, while roaming within a local domain handled by the same
MAP, the mobile node does not need to update its home agent (i.e., MAP, the mobile node does not need to update its home agent (i.e.,
the mobile node does not change its RCoA). the mobile node does not change its RCoA).
The use of HMIPv6 allows achieving some form of route optimization, The use of HMIPv6 enables some form of route optimization,
since a mobile node may decide to directly use the RCoA as source since a mobile node may decide to directly use the RCoA as source
address for a communication with a given correspondent node, notably address for a communication with a given correspondent node, particularly
if the MN does not expect to move outside the local domain during the 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 lifetime of the communication. This can be seen as a potential DMM
mode of operation. In the example shown in Figure 3, MN1 is using mode of operation. In the example shown in Figure 3, MN1 is using
its global HoA to communicate with CN1, while it is using its RCoA to its global HoA to communicate with CN1, while it is using its RCoA to
communicate with CN2. communicate with CN2.
Additionally, a local domain might have several MAPs deployed, Furthermore, a local domain might have several MAPs deployed,
enabling therefore a different kind of HMIPv6 deployments (e.g., flat enabling therefore a different kind of HMIPv6 deployments (e.g., flat
and distributed). The HMIPv6 specification supports a flexible and distributed). The HMIPv6 specification supports a flexible
selection of the MAP (e.g., based on the distance between the MN and 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 MAP, taking into consideration the expected mobility pattern of
the MN, etc.). the MN, etc.).
An additional extension that can be used to help deploying a mobility Another extension that can be used to help deploying a mobility
protocol in a distributed mobility management environment is the Home protocol in a distributed mobility management environment is the Home
Agent switch specification [RFC5142], which defines a new mobility Agent switch specification [RFC5142], which defines a new mobility
header for signaling a mobile node that it should acquire a new home header for signaling a mobile node that it should acquire a new home
agent. Even though the purposes of this specification do not include agent. RFC 5142 does not specify
the case of changing the mobile node's home address, as that might the case of changing the mobile node's home address, as that might
imply loss of connectivity for ongoing persistent connections, it imply loss of connectivity for ongoing persistent connections.
Nevertheless, that specification
could be used to force the change of home agent in those situations could be used to force the change of home agent in those situations
where there are no active persistent data sessions that cannot cope where there are no active persistent data sessions that cannot cope
with a change of home address. with a change of home address.
There are other host-based approaches standardized within IETF that There are other host-based approaches standardized within IETF that
can be used to provide mobility support. For example MOBIKE can be used to provide mobility support. For example MOBIKE
[RFC4555] allows a mobile node encrypting traffic through IKEv2 [RFC4555] allows a mobile node encrypting traffic through IKEv2
[RFC5996] to change its point of attachment while maintaining a [RFC5996] to change its point of attachment while maintaining a
Virtual Private Network (VPN) session. The MOBIKE protocol allows Virtual Private Network (VPN) session. The MOBIKE protocol allows
updating the VPN Security Associations (SAs) in cases where the base updating the VPN Security Associations (SAs) in cases where the base
connection initially used is lost and needs to be re-established. connection initially used is lost and needs to be re-established.
The use of the MOBIKE protocol avoids having to perform an IKEv2 re- The use of the MOBIKE protocol avoids having to perform an IKEv2 re-
negotiation. Similar considerations to those made for Mobile IPv6 negotiation. Similar considerations to those made for Mobile IPv6
can be applied to MOBIKE; though MOBIKE is best suited for situations can be applied to MOBIKE; though MOBIKE is best suited for situations
where the address of at least one endpoint is relatively stable and where the address of at least one endpoint is relatively stable and
can be discovered using existing mechanisms such as DNS. can be discovered using existing mechanisms such as DNS.
4.2.2. Network-based IP DMM practices 4.2.2. Network-based IP DMM practices
Proxy Mobile IPv6 (PMIPv6) [RFC5213] is the main network-based IP Proxy Mobile IPv6 (PMIPv6) [RFC5213] is the main network-based IP
mobility protocol specified for IPv6 ([RFC5844] defines some IPv4 mobility protocol specified for IPv6; Proxy Mobile IPv4 [RFC5844] defines
extensions). With network-based IP mobility protocols, the local some IPv4 extensions. With network-based IP mobility protocols, the local
mobility anchor (LMA) typically provides the anchoring function (AF), mobility anchor (LMA) typically provides the anchoring function (AF),
Routing management (RM) function, Internetwork Location Management Routing management (RM) function, Internetwork Location Management
server (LMs) function and RM function. The mobile access gateway server (LMs) function and RM function. The mobile access gateway
(MAG) provides the Location Management client (LMc) function and (MAG) provides the Location Management client (LMc) function and
Routing management (RM) function to tunnel with LMA. PMIPv6 is Routing management (RM) function to tunnel with LMA. PMIPv6 is
architecturally similar to MIPv6, as the mobility signaling and architecturally almost identical to MIPv6, as the mobility signaling and
routing between LMA and MAG in PMIPv6 is similar to those between HA 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 and MN in MIPv6. The required mobility functionality at the MN is
provided by the MAG so that the involvement in mobility support by provided by the MAG so that the involvement in mobility support by
the MN is not required. the MN is not required.
We next describe some practices on how network-based mobility We next describe some practices that show how network-based mobility
protocols and several additional protocol extensions can be deployed protocols and several other protocol extensions can be deployed
in a distributed mobility management environment. in a distributed mobility management environment.
One simple but still suboptimal approach to decentralize Proxy Mobile One way to decentralize Proxy Mobile
IPv6 operation can be to deploy several local mobility anchors and IPv6 operation can be to deploy several local mobility anchors and
use some selection criteria to assign LMAs to attaching mobile nodes use some selection criteria to assign LMAs to attaching mobile nodes
(an example of this type of assignment is shown in Figure 4). As per (an example of this type of assignment is shown in Figure 4). As with
the client based approach, a mobile node may use several anchors at the client based approach, a mobile node may use several anchors at
the same time, each of them anchoring IP flows initiated at a the same time, each of them anchoring IP flows initiated at a
different point of attachment. This assignment can be static or different point of attachment. This assignment can be static or
dynamic (as described later in this document). The main advantage of dynamic (as described later in this document). The main advantage of
CEP: xref would be nice.
this simple approach is that the IP address anchor (i.e., the LMA) this simple approach is that the IP address anchor (i.e., the LMA)
could be placed closer to the mobile node. Therefore the resulting 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 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 node moves, the resulting path will start deviating from the optimal
one. one.
<- INTERNET -><- HOME NET -><----------- ACCESS NETWORK ------------> <- INTERNET -><- HOME NET -><----------- ACCESS NETWORK ------------>
------- -------
| CN1 | -------- -------- -------- | CN1 | -------- -------- --------
------- -------- | MAG1 | | MAG2 | | MAG3 | ------- -------- | MAG1 | | MAG2 | | MAG3 |
skipping to change at page 13, line 23 skipping to change at page 13, line 23
sessions can survive an IP address change. Note that several sessions can survive an IP address change. Note that several
possible dynamic local mobility anchor discovery solutions can be possible dynamic local mobility anchor discovery solutions can be
used, as described in [RFC6097]. used, as described in [RFC6097].
4.3. 3GPP network flattening approaches 4.3. 3GPP network flattening approaches
The 3rd Generation Partnership Project (3GPP) is the standards The 3rd Generation Partnership Project (3GPP) is the standards
development organization that specifies the 3rd generation mobile development organization that specifies the 3rd generation mobile
network and the Evolved Packet System (EPS), which mainly comprises network and the Evolved Packet System (EPS), which mainly comprises
the Evolved Packet Core (EPC) and a new radio access network, the Evolved Packet Core (EPC) and a new radio access network,
sometimes referred to as LTE (Long Term Evolution). usually referred to as LTE (Long Term Evolution).
Architecturally, the 3GPP Evolved Packet Core (EPC) network is Architecturally, the 3GPP Evolved Packet Core (EPC) network is
similar to an IP wireless network running PMIPv6 or MIPv6, as it similar to an IP wireless network running PMIPv6 or MIPv6, as it
relies on the Packet Data Gateway (PGW) anchoring services to provide relies on the Packet Data Gateway (PGW) anchoring services to provide
mobile nodes with mobility support (see Figure 5). There are client- mobile nodes with mobility support (see Figure 5). There are client-
based and network-based mobility solutions in 3GPP, which for based and network-based mobility solutions in 3GPP, which for
simplicity will be analyzed together. We next describe how 3GPP simplicity will be analyzed together. We next describe how 3GPP
mobility protocols and several additional completed or ongoing mobility protocols and several other completed or ongoing
extensions can be deployed to meet some of the DMM requirements extensions can be deployed to meet some of the DMM requirements
[I-D.ietf-dmm-requirements]. [I-D.ietf-dmm-requirements].
+---------------------------------------------------------+ +---------------------------------------------------------+
| PCRF | | PCRF |
+-----------+--------------------------+----------------+-+ +-----------+--------------------------+----------------+-+
| | | | | |
+----+ +-----------+------------+ +--------+-----------+ +-+-+ +----+ +-----------+------------+ +--------+-----------+ +-+-+
| | | +-+ | | Core Network | | | | | | +-+ | | Core Network | | |
| | | +------+ |S|__ | | +--------+ +---+ | | | | | | +------+ |S|__ | | +--------+ +---+ | | |
skipping to change at page 14, line 29 skipping to change at page 14, line 29
+----+ +--------------------+ +---+ +----+ +--------------------+ +---+
Figure 5: EPS (non-roaming) architecture overview Figure 5: EPS (non-roaming) architecture overview
The GPRS Tunnelling Protocol (GTP) [SDO-3GPP.29.060] The GPRS Tunnelling Protocol (GTP) [SDO-3GPP.29.060]
[SDO-3GPP.29.281] [SDO-3GPP.29.274] is a network-based mobility [SDO-3GPP.29.281] [SDO-3GPP.29.274] is a network-based mobility
protocol specified for 3GPP networks (S2a, S2b, S5 and S8 protocol specified for 3GPP networks (S2a, S2b, S5 and S8
interfaces). Similar to PMIPv6, it can handle mobility without interfaces). Similar to PMIPv6, it can handle mobility without
requiring the involvement of the mobile nodes. In this case, the requiring the involvement of the mobile nodes. In this case, the
mobile node functionality is provided in a proxy manner by the mobile node functionality is provided in a proxy manner by the
CEP: "binding update functionality"??
Serving Data Gateway (SGW), Evolved Packet Data Gateway (ePDG), or Serving Data Gateway (SGW), Evolved Packet Data Gateway (ePDG), or
Trusted Wireless Access Gateway (TWAG). Trusted Wireless Access Gateway (TWAG).
3GPP specifications also include client-based mobility support, based 3GPP specifications also include client-based mobility support, based
on adopting the use of Dual-Stack Mobile IPv6 (DSMIPv6) [RFC5555] for on adopting the use of Dual-Stack Mobile IPv6 (DSMIPv6) [RFC5555] for
the S2c interface. In this case, the User Equipment (UE) implements the S2c interface. In this case, the User Equipment (UE) implements
the mobile node functionality, while the home agent role is played by the mobile node functionality, while the home agent role is played by
the PGW. the PGW.
A Local IP Access (LIPA) and Selected IP Traffic Offload (SIPTO) A Local IP Access (LIPA) and Selected IP Traffic Offload (SIPTO)
enabled network [SDO-3GPP.23.401] allows offloading some IP services enabled network [SDO-3GPP.23.401] allows offloading some IP services
at the local access network, above the Radio Access Network (RAN) or at the local access network, above the Radio Access Network (RAN) or
at the macro, without the need to traverse back to the PGW (see at the macro, without the need to travel back to the PGW (see
CEP: "macro" meaning is unclear
Figure 6). Figure 6).
+---------+ IP traffic to mobile operator's CN +---------+ IP traffic to mobile operator's CN
| User |....................................(Operator's CN) | User |....................................(Operator's CN)
| Equipm. |.................. | Equipm. |..................
+---------+ . Local IP traffic +---------+ . Local IP traffic
. .
+-----------+ +-----------+
|Residential| |Residential|
|enterprise | |enterprise |
skipping to change at page 15, line 28 skipping to change at page 15, line 28
+------+ +------+ +------+ +------+
|L-PGW | ---- | MME | |L-PGW | ---- | MME |
+------+ / +------+ +------+ / +------+
| / | /
+-------+ +------+ +------+/ +------+ +-------+ +------+ +------+/ +------+
| UE |.....|eNB |....| S-GW |........| P-GW |...> CN Traffic | UE |.....|eNB |....| S-GW |........| P-GW |...> CN Traffic
+-------+ +------+ +------+ +------+ +-------+ +------+ +------+ +------+
Figure 7: SIPTO architecture Figure 7: SIPTO architecture
LIPA, on the other hand, enables an IP capable UE connected via a LIPA, on the other hand, enables an IP addressable UE connected via a
Home eNB (HeNB) to access other IP capable entities in the same Home eNB (HeNB) to access other IP addressable entities in the same
residential/enterprise IP network without traversing the mobile residential/enterprise IP network without traversing the mobile
operator's network core in the user plane. In order to achieve this, operator's network core in the user plane. In order to achieve this,
a Local GW (L-GW) collocated with the HeNB is used. LIPA is a Local GW (L-GW) collocated with the HeNB is used. LIPA is
established by the UE requesting a new PDN connection to an access established by the UE requesting a new PDN connection to an access
CEP: PDN connection undefined (and irrelevant?)
point name for which LIPA is permitted, and the network selecting the point name for which LIPA is permitted, and the network selecting the
CEP: Is it really important for the gap analysis to discuss LIPA policy?
Local GW associated with the HeNB and enabling a direct user plane Local GW associated with the HeNB and enabling a direct user plane
path between the Local GW and the HeNB. path between the Local GW and the HeNB.
+---------------+-------+ +----------+ +-------------+ ===== +---------------+-------+ +----------+ +-------------+ =====
|Residential | |H(e)NB | | Backhaul | |Mobile | ( IP ) |Residential | |H(e)NB | | Backhaul | |Mobile | ( IP )
|Enterprise |..|-------|..| |..|Operator |..(Network) |Enterprise |..|-------|..| |..|Operator |..(Network)
|Network | |L-GW | | | |Core network | ======= |Network | |L-GW | | | |Core network | =======
+---------------+-------+ +----------+ +-------------+ +---------------+-------+ +----------+ +-------------+
/ /
| |
/ /
+-----+ +-----+
| UE | | UE |
+-----+ +-----+
Figure 8: LIPA architecture Figure 8: LIPA architecture
The 3GPP architecture specifications also provide mechanisms to allow The 3GPP architecture specifications also provide mechanisms to allow
discovery and selection of gateways [SDO-3GPP.29.303]. These discovery and selection of gateways [SDO-3GPP.29.303]. These
mechanisms enable decisions taking into consideration topological mechanisms enable decisions taking into consideration topological
location and gateway collocation aspects, using heavily the DNS as a location and gateway collocation aspects, relying upon the DNS as a
"location database". "location database".
Both SIPTO and LIPA have a very limited mobility support, specially Both SIPTO and LIPA have a very limited mobility support, specially
in 3GPP specifications up to Rel-12. In a glimpse, LIPA mobility in 3GPP specifications up to Rel-12[CITATION!]. Briefly, LIPA mobility
support is limited to handovers between HeNBs that are managed by the support is limited to handovers between HeNBs that are managed by the
same L-GW (i.e., mobility within the local domain), while seamless same L-GW (i.e., mobility within the local domain), while seamless
SIPTO mobility is still limited to the case where the SGW/PGW is at SIPTO mobility is still limited to the case where the SGW/PGW is at
or above Radio Access Network (RAN) level. or above Radio Access Network (RAN) level.
CEP: But, SGW/PGW is *always* above the RAN!
5. Gap analysis 5. Gap analysis
The goal of this section is to identify the limitations in the The goal of this section is to identify the limitations in the
current practices, described in Section 4, with respect to the DMM current practices, described in Section 4, with respect to the DMM
requirements listed in [I-D.ietf-dmm-requirements]. requirements listed in [I-D.ietf-dmm-requirements].
5.1. Distributed processing - REQ1 5.1. Distributed processing - REQ1
According to requirement #1 stated in [I-D.ietf-dmm-requirements], IP According to requirement #1 stated in [I-D.ietf-dmm-requirements], IP
mobility, network access and routing solutions provided by DMM MUST mobility, network access and routing solutions provided by DMM must
enable distributed processing for mobility management so that traffic enable distributed processing for mobility management so that traffic
can avoid traversing single mobility anchor far from the optimal can avoid traversing single mobility anchor far from the optimal
route. route.
From the analysis performed in Section 4, a DMM deployment can meet From the analysis performed in Section 4, a DMM deployment can meet
the requirement "REQ#1 Distributed processing" usually relying on the the requirement "REQ#1 Distributed processing" usually relying on the
following functions: following functions:
o Multiple (distributed) anchoring: ability to anchor different o Multiple (distributed) anchoring: ability to anchor different
sessions of a single mobile node at different anchors. In order sessions of a single mobile node at different anchors. In order
to make this feature "DMM-friendly", some anchors might need to be to provide improved routing, some anchors might need to be
placed closer to the mobile node. placed closer to the mobile node.
o Dynamic anchor assignment/re-location: ability to i) optimally o Dynamic anchor assignment/re-location: ability to i) assign the
assign initial anchor, and ii) dynamically change the initially initial anchor, and ii) dynamically change the initially
assigned anchor and/or assign a new one (this may also require to assigned anchor and/or assign a new one (this may also require to
transfer mobility context between anchors). This can be achieved transfer mobility context between anchors). This can be achieved
either by changing anchor for all ongoing sessions, or by either by changing anchor for all ongoing sessions, or by
assigning new anchors just for new sessions. assigning new anchors just for new sessions.
Both the main client- and network-based IP mobility protocols, namely Both the main client- and network-based IP mobility protocols, namely
(DS)MIPv6 and PMIPv6 allow deploying multiple anchors (i.e., home (DS)MIPv6 and PMIPv6 allow deploying multiple anchors (i.e., home
agents and localized mobility anchors), therefore providing the agents and localized mobility anchors), therefore providing the
multiple anchoring function. However, existing solutions only multiple anchoring function. However, existing solutions only
provide an optimal initial anchor assignment, thus the lack of provide a initial anchor assignment, thus the lack of
dynamic anchor change/new anchor assignment is a gap. Neither the HA dynamic anchor change/new anchor assignment is a gap. Neither the HA
switch nor the LMA runtime assignment allow changing the anchor switch nor the LMA runtime assignment allow changing the anchor
during an ongoing session. This actually comprises several gaps: during an ongoing session. This actually comprises several gaps:
ability to perform anchor assignment at any time (not only at the ability to perform anchor assignment at any time (not only at the
initial MN's attachment), ability of the current anchor to initiate/ initial MN's attachment), ability of the current anchor to initiate/
trigger the relocation, and ability to transfer registration context trigger the relocation, and ability to transfer registration context
between anchors. between anchors.
Dynamic anchor assignment may lead the MN to manage different Dynamic anchor assignment may lead the MN to manage different
mobility sessions served by different mobility anchors. This is not mobility sessions served by different mobility anchors. This is not
skipping to change at page 18, line 11 skipping to change at page 18, line 11
processing therefore should not contradict with centralized control processing therefore should not contradict with centralized control
plane. Other control plane solutions such as charging, lawful plane. Other control plane solutions such as charging, lawful
interception, etc. should not be limited. Yet combining the control interception, etc. should not be limited. Yet combining the control
plane and data plane routing management (RM) function may limit the plane and data plane routing management (RM) function may limit the
choice to distributing boht data plane and control plane together. choice to distributing boht data plane and control plane together.
In order to enable distributing only the data plane without In order to enable distributing only the data plane without
distributing the control plane, a gap is to split the routing distributing the control plane, a gap is to split the routing
management function into the control plane (RM-CP) and data plane management function into the control plane (RM-CP) and data plane
(RM-DP). (RM-DP).
5.2. Bypassable network-layer mobility support - REQ2 5.2. REQ2: On-demand network-layer mobility support
The need for "bypassable network-layer mobility support" introduced The need for "on-demand network-layer mobility support" introduced
in [I-D.ietf-dmm-requirements] will enable dynamic mobility in [I-D.ietf-dmm-requirements] will enable dynamic mobility
management. Note that this requirement is not on dynamic mobilitly management. Flexibility on the
itself but only enables it. It therefore leaves flexibility on the determination of whether network-layer mobility support is needed.
determination of whether network-layer mobility support is needed and The
the role to use of not use network-layer mobility support. The requirement enables one to choose whether or not use network-layer
requirement only enables one to use or not use network-layer mobility mobility support. It only enables the two following functions:
support. It only enables the which basically leverages the two
following functions:
o Dynamically assign/relocate anchor: a mobility anchor is assigned o Dynamically assign/relocate anchor: a mobility anchor is assigned
only to sessions which uses the network-layer mobility support. only to sessions which uses the network-layer mobility support.
The MN may thus manage more than one session; some of them may be The MN may thus manage more than one session; some of them may be
associated with anchored IP address(es), while the others may be associated with anchored IP address(es), while the others may be
associated with local IP address(es). associated with local IP address(es).
o Multiple IP address management: this function is related to the o Multiple IP address management: this function is related to the
preceding and is about the ability of the mobile node to preceding and is about the ability of the mobile node to
simultaneously use multiple IP addresses and select the best one simultaneously use multiple IP addresses and select the best one
(from an anchoring point of view) to use on a per-session/ (from an anchoring point of view) to use on a per-session/
application/service basis. application/service basis.
CEP: Problem: this requires MN to acquire network topology information
The dynamic anchor assignment/relocation needs to ensure that IP The dynamic anchor assignment/relocation needs to ensure that IP
address continuity is guaranteed for sessions that uses such mobility address continuity is guaranteed for sessions that uses such mobility
support (e.g., in some scenarios, the provision of mobility locally support (e.g., in some scenarios, the provision of mobility locally
within a limited area might be enough from the mobile node or the within a limited area might be enough from the mobile node or the
application point of view) at the relocated anchor. Implicitly, when application point of view) at the relocated anchor. Implicitly, when
no applications are using the network-layer mobility support, DMM may no applications are using the network-layer mobility support, DMM may
releave the needed resources. This may imply having the knowledge of release the needed resources. This may imply having the knowledge of
which sessions at the mobile node are active and are using the which sessions at the mobile node are active and are using the
mobility support. This is something typically known only by the MN mobility support. This is something typically known only by the MN
(e.g., by its connection manager). Therefore, (part of) this (e.g., by its connection manager). Therefore, (part of) this
knowledge might need to be transferred to/shared with the network. knowledge might need to be transferred to/shared with the network.
Multiple IP address management provides the MN with the choice to Multiple IP address management provides the MN with the choice to
pick-up the correct address (provided with mobility support or not) pick-up the correct address (provided with mobility support or not)
depending on the application requirements. When using client based depending on the application requirements. When using client based
mobility management, the mobile node is natively aware about the mobility management, the mobile node is itself aware of the anchoring
anchoring capabilities of its assigned IP addresses. This is not the capabilities of its assigned IP addresses. This is not necessarily the
case with network based IP mobility management and current mechanisms case with network based IP mobility management; current mechanisms
does not allow the MN to be aware of the IP addresses properties do not allow the MN to be aware of the properties of its IP addresses
(i.e., the MN does not know whether the allocated IP addresses are (e.g., the MN does not know whether the allocated IP addresses are
anchored). However, there are ongoing IETF works that are proposing anchored). However, there are proposals
that the network could indicate the different IP addresses properties that the network could indicate such IP address properties
during assignment procedures, such as during assignment procedures, such as
[I-D.bhandari-dhc-class-based-prefix], [I-D.bhandari-dhc-class-based-prefix],
[I-D.korhonen-6man-prefix-properties] and [I-D.anipko-mif-mpvd-arch]. [I-D.korhonen-6man-prefix-properties] and [I-D.anipko-mif-mpvd-arch].
However, although there exist these individual efforts that could be Although there exist these individual efforts that could be
be considered as attempts to fix the gap, there is no solution close be considered as attempts to fix the gap, there is no solution adopted
to be adopted and standardized in IETF. as a work item within any IETF working group.
5.3. IPv6 deployment - REQ3 5.3. IPv6 deployment - REQ3
This requirement states that DMM solutions SHOULD primarily target This requirement states that DMM solutions should primarily target
IPv6 as the primary deployment environment. IPv4 support is not IPv6 as the primary deployment environment. IPv4 support is not
considered mandatory and solutions SHOULD NOT be tailored considered mandatory and solutions should not be tailored
specifically to support IPv4, in particular in situations where specifically to support IPv4.
private IPv4 addresses and/or NATs are used.
CEP: "in particular in situations where private IPv4 addresses
and/or NATs are used." -- why is this needed??
All analyzed DMM practices support IPv6. Some of them, such as MIPv6 All analyzed DMM practices support IPv6. Some of them, such as MIPv6
/NEMO (including the support of dynamic HA selection), MOBIKE, SIPTO /NEMO (including the support of dynamic HA selection), MOBIKE, SIPTO
have also IPv4 support. Additionally, there are also some solutions have also IPv4 support.
CEP: Does this mean that MOBIKE, SIPTO, and NEMO are "analyzed DMM practices"?
There are also some solutions
that have some limited IPv4 support (e.g., PMIPv6). In conclusion, that have some limited IPv4 support (e.g., PMIPv6). In conclusion,
this requirement is met by existing DMM practices. this requirement is met by existing DMM practices.
5.4. Existing mobility protocols - REQ4 5.4. Existing mobility protocols - REQ4
A DMM solution MUST first consider reusing and extending IETF- A DMM solution must first consider reusing and extending IETF-
standardized protocols before specifying new protocols. standardized protocols before specifying new protocols.
As stated in [I-D.ietf-dmm-requirements], a DMM solution could reuse As stated in [I-D.ietf-dmm-requirements], a DMM solution could reuse
existing IETF and standardized protocols before specifying new existing IETF and standardized protocols before specifying new
protocols. Besides, Section 4 of this document discusses various protocols. Besides, Section 4 of this document discusses various
ways to flatten and distribute current mobility solutions. Actually, ways to flatten and distribute current mobility solutions. Actually,
nothing prevent the distribution of mobility functions with vanilla nothing prevent the distribution of mobility functions with vanilla
CEP: "vanilla"??
IP mobility protocols. However, as discussed in Section 5.1 and IP mobility protocols. However, as discussed in Section 5.1 and
Section 5.2, limitations exist. The 3GPP data plane anchoring Section 5.2, limitations exist. The 3GPP data plane anchoring
function, i.e., the PGW, can be also be distributed, but with function, i.e., the PGW, can be also be distributed, but with
limitations; e.g., no anchoring relocation, no context transfer limitations; e.g., no anchoring relocation, no context transfer
between anchors, centralized control plane. The 3GPP architecture is between anchors, centralized control plane. The 3GPP architecture is
also going into the direction of flattening with SIPTO and LIPA, also going into the direction of flattening with SIPTO and LIPA,
though they do not provide mobility support. though they do not provide mobility support.
5.5. Co-existence - REQ5 5.5. Co-existence - REQ5
According to [I-D.ietf-dmm-requirements], DMM solution MUST be able According to [I-D.ietf-dmm-requirements], DMM solution must be able
to co-exist with existing network deployments, end hosts and routers. to co-exist with existing network deployments, end hosts and routers.
All current mobility protocols can co-exist with existing network All current mobility protocols can co-exist with existing network
deployments and end hosts. There is no gap between existing mobility deployments and end hosts. There is no gap between existing mobility
protocols and this requirement. protocols and this requirement.
CEP: "can co-exist with" means "do not interfere with"?
5.6. Security considerations - REQ6 5.6. Security considerations - REQ6
As stated in [I-D.ietf-dmm-requirements], a DMM solution MUST NOT NOT As stated in [I-D.ietf-dmm-requirements], a DMM solution must NOT
introduce new security risks, or amplify existing security risks, introduce new security risks, or amplify existing security risks,
that cannot be mitigated by existing security mechanisms or that cannot be mitigated by existing security mechanisms or
protocols. Current mobility protocols have all security mechanisms protocols. Current mobility protocols have all security mechanisms
in place. For example, Mobile IPv6 defines security features to in place. For example, Mobile IPv6 defines security features to
protect binding updates both to home agents and correspondent nodes. protect binding updates both to home agents and correspondent nodes.
It also defines mechanisms to protect the data packets transmission It also defines mechanisms to protect the data packets transmission
for Mobile IPv6 users. Proxy Mobile IPv6 and other variation of for Mobile IPv6 users. Proxy Mobile IPv6 and other variations of
mobile IP also have similar security considerations. mobile IP also have similar security considerations.
5.7. Multicast - REQ7 5.7. Multicast - REQ7
It is stated in [I-D.ietf-dmm-requirements] that DMM solutions SHOULD It is stated in [I-D.ietf-dmm-requirements] that DMM solutions should
enable multicast solutions to be developed to avoid network enable multicast solutions to be developed to avoid network
inefficiency in multicast traffic delivery. inefficiency in multicast traffic delivery.
Current IP mobility solutions address mainly the mobility problem for Current IP mobility solutions address mainly the mobility problem for
unicast traffic. Solutions relying on the use of an anchor point for unicast traffic. Solutions relying on the use of an anchor point for
tunneling multicast traffic down to the access router, or to the tunneling multicast traffic down to the access router, or to the
mobile node, introduce the so-called "tunnel convergence problem". mobile node, introduce the so-called "tunnel convergence problem".
This means that multiple instances of the same multicast traffic can This means that multiple instances of the same multicast traffic can
converge to the same node, defeating hence the advantage of using converge to the same node, diminishing the advantage of using
multicast protocols. multicast protocols.
The MULTIMOB WG in IETF has studied this issue, for the specific case The MULTIMOB WG in IETF has studied this issue, for the specific case
of PMIPv6, and has produced a baseline solution [RFC6224] as well as of PMIPv6, and has produced a baseline solution [RFC6224] as well as
a routing optimization solution [RFC7028] to address the problem. a routing optimization solution [RFC7028] to address the problem.
The baseline solution suggests deploying an MLD proxy function at the The baseline solution suggests deploying an MLD proxy function at the
MAG, and either a multicast router or another MLD proxy function at MAG, and either a multicast router or another MLD proxy function at
the LMA. The routing optimization solution describes an architecture the LMA. The routing optimization solution describes an architecture
where a dedicated multicast tree mobility anchor (MTMA) or a direct where a dedicated multicast tree mobility anchor (MTMA) or a direct
routing option can be used to avoid the tunnel convergence problem. routing option can be used to avoid the tunnel convergence problem.
CEP: What is "a direct routing option"?
Besides the solutions proposed in MULTIMOB for PMIPv6, there are no Besides the solutions proposed in MULTIMOB for PMIPv6, within the IETF
there are no other
solutions for other mobility protocols to address the multicast solutions for other mobility protocols to address the multicast
tunnel convergence problem. tunnel convergence problem.
5.8. Summary 5.8. Summary
We next list the main gaps identified from the analysis performed We next list the main gaps identified from the analysis performed
above: above:
o Existing solutions do only provide an optimal initial anchor o Existing solutions only provide an optimal initial anchor
assignment, a gap being the lack of dynamic anchor change/new assignment, a gap being the lack of dynamic anchor change/new
anchor assignment. Neither the HA switch nor the LMA runtime anchor assignment. Neither the HA switch nor the LMA runtime
assignment allow changing the anchor during an ongoing session. assignment allow changing the anchor during an ongoing session.
While MOBIKE could be used to switch from a gateway to another in 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 the middle of a session from MN side, there is no protocol support
for the network side. for the network side.
CEP: What about HAHA?
o The mobile node needs to simultaneously use multiple IP addresses, o The mobile node needs to simultaneously use multiple IP addresses,
which requires additional support which might not be available on which requires support which might not be available on
the mobile node's stack, especially for the case of network-based the mobile node's stack, especially for the case of network-based
solutions. solutions.
CEP: All IPv6 nodes can use multiple IP addresses. Something here is
not stated correctly.
o Currently, there is no efficient mechanism specified by the IETF o Currently, there is no efficient mechanism specified by the IETF
that allows to dynamically discover the presence of nodes that can that allows to dynamically discover the presence of nodes that can
play the role of anchor, discover their capabilities and allow the play the role of anchor, discover their capabilities and allow the
selection of the most suitable one. There are though some selection of the most suitable one. However, the following
mechanisms that could help discovering anchors, such as the mechanisms that could help discovering anchors:
Dynamic Home Agent Address Discovery (DHAAD), the use of the Home o Dynamic Home Agent Address Discovery (DHAAD)
Agent (H) flag in Router Advertisements (which indicates that the o the use of the Home Agent (H) flag in Router Advertisements
router sending the Router Advertisement is also functioning as a (which indicates that the router sending the Router Advertisement
Mobile IPv6 home agent on the link) or the MAP option in Router is also functioning as a Mobile IPv6 home agent on the link), and
Advertisements defined by HMIPv6. o the MAP option in Router Advertisements defined by HMIPv6.
o While existing network-based DMM practices may allow to deploy o While existing network-based DMM practices may allow to deploy
multiple LMAs and dynamically select the best one, this requires multiple LMAs and dynamically select the best one, this requires
to still keep some centralization in the control plane, to access to still keep some centralization in the control plane, to access
on the policy store (as defined in RFC5213). Currently, there is the policy database (as defined in RFC5213). Currently, there is
a lack of solutions/extensions that support a clear control and a lack of solutions/extensions that support a clear control and
data plane separation for IETF IP mobility protocols. data plane separation for IETF IP mobility protocols.
CEP: There is the CP-UP separation document adopted within [netext]
6. Security Considerations 6. Security Considerations
This document does not define any protocol, so it does not introduce This document does not define any protocol, so it does not introduce
any new security concern. any new security concern.
7. IANA Considerations 7. IANA Considerations
None. None.
 End of changes. 91 change blocks. 
121 lines changed or deleted 196 lines changed or added

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