< draft-fuxh-mpls-delay-loss-rsvp-te-ext-00.txt		draft-fuxh-mpls-delay-loss-rsvp-te-ext-01.txt >
	Network Working Group X. Fu		Network Working Group X. Fu
	Internet-Draft M. Betts		Internet-Draft M. Betts
	Intended status: Standards Track Q. Wang		Intended status: Standards Track Q. Wang
	Expires: April 23, 2012 ZTE		Expires: May 16, 2012 ZTE
	D. McDysan		D. McDysan
	A. Malis		A. Malis
	Verizon		Verizon
	V. Manral		V. Manral
	Hewlett-Packard Corp.		Hewlett-Packard Corp.
	October 21, 2011		November 13, 2011
	RSVP-TE extensions for services aware MPLS		RSVP-TE extensions for services aware MPLS
	draft-fuxh-mpls-delay-loss-rsvp-te-ext-00		draft-fuxh-mpls-delay-loss-rsvp-te-ext-01
	Abstract		Abstract
	With more and more enterprises using cloud based services, the		With more and more enterprises using cloud based services, the
	distances between the user and the applications are growing. For		distances between the user and the applications are growing. For
	multiple applications such as High Performance Computing and		multiple applications such as High Performance Computing and
	Electronic Financial markets, the response times are critical as is		Electronic Financial markets, the response times are critical as is
	packet loss, while other applications require more throughput. For		packet loss, while other applications require more throughput. For
	example, financial or trading companies are very focused on end-to-		example, financial or trading companies are very focused on end-to-
	end private pipe line latency optimizations that improve things 2-3		end private pipe line latency optimizations that improve things 2-3
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 23, 2012.		This Internet-Draft will expire on May 16, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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
	skipping to change at page 2, line 33 ¶		skipping to change at page 2, line 33 ¶
	2.1.1. Latency Accumulation Object . . . . . . . . . . . . . 4		2.1.1. Latency Accumulation Object . . . . . . . . . . . . . 4
	2.1.1.1. Latency Accumulation sub-TLV . . . . . . . . . . . 5		2.1.1.1. Latency Accumulation sub-TLV . . . . . . . . . . . 5
	2.1.2. Required Latency Object . . . . . . . . . . . . . . . 6		2.1.2. Required Latency Object . . . . . . . . . . . . . . . 6
	2.1.3. Signaling Procedures . . . . . . . . . . . . . . . . . 7		2.1.3. Signaling Procedures . . . . . . . . . . . . . . . . . 7
	3. Performance SLA Parameters Conveying . . . . . . . . . . . . . 8		3. Performance SLA Parameters Conveying . . . . . . . . . . . . . 8
	3.1. Signaling Extensions . . . . . . . . . . . . . . . . . . . 9		3.1. Signaling Extensions . . . . . . . . . . . . . . . . . . . 9
	3.1.1. Latency SLA Parameters subobject . . . . . . . . . . . 9		3.1.1. Latency SLA Parameters subobject . . . . . . . . . . . 9
	3.1.2. Signaling Procedure . . . . . . . . . . . . . . . . . 12		3.1.2. Signaling Procedure . . . . . . . . . . . . . . . . . 12
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 12		4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	6.1. Normative References . . . . . . . . . . . . . . . . . . . 13		6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
	6.2. Informative References . . . . . . . . . . . . . . . . . . 13		6.2. Informative References . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	End-to-end service optimization based on latency is a key requirement		End-to-end service optimization based on latency is a key requirement
	for service provider. It needs to communicate latency of links and		for service provider. It needs to communicate latency of links and
	nodes including latency and latency variation as a traffic		nodes including latency and latency variation as a traffic
	engineering performance metric is a very important requirement.		engineering performance metric is a very important requirement.
	[LATENCY-REQ] describes the requirement of latency traffic		[LATENCY-REQ] describes the requirement of latency traffic
	skipping to change at page 10, line 8 ¶		skipping to change at page 9, line 44 ¶
	specified in this subobject.		specified in this subobject.
	This Latency SLA Parameters ERO subobject has the following format.		This Latency SLA Parameters ERO subobject has the following format.
	It follows a subobject containing the IP address, or the link		It follows a subobject containing the IP address, or the link
	identifier [RFC3477], associated with the TE link on which it is to		identifier [RFC3477], associated with the TE link on which it is to
	be used.		be used.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type(IANA) | Length |		|L| Type | Length |I|V| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|I|V| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Request Maximum Acceptable Latency Value |		| Request Maximum Acceptable Latency Value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Request Maximum Acceptable Latency Variation Value |		| Request Maximum Acceptable Latency Variation Value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4: Format of Latency SLA Parameters TLV		Figure 4: Format of Latency SLA Parameters TLV
	o I bit: a one bit field indicates whether a traffic flow shall		o I bit: a one bit field indicates whether a traffic flow shall
	select a component link with the minimum latency value or not. It		select a component link with the minimum latency value or not. It
	skipping to change at page 12, line 41 ¶		skipping to change at page 12, line 25 ¶
	value) from Latency SLA Parameters ERO subobject. This node used		value) from Latency SLA Parameters ERO subobject. This node used
	these latency parameters for FA selection, FA-LSP creation or		these latency parameters for FA selection, FA-LSP creation or
	component link selection.		component link selection.
	If the intermediate node couldn't support the latency SLA, it MUST		If the intermediate node couldn't support the latency SLA, it MUST
	generate a PathErr message with a "Latency SLA unsupported"		generate a PathErr message with a "Latency SLA unsupported"
	indication (TBD by IANA). If the intermediate node couldn't select a		indication (TBD by IANA). If the intermediate node couldn't select a
	FA or component link, or create a FA-LSP which meet the latency		FA or component link, or create a FA-LSP which meet the latency
	constraint defined in Latency SLA Parameters ERO subobject, it must		constraint defined in Latency SLA Parameters ERO subobject, it must
	generate a PathErr message with a "Latency SLA parameters couldn't be		generate a PathErr message with a "Latency SLA parameters couldn't be
	met" indication (TBD by IANA).		met" indication (TBD by IANA). These errors SHOULD also be generated
			if the node or the link were in unusable state for that particular
			service parameter.
	4. Security Considerations		4. Security Considerations
	This document raises no new security issues.		This document raises no new security issues.
	5. IANA Considerations		5. IANA Considerations
	TBD		TBD
	6. References		6. References
End of changes. 7 change blocks.
	10 lines changed or deleted		10 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/