draft-ietf-dmm-best-practices-gap-analysis-05.txt   draft-ietf-dmm-best-practices-gap-analysis-06.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: January 4, 2015 InterDigital Expires: January 5, 2015 InterDigital
P. Seite P. Seite
Orange Orange
H. Chan H. Chan
Huawei Technologies Huawei Technologies
CJ. Bernardos CJ. Bernardos
UC3M UC3M
July 3, 2014 July 4, 2014
Distributed Mobility Management: Current practices and gap analysis Distributed Mobility Management: Current practices and gap analysis
draft-ietf-dmm-best-practices-gap-analysis-05 draft-ietf-dmm-best-practices-gap-analysis-06
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 January 4, 2015. This Internet-Draft will expire on January 5, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
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 mobility management - REQ1 . . . . . . . . . . 17 5.1. Distributed mobility management - REQ1 . . . . . . . . . 17
5.2. Bypassable network-layer mobility support for each 5.2. Bypassable network-layer mobility support for each
application session - REQ2 . . . . . . . . . . . . . . . . 19 application session - REQ2 . . . . . . . . . . . . . . . 19
5.3. IPv6 deployment - REQ3 . . . . . . . . . . . . . . . . . . 20 5.3. IPv6 deployment - REQ3 . . . . . . . . . . . . . . . . . 20
5.4. Existing mobility protocols - REQ4 . . . . . . . . . . . . 21 5.4. Existing mobility protocols - REQ4 . . . . . . . . . . . 21
5.5. Coexistence with deployed networks/hosts and 5.5. Coexistence with deployed networks/hosts and operability
operability across different networks- REQ5 . . . . . . . 21 across different networks- REQ5 . . . . . . . . . . . . . 21
5.6. Operation and management considerations - REQ6 . . . . . . 21 5.6. Operation and management considerations - REQ6 . . . . . 22
5.7. Security considerations - REQ7 . . . . . . . . . . . . . . 22 5.7. Security considerations - REQ7 . . . . . . . . . . . . . 22
5.8. Multicast - REQ8 . . . . . . . . . . . . . . . . . . . . . 22 5.8. Multicast - REQ8 . . . . . . . . . . . . . . . . . . . . 23
5.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Normative References . . . . . . . . . . . . . . . . . . . 24 8.1. Normative References . . . . . . . . . . . . . . . . . . 24
8.2. Informative References . . . . . . . . . . . . . . . . . . 25 8.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 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
skipping to change at page 7, line 17 skipping to change at page 7, line 7
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
kind 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
skipping to change at page 8, line 21 skipping to change at page 8, line 10
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. In this deployment model, the mobile node can use mobile node. In this deployment model, the mobile node can use
several anchors at the same time, each of them anchoring IP flows several anchors at the same time, each of them anchoring IP flows
initiated at a different point of attachment. However there is no initiated at a different point of attachment. However there is no
mechanism specified by IETF to enable an efficient dynamic discovery mechanism specified by IETF to enable an efficient dynamic discovery
of available anchors and the selection of the most suitable one. of available anchors and the selection of the most suitable one.
Note that some of these mechanisms [SDO-3GPP.23.402] have been Note that some of these mechanisms [SDO-3GPP.23.402] have been
defined outside IETF. defined 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 19, line 32 skipping to change at page 19, line 30
re-authentication process after a change of anchor. Note that some re-authentication process after a change of anchor. Note that some
extensions might be needed in the context of DMM, as these protocols extensions might be needed in the context of DMM, as these protocols
were designed in the context of centralized client IP mobility, were designed in the context of centralized client IP mobility,
focusing on the access re-attachment and authentication. 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 both 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. Bypassable network-layer mobility support for each application 5.2. Bypassable network-layer mobility support for each application
session - REQ2 session - REQ2
The need for "bypassable network-layer mobility support for each The need for "bypassable network-layer mobility support for each
application session" introduced in [I-D.ietf-dmm-requirements] application session" introduced in [I-D.ietf-dmm-requirements]
requires flexibility on determining whether network-layer mobility requires flexibility on determining whether network-layer mobility
support is needed. The requirement enables one to choose whether or support is needed. The requirement enables one to choose whether or
not use network-layer mobility support. It only enables the two not use network-layer mobility support. It only 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
skipping to change at page 21, line 24 skipping to change at page 21, line 24
A DMM solution must first consider reusing and extending IETF- A DMM solution must first consider reusing and extending IETF-
standardized protocols before specifying new protocols. standardized protocols before specifying new protocols.
As stated in [I-D.ietf-dmm-requirements], a DMM solution could reuse As stated in [I-D.ietf-dmm-requirements], a DMM solution could reuse
existing IETF and standardized protocols before specifying new existing IETF and standardized protocols before specifying new
protocols. Besides, Section 4 of this document discusses various protocols. Besides, Section 4 of this document discusses various
ways to flatten and distribute current mobility solutions. Actually, ways to flatten and distribute current mobility solutions. Actually,
nothing prevent the distribution of mobility functions with 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.
function, i.e., the PGW, can be also be distributed, but with
limitations; e.g., no anchoring relocation, no context transfer
between anchors and centralized control plane. The 3GPP architecture
is also going into the direction of flattening with SIPTO and LIPA,
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. Coexistence with deployed networks/hosts and operability across 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 and centralized control plane. The
3GPP architecture is also going into the direction of flattening with
SIPTO and LIPA, though they do not provide full mobility support.
For example, mobility support for SIPTO traffic can be rather
limited, and offloaded traffic cannot access operator services.
Thus, the operator must be very careful in selecting which traffic to
offload.
5.5. Coexistence with deployed networks/hosts and operability across
different networks- REQ5 different networks- REQ5
According to [I-D.ietf-dmm-requirements], DMM implementations must be According to [I-D.ietf-dmm-requirements], DMM implementations must be
able to co-exist with existing network deployments, end hosts and able to co-exist with existing network deployments, end hosts and
routers, and a DMM solution SHOULD work across different networks, routers, and a DMM solution SHOULD work across different networks,
possibly operated as separate administrative domains, when the needed possibly operated as separate administrative domains, when the needed
mobility management signaling, forwarding, and network access are mobility management signaling, forwarding, and network access are
allowed by the trust relationship between them. All current mobility allowed by the trust relationship between them. All current mobility
protocols can co-exist with existing network deployments and end protocols can co-exist with existing network deployments and end
hosts. There is no gap between existing mobility protocols and this hosts. There is no gap between existing mobility protocols and this
requirement. requirement.
5.6. Operation and management considerations - REQ6 5.6. Operation and management considerations - REQ6
As stated in [I-D.ietf-dmm-requirements], (1) a DMM solution needs to As stated in [I-D.ietf-dmm-requirements], (1) a DMM solution needs to
consider configuring a device, monitoring the current operational consider configuring a device, monitoring the current operational
state of a device, responding to events that impact the device, state of a device, responding to events that impact the device,
possibly by modifying the configuration and storing the data in a possibly by modifying the configuration and storing the data in a
format that can be analyzed later. (2) a DMM solution MUST describe format that can be analyzed later. (2) a DMM solution MUST describe
in what environment and how it can be scalably deployed and managed. in what environment and how it can be scalably deployed and managed.
(3) a DMM solution MUST support mechanisms to test if the DMM (3) a DMM solution MUST support mechanisms to test if the DMM
solution is working properly. (4) a DMM solution SHOULD expose the solution is working properly. (4) a DMM solution SHOULD expose the
operational state of DMM to the administrators of the DMM entities. operational state of DMM to the administrators of the DMM entities.
(5) a DMM solution, which supports flow mobility, SHOULD support (5) a DMM solution, which supports flow mobility, SHOULD support
means to correlate the flow routing policies and the observed means to correlate the flow routing policies and the observed
forwarding actions. (6) a DMM solution SHOULD support mechanisms to forwarding actions. (6) a DMM solution SHOULD support mechanisms to
check the liveness of forwarding path. (7) a DMM solution MUST check the liveness of forwarding path. (7) a DMM solution MUST
provide fault management and monitoring mechanisms to manage provide fault management and monitoring mechanisms to manage
situations where update of the mobility session or the data path situations where update of the mobility session or the data path
fails. (8) a DMM solution SHOULD be able to monitor usage of DMM fails. (8) a DMM solution SHOULD be able to monitor usage of DMM
protocol. (9) DMM solutions SHOULD support standardized configuration protocol. (9) DMM solutions SHOULD support standardized
with NETCONF [RFC6241], using YANG [RFC6020] modules, which SHOULD be configuration with NETCONF [RFC6241], using YANG [RFC6020] modules,
created for DMM when needed for such configuration. which SHOULD be created for DMM when needed for such configuration.
Existing mobility management protocols have not thoroughly documented Existing mobility management protocols have not thoroughly documented
the above list of operation and management considerations. Each of the above list of operation and management considerations. Each of
the above needs to be considered from the begining in a DMM solution. the above needs to be considered from the begining in a DMM solution.
Management information base (MIB) objects are currently defined in Management information base (MIB) objects are currently defined in
[RFC4295] for MIPv6 and in [RFC6475] for PMIPv6. Standardized [RFC4295] for MIPv6 and in [RFC6475] for PMIPv6. Standardized
configuration with NETCONF [RFC6241], using YANG [RFC6020] modules is configuration with NETCONF [RFC6241], using YANG [RFC6020] modules is
needed. needed.
skipping to change at page 24, line 43 skipping to change at page 24, line 50
7. IANA Considerations 7. IANA Considerations
None. None.
8. References 8. References
8.1. Normative References 8.1. Normative References
[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-
draft-ietf-dmm-requirements-17 (work in progress), ietf-dmm-requirements-17 (work in progress), June 2014.
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.
[RFC4295] Keeni, G., Koide, K., Nagami, K., and S. Gundavelli, [RFC4295] Keeni, G., Koide, K., Nagami, K., and S. Gundavelli,
"Mobile IPv6 Management Information Base", RFC 4295, "Mobile IPv6 Management Information Base", RFC 4295, April
April 2006. 2006.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020, Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010. October 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", Bierman, "Network Configuration Protocol (NETCONF)", RFC
RFC 6241, June 2011. 6241, June 2011.
[RFC6475] Keeni, G., Koide, K., Gundavelli, S., and R. Wakikawa, [RFC6475] Keeni, G., Koide, K., Gundavelli, S., and R. Wakikawa,
"Proxy Mobile IPv6 Management Information Base", RFC 6475, "Proxy Mobile IPv6 Management Information Base", RFC 6475,
May 2012. May 2012.
8.2. Informative References 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), draft-anipko-mif-mpvd-arch-05 (work in progress), November
November 2013. 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", Architectures", draft-gundavelli-v6ops-community-wifi-
draft-gundavelli-v6ops-community-wifi-svcs-06 (work in svcs-06 (work in progress), April 2013.
progress), April 2013.
[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-05 Mobile IPv6", draft-ietf-netext-pmip-cp-up-separation-05
(work in progress), July 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", Liu, "IPv6 Prefix Properties", draft-korhonen-6man-prefix-
draft-korhonen-6man-prefix-properties-02 (work in properties-02 (work in progress), July 2013.
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, <http:// Systems", IEEE Standard 802.16, 2009,
standards.ieee.org/getieee802/download/802.16-2009.pdf>. <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.
[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)", Shim, "Candidate Access Router Discovery (CARD)", RFC
RFC 4066, July 2005. 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, bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, September
September 2006. 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", Mobility Route Optimization Solution Space Analysis", RFC
RFC 4889, July 2007. 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 27, line 9 skipping to change at page 27, line 12
[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, [RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, July
July 2009. 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)", "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
RFC 5996, September 2010. 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, (LMA) Discovery for Proxy Mobile IPv6", RFC 6097, February
February 2011. 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, Bootstrapping for the Integrated Scenario", RFC 6611, May
May 2012. 2012.
[RFC6697] Zorn, G., Wu, Q., Taylor, T., Nir, Y., Hoeper, K., and S. [RFC6697] Zorn, G., Wu, Q., Taylor, T., Nir, Y., Hoeper, K., and S.
Decugis, "Handover Keying (HOKEY) Architecture Design", Decugis, "Handover Keying (HOKEY) Architecture Design",
RFC 6697, July 2012. 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", Dutta, "Localized Routing for Proxy Mobile IPv6", RFC
RFC 6705, September 2012. 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.
skipping to change at page 28, line 32 skipping to change at page 28, line 35
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 3GPP, "Domain Name System Procedures; Stage 3", 3GPP TS
TS 29.303 10.4.0, September 2012. 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. 34 change blocks. 
108 lines changed or deleted 109 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/