draft-ietf-dmm-best-practices-gap-analysis-04.txt   draft-ietf-dmm-best-practices-gap-analysis-05.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: November 26, 2014 InterDigital Expires: January 4, 2015 InterDigital
P. Seite P. Seite
Orange Orange
H. Chan H. Chan
Huawei Technologies Huawei Technologies
CJ. Bernardos CJ. Bernardos
UC3M UC3M
May 25, 2014 July 3, 2014
Distributed Mobility Management: Current practices and gap analysis Distributed Mobility Management: Current practices and gap analysis
draft-ietf-dmm-best-practices-gap-analysis-04 draft-ietf-dmm-best-practices-gap-analysis-05
Abstract Abstract
The present document analyzes deployment practices of existing IP The present document analyzes deployment practices of existing IP
mobility protocols in a distributed mobility management environment. mobility protocols in a distributed mobility management environment.
It then identifies existing limitations when compared to the It then identifies existing limitations when compared to the
requirements defined for a distributed mobility management solution. requirements defined for a distributed mobility management solution.
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/.
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 November 26, 2014. This Internet-Draft will expire on January 4, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Functions of existing mobility protocols . . . . . . . . . . 3 3. Functions of existing mobility protocols . . . . . . . . . . . 3
4. DMM practices . . . . . . . . . . . . . . . . . . . . . . . . 5 4. DMM practices . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. IP flat wireless network . . . . . . . . . . . . . . . . 6 4.2. IP flat wireless network . . . . . . . . . . . . . . . . . 6
4.2.1. Host-based IP DMM practices . . . . . . . . . . . . . 7 4.2.1. Host-based IP DMM practices . . . . . . . . . . . . . 7
4.2.2. Network-based IP DMM practices . . . . . . . . . . . 12 4.2.2. Network-based IP DMM practices . . . . . . . . . . . . 12
4.3. 3GPP network flattening approaches . . . . . . . . . . . 14 4.3. 3GPP network flattening approaches . . . . . . . . . . . . 14
5. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Distributed processing - REQ1 . . . . . . . . . . . . . . 17 5.1. Distributed mobility management - REQ1 . . . . . . . . . . 17
5.2. On-demand network-layer mobility support - REQ2 . . . . . 19 5.2. Bypassable network-layer mobility support for each
5.3. IPv6 deployment - REQ3 . . . . . . . . . . . . . . . . . 20 application session - REQ2 . . . . . . . . . . . . . . . . 19
5.4. Existing mobility protocols - REQ4 . . . . . . . . . . . 21 5.3. IPv6 deployment - REQ3 . . . . . . . . . . . . . . . . . . 20
5.5. Co-existence - REQ5 . . . . . . . . . . . . . . . . . . . 21 5.4. Existing mobility protocols - REQ4 . . . . . . . . . . . . 21
5.6. Security considerations - REQ6 . . . . . . . . . . . . . 21 5.5. Coexistence with deployed networks/hosts and
5.7. Multicast - REQ7 . . . . . . . . . . . . . . . . . . . . 21 operability across different networks- REQ5 . . . . . . . 21
5.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.6. Operation and management considerations - REQ6 . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 5.7. Security considerations - REQ7 . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 5.8. Multicast - REQ8 . . . . . . . . . . . . . . . . . . . . . 22
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 5.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . 24 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. Normative References . . . . . . . . . . . . . . . . . . . 24
8.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
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 of centralized deployment of mobility management protocols and
specified the DMM requirements [I-D.ietf-dmm-requirements]. This specified the DMM requirements [I-D.ietf-dmm-requirements]. This
document investigates whether it is feasible to deploy current IP document investigates whether it is feasible to deploy current IP
mobility protocols in a DMM scenario in a way that can fulfill the mobility protocols in a DMM scenario in a way that can fulfill the
requirements. It discusses current deployment practices of existing requirements. It discusses current deployment practices of existing
mobility protocols and identifies the limitations (gaps) in these mobility protocols and identifies the limitations (gaps) in these
practices from the standpoint of satisfying DMM requirements, as practices from the standpoint of satisfying DMM requirements, as
defined in [I-D.ietf-dmm-requirements]. defined in [I-D.ietf-dmm-requirements].
The rest of this document is organized as follows. Section 3 The rest of this document is organized as follows. Section 3
analyzes existing IP mobility protocols by examining their functions analyzes existing IP mobility protocols by examining their functions
and how these functions can be configured and used to work in a DMM and how these functions can be configured and used to work in a DMM
environment. Section 4 presents the current practices of IP wireless environment. Section 4 presents the current practices of IP wireless
networks and 3GPP architectures. Both network-based and host-based networks and 3GPP architectures. Both network- and host-based
mobility protocols are considered. Section 5 presents the gap mobility protocols are considered. Section 5 presents the gap
analysis with respect to the current practices. analysis with respect to the current practices.
2. Terminology 2. Terminology
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].
All general mobility-related terms and their acronyms used in this All general mobility-related terms and their acronyms used in this
skipping to change at page 3, line 38 skipping to change at page 3, line 50
In this document there are also references to a "distributed mobility In this document there are also references to a "distributed mobility
management environment". By this term, we refer to a scenario in management environment". By this term, we refer to a scenario in
which the IP mobility, access network and routing solutions allow for which the IP mobility, access network and routing solutions allow for
setting up IP networks so that traffic is distributed in an optimal setting up IP networks so that traffic is distributed in an optimal
way, without the reliance on centrally deployed anchors to manage IP way, without 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
Host-based Mobile IPv6 [RFC6275], its network-based extension, PMIPv6 The host-based Mobile IPv6 [RFC6275] and its network-based extension,
[RFC5213], and HMIPv6 [RFC5380] are all logically centralized PMIPv6 [RFC5213], even HMIPv6 [RFC5380] are logically centralized
mobility management approaches that primarily address hierarchical mobility management approaches addressing primarily hierarchical
mobile networks. Although they are centralized approaches, they have mobile networks. Although these two are centralized approaches, they
important mobility management functions resulting from years of have important mobility management functions resulting from years of
extensive work to develop and to extend these functions. It is extensive work to develop and to extend these functions. It is
therefore useful to take these existing functions and examine them in therefore useful to take these existing functions and examine them in
a DMM scenario in order to understand how to deploy the existing a DMM scenario in order to understand how to deploy the existing
mobility protocols to provide distributed mobility management. mobility protocols to provide distributed mobility management.
The main mobility management functions of MIPv6, PMIPv6, and HMIPv6 The main mobility management functions of MIPv6, PMIPv6, and HMIPv6
are the following: are the following:
1. Anchoring function (AF): allocation to a mobile node of an IP 1. Anchoring function (AF): allocation to a mobile node of an IP
address (a Home Address (HoA)) or prefix (a Home Network Prefix address (a Home Address (HoA)) or prefix (a Home Network Prefix
(HNP)) topologically anchored by the advertising node (i.e., the (HNP)) topologically anchored by the advertising node (i.e., the
anchor node is able to advertise a connected route into the anchor node is able to advertise a connected route into the
routing infrastructure for the allocated IP prefixes). It is a routing infrastructure for the allocated IP prefixes). It is a
control plane function. control plane function.
2. Internetwork Location Management (LM) function: managing and 2. Internetwork Location Information (LI) function: managing and
keeping track of the internetwork location of an MN. The keeping track of the internetwork location of an MN. The
location information may be a mapping of the IP advertised location information may be a binding of the IP advertised
address/prefix (e.g., HoA or HNP) to the IP routing address of address/prefix (e.g., HoA or HNP) to the IP routing address of
the MN or of a node that can forward packets destined to the MN. the MN or of a node that can forward packets destined to the MN.
It is a control plane function. It is a control plane function.
In a client-server protocol model, location query and update In a client-server protocol model, location query and update
messages may be exchanged between the client (LMc) and the server messages may be exchanged between a location information client
(LMs). (LIc) and a location information server (LIs).
3. Forwarding Management (FM) function: packet interception and 3. Forwarding Management (FM) function: packet interception and
forwarding to/from the IP address/prefix assigned to the MN, forwarding to/from the IP address/prefix assigned to the MN,
based on the internetwork location information, either to the based on the internetwork location information, either to the
destination or to some other network element that knows how to destination or to some other network element that knows how to
forward the packets to their destination. forward the packets to their destination.
FM may optionally be split into the control plane (FM-CP) and FM may optionally be split into the control plane (FM-CP) and
data plane (FM-DP). data plane (FM-DP).
In Mobile IPv6, the home agent (HA) typically provides the anchoring In Mobile IPv6, the home agent (HA) typically provides the anchoring
function (AF); the location management server (LMs) is at the HA function (AF); the location information server (LIs) is at the HA
while the location management client (LMc) is at the MN; the while the location information client (LIc) is at the MN; the
forwarding management (FM) function is both ends of tunneling at the forwarding management (FM) function is both ends of tunneling at the
HA and the MN. HA and the MN.
In Proxy Mobile IPv6, the Local Mobility Anchor (LMA) provides the In Proxy Mobile IPv6, the Local Mobility Anchor (LMA) provides the
anchoring function (AF); the location management server (LMs) is at anchoring function (AF); the location information server (LIs) is at
the LMA while the location management client (LMc) is at the mobile the LMA while the location information client (LIc) is at the mobile
access gateway (MAG); the forwarding management (FM) function is both access gateway (MAG); the forwarding management (FM) function is both
ends of tunneling at the HA and the MAG. ends of tunneling at the HA and the MAG.
In Hirarchical mobile IPv6 (HMIPv6) [RFC5380], the mobility anchor In Hierarchical mobile IPv6 (HMIPv6) [RFC5380], the mobility anchor
point (MAP) serves as a location management aggregator between the point (MAP) serves as a location information aggregator between the
LMs at the HA and the LMc at the MN. The MAP also has the FM LIs at the HA and the LIc at the MN. The MAP also has FM function to
function to enable tunneling between HA and itself as well as enable tunneling between HA and itself as well as tunneling between
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 to satisfy distributed mobility management requirements. protocols to satisfy distributed mobility management requirement.
This description considers both IP wireless (e.g., evolved Wi-Fi This description considers both IP wireless (e.g., evolved Wi-Fi
hotspots) and 3GPP Architecture flattening approaches(i.e. fewer hotspots) and 3GPP Architecture flattening approaches(i.e. fewer
levels of routing hierarchy introduced into the data path by the levels of routing hierarchy introduced into the data path by the
mobility management system). mobility management system).
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 certain current mobile network The focus of the gap analysis is on certain current mobile network
architectures and standardized IP mobility solutions, considering any architectures and standardized IP mobility solutions, considering any
kind of deployment options which do not violate the original protocol kind of deployment options which do not violate the original protocol
specifications. In order to limit the scope of our analysis of DMM specifications. In order to limit the scope of our analysis of DMM
practices, we consider the following list of technical assumptions: practices, we consider the following list of technical assumptions:
1. Both host-based 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 candidates. 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). This is in contrast to provision of IP address continuity). This is in contrast to
certain transport-layer based approaches such as SCTP or certain transport-layer based approaches such as SCTP or
application-layer mobility. application-layer mobility.
skipping to change at page 7, line 7 skipping to change at page 7, line 17
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, domain-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.
IP mobility protocols can be used to provide inter-access mobility IP mobility protocols can be used to provide inter-access mobility
support to users, e.g. handover from Wi-Fi to cellular access. Two support to users, e.g. handover from Wi-Fi to cellular access. Two
kinds of protocols can be used: Proxy Mobile IPv6 [RFC5213] or Mobile kind of protocols can be used: Proxy Mobile IPv6 [RFC5213] or Mobile
IPv6 [RFC5555], with the mobility anchor (e.g., local mobility anchor IPv6 [RFC5555], with the mobility anchor (e.g., local mobility anchor
or home agent) role typically being played by the edge router of the or home agent) role typically being played by the edge router of the
mobile network [SDO-3GPP.23.402]. mobile network [SDO-3GPP.23.402].
Although this section has made use of the example of Wi-Fi networks, Although this section has made use of the example of Wi-Fi networks,
there are other IP flat wireless network architectures specified, there are other 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. 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-based 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. The analysis is divided into two parts: host-based and considered. The analysis is divided into two parts: host- and
network-based practices. network-based practices.
4.2.1. Host-based IP DMM practices 4.2.1. Host-based IP DMM practices
Mobile IPv6 (MIPv6) [RFC6275] and its extension to support mobile Mobile IPv6 (MIPv6) [RFC6275] and its extension to support mobile
networks, the NEMO Basic Support protocol (hereafter, simply referred networks, the NEMO Basic Support protocol (hereafter, simply referred
to as NEMO) [RFC3963] are well-known host-based IP mobility to as NEMO) [RFC3963] are well-known host-based IP mobility
protocols. They depend upon the function of the Home Agent (HA), a protocols. They depend upon the function of the Home Agent (HA), a
centralized anchor, to provide mobile nodes (hosts and routers) with centralized anchor, to provide mobile nodes (hosts and routers) with
mobility support. In these approaches, the home agent typically mobility support. In these approaches, the home agent typically
provides the anchoring function (AF), forwarding management (FM), and provides the anchoring function (AF), forwarding management (FM), and
Internetwork Location Management server (LMs) functions. The mobile Internetwork Location Information server (LIs) functions. The mobile
node possesses the Location management client (LMc) function and the node possesses the Location Information client (LIc) function and the
FM function to enable tunneling between HA and itself. We next FM function to enable tunneling between HA and itself. We next
describe some practices that show how MIPv6/NEMO and several other describe some practices that show how MIPv6/NEMO and several other
protocol extensions can be deployed in a distributed mobility protocol extensions can be deployed in a distributed mobility
management environment. management environment.
One approach to distribute the anchors can be to deploy several HAs One approach to distribute the anchors can be to deploy several HAs
(as shown in Figure 2), and assign the topologically closest anchor (as shown in Figure 2), and assign the topologically closest anchor
to each MN [RFC4640], [RFC5026], [RFC6611]. In the example shown in to each MN [RFC4640], [RFC5026], [RFC6611]. In the example shown in
Figure 2, MN1 is assigned HA1 (and a home address anchored by HA1), Figure 2, 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. In this deployment model, the mobile node can use
node to meet assumption #4 of Section 4.1 and use several anchors at several anchors at the same time, each of them anchoring IP flows
the same time, each of them anchoring IP flows initiated at a initiated at a different point of attachment. However there is no
different point of attachment. However there is no mechanism mechanism specified by IETF to enable an efficient dynamic discovery
specified by IETF to enable an efficient dynamic discovery of of available anchors and the selection of the most suitable one.
available anchors and the selection of the most suitable one. Note Note that some of these mechanisms [SDO-3GPP.23.402] have been
that some of these mechanisms [SDO-3GPP.23.402] have been defined defined outside IETF.
outside IETF.
<- 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) -------
------- -------
------- -------
| HA2 | ------- | HA2 | -------
------- | AR3 |-(o) zzzz (o) ------- | AR3 |-(o) zzzz (o)
------- | ------- |
------- (MN2 anchored at HA2) ------- ------- (MN2 anchored at HA2) -------
| CN2 | ------- | MN2 | | CN2 | ------- | MN2 |
------- | AR4 |-(o) ------- ------- | AR4 |-(o) -------
------- -------
CN1 CN2 HA1 HA2 AR1 MN1 AR3 MN2 CN1 CN2 HA1 HA2 AR1 MN1 AR3 MN2
| | | | | | | | | | | | | | | |
|<------------>|<=================+=====>| | | BT mode |<------------>|<=================+=====>| | | BT mode
| | | | | | | | | | | | | | | |
| |<----------------------------------------+----->| RO mode | |<----------------------------------------+----->| RO mode
| | | | | | | | | | | | | | | |
Figure 2: Distributed operation of Mobile IPv6 (BT and RO) / NEMO Figure 2: Distributed operation of Mobile IPv6 (BT and RO) / NEMO
Since one of the goals of the deployment of mobility protocols in a Since one of the goals of the deployment of mobility protocols in a
distributed mobility management environment is to avoid the distributed mobility management environment is to avoid the
suboptimal routing caused by centralized anchoring, the Route suboptimal routing caused by centralized anchoring, the Route
Optimization (RO) support provided by Mobile IPv6 can also be used to Optimization (RO) support provided by Mobile IPv6 can also be used to
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
skipping to change at page 9, line 31 skipping to change at page 9, line 41
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 LI
intermediary function between the LM server (LMs) at the HA and the intermediary function between the LI server (LIs) at the HA and the
LM client (LMc) at the MN. It also performs the FM function using LI client (LIc) at the MN. It also performs the FM function using
tunneling with the HA and also to tunnel with the MN. tunneling with the HA and also to tunnel 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
skipping to change at page 10, line 51 skipping to change at page 10, line 51
level. The mobile node uses the RCoA as the CoA signaled to its home level. The mobile node uses the RCoA as the CoA signaled to its home
agent. Therefore, while roaming within a local domain handled by the agent. Therefore, while roaming within a local domain handled by the
same MAP, the mobile node does not need to update its home agent same MAP, the mobile node does not need to update its home agent
(i.e., the mobile node does not change its RCoA). (i.e., the mobile node does not change its RCoA).
The use of HMIPv6 enables some form of route optimization, since a The use of HMIPv6 enables some form of route optimization, since a
mobile node may decide to directly use the RCoA as source address for mobile node may decide to directly use the RCoA as source address for
a communication with a given correspondent node, particularly if the a communication with a given correspondent node, particularly if the
MN does not expect to move outside the local domain during the MN does not expect to move outside the local domain during the
lifetime of the communication. This can be seen as a potential DMM lifetime of the communication. This can be seen as a potential DMM
mode of operation. In the example shown in Figure 3, MN1 is using mode of operation,though it fails to provide session continuity if
its global HoA to communicate with CN1, while it is using its RCoA to and when the MN moves outside the local domain. In the example shown
communicate with CN2. in Figure 3, MN1 is using its global HoA to communicate with CN1,
while it is using its RCoA to communicate with CN2.
Furthermore, a local domain might have several MAPs deployed, Furthermore, a local domain might have several MAPs deployed,
enabling therefore a different kind of HMIPv6 deployments (e.g., 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.).
Another extension that can be used to help distributing mobility Another extension that can be used to help distributing mobility
management functions is the Home Agent switch specification management functions is the Home Agent switch specification
skipping to change at page 11, line 38 skipping to change at page 11, line 38
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.
IETF has defined extensions to the mobility protocol to optimize the IETF has defined extensions to the mobility protocol to optimize the
handover performance. Mobile IPv6 Fast Handovers(FMIP) [RFC5568] is handover performance. Mobile IPv6 Fast Handovers (FMIPv6) [RFC5568]
the extension to optimize handover latency. It defines new access is the extension to optimize handover latency. It defines new access
router discovery mechanism before handover to reduce the new network router discovery mechanism before handover to reduce the new network
discovery latency. It also defines a tunnel between the previous discovery latency. It also defines a tunnel between the previous
access router and the new access router to reduce the packet loss access router and the new access router to reduce the packet loss
during handover. IETF seamoby working group alos has published during handover. IETF seamoby working group also has published
Candidate Access Router Discovery(CARD) [RFC4066] and Context Candidate Access Router Discovery (CARD) [RFC4066] and Context
Transfer Protocol (CXTP) [RFC4067] to improve the handover Transfer Protocol (CXTP) [RFC4067] to improve the handover
performance. The DMM deployment pratice discussed in this section performance. The DMM deployment practice discussed in this section
can also use thoes extensions to improve the handover performance. can also use those extensions to improve the handover performance.
4.2.2. Network-based IP DMM practices 4.2.2. Network-based IP DMM practices
Proxy Mobile IPv6 (PMIPv6) [RFC5213] is the main network-based IP Proxy Mobile IPv6 (PMIPv6) [RFC5213] is the main network-based IP
mobility protocol specified for IPv6. Proxy Mobile IPv4 [RFC5844] mobility protocol specified for IPv6. Proxy Mobile IPv4 [RFC5844]
defines some IPv4 extensions. With network-based IP mobility defines some IPv4 extensions. With network-based IP mobility
protocols, the local mobility anchor (LMA) typically provides the protocols, the local mobility anchor (LMA) typically provides the
anchoring function (AF), Forwarding management (FM) function, anchoring function (AF), Forwarding management (FM) function, and
internetwork Location Management server (LMs) function and RM Internetwork Location Information server (LIs) function. The mobile
function. The mobile access gateway (MAG) provides the Location access gateway (MAG) provides the Location Information client (LIc)
Management client (LMc) function and Forwarding management (FM) function and Forwarding management (FM) function to tunnel with LMA.
function to tunnel with LMA. PMIPv6 is architecturally almost PMIPv6 is architecturally almost identical to MIPv6, as the mobility
identical to MIPv6, as the mobility signaling and routing between LMA signaling and routing between LMA and MAG in PMIPv6 is similar to
and MAG in PMIPv6 is similar to those between HA and MN in MIPv6. those between HA and MN in MIPv6. The required mobility
The required mobility functionality at the MN is provided by the MAG functionality at the MN is provided by the MAG so that the
so that the involvement in mobility support by the MN is not involvement in mobility support by the MN is not required.
required.
We next describe some practices that show how network-based mobility We next describe some practices that show how network-based mobility
protocols and several other protocol extensions can be deployed in a protocols and several other protocol extensions can be deployed in a
distributed mobility management environment. distributed mobility management environment.
One way to decentralize Proxy Mobile IPv6 operation can be to deploy One way to decentralize Proxy Mobile IPv6 operation can be to deploy
several local mobility anchors and use some selection criteria to several local mobility anchors and use some selection criteria to
assign LMAs to attaching mobile nodes (an example of this type of assign LMAs to attaching mobile nodes (an example of this type of
assignment is shown in Figure 4). As with the client based approach, assignment is shown in Figure 4). As with the client based approach,
a mobile node may use several anchors at the same time, each of them a mobile node may use several anchors at the same time, each of them
skipping to change at page 15, 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
The GPRS Tunnelling Protocol (GTP) [SDO-3GPP.29.060] The GPRS Tunneling Protocol (GTP) [SDO-3GPP.29.060] [SDO-3GPP.29.281]
[SDO-3GPP.29.281] [SDO-3GPP.29.274] is a network-based mobility [SDO-3GPP.29.274] is a network-based mobility protocol specified for
protocol specified for 3GPP networks (S2a, S2b, S5 and S8 3GPP networks (S2a, S2b, S5 and S8 interfaces). Similar to PMIPv6,
interfaces). Similar to PMIPv6, it can handle mobility without it can handle mobility without requiring the involvement of the
requiring the involvement of the mobile nodes. In this case, the mobile nodes. In this case, the mobile node functionality is
mobile node functionality is provided in a proxy manner by the provided in a proxy manner by the Serving Data Gateway (SGW), Evolved
Serving Data Gateway (SGW), Evolved Packet Data Gateway (ePDG), or Packet Data Gateway (ePDG), or Trusted Wireless Access Gateway (TWAG
Trusted Wireless Access Gateway (TWAG). [SDO-3GPP.23.402]) .
3GPP specifications also include client-based mobility support, based 3GPP specifications also include client-based mobility support, based
on adopting the use of Dual-Stack Mobile IPv6 (DSMIPv6) [RFC5555] for on adopting the use of Dual-Stack Mobile IPv6 (DSMIPv6) [RFC5555] for
the S2c interface. In this case, the User Equipment (UE) implements the S2c interface [SDO-3GPP.24.303]. In this case, the User
the binding update functionality, while the home agent role is played Equipment (UE) implements the binding update functionality, while the
by the PGW. home agent role is played by the PGW.
A Local IP Access (LIPA) and Selected IP Traffic Offload (SIPTO) A Local IP Access (LIPA) and Selected IP Traffic Offload (SIPTO)
enabled network [SDO-3GPP.23.401] allows offloading some IP services enabled network [SDO-3GPP.23.401] allows offloading some IP services
at the local access network, above the Radio Access Network (RAN) or at the local access network, above the Radio Access Network (RAN) or
at the macro, without the need to travel back to the PGW (see at the macro, without the need to travel back to the PGW (see
Figure 6). Figure 6).
+---------+ IP traffic to mobile operator's CN +---------+ IP traffic to mobile operator's CN
| User |....................................(Operator's CN) | User |....................................(Operator's CN)
| Equipm. |.................. | Equipm. |..................
skipping to change at page 17, line 30 skipping to change at page 17, line 30
The 3GPP architecture specifications also provide mechanisms to allow The 3GPP architecture specifications also provide mechanisms to allow
discovery and selection of gateways [SDO-3GPP.29.303]. These discovery and selection of gateways [SDO-3GPP.29.303]. These
mechanisms enable decisions taking into consideration topological mechanisms enable decisions taking into consideration topological
location and gateway collocation aspects, relying upon the DNS as a location and gateway collocation aspects, relying upon the DNS as a
"location database". "location database".
Both SIPTO and LIPA have a very limited mobility support, specially Both SIPTO and LIPA have a very limited mobility support, specially
in 3GPP specifications up to Rel-12. Briefly, LIPA mobility support in 3GPP specifications up to Rel-12. Briefly, LIPA mobility support
is limited to handovers between HeNBs that are managed by the same is limited to handovers between HeNBs that are managed by the same
L-GW (i.e., mobility within the local domain), while seamless L-GW (i.e., mobility within the local domain). There is no guarantee
mobility is not supported when SIPTO is performed at or near the RAN of IP session continuity for SIPTO.
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, 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 mobility management - 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 forwarding solutions provided by DMM
enable distributed processing for mobility management so that traffic must enable traffic to avoid traversing single mobility anchor far
can avoid traversing single mobility anchor far from the optimal 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 mobility management" usually
following functions: relying on the following functions:
o Multiple (distributed) anchoring: ability to anchor different o Multiple (distributed) anchoring: ability to anchor different
sessions of a single mobile node at different anchors. In order sessions of a single mobile node at different anchors. In order
to provide improved routing, some anchors might need to be placed to provide improved routing, some anchors might need to be placed
closer to the mobile node. closer to the mobile node or the corresponding node.
o Dynamic anchor assignment/re-location: ability to i) assign the o Dynamic anchor assignment/re-location: ability to i) assign the
initial anchor, and ii) dynamically change the initially assigned initial anchor, and ii) dynamically change the initially assigned
anchor and/or assign a new one (this may also require to transfer anchor and/or assign a new one (this may also require to transfer
mobility context between anchors). This can be achieved either by mobility context between anchors). This can be achieved either by
changing anchor for all ongoing sessions, or by assigning new changing anchor for all ongoing sessions or by assigning new
anchors just for new sessions. anchors just for new sessions.
Both the main client- and network-based IP mobility protocols, namely 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 initial anchor assignment, thus the lack of dynamic anchor provide a initial anchor assignment, thus the lack of dynamic anchor
change/new anchor assignment is a gap. Neither the HA switch nor the change/new anchor assignment is a gap. Neither the HA switch nor the
LMA runtime assignment allow changing the anchor during an ongoing LMA runtime assignment allow changing the anchor during an ongoing
session. This actually comprises several gaps: ability to perform session. This actually comprises several gaps: ability to perform
anchor assignment at any time (not only at the initial MN's anchor assignment at any time (not only at the initial MN's
attachment), ability of the current anchor to initiate/trigger the attachment), ability of the current anchor to initiate/trigger the
relocation, and ability to transfer registration context between relocation, and ability to transfer registration context between
anchors. 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 19, line 15 skipping to change at page 19, line 15
that is currently anchoring a given home address/prefix (capability that is currently anchoring a given home address/prefix (capability
sometimes required to meet REQ#2). There are though some mechanisms sometimes required to meet REQ#2). There are though some mechanisms
that could help discovering anchors, such as the Dynamic Home Agent that could help discovering anchors, such as the Dynamic Home Agent
Address Discovery (DHAAD), the use of the Home Agent (H) flag in Address Discovery (DHAAD), the use of the Home Agent (H) flag in
Router Advertisements (which indicates that the router sending the Router Advertisements (which indicates that the router sending the
Router Advertisement is also functioning as a Mobile IPv6 home agent Router Advertisement is also functioning as a Mobile IPv6 home agent
on the link) or the MAP option in Router Advertisements defined by on the link) or the MAP option in Router Advertisements defined by
HMIPv6. Note that there are 3GPP mechanisms providing that HMIPv6. Note that there are 3GPP mechanisms providing that
functionality defined in [SDO-3GPP.29.303]. functionality defined in [SDO-3GPP.29.303].
Regarding the ability to transfer registration context between
anchors, there are already some solutions that could be reused or
adapted to fill that gap, such as Fast Handovers for Mobile IPv6
[RFC5568] -- to enable traffic redirection from the old to the new
anchor --, the Context Transfer protocol [RFC4067] -- to enable the
required transfer of registration information between anchors --, or
the Handover Keying architecture solutions [RFC6697], to speed up the
re-authentication process after a change of anchor. Note that some
extensions might be needed in the context of DMM, as these protocols
were designed in the context of centralized client IP mobility,
focusing on the access re-attachment and authentication.
Also note that REQ1 is such that the data plane traffic can avoid Also note that REQ1 is such that the data plane traffic can avoid
suboptimal route. Distributed processing of the traffic is then suboptimal route. Distributed processing of the traffic is then
needed only in the data plane. The needed capability in distributed needed only in the data plane. The needed capability in distributed
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 forwarding management (FM) function may limit plane and data plane forwarding management (FM) function may limit
the choice to distributing boht data plane and control plane the choice to distributing both data plane and control plane
together. In order to enable distributing only the data plane together. In order to enable distributing only the data plane
without distributing the control plane, a gap is to split the without distributing the control plane, a gap is to split the
forwarding management function into the control plane (FM-CP) and forwarding management function into the control plane (FM-CP) and
data plane (FM-DP). data plane (FM-DP).
5.2. On-demand network-layer mobility support - REQ2 5.2. Bypassable network-layer mobility support for each application
session - REQ2
The need for "on-demand network-layer mobility support" introduced in The need for "bypassable network-layer mobility support for each
[I-D.ietf-dmm-requirements] will enable dynamic mobility management. application session" introduced in [I-D.ietf-dmm-requirements]
management. Flexibility on the determination of whether network- requires flexibility on determining whether network-layer mobility
layer mobility support is needed. The requirement enables one to support is needed. The requirement enables one to choose whether or
choose whether or not use network-layer mobility support. It only not use network-layer mobility support. It only enables the two
enables the two following functions: 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. This requires MN to acquire application/service basis. This requires MN to acquire
information regarding the properties of the available IP information regarding the properties of the available IP
skipping to change at page 20, line 31 skipping to change at page 20, line 43
capabilities of its assigned IP addresses. This is not necessarily capabilities of its assigned IP addresses. This is not necessarily
the case with network based IP mobility management; current the case with network based IP mobility management; current
mechanisms do not allow the MN to be aware of the properties of its mechanisms do not allow the MN to be aware of the properties of its
IP addresses (e.g., the MN does not know whether the allocated IP IP addresses (e.g., the MN does not know whether the allocated IP
addresses are anchored). However, there are proposals that the addresses are anchored). However, there are proposals that the
network could indicate such IP address properties during assignment network could indicate such IP address properties during assignment
procedures, such as [I-D.bhandari-dhc-class-based-prefix], procedures, such as [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].
Although there exist these individual efforts that could be be Although there exist these individual efforts that could be be
considered as attempts to fix the gap, there is no solution adopted considered as attempts to fix the gap, there is no solution adopted
as a work item within any IETF working group.. as a work item within any IETF working group.
The handling of mobility management to the granularity of an The handling of mobility management to the granularity of an
individual session of a user/device SHOULD need proper session individual session of a user/device SHOULD need proper session
identification in addition to user/device identification. identification in addition to user/device identification.
5.3. IPv6 deployment - REQ3 5.3. IPv6 deployment - REQ3
This requirement states that DMM solutions should primarily target This requirement states that DMM solutions should primarily target
IPv6 as the primary deployment environment. IPv4 support is not IPv6 as the primary deployment environment. IPv4 support is not
considered mandatory and solutions should not be tailored considered mandatory and solutions should not be tailored
skipping to change at page 21, line 19 skipping to change at page 21, line 27
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 in IP nothing prevent the distribution of mobility functions with in IP
mobility protocols. However, as discussed in Section 5.1 and 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 and centralized control plane. The 3GPP architecture
also going into the direction of flattening with SIPTO and LIPA, is also going into the direction of flattening with SIPTO and LIPA,
though they do not provide mobility support. but they do not provide sufficient mobility support. This is
identified as a gap and DMM will be a potential solution to fulfill
this gap.
5.5. Co-existence - REQ5 5.5. Coexistence with deployed networks/hosts and operability across
different networks- REQ5
According to [I-D.ietf-dmm-requirements], DMM solution must be able According to [I-D.ietf-dmm-requirements], DMM implementations must be
to co-exist with existing network deployments, end hosts and routers. able to co-exist with existing network deployments, end hosts and
All current mobility protocols can co-exist with existing network routers, and a DMM solution SHOULD work across different networks,
deployments and end hosts. There is no gap between existing mobility possibly operated as separate administrative domains, when the needed
protocols and this requirement. mobility management signaling, forwarding, and network access are
allowed by the trust relationship between them. All current mobility
protocols can co-exist with existing network deployments and end
hosts. There is no gap between existing mobility protocols and this
requirement.
5.6. Security considerations - REQ6 5.6. Operation and management considerations - REQ6
As stated in [I-D.ietf-dmm-requirements], a DMM solution must not As stated in [I-D.ietf-dmm-requirements], (1) a DMM solution needs to
introduce new security risks, or amplify existing security risks, consider configuring a device, monitoring the current operational
that cannot be mitigated by existing security mechanisms or state of a device, responding to events that impact the device,
protocols. Current mobility protocols have all security mechanisms possibly by modifying the configuration and storing the data in a
in place. For example, Mobile IPv6 defines security features to format that can be analyzed later. (2) a DMM solution MUST describe
protect binding updates both to home agents and correspondent nodes. in what environment and how it can be scalably deployed and managed.
It also defines mechanisms to protect the data packets transmission (3) a DMM solution MUST support mechanisms to test if the DMM
for Mobile IPv6 users. Proxy Mobile IPv6 and other variations of solution is working properly. (4) a DMM solution SHOULD expose the
mobile IP also have similar security considerations. operational state of DMM to the administrators of the DMM entities.
(5) a DMM solution, which supports flow mobility, SHOULD support
means to correlate the flow routing policies and the observed
forwarding actions. (6) a DMM solution SHOULD support mechanisms to
check the liveness of forwarding path. (7) a DMM solution MUST
provide fault management and monitoring mechanisms to manage
situations where update of the mobility session or the data path
fails. (8) a DMM solution SHOULD be able to monitor usage of DMM
protocol. (9) DMM solutions SHOULD support standardized configuration
with NETCONF [RFC6241], using YANG [RFC6020] modules, which SHOULD be
created for DMM when needed for such configuration.
5.7. Multicast - REQ7 Existing mobility management protocols have not thoroughly documented
the above list of operation and management considerations. Each of
the above needs to be considered from the begining in a DMM solution.
Management information base (MIB) objects are currently defined in
[RFC4295] for MIPv6 and in [RFC6475] for PMIPv6. Standardized
configuration with NETCONF [RFC6241], using YANG [RFC6020] modules is
needed.
5.7. Security considerations - REQ7
As stated in [I-D.ietf-dmm-requirements], a DMM solution MUST support
any security protocols and mechanisms needed to secure the network
and to make continuous security improvements. In addition, with
security taken into consideration early in the design, a DMM solution
MUST NOT introduce new security risks, or amplify existing security
risks, that cannot be mitigated by existing security protocols and
mechanisms.
Current mobility protocols have all security mechanisms in place.
For example, Mobile IPv6 defines security features to protect binding
updates both to home agents and correspondent nodes. It also defines
mechanisms to protect the data packets transmission for Mobile IPv6
users. Proxy Mobile IPv6 and other variations of mobile IP also have
similar security considerations.
5.8. Multicast - REQ8
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, diminishing 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
skipping to change at page 22, line 22 skipping to change at page 23, line 26
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.
Besides the solutions proposed in MULTIMOB for PMIPv6 within the Besides the solutions proposed in MULTIMOB for PMIPv6 within the
IETF, there are no other solutions for other mobility protocols to IETF, there are no other solutions for other mobility protocols to
address the multicast tunnel convergence problem. address the multicast tunnel convergence problem.
5.8. Summary 5.9. Summary
We next list the main gaps identified from the analysis performed We next list the main gaps identified from the analysis performed
above: above:
o Existing solutions only provide an optimal initial anchor 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 MOBIKE allows change of GW but its applicability has been scoped
the middle of a session from MN side, there is no protocol support to very narrow use case.
for the network side.
o The mobile node needs to simultaneously use multiple IP addresses o The mobile node needs to simultaneously use multiple IP addresses
with different properties, which requires to expose this with different properties, which requires to expose this
information to the mobile node and to update accordingly the information to the mobile node and to update accordingly the
source address selection mechanism of the latter. source address selection mechanism of the latter.
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. However, the following selection of the most suitable one. However, the following
mechanisms that could help discovering anchors: mechanisms that could help discovering anchors:
o Dynamic Home Agent Address Discovery (DHAAD) the use of the Home o Dynamic Home Agent Address Discovery (DHAAD): the use of the Home
Agent (H) flag in Router Advertisements (which indicates that the Agent (H) flag in Router Advertisements (which indicates that the
router sending the Router Advertisement is also functioning as a router sending the Router Advertisement is also functioning as a
Mobile IPv6 home agent on the link) and Mobile IPv6 home agent on the link) and the MAP option in Router
Advertisements defined by HMIPv6.
o the MAP option in Router Advertisements defined by HMIPv6.
o While existing network-based DMM practices may allow deployment o While existing network-based DMM practices may allow to deploy
multiple LMAs and dynamic selection of the best one, doing so multiple LMAs and dynamically select the best one, this requires
requires some centralization in the control plane, for access the to still keep some centralization in the control plane, to access
policy database (as defined in RFC5213). Although the policy database (as defined in RFC5213). Although
[I-D.ietf-netext-pmip-cp-up-separation] allows a MAG to perform [I-D.ietf-netext-pmip-cp-up-separation] allows a MAG to perform
splitting of its control and user planes, there is a lack of splitting of its control and user planes, there is a lack of
solutions/extensions that support a clear control and data plane solutions/extensions that support a clear control and data plane
separation for IETF IP mobility protocols in a DMM context. separation for IETF IP mobility protocols in a DMM context.
6. Security Considerations 6. Security Considerations
Distributed mobility management systems encounter same security Distributed mobility management systems encounter same security
threats as existing centralized IP mobility protocols. Without threats as existing centralized IP mobility protocols. Without
authentication, a malicious node could forge signaling messages and authentication, a malicious node could forge signaling messages and
skipping to change at page 23, line 36 skipping to change at page 24, line 37
complex, since traffic redirection requests might come from complex, since traffic redirection requests might come from
previously unconsidered origins, thus leading to distributed points previously unconsidered origins, thus leading to distributed points
of attack. Consequently, the DMM security design must account for of attack. Consequently, the DMM security design must account for
the distribution of security associations between additional mobility the distribution of security associations between additional mobility
entities. entities.
7. IANA Considerations 7. IANA Considerations
None. None.
8. Contributors 8. References
The following people have made significant contribution for this
document.
Charles E. Perkins
Huawei Technologies
Email: charliep@computer.org
9. References 8.1. Normative References
9.1. Normative References [I-D.ietf-dmm-requirements]
Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen,
"Requirements for Distributed Mobility Management",
draft-ietf-dmm-requirements-17 (work in progress),
June 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References [RFC4295] Keeni, G., Koide, K., Nagami, K., and S. Gundavelli,
"Mobile IPv6 Management Information Base", RFC 4295,
April 2006.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)",
RFC 6241, June 2011.
[RFC6475] Keeni, G., Koide, K., Gundavelli, S., and R. Wakikawa,
"Proxy Mobile IPv6 Management Information Base", RFC 6475,
May 2012.
8.2. Informative References
[I-D.anipko-mif-mpvd-arch] [I-D.anipko-mif-mpvd-arch]
Anipko, D., "Multiple Provisioning Domain Architecture", Anipko, D., "Multiple Provisioning Domain Architecture",
draft-anipko-mif-mpvd-arch-05 (work in progress), November draft-anipko-mif-mpvd-arch-05 (work in progress),
2013. November 2013.
[I-D.bhandari-dhc-class-based-prefix] [I-D.bhandari-dhc-class-based-prefix]
Systems, C., Halwasia, G., Gundavelli, S., Deng, H., Systems, C., Halwasia, G., Gundavelli, S., Deng, H.,
Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class
based prefix", draft-bhandari-dhc-class-based-prefix-05 based prefix", draft-bhandari-dhc-class-based-prefix-05
(work in progress), July 2013. (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", draft-gundavelli-v6ops-community-wifi- Architectures",
svcs-06 (work in progress), April 2013. draft-gundavelli-v6ops-community-wifi-svcs-06 (work in
progress), April 2013.
[I-D.ietf-dmm-requirements]
Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen,
"Requirements for Distributed Mobility Management", draft-
ietf-dmm-requirements-16 (work in progress), April 2014.
[I-D.ietf-netext-pmip-cp-up-separation] [I-D.ietf-netext-pmip-cp-up-separation]
Wakikawa, R., Pazhyannur, R., Gundavelli, S., and C. Wakikawa, R., Pazhyannur, R., Gundavelli, S., and C.
Perkins, "Separation of Control and User Plane for Proxy Perkins, "Separation of Control and User Plane for Proxy
Mobile IPv6", draft-ietf-netext-pmip-cp-up-separation-03 Mobile IPv6", draft-ietf-netext-pmip-cp-up-separation-05
(work in progress), April 2014. (work in progress), July 2014.
[I-D.korhonen-6man-prefix-properties] [I-D.korhonen-6man-prefix-properties]
Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D. Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D.
Liu, "IPv6 Prefix Properties", draft-korhonen-6man-prefix- Liu, "IPv6 Prefix Properties",
properties-02 (work in progress), July 2013. draft-korhonen-6man-prefix-properties-02 (work in
progress), July 2013.
[IEEE.802-16.2009] [IEEE.802-16.2009]
"IEEE Standard for Local and metropolitan area networks "IEEE Standard for Local and metropolitan area networks
Part 16: Air Interface for Broadband Wireless Access Part 16: Air Interface for Broadband Wireless Access
Systems", IEEE Standard 802.16, 2009, Systems", IEEE Standard 802.16, 2009, <http://
<http://standards.ieee.org/getieee802/ standards.ieee.org/getieee802/download/802.16-2009.pdf>.
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.
[RFC4066] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. [RFC4066] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E.
Shim, "Candidate Access Router Discovery (CARD)", RFC Shim, "Candidate Access Router Discovery (CARD)",
4066, July 2005. RFC 4066, July 2005.
[RFC4067] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, [RFC4067] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli,
"Context Transfer Protocol (CXTP)", RFC 4067, July 2005. "Context Transfer Protocol (CXTP)", RFC 4067, July 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 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006. (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, September bootstrapping Mobile IPv6 (MIPv6)", RFC 4640,
2006. September 2006.
[RFC4889] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network [RFC4889] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network
Mobility Route Optimization Solution Space Analysis", RFC Mobility Route Optimization Solution Space Analysis",
4889, July 2007. RFC 4889, July 2007.
[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6
Socket API for Source Address Selection", RFC 5014, Socket API for Source Address Selection", RFC 5014,
September 2007. 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,
skipping to change at page 25, line 48 skipping to change at page 27, line 9
[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.
[RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, July [RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568,
2009. July 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, [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC "Internet Key Exchange Protocol Version 2 (IKEv2)",
5996, September 2010. RFC 5996, September 2010.
[RFC6097] Korhonen, J. and V. Devarapalli, "Local Mobility Anchor [RFC6097] Korhonen, J. and V. Devarapalli, "Local Mobility Anchor
(LMA) Discovery for Proxy Mobile IPv6", RFC 6097, February (LMA) Discovery for Proxy Mobile IPv6", RFC 6097,
2011. February 2011.
[RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
Deployment for Multicast Listener Support in Proxy Mobile Deployment for Multicast Listener Support in Proxy Mobile
IPv6 (PMIPv6) Domains", RFC 6224, April 2011. 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, May Bootstrapping for the Integrated Scenario", RFC 6611,
2012. May 2012.
[RFC6697] Zorn, G., Wu, Q., Taylor, T., Nir, Y., Hoeper, K., and S.
Decugis, "Handover Keying (HOKEY) Architecture Design",
RFC 6697, July 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", RFC Dutta, "Localized Routing for Proxy Mobile IPv6",
6705, September 2012. RFC 6705, September 2012.
[RFC7028] Zuniga, JC., Contreras, LM., Bernardos, CJ., Jeon, S., and [RFC7028] Zuniga, JC., Contreras, LM., Bernardos, CJ., Jeon, S., and
Y. Kim, "Multicast Mobility Routing Optimizations for Y. Kim, "Multicast Mobility Routing Optimizations for
Proxy Mobile IPv6", RFC 7028, September 2013. Proxy Mobile IPv6", RFC 7028, September 2013.
[SDO-3GPP.23.401] [SDO-3GPP.23.401]
3GPP, "General Packet Radio Service (GPRS) enhancements 3GPP, "General Packet Radio Service (GPRS) enhancements
for Evolved Universal Terrestrial Radio Access Network for Evolved Universal Terrestrial Radio Access Network
(E-UTRAN) access", 3GPP TS 23.401 10.10.0, March 2013. (E-UTRAN) access", 3GPP TS 23.401 10.10.0, March 2013.
[SDO-3GPP.23.402] [SDO-3GPP.23.402]
3GPP, "Architecture enhancements for non-3GPP accesses", 3GPP, "Architecture enhancements for non-3GPP accesses",
3GPP TS 23.402 10.8.0, September 2012. 3GPP TS 23.402 10.8.0, September 2012.
[SDO-3GPP.23.859] [SDO-3GPP.24.303]
3GPP, "Local IP access (LIPA) mobility and Selected IP 3GPP, "Mobility management based on Dual-Stack Mobile
Traffic Offload (SIPTO) at the local network", 3GPP TR IPv6; Stage 3", 3GPP TS 24.303 10.0.0, June 2013.
23.859 12.0.1, April 2013.
[SDO-3GPP.29.060] [SDO-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.
[SDO-3GPP.29.274] [SDO-3GPP.29.274]
3GPP, "3GPP Evolved Packet System (EPS); Evolved General 3GPP, "3GPP Evolved Packet System (EPS); Evolved General
Packet Radio Service (GPRS) Tunnelling Protocol for Packet Radio Service (GPRS) Tunnelling Protocol for
Control plane (GTPv2-C); Stage 3", 3GPP TS 29.274 10.11.0, Control plane (GTPv2-C); Stage 3", 3GPP TS 29.274 10.11.0,
June 2013. June 2013.
[SDO-3GPP.29.281] [SDO-3GPP.29.281]
3GPP, "General Packet Radio System (GPRS) Tunnelling 3GPP, "General Packet Radio System (GPRS) Tunnelling
Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0, Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0,
September 2011. September 2011.
[SDO-3GPP.29.303] [SDO-3GPP.29.303]
3GPP, "Domain Name System Procedures; Stage 3", 3GPP TS 3GPP, "Domain Name System Procedures; Stage 3", 3GPP
29.303 10.4.0, September 2012. TS 29.303 10.4.0, September 2012.
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
 End of changes. 77 change blocks. 
224 lines changed or deleted 290 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/