draft-ietf-dmm-requirements-16.txt		draft-ietf-dmm-requirements-17.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: October 20, 2014 China Mobile		Expires: December 7, 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
	April 18, 2014		June 5, 2014
	Requirements for Distributed Mobility Management		Requirements for Distributed Mobility Management
	draft-ietf-dmm-requirements-16		draft-ietf-dmm-requirements-17
	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 to have a distributed		the hierarchical structure, it can be useful to have a distributed
	model for mobility management in which traffic does not need to		model for mobility management in which traffic does not need to
	traverse centrally deployed mobility anchors far from the optimal		traverse centrally deployed mobility anchors far from the optimal
	skipping to change at page 2, line 4		skipping to change at page 2, line 4
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on October 20, 2014.		This Internet-Draft will expire on December 7, 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 15		skipping to change at page 3, line 15
	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 . . . . . . 7		3. Centralized versus distributed mobility management . . . . . . 7
	3.1. Centralized mobility management . . . . . . . . . . . . . 7		3.1. Centralized mobility management . . . . . . . . . . . . . 7
	3.2. Distributed mobility management . . . . . . . . . . . . . 8		3.2. Distributed mobility management . . . . . . . . . . . . . 8
	4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9		4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9
	5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11		5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 15		6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 17		9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
	9.2. Informative References . . . . . . . . . . . . . . . . . . 18		9.2. Informative References . . . . . . . . . . . . . . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
	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 these 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
	skipping to change at page 13, line 14		skipping to change at page 13, line 14
	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		development and therefore their potential problems of being
	time-consuming and error-prone.		time-consuming and error-prone.
	REQ5: Coexistence with deployed networks/hosts and operability		REQ5: Coexistence with deployed networks/hosts and operability
	across different networks		across different networks
	A DMM solution may require loose, tight or no integration into		A DMM solution may require loose, tight or no integration into
	existing mobility protocols and host IP stack. Regardless of		existing mobility protocols and host IP stack. Regardless of
	the integration level, such a DMM solution MUST be able to		the integration level, DMM implementations MUST be able to
	coexist with existing network deployments, end hosts and		coexist with existing network deployments, end hosts 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 the needed mobility management		administrative domains, when the needed mobility management
	signaling, forwarding, and network access are allowed by the		signaling, forwarding, and network access are allowed by the
	trust relationship between them.		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		This requirement addresses the problem PS7 described in
	Section 4.		Section 4.
	REQ6: Security considerations		REQ6: Operation and Management considerations.
			A DMM solution needs to consider configuring a device,
			monitoring the current operational state of a device,
			responding to events that impact the device, possibly by
			modifying the configuration and storing the data in a format
			that can be analyzed later. Different management protocols
			are available. For example:
			(a) SNMP [RFC1157] with definition of standardized management
			information base MIB objects for DMM, that allows
			monitoring traffic steering in a consistent manner across
			different devices,
			(b) NETCONF [RFC6241] with definition of standardized YANG
			[RFC6020] modules for DMM to achieve a standardized
			configuration,
			(c) syslog [RFC3164] which is a one-way protocol allowing a
			device to report significant events to a log analyzer in
			a network management system.
			(d) IP Flow Information Export (IPFIX) Protocol, which serves
			as a means for transmitting traffic flow information over
			the network [RFC7011], with a formal description of IPFIX
			Information Elements [RFC7012].
			It is not the goal of the requirements document to impose
			which management protocol(s) should be used. An inventory of
			the management protocols and data models is covered in RFC
			6632.
			The following lists the operation and management
			considerations required for a DMM solution; the list may not
			be exhaustive and may be expanded according to the needs of
			the solutions:
			A DMM solution MUST describe in what environment and how it
			can be scalably deployed and managed.
			A DMM solution MUST support mechanisms to test if the DMM
			solution is working properly. For example, when a DMM
			solution employs traffic indirection to support a mobility
			session, implementations MUST support mechanisms to test that
			the appropriate traffic indirection operations are in place,
			including the setup of traffic indirection and the subsequent
			teardown of the indirection to release the associated network
			resources when the mobility session has closed.
			A DMM solution SHOULD expose the operational state of DMM to
			the administrators of the DMM entities. For example, when a
			DMM solution employs separation between session identifier and
			forwarding address, it should expose the association between
			them.
			When flow mobility is supported by a DMM solution, the
			solution SHOULD support means to correlate the flow routing
			policies and the observed forwarding actions.
			A DMM solution SHOULD support mechanisms to check the liveness
			of forwarding path. If the DMM solution sends periodic update
			refresh messages to configure the forwarding path, the refresh
			period SHOULD be configurable and a reasonable default
			configuration value proposed. Information collected can be
			logged or made available with protocols such as SNMP
			[RFC1157], NETCONF [RFC6241], IPFIX [RFC7011], or syslog
			[RFC3164].
			A DMM solution MUST provide fault management and monitoring
			mechanisms to manage situations where update of the mobility
			session or the data path fails. The system must also be able
			to handle situations where a mobility anchor with ongoing
			mobility sessions fails.
			A DMM solution SHOULD be able to monitor usage of DMM
			protocol. When a DMM solution uses an existing protocol, the
			techniques already defined for that protocol SHOULD be used to
			monitor the DMM operation. When these techniques are
			inadequate, new techniques MUST be developed.
			In particular, the DMM solution SHOULD
			(a) be able to monitor the number of mobility sessions per
			user as well as their average duration.
			(b) provide indication on DMM performance such as
			1 the handover delay which includes the time necessary
			to re-establish the forwarding path when the point of
			attachment changes,
			2 the protocol reactivity which is the time between
			handover events such as the attachment to a new access
			point and the completion of the mobility session
			update.
			(c) provide means to measure the signaling cost of the DMM
			protocol.
			(d) if tunneling is used for traffic redirection, monitor
			1 the number of tunnels,
			2 their transmission and reception information,
			3 the used encapsulation method and overhead
			4 the security used at a node level.
			DMM solutions SHOULD support standardized configuration with
			NETCONF [RFC6241], using YANG [RFC6020] modules, which SHOULD
			be created for DMM when needed for such configuration.
			However, if a DMM solution creates extensions to MIPv6 or
			PMIPv6, the allowed addition of the definition of management
			information base (MIB) objects to MIPv6 MIB [RFC4295] or
			PMIPv6 MIB [RFC6475] needed for the control and monitoring of
			the protocol extensions SHOULD be limited to read-only
			objects.
			Motivation: A DMM solution that is designed from the beginning
			for operability and manageability can avoid difficulty or
			incompatibility to implement efficient operations and
			management solutions.
			These requirements avoid DMM designs that make operations and
			management difficult or costly.
			REQ7: Security considerations
	A DMM solution MUST support any security protocols and		A DMM solution MUST support any security protocols and
	mechanisms needed to secure the network and to make continuous		mechanisms needed to secure the network and to make continuous
	security improvements. In addition, with security taken into		security improvements. In addition, with security taken into
	consideration early in the design, a DMM solution MUST NOT		consideration early in the design, a DMM solution MUST NOT
	introduce new security risks, or amplify existing security		introduce new security risks, or amplify existing security
	risks, that cannot be mitigated by existing security protocols		risks, that cannot be mitigated by existing security protocols
	and mechanisms.		and mechanisms.
	Motivation: Various attacks such as impersonation, denial of		Motivation: Various attacks such as impersonation, denial of
	skipping to change at page 14, line 18		skipping to change at page 17, line 5
	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		uncontrollable problems of potentially insecure mobility
	management protocols which make deployment infeasible because		management protocols which make deployment infeasible because
	platforms conforming to the protocols are at risk for data		platforms conforming to the protocols are at risk for data
	loss and numerous other dangers, including financial harm to		loss and numerous other dangers, including financial harm to
	the users.		the users.
	REQ7: Multicast considerations		REQ8: 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 forwarding for the multicast traffic. Instead DMM		optimal forwarding for the multicast traffic. Instead DMM
	should consider multicast early so that the multicast		should consider multicast early so that the multicast
	solutions can better consider efficiency nature in the		solutions can better consider efficiency nature in the
	multicast traffic delivery (such as duplicate multicast		multicast traffic delivery (such as duplicate multicast
	subscriptions towards the downstream tunnel entities). The		subscriptions towards the downstream tunnel entities). The
	multicast solutions should then avoid restricting the		multicast solutions should then avoid restricting the
	management of all IP multicast traffic to a single host		management of all IP multicast traffic to a single host
	through a dedicated (tunnel) interface on multicast-capable		through a dedicated (tunnel) interface on multicast-capable
	access routers.		access routers.
	This requirement addresses the problems PS1 and PS8 described		This requirement addresses the problems PS1 and PS8 described
	in 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
	skipping to change at page 17, line 43		skipping to change at page 20, line 16
	Email: macsbug@research.att.com		Email: macsbug@research.att.com
	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
			David Harrington
			Effective Software
			Email: ietfdbh@comcast.net
	9. References		9. References
	9.1. Normative References		9.1. Normative References
			[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
			"Simple Network Management Protocol (SNMP)", STD 15,
			RFC 1157, May 1990.
	[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.
			[RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
			August 2001.
	[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",		[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
	RFC 3753, June 2004.		RFC 3753, June 2004.
			[RFC4295] Keeni, G., Koide, K., Nagami, K., and S. Gundavelli,
			"Mobile IPv6 Management Information Base", RFC 4295,
			April 2006.
	[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,		[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
	and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.		and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
			[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
			Network Configuration Protocol (NETCONF)", RFC 6020,
			October 2010.
			[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
			Bierman, "Network Configuration Protocol (NETCONF)",
			RFC 6241, June 2011.
	[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support		[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
	in IPv6", RFC 6275, July 2011.		in IPv6", RFC 6275, July 2011.
			[RFC6475] Keeni, G., Koide, K., Gundavelli, S., and R. Wakikawa,
			"Proxy Mobile IPv6 Management Information Base", RFC 6475,
			May 2012.
			[RFC6632] Ersue, M. and B. Claise, "An Overview of the IETF Network
			Management Standards", RFC 6632, June 2012.
			[RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of
			the IP Flow Information Export (IPFIX) Protocol for the
			Exchange of Flow Information", STD 77, RFC 7011,
			September 2013.
			[RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow
			Information Export (IPFIX)", RFC 7012, September 2013.
	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., Gundavelli, S., and C.
	"Separation of Control and User Plane for Proxy Mobile		Perkins, "Separation of Control and User Plane for Proxy
	IPv6", draft-wakikawa-netext-pmip-cp-up-separation-00		Mobile IPv6",
	(work in progress), February 2014.		draft-wakikawa-netext-pmip-cp-up-separation-03 (work in
			progress), April 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
End of changes. 16 change blocks.
	31 lines changed or deleted		184 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/