draft-ietf-dmm-requirements-10.txt   draft-ietf-dmm-requirements-11.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: May 11, 2014 D. Liu Expires: May 25, 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
Renesas Mobile Broadcom Communications
November 7, 2013 November 21, 2013
Requirements for Distributed Mobility Management Requirements for Distributed Mobility Management
draft-ietf-dmm-requirements-10 draft-ietf-dmm-requirements-11
Abstract Abstract
This document defines the requirements for Distributed Mobility This document defines the requirements for Distributed Mobility
Management (DMM). The hierarchical structure in traditional wireless Management (DMM). The hierarchical structure in traditional wireless
networks has led primarily to centralized deployment models. As some networks has led primarily to centralized deployment models. As some
wireless networks are evolving away from the hierarchical structure, wireless networks are evolving away from the hierarchical structure,
such as in moving the content delivery servers closer to the users, a a distributed model for mobility management can be useful to them.
distributed model for mobility management can be useful to them.
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 4 skipping to change at page 1, line 48
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 May 11, 2014.
This Internet-Draft will expire on May 25, 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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 6 2. Conventions used in this document . . . . . . . . . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Centralized versus distributed mobility management . . . . . . 7 3. Centralized versus distributed mobility management . . . . . . 5
3.1. Centralized mobility management . . . . . . . . . . . . . 7 3.1. Centralized mobility management . . . . . . . . . . . . . 6
3.2. Distributed mobility management . . . . . . . . . . . . . 8 3.2. Distributed mobility management . . . . . . . . . . . . . 7
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Distributed processing . . . . . . . . . . . . . . . . . . 11 5.1. Distributed processing . . . . . . . . . . . . . . . . . . 10
5.2. Transparency to Upper Layers when needed . . . . . . . . . 11 5.2. Transparency to Upper Layers when needed . . . . . . . . . 10
5.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 12 5.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 11
5.4. Existing mobility protocols . . . . . . . . . . . . . . . 12 5.4. Existing mobility protocols . . . . . . . . . . . . . . . 11
5.5. Co-existence . . . . . . . . . . . . . . . . . . . . . . . 13 5.5. Co-existence . . . . . . . . . . . . . . . . . . . . . . . 11
5.6. Security considerations . . . . . . . . . . . . . . . . . 13 5.6. Security considerations . . . . . . . . . . . . . . . . . 12
5.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 14 5.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Co-authors and Contributors . . . . . . . . . . . . . . . . . 14 8. Co-authors and Contributors . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
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, they all employ a mobility anchor to allow a mobile message formats, they all employ a mobility anchor to allow a mobile
node to remain reachable after it has moved to a different network. node to remain reachable after it has moved to a different network.
The anchor point, among other tasks, ensures connectivity by The anchor point, among other tasks, ensures connectivity by
forwarding packets destined to, or sent from, the mobile node. It is forwarding packets destined to, or sent from, the mobile node. It is
a centrally deployed mobility anchor in the sense that the deployed a centrally deployed mobility anchor in the sense that the deployed
architectures today have a small number of these anchors and the architectures today have a small number of these anchors and the
traffic of millions of mobile nodes in an operator network are traffic of millions of mobile nodes in an operator network are
typically managed by the same anchor. typically managed by the same anchor.
Distributed mobility management (DMM) is an alternative to the above Distributed mobility management (DMM) is an alternative to the above
centralized deployment. The background behind the interests to study centralized deployment. The background behind the interests to study
DMM are primarily in the following. DMM are primarily in the following.
(1) Mobile users are, more than ever, consuming Internet content; (1) Mobile users are, more than ever, consuming Internet content
such traffic imposes new requirements on mobile core networks including that of local Content Delivery Networks (CDNs) which
for data traffic delivery. The presence of content providers had not taken mobility service into account before. Such
closer to Internet Service Providers (ISP) network requires traffic imposes new requirements on mobile core networks for
taking into account local Content Delivery Networks (CDNs) while data traffic delivery. To prevent exceeding the available core
providing mobility services. Moreover, when the traffic demand network capacity, service providers need to implement new
exceeds available capacity, service providers need to implement strategies such as selective IPv4 traffic offload (e.g.
new strategies such as selective IPv4 traffic offload (e.g.
[RFC6909], 3GPP work items LIPA/SIPTO [TS.23.401]) through [RFC6909], 3GPP work items LIPA/SIPTO [TS.23.401]) through
alternative access networks (e.g. WLAN) [Paper- alternative access networks (e.g. WLAN) [Paper-
Mobile.Data.Offloading]. A gateway selection mechanism also Mobile.Data.Offloading]. In addition, a gateway selection
takes the user proximity into account within EPC [TS.29303]. mechanism takes the user proximity into account within EPC
These mechanisms were not pursued in the past owing to charging [TS.29303]. Yet these mechanisms were not pursued in the past
and billing reasons. Assigning a gateway anchor node from a owing to charging and billing which require solutions beyond the
visited network in roaming scenario has until recently been done mobility protocol. Consequently, assigning a gateway anchor
and are limited to voice services only. Charging and billing node from a visited network in roaming scenario has until
require solutions beyond the mobility protocol. recently been done and are limited to voice services only.
Both traffic offloading and CDN mechanisms could benefit from Both traffic offloading and CDN mechanisms could benefit from
the development of mobile architectures with fewer levels of the development of mobile architectures with fewer levels of
routing hierarchy introduced into the data path by the mobility routing hierarchy introduced into the data path by the mobility
management system. This trend towards so-called "flat networks" management system. This trend towards so-called "flat networks"
works best for direct communications among peers in the same works best for direct communications among peers in the same
geographical area. Distributed mobility management in a truly geographical area. Distributed mobility management in a truly
flat mobile architecture would anchor the traffic closer to the flat mobile architecture would anchor the traffic closer to the
point of attachment of the user. point of attachment of the user.
skipping to change at page 5, line 22 skipping to change at page 4, line 17
mobility support is designed for always-on operation, mobility support is designed for always-on operation,
maintaining all parameters of the context for each mobile maintaining all parameters of the context for each mobile
subscriber for as long as they are connected to the network. subscriber for as long as they are connected to the network.
This can result in a waste of resources and unnecessary costs This can result in a waste of resources and unnecessary costs
for the service provider. Infrequent node mobility coupled with for the service provider. Infrequent node mobility coupled with
application intelligence suggest that mobility support could be application intelligence suggest that mobility support could be
provided selectively such as in [I-D.bhandari-dhc-class-based- provided selectively such as in [I-D.bhandari-dhc-class-based-
prefix] and [I-D.korhonen-6man-prefix-properties], thus reducing prefix] and [I-D.korhonen-6man-prefix-properties], thus reducing
the amount of context maintained in the network. the amount of context maintained in the network.
In addition, considerations in the study of DMM are in the following.
(1) To optimize handovers from the perspective of mobile nodes, the
base protocols have been extended to efficiently handle packet
forwarding between the previous and new points of attachment.
These extensions are necessary when applications have stringent
requirements in terms of delay. Notions of localization and
distribution of local agents have been introduced to reduce
signaling overhead at the centralized routing anchor point
[Paper-Distributed.Centralized.Mobility]. Unfortunately, such
protocols have not been deployed today.
(2) Most existing mobility protocols have not been designed for
multiple-interface hosts which are capable to use multiple
interfaces simultaneously. Retrofitting the required
functionality can result in an unnecessary increase in the
protocol complexity.
(3) IP multicast support, including optimizations, have been
introduced as an effective transport method for multimedia data
delivery, but by "patching-up" procedure after completing the
design of reference mobility protocol, leading to network
inefficiency and non-optimal routing.
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 in the data-plane towards a more distribution of mobility anchors in the data-plane towards a more
flat network and the selective activation/deactivation of mobility flat network and the selective activation/deactivation of mobility
protocol support as an enabler to distributed mobility management. protocol support as an enabler to distributed mobility management.
The former aims at positioning mobility anchors (e.g., HA, LMA) The former aims at positioning mobility anchors (e.g., HA, LMA)
closer to the user; ideally, mobility agents could be collocated with closer to the user; ideally, mobility agents could be collocated with
the first-hop router. The latter, facilitated by the distribution of the first-hop router. The latter, facilitated by the distribution of
mobility anchors, identifies when mobility support must be activated mobility anchors, identifies when mobility support must be activated
and when sessions do not require mobility management support -- thus and when sessions do not require mobility management support -- thus
skipping to change at page 6, line 50 skipping to change at page 5, line 23
very few mobility anchors and the traffic of millions of mobile very few mobility anchors and the traffic of millions of mobile
nodes in an operator network are managed by the same anchor. nodes in an operator network are managed by the same anchor.
Centralized mobility management Centralized mobility management
makes use of centrally deployed mobility anchors. makes use of centrally deployed mobility anchors.
Distributed mobility management Distributed mobility management
is not centralized so that traffic does not need to traverse is not centralized so that traffic does not need to traverse
centrally deployed mobility anchors. centrally deployed mobility anchors far from the optimal route.
Flat mobile network Flat mobile network
has few levels of routing hierarchy introduced into the data path has few levels of routing hierarchy introduced into the data path
by the mobility management system. 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.
skipping to change at page 8, line 36 skipping to change at page 7, line 32
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
|RNC| |RNC| |RNC| |RNC| |RNC| |RNC| |RNC| |RNC|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
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
networks as shown in Figure 2, so that a mobile node in any of these networks as shown in Figure 2, so that a mobile node in any of these
networks may be served by a nearby mobility function (MF). networks may be served by a nearby function with appropriate routing/
mobility management (RM) capability.
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| MF | | MF | | MF | | MF | | RM | | RM | | RM | | RM |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| |
+----+ +----+
| MN | | MN |
+----+ +----+
Figure 2. Distributed mobility management. Figure 2. Distributed mobility management.
Mobility management may be partially or fully distributed Mobility management may be partially or fully distributed
[I-D.yokota-dmm-scenario]. In the former case only the data plane is [I-D.yokota-dmm-scenario]. In the former case only the data plane is
distributed, implicitly assuming separation of data and control distributed, implicitly assuming separation of data and control
planes as described in [I-D.wakikawa-netext-pmip-cp-up-separtion]. planes as described in [I-D.wakikawa-netext-pmip-cp-up-separtion].
Fully distributed mobility management implies that both the data Fully distributed mobility management implies that both the data
plane and the control plane are distributed. While mobility plane and the control plane are distributed. While mobility
management can be distributed, it is not necessary for other management can be distributed, it is not necessary for other
functions such as subscription management, subscription database, and functions such as subscription management, subscription database, and
network access authentication to be similarly distributed. network access authentication to be similarly distributed.
A distributed mobility management scheme for a flat mobile network of A distributed mobility management scheme for a flat mobile network of
access nodes is proposed in [Paper-Distributed.Dynamic.Mobility]. access nodes is proposed in [Paper-Distributed.Dynamic.Mobility].
Its benefits over centralized mobility management are shown through Its benefits over centralized mobility management have been shown
simulations in [Paper-Distributed.Centralized.Mobility]. Moreover, through simulations [Paper-Distributed.Centralized.Mobility].
the (re)use and extension of existing protocols in the design of both Moreover, the (re)use and extension of existing protocols in the
fully distributed mobility management [Paper-Migrating.Home.Agents] design of both fully distributed mobility management [Paper-
[Paper-Distributed.Mobility.SAE] and partially distributed mobility Migrating.Home.Agents] [Paper-Distributed.Mobility.SAE] and partially
management [Paper-Distributed.Mobility.PMIP] [Paper- distributed mobility management [Paper-Distributed.Mobility.PMIP]
Distributed.Mobility.MIP] have been reported in the literature. [Paper-Distributed.Mobility.MIP] have been reported in the
Therefore, before designing new mobility management protocols for a literature. Therefore, before designing new mobility management
future distributed architecture, it is recommended to first consider protocols for a future distributed architecture, it is recommended to
whether existing mobility management protocols can be extended. first consider whether existing mobility management protocols can be
extended.
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 non-optimal Routing via a centralized anchor often results in non-optimal
routes, thereby increasing the end-to-end delay. The problem routes, thereby increasing the end-to-end delay. The problem
is manifested, for example, when accessing a nearby server or is manifested, for example, when accessing a nearby server or
servers of a Content Delivery Network (CDN), or when receiving servers of a Content Delivery Network (CDN), or when receiving
locally available IP multicast or sending IP multicast packets. locally available IP multicast or sending IP multicast packets.
(Existing route optimization is only a host-based solution. On (Existing route optimization is only a host-based solution. On
the other hand, localized routing with PMIPv6 [RFC6705] the other hand, localized routing with PMIPv6 [RFC6705]
addresses only a part of the problem where both the MN and the addresses only a part of the problem where both the MN and the
CN are located in the PMIP domain and attached to a MAG, and is CN are attached to the same MAG, and it is not applicable when
not applicable when the CN is outside the PMIP domain or does the CN does not behave like an MN.)
not behave like an MN.)
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 Mobile networks have generally been evolving towards a flat
flat network architecture. network. Centralized mobility management, which is non-optimal
with a flat network architecture, does not support this
evolution.
PS3: Low scalability of centralized tunnel management and mobility PS3: Scalability of centralized tunnel management and mobility
context maintenance context maintenance
Setting up tunnels through a central anchor and maintaining Setting up tunnels through a central anchor and maintaining
mobility context for each MN usually requires more concentrated mobility context for each MN usually requires more concentrated
resources in a centralized design, thus reducing scalability. resources in a centralized design, thus reducing scalability.
Distributing the tunnel maintenance function and the mobility Distributing the tunnel maintenance function and the mobility
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 avoid increasing the
concentrated resources with an increasing number of MNs.
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: Unnecessary mobility support to nodes that do not need it PS5: Unnecessary mobility support to clients that do not need it
IP mobility support is not always required, and not every IP mobility support is usually provided to all MNs. Yet it is
parameter of mobility context is always used. For example, not always required, and not every parameter of mobility
some applications do not need a stable IP address during a context is always used. For example, some applications do not
handover to maintain session continuity. Sometimes, the entire need a stable IP address during a handover to maintain session
application session runs while the terminal does not change the continuity. Sometimes, the entire application session runs
point of attachment. Besides, some sessions, e.g. SIP-based while the terminal does not change the point of attachment.
sessions, can handle mobility at the application layer and Besides, some sessions, e.g. SIP-based sessions, can handle
hence do not need IP mobility support; it is then more mobility at the application layer and hence do not need IP
efficient to deactivate IP mobility support for such sessions. mobility support; it is then unnecessary to provide IP mobility
support for such sessions.
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.
particular traffic patterns that often do not benefit from
mobility support from the network. Thus, the associated
mobility support signaling (e.g., maintenance of the tunnel,
keep alive signaling, etc.) wastes network resources for no
application gain.
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 co-exist with
with solutions already in the field. solutions already deployed in the field.
PS8: Duplicate multicast traffic PS8: Duplicate multicast traffic
IP multicast distribution over architectures using IP mobility IP multicast distribution over architectures using IP mobility
solutions (e.g., [RFC6224]) may lead to convergence of solutions (e.g., [RFC6224]) may lead to convergence of
duplicated multicast subscriptions towards the downstream duplicated multicast subscriptions towards the downstream
tunnel entity (e.g. MAG in PMIPv6). Concretely, when tunnel entity (e.g. MAG in PMIPv6). Concretely, when
multicast subscription for individual mobile nodes is coupled multicast subscription for individual mobile nodes is coupled
with mobility tunnels (e.g. PMIPv6 tunnel), duplicate with mobility tunnels (e.g. PMIPv6 tunnel), duplicate
multicast subscription(s) is prone to be received through multicast subscription(s) is prone to be received through
skipping to change at page 14, line 10 skipping to change at page 13, line 4
as they are already used to protect against existing networks as they are already used to protect against existing networks
and existing mobility protocols defined in IETF. and existing mobility protocols defined in IETF.
This requirement prevents a DMM solution from introducing This requirement prevents a DMM solution from introducing
uncontrollable problems of potentially insecure mobility management uncontrollable problems of potentially insecure mobility management
protocols which make deployment infeasible because platforms protocols which make deployment infeasible because platforms
conforming to the protocols are at risk for data loss and numerous conforming to the protocols are at risk for data loss and numerous
other dangers, including financial harm to the users. other dangers, including financial harm to the users.
5.7. Multicast 5.7. Multicast
REQ7: Multicast considerations REQ7: Multicast considerations
DMM SHOULD consider multicast early so that solutions can be DMM SHOULD enable multicast solutions to be developed to avoid
developed not only to provide IP mobility support when it is network inefficiency in multicast traffic delivery.
needed, but also to avoid network inefficiency issues in
multicast traffic delivery (such as duplicate multicast
subscriptions towards the downstream tunnel entities). The
multicast solutions should therefore avoid restricting the
management of all IP multicast traffic to a single host
through a dedicated (tunnel) interface on multicast-capable
access routers.
Motivation: Existing multicast deployment have been introduced Motivation: Existing multicast deployment have been introduced
after completing the design of the reference mobility after completing the design of the reference mobility
protocol, then optimization and extensions have been followed protocol, often leading to network inefficiency and non-
by "patching-up" procedure, thus leading to network optimal routing for the multicast traffic. Instead DMM should
inefficiency and non-optimal routing. The multicast solutions consider multicast early so that the multicast solutions can
should therefore be required to consider efficiency nature in better consider efficiency nature in the multicast traffic
multicast traffic delivery. delivery (such as duplicate multicast subscriptions towards
the downstream tunnel entities). The multicast solutions
should then avoid restricting the management of all IP
multicast traffic to a single host through a dedicated
(tunnel) interface on multicast-capable access routers.
This requirement addresses the problems PS1 and PS8 described in This requirement addresses the problems PS1 and PS8 described in
Section 4. Section 4.
6. Security Considerations 6. Security Considerations
Please refer to the discussion under Security requirement in Section Please refer to the discussion under Security requirement in Section
5.6. 5.6.
7. IANA Considerations 7. IANA Considerations
skipping to change at page 18, line 4 skipping to change at page 16, line 37
H Anthony Chan (editor) H Anthony Chan (editor)
Huawei Technologies (more co-authors on P. 17) Huawei Technologies (more co-authors on P. 17)
5340 Legacy Dr. Building 3, Plano, TX 75024, USA 5340 Legacy Dr. Building 3, Plano, TX 75024, USA
Email: h.a.chan@ieee.org Email: h.a.chan@ieee.org
Dapeng Liu Dapeng Liu
China Mobile China Mobile
Unit2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China Unit2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China
Email: liudapeng@chinamobile.com Email: liudapeng@chinamobile.com
Pierrick Seite Pierrick Seite
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
Renesas Mobile Broadcom Communications
Porkkalankatu 24, FIN-00180 Helsinki, Finland Porkkalankatu 24, FIN-00180 Helsinki, Finland
Email: jouni.korhonen@nsn.com Email: jouni.nospam@gmail.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
 End of changes. 28 change blocks. 
124 lines changed or deleted 95 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/