draft-ietf-dmm-requirements-07.txt   draft-ietf-dmm-requirements-08.txt 
Network Working Group H. Chan (Ed.) Network Working Group H. Chan (Ed.)
Internet-Draft Huawei Technologies (more Internet-Draft Huawei Technologies (more
Intended status: Informational co-authors on P. 17) Intended status: Informational co-authors on P. 17)
Expires: February 3, 2014 D. Liu Expires: March 30, 2014 D. Liu
China Mobile China Mobile
P. Seite P. Seite
Orange Orange
H. Yokota H. Yokota
KDDI Lab KDDI Lab
J. Korhonen J. Korhonen
Nokia Siemens Networks Renesas Mobile
August 2, 2013 September 26, 2013
Requirements for Distributed Mobility Management Requirements for Distributed Mobility Management
draft-ietf-dmm-requirements-07 draft-ietf-dmm-requirements-08
Abstract Abstract
This document defines the requirements for Distributed Mobility This document defines the requirements for Distributed Mobility
Management (DMM) in IPv6 deployments. The hierarchical structure in Management (DMM). The hierarchical structure in traditional wireless
traditional wireless networks has led to deployment models which are networks has led primarily to centralized deployment models. As some
in practice centralized. Mobility management with logically wireless networks are evolving away from the hierarchical structure,
centralized mobility anchoring in current mobile networks is prone to such as in moving the content delivery servers closer to the users, a
suboptimal routing and raises scalability issues. Such centralized distributed model for mobility management can be useful to them.
functions can lead to single points of failure and inevitably
introduce longer delays and higher signaling loads for network
operations related to mobility management. The objective is to
enhance mobility management in order to meet the primary goals in
network evolution, i.e., improve scalability, avoid single points of
failure, enable transparent mobility support to upper layers only
when needed, and so on. Distributed mobility management must be
secure and may co-exist with existing network deployments and end
hosts.
Requirements Language Requirements Language
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 RFC 2119 RFC 2119 document are to be interpreted as described in RFC 2119 RFC 2119
[RFC2119]. [RFC2119].
Status of this Memo Status of this Memo
skipping to change at page 2, line 12 skipping to change at page 2, line 4
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 March 30, 2014.
This Internet-Draft will expire on February 3, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 10 skipping to change at page 3, line 10
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . 6 2. Conventions used in this document . . . . . . . . . . . . . . 6
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3. Centralized versus distributed mobility management . . . . . . 6 3. Centralized versus distributed mobility management . . . . . . 7
3.1. Centralized mobility management . . . . . . . . . . . . . 7 3.1. Centralized mobility management . . . . . . . . . . . . . 7
3.2. Distributed mobility management . . . . . . . . . . . . . 8 3.2. Distributed mobility management . . . . . . . . . . . . . 8
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Distributed processing . . . . . . . . . . . . . . . . . . 11 5.1. Distributed processing . . . . . . . . . . . . . . . . . . 11
5.2. Transparency to Upper Layers when needed . . . . . . . . . 11 5.2. Transparency to Upper Layers when needed . . . . . . . . . 11
5.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 12 5.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 12
5.4. Existing mobility protocols . . . . . . . . . . . . . . . 12 5.4. Existing mobility protocols . . . . . . . . . . . . . . . 12
5.5. Co-existence . . . . . . . . . . . . . . . . . . . . . . . 12 5.5. Co-existence . . . . . . . . . . . . . . . . . . . . . . . 12
5.6. Security considerations . . . . . . . . . . . . . . . . . 13 5.6. Security considerations . . . . . . . . . . . . . . . . . 13
5.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 14 5.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Co-authors and Contributors . . . . . . . . . . . . . . . . . 14 8. Co-authors and Contributors . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
In the past decade a fair number of mobility protocols have been In the past decade a fair number of mobility protocols have been
standardized [RFC6275] [RFC5944] [RFC5380] [RFC6301] [RFC5213]. standardized [RFC6275] [RFC5944] [RFC5380] [RFC6301] [RFC5213].
Although the protocols differ in terms of functions and associated Although the protocols differ in terms of functions and associated
message formats, we can identify a few key common features: message formats, they all employ a mobility anchor to allow a mobile
node to remain reachable after it has moved to a different network.
o a centralized mobility anchor providing global reachability and an The anchor point, among other tasks, ensures connectivity by
always-on experience to the user; forwarding packets destined to, or sent from, the mobile node. It is
a centrally deployed mobility anchor in the sense that the deployed
o extensions to the base protocols to optimize handover performance architectures today have a small number of these anchors and the
while users roam across wireless cells; and traffic of millions of mobile nodes in an operator network are
typically managed by the same anchor.
o extensions to enable the use of heterogeneous wireless interfaces Distributed mobility management (DMM) is an alternative to the above
for multi-mode terminals (e.g. smartphones). centralized deployment. The background behind the interests to study
DMM are primarily in the following.
The presence of the centralized mobility anchor allows a mobile node (1) Mobile users are, more than ever, consuming Internet content;
to remain reachable after it has moved to a different network. The such traffic imposes new requirements on mobile core networks
anchor point, among other tasks, ensures connectivity by forwarding for data traffic delivery. The presence of content providers
packets destined to, or sent from, the mobile node. In practice, closer to Internet Service Providers (ISP) network requires
most of the deployed architectures today have a small number of taking into account local Content Delivery Networks (CDNs) while
centralized anchors managing the traffic of millions of mobile nodes. providing mobility services. Moreover, when the traffic demand
Compared with a distributed approach, a centralized approach is exceeds available capacity, service providers need to implement
likely to have several issues or limitations affecting performance new strategies such as selective traffic offload (e.g.
and scalability, which require costly network engineering to resolve. [RFC6909], 3GPP work items LIPA/SIPTO [TS.23.401]) through
alternative access networks (e.g. WLAN) [Paper-
Mobile.Data.Offloading]. A gateway selection mechanism also
takes the user proximity into account within EPC [TS.29303].
These mechanisms were not pursued in the past owing to charging
and billing reasons. Assigning a gateway anchor node from a
visited network in roaming scenario has until recently been done
and are limited to voice services only. Charging and billing
require solutions beyond the mobility protocol.
To optimize handovers from the perspective of mobile nodes, the base Both traffic offloading and CDN mechanisms could benefit from
protocols have been extended to efficiently handle packet forwarding the development of mobile architectures with fewer levels of
between the previous and new points of attachment. These extensions routing hierarchy introduced into the data path by the mobility
are necessary when applications have stringent requirements in terms management system. This trend towards so-called "flat networks"
of delay. Notions of localization and distribution of local agents works best for direct communications among peers in the same
have been introduced to reduce signaling overhead at the centralized geographical area. Distributed mobility management in a truly
routing anchor point [Paper-Distributed.Centralized.Mobility]. flat mobile architecture would anchor the traffic closer to the
Unfortunately, today we witness difficulties in getting such point of attachment of the user.
protocols deployed, resulting in sub-optimal choices for the network
operators.
Moreover, the availability of multiple-interface host and the (2) Today's mobile networks present service providers with new
possibility of using several network interfaces simultaneously have challenges. Mobility patterns indicate that mobile nodes often
motivated the development of even more protocol extensions to add remain attached to the same point of attachment for considerable
more capabilities to the mobility management protocol. In the end, periods of time [Paper-Locating.User]. Specific IP mobility
deployment is further complicated with the multitude of extensions. management support is not required for applications that launch
and complete their sessions while the mobile node is connected
to the same point of attachment. However, currently, IP
mobility support is designed for always-on operation,
maintaining all parameters of the context for each mobile
subscriber for as long as they are connected to the network.
This can result in a waste of resources and unnecessary costs
for the service provider. Infrequent node mobility coupled with
application intelligence suggest that mobility support could be
provided selectively, thus reducing the amount of context
maintained in the network.
As an effective transport method for multimedia data delivery, IP In addition, considerations in the study of DMM are in the following.
multicast support, including optimizations, have been introduced but
by "patching-up" procedure after completing the design of reference
mobility protocol, leading to network inefficiency and non-optimal
routing.
Mobile users are, more than ever, consuming Internet content; such (1) To optimize handovers from the perspective of mobile nodes, the
traffic imposes new requirements on mobile core networks for data base protocols have been extended to efficiently handle packet
traffic delivery. The presence of content providers closer to forwarding between the previous and new points of attachment.
Internet Service Providers (ISP) network requires taking into account These extensions are necessary when applications have stringent
local Content Delivery Networks (CDNs) while providing mobility requirements in terms of delay. Notions of localization and
services. Moreover, when the traffic demand exceeds available distribution of local agents have been introduced to reduce
capacity, service providers need to implement new strategies such as signaling overhead at the centralized routing anchor point
selective traffic offload (e.g. 3GPP work items LIPA/SIPTO [Paper-Distributed.Centralized.Mobility]. Unfortunately, such
[TS.23.401]) through alternative access networks (e.g. WLAN) [Paper- protocols have not been deployed today.
Mobile.Data.Offloading]. A gateway selection mechanism also takes
the user proximity into account within EPC [TS.29303]. These
mechanisms were not pursued in the past owing to charging and billing
reasons. Assigning a gateway anchor node from a visited network in
roaming scenario has until recently been done and are limited to
voice services only. Charging and billing require solutions beyond
the mobility protocol.
Both traffic offloading and CDN mechanisms could benefit from the (2) Most existing mobility protocols have not been designed for
development of mobile architectures with fewer levels of routing multiple-interface hosts which are capable to use multiple
hierarchy introduced into the data path by the mobility management interfaces simultaneously. Retrofitting the required
system. This trend towards so-called "flat networks" works best for functionality can result in an unnecessary increase in the
direct communications among peers in the same geographical area. protocol complexity.
Distributed mobility management in a truly flat mobile architecture
would anchor the traffic closer to the point of attachment of the
user.
Today's mobile networks present service providers with new (3) IP multicast support, including optimizations, have been
challenges. Mobility patterns indicate that mobile nodes often introduced as an effective transport method for multimedia data
remain attached to the same point of attachment for considerable delivery, but by "patching-up" procedure after completing the
periods of time [Paper-Locating.User]. Specific IP mobility design of reference mobility protocol, leading to network
management support is not required for applications that launch and inefficiency and non-optimal routing.
complete their sessions while the mobile node is connected to the
same point of attachment. However, currently, IP mobility support is
designed for always-on operation, maintaining all parameters of the
context for each mobile subscriber for as long as they are connected
to the network. This can result in a waste of resources and
unnecessary costs for the service provider. Infrequent node mobility
coupled with application intelligence suggest that mobility support
could be provided selectively, thus reducing the amount of context
maintained in the network.
The distributed mobility management (DMM) charter addresses two The distributed mobility management (DMM) charter addresses two
complementary aspects of mobility management procedures: the complementary aspects of mobility management procedures: the
distribution of mobility anchors towards a more flat network and the distribution of mobility anchors in the data-plane towards a more
dynamic activation/deactivation of mobility protocol support as an flat network and the selective activation/deactivation of mobility
enabler to distributed mobility management. The former aims at protocol support as an enabler to distributed mobility management.
positioning mobility anchors (e.g., HA, LMA) closer to the user; The former aims at positioning mobility anchors (e.g., HA, LMA)
ideally, mobility agents could be collocated with the first-hop closer to the user; ideally, mobility agents could be collocated with
router. The latter, facilitated by the distribution of mobility the first-hop router. The latter, facilitated by the distribution of
anchors, aims at identifying when mobility support must be activated mobility anchors, identifies when mobility support must be activated
and identifying sessions that do not require mobility management and when sessions do not require mobility management support -- thus
support -- thus reducing the amount of state information that must be reducing the amount of state information that must be maintained in
maintained in various mobility agents of the mobile network. The key various mobility agents of the mobile network. It can then avoid the
idea is that dynamic mobility management relaxes some of the unnecessary establishment of mechanisms to forward traffic from an
constraints of previously-standardized mobility management solutions old to a new mobility anchor.
and, by doing so, it can avoid the unnecessary establishment of
mechanisms to forward traffic from an old to a new mobility anchor.
This document compares distributed mobility management with This document compares distributed mobility management with
centralized mobility management in Section 3. The problems that can centralized mobility management in Section 3. The problems that can
be addressed with DMM are summarized in Section 4. The mandatory be addressed with DMM are summarized in Section 4. The mandatory
requirements as well as the optional requirements are given in requirements as well as the optional requirements are given in
Section 5. Finally, security considerations are discussed in Section Section 5. Finally, security considerations are discussed in Section
6. 6.
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 [Paper-Distributed.Mobility.Review]. be found in [Paper-Distributed.Mobility.Review].
skipping to change at page 6, line 37 skipping to change at page 6, line 34
All the general mobility-related terms and their acronyms used in All the general mobility-related terms and their acronyms used in
this document are to be interpreted as defined in the Mobile IPv6 this document are to be interpreted as defined in the Mobile IPv6
base specification [RFC6275], in the Proxy mobile IPv6 specification base specification [RFC6275], in the Proxy mobile IPv6 specification
[RFC5213], and in Mobility Related Terminology [RFC3753]. These [RFC5213], and in Mobility Related Terminology [RFC3753]. These
terms include the following: mobile node (MN), correspondent node terms include the following: mobile node (MN), correspondent node
(CN), and home agent (HA) as per [RFC6275]; local mobility anchor (CN), and home agent (HA) as per [RFC6275]; local mobility anchor
(LMA) and mobile access gateway (MAG) as per [RFC5213], and context (LMA) and mobile access gateway (MAG) as per [RFC5213], and context
as per [RFC3753]. as per [RFC3753].
In addition, this draft introduces the following term. In addition, this draft introduces the following terms.
Centrally deployed mobility anchors
refer to the mobility management deployments in which there are
very few mobility anchors and the traffic of millions of mobile
nodes in an operator network are managed by the same anchor.
Centralized mobility management
makes use of centrally deployed mobility anchors.
Distributed mobility management
is not centralized so that traffic does not need to traverse
centrally deployed mobility anchors.
Flat mobile network
has few levels of routing hierarchy introduced into the data path
by the mobility management system.
Mobility context Mobility context
is the collection of information required to provide mobility is the collection of information required to provide mobility
management support for a given mobile node. management 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 protocol stack. At the IP (network) layer, they may reside in of the protocol stack. At the IP (network) layer, mobility
the network or in the mobile node. In particular, a network-based management can be client-based or network-based.
solution resides in the network only. It therefore enables mobility
for existing hosts and network applications which are already in
deployment but lack mobility support.
At the IP layer, a mobility management protocol supporting session An IP-layer mobility management protocol is typically based on the
continuity is typically based on the principle of distinguishing principle of distinguishing between session identifier and routing
between identifier and routing address and maintaining a mapping address and maintaining a mapping between the two. In Mobile IP, the
between the two. In Mobile IP, the home address serves as an home address serves as the session identifier whereas the care-of-
identifier of the device whereas the care-of-address (CoA) takes the address (CoA) takes the role of the routing address. The binding
role of the routing address. The binding between these two is between these two is maintained at the home agent (mobility anchor).
maintained at the home agent (mobility anchor). If packets can be If packets addressed to the home address of a mobile node can be
continuously delivered to a mobile node at its home address, then all continuously delivered to the node, then all sessions using that home
sessions using that home address are unaffected even though the address are unaffected even though the routing address (CoA) changes.
routing address (CoA) changes.
The next two subsections explain centralized and distributed mobility The next two subsections explain centralized and distributed mobility
management functions in the network. management functions in the network.
3.1. Centralized mobility management 3.1. Centralized mobility management
In centralized mobility management, the mapping information between In centralized mobility management, the mapping information between
the persistent node identifier and the locator IP address of a mobile the session identifier and the locator IP address of a mobile node
node (MN) is kept at a single mobility anchor. At the same time, (MN) is kept at a single mobility anchor. At the same time, packets
packets destined to the MN are routed via this anchor. In other destined to the MN are routed via this anchor. In other words, such
words, such mobility management systems are centralized in both the mobility management systems are centralized in both the control plane
control plane and the data plane (mobile node IP traffic). and the data plane (mobile node IP traffic).
Many existing mobility management deployments make use of centralized Many existing mobility management deployments make use of centralized
mobility anchoring in a hierarchical network architecture, as shown mobility anchoring in a hierarchical network architecture, as shown
in Figure 1. Examples of such centralized mobility anchors are the in Figure 1. Examples of such centralized mobility anchors are the
home agent (HA) and local mobility anchor (LMA) in Mobile IPv6 home agent (HA) and local mobility anchor (LMA) in Mobile IPv6
[RFC6275] and Proxy Mobile IPv6 [RFC5213], respectively. Current [RFC6275] and Proxy Mobile IPv6 [RFC5213], respectively. Current
cellular networks such as the Third Generation Partnership Project cellular networks such as the Third Generation Partnership Project
(3GPP) GPRS networks, CDMA networks, and 3GPP Evolved Packet System (3GPP) GPRS networks, CDMA networks, and 3GPP Evolved Packet System
(EPS) networks employ centralized mobility management too. In (EPS) networks employ centralized mobility management too. In
particular, the Gateway GPRS Support Node (GGSN), Serving GPRS particular, the Gateway GPRS Support Node (GGSN), Serving GPRS
skipping to change at page 8, line 44 skipping to change at page 8, line 48
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| MF | | MF | | MF | | MF | | MF | | MF | | MF | | MF |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| |
+----+ +----+
| MN | | MN |
+----+ +----+
Figure 2. Distributed mobility management. Figure 2. Distributed mobility management.
Mobility management may be partially or fully distributed. In the Mobility management may be partially or fully distributed
former case only the data plane is distributed. Fully distributed [I-D.yokota-dmm-scenario]. In the former case only the data plane is
mobility management implies that both the data plane and the control distributed, implicitly assuming separation of data and control
plane are distributed. Such concepts of data and control plane planes as described in [I-D.wakikawa-netext-pmip-cp-up-separtion].
separation are not yet described in the IETF developed mobility Fully distributed mobility management implies that both the data
protocols so far but are described in detail in [I-D.yokota-dmm- plane and the control plane are distributed. While mobility
scenario]. While mobility management can be distributed, it is not management can be distributed, it is not necessary for other
necessary for other functions such as subscription management, functions such as subscription management, subscription database, and
subscription database, and network access authentication to be network access authentication to be similarly distributed.
similarly distributed.
A distributed mobility management scheme for flat IP-based mobile A distributed mobility management scheme for a flat mobile network of
network architecture consisting of access nodes is proposed in access nodes is proposed in [Paper-Distributed.Dynamic.Mobility].
[Paper-Distributed.Dynamic.Mobility]. Its benefits over centralized Its benefits over centralized mobility management are shown through
mobility management are shown through simulations in [Paper- simulations in [Paper-Distributed.Centralized.Mobility]. Moreover,
Distributed.Centralized.Mobility]. Moreover, the (re)use and the (re)use and extension of existing protocols in the design of both
extension of existing protocols in the design of both fully fully distributed mobility management [Paper-Migrating.Home.Agents]
distributed mobility management [Paper-Migrating.Home.Agents] [Paper- [Paper-Distributed.Mobility.SAE] and partially distributed mobility
Distributed.Mobility.SAE] and partially distributed mobility
management [Paper-Distributed.Mobility.PMIP] [Paper- management [Paper-Distributed.Mobility.PMIP] [Paper-
Distributed.Mobility.MIP] have been reported in the literature. Distributed.Mobility.MIP] have been reported in the literature.
Therefore, before designing new mobility management protocols for a Therefore, before designing new mobility management protocols for a
future flat IP architecture, it is recommended to first consider future distributed architecture, it is recommended to first consider
whether existing mobility management protocols can be extended to whether existing mobility management protocols can be extended.
serve a flat IP architecture.
4. Problem Statement 4. Problem Statement
The problems that can be addressed with DMM are summarized in the The problems that can be addressed with DMM are summarized in the
following: following:
PS1: Non-optimal routes PS1: Non-optimal routes
Routing via a centralized anchor often results in a longer Routing via a centralized anchor often results in non-optimal
route. The problem is manifested, for example, when accessing routes, thereby increasing the end-to-end delay. The problem
a local server or servers of a Content Delivery Network (CDN), is manifested, for example, when accessing a local server or
or when receiving locally available IP multicast or sending IP servers of a Content Delivery Network (CDN), or when receiving
multicast packets. locally available IP multicast or sending IP multicast packets.
PS2: Divergence from other evolutionary trends in network PS2: Divergence from other evolutionary trends in network
architectures such as distribution of content delivery. architectures such as distribution of content delivery.
Centralized mobility management can become non-optimal with a Centralized mobility management can become non-optimal with a
flat network architecture. flat network architecture.
PS3: Low scalability of centralized tunnel management and mobility PS3: Low scalability of centralized tunnel management and mobility
context maintenance context maintenance
skipping to change at page 10, line 12 skipping to change at page 10, line 14
context maintenance function among different network entities context maintenance function among different network entities
with proper signaling protocol design can increase scalability. with proper signaling protocol design can increase scalability.
PS4: Single point of failure and attack PS4: Single point of failure and attack
Centralized anchoring designs may be more vulnerable to single Centralized anchoring designs may be more vulnerable to single
points of failures and attacks than a distributed system. The points of failures and attacks than a distributed system. The
impact of a successful attack on a system with centralized impact of a successful attack on a system with centralized
mobility management can be far greater as well. mobility management can be far greater as well.
PS5: Unnecessarily reserving resources to provide mobility support PS5: Unnecessary mobility support to nodes that do not need it
to nodes that do not need such support
IP mobility support is not always required, and not every IP mobility support is not always required, and not every
parameter of mobility context is always used. For example, parameter of mobility context is always used. For example,
some applications do not need a stable IP address during a some applications do not need a stable IP address during a
handover to maintain session continuity. Sometimes, the entire handover to maintain session continuity. Sometimes, the entire
application session runs while the terminal does not change the application session runs while the terminal does not change the
point of attachment. Besides, some sessions, e.g. SIP-based point of attachment. Besides, some sessions, e.g. SIP-based
sessions, can handle mobility at the application layer and sessions, can handle mobility at the application layer and
hence do not need IP mobility support; it is then more hence do not need IP mobility support; it is then more
efficient to deactivate IP mobility support for such sessions. efficient to deactivate IP mobility support for such sessions.
skipping to change at page 10, line 35 skipping to change at page 10, line 36
PS6: (Related problem) Mobility signaling overhead with peer-to-peer PS6: (Related problem) Mobility signaling overhead with peer-to-peer
communication communication
Wasting resources when mobility signaling (e.g., maintenance of Wasting resources when mobility signaling (e.g., maintenance of
the tunnel, keep alive signaling, etc.) is not turned off for the tunnel, keep alive signaling, etc.) is not turned off for
peer-to-peer communication. Peer-to-peer communications have peer-to-peer communication. Peer-to-peer communications have
particular traffic patterns that often do not benefit from particular traffic patterns that often do not benefit from
mobility support from the network. Thus, the associated mobility support from the network. Thus, the associated
mobility support signaling (e.g., maintenance of the tunnel, mobility support signaling (e.g., maintenance of the tunnel,
keep alive signaling, etc.) wastes network resources for no keep alive signaling, etc.) wastes network resources for no
application gain. In such a case, it is better to enable application gain.
mobility support selectively.
PS7: (Related problem) Deployment with multiple mobility solutions PS7: (Related problem) Deployment with multiple mobility solutions
There are already many variants and extensions of MIP. There are already many variants and extensions of MIP.
Deployment of new mobility management solutions can be Deployment of new mobility management solutions can be
challenging, and debugging difficult, when they must co-exist challenging, and debugging difficult, when they must co-exist
with solutions already in the field. with solutions already in the field.
PS8: Duplicate multicast traffic PS8: Duplicate multicast traffic
skipping to change at page 12, line 6 skipping to change at page 12, line 7
DMM solutions MUST provide transparent mobility support above DMM solutions MUST provide transparent mobility support above
the IP layer when needed. Such transparency is needed, for the IP layer when needed. Such transparency is needed, for
example, when, upon change of point of attachment to the example, when, upon change of point of attachment to the
network, an application flow cannot cope with a change in the network, an application flow cannot cope with a change in the
IP address. However, it is not always necessary to maintain a IP address. However, it is not always necessary to maintain a
stable home IP address or prefix for every application or at stable home IP address or prefix for every application or at
all times for a mobile node. all times for a mobile node.
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 routing and more efficient use of network
routing by not maintaining context at the mobility anchor when resources by selecting an IP address or prefix according to
there is no such need. whether mobility support is needed and by not maintaining
context at the mobility anchor when there is no such need.
This requirement addresses the problem PS5 as well as the related This requirement addresses the problem PS5 as well as the related
problem PS6 stated in Section 4. problem PS6 stated in Section 4.
5.3. IPv6 deployment 5.3. IPv6 deployment
REQ3: IPv6 deployment REQ3: IPv6 deployment
DMM solutions SHOULD target IPv6 as the primary deployment DMM solutions SHOULD target IPv6 as the primary deployment
environment and SHOULD NOT be tailored specifically to support environment and SHOULD NOT be tailored specifically to support
skipping to change at page 15, line 14 skipping to change at page 15, line 20
9. References 9. References
9.1. Normative References 9.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.
9.2. Informative References 9.2. Informative References
[I-D.wakikawa-netext-pmip-cp-up-separation]
Wakikawa, R., Pazhyannur, R., and S. Gundavelli,
"Separation of Control and User Plane for Proxy Mobile
IPv6", draft-wakikawa-netext-pmip-cp-up-separation-00
(work in progress), July 2013.
[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.
skipping to change at page 16, line 44 skipping to change at page 17, line 8
[RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised",
RFC 5944, November 2010. RFC 5944, November 2010.
[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.
[RFC6301] Zhu, Z., Wakikawa, R., and L. Zhang, "A Survey of Mobility [RFC6301] Zhu, Z., Wakikawa, R., and L. Zhang, "A Survey of Mobility
Support in the Internet", RFC 6301, July 2011. Support in the Internet", RFC 6301, July 2011.
[RFC6909] Gundavelli, S., Zhou, X., Korhonen, J., Feige, G., and R.
Koodli, "IPv4 Traffic Offload Selector Option for Proxy
Mobile IPv6", RFC 6909, April 2013.
[TS.23.401] [TS.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 TR 23.401 10.10.0, March 2013. (E-UTRAN) access", 3GPP TR 23.401 10.10.0, March 2013.
[TS.29303] [TS.29303]
3GPP, "Domain Name System Procedures; Stage 3", 3GPP 3GPP, "Domain Name System Procedures; Stage 3", 3GPP
TR 23.303 11.2.0, September 2012. TR 23.303 11.2.0, September 2012.
Authors' Addresses Authors' Addresses
skipping to change at page 17, line 28 skipping to change at page 17, line 44
Orange Orange
4, rue du Clos Courtel, BP 91226, Cesson-Sevigne 35512, France 4, rue du Clos Courtel, BP 91226, Cesson-Sevigne 35512, France
Email: pierrick.seite@orange.com Email: pierrick.seite@orange.com
Hidetoshi Yokota Hidetoshi Yokota
KDDI Lab KDDI Lab
2-1-15 Ohara, Fujimino, Saitama, 356-8502 Japan 2-1-15 Ohara, Fujimino, Saitama, 356-8502 Japan
Email: yokota@kddilabs.jp Email: yokota@kddilabs.jp
Jouni Korhonen Jouni Korhonen
Nokia Siemens Networks Renesas Mobile
Email: jouni.korhonen@nsn.com Email: jouni.korhonen@nsn.com
- -
Charles E. Perkins Charles E. Perkins
Huawei Technologies Huawei Technologies
Email: charliep@computer.org Email: charliep@computer.org
- -
Melia Telemaco Melia Telemaco
Alcatel-Lucent Bell Labs Alcatel-Lucent Bell Labs
Email: telemaco.melia@alcatel-lucent.com Email: telemaco.melia@alcatel-lucent.com
- -
Elena Demaria Elena Demaria
Telecom Italia Telecom Italia
via G. Reiss Romoli, 274, TORINO, 10148, Italy via G. Reiss Romoli, 274, TORINO, 10148, Italy
Email: elena.demaria@telecomitalia.it Email: elena.demaria@telecomitalia.it
- -
Jong-Hyouk Lee Jong-Hyouk Lee
RSM Department, Telecom Bretagne Sangmyung University
Cesson-Sevigne, 35512, France Email: hurryon@gmail.com
Email: jh.lee@telecom-bretagne.eu
- -
Kostas Pentikousis Kostas Pentikousis
Huawei Technologies Huawei Technologies
Carnotstr. 4 10587 Berlin, Germany Carnotstr. 4 10587 Berlin, Germany
Email: k.pentikousis@huawei.com Email: k.pentikousis@huawei.com
- -
Tricci So Tricci So
ZTE ZTE
Email: tso@zteusa.com Email: tso@zteusa.com
- -
skipping to change at page 18, line 32 skipping to change at page 18, line 48
Seok Joo Koh Seok Joo Koh
Kyungpook National University, Korea Kyungpook National University, Korea
Email: sjkoh@knu.ac.kr Email: sjkoh@knu.ac.kr
- -
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
- -
Sri Gundavelli Sri Gundavelli
Cisco
sgundave@cisco.com sgundave@cisco.com
- -
Marco Liebsch Marco Liebsch
NEC Laboratories Europe NEC Laboratories Europe
Email: liebsch@neclab.eu Email: liebsch@neclab.eu
- -
Carl Williams Carl Williams
MCSR Labs MCSR Labs
Email: carlw@mcsr-labs.org Email: carlw@mcsr-labs.org
- -
skipping to change at page 19, line 6 skipping to change at page 19, line 23
Email: seiljeon@av.it.pt Email: seiljeon@av.it.pt
- -
Sergio Figueiredo Sergio Figueiredo
Universidade de Aveiro Universidade de Aveiro
Email: sfigueiredo@av.it.pt Email: sfigueiredo@av.it.pt
- -
Stig Venaas Stig Venaas
Email: stig@venaas.com Email: stig@venaas.com
- -
Luis Miguel Contreras Murillo Luis Miguel Contreras Murillo
Telefonica I+D
Email: lmcm@tid.es Email: lmcm@tid.es
- -
Juan Carlos Zuniga Juan Carlos Zuniga
InterDigital
Email: JuanCarlos.Zuniga@InterDigital.com Email: JuanCarlos.Zuniga@InterDigital.com
- -
Alexandru Petrescu Alexandru Petrescu
Email: alexandru.petrescu@gmail.com Email: alexandru.petrescu@gmail.com
- -
Georgios Karagiannis Georgios Karagiannis
University of Twente
Email: g.karagiannis@utwente.nl Email: g.karagiannis@utwente.nl
- -
Julien Laganier Julien Laganier
Juniper
jlaganier@juniper.net jlaganier@juniper.net
- -
Wassim Michel Haddad Wassim Michel Haddad
Ericsson
Wassam.Haddad@ericsson.com Wassam.Haddad@ericsson.com
- -
Dirk von Hugo Dirk von Hugo
Deutsche Telekom Laboratories
Dirk.von-Hugo@telekom.de Dirk.von-Hugo@telekom.de
- -
Ahmad Muhanna Ahmad Muhanna
Award Solutions
amuhanna@awardsolutions.com amuhanna@awardsolutions.com
- -
Byoung-Jo Kim Byoung-Jo Kim
ATT Labs ATT Labs
macsbug@research.att.com macsbug@research.att.com
- -
Hassan Aliahmad Hassan Ali-Ahmad
Orange Orange
hassan.aliahmad@orange.com hassan.aliahmad@orange.com
- -
 End of changes. 41 change blocks. 
171 lines changed or deleted 183 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/