< draft-atlas-mpls-te-express-path-00.txt		draft-atlas-mpls-te-express-path-01.txt >
	MPLS Working Group A. Atlas		MPLS Working Group A. Atlas
	Internet-Draft J. Drake		Internet-Draft J. Drake
	Intended status: Informational D. Ward		Intended status: Informational Juniper Networks
	Expires: April 26, 2012 Juniper Networks		Expires: December 27, 2012 S. Giacalone
	S. Giacalone
	Thomson Reuters		Thomson Reuters
			D. Ward
	S. Previdi		S. Previdi
	C. Filsfils		C. Filsfils
	Cisco Systems		Cisco Systems
	October 24, 2011		June 25, 2012
	Performance-based Path Selection for Explicitly Routed LSPs		Performance-based Path Selection for Explicitly Routed LSPs
	draft-atlas-mpls-te-express-path-00		draft-atlas-mpls-te-express-path-01
	Abstract		Abstract
	In certain networks, it is critical to consider network performance		In certain networks, it is critical to consider network performance
	criteria when selecting the path for an explicitly routed RSVP-TE		criteria when selecting the path for an explicitly routed RSVP-TE
	LSP. Such performance criteria can include latency, jitter, and loss		LSP. Such performance criteria can include latency, jitter, and loss
	or other indications such as the conformance to link SLAs and non-		or other indications such as the conformance to link SLAs and non-
	RSVP TE traffic load. This specification uses IGP extension data		RSVP TE traffic load. This specification uses IGP extension data
	(which is defined outside the scope of this document) to perform such		(which is defined outside the scope of this document) to perform such
	path selections.		path selections.
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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 April 26, 2012.		This Internet-Draft will expire on December 27, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	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.
	1. Introduction		1. Introduction
	In certain networks, such as financial information networks, network		In certain networks, such as financial information networks, network
	performance information is becoming as critical to data path		performance information is becoming as critical to data path
	selection as other existing metrics. The ability to distribute		selection as other existing metrics. The ability to distribute
	network performance information in OSPF		network performance information in OSPF
	[I-D.giacalone-ospf-te-express-path] and in ISIS		[I-D.ietf-ospf-te-metric-extensions] and in ISIS
	[I-D.previdi-isis-te-metric-extensions] is being defined (outside the		[I-D.previdi-isis-te-metric-extensions] is being defined (outside the
	scope of this document). This document describes how to use that		scope of this document). This document describes how to use that
	information for path selection for explicitly routed LSPs signaled		information for path selection for explicitly routed LSPs signaled
	via RSVP-TE [RFC3209].		via RSVP-TE [RFC3209]. The method suggested is not optimal for both
			minimizing path cost and additional constraints, such as latency;
			optimal solutions are computationally complex.
	The path selection mechanisms described in this document apply to		The path selection mechanisms described in this document apply to
	paths that are fully computed by the head-end of the LSP and then		paths that are fully computed by the head-end of the LSP and then
	signaled in an ERO where every sub-object is strict. This allows the		signaled in an ERO where every sub-object is strict. This allows the
	head-end to consider IGP-distributed performance data without		head-end to consider IGP-distributed performance data without
	requiring the ability to signal the performance constraints in an		requiring the ability to signal the performance constraints in an
	object of the RSVP Path message.		object of the RSVP Path message.
	When considering performance-based data, it is obvious that there are		When considering performance-based data, it is obvious that there are
	additional contributors beyond just the links. Clearly end-to-end		additional contributors beyond just the links. Clearly end-to-end
	skipping to change at page 3, line 37 ¶		skipping to change at page 3, line 37 ¶
	performance would still meet requirements.		performance would still meet requirements.
	7. Ability to revert back to the best path after a configurable		7. Ability to revert back to the best path after a configurable
	period.		period.
	2. Using Performance Data Constraints		2. Using Performance Data Constraints
	2.1. End-to-End Constraints		2.1. End-to-End Constraints
	The per-link performance data available in the IGP		The per-link performance data available in the IGP
	[I-D.giacalone-ospf-te-express-path]		[I-D.ietf-ospf-te-metric-extensions]
	[I-D.previdi-isis-te-metric-extensions] includes: unidirectional link		[I-D.previdi-isis-te-metric-extensions] includes: unidirectional link
	delay, unidirectional delay variation, and link loss. Each (or all)		delay, unidirectional delay variation, and link loss. Each (or all)
	of these parameters can be used to create the path-level link-based		of these parameters can be used to create the path-level link-based
	parameter.		parameter.
	While it has been possible to compute a CSPF where the link latency		While it has been possible to compute a CSPF where the link latency
	values are used instead of TE metrics, this results in ignoring the		values are used instead of TE metrics, this results in ignoring the
	TE metrics and causing LSPs to prefer the lowest-latency paths.		TE metrics and causing LSPs to prefer the lowest-latency paths.
	Instead of this approach to minimize path latency, an end-to-end		Instead of this approach to minimize path latency, an end-to-end
	latency bound merely requires that the path computed be no more than		latency bound merely requires that the path computed be no more than
	skipping to change at page 4, line 40 ¶		skipping to change at page 4, line 40 ¶
	fixed value, then resource attribute flags could be used to express		fixed value, then resource attribute flags could be used to express
	this behavior. However, when the parameter associated with a link		this behavior. However, when the parameter associated with a link
	may vary dynamically, there is not currently a configuration-time		may vary dynamically, there is not currently a configuration-time
	mechanism to enforce such behavior. An example of this is described		mechanism to enforce such behavior. An example of this is described
	in Section 2.3, where links may move in and out of SLA-conformance		in Section 2.3, where links may move in and out of SLA-conformance
	with regards to latency, delay variation, and link loss.		with regards to latency, delay variation, and link loss.
	When doing path selection for TE tunnels, it has not been possible to		When doing path selection for TE tunnels, it has not been possible to
	know how much actual bandwidth is available that inludes the		know how much actual bandwidth is available that inludes the
	bandwidth used by non-RSVP-TE traffic. In		bandwidth used by non-RSVP-TE traffic. In
	[I-D.giacalone-ospf-te-express-path]		[I-D.ietf-ospf-te-metric-extensions]
	[I-D.previdi-isis-te-metric-extensions], the Unidirectional Available		[I-D.previdi-isis-te-metric-extensions], the Unidirectional Available
	Bandwidth is advertised as is the Residual Bandwidth. When computing		Bandwidth is advertised as is the Residual Bandwidth. When computing
	the path for a TE tunnel, only links with at least a configurable		the path for a TE tunnel, only links with at least a configurable
	amount of Unidirectional Available Bandwidth might be permitted.		amount of Unidirectional Available Bandwidth might be permitted.
	Similarly, only links whose loss is under a configurable value might		Similarly, only links whose loss is under a configurable value might
	be acceptable. For these constraints, each link can be tested		be acceptable. For these constraints, each link can be tested
	against the constraint and only explored in the CSPF if the link		against the constraint and only explored in the CSPF if the link
	passes. In essence, a link that fails the constraint test is treated		passes. In essence, a link that fails the constraint test is treated
	as if it contained a resource attribute in the exclude-any filter.		as if it contained a resource attribute in the exclude-any filter.
	skipping to change at page 5, line 24 ¶		skipping to change at page 5, line 24 ¶
	b. Should LSPs using this link be immediately verified for continued		b. Should LSPs using this link be immediately verified for continued
	compliance to their end-to-end constraints?		compliance to their end-to-end constraints?
	c. Should LSPs using this link automatically be moved to a secondary		c. Should LSPs using this link automatically be moved to a secondary
	path?		path?
	2.3.1. Use of Anomalous Links for New Paths		2.3.1. Use of Anomalous Links for New Paths
	If the answer to (a) is no for latency SLAs, then any link which has		If the answer to (a) is no for latency SLAs, then any link which has
	the Anomalous bit set in the Unidirectional Link Delay sub-		the Anomalous bit set in the Unidirectional Link Delay sub-
	TLV[I-D.giacalone-ospf-te-express-path]		TLV[I-D.ietf-ospf-te-metric-extensions]
	[I-D.previdi-isis-te-metric-extensions] should be removed from the		[I-D.previdi-isis-te-metric-extensions] should be removed from the
	topology before a CSPF calculation is used to compute a new path. In		topology before a CSPF calculation is used to compute a new path. In
	essence, the link should be treated exactly as if it fails the		essence, the link should be treated exactly as if it fails the
	exclude-any resource attributes filter.[RFC3209].		exclude-any resource attributes filter.[RFC3209].
	Similarly, if the answer to (a) is no for link loss SLAs, then any		Similarly, if the answer to (a) is no for link loss SLAs, then any
	link which has the Anomalous bit set in the Link Los sub-TLV should		link which has the Anomalous bit set in the Link Los sub-TLV should
	be treated as if it fails the exclude-any resource attributes filter.		be treated as if it fails the exclude-any resource attributes filter.
	If the answer to (a) is no for jitter SLAs, then any link that has		If the answer to (a) is no for jitter SLAs, then any link that has
	the Anomalous bit set in the Unidirectional Delay Variation sub-		the Anomalous bit set in the Unidirectional Delay Variation sub-
	skipping to change at page 6, line 32 ¶		skipping to change at page 6, line 32 ¶
	4. Security Considerations		4. Security Considerations
	This document is not currently believed to introduce new security		This document is not currently believed to introduce new security
	concerns.		concerns.
	5. References		5. References
	5.1. Normative References		5.1. Normative References
	[I-D.giacalone-ospf-te-express-path]		[I-D.ietf-ospf-te-metric-extensions]
	Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.		Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
	Previdi, "OSPF Traffic Engineering (TE) Express Path",		Previdi, "OSPF Traffic Engineering (TE) Metric
	draft-giacalone-ospf-te-express-path-02 (work in		Extensions", draft-ietf-ospf-te-metric-extensions-01 (work
	progress), September 2011.		in progress), May 2012.
	[I-D.previdi-isis-te-metric-extensions]		[I-D.previdi-isis-te-metric-extensions]
	Previdi, S., Giacalone, S., Ward, D., Drake, J., Atlas,		Previdi, S., Giacalone, S., Ward, D., Drake, J., Atlas,
	A., and C. Filsfils, "IS-IS Traffic Engineering (TE)		A., and C. Filsfils, "IS-IS Traffic Engineering (TE)
	Metric Extensions",		Metric Extensions",
	draft-previdi-isis-te-metric-extensions-00 (work in		draft-previdi-isis-te-metric-extensions-01 (work in
	progress), October 2011.		progress), March 2012.
	[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,		[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
	and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP		and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
	Tunnels", RFC 3209, December 2001.		Tunnels", RFC 3209, December 2001.
	5.2. Informative References		5.2. Informative References
	[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,		[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
	J., Courtney, W., Davari, S., Firoiu, V., and D.		J., Courtney, W., Davari, S., Firoiu, V., and D.
	Stiliadis, "An Expedited Forwarding PHB (Per-Hop		Stiliadis, "An Expedited Forwarding PHB (Per-Hop
	skipping to change at page 7, line 35 ¶		skipping to change at page 7, line 35 ¶
	Email: akatlas@juniper.net		Email: akatlas@juniper.net
	John Drake		John Drake
	Juniper Networks		Juniper Networks
	1194 N. Mathilda Ave.		1194 N. Mathilda Ave.
	Sunnyvale, CA 94089		Sunnyvale, CA 94089
	USA		USA
	Email: jdrake@juniper.net		Email: jdrake@juniper.net
	Dave Ward
	Juniper Networks
	1194 N. Mathilda Ave.
	Sunnyvale, CA 94089
	USA
	Email: dward@juniper.net
	Spencer Giacalone		Spencer Giacalone
	Thomson Reuters		Thomson Reuters
	195 Broadway		195 Broadway
	New York, NY 10007		New York, NY 10007
	USA		USA
	Email: Spencer.giacalone@thomsonreuters.com		Email: Spencer.giacalone@thomsonreuters.com
			Dave Ward
			Cisco Systems
			170 West Tasman Dr.
			San Jose, CA 95134
			USA
			Email: dward@cisco.com
	Stefano Previdi		Stefano Previdi
	Cisco Systems		Cisco Systems
	Via Del Serafico 200		Via Del Serafico 200
	Rome 00142		Rome 00142
	Italy		Italy
	Email: sprevidi@cisco.com		Email: sprevidi@cisco.com
	Clarence Filsfils		Clarence Filsfils
End of changes. 16 change blocks.
	25 lines changed or deleted		27 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/