< draft-wang-ccamp-latency-te-metric-01.txt		draft-wang-ccamp-latency-te-metric-02.txt >
	Network Working Group Q. Wang		Network Working Group X. Fu
	Internet-Draft X. Fu		Internet-Draft M. Betts
	Intended status: Standards Track ZTE Corporation		Intended status: Standards Track Q. Wang
	Expires: April 28, 2011 Oct 25, 2010		Expires: August 21, 2011 ZTE Corporation
			February 17, 2011
	GMPLS extensions to communicate latency as a TE performance metric		GMPLS extensions to communicate latency as a traffic engineering
	draft-wang-ccamp-latency-te-metric-01		performance metric
			draft-wang-ccamp-latency-te-metric-02
	Abstract		Abstract
	Latency is such requirement that must be achieved according to the		Latency is such requirement that must be achieved according to the
	SLA signed between customers and service providers, so mechanism is		Service Level Agreement (SLA) between customers and service
	needed to collect, compute and identify the latency by signaling and		providers. A SLA is a part of a service contract where the level of
	routing protocol.		service is formally defined between service providers and customers.
			For example, the service level includes platinum, golden, silver and
			bronze. Different service level may associate with different
			protection/restoration requirement. Latency can also be associated
			with different service level. The user may select a private line
			provider based on the ability to meet a latency SLA.
	This document describes the requirement and method to compute and		The key driver for latency is stock/commodity trading applications
	identify the latency by control plane in today's network which is		that use data base mirroring. A few milli seconds can impact a
	consisted of packet transport network and optical transport network		transaction. Financial or trading companies are very focused on end-
	in order to meet the latency SLA of the customer. This document also		to-end private pipe line latency optimizations that improve things
	describes RSVP-TE signaling and OSPF routing extensions needed to		2-3 ms. Latency and latency SLA is one of the key parameters that
	support the computation and identification of latency. These		these "high value" customers use to select a private pipe line
	extensions are intended to advertise and convey the information of		provider. Other key applications like video gaming, conferencing and
	node latency and link latency as TE performance metric.		storage area networks require stringent latency and bandwidth.
			This document describes the requirements and mechanisms to
			communicate latency as a traffic engineering performance metric in
			today's network which is consisting of potentially multiple layers of
			packet transport network and optical transport network in order to
			meet the latency SLA between service provider and his customers.
			This document also extends RSVP-TE and IGP to support these
			requirement. These extensions are intended to advertise and convey
			the latency information of nodes and links as traffic engineering
			performance metric.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 28, 2011.		This Internet-Draft will expire on August 21, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 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
	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.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Conventions Used in This Document . . . . . . . . . . . . 4		1.1. Conventions Used in This Document . . . . . . . . . . . . 5
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Identification of Requirements . . . . . . . . . . . . . . . . 5
	2.1. List of Acronyms . . . . . . . . . . . . . . . . . . . . . 5		3. Control Plane Solution . . . . . . . . . . . . . . . . . . . . 9
	3. Analysis of the Latency Measurement Mechanism . . . . . . . . 5		3.1. Latency Advertisement . . . . . . . . . . . . . . . . . . 9
	3.1. Support of SLA . . . . . . . . . . . . . . . . . . . . . . 6		3.1.1. Routing Extensions . . . . . . . . . . . . . . . . . . 10
	3.2. Latency Value . . . . . . . . . . . . . . . . . . . . . . 6		3.1.1.1. OSPF-TE Extension . . . . . . . . . . . . . . . . 10
	3.3. Latency of Server Layer Network . . . . . . . . . . . . . 7		3.1.1.2. IS-IS-TE Extension . . . . . . . . . . . . . . . . 10
	3.4. Role of the Control Plane . . . . . . . . . . . . . . . . 7		3.2. Latency SLA Parameters Conveying . . . . . . . . . . . . . 10
	3.5. Impact of the Change of Link Latency . . . . . . . . . . . 8		3.2.1. Signaling Extensions . . . . . . . . . . . . . . . . . 10
	4. A New Latency Measurement Mechanism . . . . . . . . . . . . . 8		3.2.1.1. Latency SLA Parameters ERO subobject . . . . . . . 11
	4.1. Advertisement of the Latency Value . . . . . . . . . . . . 8		3.2.1.2. Signaling Procedure . . . . . . . . . . . . . . . 12
	4.2. Latency Collection and Verification . . . . . . . . . . . 9		3.3. Latency Accumulation and Verification . . . . . . . . . . 12
	5. Signaling and Routing Extensions to Support Latency		3.3.1. Signaling Extensions . . . . . . . . . . . . . . . . . 12
	Measurement . . . . . . . . . . . . . . . . . . . . . . . . . 9		3.3.1.1. Latency Accumulation Object . . . . . . . . . . . 12
	5.1. Routing Extensions to Support the Advertisement of		3.3.1.2. Latency Accumulation sub-TLV . . . . . . . . . . . 13
	Latency . . . . . . . . . . . . . . . . . . . . . . . . . 10		3.3.1.3. Signaling Procedures . . . . . . . . . . . . . . . 14
	5.2. Signaling Extensions to Support the Latency Measurement . 11		4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 11		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		6.1. Normative References . . . . . . . . . . . . . . . . . . . 15
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 12		6.2. Informative References . . . . . . . . . . . . . . . . . . 16
	8.2. Informative References . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	In a network, latency, a synonym for delay, is an expression of how		In a network, latency, a synonym for delay, is an expression of how
	much time it takes for a packet of data to get from one designated		much time it takes for a packet/frame of data to get from one
	point to another. In some usages, latency is measured by sending a		designated point to another. In some usages, latency is measured by
	packet that is returned to the sender and the round-trip time is		sending a packet/frame that is returned to the sender and the round-
	considered the latency. In this document, we refer to the former		trip time is considered the latency of bidirectional co-routed or
	expression.		associated LSP. One way time is considered as the latency of
			unidirectional LSP. The one way latency may not be half of the
			round-trip latency in the case that the transmit and receive
			directions of the path are of unequal lengths.
			Latency on a connection has two sources: Node latency which is caused
			by the node as a result of process time in each node and: Link
			latency as a result of packet/frame transit time between two
			neighbouring nodes or a FA-LSP/Composit Link [CL-REQ]. Latency
			variation is a parameter that is used to indicate the variation range
			of the latency value. These values should be made available to the
			control plane and management plane prior to path computation. This
			allows path computation to select a path that will meet the latency
			SLA.
	In many cases, latency is a sensitive topic. For example, two stock		In many cases, latency is a sensitive topic. For example, two stock
	exchanges, one in Beijing, which is a city of north China and another		exchanges (e.g.,one in Chicago and another in New York) need to
	in Shenzhen, which is a city of south China. Both of them need to		communicate with each other. A few ms can result in large impact on
	synchronize with each other. A little change may result in large		service. Some customers would pay for the latency performance. SLA
	loss. So something SHOULD be assured that the network path latency		contract which includes the requirement of latency is signed between
	MUST be limited to a value lower than the upper limit. SLA contract		service providers and customers. Service provider should assure that
	which includes the requirement of latency is signed between service		the network path latency MUST be limited to a value lower than the
	providers and customers. In the future, latency demand will be		upper limit. In the future, latency optimization will be needed by
	needed by more and more customers.		more and more customers. For example, some customers pay for a
			private pipe line with latency constraint (e.g., less than 10 ms)
			which connects to Data Center. If this "provisioned" latency of this
			private pipe line couldn't meet the SLA, service provider may
			transfer customer's service to other Data Centers. Service provider
			may have many layers of pre-defined restoration for this transfer,
			but they have to duplicate restoration resources at significant cost.
			So service provider needs some mechanisms to avoid the duplicate
			restoration and reduce the network cost.
	Measurement mechanism of link latency has been defined in many		Measurement mechanism for link latency has been defined in many
	technologies. For example, the measurement mechanism of link latency		technologies. For example, the measurement mechanism for link
	has been provided in ITU-T [G.8021] and [Y.1731] for Ethernet. The		latency has been provided in ITU-T [G.8021] and [Y.1731] for
	link transit latency between two Ethernet equipments can be measured		Ethernet. The link transit latency between two Ethernet equipments
	by using this mechanism. Similarly, overhead byte and measurement		can be measured by using this mechanism. Similarly, overhead byte
	mechanism of latency has been provided in OTN (i.e., ITU-T [G.709]).		and measurement mechanism of latency has been provided in OTN (i.e.,
	In order to measure the link latency between two OTN nodes, PM&TCM		ITU-T [G.709]). In order to measure the link latency between two OTN
	which include Path Latency Measurement field and flag used to		nodes, PM&TCM which include Path Latency Measurement field and flag
	indicate the beginning of measurement of latency is added to the		used to indicate the beginning of measurement of latency is added to
	overhead of ODUk. The detailed measurement mechanism of link latency		the overhead of ODUk. Node latency can also be recorded at each node
	is out of scope of this document. You can refer to ITU-T G.709 for		by recording the process time between the beginning and the end. The
	more messages. Technologies that do not support the measurement of		measurement mechanism of links and nodes is out scope of this
	latency SHOULD be developed to allow the measurement of link latency		document.
	in scenario similar to the above. This is out of scope of this
	document. Node latency can also be recorded at each node by
	recording the process time at the beginning and at the end. More
	detail of the node latency is described in section 3.2.
	Current operation and maintenance mode of latency measurement is high		Current operation and maintenance mode of latency measurement is high
	in cost and low in efficiency. Only after the path needed by the		in cost and low in efficiency. The latency can only be measured
	customers' business is determined, signal can be sent to detect		after the connection has been established, if the measurement
	whether the latency of the path fit the requirement of the customers.		indicates that the latency SLA is not met then another path is
	If not, another path SHOULD be determined by the ingress node until		computed, set up and measured. This "trial and error" process is
	one can. So a low cost and high efficiency latency measurement		very inefficient. To avoid this problem a means of making an
	method SHOULD be provided in order to support the SLA. However, the		accurate prediction of latency before a path is establish is
	control plane does not provide latency measure mechanism. A new		required.
	method is provided that the node latency, link latency and latency
	variation can be collected by control plane from the transport plane.
	Then node latency, link latency values and latency variation can be
	used by service provider through control plane to provide a path
	correspond with the customers' requirement. As there is demand from
	the customer, this method can be used to select a path correspond
	with customers' latency demand. In this document, link latency
	refers to the latency of the link between two neighbor nodes or a FA-
	LSP.
	This document describes the requirement and method to compute and
	identify the latency by control plane in today's network which is
	consisted of packet transport network and optical transport network
	in order to meet the latency SLA of the customer. This document also
	describes RSVP-TE signaling and OSPF routing extensions needed to
	support the computation and identification of latency. Latency can
	be divided into two types as described above: node latency which is
	provided by the node as a result of process time at each node and
	link latency as a result of packet traverse between two neighbor
	nodes or a FA-LSP. Latency variation is also a parameter that is
	used to indicate the variation range of the latency value.
	Extensions are also intended to advertise and convey the information
	of node latency, link latency and latency variation as TE performance
	metric.
	[RFC4203] details the OSPF extensions in support of Generalized		This document describes the requirements and mechanisms to
	Multi-Protocol Label Switching (GMPLS). In order to support the		communicate latency as a traffic engineering performance metric in
	advertisement of the attributes of the node latency, link latency and		today's network which is consisting of potentially multiple layers of
	latency variation by routing, extensions SHOULD be made to [RFC4203]		packet transport network and optical transport network in order to
	in this document. Thus ingress node that is responsible for the		meet the latency SLA between service provider and his customers.
	creation of the path will have a good knowledge of the latency of the		This document extends IGP to advertise and convey the latency
	path.		attributes and latency variation as traffic engineering performance
			metric. Thus path computation entity can have a good knowledge of
			the latency traffic engineering database.
	[RFC3473] details the Generalized Multi-Protocol Label Switching		This document extends RSVP-TE protocol to accumulate (e.g., sum)
	(GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering		latency information of links and nodes along one LSP across multi-
	(RSVP-TE) Extensions. Extensions SHOULD be made to [RFC3473] to		domain (e.g., Inter-AS, Inter-Area or Multi-Layer) so that an latency
	collect the node, link latency and latency variation along the path,		verification can be made at source node. One-way and round-trip
	so egress node can determine whether such a path is adaptive. This		latency collection along the LSP by signaling protocol can be
	extensions is not necessary unless there is a need.		supported. So the end points of this LSP can verify whether the
			total amount of latency could meet the latency agreement between
			operator and his user.
	1.1. Conventions Used in This Document		1.1. Conventions Used in This Document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Terminology		2. Identification of Requirements
	The reader is assumed to be familiar with the terminology in		End-to-end service optimization based on latency (e.g., minimum
	[RFC3473] and [RFC4203].		latency) is a key requirement for service provider. This type of
			function will be adopted by their "premium" service customers. They
			would like to pay for this "premium" service. After these premium
			services are deployed, they will also expand to their own customers.
	Frame Delay:		Following key requirements associated with latency is identified.
	The definition of Frame Delay in ITU-T Y.1731 can be seen below.
	Frame Delay can be specified as round-trip delay for a frame, where
	Frame Delay is defined as the time elapsed since the start of
	transmission of the first bit of the frame by a source node until the
	reception of the last bit of the loop backed frame by the same source
	node, when the loop back is performed at the frame's destination
	node.
	Frame Delay Variation:		o Communication latency of links and nodes including minimum latency
	The definition of Frame Delay in ITU-T [Y.1731] can be seen below.		and latency variation as a traffic engineering performance metric
	Frame Delay Variation is a measure of the variations in the Frame		is a very important requirement. The latency performance metric
	Delay between a pair of service frames.		MUST be advertised into path computation entity by IGP(etc.,
			OSPF-TE or IS-IS-TE) to perform route computation and network
			planning based on latecny SLA target. Latency characteristics of
			these links may change dynamically. In order to control IGP
			messaging and avoid being unstable when the latency and latency
			variation value changes, a threshold and a limit on rate of change
			MUST be configured to control plane.
	Path Monitoring & Tandem Connection Monitoring:		* Data plane is responsible for measuring the latency (e.g.,
	Path Monitoring & Tandem Connection Monitoring is a field contained		minimum latency and latency variation). Latency measurement
	in [G.709] OTN ODUk overhead, which can be used to support the		can be provided by different technologies. This information
	measurement of latency between two OTN nodes.		will be provided to the Control Plane. In order to monitor the
			performance, pro-active latency measurement is required.
			Generally, every 15 minutes or 24 hours, the value of latency
			and latency variation should be collected. Similarly, on
			demand latency measurement is required due to the goal of
			maintenance. This can be done every fixed time interval (e.g.,
			5 minutes or 1 hour). The method used to measure the latency
			of links and nodes is out scope of this document.
	Service Level Agreement:		* Control plane is responsible for advertising and collecting the
	A service level agreement is a part of a service contract where the		latency value of links and nodes by IGP (i.e., OSPF-TE/
	level of service is formally defined between service providers and		IS-IS-TE).
	customers.
	2.1. List of Acronyms		o End-to-end service optimization based on latency (e.g., minimum
			latency) is a key requirement for service provider. Latency on a
			route level will help carriers' customers to make his provider
			selection decision. Path computation entity MUST have the
			capability to compute one end-to-end path with latency constraint.
			For example, it MUST have the capability to compute a route with x
			amount bandwidth and less than y ms of latency limit based on the
			latency traffic engineering database. It should also support
			combined routing constraints with pre-defined priorities, e.g.,
			SRLG diversity, latency and cost.
	FD: Frame Delay		o One end-to-end LSP may be across some Composite Links [CL-REQ].
	FDV: Frame Delay Variation		Even if the transport technology (e.g., OTN) implementing the
	PM&TCM: Path Monitoring & Tandem Connection Monitoring		component links is identical, the latency characteristics of the
	SLA: Service Level Agreement		component links may differ. When the composite link is advertised
			into IGP, the latency of composite link should be the maximum
			latency value of all component links.
	3. Analysis of the Latency Measurement Mechanism		In order to assigne the LSP to one of component links with
			different latency characteristics, RSVP-TE message MUST convey
			latency SLA parameter (e.g., minimum latency) to the end points of
			Composite Links where it can select one of component links or
			trigger the creation of lower layer connection which MUST meet
			latency SLA parameter. Following related requirements are from
			[CL-REQ].
	As described in the Introduction section, latency is sensitive in		* The solution SHALL provide a means to indicate that a traffic
	many cases like finance, storage. A little frame delay may result in		flow shall select a component link with the minimum latency
	large loss. So network latency values MUST be strictly limited to a		value.
	value lower than the upper limit described in the SLA. Latency
	measurement mechanism is important to certain customers. However,
	the control plane does not provide latency measure mechanism. A
	method is provided that the node latency, link latency and latency
	variation can be collected by control plane from the latency
	measurement of the transport plane. Then node latency, link latency
	values and latency variation can be used by service provider through
	control plane to provide a path correspond with the customers'
	demand. In this document, link latency refers to the latency of the
	link between two neighbor nodes or a FA-LSP. This section analyzes
	latency support for SLA contract signed between customers and
	providers, analysis of the mechanism of latency measurement, latency
	of the server layer network and role of the control plane in this new
	latency measurement mechanism.
	3.1. Support of SLA		* The solution SHALL provide a means to indicate that a traffic
			flow shall select a component link with a maximum acceptable
			latency value as specified by protocol.
	In today's network (e.g., DWDM), latency measurement is required by		* The solution SHALL provide a means to indicate that a traffic
	many service providers because of the demand from the customers.		flow shall select a component link with a maximum acceptable
	Latency is especially important for the customers who provide service		latency variation value as specified by protocol.
	like finance, storage. As a result of the demand, SLA contract which
	includes the demand of latency is signed between service providers
	and customers. According to the definition in section 2, SLA (i.e.,
	Service Level Agreement) is a part of a service contract where the
	level of service is formally defined between service providers and
	customers. Service providers MUST provide accurate latency
	measurement result to the customers per SLA levels. Latency to
	different customers can be different per SLA levels.
	However, current operation and maintenance mode of latency		The RSVP-TE message needs to carry minimum latency, maximum
	measurement through transport plane is high in cost and low in		acceptable latency and maximum acceptable delay variation for the
	efficiency. Only after the path needed by the customers' business is		component link selection or creation. The composite link will
	determined, signal can be sent to detect whether the latency of the		take these parameters into account when assigning traffic of LSP
	path fit the requirement of the customers. A new method described in		to a component link.
	this document is provided to support a low cost and high efficiency
	latency measurement mechanism in order to support the SLA. This can
	be seen in the 4th section and 5th section.
	3.2. Latency Value		o One end-to-end LSP (e.g., in IP/MPLS or MPLS-TP network) may
			traverse a FA-LSP of server layer (e.g., OTN rings). The boundary
			nodes of the FA-LSP SHOULD be aware of the latency information of
			this FA-LSP (e.g., minimum latency and latency variation). If the
			FA-LSP is able to form a routing adjacency and/or as a TE link in
			the client network, the latency value of the FA-LSP can be as an
			input to a transformation that results in a FA traffic engineering
			metric and advertised into the client layer routing instances.
			Note that this metric will include the latency of the links and
			nodes that the trail traverses.
	The mechanism of latency measurement can be sorted into two types.		If the latency information of the FA-LSP changes (e.g., due to a
	In order to monitor the performance, pro-active latency measurement		maintenance action or failure in OTN rings), the boundary node of
	is required. Generally, every 15 minutes or 24 hours, the value of		the FA-LSP will receive the TE link information advertisement
	FD and FDV SHOULD be collected. Similarly, on demand latency		including the latency value which is already changed and if it is
	measurement is required due to the goal of maintenance. This can be		over than the threshold and a limit on rate of change, then it
	done every fixed time interval (e.g., 5 minutes or 1 hour).		will compute the total latency value of the FA-LSP again. If the
			total latency value of FA-LSP changes, the client layer MUST also
			be notified about the latest value of FA. The client layer can
			then decide if it will accept the increased latency or request a
			new path that meets the latency requirement.
	As described in [CL-REQ], when a traffic flow moves from one		When one end-to-end LSP traverse a server layer, there will be
	component link to another in the same composite link between a set of		some latency constraint requirement for the segment route in
	nodes (or sites), it MUST be processed in a minimally disruptive		server layer. So RSVP-TE message needs to carry minimum latency,
	manner. When a traffic flow moves from a current link to a target		maximum acceptable latency and maximum acceptable delay variation
	link with different latency, reordering can occur if the target link		for the FA selection or FA-LSP creation. The boundary nodes of
	latency is less than that of the current and clumping can occur if		FA-LSP will take these parameters into account for FA selection or
	target link latency is more than that of the current. Therefore, the		FA-LSP creation.
	solution SHALL provide a means to indicate that a traffic flow shall
	select a component link with the minimum latency value and a maximum
	acceptable latency value.
	Similarly, the value of latency is not fixed because of different		o Standardized measurement should be a goal for SLA validation. It
	signal process technology (The packet transport network use		is out scope of this document. RSPV-TE should support the
	statistical multiplexing and the optical transport network use time		accumulation (e.g., sum) of latency information of links and nodes
	division multiplex). For example, in statistical multiplexing		along one LSP across multi-domain (e.g., Inter-AS, Inter-Area or
	business, latency for every business may be different because of the		Multi-Layer) so that an latency validation decision can be made at
	existence of buffering and priority. At this time, average latency		the source node. One-way and round-trip latency collection along
	value is needed when refer to node latency. Average latency value of		the LSP by signaling protocol and latency verification at the end
	node can be derived through the computation of the node or management		of LSP should be supported.
	plane configuration.
	latency varation is also needed in the case the latency value of, for		o Restoration, protection and equipment variations can impact
	example, average latency value's variation range.		"provisioned" latency (e.g., latency increase). The change of one
			end-to-end LSP latency performance MUST be known by source and/or
			sink node. So it can inform the higher layer network of a latency
			change. The latency change of links and nodes will affect one
			end-to-end LSP's total amount of latency. Applications can fail
			beyond an application-specific threshold. Some remedy mechanism
			could be used.
	Measurement mechanism of link latency has been defined in many		* Congestion in packet network can affect the latency. If the
	technologies like Ethernet, OTN. You can refer to ITU-T [G.8021],		latency of a provisioned end-to-end LSP could not meet the
	[Y.1731] and [G.709] for more information.		latency agreement between operator and his user again, a
			mechanism may cause the LSPs for some traffic flows to move to
			some points in the network that is not congested. It is out
			scope of this document.
	3.3. Latency of Server Layer Network		* Some customers may insist on having the ability to re-route if
			the latency SLA is not being met. If a "provisioned" end-to-
			end LSP latency could not meet the latency agreement (e.g.,
			minimum latency or latency variation) between operator and his
			user, then re-routing could be triggered based on the local
			policy. Pre-defined or dynamic re-routing could be triggered
			to handle this case. The latency performance of pre-defined or
			dynamic re-routing LSP MUST meet the latency SLA parameter. In
			the case of predefined re-routing, the large amounts of
			redundant capacity may have a significant negative impact on
			the overall network cost. Dynamic re-routing also has to face
			the risk of resource limitation. So the choice of mechanism
			MUST be based on SLA or policy.
	When a LSP traverses a server layer FA-LSP, the latency information		* As a result of the change of links and nodes latency in the
	of the FA-LSP SHOULD be provided by signaling protocol message if		LSP, current LSP may be frequently switched to a new LSP with a
	needed. Extension to the current signaling protocol is done to carry		appropriate latency value. In order to avoid this, the
	the latency information of the server layer FA-LSP. This is		solution SHOULD indicate the switchover of the LSP according to
	described in section 4 and section 5.		maximum acceptable change latency value.
	The boundary nodes of the FA-LSP SHOULD be aware of the latency		3. Control Plane Solution
	information of this FA-LSP (i.e., minimum latency, maximum latency,
	average latency). If the latency information of the FA-LSP changes,
	the ingress node of the FA-LSP will receive the TE link information
	advertisement including the latency value which is already changed,
	then it will compute the total latency value of the FA-LSP again. If
	this value changes, the client layer of the FA-LSP MUST also be
	notified about the total value of the latency.
	The ingress node or egress node of the FA-LSP can advertise the total		In order to meet the requirements which have been identified in
	value of the latency to the client layer nodes connecting to the		section 3, this document defines following four phases.
	ingress node or egress node through signaling protocol message (e.g.,
	notify message or refresh message). If the FA-LSP is able to form a
	routing adjacency and/or as a TE link in the client network, the
	value of the FA-LSP can be used as TE link metric and advertised into
	the client layer routing instances or PCE.
	3.4. Role of the Control Plane		o The first phase is the advertisement of the latency information by
			routing protocol (i.e., OSPF-TE/IS-IS-TE), including latency of
			nodes and links, a FA-LSP or Composite Link [CL-REQ] between two
			neighbour and latency variation, so path computation entity can be
			aware of the latency of nodes and links.
	Current mechanism of latency measurement is provided by transport		o In the second phase, path computation entity is responsible for
	plane instead of control plane. The latency information between two		end-to-end path computation with latency constraint (e.g., less
	specified nodes will be detected if there is latency demand of the		than 10 ms) combining other routing constraint parameters (e.g.,
	path between the two nodes. This is low in efficiency and high in		SRLG, cost and bandwidth).
	cost if the latency information does not correspond with the
	customers' demand.
	A new method of latency measurement mechanism is provided by		o The third phase is to convey the latency SLA parameters for the
	collecting the node latency value, link latency value between two		selection or creation of component link or FA/FA-LSP. One end-to-
	neighbor nodes or a FA-LSP and latency variation, then these values		end LSP may be across some Composite Links or server layers, so it
	is provided to the control plane. Control plane can compute a path		can convey latency SLA parameters by RSVP-TE message.
	correspond with customers' demand with these latency values.
	3.5. Impact of the Change of Link Latency		o The last phase is the latency collection and verification. This
			stage could be optional. It could accumulate (e.g., sum) latency
			information along the LSP across multi-domain (e.g., Inter-AS,
			Inter-Area or Multi-Layer) by RSVP-TE signaling message to verify
			the total latency at the end of path.
	If the link latency of a LSP which have a latency value corresponds		3.1. Latency Advertisement
	with customers' demand changes, the ingress node or PCE will be aware
	of the latency value change in the network. Total latency value of
	the LSP affected by the latency value change will be re-computed
	through the ingress node or PCE. Client service SHOULD be switched
	to a new LSP which have a latency value corresponds with customers'
	demand if current changed latency value is invalid. This is much
	like the recovery, but not recovery. All the LSPs affected by this
	latency change may not be rerouted to find appropriate LSPs if they
	still have appropriate latency values. All the LSPs affected will be
	rerouted to find a recovery path if there is a link failure.
	As a result of the change of link latency in the LSP, current LSP may		A node in the packet transport network or optical transport network
	be frequently switched to a new LSP with a appropriate latency value.		can detect the latency value of link which connects to it. Also the
	In order to avoid this, solution SHOULD indicate the switchover of		node latency can be recorded at every node. Then latency values of
	the LSP according to maximum acceptable value of the customers.		TE links, Composit Links [CL-REQ] or FAs, latency values of nodes and
			latency variation are notified to the IGP and/or PCE. If any latency
			values change and over than the threshold and a limit on rate of
			change, then the change MUST be notified to the IGP and/or PCE again.
			As a result, path computation entity can have every node and link
			latency values and latency variation in its view of the network, and
			it can compute one end-to-end path with latency constraint. It needs
			to extend IGP protocol (i.e., OSPF-TE/IS-IS-TE).
	4. A New Latency Measurement Mechanism		3.1.1. Routing Extensions
	This new latency measurement can be divided into two phases. The		Following is the extensions to OSPF-TE/IS-IS-TE to support the
	first phase is the advertisement of the latency information by		advertisement of the node latency value, link latency and latency
	routing protocol, including node latency, link latency between two		variation.
	neighbor nodes or a FA-LSP and latency variation, so every node in
	the network can be aware of the latency of every node and link. The
	second phase is the latency collection and verification along the
	path from the ingress node to the egress node by signaling protocol,
	so an adaptive LSP can be found out and verified.
	4.1. Advertisement of the Latency Value		3.1.1.1. OSPF-TE Extension
	As described in the introduction section, a node in the packet		OSPF-TE routing protocol can be used to carry latency performance
	transport network or optical transport network can detect link		metric by adding a sub-TLV to the TE link defined in [RFC4203]. As
	latency value which has connection with it. Also the node latency		defined in [RFC3630] and [RFC4203], the top-level TLV can take one of
	can be recorded at every node. Then these link latency values of the		two values (1) Router address or (2) Link. Latency sub-TLV of node
	neighbor nodes, node latency and latency variation is notified to the		and link is added behind the top-level TLV. The link latency sub-TLV
	control plane. The control plane instances then advertise these link		has the same format as node latency sub-TLV. They both include
	latency values, node latency values and latency variation as		minimum latency and latency variation value. Following is the
	attributes of the TE link to the other nodes in the routing domain or		Latency sub-TLV format.
	PCE by routing protocol. If any latency values change, then the
	change MUST be notified to the control plane instances, then
	advertise by routing protocol in the routing domain or to the PCE.
	As a result, control plane instances and PCE can have every node
	latency values, link latency values and latency variation in the
	network.
	4.2. Latency Collection and Verification		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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type(IANA) | Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Minimum Latency Value |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Latency Variation Value |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	When the PCE receives the request which indicates the demand of		Figure 1: Format of the Latency sub-TLV
	latency, PCE can compute a path which satisfies customers' latency
	demand with the node latency values, link latency values and latency
	variation in the network. The ingress node initializes the creation
	of the LSP with path signaling message which includes the latency
	demand parameter. The path signaling message collects the node
	latency value, link latency value and latency variation along the
	path. When the path signaling message reaches the egress node, the
	egress node can verify whether the value of the latency is applicable
	by comparing the LSP latency with the latency demand parameter
	carried in the path message. Similarly, when egress node returns
	recv signaling message to ingress node, node latency values, link
	latency values and latency variation will also be gathered in the
	reverse direction. The ingress node verifies whether the latency
	values from the egress node to the ingress node is applicable.This
	extensions is not necessary unless there is a need.
	When a LSP traverses a server layer FA-LSP, the latency information		o Minimum Latency Value: a value indicates the minumum latency of
	of the FA-LSP is advertised by routing protocol and carried in the		link or node.
	signaling message. The latency information of the server layer FA-
	LSP can be carried in the ERBO object which is defined in
	[draft-fuxh-ccamp-boundary-explicit-control-ext]. Region boundaries
	carried in ERBO contain one pair or multiple pair of nodes. One pair
	of boundary nodes indicates the head node and the end node of the FA-
	LSP (i.e., the region boundary). The latency values information of
	the FA-LSP between two boundary nodes is carried in the signaling
	message directly behind a pair of boundary nodes in the ERBO.
	Ingress node will re-compute the total latency value of the FA-LSP if
	the total latency value of the FA-LSP changes. The latency value of
	the FA-LSP SHOULD be announced to the client layer of the FA-LSP,
	also advertised in the routing domain.
	5. Signaling and Routing Extensions to Support Latency Measurement		o Latency Variation Value: a value indicates the variation range of
			the minimum latency value.
	Extensions SHOULD be done to existing OSPF-TE routing protocol and		3.1.1.2. IS-IS-TE Extension
	RSVP-TE routing protocol, in order to support the advertisement, the
	collection and the verification of the latency values. In this
	section, routing extensions and signaling extensions will be
	described.
	5.1. Routing Extensions to Support the Advertisement of Latency		TBD
	Some extensions to the existing OSPF-TE routing protocol to support		3.2. Latency SLA Parameters Conveying
	the advertisement of the node latency value, link latency and latency
	variation value in the routing domain or to the PCE as TE metric.
	OSPF-TE routing protocol can be used to carry latency information by
	adding a sub-TLV to the TE link which is defined in [RFC4203]. The
	latency value can be used as constraint for routing computation and
	as a factor impacting the node and link performance.
	As defined in [RFC3630] and [RFC4203], the top-level TLV can take one		3.2.1. Signaling Extensions
	of two values (1) Router address or (2) Link. Node latency sub-TLV
	and link latency sub-TLV can be added behind the top-level TLV. The		This document defines extensions to and describes the use of RSVP-TE
	link latency sub-TLV has the same format as node latency TLV. They		[RFC3209], [RFC3471], [RFC3473] to explicitly convey the latency SLA
	both include these parameters like minimum latency value, minimum		parameter for the selection or creation of component link or FA/
	latency variation value, maximum latency value, maximum latency		FA-LSP. Specifically, in this document, Latency SLA Parameters TLV
	variation value, average latency value, average latency variation		are defined and added into ERO as a subobject.
	value. The format of the sub-TLV can be seen below.
			3.2.1.1. Latency SLA Parameters ERO subobject
			A new OPTIONAL subobject of the EXPLICIT_ROUTE Object (ERO) is used
			to specify the latency SLA parameters including minimum latency,
			maximum acceptable latency and maximum acceptable latency variation.
			It can be used for the following scenarios.
			o One end-to-end LSP may traverse a server layer FA-LSP. This
			subobject of ERO can indicate that FA selection or FA-LSP creation
			shall be based on this latency constraint. The boundary nodes of
			multi-layer will take these parameters into account for FA
			selection or FA-LSP creation.
			o One end-to-end LSP may be across some Composite Links [CL-REQ].
			This subobject of ERO can indicate that a traffic flow shall
			select a component link with some latency constraint values as
			specified in this subobject.
			This Latency SLA Parameters ERO subobject has the following format.
			It follows a subobject containing the IP address, or the link
			identifier [RFC3477], associated with the TE link on which it is to
			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 |		| Type(IANA) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Minimum Latency Value |		| Minimum Latency Value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Maximum Latency Value |		| Maximum Acceptable Latency Value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Average Latency Value |		| Maximum Acceptable Latency Variation Value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Latency Variation Value |
			Figure 2: Format of Latency SLA Parameters TLV
			o Minimum Latency Value: a value indicates that a traffic flow shall
			select a component link with the minimum latency value [CL-REQ].
			It can also indicate one end-to-end LSP shall select a FA or
			trigger a FA-LSP creation with the minimum latency value when it
			traverse a server layer.
			o Maximum Acceptable Latency Value: a value indicates that a traffic
			flow shall select a component link with a maximum acceptable
			latency value [CL-REQ]. It can also indicate one end-to-end LSP
			shall select a FA or trigger a FA-LSP creation with a maximum
			acceptable latency value when it traverse a server layer.
			o Maximum Acceptable Latency Variation Value: a value indicates that
			a traffic flow shall select a component link with a maximum
			acceptable latency variation value [CL-REQ]. It can also indicate
			one end-to-end LSP shall select a FA or trigger a FA-LSP creation
			with a maximum acceptable latency variation value when it traverse
			a server layer.
			3.2.1.2. Signaling Procedure
			When a intermediate node receives a PATH message containing ERO and
			finds that there is a Latency SLA Parameters ERO subobject
			immediately behind the IP address or link address sub-object related
			to itself, if the node determines that it's a region edge node of FA-
			LSP or an end point of a composite link [CL-REQ], then, this node
			extracts latency SLA parameters (i.e., minimum, maximum acceptable
			and maximum acceptable latency variation value) from Latency SLA
			Parameters ERO subobject. This node used these latency parameters
			for FA selection, FA-LSP creation or component link selection. If
			the intermediate node couldn't support the latency SLA, it MUST
			generate a PathErr message with a "Latency SLA unsupported"
			indication (TBD by INNA). If the intermediate node couldn't select a
			FA or component link, or create a FA-LSP which meet the latency
			constraint defined in Latency SLA Parameters ERO subobject, it must
			generate a PathErr message with a "Latency SLA parameters couldn't be
			met" indication (TBD by INNA).
			3.3. Latency Accumulation and Verification
			Latency accumulation and verification applies where the full path of
			an multi-domain (e.g., Inter-AS, Inter-Area or Multi-Layer) TE LSP
			can't be or is not determined at the ingress node of the TE LSP.
			This is most likely to arise owing to TE visibility limitations. If
			all domains support to communicate latency as a traffic engineering
			metric parameter, one end-to-end optimized path with delay constraint
			(e.g., less than 10 ms) which satisfies latency SLAs parameter could
			be computed by BRPC [RFC5441] in PCE. Otherwise, it could use the
			mechanism defined in this section to accumulat the latency of each
			links and nodes along the path which is across multi-domain. Latency
			accumulation and verification also applies where not all domains
			could support the communication latency as a traffic engineering
			metric parameter.
			3.3.1. Signaling Extensions
			3.3.1.1. Latency Accumulation Object
			An Latency Accumulation Object is defined in this document to support
			the accumulation and verification of the latency. This object which
			can be carried in a Path/Resv message may includes two sub-TLVs.
			Latency Accumulation Object has the following format.
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type(IANA) | Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Latency Accumulation sub-TLV (from source to sink) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Latency Accumulation sub-TLV (from sink to source) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Format of the sub-TLV		Figure 3: Format of Accumulated Latency Object
	- Minimum Latency Value: a value indicates the boundary of the node		o Latency Accumulation sub-TLV (from source to sink):It is used to
	latency or link latency along with maximum latency value.		accumulate the latency from source to sink along the
			unidirectional or bidirectional LSP. A Path message for
			unidirectional and bidirectional LSP must includes this sub-TLV.
			When sink node receives the Path message including this sub-TLV,
			it must copy this sub-TLV into Resv message. So the source node
			can receive the latency accumulated value (i.e., sum) from itself
			to sink node which can be used for latency verification.
	- Maximum Latency Value: a value indicates the boundary of the node		o Latency Accumulation sub-TLV (from sink to source):It is used to
	latency or link latency along with maximum latency value.		accumulate the latency from sink to source along the bidirectional
			LSP. A Resv message for the bidirectional LSP must includes this
			sub-TLV. So the source node can get the latency accumulated value
			(i.e., sum) of round-trip which can be used for latency
			verification.
	- Average Latency Value: a value indicates the average of the node		3.3.1.2. Latency Accumulation sub-TLV
	latency or link latency.
	- Latency Variation Value: a value indicates the variation range of		The Sub-TLV format is defined in the next picture.
	the minimum latency value, maximum latency value or average
	latency value.
	5.2. Signaling Extensions to Support the Latency Measurement		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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type | Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Accumulated Minimum Latency Value |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Accumulated Latency Variation Value |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Extensions SHOULD also be done to the RSVP-TE signaling protocol to		Figure 4: Format of Latency Accumulation sub-TLV
	support the collection and verification of the latency measurement.
	This can be achieved base on the extension to the RRO which is
	defined in [RFC3209] by adding an interface ID (i.e., IP Address) or
	interface identifier defined in [RFC3477], then adding the sub-TLV
	which has the same format with that described above. When a node
	receives the path message, node latency value, link latency value and
	latency variation along the path which has correlation to the node
	will be added behind the interface identifier and node ID sub-object.
	At the same time, the latency values requirement from the ingress
	node to the egress node have been added into the TE metric TLV. When
	the egress node receives the path message, the latency value of the
	LSP can be compute by the node latency value, link latency value and
	latency variation carried behind RRO. If the total latency value
	does not meet the requirement of the customer, patherr message SHOULD
	be created and return to the ingress node. Recv message can be used
	to collect and verify the latency information in the reverse
	direction in the same way.
	The signaling format of the sub-TLV has the same format as that		o Type: sub-TLV type
	described in the section 5.1. This format can also been used behind
	a pair of boundary nodes which are carried in ERBO to indicate the
	latency information of the FA-LSP if there are requirement of the
	server layer.
	6. Security Considerations		* 0: It indicates the sub-TLV is for the latency accumulation
			from source to sink node along the LSP.
			* 1: It indicates the sub-TLV is for the latency accumulation
			from sink to source node along the LSP.
			o Length: length of the sub-TLV value in bytes.
			o Accumulated Minimum Latency Value: a value indicates the sum of
			each links and nodes' minumum latency along one direction of LSP.
			o Accumulated Latency Variation Value: a value indicates the sume of
			each links and nodes' minumum latency variation along one
			direction of LSP.
			3.3.1.3. Signaling Procedures
			When the source node desires to accumulate (i.e., sum) the total
			latency of one end-to-end LSP, the "Latency Accumulating desired"
			flag (value TBD) should be set in the LSP_ATTRIBUTES object of Path/
			Resv message, object that is defined in [RFC5420].
			A source node initiates latency accumulation for a given LSP by
			adding Latency Accumulation object to the Path message. The Latency
			Accumulation object only includes one sub-TLV (sub-TLV type=0) where
			it is going to accumulate the latency value of each links and nodes
			along path from source to sink.
			When the downstream node receives Path message and if the "Latency
			Accumulating desired" is set in the LSP_ATTRIBUTES, it accumulates
			the latency of link and node based on the accumulated latency value
			of the sub-TLV (sub-TLV type=0) in Latency Accumulation object before
			it sends Path message to downsteam.
			If the intermediate node couldn't support the latency accumulation
			function, it MUST generate a PathErr message with a "Latency
			Accumulation unsupported" indication (TBD by INNA).
			When the sink node of LSP receives the Path message and the "Latency
			Accumulating desired" is set in the LSP_ATTRIBUTES, it copy the
			latency value in the Latency Accumulation sub-TLV (sub-TLV type=0) of
			Path message into the Resv message which will be forwarded hop by hop
			in the upstream direction until it arrives the source node. Then
			source node can get the latency sum value from source to sink for
			unidirectional and bidirectional LSP.
			If the LSP is a bidirectional one and the "Latency Accumulating
			desired" is set in the LSP_ATTRIBUTES, it adds another Latency
			Accumulation sub-TLV (sub-TLV type=1) into the Latency Accumulation
			object of Resv message where latency of each links and nodes along
			path will be accumulated from sink to source into this sub-TLV.
			When the upstream node receives Resv message and if the "Latency
			Accumulating desired" is set in the LSP_ATTRIBUTES, it accumulates
			the latency of link and node based on the latency value in sub-TLV
			(sub-TLV type=1) before it continues to sends Resv message.
			After source node receive Resv message, it can get the total latency
			value of one way or round-trip from Latency Accumulation object. So
			it can confirm whether the latency value meet the latency SLA or not.
			4. Security Considerations
	TBD		TBD
	7. IANA Considerations		5. IANA Considerations
	TBD		TBD
	8. References		6. References
	8.1. Normative References
			6.1. Normative References
	[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.
	[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.
	[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching		[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
	(GMPLS) Signaling Resource ReserVation Protocol-Traffic		(GMPLS) Signaling Resource ReserVation Protocol-Traffic
	skipping to change at page 12, line 29 ¶		skipping to change at page 16, line 9 ¶
	(RSVP-TE)", RFC 3477, January 2003.		(RSVP-TE)", RFC 3477, January 2003.
	[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering		[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
	(TE) Extensions to OSPF Version 2", RFC 3630,		(TE) Extensions to OSPF Version 2", RFC 3630,
	September 2003.		September 2003.
	[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support		[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
	of Generalized Multi-Protocol Label Switching (GMPLS)",		of Generalized Multi-Protocol Label Switching (GMPLS)",
	RFC 4203, October 2005.		RFC 4203, October 2005.
	8.2. Informative References		6.2. Informative References
	[CL-REQ] C. Villamizar, "Requirements for MPLS Over a Composite		[CL-REQ] C. Villamizar, "Requirements for MPLS Over a Composite
	Link", draft-ietf-rtgwg-cl-requirement-02 .		Link", draft-ietf-rtgwg-cl-requirement-02 .
	[G.709] ITU-T Recommendation G.709, "Interfaces for the Optical		[G.709] ITU-T Recommendation G.709, "Interfaces for the Optical
	Transport Network (OTN)", December 2009.		Transport Network (OTN)", December 2009.
	Authors' Addresses		Authors' Addresses
	Qilei Wang
	ZTE Corporation
	No.68 ZiJingHua Road,Yuhuatai District
	Nanjing 210012
	P.R.China
	Email: wang.qilei@zte.com.cn
	URI: http://wwwen.zte.com.cn/
	Xihua Fu		Xihua Fu
	ZTE Corporation		ZTE Corporation
	West District,ZTE Plaza,No.10,Tangyan South Road,Gaoxin District
	Xi An 710065
	P.R.China
	Phone: +8613798412242
	Email: fu.xihua@zte.com.cn		Email: fu.xihua@zte.com.cn
	URI: http://wwwen.zte.com.cn/
			Malcolm Betts
			ZTE Corporation
			Email: malcolm.betts@zte.com.cn
			Qilei Wang
			ZTE Corporation
			Email: wang.qilei@zte.com.cn
End of changes. 74 change blocks.
	395 lines changed or deleted		530 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/