draft-ietf-dmm-requirements-14.txt   draft-ietf-dmm-requirements-15.txt 
Network Working Group H. Chan (Ed.) Network Working Group H. Chan (Ed.)
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Informational D. Liu Intended status: Informational D. Liu
Expires: August 7, 2014 China Mobile Expires: September 4, 2014 China Mobile
P. Seite P. Seite
Orange Orange
H. Yokota H. Yokota
KDDI Lab KDDI Lab
J. Korhonen J. Korhonen
Broadcom Communications Broadcom Communications
February 3, 2014 March 3, 2014
Requirements for Distributed Mobility Management Requirements for Distributed Mobility Management
draft-ietf-dmm-requirements-14 draft-ietf-dmm-requirements-15
Abstract Abstract
This document defines the requirements for Distributed Mobility This document defines the requirements for Distributed Mobility
Management (DMM) at the network layer. The hierarchical structure in Management (DMM) at the network layer. The hierarchical structure in
traditional wireless networks has led primarily to centralized traditional wireless networks has led primarily to centrally deployed
deployment models. As some wireless networks are evolving away from mobility anchors. As some wireless networks are evolving away from
the hierarchical structure, a distributed model for mobility the hierarchical structure, it can be useful have a distributed model
management can be useful to them. for mobility management in which traffic does not need to traverse
centrally deployed mobility anchors far from the optimal route. The
motivation and the problems addressed by each requirement are also
described.
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 1, line 49 skipping to change at page 2, line 6
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 August 7, 2014. This Internet-Draft will expire on September 4, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Centralized versus distributed mobility management . . . . . . 5 3. Centralized versus distributed mobility management . . . . . . 6
3.1. Centralized mobility management . . . . . . . . . . . . . 6 3.1. Centralized mobility management . . . . . . . . . . . . . 7
3.2. Distributed mobility management . . . . . . . . . . . . . 7 3.2. Distributed mobility management . . . . . . . . . . . . . 8
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
In the past decade a fair number of network-layer mobility protocols In the past decade a fair number of network-layer mobility protocols
have been standardized [RFC6275] [RFC5944] [RFC5380] [RFC6301] have been standardized [RFC6275] [RFC5944] [RFC5380] [RFC6301]
[RFC5213]. Although the protocols differ in terms of functions and [RFC5213]. Although the protocols differ in terms of functions and
associated message formats, they all employ a mobility anchor to associated message formats, they all employ a mobility anchor to
allow a mobile node to remain reachable after it has moved to a allow a mobile node to remain reachable after it has moved to a
different network. The anchor point, among other tasks, ensures different network. The anchor point, among other tasks, ensures
connectivity by forwarding packets destined to, or sent from, the connectivity by forwarding packets destined to, or sent from, the
skipping to change at page 3, line 29 skipping to change at page 4, line 29
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
including that of local Content Delivery Networks (CDNs) which including that of local Content Delivery Networks (CDNs) which
had not taken mobility service into account before. Such had not taken mobility service into account before. Such
traffic imposes new requirements on mobile core networks for traffic imposes new requirements on mobile core networks for
data traffic delivery. To prevent exceeding the available core data traffic delivery. To prevent exceeding the available core
network capacity, service providers need to implement new network capacity, service providers need to implement new
strategies such as selective IPv4 traffic offload (e.g. strategies such as selective IPv4 traffic offload (e.g.,
[RFC6909], 3GPP work items Local IP Access (LIPA) and Selected [RFC6909], Third Generation Partnership Project (3GPP) work
IP Traffic Offload (SIPTO) [TS.23.401]) through alternative items Local IP Access (LIPA) and Selected IP Traffic Offload
access networks (e.g. WLAN) [Paper-Mobile.Data.Offloading]. In (SIPTO) [TS.23.401]) through alternative access networks such as
addition, a gateway selection mechanism takes the user proximity Wireless Local Area Network (WLAN) [Paper-
into account within EPC [TS.29303]. Yet these mechanisms were Mobile.Data.Offloading]. In addition, a gateway selection
mechanism takes the user proximity into account within the EPC
Evolved Packet Core (EPC) [TS.29303]. Yet these mechanisms were
not pursued in the past owing to charging and billing which not pursued in the past owing to charging and billing which
require solutions beyond the mobility protocol. Consequently, require solutions beyond the mobility protocol. Consequently,
assigning a gateway anchor node from a visited network in assigning a gateway anchor node from a visited network in
roaming scenario has until recently been done and are limited to roaming scenario has until recently been done and are limited to
voice services only. 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"
skipping to change at page 6, line 28 skipping to change at page 7, line 28
session identifier are routed via this anchor. In other words, such session identifier are routed via this anchor. In other words, such
mobility management systems are centralized in both the control plane mobility management systems are centralized in both the 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 are the home agent (HA) and local mobility in Figure 1. Examples are the home agent (HA) and local mobility
anchor (LMA) serving as the anchors for the mobile node (MN) and anchor (LMA) serving as the anchors for the mobile node (MN) and
Mobile Access Gateway (MAG) in Mobile IPv6 [RFC6275] and in Proxy Mobile Access Gateway (MAG) in Mobile IPv6 [RFC6275] and in Proxy
Mobile IPv6 [RFC5213] respectively. Cellular networks such as the Mobile IPv6 [RFC5213] respectively. Cellular networks such as the
Third Generation Partnership Project (3GPP) General Packet Radio 3GPP General Packet Radio System (GPRS) networks and 3GPP Evolved
System (GPRS) networks and 3GPP Evolved Packet System (EPS) networks Packet System (EPS) networks employ centralized mobility management
employ centralized mobility management too. In the 3GPP GPRS too. In the 3GPP GPRS network, the Gateway GPRS Support Node (GGSN),
network, the Gateway GPRS Support Node (GGSN), Serving GPRS Support Serving GPRS Support Node (SGSN) and Radio Network Controller (RNC)
Node (SGSN) and Radio Network Controller (RNC) constitute a hierarchy constitute a hierarchy of anchors. In the 3GPP EPS network, the
of anchors. In the 3GPP EPS network, the Packet Data Network Gateway Packet Data Network Gateway (P-GW) and Serving Gateway (S-GW)
(P-GW) and Serving Gateway (S-GW) constitute another hierarchy of constitute another hierarchy of anchors.
anchors.
3G GPRS 3GPP EPS MIP/PMIP 3GPP GPRS 3GPP EPS MIP/PMIP
+------+ +------+ +------+ +------+ +------+ +------+
| GGSN | | P-GW | |HA/LMA| | GGSN | | P-GW | |HA/LMA|
+------+ +------+ +------+ +------+ +------+ +------+
/\ /\ /\ /\ /\ /\
/ \ / \ / \ / \ / \ / \
/ \ / \ / \ / \ / \ / \
/ \ / \ / \ / \ / \ / \
/ \ / \ / \ / \ / \ / \
/ \ / \ / \ / \ / \ / \
/ \ / \ / \ / \ / \ / \
skipping to change at page 9, line 26 skipping to change at page 10, line 26
mobility management can be far greater as well. mobility management can be far greater as well.
PS5: Unnecessary mobility support to clients that do not need it PS5: Unnecessary mobility support to clients that do not need it
IP mobility support is usually provided to all MNs. Yet it is IP mobility support is usually provided to all MNs. Yet it is
not always required, and not every parameter of mobility not always required, and not every parameter of mobility
context is always used. For example, some applications or context is always used. For example, some applications or
nodes do not need a stable IP address during a handover to nodes do not need a stable IP address during a handover to
maintain session continuity. Sometimes, the entire application maintain session continuity. Sometimes, the entire application
session runs while the MN does not change the point of session runs while the MN does not change the point of
attachment. Besides, some sessions, e.g. SIP-based sessions, attachment. Besides, some sessions, e.g., SIP-based sessions,
can handle mobility at the application layer and hence do not can handle mobility at the application layer and hence do not
need IP mobility support; it is then unnecessary to provide IP need IP mobility support; it is then unnecessary to provide IP
mobility support for such sessions. mobility support for such sessions.
PS6: Mobility signaling overhead with peer-to-peer communication PS6: Mobility signaling overhead with peer-to-peer 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 communication.
skipping to change at page 9, line 50 skipping to change at page 10, line 50
mobility solutions at other layers. Deployment of new mobility mobility solutions at other layers. Deployment of new mobility
management solutions can be challenging, and debugging management solutions can be challenging, and debugging
difficult, when they co-exist with solutions already deployed difficult, when they co-exist with solutions already deployed
in the field. 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
different upstream paths. This problem may also exist or be different upstream paths. This problem may also exist or be
more severe in a distributed 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 and describing the problems in Section 4, deployment in Section 3 and describing the problems in Section 4,
this section identifies the following requirements: this section identifies the following requirements:
REQ1: Distributed processing REQ1: Distributed mobility management
IP mobility, network access and routing solutions provided by IP mobility, network access and routing solutions provided by
DMM MUST enable distributed processing for mobility management DMM MUST enable traffic to avoid traversing single mobility
so that traffic can avoid traversing single mobility anchor anchor far from the optimal route.
far from the optimal route.
Motivation: This requirement is motivated by current trends in Motivation: This requirement is motivated by current trends in
network evolution: (a) it is cost- and resource-effective to network evolution: (a) it is cost- and resource-effective to
cache contents, and the caching (e.g., CDN) servers are cache contents, and the caching (e.g., CDN) servers are
distributed so that each user in any location can be close to distributed so that each user in any location can be close to
one of the servers; (b) the significantly larger number of one of the servers; (b) the significantly larger number of
mobile nodes and flows call for improved scalability; (c) mobile nodes and flows call for improved scalability; (c)
single points of failure are avoided in a distributed system; single points of failure are avoided in a distributed system;
(d) threats against centrally deployed anchors, e.g., home (d) threats against centrally deployed anchors, e.g., home
agent and local mobility anchor, are mitigated in a agent and local mobility anchor, are mitigated in a
skipping to change at page 10, line 42 skipping to change at page 11, line 41
This requirement addresses the problems PS1, PS2, PS3, and PS4 This requirement addresses the problems PS1, PS2, PS3, and PS4
described in Section 4. described in Section 4.
REQ2: Bypassable network-layer mobility support REQ2: Bypassable network-layer mobility support
DMM solutions MUST enable network-layer mobility but it MUST DMM solutions MUST enable network-layer mobility but it MUST
be possible to not use it. Mobility support is needed, for be possible to not use it. Mobility support is needed, for
example, when a mobile host moves and an application cannot example, when a mobile host moves and an application cannot
cope with a change in the IP address. Mobility support is cope with a change in the IP address. Mobility support is
also needed, for example, when a mobile router moves together also needed when a mobile router changes its IP address as it
with a host and an application in the host is interrupted by a moves together with a host and, in the presence of ingress
change of IP address of the mobile router. However mobility filtering, an application in the host is interrupted. However
support at the network-layer is not always needed; a mobile mobility support at the network-layer is not always needed; a
node can often be stationary, and mobility support can also be mobile node can often be stationary, and mobility support can
provided at other layers. It is then not always necessary to also be provided at other layers. It is then not always
maintain a stable IP address or prefix. necessary to maintain a stable IP address or prefix.
Motivation: The motivation of this requirement is to enable Motivation: The motivation of this requirement is to enable
more efficient routing and more efficient use of network more efficient routing and more efficient use of network
resources by selecting an IP address or prefix according to resources by selecting an IP address or prefix according to
whether mobility support is needed and by not maintaining whether mobility support is needed and by not maintaining
context at the mobility anchor when there is no such need. context at the mobility anchor when there is no such need.
This requirement addresses the problems PS5 and PS6 described in This requirement addresses the problems PS5 and PS6 described in
Section 4. Section 4.
skipping to change at page 12, line 24 skipping to change at page 13, line 22
A DMM solution MUST NOT introduce new security risks, or A DMM solution MUST NOT introduce new security risks, or
amplify existing security risks, that cannot be mitigated by amplify existing security risks, that cannot be mitigated by
existing security mechanisms or protocols. existing security mechanisms or protocols.
Motivation: Various attacks such as impersonation, denial of Motivation: Various attacks such as impersonation, denial of
service, man-in-the-middle attacks, and so on, may be launched service, man-in-the-middle attacks, and so on, may be launched
in a DMM deployment. For instance, an illegitimate node may in a DMM deployment. For instance, an illegitimate node may
attempt to access a network providing DMM. Another example is attempt to access a network providing DMM. Another example is
that a malicious node can forge a number of signaling messages that a malicious node can forge a number of signaling messages
thus redirecting traffic from its legitimate path. thus redirecting traffic from its legitimate path.
Consequently, the specific node is under a denial of service Consequently, the specific node or nodes to which the traffic
attack, whereas other nodes do not receive their traffic. is redirected may be under a denial of service attack, whereas
Accordingly, security mechanisms/protocols providing access other nodes do not receive their traffic. Accordingly,
control, integrity, authentication, authorization, security mechanisms/protocols providing access control,
confidentiality, etc. can be used to protect the DMM entities integrity, authentication, authorization, confidentiality,
as they are already used to protect against existing networks etc. should be used to protect the DMM entities as they are
and existing mobility protocols defined in IETF. already used to protect against existing networks and existing
mobility protocols defined in IETF. Yet if a candidate DMM
solution is such that even the proper use of these existing
security mechanisms/protocols are unable to provide sufficient
security protection, that candidate DMM solution is causing
uncontrollable security problems.
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.
REQ7: Multicast considerations REQ7: Multicast considerations
DMM SHOULD enable multicast solutions to be developed to avoid DMM SHOULD enable multicast solutions to be developed to avoid
skipping to change at page 13, line 12 skipping to change at page 14, line 16
should then avoid restricting the management of all IP should then avoid restricting the management of all IP
multicast traffic to a single host through a dedicated multicast traffic to a single host through a dedicated
(tunnel) interface on multicast-capable access routers. (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.
7. IANA Considerations 7. IANA Considerations
None None
8. Contributors 8. Contributors
This requirements document is a joint effort among numerous This requirements document is a joint effort among numerous
participants working in a team. In addition to the authors, each of participants working in a team. In addition to the authors, each of
the following has made very significant and important contributions the following has made very significant and important contributions
skipping to change at page 14, line 26 skipping to change at page 15, line 30
Wen Luo Wen Luo
ZTE ZTE
No.68, Zijinhua RD,Yuhuatai District, Nanjing, Jiangsu 210012, China No.68, Zijinhua RD,Yuhuatai District, Nanjing, Jiangsu 210012, China
Email: luo.wen@zte.com.cn Email: luo.wen@zte.com.cn
Sri Gundavelli Sri Gundavelli
Cisco Cisco
sgundave@cisco.com sgundave@cisco.com
Hui Deng
China Mobile
Email: denghui@chinamobile.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
Seil Jeon Seil Jeon
Instituto de Telecomunicacoes, Aveiro Instituto de Telecomunicacoes, Aveiro
 End of changes. 18 change blocks. 
60 lines changed or deleted 72 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/