draft-ietf-dmm-requirements-08.txt   draft-ietf-dmm-requirements-09.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: March 30, 2014 D. Liu Expires: April 1, 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 Renesas Mobile
September 26, 2013 September 28, 2013
Requirements for Distributed Mobility Management Requirements for Distributed Mobility Management
draft-ietf-dmm-requirements-08 draft-ietf-dmm-requirements-09
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 such as in moving the content delivery servers closer to the users, a
distributed model for mobility management can be useful to them. distributed model for mobility management can be useful to them.
skipping to change at page 2, line 4 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 April 1, 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 19 skipping to change at page 3, line 19
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3. Centralized versus distributed mobility management . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . . . . . . 15
8. Co-authors and Contributors . . . . . . . . . . . . . . . . . 15 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].
skipping to change at page 4, line 30 skipping to change at page 4, line 30
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 such traffic imposes new requirements on mobile core networks
for data traffic delivery. The presence of content providers for data traffic delivery. The presence of content providers
closer to Internet Service Providers (ISP) network requires closer to Internet Service Providers (ISP) network requires
taking into account local Content Delivery Networks (CDNs) while taking into account local Content Delivery Networks (CDNs) while
providing mobility services. Moreover, when the traffic demand providing mobility services. Moreover, when the traffic demand
exceeds available capacity, service providers need to implement exceeds available capacity, service providers need to implement
new strategies such as selective 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]. A gateway selection mechanism also
takes the user proximity into account within EPC [TS.29303]. takes the user proximity into account within EPC [TS.29303].
These mechanisms were not pursued in the past owing to charging These mechanisms were not pursued in the past owing to charging
and billing reasons. Assigning a gateway anchor node from a and billing reasons. Assigning a gateway anchor node from a
visited network in roaming scenario has until recently been done visited network in roaming scenario has until recently been done
and are limited to voice services only. Charging and billing and are limited to voice services only. Charging and billing
require solutions beyond the mobility protocol. require solutions beyond the mobility protocol.
skipping to change at page 5, line 18 skipping to change at page 5, line 18
periods of time [Paper-Locating.User]. Specific IP mobility periods of time [Paper-Locating.User]. Specific IP mobility
management support is not required for applications that launch management support is not required for applications that launch
and complete their sessions while the mobile node is connected and complete their sessions while the mobile node is connected
to the same point of attachment. However, currently, IP to the same point of attachment. However, currently, IP
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, thus reducing the amount of context provided selectively such as in [I-D.bhandari-dhc-class-based-
maintained in the network. prefix] and [I-D.korhonen-6man-prefix-properties], thus reducing
the amount of context maintained in the network.
In addition, considerations in the study of DMM are in the following. In addition, considerations in the study of DMM are in the following.
(1) To optimize handovers from the perspective of mobile nodes, the (1) To optimize handovers from the perspective of mobile nodes, the
base protocols have been extended to efficiently handle packet base protocols have been extended to efficiently handle packet
forwarding between the previous and new points of attachment. forwarding between the previous and new points of attachment.
These extensions are necessary when applications have stringent These extensions are necessary when applications have stringent
requirements in terms of delay. Notions of localization and requirements in terms of delay. Notions of localization and
distribution of local agents have been introduced to reduce distribution of local agents have been introduced to reduce
signaling overhead at the centralized routing anchor point signaling overhead at the centralized routing anchor point
skipping to change at page 9, line 34 skipping to change at page 9, line 34
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 local 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
the other hand, localized routing with PMIPv6 [RFC6705]
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
not applicable when the CN is outside the PMIP domain or does
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 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 48 skipping to change at page 11, line 8
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
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 duplicated solutions (e.g., [RFC6224]) may lead to convergence of
multicast subscriptions towards the downstream tunnel entity duplicated multicast subscriptions towards the downstream
(e.g. MAG in PMIPv6). Concretely, when multicast subscription tunnel entity (e.g. MAG in PMIPv6). Concretely, when
for individual mobile nodes is coupled with mobility tunnels multicast subscription for individual mobile nodes is coupled
(e.g. PMIPv6 tunnel), duplicate multicast subscription(s) is with mobility tunnels (e.g. PMIPv6 tunnel), duplicate
prone to be received through different upstream paths. This multicast subscription(s) is prone to be received through
problem may also exist or be more severe in a distributed different upstream paths. This problem may also exist or be
mobility environment. more severe in a distributed mobility environment.
5. Requirements 5. Requirements
After comparing distributed mobility management against centralized After comparing distributed mobility management against centralized
deployment in Section 3, this section identifies the following deployment in Section 3, this section identifies the following
requirements: requirements:
5.1. Distributed processing 5.1. Distributed processing
REQ1: Distributed processing REQ1: Distributed processing
skipping to change at page 11, line 35 skipping to change at page 11, line 43
network evolution: (a) it is cost- and resource-effective to network evolution: (a) it is cost- and resource-effective to
cache and distribute content by combining distributed mobility cache and distribute content by combining distributed mobility
anchors with caching systems (e.g., CDN); (b) the anchors with caching systems (e.g., CDN); (b) the
significantly larger number of mobile nodes and flows call for significantly larger number of mobile nodes and flows call for
improved scalability; (c) single points of failure are avoided improved scalability; (c) single points of failure are avoided
in a distributed system; (d) threats against centrally in a distributed system; (d) threats against centrally
deployed anchors, e.g., home agent and local mobility anchor, deployed anchors, e.g., home agent and local mobility anchor,
are mitigated in a distributed system. are mitigated in a distributed system.
This requirement addresses the problems PS1, PS2, PS3, and PS4 This requirement addresses the problems PS1, PS2, PS3, and PS4
described in Section 4. (Existing route optimization is only a host- described in Section 4.
based solution. On the other hand, localized routing with PMIPv6
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 not
applicable when the CN is outside the PMIP domain.)
5.2. Transparency to Upper Layers when needed 5.2. Transparency to Upper Layers when needed
REQ2: Transparency to Upper Layers when needed REQ2: Transparency to Upper Layers when needed
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
skipping to change at page 15, line 20 skipping to change at page 15, line 24
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.bhandari-dhc-class-based-prefix]
Bhandari, S., Halwasia, G., Gundavelli, S., Deng, H.,
Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class
based prefix", draft-bhandari-dhc-class-based-prefix-05
(work in progress), July 2013.
[I-D.korhonen-6man-prefix-properties]
Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D.
Liu, "IPv6 Prefix Properties",
draft-korhonen-6man-prefix-properties-02 (work in
progress), July 2013.
[I-D.wakikawa-netext-pmip-cp-up-separation] [I-D.wakikawa-netext-pmip-cp-up-separation]
Wakikawa, R., Pazhyannur, R., and S. Gundavelli, Wakikawa, R., Pazhyannur, R., and S. Gundavelli,
"Separation of Control and User Plane for Proxy Mobile "Separation of Control and User Plane for Proxy Mobile
IPv6", draft-wakikawa-netext-pmip-cp-up-separation-00 IPv6", draft-wakikawa-netext-pmip-cp-up-separation-00
(work in progress), July 2013. (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),
skipping to change at page 16, line 50 skipping to change at page 17, line 19
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L.
Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
Management", RFC 5380, October 2008. Management", RFC 5380, October 2008.
[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.
[RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
Deployment for Multicast Listener Support in Proxy Mobile
IPv6 (PMIPv6) Domains", RFC 6224, April 2011.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011. in IPv6", RFC 6275, July 2011.
[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.
[RFC6705] Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A.
Dutta, "Localized Routing for Proxy Mobile IPv6",
RFC 6705, September 2012.
[RFC6909] Gundavelli, S., Zhou, X., Korhonen, J., Feige, G., and R. [RFC6909] Gundavelli, S., Zhou, X., Korhonen, J., Feige, G., and R.
Koodli, "IPv4 Traffic Offload Selector Option for Proxy Koodli, "IPv4 Traffic Offload Selector Option for Proxy
Mobile IPv6", RFC 6909, April 2013. 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]
skipping to change at page 17, line 30 skipping to change at page 18, line 14
Authors' Addresses Authors' Addresses
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 Renesas Mobile
Porkkalankatu 24, FIN-00180 Helsinki, Finland
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
- -
 End of changes. 18 change blocks. 
25 lines changed or deleted 49 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/