< draft-ietf-rtgwg-cl-requirement-06.txt		draft-ietf-rtgwg-cl-requirement-07.txt >
	RTGWG C. Villamizar, Ed.		RTGWG C. Villamizar, Ed.
	Internet-Draft OCCNC, LLC		Internet-Draft OCCNC, LLC
	Intended status: Informational D. McDysan, Ed.		Intended status: Informational D. McDysan, Ed.
	Expires: December 9, 2012 Verizon		Expires: December 22, 2012 Verizon
	S. Ning		S. Ning
	Tata Communications		Tata Communications
	A. Malis		A. Malis
	Verizon		Verizon
	L. Yong		L. Yong
	Huawei USA		Huawei USA
	June 7, 2012		June 20, 2012
	Requirements for MPLS Over a Composite Link		Requirements for MPLS Over a Composite Link
	draft-ietf-rtgwg-cl-requirement-06		draft-ietf-rtgwg-cl-requirement-07
	Abstract		Abstract
	There is often a need to provide large aggregates of bandwidth that		There is often a need to provide large aggregates of bandwidth that
	are best provided using parallel links between routers or MPLS LSR.		are best provided using parallel links between routers or MPLS LSR.
	In core networks there is often no alternative since the aggregate		In core networks there is often no alternative since the aggregate
	capacities of core networks today far exceed the capacity of a single		capacities of core networks today far exceed the capacity of a single
	physical link or single packet processing element.		physical link or single packet processing element.
	The presence of parallel links, with each link potentially comprised		The presence of parallel links, with each link potentially comprised
	skipping to change at page 2, line 7 ¶		skipping to change at page 2, line 7 ¶
	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 December 9, 2012.		This Internet-Draft will expire on December 22, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 17 ¶		skipping to change at page 3, line 17 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
	2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Network Operator Functional Requirements . . . . . . . . . . . 5		4. Network Operator Functional Requirements . . . . . . . . . . . 5
	4.1. Availability, Stability and Transient Response . . . . . . 5		4.1. Availability, Stability and Transient Response . . . . . . 5
	4.2. Component Links Provided by Lower Layer Networks . . . . . 6		4.2. Component Links Provided by Lower Layer Networks . . . . . 6
	4.3. Parallel Component Links with Different Characteristics . 8		4.3. Parallel Component Links with Different Characteristics . 8
	5. Derived Requirements . . . . . . . . . . . . . . . . . . . . . 10		5. Derived Requirements . . . . . . . . . . . . . . . . . . . . . 10
	6. Management Requirements . . . . . . . . . . . . . . . . . . . 11		6. Management Requirements . . . . . . . . . . . . . . . . . . . 11
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 12		9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 12		10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	10.2. Informative References . . . . . . . . . . . . . . . . . . 13		10.2. Informative References . . . . . . . . . . . . . . . . . . 13
	Appendix A. ITU-T G.800 Composite Link Definitions and		Appendix A. ITU-T G.800 Composite Link Definitions and
	Terminology . . . . . . . . . . . . . . . . . . . . . 14		Terminology . . . . . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	The purpose of this document is to describe why network operators		The purpose of this document is to describe why network operators
	require certain functions in order to solve certain business problems		require certain functions in order to solve certain business problems
	(Section 2). The intent is to first describe why things need to be		(Section 2). The intent is to first describe why things need to be
	done in terms of functional requirements that are as independent as		done in terms of functional requirements that are as independent as
	possible of protocol specifications (Section 4). For certain		possible of protocol specifications (Section 4). For certain
	functional requirements this document describes a set of derived		functional requirements this document describes a set of derived
	skipping to change at page 8, line 28 ¶		skipping to change at page 8, line 28 ¶
	FR#11 The solution SHALL measure traffic on a labeled traffic flow		FR#11 The solution SHALL measure traffic on a labeled traffic flow
	and dynamically select the component link on which to place		and dynamically select the component link on which to place
	this flow in order to balance the load so that no component		this flow in order to balance the load so that no component
	link in the composite link between a pair of nodes is		link in the composite link between a pair of nodes is
	overloaded.		overloaded.
	FR#12 When a traffic flow is moved from one component link to		FR#12 When a traffic flow is moved from one component link to
	another in the same composite link between a set of nodes (or		another in the same composite link between a set of nodes (or
	sites), it MUST be done so in a minimally disruptive manner.		sites), it MUST be done so in a minimally disruptive manner.
	FR#13 The solution SHALL provide a means to identify flows whose		FR#13 Load balancing MAY be used during sustained low traffic
			periods to reduce the number of active component links for the
			purpose of power reduction.
			FR#14 The solution SHALL provide a means to identify flows whose
	rearrangement frequency needs to be bounded by a configured		rearrangement frequency needs to be bounded by a configured
	value.		value.
	FR#14 The solution SHALL provide a means that communicates whether		FR#15 The solution SHALL provide a means that communicates whether
	the flows within an LSP can be split across multiple component		the flows within an LSP can be split across multiple component
	links. The solution SHOULD provide a means to indicate the		links. The solution SHOULD provide a means to indicate the
	flow identification field(s) which can be used along the flow		flow identification field(s) which can be used along the flow
	path which can be used to perform this function.		path which can be used to perform this function.
	FR#15 The solution SHALL provide a means to indicate that a traffic		FR#16 The solution SHALL provide a means to indicate that a traffic
	flow shall select a component link with the minimum latency		flow shall select a component link with the minimum latency
	value.		value.
	FR#16 The solution SHALL provide a means to indicate that a traffic		FR#17 The solution SHALL provide a means to indicate that a traffic
	flow shall select a component link with a maximum acceptable		flow shall select a component link with a maximum acceptable
	latency value as specified by protocol.		latency value as specified by protocol.
	FR#17 The solution SHALL provide a means to indicate that a traffic		FR#18 The solution SHALL provide a means to indicate that a traffic
	flow shall select a component link with a maximum acceptable		flow shall select a component link with a maximum acceptable
	delay variation value as specified by protocol.		delay variation value as specified by protocol.
	FR#18 The solution SHALL provide a means local to a node that		FR#19 The solution SHALL provide a means local to a node that
	automatically distributes flows across the component links in		automatically distributes flows across the component links in
	the composite link such that NPOs are met.		the composite link such that NPOs are met.
	FR#19 The solution SHALL provide a means to distribute flows from a		FR#20 The solution SHALL provide a means to distribute flows from a
	single LSP across multiple component links to handle at least		single LSP across multiple component links to handle at least
	the case where the traffic carried in an LSP exceeds that of		the case where the traffic carried in an LSP exceeds that of
	any component link in the composite link. As defined in		any component link in the composite link. As defined in
	section 3, a flow is a sequence of packets that must be		section 3, a flow is a sequence of packets that must be
	transferred on one component link.		transferred on one component link.
	FR#20 The solution SHOULD support the use case where a composite		FR#21 The solution SHOULD support the use case where a composite
	link itself is a component link for a higher order composite		link itself is a component link for a higher order composite
	link. For example, a composite link comprised of MPLS-TP bi-		link. For example, a composite link comprised of MPLS-TP bi-
	directional tunnels viewed as logical links could then be used		directional tunnels viewed as logical links could then be used
	as a component link in yet another composite link that		as a component link in yet another composite link that
	connects MPLS routers.		connects MPLS routers.
	FR#21 The solution MUST support an optional means for LSP signaling		FR#22 The solution MUST support an optional means for LSP signaling
	to bind an LSP to a particular component link within a		to bind an LSP to a particular component link within a
	composite link. If this option is not exercised, then an LSP		composite link. If this option is not exercised, then an LSP
	that is bound to a composite link may be bound to any		that is bound to a composite link may be bound to any
	component link matching all other signaled requirements, and		component link matching all other signaled requirements, and
	different directions of a bidirectional LSP can be bound to		different directions of a bidirectional LSP can be bound to
	different component links.		different component links.
	FR#22 The solution MUST support a means to indicate that both		FR#23 The solution MUST support a means to indicate that both
	directions of co-routed bidirectional LSP MUST be bound to the		directions of co-routed bidirectional LSP MUST be bound to the
	same component link.		same component link.
	A minimally disruptive change implies that as little disruption as is		A minimally disruptive change implies that as little disruption as is
	practical occurs. Such a change can be achieved with zero packet		practical occurs. Such a change can be achieved with zero packet
	loss. A delay discontinuity may occur, which is considered to be a		loss. A delay discontinuity may occur, which is considered to be a
	minimally disruptive event for most services if this type of event is		minimally disruptive event for most services if this type of event is
	sufficiently rare. A delay discontinuity is an example of a		sufficiently rare. A delay discontinuity is an example of a
	minimally disruptive behavior corresponding to current techniques.		minimally disruptive behavior corresponding to current techniques.
	skipping to change at page 10, line 5 ¶		skipping to change at page 10, line 8 ¶
	the normal delay variation (jitter). A delay discontinuity has the		the normal delay variation (jitter). A delay discontinuity has the
	following effect. When a flow is moved from a current link to a		following effect. When a flow is moved from a current link to a
	target link with lower latency, reordering can occur. When a flow is		target link with lower latency, reordering can occur. When a flow is
	moved from a current link to a target link with a higher latency, a		moved from a current link to a target link with a higher latency, a
	time gap can occur. Some flows (e.g., timing distribution, PW		time gap can occur. Some flows (e.g., timing distribution, PW
	circuit emulation) are quite sensitive to these effects. A delay		circuit emulation) are quite sensitive to these effects. A delay
	discontinuity can also cause a jitter buffer underrun or overrun		discontinuity can also cause a jitter buffer underrun or overrun
	affecting user experience in real time voice services (causing an		affecting user experience in real time voice services (causing an
	audible click). These sensitivities may be specified in an NPO.		audible click). These sensitivities may be specified in an NPO.
			As with any load balancing change, a change initiated for the purpose
			of power reduction may be minimally disruptive. Typically the
			disruption is limited to a change in delay characteristics and the
			potential for a very brief period with traffic reordering. The
			network operator when configuring a network for power reduction
			should weigh the benefit of power reduction against the disadvantage
			of a minimal disruption.
	5. Derived Requirements		5. Derived Requirements
	This section takes the next step and derives high-level requirements		This section takes the next step and derives high-level requirements
	on protocol specification from the functional requirements.		on protocol specification from the functional requirements.
	DR#1 The solution SHOULD attempt to extend existing protocols		DR#1 The solution SHOULD attempt to extend existing protocols
	wherever possible, developing a new protocol only if this adds		wherever possible, developing a new protocol only if this adds
	a significant set of capabilities.		a significant set of capabilities.
	DR#2 A solution SHOULD extend LDP capabilities to meet functional		DR#2 A solution SHOULD extend LDP capabilities to meet functional
	skipping to change at page 11, line 7 ¶		skipping to change at page 11, line 16 ¶
	DR#7 When a worst case failure scenario occurs, the number of		DR#7 When a worst case failure scenario occurs, the number of
	RSVP-TE LSPs to be resignaled will cause a period of		RSVP-TE LSPs to be resignaled will cause a period of
	unavailability as perceived by users. The resignaling time of		unavailability as perceived by users. The resignaling time of
	the solution MUST meet the NPO objective for the duration of		the solution MUST meet the NPO objective for the duration of
	unavailability. The resignaling time of the solution MUST not		unavailability. The resignaling time of the solution MUST not
	increase significantly as compared with current methods.		increase significantly as compared with current methods.
	6. Management Requirements		6. Management Requirements
	MR#1 Management Plane MUST support polling of the status and		MR#1 Management Plane MUST support polling of the status and
	configuration of a composite link and its individual composite		configuration of a composite link and its individual composite
	link and support notification of status change.		link and support notification of status change.
	MR#2 Management Plane MUST be able to activate or de-activate any		MR#2 Management Plane MUST be able to activate or de-activate any
	component link in a composite link in order to facilitate		component link in a composite link in order to facilitate
	operation maintenance tasks. The routers at each end of a		operation maintenance tasks. The routers at each end of a
	composite link MUST redistribute traffic to move traffic from a		composite link MUST redistribute traffic to move traffic from
	de-activated link to other component links based on the traffic		a de-activated link to other component links based on the
	flow TE criteria.		traffic flow TE criteria.
	MR#3 Management Plane MUST be able to configure a LSP over a		MR#3 Management Plane MUST be able to configure a LSP over a
	composite link and be able to select a component link for the		composite link and be able to select a component link for the
	LSP.		LSP.
	MR#4 Management Plane MUST be able to trace which component link a		MR#4 Management Plane MUST be able to trace which component link a
	LSP is assigned to and monitor individual component link and		LSP is assigned to and monitor individual component link and
	composite link performance.		composite link performance.
	MR#5 Management Plane MUST be able to verify connectivity over each		MR#5 Management Plane MUST be able to verify connectivity over each
	individual component link within a composite link.		individual component link within a composite link.
	MR#6 Management Plane SHOULD provide the means for an operator to		MR#6 Component link fault notification MUST be sent to the
	initiate an optimization process.		management plane.
	MR#7 Any statement which requires the solution to support some new		MR#7 Composite link fault notification MUST be sent to management
	functionality through use of the words new functionality,		plane and distribute via link state message in the IGP.
	SHOULD be interpretted as follows. The implementation either
	MUST or SHOULD support the new functionality depending on the		MR#8 Management Plane SHOULD provide the means for an operator to
	use of either MUST or SHOULD in the requirements statement.		initiate an optimization process.
	The implementation SHOULD in most or all cases allow any new
	functionality to be individually enabled or disabled through		MR#9 An operator initiated optimization MUST be performed in a
	configuration.		minimally disruptive manner as described in Section 4.3.
			MR#10 Any statement which requires the solution to support some new
			functionality through use of the words new functionality,
			SHOULD be interpretted as follows. The implementation either
			MUST or SHOULD support the new functionality depending on the
			use of either MUST or SHOULD in the requirements statement.
			The implementation SHOULD in most or all cases allow any new
			functionality to be individually enabled or disabled through
			configuration.
	7. Acknowledgements		7. Acknowledgements
	Frederic Jounay of France Telecom and Yuji Kamite of NTT		Frederic Jounay of France Telecom and Yuji Kamite of NTT
	Communications Corporation co-authored a version of this document.		Communications Corporation co-authored a version of this document.
	A rewrite of this document occurred after the IETF77 meeting.		A rewrite of this document occurred after the IETF77 meeting.
	Dimitri Papadimitriou, Lou Berger, Tony Li, the WG chairs John Scuder		Dimitri Papadimitriou, Lou Berger, Tony Li, the former WG chairs John
	and Alex Zinin, and others provided valuable guidance prior to and at		Scuder and Alex Zinin, the current WG chair Alia Atlas, and others
	the IETF77 RTGWG meeting.		provided valuable guidance prior to and at the IETF77 RTGWG meeting.
	Tony Li and John Drake have made numerous valuable comments on the		Tony Li and John Drake have made numerous valuable comments on the
	RTGWG mailing list that are reflected in versions following the		RTGWG mailing list that are reflected in versions following the
	IETF77 meeting.		IETF77 meeting.
	Iftekhar Hussain and Kireeti Kompella made comments on the RTGWG		Iftekhar Hussain and Kireeti Kompella made comments on the RTGWG
	mailing list after IETF82 that identified a new requirement.		mailing list after IETF82 that identified a new requirement.
	Iftekhar Hussain made numerous valuable comments on the RTGWG mailing		Iftekhar Hussain made numerous valuable comments on the RTGWG mailing
	list that resulted in improvements to document clarity.		list that resulted in improvements to document clarity.
	skipping to change at page 16, line 4 ¶		skipping to change at page 16, line 15 ¶
	Verizon		Verizon
	22001 Loudoun County PKWY		22001 Loudoun County PKWY
	Ashburn, VA 20147		Ashburn, VA 20147
	Email: dave.mcdysan@verizon.com		Email: dave.mcdysan@verizon.com
	So Ning		So Ning
	Tata Communications		Tata Communications
	Email: ning.so@tatacommunications.com		Email: ning.so@tatacommunications.com
	Andrew Malis		Andrew Malis
	Verizon		Verizon
	117 West St.		117 West St.
	Waltham, MA 02451		Waltham, MA 02451
	Phone: +1 781-466-2362		Phone: +1 781-466-2362
	Email: andrew.g.malis@verizon.com		Email: andrew.g.malis@verizon.com
	Lucy Yong		Lucy Yong
	Huawei USA		Huawei USA
	1700 Alma Dr. Suite 500		5340 Legacy Dr.
	Plano, TX 75075		Plano, TX 75025
	Phone: +1 469-229-5387		Phone: +1 469-277-5837
	Email: lucyyong@huawei.com		Email: lucy.yong@huawei.com
End of changes. 29 change blocks.
	50 lines changed or deleted		72 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/