draft-ietf-dmm-requirements-00.txt   draft-ietf-dmm-requirements-01.txt 
Network Working Group H. Chan (Ed.) Network Working Group H. Chan (Ed.)
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Informational July 7, 2012 Intended status: Informational July 12, 2012
Expires: January 8, 2013 Expires: January 13, 2013
Requirements of distributed mobility management Requirements of distributed mobility management
draft-ietf-dmm-requirements-00 draft-ietf-dmm-requirements-01
Abstract Abstract
The traditional hierarchical structure of cellular networks has led The traditional hierarchical structure of cellular networks has led
to deployment models which are heavily centralized. Mobility to deployment models which are heavily centralized. Mobility
management with centralized mobility anchoring in existing management with centralized mobility anchoring in existing
hierarchical mobile networks is quite prone to suboptimal routing and hierarchical mobile networks is quite prone to suboptimal routing and
issues related to scalability. Centralized functions present a issues related to scalability. Centralized functions present a
single point of failure, and inevitably introduce longer delays and single point of failure, and inevitably introduce longer delays and
higher signaling loads for network operations related to mobility higher signaling loads for network operations related to mobility
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 8, 2013. This Internet-Draft will expire on January 13, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 5 2. Conventions used in this document . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Centralized versus distributed mobility management . . . . . . 5 3. Centralized versus distributed mobility management . . . . . . 5
3.1. Centralized mobility management . . . . . . . . . . . . . 5 3.1. Centralized mobility management . . . . . . . . . . . . . 6
3.2. Distributed mobility management . . . . . . . . . . . . . 6 3.2. Distributed mobility management . . . . . . . . . . . . . 6
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Distributed deployment . . . . . . . . . . . . . . . . . . 8 4.1. Distributed deployment . . . . . . . . . . . . . . . . . . 8
4.2. Transparency to Upper Layers when needed . . . . . . . . . 9 4.2. Transparency to Upper Layers when needed . . . . . . . . . 9
4.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 10 4.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 10
4.4. Compatibility . . . . . . . . . . . . . . . . . . . . . . 10 4.4. Compatibility . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Existing mobility protocols . . . . . . . . . . . . . . . 11 4.5. Existing mobility protocols . . . . . . . . . . . . . . . 11
4.6. Security considerations . . . . . . . . . . . . . . . . . 11 4.6. Security considerations . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
skipping to change at page 4, line 32 skipping to change at page 4, line 32
launch and complete while the mobile device is connected to the same launch and complete while the mobile device is connected to the same
point of attachment. However, the mobility support has been designed point of attachment. However, the mobility support has been designed
to be always on and to maintain the context for each mobile to be always on and to maintain the context for each mobile
subscriber as long as they are connected to the network. This can subscriber as long as they are connected to the network. This can
result in a waste of resources and ever-increasing costs for the result in a waste of resources and ever-increasing costs for the
service provider. Infrequent mobility and intelligence of many service provider. Infrequent mobility and intelligence of many
applications suggest that mobility can be provided dynamically, thus applications suggest that mobility can be provided dynamically, thus
simplifying the context maintained in the different nodes of the simplifying the context maintained in the different nodes of the
mobile network. mobile network.
The proposed charter will address two complementary aspects of The DMM charter addresses two complementary aspects of mobility
mobility management procedures: the distribution of mobility anchors management procedures: the distribution of mobility anchors to
to achieve a more flat design and the dynamic activation/deactivation achieve a more flat design and the dynamic activation/deactivation of
of mobility protocol support as an enabler to distributed mobility mobility protocol support as an enabler to distributed mobility
management. The former has the goal of positioning mobility anchors management. The former has the goal of positioning mobility anchors
(HA, LMA) closer to the user; ideally, these mobility agents could be (HA, LMA) closer to the user; ideally, these mobility agents could be
collocated with the first hop router. The latter, facilitated by the collocated with the first hop router. The latter, facilitated by the
distribution of mobility anchors, aims at identifying when mobility distribution of mobility anchors, aims at identifying when mobility
must be activated and identifying sessions that do not impose must be activated and identifying sessions that do not impose
mobility management -- thus reducing the amount of state information mobility management -- thus reducing the amount of state information
to be maintained in the various mobility agents of the mobile to be maintained in the various mobility agents of the mobile
network. The key idea is that dynamic mobility management relaxes network. The key idea is that dynamic mobility management relaxes
some constraints while also repositioning mobility anchors; it avoids some constraints so that it may avoid the establishment of non-
the establishment of non optimal tunnels between two topologically optimal tunnels between two topologically distant anchors.
distant anchors.
This document describes the motivations of distributed mobility This document describes the motivations of distributed mobility
management in Section 1. Section 3 compares distributed mobility management in Section 1. Section 3 compares distributed mobility
management with centralized mobility management. The requirements to management with centralized mobility management. The requirements to
address these problems are given in Section 4. address these problems are given in Section 4.
The problem statement and the use cases [I-D.yokota-dmm-scenario] can The problem statement and the use cases [I-D.yokota-dmm-scenario] can
be found in the following review paper: [Paper- be found in the following review paper: [Paper-
Distributed.Mobility.Review]. Distributed.Mobility.Review].
2. Conventions used in this document 2. Conventions used in this document
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].
2.1. Terminology
All the general mobility-related terms and their acronyms used in
this document are to be interpreted as defined in the Mobile IPv6
base specification [RFC6275], in the Proxy mobile IPv6 specification
[RFC5213], and in Mobility Related Terminology [RFC3753]. These
terms include mobile node (MN), correspondent node (CN), home agent
(HA), local mobility anchor (LMA), mobile access gateway (MAG), and
context.
In addition, this draft introduces the following term.
Mobility context
is the collection of information required to provide mobility
support for a given mobile node.
3. Centralized versus distributed mobility management 3. Centralized versus distributed mobility management
Mobility management functions may be implemented at different layers Mobility management functions may be implemented at different layers
of the network protocol stack. At the IP (network) layer, they may of the network protocol stack. At the IP (network) layer, they may
reside in the network or in the mobile node. In particular, a reside in the network or in the mobile node. In particular, a
network-based solution resides in the network only. It therefore network-based solution resides in the network only. It therefore
enables mobility for existing hosts and network applications which enables mobility for existing hosts and network applications which
are already in deployment but lack mobility support. are already in deployment but lack mobility support.
At the IP layer, a mobility management protocol to achieve session At the IP layer, a mobility management protocol to achieve session
skipping to change at page 6, line 23 skipping to change at page 6, line 39
UMTS 3GPP SAE MIP/PMIP UMTS 3GPP SAE MIP/PMIP
+------+ +------+ +------+ +------+ +------+ +------+
| GGSN | | P-GW | |HA/LMA| | GGSN | | P-GW | |HA/LMA|
+------+ +------+ +------+ +------+ +------+ +------+
/\ /\ /\ /\ /\ /\
/ \ / \ / \ / \ / \ / \
/ \ / \ / \ / \ / \ / \
/ \ / \ / \ / \ / \ / \
/ \ / \ / \ / \ / \ / \
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| SGSN | | SGSN | | S-GW | | S-GW | |FA/MAG| |FA/MAG| | SGSN | | SGSN | | S-GW | | S-GW | |MN/MAG| |MN/MAG|
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
Figure 1. Centralized mobility management. Figure 1. Centralized mobility management.
3.2. Distributed mobility management 3.2. Distributed mobility management
Mobility management functions may also be distributed to multiple Mobility management functions may also be distributed to multiple
locations in different networks as shown in Figure 2, so that a locations in different networks as shown in Figure 2, so that a
mobile node in any of these networks may be served by a closeby mobile node in any of these networks may be served by a closeby
mobility function (MF). mobility function (MF).
skipping to change at page 7, line 12 skipping to change at page 7, line 29
[Paper-New.Perspective] discusses some initial steps towards a clear [Paper-New.Perspective] discusses some initial steps towards a clear
definition of what mobility management may be, to assist in better definition of what mobility management may be, to assist in better
developing distributed architecture. [Paper- developing distributed architecture. [Paper-
Characterization.Mobility.Management] analyses current mobility Characterization.Mobility.Management] analyses current mobility
solutions and proposes an initial decoupling of mobility management solutions and proposes an initial decoupling of mobility management
into well-defined functional blocks, identifying their interactions, into well-defined functional blocks, identifying their interactions,
as well as a potential grouping, which later can assist in deriving as well as a potential grouping, which later can assist in deriving
more flexible mobility management architectures. According to the more flexible mobility management architectures. According to the
split functional blocks, this paper proposes three ways into which split functional blocks, this paper proposes three ways into which
mobility management functional blocks can be groups, as an initial mobility management functional blocks can be grouped, as an initial
way to consider a better distribution: location and handover way to consider a better distribution: location and handover
management, control and data plane, user and access perspective. management, control and data plane, user and access perspective.
A distributed mobility management scheme is proposed in [Paper- A distributed mobility management scheme is proposed in [Paper-
Distributed.Dynamic.Mobility] for future flat IP architecture Distributed.Dynamic.Mobility] for future flat IP architecture
consisting of access nodes. The benefits of this design over consisting of access nodes. The benefits of this design over
centralized mobility management are also verified through simulations centralized mobility management are also verified through simulations
in [Paper-Distributed.Centralized.Mobility]. in [Paper-Distributed.Centralized.Mobility].
Before designing new mobility management protocols for a future flat Before designing new mobility management protocols for a future flat
skipping to change at page 7, line 38 skipping to change at page 8, line 6
Using MIP or PMIP for both centralized and distributed architectures Using MIP or PMIP for both centralized and distributed architectures
would ease the migration of the current mobile networks towards a would ease the migration of the current mobile networks towards a
flat architecture. It has therefore been proposed to adapt MIP or flat architecture. It has therefore been proposed to adapt MIP or
PMIPv6 to achieve distributed mobility management by using a PMIPv6 to achieve distributed mobility management by using a
distributed mobility anchor architecture. distributed mobility anchor architecture.
In [Paper-Migrating.Home.Agents], the HA functionality is copied to In [Paper-Migrating.Home.Agents], the HA functionality is copied to
many locations. The HoA of all MNs are anycast addresses, so that a many locations. The HoA of all MNs are anycast addresses, so that a
packet destined to the HoA from any corresponding node (CN) from any packet destined to the HoA from any corresponding node (CN) from any
network can be routed via the nearest copy of the HA. In addition, network can be routed via the nearest copy of the HA. In addition,
distributing the function of HA using a distributed hash table [Paper-Distributed.Mobility.SAE] proposes to distribute the function
structure is proposed in [Paper-Distributed.Mobility.SAE]. A lookup of HA into many mobility agents (MAs) each serving a portion of MNs
query to the hash table will retrieve the location information of an using a distributed hash table structure. A lookup to the hash table
MN is stored. will point to the MA serving an MN. In [Paper-
Distributed.Mobility.PMIP] and [Paper-Distributed.Mobility.MIP], only
In [Paper-Distributed.Mobility.PMIP], only the mobility routing (MR) the mobility routing (MR) function is duplicated and distributed in
function is duplicated and distributed in many locations. The many locations. The location information for any MN that has moved
location information for any MN that has moved to a visited network to a visited network is still centralized and kept at a location
is still centralized and kept at a location management (LM) function management (LM) function in the home network of the MN. The LM
in the home network of the MN. The LM function at different networks function at different networks constitutes a distributed database
constitutes a distributed database system of all the MNs that belong system of all the MNs that belong to any of these networks and have
to any of these networks and have moved to a visited network. The moved to a visited network.
location information is maintained in the form of a hierarchy: the LM
at the home network, the CoA of the MR of the visited network, and
then the CoA to reach the MN in the visited network. The LM in the
home network keeps a binding of the HoA of the MN to the CoA of the
MR of the visited network. The MR keeps the binding of the HoA of
the MN to the CoA of the MN in the case of MIP, or the proxy-CoA of
the Mobile Access Gateway (MAG) serving the MN in the case of PMIP.
[I-D.jikim-dmm-pmip] discusses two distributed mobility control
schemes using the PMIP protocol: Signal-driven PMIP (S-PMIP) and
Signal-driven Distributed PMIP (SD-PMIP). S-PMIP is a partially
distributed scheme, in which the control plane (using a Proxy Binding
Query to get the Proxy-CoA of the MN) is separate from the data
plane, and the optimized data path is directly between the CN and the
MN. SD-PMIP is a fully distributed scheme, in which the Proxy
Binding Update is not performed, and instead each MAG will multicast
a Proxy Binding Query message to all of the MAGs in its local PMIP
domain to retrieve the Proxy-CoA of the MN.
4. Requirements 4. Requirements
After reviewing the problems and limitations of centralized After comparing distributed mobility management against centralized
deployment in Section 4, this section states the requirements as deployment in Section 3, this section states the requirements as
follows: follows:
4.1. Distributed deployment 4.1. Distributed deployment
REQ1: Distributed deployment REQ1: Distributed deployment
IP mobility, network access and routing solutions provided by IP mobility, network access and routing solutions provided by
DMM MUST enable a distributed deployment of mobility DMM MUST enable a distributed deployment of mobility
management of IP sessions so that the traffic can be routed in management of IP sessions so that the traffic can be routed in
an optimal manner without traversing centrally deployed an optimal manner without traversing centrally deployed
skipping to change at page 9, line 44 skipping to change at page 9, line 38
The DMM solutions MUST provide transparency above the IP layer The DMM solutions MUST provide transparency above the IP layer
when needed. Such transparency is needed, when the mobile when needed. Such transparency is needed, when the mobile
hosts or entire mobile networks [RFC3963] change their point hosts or entire mobile networks [RFC3963] change their point
of attachment to the Internet, for the application flows that of attachment to the Internet, for the application flows that
cannot cope with a change of IP address. Otherwise the cannot cope with a change of IP address. Otherwise the
support to maintain a stable home IP address or prefix during support to maintain a stable home IP address or prefix during
handover may be declined. handover may be declined.
Motivation: The motivation of this requirement is to enable Motivation: The motivation of this requirement is to enable
more efficient use of network resources and more efficient more efficient use of network resources and more efficient
routing by not maintaining a stable IP home IP address when routing by not maintaining a stable home IP address when there
there is no such need. is no such need.
This requirement addresses the problems PS5 as well as the other This requirement addresses the problems PS5 as well as the other
related problem O-PS1. related problem O-PS1.
PS5: Wasting resources to support mobile nodes not needing mobility PS5: Wasting resources to support mobile nodes not needing mobility
support support
IP mobility support is not always required. For example, some IP mobility support is not always required. For example, some
applications do not need a stable IP address during handover, applications do not need a stable IP address during handover,
i.e., IP session continuity. Sometimes, the entire application i.e., IP session continuity. Sometimes, the entire application
skipping to change at page 10, line 48 skipping to change at page 10, line 38
4.4. Compatibility 4.4. Compatibility
REQ4: Compatibility REQ4: Compatibility
The DMM solution SHOULD be able to work between trusted The DMM solution SHOULD be able to work between trusted
administrative domains when allowed by the security measures administrative domains when allowed by the security measures
deployed between these domains. Furthermore, the DMM solution deployed between these domains. Furthermore, the DMM solution
MUST be able to co-exist with existing network deployment and MUST be able to co-exist with existing network deployment and
end hosts so that the existing deployment can continue to be end hosts so that the existing deployment can continue to be
supported. For example, depending on the environment in which supported. For example, depending on the environment in which
dmm is deployed, the dmm solutions may need to be compatible DMM is deployed, the DMM solutions may need to be compatible
with other existing mobility protocols that are deployed in with other existing mobility protocols that are deployed in
that environment or may need to be interoperable with the that environment or may need to be interoperable with the
network or the mobile hosts/routers that do not support the network or the mobile hosts/routers that do not support the
dmm enabling protocol. DMM enabling protocol.
Motivation: The motivation of this requirement is to allow Motivation: The motivation of this requirement is to allow
inter-domain operation if desired and to preserve backwards inter-domain operation if desired and to preserve backwards
compatibility so that the existing networks and hosts are not compatibility so that the existing networks and hosts are not
affected and do not break. affected and do not break.
This requirement addresses the following other related problem O-PS2. This requirement addresses the following other related problem O-PS2.
O-PS2: Complicated deployment with too many variants and extensions O-PS2: Complicated deployment with too many variants and extensions
of MIP Deployment is complicated with many variants and of MIP
extensions of MIP. When introducing new functions which may
add to the complicity, existing solutions are more vulnerable Deployment is complicated with many variants and extensions
to break. of MIP. When introducing new functions which may add to the
complexity, existing solutions are more vulnerable to break.
4.5. Existing mobility protocols 4.5. Existing mobility protocols
REQ5: Existing mobility protocols REQ5: Existing mobility protocols
A DMM solution SHOULD first consider reusing and extending the A DMM solution SHOULD first consider reusing and extending the
existing mobility protocols before specifying new protocols. existing mobility protocols before specifying new protocols.
Motivation: The purpose is to reuse the existing protocols Motivation: The purpose is to reuse the existing protocols
first before considering new protocols. first before considering new protocols.
4.6. Security considerations 4.6. Security considerations
REQ6: Security considerations REQ6: Security considerations
The protocol solutions for DMM MUST consider security, for The protocol solutions for DMM MUST consider security, for
example authentication and authorization mechanisms that allow example authentication and authorization mechanisms that allow
a legitimate mobile host/router to access to the DMM service, a legitimate mobile host/router to access to the DMM service,
protection of signaling messages of the protocol solutions in protection of signaling messages of the protocol solutions in
terms of authentication, data integrity, and data terms of authentication, data integrity, and data
confidentiality, opti-in or opt-out data confidentiality to confidentiality, opt-in or opt-out data confidentiality to
signaling messages depending on network environments or user signaling messages depending on network environments or user
requirements. requirements.
Motivation and problem statement: Mutual authentication and Motivation and problem statement: Mutual authentication and
authorization between a mobile host/router and an access authorization between a mobile host/router and an access
router providing the DMM service to the mobile host/router are router providing the DMM service to the mobile host/router are
required to prevent potential attacks in the access network of required to prevent potential attacks in the access network of
the DMM service. Otherwise, various attacks such as the DMM service. Otherwise, various attacks such as
impersonation, denial of service, man-in-the-middle attacks, impersonation, denial of service, man-in-the-middle attacks,
etc. are present to obtain illegitimate access or to collapse etc. are present to obtain illegitimate access or to collapse
skipping to change at page 13, line 4 skipping to change at page 12, line 43
Pierrick Seite: pierrick.seite@orange-ftgroup.com Pierrick Seite: pierrick.seite@orange-ftgroup.com
Hidetoshi Yokota: yokota@kddilabs.jp Hidetoshi Yokota: yokota@kddilabs.jp
Charles E. Perkins: charliep@computer.org Charles E. Perkins: charliep@computer.org
Melia Telemaco: telemaco.melia@alcatel-lucent.com Melia Telemaco: telemaco.melia@alcatel-lucent.com
Elena Demaria: elena.demaria@telecomitalia.it Elena Demaria: elena.demaria@telecomitalia.it
Peter McCann: Peter.McCann@huawei.com Peter McCann: Peter.McCann@huawei.com
Tricci So: tso@zteusa.com Tricci So: tso@zteusa.com
Jong-Hyouk Lee: jh.lee@telecom-bretagne.eu Jong-Hyouk Lee: jh.lee@telecom-bretagne.eu
Jouni Korhonen: jouni.korhonen@nsn.com Jouni Korhonen: jouni.korhonen@nsn.com
Sri Gundavelli: sgundave@cisco.com
Wen Luo: luo.wen@zte.com.cn
Carlos J. Bernardos: cjbc@it.uc3m.es Carlos J. Bernardos: cjbc@it.uc3m.es
Marco Liebsch: Marco.Liebsch@neclab.eu Marco Liebsch: Marco.Liebsch@neclab.eu
Georgios Karagian: karagian@cs.utwente.nl Wen Luo: luo.wen@zte.com.cn
Georgios Karagiannis: g.karagiannis@utwente.nl
Julien Laganier: jlaganier@juniper.net Julien Laganier: jlaganier@juniper.net
Wassim Michel Haddad: Wassam.Haddad@ericsson.com Wassim Michel Haddad: Wassam.Haddad@ericsson.com
Seok Joo Koh: sjkoh@knu.ac.kr Seok Joo Koh: sjkoh@knu.ac.kr
Dirk von Hugo: Dirk.von-Hugo@telekom.de
Ahmad Muhanna: amuhanna@awardsolutions.com
8. References 8. References
8.1. Normative References 8.1. Normative References
[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.
8.2. Informative References 8.2. Informative References
[I-D.ietf-netext-pd-pmip] [I-D.ietf-netext-pd-pmip]
Zhou, X., Korhonen, J., Williams, C., Gundavelli, S., and Zhou, X., Korhonen, J., Williams, C., Gundavelli, S., and
C. Bernardos, "Prefix Delegation for Proxy Mobile IPv6", C. Bernardos, "Prefix Delegation for Proxy Mobile IPv6",
draft-ietf-netext-pd-pmip-02 (work in progress), draft-ietf-netext-pd-pmip-02 (work in progress),
March 2012. March 2012.
[I-D.jikim-dmm-pmip]
Kim, J., Koh, S., Jung, H., and Y. Han, "Use of Proxy
Mobile IPv6 for Distributed Mobility Control",
draft-jikim-dmm-pmip-00 (work in progress), March 2012.
[I-D.yokota-dmm-scenario] [I-D.yokota-dmm-scenario]
Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case
scenarios for Distributed Mobility Management", scenarios for Distributed Mobility Management",
draft-yokota-dmm-scenario-00 (work in progress), draft-yokota-dmm-scenario-00 (work in progress),
October 2010. October 2010.
[Paper-Distributed.Centralized.Mobility] [Paper-Distributed.Centralized.Mobility]
Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed
or Centralized Mobility", Proceedings of Global or Centralized Mobility", Proceedings of Global
Communications Conference (GlobeCom), December 2009. Communications Conference (GlobeCom), December 2009.
[Paper-Distributed.Dynamic.Mobility] [Paper-Distributed.Dynamic.Mobility]
Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed
Dynamic Mobility Management Scheme Designed for Flat IP Dynamic Mobility Management Scheme Designed for Flat IP
Architectures", Proceedings of 3rd International Architectures", Proceedings of 3rd International
Conference on New Technologies, Mobility and Security Conference on New Technologies, Mobility and Security
(NTMS), 2008. (NTMS), 2008.
[Paper-Distributed.Mobility.MIP]
Chan, H., "Distributed Mobility Management with Mobile
IP", Proceedings of IEEE International Communication
Conference (ICC) Workshop on Telecommunications: from
Research to Standards, June 2012.
[Paper-Distributed.Mobility.PMIP] [Paper-Distributed.Mobility.PMIP]
Chan, H., "Proxy Mobile IP with Distributed Mobility Chan, H., "Proxy Mobile IP with Distributed Mobility
Anchors", Proceedings of GlobeCom Workshop on Seamless Anchors", Proceedings of GlobeCom Workshop on Seamless
Wireless Mobility, December 2010. Wireless Mobility, December 2010.
[Paper-Distributed.Mobility.Review] [Paper-Distributed.Mobility.Review]
Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu, Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu,
"Distributed and Dynamic Mobility Management in Mobile "Distributed and Dynamic Mobility Management in Mobile
Internet: Current Approaches and Issues, Journal of Internet: Current Approaches and Issues, Journal of
Communications, vol. 6, no. 1, pp. 4-15, Feb 2011.", Communications, vol. 6, no. 1, pp. 4-15, Feb 2011.",
skipping to change at line 719 skipping to change at page 16, line 30
- -
Wen Luo Wen Luo
ZTE ZTE
No.68, Zijinhua RD,Yuhuatai District, Nanjing, Jiangsu 210012, China No.68, Zijinhua RD,Yuhuatai District, Nanjing, Jiangsu 210012, China
Email: luo.wen@zte.com.cn Email: luo.wen@zte.com.cn
- -
Marco Liebsch Marco Liebsch
NEC Laboratories Europe NEC Laboratories Europe
Email: liebsch@neclab.eu Email: liebsch@neclab.eu
- -
Carl Williams
MCSR Labs
Email: carlw@mcsr-labs.org
-
 End of changes. 24 change blocks. 
63 lines changed or deleted 70 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/