< draft-ietf-rtgwg-cl-requirement-07.txt		draft-ietf-rtgwg-cl-requirement-08.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 22, 2012 Verizon		Expires: February 13, 2013 Verizon
	S. Ning		S. Ning
	Tata Communications		Tata Communications
	A. Malis		A. Malis
	Verizon		Verizon
	L. Yong		L. Yong
	Huawei USA		Huawei USA
	June 20, 2012		August 12, 2012
	Requirements for MPLS Over a Composite Link		Requirements for MPLS Over a Composite Link
	draft-ietf-rtgwg-cl-requirement-07		draft-ietf-rtgwg-cl-requirement-08
	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 22, 2012.		This Internet-Draft will expire on February 13, 2013.
	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 5, line 36 ¶		skipping to change at page 5, line 36 ¶
	Flow identification: The label stack and other information that		Flow identification: The label stack and other information that
	uniquely identifies a flow. Other information in flow		uniquely identifies a flow. Other information in flow
	identification may include an IP header, PW control word,		identification may include an IP header, PW control word,
	Ethernet MAC address, etc. Note that an LSP may contain one or		Ethernet MAC address, etc. Note that an LSP may contain one or
	more Flows or an LSP may be equivalent to a Flow. Flow		more Flows or an LSP may be equivalent to a Flow. Flow
	identification is used to locally select a component link, or a		identification is used to locally select a component link, or a
	path through the network toward the destination.		path through the network toward the destination.
	Network Performance Objective (NPO): Numerical values for		Network Performance Objective (NPO): Numerical values for
	performance measures, principally availability, latency, and		performance measures, principally availability, latency, and
	delay variation. See [I-D.symmvo-rtgwg-cl-use-cases] for more		delay variation. See [I-D.ietf-rtgwg-cl-use-cases] for more
	details.		details.
	4. Network Operator Functional Requirements		4. Network Operator Functional Requirements
	The Functional Requirements in this section are grouped in		The Functional Requirements in this section are grouped in
	subsections starting with the highest priority.		subsections starting with the highest priority.
	4.1. Availability, Stability and Transient Response		4.1. Availability, Stability and Transient Response
	Limiting the period of unavailability in response to failures or		Limiting the period of unavailability in response to failures or
	transient events is extremely important as well as maintaining		transient events is extremely important as well as maintaining
	stability. The transient period between some service disrupting		stability. The transient period between some service disrupting
	event and the convergence of the routing and/or signaling protocols		event and the convergence of the routing and/or signaling protocols
	MUST occur within a time frame specified by NPO values.		MUST occur within a time frame specified by NPO values.
	[I-D.symmvo-rtgwg-cl-use-cases] provides references and a summary of		[I-D.ietf-rtgwg-cl-use-cases] provides references and a summary of
	service types requiring a range of restoration times.		service types requiring a range of restoration times.
	FR#1 The solution SHALL provide a means to summarize some routing		FR#1 The solution SHALL provide a means to summarize some routing
	advertisements regarding the characteristics of a composite		advertisements regarding the characteristics of a composite
	link such that the routing protocol converges within the		link such that the routing protocol converges within the
	timeframe needed to meet the network performance objective. A		timeframe needed to meet the network performance objective. A
	composite link CAN be announced in conjunction with detailed		composite link CAN be announced in conjunction with detailed
	parameters about its component links, such as bandwidth and		parameters about its component links, such as bandwidth and
	latency. The composite link SHALL behave as a single IGP		latency. The composite link SHALL behave as a single IGP
	adjacency.		adjacency.
	skipping to change at page 6, line 36 ¶		skipping to change at page 6, line 36 ¶
	in a manner similar to that of current networks without any		in a manner similar to that of current networks without any
	composite link protocol enhancements when the characteristics		composite link protocol enhancements when the characteristics
	of the individual component links are advertised.		of the individual component links are advertised.
	FR#4 If extensions to existing protocols are specified and/or new		FR#4 If extensions to existing protocols are specified and/or new
	protocols are defined, then the solution SHOULD provide a means		protocols are defined, then the solution SHOULD provide a means
	for a network operator to migrate an existing deployment in a		for a network operator to migrate an existing deployment in a
	minimally disruptive manner.		minimally disruptive manner.
	FR#5 Any automatic LSP routing and/or load balancing solutions MUST		FR#5 Any automatic LSP routing and/or load balancing solutions MUST
	not oscillate such that performance observed by users changes		NOT oscillate such that performance observed by users changes
	such that an NPO is violated. Since oscillation may cause		such that an NPO is violated. Since oscillation may cause
	reordering, there MUST be means to control the frequency of		reordering, there MUST be means to control the frequency of
	changing the component link over which a flow is placed.		changing the component link over which a flow is placed.
	FR#6 Management and diagnostic protocols MUST be able to operate		FR#6 Management and diagnostic protocols MUST be able to operate
	over composite links.		over composite links.
	Existing scaling techniques used in MPLS networks apply to MPLS		Existing scaling techniques used in MPLS networks apply to MPLS
	networks which support Composite Links. Scalability and stability		networks which support Composite Links. Scalability and stability
	are covered in more detail in [I-D.so-yong-rtgwg-cl-framework].		are covered in more detail in [I-D.ietf-rtgwg-cl-framework].
	4.2. Component Links Provided by Lower Layer Networks		4.2. Component Links Provided by Lower Layer Networks
	Case 3 as defined in [ITU-T.G.800] involves a component link		Case 3 as defined in [ITU-T.G.800] involves a component link
	supporting an MPLS layer network over another lower layer network		supporting an MPLS layer network over another lower layer network
	(e.g., circuit switched or another MPLS network (e.g., MPLS-TP)).		(e.g., circuit switched or another MPLS network (e.g., MPLS-TP)).
	The lower layer network may change the latency (and/or other		The lower layer network may change the latency (and/or other
	performance parameters) seen by the MPLS layer network. Network		performance parameters) seen by the MPLS layer network. Network
	Operators have NPOs of which some components are based on performance		Operators have NPOs of which some components are based on performance
	parameters. Currently, there is no protocol for the lower layer		parameters. Currently, there is no protocol for the lower layer
	skipping to change at page 7, line 50 ¶		skipping to change at page 7, line 50 ¶
	"preempted LSPs" may not be restored if there is no		"preempted LSPs" may not be restored if there is no
	uncongested path in the network.		uncongested path in the network.
	The intent is to measure the predominant latency in uncongested		The intent is to measure the predominant latency in uncongested
	service provider networks, where geographic delay dominates and is on		service provider networks, where geographic delay dominates and is on
	the order of milliseconds or more. The argument for including		the order of milliseconds or more. The argument for including
	queuing delay is that it reflects the delay experienced by		queuing delay is that it reflects the delay experienced by
	applications. The argument against including queuing delay is that		applications. The argument against including queuing delay is that
	it if used in routing decisions it can result in routing instability.		it if used in routing decisions it can result in routing instability.
	This tradeoff is discussed in detail in		This tradeoff is discussed in detail in
	[I-D.so-yong-rtgwg-cl-framework].		[I-D.ietf-rtgwg-cl-framework].
	4.3. Parallel Component Links with Different Characteristics		4.3. Parallel Component Links with Different Characteristics
	Corresponding to Case 1 of [ITU-T.G.800], as one means to provide		Corresponding to Case 1 of [ITU-T.G.800], as one means to provide
	high availability, network operators deploy a topology in the MPLS		high availability, network operators deploy a topology in the MPLS
	network using lower layer networks that have a certain degree of		network using lower layer networks that have a certain degree of
	diversity at the lower layer(s). Many techniques have been developed		diversity at the lower layer(s). Many techniques have been developed
	to balance the distribution of flows across component links that		to balance the distribution of flows across component links that
	connect the same pair of nodes. When the path for a flow can be		connect the same pair of nodes. When the path for a flow can be
	chosen from a set of candidate nodes connected via composite links,		chosen from a set of candidate nodes connected via composite links,
	other techniques have been developed. Refer to the Appendices in		other techniques have been developed. Refer to the Appendices in
	[I-D.symmvo-rtgwg-cl-use-cases] for a description of existing		[I-D.ietf-rtgwg-cl-use-cases] for a description of existing
	techniques and a set of references.		techniques and a set of references.
	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
	skipping to change at page 11, line 11 ¶		skipping to change at page 11, line 11 ¶
	Examples of advertisement update triggering events to be		Examples of advertisement update triggering events to be
	considered include: LSP establishment/release, changes in		considered include: LSP establishment/release, changes in
	component link characteristics (e.g., latency, up/down state),		component link characteristics (e.g., latency, up/down state),
	and/or bandwidth utilization.		and/or bandwidth utilization.
	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
	skipping to change at page 13, line 31 ¶		skipping to change at page 13, line 31 ¶
	10.2. Informative References		10.2. Informative References
	[I-D.ietf-l2vpn-vpms-frmwk-requirements]		[I-D.ietf-l2vpn-vpms-frmwk-requirements]
	Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D.,		Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D.,
	and L. Jin, "Framework and Requirements for Virtual		and L. Jin, "Framework and Requirements for Virtual
	Private Multicast Service (VPMS)",		Private Multicast Service (VPMS)",
	draft-ietf-l2vpn-vpms-frmwk-requirements-04 (work in		draft-ietf-l2vpn-vpms-frmwk-requirements-04 (work in
	progress), July 2011.		progress), July 2011.
	[I-D.so-yong-rtgwg-cl-framework]		[I-D.ietf-rtgwg-cl-framework]
	So, N., McDysan, D., Osborne, E., Yong, L., and C.		Ning, S., McDysan, D., Osborne, E., Yong, L., and C.
	Villamizar, "Composite Link Framework in Multi Protocol		Villamizar, "Composite Link Framework in Multi Protocol
	Label Switching (MPLS)",		Label Switching (MPLS)", draft-ietf-rtgwg-cl-framework-01
	draft-so-yong-rtgwg-cl-framework-05 (work in progress),		(work in progress), August 2012.
	March 2012.
	[I-D.symmvo-rtgwg-cl-use-cases]		[I-D.ietf-rtgwg-cl-use-cases]
	Malis, A., Villamizar, C., McDysan, D., Yong, L., and N.		Ning, S., Malis, A., McDysan, D., Yong, L., and C.
	So, "Composite Link USe Cases and Design Considerations",		Villamizar, "Composite Link Use Cases and Design
	draft-symmvo-rtgwg-cl-use-cases-00 (work in progress),		Considerations", draft-ietf-rtgwg-cl-use-cases-01 (work in
	February 2012.		progress), August 2012.
	[ITU-T.G.800]		[ITU-T.G.800]
	ITU-T, "Unified functional architecture of transport		ITU-T, "Unified functional architecture of transport
	networks", 2007, <http://www.itu.int/rec/T-REC-G/		networks", 2007, <http://www.itu.int/rec/T-REC-G/
	recommendation.asp?parent=T-REC-G.800>.		recommendation.asp?parent=T-REC-G.800>.
	[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol		[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
	Label Switching Architecture", RFC 3031, January 2001.		Label Switching Architecture", RFC 3031, January 2001.
	[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,		[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
End of changes. 14 change blocks.
	21 lines changed or deleted		20 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/