draft-ietf-ccamp-te-metric-recording-02.txt		draft-ietf-ccamp-te-metric-recording-03.txt
	CCAMP Working Group Zafar Ali		CCAMP Working Group Zafar Ali
	Internet Draft George Swallow		Internet Draft George Swallow
	Intended status: Standard Track Clarence Filsfils		Intended status: Standard Track Clarence Filsfils
	Expires: January 13, 2014 Matt Hartley		Expires: August 13, 2014 Matt Hartley
	Cisco Systems		Cisco Systems
	Kenji Kumaki		Kenji Kumaki
	KDDI Corporation		KDDI Corporation
	Ruediger Kunze		Ruediger Kunze
	Deutsche Telekom AG		Deutsche Telekom AG
	July 14, 2013
			February 14, 2014
	Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)		Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
	extension for recording TE Metric of a Label Switched Path		extension for recording TE Metric of a Label Switched Path
	draft-ietf-ccamp-te-metric-recording-02.txt		draft-ietf-ccamp-te-metric-recording-03.txt
	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
	and may be updated, replaced, or obsoleted by other documents at any		months and may be updated, replaced, or obsoleted by other
	time. It is inappropriate to use Internet-Drafts as reference		documents at any time. It is inappropriate to use Internet-Drafts
	material or to cite them other than as "work in progress."		as reference material or to cite them other than as "work in
			progress."
	This Internet-Draft will expire on January 13, 2014.		This Internet-Draft will expire on August 13, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 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
	to this document. Code Components extracted from this document must		respect to this document. Code Components extracted from this
	include Simplified BSD License text as described in Section 4.e of		document must include Simplified BSD License text as described in
	the Trust Legal Provisions and are provided without warranty as		Section 4.e of the Trust Legal Provisions and are provided without
	described in the Simplified BSD License.		warranty as described in the Simplified BSD License.
	Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt		This document may contain material from IETF Documents or IETF
			Contributions published or made publicly available before November
			10, 2008. The person(s) controlling the copyright in some of this
			material may not have granted the IETF Trust the right to allow
			modifications of such material outside the IETF Standards Process.
			Without obtaining an adequate license from the person(s)
			controlling the copyright in such materials, this document may not
			be modified outside the IETF Standards Process, and derivative
			works of it may not be created outside the IETF Standards Process,
			except to format it for publication as an RFC or to translate it
			into languages other than English.
			Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt
	Abstract		Abstract
	There are many scenarios in which Traffic Engineering (TE) metrics		There are many scenarios in which Traffic Engineering (TE) metrics
	such as cost, latency and latency variation associated with a		such as cost, latency and latency variation associated with a
	Forwarding Adjacency (FA) or Routing Adjacency (RA) Label Switched		Forwarding Adjacency (FA) or Routing Adjacency (RA) Label Switched
	Path (LSP) are not available to the ingress and egress nodes. This		Path (LSP) are not available to the ingress and egress nodes. This
	draft provides extensions for the Resource ReserVation Protocol-		draft provides extensions for the Resource ReserVation Protocol-
	Traffic Engineering (RSVP-TE) for the support of the discovery of		Traffic Engineering (RSVP-TE) for the support of the discovery of
	cost, latency and latency variation of an LSP.		cost, latency and latency variation of an LSP.
	Conventions used in this document		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		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
	this document are to be interpreted as described in RFC 2119		this document are to be interpreted as described in RFC 2119
	[RFC2119].		[RFC2119].
	Table of Contents		Table of Contents
	Copyright Notice..................................................1		1. Introduction................................................3
	1. Introduction...................................................3		2. RSVP-TE Requirement.........................................4
	2. RSVP-TE Requirement............................................3		2.1. Cost, Latency and Latency Variation Collection Indication.4
	2.1. Cost, Latency and Latency Variation Collection Indication....4		2.2. Cost, Latency and Latency Variation Collection............4
	2.2. Cost, Latency and Latency Variation Collection...............4		2.3. Cost, Latency and Latency Variation Update................4
	2.3. Cost, Latency and Latency Variation Update...................4		3. RSVP-TE signaling extensions................................5
	3. RSVP-TE signaling extensions...................................4		3.1. Cost, Latency, and Latency Variation Collection Flags.....5
	3.1. Cost, Latency and Latency Variation Collection Flags.........4		3.4. Cost subobject............................................5
	3.2. Cost Subobject...............................................5		3.5. Latency subobject.........................................6
	3.3. Latency Subobject............................................6		3.6. Latency Variation subobject...............................7
	3.4. Latency Variation Subobject..................................7		3.7. Signaling Procedures......................................8
	3.5. Signaling Procedures.........................................8		4. Security Considerations....................................12
	4. Security Considerations........................................9		5. IANA Considerations........................................12
	5. IANA Considerations............................................9		5.1. RSVP Attribute Bit Flags.................................12
	5.1. RSVP Attribute Bit Flags.....................................9		Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt
	Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt
	5.2. New RSVP error sub-code.....................................10		5.2. New RSVP error sub-code..................................13
	6. Acknowledgments...............................................11		6. Acknowledgments............................................14
	7. References....................................................11		7. References.................................................14
	7.1. Normative References........................................11		7.1. Normative References.....................................14
	7.2. Informative References......................................12		7.2. Informative References...................................14
	1. Introduction		1. Introduction
	There are many scenarios in packet and optical networks where
	the route information of an LSP may not be provided to the
	ingress node for confidentiality reasons and/or the ingress node
	may not run the same routing instance as the intermediate nodes
	traversed by the path. In such scenarios, the ingress node
	cannot determine the cost, latency and latency variation
	properties of the LSP's route. Similarly, in Generalized Multi-
	Protocol Label Switching (GMPLS) networks signaling
	bidirectional LSP, the egress node cannot determine the cost,
	latency and latency variation properties of the LSP route. A
	multi-domain or multi-layer network is an example of such
	networks. Similarly, a GMPLS User-Network Interface (UNI)
	[RFC4208] is also an example of such networks.
	In certain networks, such as financial information networks,		In certain networks, such as financial information networks,
	network performance information (e.g. latency, latency		network performance information (e.g. latency, latency
	variation) is becoming as critical to data path selection as		variation) is becoming as critical to data path selection as
	other metrics [DRAFT-OSPF-TE-METRIC], [DRAFT-ISIS-TE-METRIC]. If		other metrics [DRAFT-OSPF-TE-METRIC], [DRAFT-ISIS-TE-METRIC]. If
	cost, latency or latency variation associated with an FA or an		cost, latency or latency variation associated with a Forwarding
	RA LSP is not available to the ingress or egress node, it cannot		Adjacency (FA) or a Routing Adjacency (RA) LSP is not available
	be advertised as an attribute of the FA or RA. One possible way		to the ingress or egress node, it cannot be advertised as an
	to address this issue is to configure cost, latency and latency		attribute of the FA or RA. There are scenarios in packet and
	variation values manually. However, in the event of an LSP being		optical networks where the route information of an LSP may not
	rerouted (e.g. due to re-optimization), such configuration		be provided to the ingress node for confidentiality reasons
	information may become invalid. Consequently, in case where that		and/or the ingress node may not run the same routing instance as
	an LSP is advertised as a TE-Link, the ingress and/or egress		the intermediate nodes traversed by the path. In such scenarios,
	nodes cannot provide the correct latency, latency variation and		the ingress node cannot determine the cost, latency and latency
	cost attribute associated with the TE-Link automatically.		variation properties of the LSP's route.
			One possible way to address this issue is to configure cost,
			latency and latency variation values manually. However, in the
			event of an LSP being rerouted (e.g. due to re-optimization),
			such configuration information may become invalid. Consequently,
			in cases where that an LSP is advertised as a TE-Link, the
			ingress and/or egress nodes cannot provide the correct latency,
			latency variation and cost attribute associated with the TE-Link
			automatically.
	In summary, there is a requirement for the ingress and egress		In summary, there is a requirement for the ingress and egress
	nodes to learn the cost, latency and latency variation		nodes to learn the cost, latency and latency variation
	attributes of an FA or RA LSP. This draft provides extensions to		attributes of an FA or RA LSP. This draft provides extensions to
	the Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)		the Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
	for the support of the automatic discovery of these attributes.		for the support of the automatic discovery of these attributes.
	2. RSVP-TE Requirement		1.1. Use Cases
			1.1.1. GMPLS
			In Generalized Multi-Protocol Label Switching (GMPLS) networks
			signaling bidirectional LSPs, the egress node cannot determine
			the cost, latency and latency variation properties of the LSP
			path. A multi-domain or multi-layer network is an example of
			such networks. A GMPLS User-Network Interface (UNI) [RFC4208] is
			also an example of such networks.
			Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt
			1.1.2. Inter-area tunnels with loose-hops
			When a LSP is established over multiple IGP-areas using loose
			hops in the ERO, the ingress node only has knowledge of the
			first IGP-area traversed by the LSP. In this case, it cannot
			determine the cost, latency and latency variation properties of
			the LSP path.
			2. RSVP-TE Requirements
	This section outlines RSVP-TE requirements for the support of		This section outlines RSVP-TE requirements for the support of
	the automatic discovery of cost, latency and latency variation		the automatic discovery of cost, latency and latency variation
	attributes of an LSP. These requirements are very similar to the		attributes of an LSP. These requirements are very similar to the
	requirement of discovering the Shared Risk Link Groups (SRLGs)		requirement of discovering the Shared Risk Link Groups (SRLGs)
	associated with the route taken by an LSP [DRAFT-SRLG-		associated with the route taken by an LSP [DRAFT-SRLG-
	RECORDING].		RECORDING].
	Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt
	2.1. Cost, Latency and Latency Variation Collection Indication		2.1. Cost, Latency and Latency Variation Collection Indication
	The ingress node of the LSP must be capable of indicating		The ingress node of the LSP must be capable of indicating
	whether the cost, latency and latency variation attributes of		whether the cost, latency and latency variation attributes of
	the LSP should be collected during the signaling procedure of		the LSP should be collected during the signaling procedure of
	setting up the LSP. No cost, latency or latency variation		setting up the LSP. No cost, latency or latency variation
	information is collected without an explicit request being made		information is collected without an explicit request being made
	by the ingress node.		by the ingress node.
	2.2. Cost, Latency and Latency Variation Collection		2.2. Cost, Latency and Latency Variation Collection
	If requested, cost, latency and latency variation is		If requested, cost, latency and latency variation is
	collected during the setup of an LSP. The endpoints of the LSP		collected during the setup of an LSP. The endpoints of the LSP
	may use the collected information for routing, flooding and TE		may use the collected information for routing, flooding and TE
	link configuration and other purposes.		link configuration and other purposes.
	2.3. Cost, Latency and Latency Variation Update		2.3. Cost, Latency and Latency Variation Update
	When the cost, latency and latency variation property of a TE		When the cost, latency or latency variation property of a TE
	link along the route of a LSP for which that property was		link along the route of a LSP for which that property was
	collected changes, e.g., if the administrator changes cost of a		collected changes (e.g., if the administrator changes the cost
	TE link, the node where the change occurred needs to be capable		of a TE link traversed by the LSP), the node where the change
	of updating the cost, latency and latency variation information		occurred needs to be capable of updating the cost, latency and
	of the path and signaling this to the end-points. Similarly, if		latency variation information of the path and signaling this to
	a path segment of the LSP is rerouted, the endpoints of the re-		the end-points. Similarly, if a path segment of the LSP is
	routed segment need to be capable of updating the cost, latency		rerouted, the endpoints of the re-routed segment need to be
	and latency variation information of the path. Any node, which		capable of updating the cost, latency and latency variation
	adds cost, latency or latency variation information to an LSP		information of the path. Any node which adds cost, latency or
	during initial setup, needs to signal changes to these values to		latency variation information to an LSP during initial setup,
	both endpoints.		needs to signal changes to these values to both endpoints.
	3. RSVP-TE signaling extensions		2.4. Cost Definition
	3.1. Cost, Latency and Latency Variation Collection Flags		Although the terms latency and latency variation are well
			understood, "cost" may be ambiguous; in particular, in the
			Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt
	Three Attribute flags are defined in the Attribute Flags TLV,		context of a LSP that traverses nodes and links operated by
	which can be set and carried in either the LSP_ATTRIBUTES or		different entities, there may be no common definition of cost.
	LSP_REQUIRED_ATTRIBUTES Objects.		However, there are situations in which the entire LSP may be
			within a single AS (e.g. inter-area LSPs) in which cost
			discovery is useful.
	- Cost Collection flag (to be assigned by IANA)		The precise meaning and interpretation of numerical costs is a
			matter for the network operator. For the purposes of this
			document, two constraints are assumed:
	- Latency Collection flag (to be assigned by IANA)		. A higher cost represents an inferior path
	- Latency Variation Collection flag (to be assigned by IANA)		. Simple addition of costs for different sections of a path
			must make sense.
	These flags are meaningful in a Path message. If the Cost		3. RSVP-TE signaling extensions
	Collection flag is set to 1, the transit nodes SHOULD report the
	cost information in the Record Route Objects (RRO) of both the
	Path and Resv messages.
	Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt		3.1. Cost, Latency and Latency Variation Collection Flags
	If the Cost Collection flag is set to 1, the transit nodes		In order to indicate nodes that cost, latency and/ or latency
	SHOULD report latency variation information in the Record Route		variation collection is desired, the following three Attribute
	Objects (RRO) of both the Path and Resv messages.		flags are defined in the Attribute Flags TLV:
	If the Latency Collection flag is set to 1, the transit nodes		- Cost Collection flag (to be assigned by IANA)
	SHOULD report latency variation information in the Record Route
	Objects (RRO) of both the Path and Resv messages.
	If the Latency Variation Collection flag is set to 1, the		- Latency Collection flag (to be assigned by IANA)
	transit nodes SHOULD report latency variation information in the
	Record Route Objects (RRO) of both the Path and Resv messages.
	The procedure for the processing the Attribute Flags TLV follows		- Latency Variation Collection flag (to be assigned by IANA)
	[RFC5420].
			These flags are set and carried in either the LSP_ATTRIBUTES or
			LSP_REQUIRED_ATTRIBUTES Objects in a Path message.
	3.2. Cost Subobject		3.2. Cost Subobject
	The cost subobject is defined for the RRO to record the cost		The Cost subobject is a new RRO (ROUTE_RECORD OBJECT) sub-object
	information of the LSP. Its format is similar to the RRO		used to record the cost information of the LSP. Its format is
	subobjects (ROUTE_RECORD sub-object) defined in [RFC3209].		similar to the other RRO subobjects defined in [RFC3209].
	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 | Length | Reserved (must be zero) |		| Type | Length | Reserved (must be zero) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Downstream Cost |		| Downstream Cost |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Upstream Cost |		| Upstream Cost |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: TBA1 - Cost subobject (to be assigned by IANA).		Type: TBA1 - Cost subobject (to be assigned by IANA).
			Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt
	Length: The Length value is set to 8 or 12 depending on the		Length: The Length value is set to 8 or 12 depending on the
	presence of Upstream Cost information.		presence of Upstream Cost information. It MUST NOT be set to
			any other value.
	Reserved: This field is reserved for future use. It MUST be		Reserved: This field is reserved for future use. It MUST be
	set to 0 when sent and MUST be ignored when received.		set to 0 on transmission and MUST be ignored when received.
	Downstream Cost: Cost of the local link along the route of		Downstream Cost: Cost of the local link along the route of
	the LSP in the direction of the tail-end node, encoded as a		the LSP in the direction of the tail-end node, encoded as a
	32-bit integer. Based on the policy at the recording node,		32-bit integer. This approach has been taken to avoid
	the cost value can be set to the Interior Gateway Protocol		defining a flag for each cost type in the Attribute-Flags
	(IGP) metric or TE metric of the link in question. This		TLV.
	approach has been taken to avoid defining a flag for each
	cost type in the Attribute-Flags TLV. It is assumed that,
	based on policy, all nodes report the same cost-type and that
	Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt
	the ingress and egress nodes know the cost type reported in
	the RRO.
	Upstream Cost: Cost of the local link along the route of the		Upstream Cost: Cost of the local link along the route of the
	LSP in the direction of the head-end node, encoded as a 32-		LSP in the direction of the head-end node, encoded as a 32-
	bit integer. Based on the policy at the recording node, the		bit integer.
	cost value can be set to the Interior Gateway Protocol (IGP)
	metric or TE metric of the link in question. This approach
	has been taken to avoid defining a flag for each cost type in
	the Attribute-Flags TLV. It is assumed that, based on policy,
	all nodes report the same cost-type and that the ingress and
	egress nodes know the cost type reported in the RRO.
	3.3. Latency Subobject		3.3. Latency Subobject
	The Latency subobject is defined for RRO to record the latency		The Latency subobject is a new RRO sub-object to record the
	information of the LSP. Its format is similar the RRO subobjects		latency information of the LSP. Its format is similar the other
	defined in [RFC3209].		RRO subobjects defined in [RFC3209].
	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 | Length | Reserved (must be zero) |		| Type | Length | Reserved (must be zero) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|A| Reserved | Downstream Delay |		|A| Reserved | Downstream Delay |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|A| Reserved | Upstream Delay |		|A| Reserved | Upstream Delay |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: TBA2 - Latency subobject (to be assigned by IANA).		Type: TBA2 - Latency subobject (to be assigned by IANA).
	Length: 8 or 12 depending on the presence of Upstream Cost		Length: 8 or 12 depending on the presence of Upstream Delay
	information.		information.
	A-bit: These fields represent the Anomalous (A) bit		A-bit: These fields represent the Anomalous (A) bit
	associated with the Downstream and Upstream Delay		associated with the Downstream and Upstream Delay
	respectively, as defined in [DRAFT-OSPF-TE-METRIC].		respectively, as defined in [DRAFT-OSPF-TE-METRIC].
	Reserved: These fields are reserved for future use. They MUST		Reserved: These fields are reserved for future use. They MUST
	be set to 0 when sent and MUST be ignored when received.		be set to 0 when sent and MUST be ignored when received.
	Downstream Delay: Delay of the local link along the route of		Downstream Delay: Delay of the local link along the route of
	the LSP in the direction of the tail-end node, encoded as 24-		the LSP in the direction of the tail-end node, encoded as 24-
	bit integer. When set to 0, it has not been measured. When		bit integer, as defined in [DRAFT-OSPF-TE-METRIC]. When set
	set to the maximum value 16,777,215 (16.777215 sec), the		Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt
	delay is at least that value and may be larger.
			to the maximum value 16,777,215 (16.777215 sec), the delay is
			at least that value and may be larger.
	Upstream Delay: Delay of the local link along the route of		Upstream Delay: Delay of the local link along the route of
	the LSP in the direction of the head-end node, encoded as 24-		the LSP in the direction of the head-end node, encoded as 24-
	Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt		bit integer, as defined in [DRAFT-OSPF-TE-METRIC]. When set
			to the maximum value 16,777,215 (16.777215 sec), the delay is
	bit integer. When set to 0, it has not been measured. When		at least that value and may be larger.
	set to the maximum value 16,777,215 (16.777215 sec), the
	delay is at least that value and may be larger.
	3.4. Latency Variation Subobject		3.4. Latency Variation Subobject
	The Latency Variation subobject is defined for RRO to record the		The Latency Variation subobject is a new RRO sub-object to
	Latency Variation information of the LSP. Its format is similar		record the Latency Variation information of the LSP. Its format
	to the RRO subobjects defined in [RFC3209].		is similar to the other RRO subobjects defined in [RFC3209].
	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 | Length | Reserved (must be zero) |		| Type | Length | Reserved (must be zero) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|A| Reserved | Downstream Delay Variation |		|A| Reserved | Downstream Delay Variation |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|A| Reserved | Upstream Delay Variation |		|A| Reserved | Upstream Delay Variation |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: TBA3 - Latency Variation subobject (to be assigned by		Type: TBA3 - Latency Variation subobject (to be assigned by
	IANA).		IANA).
	Length: 8 or 12 depending on the presence of Upstream Latency		Length: 8 or 12 depending on the presence of Upstream Latency
	Variation information.		Variation information.
	A-bit: These fields represent the Anomalous (A) bit		A-bit: These fields represent the Anomalous (A) bit
	associated with the Downstream and Upstream Delay		associated with the Downstream and Upstream Delay Variation
	respectively, as defined in [DRAFT-OSPF-TE-METRIC].		respectively, as defined in [DRAFT-OSPF-TE-METRIC].
	Reserved: These fields are reserved for future use. It MUST		Reserved: These fields are reserved for future use. It SHOULD
	be set to 0 when sent and MUST be ignored when received.		be set to 0 when sent and MUST be ignored when received.
	Downstream Delay Variation: Delay Variation of the local link		Downstream Delay Variation: Delay Variation of the local link
	along the route of the LSP in the direction of the tail-end		along the route of the LSP in the direction of the tail-end
	node, encoded as 24-bit integer. When set to 0, it has not		node, encoded as 24-bit integer, as defined in [DRAFT-OSPF-
	been measured. When set to the maximum value 16,777,215		TE-METRIC]. When set to the maximum value 16,777,215
	(16.777215 sec), the delay is at least that value and may be		(16.777215 sec), the delay is at least that value and may be
	larger.		larger.
	Upstream Delay Variation: Delay Variation of the local link		Upstream Delay Variation: Delay Variation of the local link
	along the route of the LSP in the direction of the head-end		along the route of the LSP in the direction of the head-end
	node, encoded as 24-bit integer. When set to 0, it has not		node, encoded as 24-bit integer. When set to 0, it has not
	been measured. When set to the maximum value 16,777,215		been measured. When set to the maximum value 16,777,215
			Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt
	(16.777215 sec), the delay is at least that value and may be		(16.777215 sec), the delay is at least that value and may be
	larger.		larger.
	Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt		4. Signaling Procedures
	3.5. Signaling Procedures		The rules for processing the LSP_ATTRIBUTES and
			LSP_REQUIRED_ATTRIBUTES Objects and RRO defined in [RFC5420] are
			not changed.
			4.1. Collection request
	Typically, the ingress node learns the route of an LSP by adding		Typically, the ingress node learns the route of an LSP by adding
	a RRO in the Path message. If an ingress node also desires cost,		a RRO in the Path message. If an ingress node also desires cost,
	latency and/or latency variation recording, it sets the		latency and/or latency variation recording, it MUST set the
	appropriate flag(s) in the Attribute Flags TLV of the		appropriate flag(s) in the Attribute Flags TLV of the
	LSP_ATTRIBUTES (if recording is desired but not mandatory) or		LSP_ATTRIBUTES (if recording is desired but not mandatory) or
	LSP_REQUIRED_ATTRIBUTES (if recording in mandatory) Object.		LSP_REQUIRED_ATTRIBUTES (if recording in mandatory) Object.
	None, all or any of the Cost Collection, Latency Collection or		None, all or any of the Cost Collection, Latency Collection or
	Latency Variation Collection flags may be set in the Attribute		Latency Variation Collection flags MAY be set in the Attribute
	Flags TLV of the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES		Flags TLV of the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES
	Object. The rules for processing the LSP_ATTRIBUTES and		Object. These flags affect both Path and Resv RRO processing, as
	LSP_REQUIRED_ATTRIBUTES Objects and RRO are not changed. The		described below.
	corresponding sub-objects MUST be included in the RRO, with the
	Downstream (only) information filled in.
	When a node receives a Path message which carries an		The Cost Collection, Latency Collection or Latency Variation
	LSP_REQUIRED_ATTRIBUTES Object and the Cost, Latency and/or		Collection flags SHOULD NOT be set in an Attribute Flags TLV in
	Latency Variation Collection Flag(s) is (are) set, if local		a Resv message. If any of these flags is set in a received
	policy disallows providing the requested information to the		Attribute Flags TLV in a Resv message, it MUST be ignored.
	endpoints, the node MUST return a Path Error message with error
	code "Policy Control Failure (2)" and one of the following error
	subcodes:
	. "Cost Recoding Rejected" (value to be assigned by IANA,		The Cost Collection, Latency Collection or Latency Variation
	suggested value 105) if Cost Collection Flag is set.		Collection flags SHOULD NOT be set in an Attribute Flags TLV in
			a RRO. If any of these flags is set in a received Attribute
			Flags TLV in a RRO, it MUST be ignored.
	. "Latency Recording Rejected" (value to be assigned by IANA,		4.2. Path and Resv message processing
	suggested value 106) if Latency Collection Flag is set.
	. "Latency Variation Recording Rejected" (value to be assigned		4.2.1. Cost
	by IANA, suggested value 107) if Latency Variation Collection
	Flag is set.
	When a node receives a Path message which carries an		If a node receives a Path message containing a
	LSP_ATTRIBUTES Object and the Cost, Latency and/or Latency		LSP_REQUIRED_ATTRIBUTES Object with the Cost Collection Flag set
	Variation Collection Flag(s) is (are) set, if local policy		in the Attribute Flags TLV:
	disallows providing the requested information to the endpoints,
	the Path message SHOULD NOT rejected due to Metric recording
	restriction and the Path message is forwarded without the
	appropriate sub-object(s) in the Path RRO.
	If local policy permits the recording of the requested		. If local policy disallows providing the requested
	information, the processing node SHOULD add the requested		information to the endpoints, the node MUST return a Path
	subobject(s) with the cost, latency and/or latency variation		Error message with error code "Policy Control Failure" (2)
	metric value(s) associated with the local hop to the Path RRO.		and subcode "Cost Recording Rejected" (value to be assigned
	If the LSP being setup is bidirectional, both Downstream and		by IANA, suggested value 105).
	Upstream information SHOULD be included. If the LSP is
	unidirectional, only Downstream information SHOULD be included.
	Following the steps described above, the intermediate nodes of		. It SHOULD add a Cost subobject to the Path and Resv RROs
	the LSP provide the requested metric value(s) associated with		for the LSP. It SHOULD supply only downstream information
	Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt		for a unidirectional LSP, and SHOULD provide both upstream
			Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt
	the local hop in the Path RRO. When the egress node receives the		and downstream information if a bidirectional LSP is being
	Path message, it can calculate the end-to-end cost, latency		signaled.
	and/or latency variation properties of the LSP.
	Before the Resv message is sent to the upstream node, the egress		. If Cost information is not known, a Cost subobject SHOULD
	node adds the requested subobject(s) with the downstream cost,		NOT be added to either the Path or Resv RRO.
	latency and/or latency variation metric value(s) associated with
	the local hop to the Resv RRO in a similar manner to that
	specified above for the addition of Path RRO sub-objects by
	transit nodes.
	Similarly, the intermediate nodes of the LSP provide the		If a node receives a Path message containing a LSP_ATTRIBUTES
	requested metric value(s) associated with the local hop in the		Object with the Cost Collection Flag set in the Attribute Flags
	Resv RRO. When the ingress node receives the Resv message, it can		TLV:
	calculate the end-to-end cost, latency and/or latency variation
	properties of the LSP.		. If local policy disallows providing the requested
			information to the endpoints, the Path message SHOULD NOT
			be rejected. A Cost subobject is not added to the Path or
			Resv RRO.
			. If local policy permits, it SHOULD add a Cost subobject to
			the Path and Resv RROs for the LSP. It SHOULD supply only
			downstream information for a unidirectional LSP, and SHOULD
			provide both upstream and downstream information if a
			bidirectional LSP is being signaled.
			. If Cost information is not known, a Cost subobject SHOULD
			NOT be added to either the Path or Resv RRO.
			When adding a Cost subobject to a Path or Resv RRO:
			. The Downstream Cost is set to the cost of the local link
			used by the LSP in the direction of the egress node. It
			SHOULD be set to zero by the egress node.
			. The Upstream Cost, if set, is set to the cost of the local
			link used by the LSP in the direction of the ingress node.
			It SHOULD be set to zero by the ingress node.
			. The cost of a local link is the Interior Gateway Protocol
			(IGP) metric or TE metric of the link in question,
			depending on the policy of the processing node.
			4.2.2. Latency
			If a node receives a Path message containing a
			LSP_REQUIRED_ATTRIBUTES Object with the Latency Collection Flag
			set in the Attribute Flags TLV:
			. If local policy disallows providing the requested
			information to the endpoints, the node MUST return a Path
			Error message with error code "Policy Control Failure" (2)
			and subcode "Latency Recording Rejected" (value to be
			assigned by IANA, suggested value 106).
			. It SHOULD add a Latency subobject to the Path and Resv
			RROs for the LSP. It SHOULD supply only downstream
			Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt
			information for a unidirectional LSP, and SHOULD provide
			both upstream and downstream information if a bidirectional
			LSP is being signaled.
			. If Latency information is not known, a Latency subobject
			SHOULD NOT be added to either the Path or Resv RRO.
			If a node receives a Path message containing a LSP_ATTRIBUTES
			Object with the Latency Collection Flag set in the Attribute
			Flags TLV:
			. If local policy disallows providing the requested
			information to the endpoints, the Path message SHOULD NOT
			be rejected. A Latency subobject is not added to the Path
			or Resv RRO.
			. If local policy permits, it SHOULD add a Latency subobject
			to the Path and Resv RROs for the LSP. It SHOULD supply
			only downstream information for a unidirectional LSP, and
			SHOULD provide both upstream and downstream information if
			a bidirectional LSP is being signaled.
			. If Latency information is not known, a Latency subobject
			SHOULD NOT be added to either the Path or Resv RRO.
			When adding a Latency subobject to a Path or Resv RRO:
			. The Downstream Delay is set to the delay of the local link
			used by the LSP in the direction of the egress node. It
			SHOULD be set to zero by the egress node.
			. The Upstream Delay, if set, is set to the delay of the
			local link used by the LSP in the direction of the ingress
			node. It SHOULD be set to zero by the ingress node.
			. The A-bit for the downstream and upstream latency SHOULD
			be set as described in [DRAFT-OSPF-TE-METRIC].
			4.2.3. Latency Variation
			If a node receives a Path message containing a
			LSP_REQUIRED_ATTRIBUTES Object with the Latency Variation
			Collection Flag set in the Attribute Flags TLV:
			. If local policy disallows providing the requested
			information to the endpoints, the node MUST return a Path
			Error message with error code "Policy Control Failure" (2)
			and subcode "Latency Variation Recording Rejected" (value
			to be assigned by IANA, suggested value 107).
			. It SHOULD add a Latency Variation subobject to the Path
			and Resv RROs for the LSP. It SHOULD supply only downstream
			Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt
			information for a unidirectional LSP, and SHOULD provide
			both upstream and downstream information if a bidirectional
			LSP is being signaled.
			. If Latency Variation information is not known, a Latency
			subobject SHOULD NOT be added to either the Path or Resv
			RRO.
			If a node receives a Path message containing a LSP_ATTRIBUTES
			Object with the Latency Variation Collection Flag set in the
			Attribute Flags TLV:
			. If local policy disallows providing the requested
			information to the endpoints, the Path message SHOULD NOT
			be rejected. A Latency Variation subobject is not added to
			the Path or Resv RRO.
			. If local policy permits, it SHOULD add a Latency Variation
			subobject to the Path and Resv RROs for the LSP. It SHOULD
			supply only downstream information for a unidirectional
			LSP, and SHOULD provide both upstream and downstream
			information if a bidirectional LSP is being signaled.
			. If Latency Variation information is not known, a Latency
			subobject SHOULD NOT be added to either the Path or Resv
			RRO.
			When adding a Latency Variation subobject to a Path or Resv RRO:
			. The Downstream Latency Variation is set to the latency of
			the local link used by the LSP in the direction of the
			egress node. It SHOULD be set to zero by the egress node.
			. The Upstream Latency Variation, if set, is set to the
			latency of the local link used by the LSP in the direction
			of the ingress node. It SHOULD be set to zero by the egress
			node.
			. The A-bit for the downstream and upstream latency SHOULD
			be set as described in [DRAFT-OSPF-TE-METRIC].
			4.3. Metric Update
			When the cost, latency and/or latency variation information of a
			link is changed, the corresponding metric values for the LSPs
			using that link should also be updated. If node has added Cost,
			Latency and/or Latency Variation subobjects to the Path or Resv
			RRO, the procedures defined in Section 4.4.3 of RFC 3209
			[RFC3209] MUST be used to communicate any changes to relevant
			information to the other nodes on the LSP's path. The node need
			not send an update for changes to information which has not been
			added to the RRO.
			Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt
			5. Endpoint processing
			The ingress and egress nodes of a LSP may calculate the end-to-
			end cost, latency and/or latency variation properties of the LSP
			from the supplied values in the Resv or Path RRO respectively.
	Typically, cost and latency are additive metrics, but latency		Typically, cost and latency are additive metrics, but latency
	variation is not an additive metric. The means by which the		variation is not an additive metric. The means by which the
	ingress and egress nodes compute the end-to-end cost, latency		ingress and egress nodes compute the end-to-end cost, latency
	and latency variation metric from information recorded in the		and latency variation metric from information recorded in the
	RRO is beyond the scope of this document.		RRO is a local decision and is beyond the scope of this
			document.
	Based on the local policy, the ingress and egress nodes can		Based on the local policy, the ingress and egress nodes can
	advertise the calculated end-to-end cost, latency and/or latency		advertise the calculated end-to-end cost, latency and/or latency
	variation properties of the FA or RA LSP in TE link		variation properties of the FA or RA LSP in TE link
	advertisement to the routing instance based on the procedure		advertisement to the routing instance based on the procedure
	described in [DRAFT-OSPF-TE-METRIC], [DRAFT-ISIS-TE-METRIC].		described in [DRAFT-OSPF-TE-METRIC], [DRAFT-ISIS-TE-METRIC].
	Based on the local policy, a transit node (e.g. the edge node of		Based on the local policy, a transit node (e.g. the edge node of
	a domain) may edit a Path or Resv RRO to remove route		a domain) may edit a Path or Resv RRO to remove route
	information (e.g. node or interface identifier information)		information (e.g. node or interface identifier information)
	before forwarding it. A node that does this SHOULD summarize the		before forwarding it. A node that does this SHOULD summarize the
	cost, latency and latency variation data removed as a single		cost, latency and latency variation data and SHOULD follow
	value for each for the loose hop that is summarized by the		procedure defined in [DRAFT-RRO-EDIT]. How a node that performs
	transit node. How a transit node calculates the cost, latency o		the RRO edit operation calculates the cost, latency o and/or
	and/or latency variation metric for the segment summarized by		latency variation metric is beyond the scope of this document.
	the transit node is beyond the scope of this document.
	4. Security Considerations		6. Security Considerations
	This document does not introduce any additional security issues		This document does not introduce any additional security issues
	above those identified in [RFC5920], [RFC5420], [RFC2205],		above those identified in [RFC5920], [RFC5420], [RFC2205],
	[RFC3209], and [RFC3473].		[RFC3209], and [RFC3473].
	5. IANA Considerations		7. IANA Considerations
	5.1. RSVP Attribute Bit Flags		7.1. RSVP Attribute Bit Flags
	The IANA has created a registry and manages the space of		The IANA has created a registry and manages the space of
	attributes bit flags of Attribute Flags TLV as described in		attributes bit flags of Attribute Flags TLV as described in
	section 11.3 of [RFC5420]. It is requested that the IANA makes		section 11.3 of [RFC5420]. It is requested that the IANA makes
	Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt
	assignments from the Attribute Bit Flags defined in this		assignments from the Attribute Bit Flags defined in this
	document.		document.
	This document introduces the following three new Attribute		This document introduces the following three new Attribute
	Bit Flag:		Bit Flag:
	- Bit number: TBD (recommended bit position 11)		- Bit number: TBD (recommended bit position 11)
	- Defining RFC: this I-D		- Defining RFC: this I-D
	- Name of bit: Cost Collection Flag		- Name of bit: Cost Collection Flag
			Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt
	- Bit number: TBD (recommended bit position 12)		- Bit number: TBD (recommended bit position 12)
	- Defining RFC: this I-D		- Defining RFC: this I-D
	- Name of bit: Latency Collection Flag		- Name of bit: Latency Collection Flag
	- Bit number: TBD (recommended bit position 13)		- Bit number: TBD (recommended bit position 13)
	- Defining RFC: this I-D		- Defining RFC: this I-D
	skipping to change at page 10, line 45		skipping to change at page 13, line 33
	Type Name Reference		Type Name Reference
	--------- ---------------------- ---------		--------- ---------------------- ---------
	TBD (35) Cost subobject This I-D		TBD (35) Cost subobject This I-D
	TBD (36) Latency subobject This I-D		TBD (36) Latency subobject This I-D
	TBD (37) Latency Variation subobject This I-D		TBD (37) Latency Variation subobject This I-D
	5.2. New RSVP error sub-code		7.2. New RSVP error sub-code
	For Error Code = 2 "Policy Control Failure" (see [RFC2205]) the		For Error Code = 2 "Policy Control Failure" (see [RFC2205]) the
	following sub-code is defined.		following sub-code is defined.
	Sub-code Value		Sub-code Value
	-------- -----		-------- -----
	Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt
	Cost Recoding Rejected To be assigned by IANA.		Cost Recoding Rejected To be assigned by IANA.
	Suggested Value: 105.		Suggested Value: 105.
	Latency Recoding Rejected To be assigned by IANA.		Latency Recoding Rejected To be assigned by IANA.
	Suggested Value: 106.		Suggested Value: 106.
	Latency Variation Recoding Rejected To be assigned by		Latency Variation Recoding Rejected To be assigned by IANA.
	IANA.
	Suggested Value: 107.		Suggested Value: 107.
	6. Acknowledgments		Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt
			8. Acknowledgments
	Authors would like to thank Ori Gerstel, Gabriele Maria		Authors would like to thank Ori Gerstel, Gabriele Maria
	Galimberti, Luyuan Fang and Walid Wakim for their review		Galimberti, Luyuan Fang and Walid Wakim for their review
	comments.		comments.
	7. References		9. References
	7.1. Normative References		9.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,		[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
	V., and G. Swallow, "RSVP-TE: Extensions to RSVP for		V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
	LSP Tunnels", RFC 3209, December 2001.		LSP Tunnels", RFC 3209, December 2001.
	[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and		[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and
	A. Ayyangarps, "Encoding of Attributes for MPLS LSP		A. Ayyangarps, "Encoding of Attributes for MPLS LSP
	skipping to change at page 11, line 49		skipping to change at page 14, line 40
	[DRAFT-OSPF-TE-METRIC] S. Giacalone, D. Ward, J. Drake, A.		[DRAFT-OSPF-TE-METRIC] S. Giacalone, D. Ward, J. Drake, A.
	Atlas, S. Previdi, "OSPF Traffic Engineering (TE)		Atlas, S. Previdi, "OSPF Traffic Engineering (TE)
	Metric Extensions", draft-ietf-ospf-te-metric-		Metric Extensions", draft-ietf-ospf-te-metric-
	extensions, work in progress.		extensions, work in progress.
	[DRAFT-ISIS-TE-METRIC] S. Previdi, S. Giacalone, D. Ward, J.		[DRAFT-ISIS-TE-METRIC] S. Previdi, S. Giacalone, D. Ward, J.
	Drake, A. Atlas, C. Filsfils, "IS-IS Traffic		Drake, A. Atlas, C. Filsfils, "IS-IS Traffic
	Engineering (TE) Metric Extensions", draft-ietf-isis-		Engineering (TE) Metric Extensions", draft-ietf-isis-
	te-metric-extensions, work in progress.		te-metric-extensions, work in progress.
	[DRAFT-SRLG-RECORDING] F. Zhang, D. Li, O. Gonzalez de Dios, C.		9.2. Informative References
	Margaria,, "RSVP-TE Extensions for Collecting SRLG
	Information", draft-ietf-ccamp-rsvp-te-srlg-
	collect.txt, work in progress.
	Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt
	7.2. Informative References
	[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,		[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
	"Generalized Multiprotocol Label Switching (GMPLS)		"Generalized Multiprotocol Label Switching (GMPLS)
	User-Network Interface (UNI): Resource ReserVation		User-Network Interface (UNI): Resource ReserVation
	Protocol-Traffic Engineering (RSVP-TE) Support for the		Protocol-Traffic Engineering (RSVP-TE) Support for the
	Overlay Model", RFC 4208, October 2005.		Overlay Model", RFC 4208, October 2005.
	[RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation		[RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation
	Protocol (RSVP) -- Version 1 Message Processing		Protocol (RSVP) -- Version 1 Message Processing
	Rules", RFC 2209, September 1997.		Rules", RFC 2209, September 1997.
	[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS		[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
	Networks", RFC 5920, July 2010.		Networks", RFC 5920, July 2010.
			Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt
			[DRAFT-SRLG-RECORDING] F. Zhang, D. Li, O. Gonzalez de Dios, C.
			Margaria,, "RSVP-TE Extensions for Collecting SRLG
			Information", draft-ietf-ccamp-rsvp-te-srlg-
			collect.txt, work in progress.
	Authors' Addresses		Authors' Addresses
	Zafar Ali		Zafar Ali
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Email: zali@cisco.com		Email: zali@cisco.com
	George Swallow		George Swallow
	Cisco Systems, Inc.		Cisco Systems, Inc.
	swallow@cisco.com		swallow@cisco.com
End of changes. 77 change blocks.
	231 lines changed or deleted		396 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/