draft-ietf-dmm-requirements-15.txt		draft-ietf-dmm-requirements-16.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: September 4, 2014 China Mobile		Expires: October 20, 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
	March 3, 2014		April 18, 2014
	Requirements for Distributed Mobility Management		Requirements for Distributed Mobility Management
	draft-ietf-dmm-requirements-15		draft-ietf-dmm-requirements-16
	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 centrally deployed		traditional wireless networks has led primarily to centrally deployed
	mobility anchors. As some wireless networks are evolving away from		mobility anchors. As some wireless networks are evolving away from
	the hierarchical structure, it can be useful have a distributed model		the hierarchical structure, it can be useful to have a distributed
	for mobility management in which traffic does not need to traverse		model for mobility management in which traffic does not need to
	centrally deployed mobility anchors far from the optimal route. The		traverse centrally deployed mobility anchors far from the optimal
	motivation and the problems addressed by each requirement are also		route. The motivation and the problems addressed by each requirement
	described.		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 [RFC2119].
	[RFC2119].
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 October 20, 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
	skipping to change at page 3, line 10		skipping to change at page 3, line 10
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Conventions used in this document . . . . . . . . . . . . . . 5		2. Conventions used in this document . . . . . . . . . . . . . . 5
	2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Centralized versus distributed mobility management . . . . . . 6		3. Centralized versus distributed mobility management . . . . . . 7
	3.1. Centralized mobility management . . . . . . . . . . . . . 7		3.1. Centralized mobility management . . . . . . . . . . . . . 7
	3.2. Distributed mobility management . . . . . . . . . . . . . 8		3.2. Distributed mobility management . . . . . . . . . . . . . 8
	4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9		4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9
	5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11		5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 14		6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 17		9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
	9.2. Informative References . . . . . . . . . . . . . . . . . . 17		9.2. Informative References . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
	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 these 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
	mobile node. It is a centrally deployed mobility anchor in the sense		mobile node. It is a centrally deployed mobility anchor in the sense
	that the deployed architectures today have a small number of these		that the deployed architectures today have a small number of these
	anchors and the traffic of millions of mobile nodes in an operator		anchors and the traffic of millions of mobile nodes in an operator
	network are typically managed by the same anchor.		network are typically managed by the same anchor. Such a mobility
			anchor may still have to reside in the subscriber's provider network
			even when the subscriber is roaming to a visited network, in order
			that certain functions such as charging and billing can be performed
			more readily by the provider's network. An example provider network
			is a Third Generation Partnership Project (3GPP) network.
	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). 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], Third Generation Partnership Project (3GPP) work		[RFC6909], 3GPP work items Local IP Access (LIPA) and Selected
	items Local IP Access (LIPA) and Selected IP Traffic Offload		IP Traffic Offload (SIPTO) [TS.23.401]) through alternative
	(SIPTO) [TS.23.401]) through alternative access networks such as		access networks such as Wireless Local Area Network (WLAN)
	Wireless Local Area Network (WLAN) [Paper-		[Paper-Mobile.Data.Offloading]. In addition, a gateway
	Mobile.Data.Offloading]. In addition, a gateway selection		selection mechanism takes the user proximity into account within
	mechanism takes the user proximity into account within the EPC		the Evolved Packet Core (EPC) [TS.29303]. Yet these mechanisms
	Evolved Packet Core (EPC) [TS.29303]. Yet these mechanisms were		were not pursued in the past owing to charging and billing
	not pursued in the past owing to charging and billing which		considerations which require solutions beyond the mobility
	require solutions beyond the mobility protocol. Consequently,		protocol. Consequently, assigning a gateway anchor node from a
	assigning a gateway anchor node from a visited network in		visited network when roaming to the visited network has only
	roaming scenario has until recently been done and are limited to		recently been done and is limited to voice services.
	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 hierarchical
	routing hierarchy introduced into the data path by the mobility		levels introduced into the data path by the mobility management
	management system. This trend towards so-called "flat networks"		system. This trend of "flattening" the mobile networks works
	works best for direct communications among peers in the same		best for direct communications among peers in the same
	geographical area. Distributed mobility management in a truly		geographical area. Distributed mobility management in the
	flat mobile architecture would anchor the traffic closer to the		flattening mobile networks would anchor the traffic closer to
	point of attachment of the user.		the point of attachment of the user.
	(2) Today's mobile networks present service providers with new		(2) Today's mobile networks present service providers with new
	challenges. Mobility patterns indicate that mobile nodes often		challenges. Mobility patterns indicate that mobile nodes often
	remain attached to the same point of attachment for considerable		remain attached to the same point of attachment for considerable
	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 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.
	DMM may distribute the mobility anchors in the data-plane towards a		DMM may distribute the mobility anchors in the data-plane in
	more flat network such that the mobility anchors are positioned		flattening the mobility network such that the mobility anchors are
	closer to the user; ideally, mobility agents could be collocated with		positioned closer to the user; ideally, mobility agents could be
	the first-hop router. Facilitated by the distribution of mobility		collocated with the first-hop router. Facilitated by the
	anchors, it may be possible to selectively use or not use mobility		distribution of mobility anchors, it may be possible to selectively
	protocol support depending on whether such support is needed or not.		use or not use mobility protocol support depending on whether such
	It can thus reduce the amount of state information that must be		support is needed or not. It can thus reduce the amount of state
	maintained in various mobility agents of the mobile network. It can		information that must be maintained in various mobility agents of the
	then avoid the unnecessary establishment of mechanisms to forward		mobile network. It can then avoid the unnecessary establishment of
	traffic from an old to a new mobility anchor.		mechanisms to forward traffic from an old to a new mobility anchor.
	This document compares distributed mobility management with		This document compares distributed mobility management with
	centralized mobility management in Section 3. The problems that can		centralized mobility management in Section 3. The problems that can
	be addressed with DMM are summarized in Section 4. The mandatory		be addressed with DMM are summarized in Section 4. The mandatory
	requirements as well as the optional requirements for network-layer		requirements as well as the optional requirements for network-layer
	distributed mobility management are given in Section 5. Finally,		distributed mobility management are given in Section 5. Finally,
	security considerations are discussed in Section 6.		security considerations are discussed in Section 6.
	The problem statement and the use cases [I-D.yokota-dmm-scenario] can		The problem statement and the use cases [I-D.yokota-dmm-scenario] can
	be found in [Paper-Distributed.Mobility.Review].		be found in [Paper-Distributed.Mobility.Review].
	skipping to change at page 6, line 25		skipping to change at page 6, line 28
	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 far from the optimal route.		centrally deployed mobility anchors far from the optimal route.
	Flat mobile network		Hierarchical mobile network
	has few levels of routing hierarchy introduced into the data path		has a hierarchy of network elements arranged into multiple
	by the mobility management system.		hierarchical levels which are introduced into the data path by the
			mobility management system.
			Flattening mobile network
			refers to the hierarchical mobile network which is going through
			the trend of reducing its number of hierarchical levels.
			Flatter mobile network
			has fewer hierarchical levels compared to a hierarchical mobile
			network.
	Mobility context		Mobility context
	is the collection of information required to provide mobility		is the collection of information required to provide mobility
	management support for a given mobile node.		management support for a given mobile node.
	3. Centralized versus distributed mobility management		3. Centralized versus distributed mobility management
	Mobility management is needed because the IP address of a mobile node		Mobility management is needed because the IP address of a mobile node
	may change as the node moves. Mobility management functions may be		may change as the node moves. Mobility management functions may be
	implemented at different layers of the protocol stack. At the IP		implemented at different layers of the protocol stack. At the IP
	(network) layer, mobility management can be client-based or network-		(network) layer, mobility management can be client-based or network-
	based.		based.
	An IP-layer mobility management protocol is typically based on the		An IP-layer mobility management protocol is typically based on the
	principle of distinguishing between a session identifier and a		principle of distinguishing between a session identifier and a
	routing address and maintaining a mapping between the two. In Mobile		forwarding address and maintaining a mapping between the two. In
	IP, the new IP address of the mobile node after the node has moved is		Mobile IP, the new IP address of the mobile node after the node has
	the routing address, whereas the original IP address before the		moved is the forwarding address, whereas the original IP address
	mobile node moves serves as the session identifier. The location		before the mobile node moves serves as the session identifier. The
	management (LM) information is kept by associating the routing		location management (LM) information is kept by associating the
	address with the session identifier. Packets addressed to the		forwarding address with the session identifier. Packets addressed to
	session identifier will first route to the original network which re-		the session identifier will first route to the original network which
	directs them using the routing address to deliver to the session.		re-directs them using the forwarding address to deliver to the
	Re-directing packets this way can result in long routes. An existing		session. Re-directing packets this way can result in long routes.
	optimization routes directly using the routing address of the host,		An existing optimization routes directly using the forwarding address
	and such is a host-based solution.		of the host, and such is a host-based solution.
	The next two subsections explain centralized and distributed mobility		The next two subsections explain centralized and distributed mobility
	management functions in the network.		management functions in the network.
	3.1. Centralized mobility management		3.1. Centralized mobility management
	In centralized mobility management, the location information in terms		In centralized mobility management, the location information in terms
	of a mapping between the session identifier and the routing address		of a mapping between the session identifier and the forwarding
	is kept at a single mobility anchor, and packets destined to the		address is kept at a single mobility anchor, and packets destined to
	session identifier are routed via this anchor. In other words, such		the session identifier are forwarded via this anchor. In other
	mobility management systems are centralized in both the control plane		words, such mobility management systems are centralized in both the
	and the data plane (mobile node IP traffic).		control plane 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
	3GPP General Packet Radio System (GPRS) networks and 3GPP Evolved		3GPP General Packet Radio System (GPRS) networks and 3GPP Evolved
	Packet System (EPS) networks employ centralized mobility management		Packet System (EPS) networks employ centralized mobility management
	too. In the 3GPP GPRS network, the Gateway GPRS Support Node (GGSN),		too. In the 3GPP GPRS network, the Gateway GPRS Support Node (GGSN),
	skipping to change at page 8, line 30		skipping to change at page 8, line 30
	/ \ / \		/ \ / \
	/ \ / \		/ \ / \
	+---+ +---+ +---+ +---+		+---+ +---+ +---+ +---+
	|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 in the data
	networks as shown in Figure 2, so that a mobile node in any of these		plane to multiple networks as shown in Figure 2, so that a mobile
	networks may be served by a nearby function with appropriate		node in any of these networks may be served by a nearby function with
	mobility/routing management (RM) capability.		appropriate forwarding management (FM) capability.
	+------+ +------+ +------+ +------+		+------+ +------+ +------+ +------+
	| RM | | RM | | RM | | RM |		| FM | | FM | | FM | | FM |
	+------+ +------+ +------+ +------+		+------+ +------+ +------+ +------+
	|		|
	+----+		+----+
	| MN |		| MN |
	+----+		+----+
	Figure 2. Distributed mobility management.		Figure 2. Distributed mobility management.
	Mobility management may be partially or fully distributed		DMM is distributed in the data plane, whereas the control plane may
	[I-D.yokota-dmm-scenario]. In the former case only the data plane is		either be centralized or distributed [I-D.yokota-dmm-scenario]. The
	distributed, implicitly assuming separation of data and control		former case implicitly assumes separation of data and control planes
	planes as described in [I-D.wakikawa-netext-pmip-cp-up-separation].		as described in [I-D.wakikawa-netext-pmip-cp-up-separation]. While
	Fully distributed mobility management implies that both the data		mobility management can be distributed, it is not necessary for other
	plane and the control plane are distributed. While mobility
	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 flattening mobile
	access nodes is proposed in [Paper-Distributed.Dynamic.Mobility].		network consisting of access nodes is proposed in [Paper-
	Its benefits over centralized mobility management have been shown		Distributed.Dynamic.Mobility]. Its benefits over centralized
	through simulations [Paper-Distributed.Centralized.Mobility].		mobility management have been shown through simulations [Paper-
	Moreover, the (re)use and extension of existing protocols in the		Distributed.Centralized.Mobility]. Moreover, the (re)use and
	design of both fully distributed mobility management [Paper-		extension of existing protocols in the design of both fully
	Migrating.Home.Agents] [Paper-Distributed.Mobility.SAE] and partially		distributed mobility management [Paper-Migrating.Home.Agents] [Paper-
	distributed mobility management [Paper-Distributed.Mobility.PMIP]		Distributed.Mobility.SAE] and partially distributed mobility
	[Paper-Distributed.Mobility.MIP] have been reported in the		management [Paper-Distributed.Mobility.PMIP] [Paper-
	literature. Therefore, before designing new mobility management		Distributed.Mobility.MIP] have been reported in the literature.
	protocols for a future distributed architecture, it is recommended to		Therefore, before designing new mobility management protocols for a
	first consider whether existing mobility management protocols can be		future distributed architecture, it is recommended to first consider
	extended.		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		Forwarding via a centralized anchor often results in non-
	routes, thereby increasing the end-to-end delay. The problem		optimal routes, thereby increasing the end-to-end delay. The
	is manifested, for example, when accessing a nearby server or		problem is manifested, for example, when accessing a nearby
	servers of a Content Delivery Network (CDN), or when receiving		server or servers of a Content Delivery Network (CDN), or when
	locally available IP multicast or sending IP multicast packets.		receiving locally available IP multicast or sending IP
	(Existing route optimization is only a host-based solution. On		multicast packets. (Existing route optimization is only a
	the other hand, localized routing with PMIPv6 [RFC6705]		host-based solution. On the other hand, localized routing with
	addresses only a part of the problem where both the MN and the		PMIPv6 [RFC6705] addresses only a part of the problem where
	correspondent node (CN) are attached to the same MAG, and it is		both the MN and the correspondent node (CN) are attached to the
	not applicable when the CN does not behave like an MN.)		same MAG, and it is not applicable when the CN 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.
	Mobile networks have generally been evolving towards a flat		Mobile networks have generally been evolving towards a flatter
	network. Centralized mobility management, which is non-optimal		and flatter network. Centralized mobility management, which is
	with a flat network architecture, does not support this		non-optimal with a flatter network architecture, does not
	evolution.		support this evolution.
	PS3: Lack of scalability of centralized tunnel management and		PS3: Lack of scalability of centralized tunnel management and
	mobility context maintenance		mobility 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 avoid increasing the		with proper signaling protocol design can avoid increasing the
	concentrated resources with an increasing number of MNs.		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
	skipping to change at page 11, line 17		skipping to change at page 11, line 15
	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 mobility management		REQ1: Distributed mobility management
	IP mobility, network access and routing solutions provided by		IP mobility, network access and forwarding solutions provided
	DMM MUST enable traffic to avoid traversing single mobility		by DMM MUST enable traffic to avoid traversing single mobility
	anchor far from the optimal route.		anchor far from the optimal route.
			This requirement on distribution is in the data plane only.
			It does not impose constraints on whether the control plane
			should be distributed or centralized. However, if the control
			plane is centralized while the data plane is distributed, it
			is implicit that the control plane and data plane need to
			separate (Section 3.2).
	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
	distributed system.		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.		described in Section 4.
	REQ2: Bypassable network-layer mobility support		REQ2: Bypassable network-layer mobility support for each application
			session
	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 for any individual active application session
			(flow) 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 when a mobile router changes its IP address as it		also needed when a mobile router changes its IP address as it
	moves together with a host and, in the presence of ingress		moves together with a host and, in the presence of ingress
	filtering, an application in the host is interrupted. However		filtering, an application in the host is interrupted. However
	mobility support at the network-layer is not always needed; a		mobility support at the network-layer is not always needed; a
	mobile node can often be stationary, and mobility support can		mobile node can often be stationary, and mobility support can
	also be provided at other layers. It is then not always		also be provided at other layers. It is then not always
	necessary to maintain a stable IP address or prefix.		necessary to maintain a stable IP address or prefix for an
			active application session.
			Different active sessions can also differ in whether network-
			layer mobility support is needed. IP mobility, network access
			and forwarding solutions provided by DMM MUST then enable the
			possibility of independent handling for each application
			session of a user or mobile device.
			The handling of mobility management to the granularity of an
			individual session of a user/device SHOULD need proper session
			identification in addition to user/device identification.
	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 forwarding 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
	Section 4.		in Section 4.
	REQ3: IPv6 deployment		REQ3: IPv6 deployment
	DMM solutions SHOULD target IPv6 as the primary deployment		DMM solutions SHOULD target IPv6 as the primary deployment
	environment and SHOULD NOT be tailored specifically to support		environment and SHOULD NOT be tailored specifically to support
	IPv4, in particular in situations where private IPv4 addresses		IPv4, in particular in situations where private IPv4 addresses
	and/or NATs are used.		and/or NATs are used.
	Motivation: This requirement conforms to the general		Motivation: This requirement conforms to the general
	orientation of IETF work. DMM deployment is foreseen in mid-		orientation of IETF work. DMM deployment is foreseen in mid-
	to long-term horizon, when IPv6 is expected to be far more		to long-term horizon, when IPv6 is expected to be far more
	common than today.		common than today.
	This requirement avoids the unnecessarily complexity in solving the		This requirement avoids the unnecessarily complexity in
	problems in Section 4 for IPv4, which will not be able to use some of		solving the problems in Section 4 for IPv4, which will not be
	the IPv6-specific features.		able to use some of the IPv6-specific features.
	REQ4: Existing mobility protocols		REQ4: Existing mobility protocols
	A DMM solution MUST first consider reusing and extending IETF-		A DMM solution MUST first consider reusing and extending IETF-
	standardized protocols before specifying new protocols.		standardized protocols before specifying new protocols.
	Motivation: Reuse of existing IETF work is more efficient and		Motivation: Reuse of existing IETF work is more efficient and
	less error-prone.		less error-prone.
	This requirement attempts to avoid the need of new protocols		This requirement attempts to avoid the need of new protocols
	development and therefore their potential problems of being time-		development and therefore their potential problems of being
	consuming and error-prone.		time-consuming and error-prone.
	REQ5: Coexistence with deployed networks and hosts		REQ5: Coexistence with deployed networks/hosts and operability
			across different networks
	The DMM solution may require loose, tight or no integration		A DMM solution may require loose, tight or no integration into
	into existing mobility protocols and host IP stack.		existing mobility protocols and host IP stack. Regardless of
	Regardless of the integration level, the DMM solution MUST be		the integration level, such a DMM solution MUST be able to
	able to coexist with existing network deployments, end hosts		coexist with existing network deployments, end hosts and
	and routers that may or may not implement existing mobility		routers that may or may not implement existing mobility
	protocols. Furthermore, a DMM solution SHOULD work across		protocols. Furthermore, a DMM solution SHOULD work across
	different networks, possibly operated as separate		different networks, possibly operated as separate
	administrative domains, when allowed by the trust relationship		administrative domains, when the needed mobility management
	between them.		signaling, forwarding, and network access are allowed by the
			trust relationship between them.
	Motivation: (a) to preserve backwards compatibility so that		Motivation: (a) to preserve backwards compatibility so that
	existing networks and hosts are not affected and continue to		existing networks and hosts are not affected and continue to
	function as usual, and (b) enable inter-domain operation if		function as usual, and (b) enable inter-domain operation if
	desired.		desired.
	This requirement addresses the problem PS7 described in Section 4.		This requirement addresses the problem PS7 described in
			Section 4.
	REQ6: Security considerations		REQ6: Security considerations
	A DMM solution MUST NOT introduce new security risks, or		A DMM solution MUST support any security protocols and
	amplify existing security risks, that cannot be mitigated by		mechanisms needed to secure the network and to make continuous
	existing security mechanisms or protocols.		security improvements. In addition, with security taken into
			consideration early in the design, a DMM solution MUST NOT
			introduce new security risks, or amplify existing security
			risks, that cannot be mitigated by existing security protocols
			and mechanisms.
	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 or nodes to which the traffic		Consequently, the specific node or nodes to which the traffic
	is redirected may be under a denial of service attack, whereas		is redirected may be under a denial of service attack, whereas
	other nodes do not receive their traffic. Accordingly,		other nodes do not receive their traffic. Accordingly,
	security mechanisms/protocols providing access control,		security mechanisms/protocols providing access control,
	integrity, authentication, authorization, confidentiality,		integrity, authentication, authorization, confidentiality,
	etc. should be used to protect the DMM entities as they are		etc. should be used to protect the DMM entities as they are
	already used to protect against existing networks and existing		already used to protect against existing networks and existing
	mobility protocols defined in IETF. Yet if a candidate DMM		mobility protocols defined in IETF. Yet if a candidate DMM
	solution is such that even the proper use of these existing		solution is such that even the proper use of these existing
	security mechanisms/protocols are unable to provide sufficient		security mechanisms/protocols are unable to provide sufficient
	security protection, that candidate DMM solution is causing		security protection, that candidate DMM solution is causing
	uncontrollable security problems.		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
	protocols which make deployment infeasible because platforms		management protocols which make deployment infeasible because
	conforming to the protocols are at risk for data loss and numerous		platforms conforming to the protocols are at risk for data
	other dangers, including financial harm to the users.		loss and numerous 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
	network inefficiency in multicast traffic delivery.		network inefficiency in multicast traffic delivery.
	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, often leading to network inefficiency and non-		protocol, often leading to network inefficiency and non-
	optimal routing for the multicast traffic. Instead DMM should		optimal forwarding for the multicast traffic. Instead DMM
	consider multicast early so that the multicast solutions can		should consider multicast early so that the multicast
	better consider efficiency nature in the multicast traffic		solutions can better consider efficiency nature in the
	delivery (such as duplicate multicast subscriptions towards		multicast traffic delivery (such as duplicate multicast
	the downstream tunnel entities). The multicast solutions		subscriptions towards the downstream tunnel entities). The
	should then avoid restricting the management of all IP		multicast solutions should then avoid restricting the
	multicast traffic to a single host through a dedicated		management of all IP multicast traffic to a single host
	(tunnel) interface on multicast-capable access routers.		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
	Section 4.		in Section 4.
			REQ8: OAM considerations
			DMM SHOULD support operations, administration and management
			(OAM) solutions to reduce OAM complexity and operational
			expenditure.
			Motivation: A DMM solution that takes OAM into considerations
			from the beginning of its design can avoid difficulty or
			incompatibility to implement efficient OAM solutions.
			This requirement avoids DMM designs that make OAM difficult or
			costly.
	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.		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. Valuable comments and suggestions in
	the following has made very significant and important contributions		various reviews from the following area directors and IESG members
	to this work:		have also contributed to much improvements: Russ Housley, Catherine
			Meadows, Adrian Farrel, Barry Leiba, Alissa Cooper, Ted Lemon, Brian
			Haberman, Stephen Farrell, Joel Jaeggli, Alia Atlas, and Benoit
			Claise. In addition to the authors, each of the following has made
			very significant and important contributions to the working group
			draft in this work:
	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@googlemail.com		Email: telemaco.melia@googlemail.com
	Elena Demaria		Elena Demaria
	skipping to change at page 17, line 4		skipping to change at page 17, line 44
	Hassan Ali-Ahmad		Hassan Ali-Ahmad
	Orange		Orange
	Email: hassan.aliahmad@orange.com		Email: hassan.aliahmad@orange.com
	Alper Yegin		Alper Yegin
	Samsung		Samsung
	Email: alper.yegin@partner.samsung.com		Email: alper.yegin@partner.samsung.com
	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.
			[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
			RFC 3753, June 2004.
			[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
			and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
			[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
			in IPv6", RFC 6275, July 2011.
	9.2. Informative References		9.2. Informative References
	[I-D.bhandari-dhc-class-based-prefix]		[I-D.bhandari-dhc-class-based-prefix]
	Bhandari, S., Halwasia, G., Gundavelli, S., Deng, H.,		Bhandari, S., Halwasia, G., Gundavelli, S., Deng, H.,
	Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class		Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class
	based prefix", draft-bhandari-dhc-class-based-prefix-05		based prefix", draft-bhandari-dhc-class-based-prefix-05
	(work in progress), July 2013.		(work in progress), July 2013.
	[I-D.korhonen-6man-prefix-properties]		[I-D.korhonen-6man-prefix-properties]
	Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D.		Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D.
	Liu, "IPv6 Prefix Properties",		Liu, "IPv6 Prefix Properties",
	draft-korhonen-6man-prefix-properties-02 (work in		draft-korhonen-6man-prefix-properties-02 (work in
	progress), July 2013.		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), February 2014.
	[I-D.yokota-dmm-scenario]		[I-D.yokota-dmm-scenario]
	Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case		Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case
	scenarios for Distributed Mobility Management",		scenarios for Distributed Mobility Management",
	draft-yokota-dmm-scenario-00 (work in progress),		draft-yokota-dmm-scenario-00 (work in progress),
	October 2010.		October 2010.
	[Paper-Distributed.Centralized.Mobility]		[Paper-Distributed.Centralized.Mobility]
	Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed		Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed
	or Centralized Mobility", Proceedings of Global		or Centralized Mobility", Proceedings of Global
	skipping to change at page 18, line 38		skipping to change at page 19, line 41
	Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home		Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home
	Agents Towards Internet-scale Mobility Deployments",		Agents Towards Internet-scale Mobility Deployments",
	Proceedings of the ACM 2nd CoNEXT Conference on Future		Proceedings of the ACM 2nd CoNEXT Conference on Future
	Networking Technologies, December 2006.		Networking Technologies, December 2006.
	[Paper-Mobile.Data.Offloading]		[Paper-Mobile.Data.Offloading]
	Lee, K., Lee, J., Yi, Y., Rhee, I., and S. Chong, "Mobile		Lee, K., Lee, J., Yi, Y., Rhee, I., and S. Chong, "Mobile
	Data Offloading: How Much Can WiFi Deliver?", SIGCOMM		Data Offloading: How Much Can WiFi Deliver?", SIGCOMM
	2010, 2010.		2010, 2010.
	[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
	RFC 3753, June 2004.
	[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
	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		[RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
	Deployment for Multicast Listener Support in Proxy Mobile		Deployment for Multicast Listener Support in Proxy Mobile
	IPv6 (PMIPv6) Domains", RFC 6224, April 2011.		IPv6 (PMIPv6) Domains", RFC 6224, April 2011.
	[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
	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.		[RFC6705] Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A.
	Dutta, "Localized Routing for Proxy Mobile IPv6",		Dutta, "Localized Routing for Proxy Mobile IPv6",
	RFC 6705, September 2012.		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.
End of changes. 50 change blocks.
	165 lines changed or deleted		225 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/