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/