draft-ietf-dmm-requirements-04.txt		draft-ietf-dmm-requirements-05.txt
	Network Working Group H. Chan (Ed.)		Network Working Group H. Chan (Ed.)
	Internet-Draft Huawei Technologies (more		Internet-Draft Huawei Technologies (more
	Intended status: Informational co-authors on P. 17)		Intended status: Informational co-authors on P. 17)
	Expires: November 9, 2013 D. Liu		Expires: December 7, 2013 D. Liu
	China Mobile		China Mobile
	P. Seite		P. Seite
	France Telecom - Orange		Orange
	H. Yokota		H. Yokota
	KDDI Lab		KDDI Lab
	J. Korhonen		J. Korhonen
	Nokia Siemens Networks		Nokia Siemens Networks
	May 8, 2013		June 5, 2013
	Requirements for Distributed Mobility Management		Requirements for Distributed Mobility Management
	draft-ietf-dmm-requirements-04		draft-ietf-dmm-requirements-05
	Abstract		Abstract
	This document defines the requirements for Distributed Mobility		This document defines the requirements for Distributed Mobility
	Management (DMM) in IPv6 deployments. The hierarchical structure in		Management (DMM) in IPv6 deployments. The hierarchical structure in
	traditional wireless networks has led to deployment models which are		traditional wireless networks has led to deployment models which are
	in practice centralized. Mobility management with logically		in practice centralized. Mobility management with logically
	centralized mobility anchoring in current mobile networks is prone to		centralized mobility anchoring in current mobile networks is prone to
	suboptimal routing and raises scalability issues. Such centralized		suboptimal routing and raises scalability issues. Such centralized
	functions can lead to single points of failure and inevitably		functions can lead to single points of failure and inevitably
	skipping to change at page 1, line 41		skipping to change at page 1, line 41
	network evolution, i.e., improve scalability, avoid single points of		network evolution, i.e., improve scalability, avoid single points of
	failure, enable transparent mobility support to upper layers only		failure, enable transparent mobility support to upper layers only
	when needed, and so on. Distributed mobility management must be		when needed, and so on. Distributed mobility management must be
	secure and may co-exist with existing network deployments and end		secure and may co-exist with existing network deployments and end
	hosts.		hosts.
	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 [RFC2119].		document are to be interpreted as described in RFC 2119 RFC 2119
			[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 November 9, 2013.		This Internet-Draft will expire on December 7, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 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 . . . . . . . . . . . . . . 6		2. Conventions used in this document . . . . . . . . . . . . . . 6
	2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6		2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Centralized versus distributed mobility management . . . . . . 7		3. Centralized versus distributed mobility management . . . . . . 6
	3.1. Centralized mobility management . . . . . . . . . . . . . 7		3.1. Centralized mobility management . . . . . . . . . . . . . 7
	3.2. Distributed mobility management . . . . . . . . . . . . . 8		3.2. Distributed mobility management . . . . . . . . . . . . . 8
	4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9		4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9
	5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11		5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.1. Distributed deployment . . . . . . . . . . . . . . . . . . 11		5.1. Distributed processing . . . . . . . . . . . . . . . . . . 11
	5.2. Transparency to Upper Layers when needed . . . . . . . . . 11		5.2. Transparency to Upper Layers when needed . . . . . . . . . 11
	5.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 12		5.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 12
	5.4. Existing mobility protocols . . . . . . . . . . . . . . . 12		5.4. Existing mobility protocols . . . . . . . . . . . . . . . 12
	5.5. Co-existence . . . . . . . . . . . . . . . . . . . . . . . 12		5.5. Co-existence . . . . . . . . . . . . . . . . . . . . . . . 12
	5.6. Security considerations . . . . . . . . . . . . . . . . . 13		5.6. Security considerations . . . . . . . . . . . . . . . . . 13
	5.7. Multicast considerations . . . . . . . . . . . . . . . . . 13		5.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 14
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 14		6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	8. Co-authors and Contributors . . . . . . . . . . . . . . . . . 14		8. Co-authors and Contributors . . . . . . . . . . . . . . . . . 15
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 14		9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
	9.2. Informative References . . . . . . . . . . . . . . . . . . 14		9.2. Informative References . . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	In the past decade a fair number of mobility protocols have been		In the past decade a fair number of mobility protocols have been
	standardized [RFC6275] [RFC5944] [RFC5380] [RFC6301] [RFC5213].		standardized [RFC6275] [RFC5944] [RFC5380] [RFC6301] [RFC5213].
	Although the protocols differ in terms of functions and associated		Although the protocols differ in terms of functions and associated
	message formats, we can identify a few key common features:		message formats, we can identify a few key common features:
	o a centralized mobility anchor providing global reachability and an		o a centralized mobility anchor providing global reachability and an
	always-on experience to the user;		always-on experience to the user;
	skipping to change at page 4, line 29		skipping to change at page 4, line 29
	for multi-mode terminals (e.g. smartphones).		for multi-mode terminals (e.g. smartphones).
	The presence of the centralized mobility anchor allows a mobile node		The presence of the centralized mobility anchor allows a mobile node
	to remain reachable after it has moved to a different network. The		to remain reachable after it has moved to a different network. The
	anchor point, among other tasks, ensures connectivity by forwarding		anchor point, among other tasks, ensures connectivity by forwarding
	packets destined to, or sent from, the mobile node. In practice,		packets destined to, or sent from, the mobile node. In practice,
	most of the deployed architectures today have a small number of		most of the deployed architectures today have a small number of
	centralized anchors managing the traffic of millions of mobile nodes.		centralized anchors managing the traffic of millions of mobile nodes.
	Compared with a distributed approach, a centralized approach is		Compared with a distributed approach, a centralized approach is
	likely to have several issues or limitations affecting performance		likely to have several issues or limitations affecting performance
	and scalability, which require costly network dimensioning and		and scalability, which require costly network engineering to resolve.
	engineering to resolve.
	To optimize handovers from the perspective of mobile nodes, the base		To optimize handovers from the perspective of mobile nodes, the base
	protocols have been extended to efficiently handle packet forwarding		protocols have been extended to efficiently handle packet forwarding
	between the previous and new points of attachment. These extensions		between the previous and new points of attachment. These extensions
	are necessary when applications have stringent requirements in terms		are necessary when applications have stringent requirements in terms
	of delay. Notions of localization and distribution of local agents		of delay. Notions of localization and distribution of local agents
	have been introduced to reduce signaling overhead [Paper-		have been introduced to reduce signaling overhead at the centralized
	Distributed.Centralized.Mobility]. Unfortunately, today we witness		routing anchor point [Paper-Distributed.Centralized.Mobility].
	difficulties in getting such protocols deployed, resulting in sub-		Unfortunately, today we witness difficulties in getting such
	optimal choices for the network operators.		protocols deployed, resulting in sub-optimal choices for the network
			operators.
	Moreover, the availability of multiple-interface host and the		Moreover, the availability of multiple-interface host and the
	possibility of using several network interfaces simultaneously have		possibility of using several network interfaces simultaneously have
	motivated the development of even more protocol extensions to add		motivated the development of even more protocol extensions to add
	more capabilities to the mobility management protocol. In the end,		more capabilities to the mobility management protocol. In the end,
	deployment is further complicated with the multitude of extensions.		deployment is further complicated with the multitude of extensions.
	As an effective transport method for multimedia data delivery, IP		As an effective transport method for multimedia data delivery, IP
	multicast support, including optimizations, have been introduced but		multicast support, including optimizations, have been introduced but
	by "patching-up" procedure after completing the design of reference		by "patching-up" procedure after completing the design of reference
	skipping to change at page 5, line 25		skipping to change at page 5, line 25
	the user proximity into account within EPC [TS.29303]. These		the user proximity into account within EPC [TS.29303]. These
	mechanisms were not pursued in the past owing to charging and billing		mechanisms were not pursued in the past owing to charging and billing
	reasons. Assigning a gateway anchor node from a visited network in		reasons. 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. Charging and billing require solutions beyond		voice services only. Charging and billing require solutions beyond
	the mobility protocol.		the mobility protocol.
	Both traffic offloading and CDN mechanisms could benefit from the		Both traffic offloading and CDN mechanisms could benefit from the
	development of mobile architectures with fewer levels of routing		development of mobile architectures with fewer levels of routing
	hierarchy introduced into the data path by the mobility management		hierarchy introduced into the data path by the mobility management
	system. This trend towards so-called "flat networks" is reinforced		system. This trend towards so-called "flat networks" works best for
	by a shift in user traffic behavior. In particular, there are direct		direct communications among peers in the same geographical area.
	communications among peers in the same geographical area.
	Distributed mobility management in a truly flat mobile architecture		Distributed mobility management in a truly flat mobile architecture
	would anchor the traffic closer to the point of attachment of the		would anchor the traffic closer to the point of attachment of the
	user.		user.
	Today's mobile networks present service providers with new		Today's mobile networks present service providers with new
	challenges. Mobility patterns indicate that mobile nodes remain		challenges. Mobility patterns indicate that mobile nodes often
	attached to the same point of attachment for considerable periods of		remain attached to the same point of attachment for considerable
	time [Paper-Locating.User]. Specific IP mobility management support		periods of time [Paper-Locating.User]. Specific IP mobility
	is not required for applications that launch and complete their		management support is not required for applications that launch and
	sessions while the mobile node is connected to the same point of		complete their sessions while the mobile node is connected to the
	attachment. However, currently, IP mobility support is designed for		same point of attachment. However, currently, IP mobility support is
	always-on operation, maintaining all parameters of the context for		designed for always-on operation, maintaining all parameters of the
	each mobile subscriber for as long as they are connected to the		context for each mobile subscriber for as long as they are connected
	network. This can result in a waste of resources and unnecessary		to the network. This can result in a waste of resources and
	costs for the service provider. Infrequent node mobility coupled		unnecessary costs for the service provider. Infrequent node mobility
	with application intelligence suggest that mobility support could be		coupled with application intelligence suggest that mobility support
	provided selectively, thus reducing the amount of context maintained		could be provided selectively, thus reducing the amount of context
	in the network.		maintained in the network.
	The distributed mobility managemetn (DMM) charter addresses two		The distributed mobility management (DMM) charter addresses two
	complementary aspects of mobility management procedures: the		complementary aspects of mobility management procedures: the
	distribution of mobility anchors towards a more flat network and the		distribution of mobility anchors towards a more flat network and the
	dynamic activation/deactivation of mobility protocol support as an		dynamic activation/deactivation of mobility protocol support as an
	enabler to distributed mobility management. The former aims at		enabler to distributed mobility management. The former aims at
	positioning mobility anchors (e.g., HA, LMA) closer to the user;		positioning mobility anchors (e.g., HA, LMA) closer to the user;
	ideally, mobility agents could be collocated with the first-hop		ideally, mobility agents could be collocated with the first-hop
	router. The latter, facilitated by the distribution of mobility		router. The latter, facilitated by the distribution of mobility
	anchors, aims at identifying when mobility support must be activated		anchors, aims at identifying when mobility support must be activated
	and identifying sessions that do not require mobility management		and identifying sessions that do not require mobility management
	support -- thus reducing the amount of state information that must be		support -- thus reducing the amount of state information that must be
	maintained in various mobility agents of the mobile network. The key		maintained in various mobility agents of the mobile network. The key
	idea is that dynamic mobility management relaxes some of the		idea is that dynamic mobility management relaxes some of the
	constraints of previously-standardized mobility management solutions		constraints of previously-standardized mobility management solutions
	and, by doing so, it can avoid the unnecessary establishment of		and, by doing so, it can avoid the unnecessary establishment of
	mechanisms to forward 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 requirements		be addressed with DMM are summarized in Section 4. The mandatory
	to address various problems are given in Section 5. Finally,		requirements as well as the optional requirements are given in
	security considerations are discussed in Section 6.		Section 5. Finally, 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].
	2. Conventions used in this document		2. Conventions used in this document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].
	2.1. Terminology		2.1. Terminology
	All the general mobility-related terms and their acronyms used in		All the general mobility-related terms and their acronyms used in
	this document are to be interpreted as defined in the Mobile IPv6		this document are to be interpreted as defined in the Mobile IPv6
	base specification [RFC6275], in the Proxy mobile IPv6 specification		base specification [RFC6275], in the Proxy mobile IPv6 specification
	[RFC5213], and in Mobility Related Terminology [RFC3753]. These		[RFC5213], and in Mobility Related Terminology [RFC3753]. These
	terms include the following: mobile node (MN), correspondent node		terms include the following: mobile node (MN), correspondent node
	(CN), and home agent (HA) as per [RFC6275]; local mobility anchor		(CN), and home agent (HA) as per [RFC6275]; local mobility anchor
	(LMA) and mobile access gateway (MAG) as per [RFC5213], and context		(LMA) and mobile access gateway (MAG) as per [RFC5213], and context
	as per [RFC3753].		as per [RFC3753].
	skipping to change at page 7, line 35		skipping to change at page 7, line 28
	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 mapping information between		In centralized mobility management, the mapping information between
	the persistent node identifier and the locator IP address of a mobile		the persistent node identifier and the locator IP address of a mobile
	node (MN) is kept at a single mobility anchor. At the same time,		node (MN) is kept at a single mobility anchor. At the same time,
	packets destined to the MN are routed via this anchor. In other		packets destined to the MN are routed via this anchor. In other
	words, such mobility management systems are centralized in both the		words, such mobility management systems are centralized in both the
	control plane and the data plane.		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 of such centralized mobility anchors are the		in Figure 1. Examples of such centralized mobility anchors are the
	home agent (HA) and local mobility anchor (LMA) in Mobile IPv6		home agent (HA) and local mobility anchor (LMA) in Mobile IPv6
	[RFC6275] and Proxy Mobile IPv6 [RFC5213], respectively. Current		[RFC6275] and Proxy Mobile IPv6 [RFC5213], respectively. Current
	cellular networks such as the Third Generation Partnership Project		cellular networks such as the Third Generation Partnership Project
	(3GPP) GPRS networks, CDMA networks, and 3GPP Evolved Packet System		(3GPP) GPRS networks, CDMA networks, and 3GPP Evolved Packet System
	(EPS) networks employ centralized mobility management too. In		(EPS) networks employ centralized mobility management too. In
	particular, the Gateway GPRS Support Node (GGSN), Serving GPRS		particular, the Gateway GPRS Support Node (GGSN), Serving GPRS
	Support Node (SGSN) and Radio Network Controller (RNC) in the 3GPP		Support Node (SGSN) and Radio Network Controller (RNC) in the 3GPP
	GPRS hierarchical network, and the Packet Data Network Gateway (P-GW)		GPRS hierarchical network, and the Packet Data Network Gateway (P-GW)
	and Serving Gateway (S-GW) in the 3GPP EPS network, respectively, act		and Serving Gateway (S-GW) in the 3GPP EPS network all act as anchors
	as anchors in a hierarchy.		in a hierarchy.
	3G GPRS 3GPP EPS MIP/PMIP		3G GPRS 3GPP EPS MIP/PMIP
	+------+ +------+ +------+		+------+ +------+ +------+
	| GGSN | | P-GW | |HA/LMA|		| GGSN | | P-GW | |HA/LMA|
	+------+ +------+ +------+		+------+ +------+ +------+
	/\ /\ /\		/\ /\ /\
	/ \ / \ / \		/ \ / \ / \
	/ \ / \ / \		/ \ / \ / \
	/ \ / \ / \		/ \ / \ / \
	/ \ / \ / \		/ \ / \ / \
	skipping to change at page 9, line 45		skipping to change at page 9, line 45
	PS2: Divergence from other evolutionary trends in network		PS2: Divergence from other evolutionary trends in network
	architectures such as distribution of content delivery.		architectures such as distribution of content delivery.
	Centralized mobility management can become non-optimal with a		Centralized mobility management can become non-optimal with a
	flat network architecture.		flat network architecture.
	PS3: Low scalability of centralized tunnel management and mobility		PS3: Low scalability of centralized tunnel management and mobility
	context maintenance		context maintenance
	Setting up tunnels through a central anchor and maintaining		Setting up tunnels through a central anchor and maintaining
	mobility context for each MN requires more resources in a		mobility context for each MN usually requires more concentrated
	centralized design, thus reducing scalability. Distributing		resources in a centralized design, thus reducing scalability.
	the tunnel maintenance function and the mobility context		Distributing the tunnel maintenance function and the mobility
	maintenance function among different network entities with		context maintenance function among different network entities
	proper signaling protocol design can increase scalability.		with proper signaling protocol design can increase scalability.
	PS4: Single point of failure and attack		PS4: Single point of failure and attack
	Centralized anchoring designs may be more vulnerable to single		Centralized anchoring designs may be more vulnerable to single
	points of failures and attacks than a distributed system. The		points of failures and attacks than a distributed system. The
	impact of a successful attack on a system with centralized		impact of a successful attack on a system with centralized
	mobility management can be far greater as well.		mobility management can be far greater as well.
	PS5: Unnecessarily reserving resources to provide mobility support		PS5: Unnecessarily reserving resources to provide mobility support
	to nodes that do not need such support		to nodes that do not need such support
	IP mobility support is not always required, and not every		IP mobility support is not always required, and not every
	parameter of mobility context is always used. For example,		parameter of mobility context is always used. For example,
	some applications do not need a stable IP address during a		some applications do not need a stable IP address during a
	handover to maintain session continuity. Sometimes, the entire		handover to maintain session continuity. Sometimes, the entire
	application session runs while the terminal does not change the		application session runs while the terminal does not change the
	point of attachment. Besides, some sessions, e.g. SIP-based		point of attachment. Besides, some sessions, e.g. SIP-based
	sessions, can handle mobility at the application layer and		sessions, can handle mobility at the application layer and
	hence do not need IP mobility support; it is then more		hence do not need IP mobility support; it is then more
	efficient to deactivate IP mobility support for such sessions."		efficient to deactivate IP mobility support for such sessions.
	PS6: (Related problem) Mobility signaling overhead with peer-to-peer		PS6: (Related problem) Mobility signaling overhead with peer-to-peer
	communication		communication
	Wasting resources when mobility signaling (e.g., maintenance of		Wasting resources when mobility signaling (e.g., maintenance of
	the tunnel, keep alive signaling, etc.) is not turned off for		the tunnel, keep alive signaling, etc.) is not turned off for
	peer-to-peer communication. Peer-to-peer communications have		peer-to-peer communication. Peer-to-peer communications have
	particular traffic patterns that often do not benefit from		particular traffic patterns that often do not benefit from
	mobility support from the network. Thus, the associated		mobility support from the network. Thus, the associated
	mobility support signaling (e.g., maintenance of the tunnel,		mobility support signaling (e.g., maintenance of the tunnel,
	keep alive signaling, etc.) wastes network resources for no		keep alive signaling, etc.) wastes network resources for no
	application gain. In such a case, it is better to enable		application gain. In such a case, it is better to enable
	mobility support selectively.		mobility support selectively.
	PS7: (Related problem) Complicated deployment with many MIP variants		PS7: (Related problem) Deployment with multiple mobility solutions
	and extensions
	Deployment is complicated with many variants and extensions of		There are already many variants and extensions of MIP.
	MIP. When introducing new functions which may add to the		Deployment of new mobility management solutions can be
	complexity, existing solutions are more vulnerable to break.		challenging, and debugging difficult, when they must co-exist
			with solutions already in the field.
	PS8: Duplicate multicast traffic		PS8: Duplicate multicast traffic
	IP multicast distribution over architectures using IP mobility		IP multicast distribution over architectures using IP mobility
	solutions (e.g. RFC6224) may lead to convergence of duplicated		solutions (e.g. RFC6224) may lead to convergence of duplicated
	multicast subscriptions towards the downstream tunnel entity		multicast subscriptions towards the downstream tunnel entity
	(e.g. MAG in PMIPv6). Concretely, when multicast subscription		(e.g. MAG in PMIPv6). Concretely, when multicast subscription
	for individual mobile nodes is coupled with mobility tunnels		for individual mobile nodes is coupled with mobility tunnels
	(e.g. PMIPv6 tunnel), duplicate multicast subscription(s) is		(e.g. PMIPv6 tunnel), duplicate multicast subscription(s) is
	prone to be received through different upstream paths. This		prone to be received through different upstream paths. This
	problem may also exist or be more severe in a distributed		problem may also exist or be more severe in a distributed
	mobility environment.		mobility environment.
	5. Requirements		5. Requirements
	After comparing distributed mobility management against centralized		After comparing distributed mobility management against centralized
	deployment in Section 3, this section identifies the following		deployment in Section 3, this section identifies the following
	requirements:		requirements:
	5.1. Distributed deployment		5.1. Distributed processing
	REQ1: Distributed deployment		REQ1: Distributed processing
	IP mobility, network access and routing solutions provided by		IP mobility, network access and routing solutions provided by
	DMM MUST enable distributed deployment for mobility management		DMM MUST enable distributed processing for mobility management
	of some flows so that traffic does not need to traverse		of some flows so that traffic does not need to traverse
	centrally deployed mobility anchors and thus can be routed in		centrally deployed mobility anchors and thereby avoid non-
	an optimal manner.		optimal routes.
	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 and distribute content by combining distributed mobility		cache and distribute content by combining distributed mobility
	anchors with caching systems (e.g., CDN); (b) the		anchors with caching systems (e.g., CDN); (b) the
	significantly larger number of mobile nodes and flows call for		significantly larger number of mobile nodes and flows call for
	improved scalability; (c) single points of failure are avoided		improved scalability; (c) single points of failure are avoided
	in a distributed system; (d) threats against centrally		in a distributed system; (d) threats against centrally
	deployed anchors, e.g., home agent and local mobility anchor,		deployed anchors, e.g., home agent and local mobility anchor,
	are mitigated in a distributed system.		are mitigated in a distributed system.
	This requirement addresses problems PS1, PS2, PS3, and PS4 in Section		This requirement addresses problems PS1, PS2, PS3, and PS4 in Section
	4.		4. (Existing route optimization is only a host-based solution. On
			the other hand, localized routing with PMIPv6 addresses only a part
			of the problem where both the MN and the CN are located in the PMIP
			domain and attached to a MAG, and is not applicable when the CN is
			outside the PMIP domain.)
	5.2. Transparency to Upper Layers when needed		5.2. Transparency to Upper Layers when needed
	REQ2: Transparency to Upper Layers when needed		REQ2: Transparency to Upper Layers when needed
	DMM solutions MUST provide transparent mobility support above		DMM solutions MUST provide transparent mobility support above
	the IP layer when needed. Such transparency is needed, for		the IP layer when needed. Such transparency is needed, for
	example, when, upon change of point of attachment to the		example, when, upon change of point of attachment to the
	network, an application flow cannot cope with a change in the		network, an application flow cannot cope with a change in the
	IP address. However, it is not always necessary to maintain a		IP address. However, it is not always necessary to maintain a
	skipping to change at page 12, line 22		skipping to change at page 12, line 26
	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. It is also unnecessarily complex to solve		common than today.
	this problem for IPv4, as we will not be able to use some of
	the IPv6-specific features/tools.		This requirement avoids the unnecessarily complexity in solving the
			problems in Section 4 for IPv4, which will not be able to use some of
			the IPv6-specific features.
	5.4. Existing mobility protocols		5.4. Existing mobility protocols
	REQ4: Existing mobility protocols		REQ4: Existing mobility protocols
	A DMM solution SHOULD first consider reusing and extending		A DMM solution SHOULD first consider reusing and extending
	IETF-standardized protocols before specifying new protocols.		IETF-standardized protocols before specifying new protocols.
	5.5. Co-existence		Motivation: Reuse of existing IETF work is more efficient and
			less error-prone.
			This requirement attempts to avoid the need of new protocols
			development and therefore their potential problems of being time-
			consuming and error-prone.
			5.5. Co-existence
	REQ5: Co-existence with deployed networks and hosts		REQ5: Co-existence with deployed networks and hosts
	The DMM solution MUST be able to co-exist with existing		The DMM solution MUST be able to co-exist with existing
	network deployments and end hosts. For example, depending on		network deployments and end hosts. For example, depending on
	the environment in which DMM is deployed, DMM solutions may		the environment in which DMM is deployed, DMM solutions may
	need to be compatible with other deployed mobility protocols		need to be compatible with other deployed mobility protocols
	or may need to co-exist with a network or mobile hosts/routers		or may need to co-exist with a network or mobile hosts/routers
	that do not support DMM protocols. The mobile node may also		that do not support DMM protocols. The mobile node may also
	move between different access networks, where some of them may		move between different access networks, where some of them may
	neither support DMM nor another mobility protocol.		support neither DMM nor another mobility protocol.
	Furthermore, a DMM solution SHOULD work across different		Furthermore, a DMM solution SHOULD work across different
	networks, possibly operated as separate administrative		networks, possibly operated as separate administrative
	domains, when allowed by the trust relationship between them.		domains, when 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 following related problem PS7 in		This requirement addresses the following related problem PS7 in
	Section 4.		Section 4.
	5.6. Security considerations		5.6. Security considerations
	REQ6: Security considerations		REQ6: Security considerations
	DMM protocol solutions MUST consider security risks introduced		DMM protocol solutions MUST consider security risks introduced
	by DMM into the network. Examples of such risks to be		by DMM into the network. Such considerations may include
	considered are authentication and authorization mechanisms		authentication and authorization mechanisms that allow a
	that allow a legitimate mobile host/router to use the mobility		mobile host/router to use the mobility support provided by the
	support provided by the DMM solution; redirecting traffic to		DMM solution; measures against redirecting traffic to the
	the wrong host when providing DMM support; signaling message		wrong host when providing DMM support; signaling message
	protection in terms of authentication, encryption, data		protection for authentication, integrity and confidentiality.
	integrity and confidentiality.
	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, can be mounted		service, man-in-the-middle attacks, and so on, may become
	against a DMM network and need to be protected against. Proof		newly possible or easier to mount due to the introduction of
	of possession of past and new IP addresses may be needed.		DMM. Proof of possession of past and new IP addresses may be
			needed.
	Signaling messages can be subject to various attacks since		Signaling messages can be subject to various attacks since
	they carry critical context information about a mobile node/		they carry critical context information about a mobile node/
	router. For instance, a malicious node can forge a number of		router. For instance, a malicious node can forge a number of
	signaling messages thus redirecting traffic from its		signaling messages thus redirecting traffic from its
	legitimate path. Consequently, the specific node is under a		legitimate path. Consequently, the specific node is under a
	denial of service attack, whereas other nodes do not receive		denial of service attack, whereas other nodes do not receive
	their traffic. As signaling messages may travel over the		their traffic. As signaling messages may travel over the
	Internet, end-to-end security between communicating hosts must		Internet, end-to-end security between communicating hosts must
	be required.		be required.
	5.7. Multicast considerations		This requirement addresses the problems of potentially insecure
			mobility management protocols which make deployment infeasible
			because platforms conforming to the protocols are at risk for data
			loss and numerous other dangers, including financial harm to the
			user.
	REQ7: DMM should enable multicast solutions in flexible distribution		5.7. Multicast
			REQ7: DMM SHOULD enable multicast solutions in flexible distribution
	scenario. This flexibility pertains to the preservation of IP		scenario. This flexibility pertains to the preservation of IP
	multicast nature from the perspective of a mobility entiry and		multicast nature from the perspective of a mobility entity and
	transmission of mulitcast packets to/from varius multicast-		transmission of multicast packets to/from various multicast-
	enabled entities. Therefore, this flexibility enables		enabled entities. Therefore, this flexibility enables
	different IP multicast flows with respect to a mobile host to		different IP multicast flows with respect to a mobile host to
	be managed (e.g., subscribed, received and/or transmitted)		be managed (e.g., subscribed, received and/or transmitted)
	using multiple multicast-enabled endpoints.		using multiple multicast-enabled endpoints.
	Motivation: The motivation of this requirement is to consider		Motivation: to consider multicast early so that solutions can
	multicast early so that solutions can be developed to avoid		be developed to avoid network inefficiency issues in multicast
	network inefficiency issues in multicast traffic delivery.		traffic delivery. The multicast solution should therefore
	The multicast solution should therefore avoid restricting the		avoid restricting the management of all IP multicast traffic
	managment of all IP multicast traffic relative to a host		relative to a host through a dedicated interface on multicast-
	through a dedicated interface on multicast-capable access		capable access routers.
	routers.
	This requirement addresses the problems PS1 and PS8 in Section 4.		This requirement addresses the problems PS1 and PS8 in Section 4.
	6. Security Considerations		6. Security Considerations
	Distributed mobility management (DMM) requires two kinds of security		Distributed mobility management (DMM) requires two kinds of security
	considerations: First, access network security that only allows a		considerations. The first consideration is on access network
	legitimate mobile host/router to use DMM; Second, end-to-end security		security required between the mobile host/router and the access
	between the end hosts, which protects signaling messages for DMM.		network deploying DMM. It allows only a legitimate mobile host/
	Access network security is required between the mobile host/router		router to use DMM. The second consideration is on end-to-end
	and the access network deploying DMM. End-to-end security is		security required between nodes that participate in the DMM protocol.
	required between nodes that participate in the DMM protocol.		It protects the DMM signaling messages.
	It is necessary to provide sufficient defense against possible		It is necessary to provide sufficient defense against possible
	security attacks, or to adopt existing security mechanisms and		security attacks, or to adopt existing security mechanisms and
	protocols to provide sufficient security protections. For instance,		protocols to provide sufficient security protections. For instance,
	EAP-based authentication can be used for access network security,		EAP-based authentication can be used for access network security,
	while IPsec can be used for end-to-end security.		while IPsec can be used for end-to-end security.
	7. IANA Considerations		7. IANA Considerations
	None		None
	skipping to change at page 17, line 4		skipping to change at page 17, line 23
	[TS.29303]		[TS.29303]
	3GPP, "Domain Name System Procedures; Stage 3", 3GPP		3GPP, "Domain Name System Procedures; Stage 3", 3GPP
	TR 23.303 11.2.0, September 2012.		TR 23.303 11.2.0, September 2012.
	Authors' Addresses		Authors' Addresses
	H Anthony Chan (editor)		H Anthony Chan (editor)
	Huawei Technologies (more co-authors on P. 17)		Huawei Technologies (more co-authors on P. 17)
	5340 Legacy Dr. Building 3, Plano, TX 75024, USA		5340 Legacy Dr. Building 3, Plano, TX 75024, USA
	Email: h.a.chan@ieee.org		Email: h.a.chan@ieee.org
	Dapeng Liu		Dapeng Liu
	China Mobile		China Mobile
	Unit2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China		Unit2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China
	Email: liudapeng@chinamobile.com		Email: liudapeng@chinamobile.com
	Pierrick Seite		Pierrick Seite
	France Telecom - Orange		Orange
	4, rue du Clos Courtel, BP 91226, Cesson-Sevigne 35512, France		4, rue du Clos Courtel, BP 91226, Cesson-Sevigne 35512, France
	Email: pierrick.seite@orange-ftgroup.com		Email: pierrick.seite@orange.com
	Hidetoshi Yokota		Hidetoshi Yokota
	KDDI Lab		KDDI Lab
	2-1-15 Ohara, Fujimino, Saitama, 356-8502 Japan		2-1-15 Ohara, Fujimino, Saitama, 356-8502 Japan
	Email: yokota@kddilabs.jp		Email: yokota@kddilabs.jp
	Jouni Korhonen		Jouni Korhonen
	Nokia Siemens Networks		Nokia Siemens Networks
	Email: jouni.korhonen@nsn.com		Email: jouni.korhonen@nsn.com
	-		-
End of changes. 42 change blocks.
	99 lines changed or deleted		114 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/