draft-ietf-dmm-best-practices-gap-analysis-01.txt   draft-ietf-dmm-best-practices-gap-analysis-02.txt 
DMM D. Liu, Ed. DMM D. Liu, Ed.
Internet-Draft China Mobile Internet-Draft China Mobile
Intended status: Informational JC. Zuniga, Ed. Intended status: Informational JC. Zuniga, Ed.
Expires: December 19, 2013 InterDigital Expires: April 23, 2014 InterDigital
P. Seite P. Seite
Orange Orange
H. Chan H. Chan
Huawei Technologies Huawei Technologies
CJ. Bernardos CJ. Bernardos
UC3M UC3M
June 17, 2013 October 20, 2013
Distributed Mobility Management: Current practices and gap analysis Distributed Mobility Management: Current practices and gap analysis
draft-ietf-dmm-best-practices-gap-analysis-01 draft-ietf-dmm-best-practices-gap-analysis-02
Abstract Abstract
The present document analyses deplyment practices of existing The present document analyses deplyment practices of existing
mobility protocols in a distributed mobility management environment. mobility protocols in a distributed mobility management environment.
It also identifies some limitations compared to the expected It also identifies some limitations compared to the expected
functionality of a fully distributed mobility management system. The functionality of a fully distributed mobility management system. The
comparison is made taking into account the identified DMM comparison is made taking into account the identified DMM
requirements. requirements.
skipping to change at page 1, line 42 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 19, 2013. This Internet-Draft will expire on April 23, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Functions of existing mobility protocols . . . . . . . . . . . 4 3. Functions of existing mobility protocols . . . . . . . . . . . 4
4. DMM practices . . . . . . . . . . . . . . . . . . . . . . . . 5 4. DMM practices . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. IP flat wireless network . . . . . . . . . . . . . . . . . 6 4.2. IP flat wireless network . . . . . . . . . . . . . . . . . 6
4.2.1. Host-based IP DMM practices . . . . . . . . . . . . . 8 4.2.1. Host-based IP DMM practices . . . . . . . . . . . . . 8
4.2.2. Network-based IP DMM practices . . . . . . . . . . . . 11 4.2.2. Network-based IP DMM practices . . . . . . . . . . . . 12
4.3. 3GPP network flattening approaches . . . . . . . . . . . . 13 4.3. 3GPP network flattening approaches . . . . . . . . . . . . 14
5. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 5.1. Distributed processing - REQ1 . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 5.2. Transparency to Upper Layers - REQ2 . . . . . . . . . . . 19
8. Informative References . . . . . . . . . . . . . . . . . . . . 18 5.3. IPv6 deployment - REQ3 . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 5.4. Existing mobility protocols - REQ4 . . . . . . . . . . . . 20
5.5. Co-existence - REQ5 . . . . . . . . . . . . . . . . . . . 20
5.6. Security considerations - REQ6 . . . . . . . . . . . . . . 20
5.7. Multicast - REQ7 . . . . . . . . . . . . . . . . . . . . . 21
5.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The distributed mobility management (DMM) WG has studied the problems The distributed mobility management (DMM) WG has studied the problems
of centralized deployment of mobility management protocols and the of centralized deployment of mobility management protocols and the
related requirements [I-D.ietf-dmm-requirements]. In order to guide related requirements [I-D.ietf-dmm-requirements]. In order to guide
the deployment and before defining any new DMM protocol, the DMM WG the deployment and before defining any new DMM protocol, the DMM WG
is chartered to investigate first whether it is feasible to deploy is chartered to investigate first whether it is feasible to deploy
current IP mobility protocols in a DMM scenario in a way that can current IP mobility protocols in a DMM scenario in a way that can
fullfil the requirements of DMM. This document discusses current fullfil the requirements of DMM. This document discusses current
skipping to change at page 3, line 28 skipping to change at page 3, line 28
The rest of this document is organized as follows. Section 3 The rest of this document is organized as follows. Section 3
analyzes existing IP mobility protocols by examining their functions analyzes existing IP mobility protocols by examining their functions
and how these functions can be reconfigured to work in a DMM and how these functions can be reconfigured to work in a DMM
environment. Section 4 presents the current practices of IP flat environment. Section 4 presents the current practices of IP flat
wireless networks and 3GPP architectures. Both network- and host- wireless networks and 3GPP architectures. Both network- and host-
based mobility protocols are considered. Section 5 presents the gap based mobility protocols are considered. Section 5 presents the gap
analysis with respect to the current practices. analysis with respect to the current practices.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
All general mobility-related terms and their acronyms used in this All general mobility-related terms and their acronyms used in this
document are to be interpreted as defined in the Mobile IPv6 base document are to be interpreted as defined in the Mobile IPv6 base
specification [RFC6275] and in the Proxy mobile IPv6 specification specification [RFC6275] and in the Proxy mobile IPv6 specification
[RFC5213]. These terms include mobile node (MN), correspondent node [RFC5213]. These terms include mobile node (MN), correspondent node
(CN), home agent (HA), local mobility anchor (LMA), and mobile access (CN), home agent (HA), local mobility anchor (LMA), and mobile access
gateway (MAG). gateway (MAG).
In addition, this document uses the following terms: In addition, this document uses the following terms:
Mobility routing (MR) is the logical function that intercepts Mobility routing (MR) is the logical function that intercepts
skipping to change at page 6, line 14 skipping to change at page 6, line 23
1. Both host- and network-based solutions should be covered. 1. Both host- and network-based solutions should be covered.
2. Solution should allow selecting and using the most appropriate IP 2. Solution should allow selecting and using the most appropriate IP
anchor among a set of distributed ones. anchor among a set of distributed ones.
3. Mobility management should be realized by the preservation of the 3. Mobility management should be realized by the preservation of the
IP address across the different points of attachment during the IP address across the different points of attachment during the
mobility (i.e., provision of IP address continuity). IP flows of mobility (i.e., provision of IP address continuity). IP flows of
applications which do not need a constant IP address should not applications which do not need a constant IP address should not
be handled by DMM. It is typically the role of a connection be handled by DMM. Typically, the a connection manager together
manager to distinguish application capabilities and trigger the with the operating system configure the source address selection
mobility support accordingly. Further considerations on mechanism of the IP stack. This might involve identifying
application management are out of the scope of this document. application capabilities and triggering the mobility support
accordingly. Further considerations on application management
and source address selection are out of the scope of this
document.
4. Mobility management and traffic redirection should only be 4. Mobility management and traffic redirection should only be
triggered due to IP mobility reasons, that is when the MN moves triggered due to IP mobility reasons, that is when the MN moves
from the point of attachment where the IP flow was originally from the point of attachment where the IP flow was originally
initiated. initiated.
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. Since WiFi is the most view using common and standardized protocols. We take WiFi an
widely deployed wireless access technology nowadays, we take it as exemplary wireless technology, as it is widely known and deployed
example in the following. Some representative examples of WiFi nowadays. Some representative examples of WiFi deployed
deployed architectures are depicted on Figure 1. architectures are depicted on Figure 1.
+-------------+ _----_ +-------------+ _----_
+---+ | Access | _( )_ +---+ | Access | _( )_
|AAA|. . . . . . | Aggregation |----------( Internet ) |AAA|. . . . . . | Aggregation |----------( Internet )
+---+ | Gateway | (_ _) +---+ | Gateway | (_ _)
+-------------+ '----' +-------------+ '----'
| | | | | |
| | +-------------+ | | +-------------+
| | | | | |
| | +-----+ | | +-----+
skipping to change at page 8, line 6 skipping to change at page 8, line 6
In some network architectures, such as the evolved Wi-Fi hotspot, In some network architectures, such as the evolved Wi-Fi hotspot,
operators might make use of IP mobility protocols to provide mobility operators might make use of IP mobility protocols to provide mobility
support to users, for example to allow connecting the IP WiFi network support to users, for example to allow connecting the IP WiFi network
to a mobile operator core and support roaming between WLAN and 3GPP to a mobile operator core and support roaming between WLAN and 3GPP
accesses. Two main protocols can be used: Proxy Mobile IPv6 accesses. Two main protocols can be used: Proxy Mobile IPv6
[RFC5213] or Mobile IPv6 [RFC6275], [RFC5555], with the anchor role [RFC5213] or Mobile IPv6 [RFC6275], [RFC5555], with the anchor role
(e.g., local mobility anchor or home agent) typically being played by (e.g., local mobility anchor or home agent) typically being played by
the Access Aggregation Gateway or even by an entity placed on the the Access Aggregation Gateway or even by an entity placed on the
mobile operator's core network. mobile operator's core network.
Although we have adopted in this section the example of WiFi
networks, there are other IP flat wireless network architectures
specified, such as WiMAX [IEEE.802-16.2009], which integrates both
host and network-based IP mobility functionality.
Existing IP mobility protocols can also be deployed in a "flatter" Existing IP mobility protocols can also be deployed in a "flatter"
way, so the anchoring and access aggregation functions are way, so the anchoring and access aggregation functions are
distributed. We next describe several practices for the deployment distributed. We next describe several practices for the deployment
of existing mobility protocols in a distributed mobility management of existing mobility protocols in a distributed mobility management
environment. We limit our analysis in this section to protocol environment. We limit our analysis in this section to protocol
solutions based on existing IP mobility protocols, either host- or solutions based on existing IP mobility protocols, either host- or
network-based, such as Mobile IPv6 [RFC6275], [RFC5555], Proxy Mobile network-based, such as Mobile IPv6 [RFC6275], [RFC5555], Proxy Mobile
IPv6 [RFC5213], [RFC5844] and NEMO [RFC3963]. Extensions to these IPv6 [RFC5213], [RFC5844] and NEMO [RFC3963]. Extensions to these
base protocol solutions are also considered. We pay special base protocol solutions are also considered. We pay special
attention to the management of the use of care-of-addresses versus attention to the management of the use of care-of-addresses versus
skipping to change at page 8, line 44 skipping to change at page 8, line 49
One approach to distribute the anchors can be to deploy several HAs One approach to distribute the anchors can be to deploy several HAs
(as shown in Figure 2), and assign to each MN the one closest to its (as shown in Figure 2), and assign to each MN the one closest to its
topological location [RFC4640], [RFC5026], [RFC6611]. In the example topological location [RFC4640], [RFC5026], [RFC6611]. In the example
shown in Figure 2, MN1 is assigned HA1 (and a home address anchored shown in Figure 2, MN1 is assigned HA1 (and a home address anchored
by HA1), while MN2 is assigned HA2. Note that Mobile IPv6 / NEMO by HA1), while MN2 is assigned HA2. Note that Mobile IPv6 / NEMO
specifications do not prevent the simultaneous use of multiple home specifications do not prevent the simultaneous use of multiple home
agents by a single mobile node. This deployment model could be agents by a single mobile node. This deployment model could be
exploited by a mobile node to meet assumption #4 and use several exploited by a mobile node to meet assumption #4 and use several
anchors at the same time, each of them anchoring IP flows initiated anchors at the same time, each of them anchoring IP flows initiated
at different point of attachment. However there is no mechanism at different point of attachment. However there is no mechanism
specified to enable an efficient dynamic discovery of available specified by the IETF to enable an efficient dynamic discovery of
anchors and the selection of the most suitable one. available anchors and the selection of the most suitable one. Note
that some of these mechanisms have been defined outside the IETF
(e.g., 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 45 skipping to change at page 9, line 46
achieve a flatter IP data forwarding. By default, Mobile IPv6 and achieve a flatter IP data forwarding. By default, Mobile IPv6 and
NEMO use the so-called Bidirectional Tunnel (BT) mode, in which data NEMO use the so-called Bidirectional Tunnel (BT) mode, in which data
traffic is always encapsulated between the MN and its HA before being traffic is always encapsulated between the MN and its HA before being
directed to any other destination. The Route Optimization (RO) mode directed to any other destination. The Route Optimization (RO) mode
allows the MN to update its current location on the CNs, and then use allows the MN to update its current location on the CNs, and then use
the direct path between them. Using the example shown in Figure 2, the direct path between them. Using the example shown in Figure 2,
MN1 is using BT mode with CN2 and MN2 is in RO mode with CN1. MN1 is using BT mode with CN2 and MN2 is in RO mode with CN1.
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, although optimization support standardized for the NEMO protocol because of
many different solutions have been proposed. the security problems posed by extending return routability tests
for prefixes, although many different solutions have been
proposed.
o The RO mode requires additional signaling, which adds some o The RO mode requires additional signaling, which adds some
protocol overhead. protocol overhead.
o The signaling required to enable RO involves the home agent, and o The signaling required to enable RO involves the home agent, and
it is repeated periodically because of security reasons [RFC4225]. it is repeated periodically because of security reasons [RFC4225].
This basically means that the HA remains as single point of This basically means that the HA remains as single point of
failure, because the Mobile IPv6 RO mode does not mean HA-less failure, because the Mobile IPv6 RO mode does not mean HA-less
operation. operation.
o The RO mode requires additional support on the correspondent node o The RO mode requires additional support on the correspondent node
(CN). (CN).
Notwithstanding these considerations, the RO mode does offer the Notwithstanding these considerations, the RO mode does offer the
possibility of substantially reducing traffic through the Home Agent, possibility of substantially reducing traffic through the Home Agent,
in cases when it can be supported on the relevant correspondent in cases when it can be supported on the relevant correspondent
skipping to change at page 10, line 15 skipping to change at page 10, line 20
This basically means that the HA remains as single point of This basically means that the HA remains as single point of
failure, because the Mobile IPv6 RO mode does not mean HA-less failure, because the Mobile IPv6 RO mode does not mean HA-less
operation. operation.
o The RO mode requires additional support on the correspondent node o The RO mode requires additional support on the correspondent node
(CN). (CN).
Notwithstanding these considerations, the RO mode does offer the Notwithstanding these considerations, the RO mode does offer the
possibility of substantially reducing traffic through the Home Agent, possibility of substantially reducing traffic through the Home Agent,
in cases when it can be supported on the relevant correspondent in cases when it can be supported on the relevant correspondent
nodes. nodes. Note that a mobile node can also use its CoA directly
[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.
<- 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 11, line 45 skipping to change at page 12, line 33
protocol in a distributed mobility management environment is the the protocol in a distributed mobility management environment is the the
Home Agent switch specification [RFC5142], which defines a new Home Agent switch specification [RFC5142], which defines a new
mobility header for signaling a mobile node that it should acquire a mobility header for signaling a mobile node that it should acquire a
new home agent. Even though the purposes of this specification do new home agent. Even though the purposes of this specification do
not include the case of changing the mobile node's home address, as not include the case of changing the mobile node's home address, as
that might imply loss of connectivity for ongoing persistent that might imply loss of connectivity for ongoing persistent
connections, it could be used to force the change of home agent in connections, it could be used to force the change of home agent in
those situations where there are no active persistent data sessions those situations where there are no active persistent data sessions
that cannot cope with a change of home address. that cannot cope with a change of home address.
There other host-based approaches standardized within the IETF that
can be used to provide mobility support. For example MOBIKE
[RFC4555] allows a mobile node encrypting traffic through IKEv2
[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.
4.2.2. Network-based IP DMM practices 4.2.2. Network-based IP DMM practices
Proxy Mobile IPv6 (PMIPv6) [RFC5213] is the main network-based IP Proxy Mobile IPv6 (PMIPv6) [RFC5213] is the main network-based IP
mobility protocol specified for IPv6 ([RFC5844] defines some IPv4 mobility protocol specified for IPv6 ([RFC5844] defines some IPv4
extensions). Architecturally, PMIPv6 is similar to MIPv6, as it extensions). Architecturally, PMIPv6 is similar to MIPv6, as it
relies on the function of the Local Mobility Anchor (LMA) to provide relies on the function of the Local Mobility Anchor (LMA) to provide
mobile nodes with mobility support, without requiring the involvement mobile nodes with mobility support, without requiring the involvement
of the mobile nodes. The required functionality at the mobile node of the mobile nodes. The required functionality at the mobile node
is provided in a proxy manner by the Mobile Access Gateway (MAG). is provided in a proxy manner by the Mobile Access Gateway (MAG).
With network-based IP mobility protocols, the local mobility anchor With network-based IP mobility protocols, the local mobility anchor
skipping to change at page 13, line 32 skipping to change at page 14, line 33
[RFC6463]. This extension specifies a runtime local mobility anchor [RFC6463]. This extension specifies a runtime local mobility anchor
assignment functionality and corresponding mobility options for Proxy assignment functionality and corresponding mobility options for Proxy
Mobile IPv6. This runtime local mobility anchor assignment takes Mobile IPv6. This runtime local mobility anchor assignment takes
place during the Proxy Binding Update / Proxy Binding Acknowledgment place during the Proxy Binding Update / Proxy Binding Acknowledgment
message exchange between a mobile access gateway and a local mobility message exchange between a mobile access gateway and a local mobility
anchor. While this mechanism is mainly aimed for load-balancing anchor. While this mechanism is mainly aimed for load-balancing
purposes, it can also be used to select an optimal LMA from the purposes, it can also be used to select an optimal LMA from the
routing point of view. A runtime LMA assignment can be used to routing point of view. A runtime LMA assignment can be used to
change the assigned LMA of an MN, for example in case when the mobile change the assigned LMA of an MN, for example in case when the mobile
node does not have any session active, or when running sessions can node does not have any session active, or when running sessions can
survive an IP address change. survive an IP address change. Note that several possible dynamic
local mobility anchor discovery solutions can be used, as described
in [RFC6097].
4.3. 3GPP network flattening approaches 4.3. 3GPP network flattening approaches
The 3rd Generation Partnership Project (3GPP) is the standard The 3rd Generation Partnership Project (3GPP) is the standard
development organization that specifies the 3rd generation mobile development organization that specifies the 3rd generation mobile
network and LTE (Long Term Evolution). network and 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
skipping to change at page 14, line 41 skipping to change at page 15, line 41
| | +------------------------+ | | | | | k | | | +------------------------+ | | | | | k |
| +---+ Trusted non-3GPP AN +-S2a--------------+ | | | s | | +---+ Trusted non-3GPP AN +-S2a--------------+ | | | s |
| | +------------------------+ | | | | | | | | +------------------------+ | | | | | |
| | | +-+-+ | | | | | | +-+-+ | | |
| +--------------------------S2c--------------------| | | | | +--------------------------S2c--------------------| | | |
| | | | | | | | | | | |
+----+ +--------------------+ +---+ +----+ +--------------------+ +---+
Figure 5: EPS (non-roaming) architecture overview Figure 5: EPS (non-roaming) architecture overview
GPRS Tunnelling Protocol (GTP) [3GPP.29.060] is a network-based GPRS Tunnelling Protocol (GTP) [3GPP.29.060] [3GPP.29.281]
mobility protocol specified for 3GPP networks (S2a, S2b, S5 and S8 [3GPP.29.274] is a network-based mobility protocol specified for 3GPP
interfaces). Similar to PMIPv6, it can handle mobility without networks (S2a, S2b, S5 and S8 interfaces). Similar to PMIPv6, it can
requiring the involvement of the mobile nodes. In this case, the handle mobility without requiring the involvement of the mobile
mobile node functionality is provided in a proxy manner by the nodes. In this case, the mobile node functionality is provided in a
Serving Data Gateway (SGW), Evolved Packet Data Gateway (ePDG), or proxy manner by the Serving Data Gateway (SGW), Evolved Packet Data
Trusted Wireless Access Gateway (TWAG). Gateway (ePDG), or Trusted Wireless Access Gateway (TWAG).
3GPP specifications also include client-based mobility support, based 3GPP specifications also include client-based mobility support, based
on adopting the use of Dual-Stack Mobile IPv6 (DSMIPv6) [RFC5555] for on adopting the use of Dual-Stack Mobile IPv6 (DSMIPv6) [RFC5555] for
the S2c interface. In this case, the UE implements the mobile node the S2c interface. In this case, the UE implements the mobile node
functionality, while the home agent role is played by the PGW. functionality, while the home agent role is played by the PGW.
A Local IP Access (LIPA) and Selected IP Traffic Offload (SIPTO) A Local IP Access (LIPA) and Selected IP Traffic Offload (SIPTO)
enabled network [3GPP.23.829] allows offloading some IP services at enabled network [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 the macro, without the need to traverse back to the PGW (see
Figure 6. Figure 6.
+---------+ IP traffic to mobile operator's CN +---------+ IP traffic to mobile operator's CN
| User |....................................(Operator's CN) | User |....................................(Operator's CN)
| Equipm. |.................. | Equipm. |..................
+---------+ . Local IP traffic +---------+ . Local IP traffic
. .
+-----------+ +-----------+
skipping to change at page 16, line 19 skipping to change at page 17, line 19
+---------------+-------+ +----------+ +-------------+ +---------------+-------+ +----------+ +-------------+
/ /
| |
/ /
+-----+ +-----+
| UE | | UE |
+-----+ +-----+
Figure 8: LIPA architecture Figure 8: LIPA architecture
The 3GPP architecture specifications also provide mechanisms to allow
discovery and selection of gateways [3GPP.29.303]. These mechanisms
enable taking decisions taking into consideration topological
location and gateway collocation aspects, using heavily the DNS as a
"location database".
Both SIPTO and LIPA have a very limited mobility support, specially Both SIPTO and LIPA have a very limited mobility support, specially
in 3GPP specifications up to Rel-10. In Rel-11, there is currently a in 3GPP specifications up to Rel-10. In Rel-11, there is currently a
work item on LIPA Mobility and SIPTO at the Local Network (LIMONET) work item on LIPA Mobility and SIPTO at the Local Network (LIMONET)
[3GPP.23.859] that is studying how to provide SIPTO and LIPA [3GPP.23.859] that is studying how to provide SIPTO and LIPA
mechanisms with some additional, but still limited, mobility support. mechanisms with some additional, but still limited, mobility support.
In a glimpse, LIPA mobility support is limited to handovers between In a glimpse, LIPA mobility support is limited to handovers between
HeNBs that are managed by the same L-GW (i.e., mobility within the HeNBs that are managed by the same L-GW (i.e., mobility within the
local domain), while seamless SIPTO mobility is still limited to the local domain), while seamless SIPTO mobility is still limited to the
case where the SGW/PGW is at or above Radio Access Network (RAN) case where the SGW/PGW is at or above Radio Access Network (RAN)
level. level.
5. Gap analysis 5. Gap analysis
The goal of this section is to identify the limitations in the The goal of this section is to identify the limitations in the
current practices with respect to providing the expected DMM current practices, described in Section 4, with respect to the
functionality. expected DMM requirements listed in [I-D.ietf-dmm-requirements].
From the analysis performed in Section 4, we can first identify a 5.1. Distributed processing - REQ1
basic set of functions that a DMM solution needs to provide:
According to requirement #1 stated in [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
does not need to traverse centrally deployed mobility anchors and
thereby avoid non-optimal routes.
From the analysis performed in Section 4, a DMM deployment can meet
the requirement "REQ#1 Distributed processing" usually relying on the
following functions:
o Multiple (distributed) anchoring: ability to anchor different o Multiple (distributed) anchoring: ability to anchor different
sessions of a single mobile node at different anchors. In order sessions of a single mobile node at different anchors. In order
to make this feature "DMM-friendly", some anchors might need to be to make this feature "DMM-friendly", some anchors might need to be
placed closer to the mobile node. placed closer to the mobile node.
o Dynamic anchor assignment/re-location: ability to i) optimally o Dynamic anchor assignment/re-location: ability to i) optimally
assign initial anchor, and ii) dynamically change the initially assign initial anchor, and ii) dynamically change the initially
assigned anchor and/or assign a new one (this may also require to assigned anchor and/or assign a new one (this may also require to
transfer mobility context between anchors). This can be achieved transfer mobility context between anchors). This can be achieved
either by changing anchor for all ongoing sessions, or by either by changing anchor for all ongoing sessions, or by
assigning new anchors just for new sessions. assigning new anchors just for new sessions.
o Multiple IP address management: ability of the mobile node to Both the main client- and network-based IP mobility protocols, namely
(DS)MIPv6 and PMIPv6 allows to deploy multiple anchors (i.e., home
agents and localized mobility anchors), therefore providing the
multiple anchoring function. However, existing solutions do 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. 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 of transferring registration context between
anchors.
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, it may raise issues with network based mobility
management. In this case, the mobile client, located in the network
(e.g., MAG), usually retrieves the MN's anchor from the MN's policy
profile (e.g., Section 6.2 of [RFC5213]). Currently, the MN's policy
profile implicitly assumes a single serving anchor and, thus, does
not maintain the association between home network prefix and anchor.
The consequence of the distribution of the mobility anchors is that
there might be more than one available anchor for a mobile node to
use, so leading to an anchor discovery and selection issue.
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. Note that there are 3GPP
mechanisms providing this functionality defined in [3GPP.29.303].
5.2. Transparency to Upper Layers - REQ2
The need for "transparency to upper layer", introduced in
[I-D.ietf-dmm-requirements], requires dynamic mobility management,
which basically leverages the two following functions:
o Dynamically assign/relocate anchor: a mobility anchor is assigned
only to sessions which require IP continuity 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).
o Multiple IP address management: this function is ensued from the
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. Depending on the mobile node support, application/service basis.
this functionality might require more or less support from the
network side. This is typically the role of a connection manager.
In order to summarize the previously listed functions, Figure 9 shows The dynamic anchor assignment/relocation needs to ensure that IP
an example of a conceptual DMM solution deployment. address continuity is guaranteed for sessions that need it and while
needed (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. This for example implies
having the knowledge of which sessions are active at the mobile node,
which is something typically known only by the MN e.g., by its
connection manager). Therefore, (part of) this knowledge might need
to be transferred to/shared with the network.
( ) Multiple IP address management requires the MN to pick-up the correct
+------------------------------------------------+ address (with mobility support or not) depending on the application
/ | \ requirements. When using client based mobility management, the
/ * Internet | x Internet \ Internet mobile node is natively aware about the anchoring capabilities of its
/ * / access | x / access \ / access assigned IP addresses. This is not the case with network based IP
/ * / (IP a) | x / (IP b) \ / mobility management and current mechanisms does not allow the MN to
--+------+----- ----+-----+---- ------+---+---- be aware of the IP addresses properties (i.e. the MN does not know
| distributed | * * *| distributed | | distributed | whether the allocated IP addresses are anchored). However, there are
| anchor 1 | | anchor i | | anchor n | ongoing IETF works that are proposing that the network could indicate
---+----------- ---+----------- ---+----------- the different IP addresses properties during assignment procedures
| | | [I-D.bhandari-dhc-class-based-prefix],
(o) (o) (o) [I-D.korhonen-6man-prefix-properties].
session X * x session Y
anchored * x anchored
at 1 * x at i
(IP a) (o) (IP b)
|
+--+--+
| MN1 |
+-----+
Figure 9: DMM functions 5.3. IPv6 deployment - REQ3
Based on the analysis performed in Section 4, the following list of This requirement states that DMM solutions SHOULD primariliy target
gaps can be identified: IPv6 as the primary deployment environment.. IPv4 support is not
considered mandatory and SHOULD NOT be tailored specifically to
support IPv4, in particular in situations where private IPv4
addresses and/or NATs are used.
o Both the main client- and network-based IP mobility protocols, All analyzed DMM practices support IPv6. Some of them, such as
namely (DS)MIPv6 and PMIPv6 allows to deploy multiple anchors MIPv6/NEMO (including the support of dynamic HA selection), MOBIKE,
(i.e., home agents and localized mobility anchors), therefore SIPTO have also IPv4 support. Additionally, there are also some
providing the multiple anchoring function. However, existing solutions that have some limited IPv4 support (e.g., PMIPv6). In
solutions do only provide an optimal initial anchor assignment, a conclusion, this requirement is met by existing DMM practices.
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. 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 of
transferring registration context between anchors.
o The dynamic anchor relocation needs to ensure that IP address 5.4. Existing mobility protocols - REQ4
continuity is guaranteed for sessions that need it at the
relocated anchor. This for example implies having the knowledge
of which sessions are active at the mobile node, which is
something typically known only by the MN (namely, by its
connection manager). Therefore, (part of) this knowledge might
need to be transferred to/shared with the network.
o Dynamic discovery and selection of anchors. There might be more A DMM solution SHOULD first consider reusing and extending IETF-
than one available anchor for a mobile node to use. Currently, standardized protocols before specifying new protocols.
there is no efficient mechanism 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.
o NOTE: This section is in progress. More gaps are still to be As stated in [I-D.ietf-dmm-requirements], a DMM solution could reuse
identified and more text added to these bullets (perhaps even existing IETF and standardized protocols before specifying new
assigning one subsection to each one). More discussion/feedback protocols. Besides, Section 4 of this document discusses various
from the group is still needed. ways to flatten and distribute current mobility solutions. Actually,
nothing prevent the distribution of mobility functions with vanilla
IP mobility protocols. However, as discussed in Section 5.1 and
Section 5.2, 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
where IP anchoring function, however these solutions are supposed to
be deployed do and, thus, do not provide mobility support. In
conclusion this requirement can be met, DMM can reuse existing
mobility solutions, however some limitations exist.
5.5. Co-existence - REQ5
According to [I-D.ietf-dmm-requirements], DMM solution should be able
to co-exist with existing network deployments and end hosts. All of
current mobility protocols can co-exist with existing network
deployments and end hosts. There is no gap between existing mobility
protocols and this requirement.
5.6. Security considerations - REQ6
As stated in [I-D.ietf-dmm-requirements], a DMM solution MUST NOT
introduce new security risks or amplify existing security risks
against which the existing security mechanisms/protocols cannot offer
sufficient protection. Current mobility protocols all have security
mechanisms. 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 variation of
mobile IP also have similar security considerations.
5.7. Multicast - REQ7
It is stated in [I-D.ietf-dmm-requirements] that DMM solutions SHOULD
consider multicast traffic delivery so that network inefficiency
issues, such as duplicate multicast subscriptions towards the
downstream tunnel entities, can be avoided.
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 MN,
introduce the so-called "tunnel convergence problem". This means
that multiple instances of the same multicast traffic can converge to
the same node, defeating hence the advantage of using multicast
protocols.
The MULTIMOB WG in IETF has studied the issue, for the specific case
of PMIPv6, and has produced a baseline solution [RFC6224] as well as
a routing optimization solution [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.
Besides the solutions proposed in MULTIMOB for PMIPv6, there are no
solutions for other mobility protocols to address the multicast
tunnel convergence problem.
5.8. Summary
We next list the main gaps identified from the analysis performed
above.
o Existing solutions do 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.
o The mobile node needs to simultaneously use multiple IP addresses,
which requires additional support which might not be available on
the mobile node's stack, especially for the case of network-based
solutions.
o 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.
o While existing network-based DMM practices may allow to deploy
multiple LMAs and dynamically select the best one, this requires
to still keep some centralization in the control plane, to access
on the policy store (as defined in RFC5213).
The following table summarizes the previous analysis, indicating the
gaps existing DMM solutions have when compared to the requirements
listed in [I-D.ietf-dmm-requirements].
+------------+------+------+------+------+------+------+------+
| | REQ1 | REQ2 | REQ3 | REQ4 | REQ5 | REQ6 | REQ7 |
+------------+------+------+------+------+------+------+------+
| MIPv6/NEMO | X | X | | | | | X |
| MIPv6 RO | X | | | | | | X |
| HMIPv6 | X | | | | | | X |
| HA sel | X | X | | | | | X |
| MOBIKE | X | X | | | | | X |
| PMIPv6 | X | X | | | | | * |
| LMA sel | X | X | | | | | X |
| LIPA | X | X | | | | | X |
| SIPTO | X | X | | | | | X |
| LIMONET | X | X | | | | | X |
+------------+------+------+------+------+------+------+------+
* MULTIMOB optimizations for PMIPv6 can be used to handle multicast
traffic.
6. Security Considerations 6. Security Considerations
TBD. This document does not define any protocol, there is no security
considerations.
7. IANA Considerations 7. IANA Considerations
None. None.
8. Informative References 8. References
[3GPP.23.829] 8.1. Normative References
3GPP, "Local IP Access and Selected IP Traffic Offload
(LIPA-SIPTO)", 3GPP TR 23.829 10.0.1, October 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[3GPP.23.401]
3GPP, "General Packet Radio Service (GPRS) enhancements
for Evolved Universal Terrestrial Radio Access Network
(E-UTRAN) access", 3GPP TS 23.401 10.10.0, March 2013.
[3GPP.23.859] [3GPP.23.859]
3GPP, "Local IP access (LIPA) mobility and Selected IP 3GPP, "Local IP access (LIPA) mobility and Selected IP
Traffic Offload (SIPTO) at the local network", 3GPP Traffic Offload (SIPTO) at the local network", 3GPP
TR 23.859 12.0.1, April 2013. TR 23.859 12.0.1, April 2013.
[3GPP.29.060] [3GPP.29.060]
3GPP, "General Packet Radio Service (GPRS); GPRS 3GPP, "General Packet Radio Service (GPRS); GPRS
Tunnelling Protocol (GTP) across the Gn and Gp interface", Tunnelling Protocol (GTP) across the Gn and Gp interface",
3GPP TS 29.060 3.19.0, March 2004. 3GPP TS 29.060 3.19.0, March 2004.
[3GPP.29.274]
3GPP, "3GPP Evolved Packet System (EPS); Evolved General
Packet Radio Service (GPRS) Tunnelling Protocol for
Control plane (GTPv2-C); Stage 3", 3GPP TS 29.274 10.11.0,
June 2013.
[3GPP.29.281]
3GPP, "General Packet Radio System (GPRS) Tunnelling
Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0,
September 2011.
[3GPP.29.303]
3GPP, "Domain Name System Procedures; Stage 3", 3GPP
TS 29.303 10.4.0, September 2012.
[I-D.bhandari-dhc-class-based-prefix]
Systems, C., Halwasia, G., Gundavelli, S., Deng, H.,
Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class
based prefix", draft-bhandari-dhc-class-based-prefix-05
(work in progress), July 2013.
[I-D.gundavelli-v6ops-community-wifi-svcs] [I-D.gundavelli-v6ops-community-wifi-svcs]
Gundavelli, S., Grayson, M., Seite, P., and Y. Lee, Gundavelli, S., Grayson, M., Seite, P., and Y. Lee,
"Service Provider Wi-Fi Services Over Residential "Service Provider Wi-Fi Services Over Residential
Architectures", Architectures",
draft-gundavelli-v6ops-community-wifi-svcs-06 (work in draft-gundavelli-v6ops-community-wifi-svcs-06 (work in
progress), April 2013. progress), April 2013.
[I-D.ietf-dmm-requirements] [I-D.ietf-dmm-requirements]
Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen, Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen,
"Requirements for Distributed Mobility Management", "Requirements for Distributed Mobility Management",
draft-ietf-dmm-requirements-05 (work in progress), draft-ietf-dmm-requirements-09 (work in progress),
June 2013. September 2013.
[I-D.korhonen-6man-prefix-properties]
Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D.
Liu, "IPv6 Prefix Properties",
draft-korhonen-6man-prefix-properties-02 (work in
progress), July 2013.
[IEEE.802-16.2009]
"IEEE Standard for Local and metropolitan area networks
Part 16: Air Interface for Broadband Wireless Access
Systems", IEEE Standard 802.16, 2009, <http://
standards.ieee.org/getieee802/download/802.16-2009.pdf>.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol", Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005. RFC 3963, January 2005.
[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP Version 6 Route Optimization Security Nordmark, "Mobile IP Version 6 Route Optimization Security
Design Background", RFC 4225, December 2005. Design Background", RFC 4225, December 2005.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.
[RFC4640] Patel, A. and G. Giaretta, "Problem Statement for [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for
bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, bootstrapping Mobile IPv6 (MIPv6)", RFC 4640,
September 2006. September 2006.
[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6
Socket API for Source Address Selection", RFC 5014,
September 2007.
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
Bootstrapping in Split Scenario", RFC 5026, October 2007. Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, [RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf,
"Mobility Header Home Agent Switch Message", RFC 5142, "Mobility Header Home Agent Switch Message", RFC 5142,
January 2008. January 2008.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L.
Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
Management", RFC 5380, October 2008. Management", RFC 5380, October 2008.
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", RFC 5555, June 2009. Routers", RFC 5555, June 2009.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", RFC 5844, May 2010. Mobile IPv6", RFC 5844, May 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
[RFC6097] Korhonen, J. and V. Devarapalli, "Local Mobility Anchor
(LMA) Discovery for Proxy Mobile IPv6", RFC 6097,
February 2011.
[RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
Deployment for Multicast Listener Support in Proxy Mobile
IPv6 (PMIPv6) Domains", RFC 6224, April 2011.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011. in IPv6", RFC 6275, July 2011.
[RFC6463] Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui, [RFC6463] Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui,
"Runtime Local Mobility Anchor (LMA) Assignment Support "Runtime Local Mobility Anchor (LMA) Assignment Support
for Proxy Mobile IPv6", RFC 6463, February 2012. for Proxy Mobile IPv6", RFC 6463, February 2012.
[RFC6611] Chowdhury, K. and A. Yegin, "Mobile IPv6 (MIPv6) [RFC6611] Chowdhury, K. and A. Yegin, "Mobile IPv6 (MIPv6)
Bootstrapping for the Integrated Scenario", RFC 6611, Bootstrapping for the Integrated Scenario", RFC 6611,
May 2012. May 2012.
[RFC6705] Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A. [RFC6705] Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A.
Dutta, "Localized Routing for Proxy Mobile IPv6", Dutta, "Localized Routing for Proxy Mobile IPv6",
RFC 6705, September 2012. RFC 6705, September 2012.
[RFC7028] Zuniga, JC., Contreras, LM., Bernardos, CJ., Jeon, S., and
Y. Kim, "Multicast Mobility Routing Optimizations for
Proxy Mobile IPv6", RFC 7028, September 2013.
Authors' Addresses Authors' Addresses
Dapeng Liu (editor) Dapeng Liu (editor)
China Mobile China Mobile
Unit2, 28 Xuanwumenxi Ave, Xuanwu District Unit2, 28 Xuanwumenxi Ave, Xuanwu District
Beijing 100053 Beijing 100053
China China
Email: liudapeng@chinamobile.com Email: liudapeng@chinamobile.com
Juan Carlos Zuniga (editor) Juan Carlos Zuniga (editor)
InterDigital Communications, LLC InterDigital Communications, LLC
1000 Sherbrooke Street West, 10th floor 1000 Sherbrooke Street West, 10th floor
Montreal, Quebec H3A 3G4 Montreal, Quebec H3A 3G4
Canada Canada
Email: JuanCarlos.Zuniga@InterDigital.com Email: JuanCarlos.Zuniga@InterDigital.com
URI: http://www.InterDigital.com/ URI: http://www.InterDigital.com/
Pierrick Seite Pierrick Seite
 End of changes. 42 change blocks. 
106 lines changed or deleted 362 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/