< draft-leroux-ccamp-rsvp-te-path-constr-00.txt		draft-leroux-ccamp-rsvp-te-path-constr-01.txt >
	CCAMP Working Group J.L. Le Roux		Network Working Group J.L. Le Roux
	France Telecom		France Telecom
	Internet Draft D. Papadimitriou		Internet Draft
	Alcatel		D. Papadimitriou
	Category: Standard Track		Alcatel
	Expires: April 2006 October 2005
	Handling Path Constraints in Generalized RSVP-TE signaling		Category: Standard Track
			Expires: April 2006 October 2005
	draft-leroux-ccamp-rsvp-te-path-constr-00.txt		Handling Path Constraints in Generalized RSVP-TE signaling
	Status of this Memo		draft-leroux-ccamp-rsvp-te-path-constr-01.txt
	By submitting this Internet-Draft, each author represents that any		Status of this Memo
	applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		By submitting this Internet-Draft, each author represents that any
	Task Force (IETF), its areas, and its working groups. Note that		applicable patent or other IPR claims of which he or she is aware
	other groups may also distribute working documents as Internet-		have been or will be disclosed, and any of which he or she becomes
	Drafts.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are working documents of the Internet Engineering
	and may be updated, replaced, or obsoleted by other documents at any		Task Force (IETF), its areas, and its working groups. Note that
	time. It is inappropriate to use Internet-Drafts as reference		other groups may also distribute working documents as Internet-
	material or to cite them other than as "work in progress."		Drafts.
	The list of current Internet-Drafts can be accessed at		Internet-Drafts are draft documents valid for a maximum of six months
	http://www.ietf.org/ietf/1id-abstracts.txt.		and may be updated, replaced, or obsoleted by other documents at any
			time. It is inappropriate to use Internet-Drafts as reference
			material or to cite them other than as "work in progress."
	The list of Internet-Draft Shadow Directories can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/ietf/1id-abstracts.txt.
	This Internet-Draft will expire on April 2006.		The list of Internet-Draft Shadow Directories can be accessed at
			http://www.ietf.org/shadow.html.
	Copyright Notice		This Internet-Draft will expire on April 2006.
	Copyright (C) The Internet Society (2005).		Copyright Notice
	Abstract		Copyright (C) The Internet Society (2005).
	In various situations, it would be useful to include path parameters		Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt
	such as delay, jitter, number of hops, cost, optical power, within
	Generalized MPLS signaling. For that purpose, this draft extends
	GMPLS RSVP-TE, for signaling path constraint, and accumulating path
	parameters. It defines protocol elements and procedures, that allow
	signaling path_constraints and accumulating path parameters along the
	signaled path.
	Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt		Abstract
	This draft only defines generic encoding rules and procedures.		In various situations, it would be useful to include aggregated path
	Specific encoding and procedures for each path parameter such as		parameters such as, e.g., delay, hop-count or optical power, within
	delay, hop count, jitter will be addressed in separate documents.		Generalized MPLS signaling. For that purpose, this draft extends
			GMPLS RSVP-TE, for signaling end-to-end path constraint, and
			aggregating path parameters along the path.
	Table of Contents		This draft only defines generic encoding rules and procedures.
			Specific encoding and procedures for each path parameter will be
			addressed in separate documents.
	1. Terminology 2		Table of Contents
	2. Introduction 2
	3. Overview of the Mechanism 4
	4. Path_Constraints TLV 5
	4.1. Description 5
	4.2. Format 5
	4.2.1. Path Parameter sub-TLV 6
	4.3. Elements of procedure 6
	5. The COMPOSITION object 7
	5.1. Format 7
	5.2. Elements of procedure 7
	6. Procedures to setup a TE-LSP with Path_Constraints 8
	6.1. Procedure for the Head-End LSR 8
	6.2. Procedure for a transit LSR 8
	6.3. Procedure for tail-end LSRs 9
	7. Bi-directional LSPs 9
	8. IANA Consideration 9
	8.1. New RSVP C-Num and C-Type 9
	8.2. New LSP Attributes TLV 10
	8.3. New Path Parameters TLV Space 10
	8.4. New Error Codes 10
	8.5. Security issues 10
	9. Intellectual Property Considerations 10
	10. Normative References 11
	11. Informative References 11
	12. Authors' Address 12
	Conventions used in this document		1. Terminology.................................................3
			2. Introduction................................................3
			3. Overview of the mechanism...................................4
			4. The Path_Constraints TLV....................................5
			4.1. Description.................................................5
			4.2. Format......................................................5
			4.2.1. Path Parameter sub-TLV......................................6
			4.3. Elements of procedure.......................................6
			5. The AGGREGATION object......................................7
			5.1. Format......................................................7
			5.2. Elements of procedure.......................................7
			6. Procedures to setup a TE-LSP with Path_Constraints..........8
			6.1. Procedure for the Head-End LSR..............................8
			6.2. Procedure for a transit/tail-end LSR........................8
			7. Procedures for Bidirectional LSPs..........................10
			8. Procedures for inter-domain LSPs...........................10
			9. IANA Consideration.........................................10
			9.1. New RSVP C-Num and C-Type..................................10
			9.2. New LSP Attributes TLV.....................................10
			9.3. New Path Parameters TLV Space:.............................10
			9.4. New Error Codes............................................11
			9.5. Security issues............................................11
			10. Normative References.......................................11
			11. Informative References.....................................12
			12. Authors' Address:..........................................12
			13. Intellectual Property Statement............................12
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		Conventions used in this document
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC-2119.
	1. Terminology		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in RFC-2119.
	This document uses terminology from the MPLS architecture document		Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt
	[RFC3031] and from the RSVP-TE protocol specification [RFC3209] which
	inherits from the RSVP specification [RFC2205]. It also makes uses of
	the Generalized MPLS RSVP-TE terminology introduced in [RFC3471] and
	[RFC3473].
	2. Introduction		1. Terminology
	Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt
	GMPLS control plane (see [GMPLS-ARCH]) supports routing and signaling		This document uses terminology from the MPLS architecture document
	of TE-LSPs for various switching technologies (PSC, L2SC, TDM, LSC,		[RFC3031] and from the RSVP-TE protocol specification [RFC3209] which
	FSC). Those generalized TE LSPs are routed along paths that respect a		inherits from the RSVP specification [RFC2205]. It also makes uses of
	set of TE constraints. Various TE constraints can be taken into		the Generalized MPLS RSVP-TE terminology introduced in [RFC3471] and
	account during path computation, such as, for instance, bandwidth,		[RFC3473].
	delay, hop-counts, and resource affinities.
	There are two types of TE constraints:		2. Introduction
	- Link constraints: bandwidth, affinities, etc.
	- Spatial Path_Constraints: delay, jitter, hop count, etc.
	- Spectral Path Constraints: polarization, signal power, etc.
	Some GMPLS Path_Constraints such as jitter apply only to statistical		GMPLS control plane (see [GMPLS-ARCH]) supports routing and signaling
	multiplexing layers (PSC, L2SC). Some constraints such as		of TE-LSPs for various switching technologies (PSC, L2SC, TDM, LSC,
	polarization or signal power, applies only to photonic layers. Some		FSC). Those generalized TE LSPs are routed along paths that respect a
	other constraints such as hop count apply to any switching layer.		set of TE constraints. Various TE constraints can be taken into
			account during path computation, such as, for instance, bandwidth,
			delay, hop-counts, and resource affinities.
	GMPLS Path parameters such as delay, hop count, signal power result		There are actually two types of TE LSP constraints:
	from the combination of link parameters. Their composition can be a		- Link constraints: bandwidth, affinities, etc.
	simple accumulation / reduction function but this may be a more		- Path_Constraints: delay, hop count, power loss, etc.
	complex function. For instance the delay of a path is simply the
	accumulation of hop delays.
	Current Generalized RSVP-TE [RFC3473] signals, and performs local		Some path constraints such as delay or hop count apply to any
	admission control based on link constraints only. Path_Constraints		switching capability. Some other path constraints apply only to a
	are not signaled within RSVP-TE.		subset of switching capabilities, such as power loss for instance.
	However there are some cases where it would be useful to signal paths		GMPLS Path parameters such as delay, hop count, power loss result
	constraints, and combine link parameters values along the path, in		from the aggregation of link parameters. Such aggregation is
	order to perform an admission control a tail-end LSR, based on		actually an addition of link parameters along the path. For instance
	Path_Constraints. This includes the following cases:		the delay of a path is the sum of hop delays.
	- The TE-LSP path has been computed taking into account		Current Generalized RSVP-TE [RFC3473] signals, and performs local
	Path_Constraints, but with incomplete information on link		admission control based on link constraints only. Path Constraints
	parameters, or estimated link parameters. In that case it		are not signaled within RSVP-TE.
	is useful to signal path constraint, and combine link
	parameters along the path, to let the tail-end perform
	admission control based on signaled constraints with
	respect to the composition of the corresponding link
	parameter(s). Also it is also useful to reflect actual path
	parameters value back to the Head-End LSR.
	- In case of inter-domain LSP it may be useful to signal		However in some situations, it would be useful to signal Paths
	Path_Constraints, and accumulate link parameters, so that a		Constraints, and aggregate link parameters values along the path, in
	border router can take them into account when doing ERO		order to perform an admission control based also on Path_Constraints.
	expansion (case of per-domain path computation in [INTER-		This includes the following situations:
	DOMAIN-COMP]).
	This draft defines Generalized RSVP-TE protocol extensions to allow		- The TE-LSP path has been computed taking into account
	for signaling of Path_Constraints, and accumulation of link		Path_Constraints, but with incomplete information on link
	parameters along the path.		parameters, or estimated link parameters. In that case it
			is useful to signal Path Constraints, and to aggregate link
			parameters along the path, so as to let LSRs perform
			admission control based on signaled constraints and aggregated
			link parameter(s). Also it is useful to reflect actual
			aggregated path parameters value back to the Head-End LSR.
	Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt		- In an inter-domain domain context (inter-area, inter-AS) it
			may be useful to signal Path_Constraints, and to aggregate
			link parameters, so that a border router can take them into
			account when doing ERO expansion (case of per-domain path
	The document is built as follows:		Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt
	- Section 3 gives an overview of the solution.		computation in [PD-PATH-COMP]). Also it may be useful to
	- Section 4 defines a new Path Constraint TLV, to be carried within		indicate to the head-end LSR the actual values of path
	the LSP_REQUIRED_ATTRIBUTE object, and used to encode Path		parameters, as they cannot be deduced from the RRO.
	Constraints.
	- Section 5 defines a new object called the COMPOSITION object, used
	to build path parameters based on a composition of link parameters
	along the signaled path.
	- Finally, section 6 defines elements of procedures for head-end,
	transit, and tail-end LSRs.
	This document only defines generic encoding and procedures. Specific		This draft defines Generalized RSVP-TE protocol extensions to allow
	encoding, procedures and accumulation rules is path parameter such as		for signaling of Path_Constraints, and for aggregation of link
	delay, hop count, jitter and LSP class specific and will be addressed		parameters along the path.
	in separate documents.
	3. Overview of the Mechanism		The document is built as follows:
	As mentioned in the previous section, it would be useful in various		- Section 3 gives an overview of the solution.
	situations to signal Path_Constraints such as maximum delay or		- Section 4 defines a new Path Constraints TLV, to be carried
	maximum hop count (in particular during for loose paths), within		within the LSP_REQUIRED_ATTRIBUTE object, and used to encode Path
	RSVP-TE, and to combine link parameters along the path, in order to		Constraints.
	determine path parameters such as path delay or path hop count.		- Section 5 defines a new object called the AGGREGATION object,
			used to build path parameters based on an aggregation of
			link parameters along the signaled path.
			- Finally, section 6 defines elements of procedures for head-end,
			transit, and tail-end LSRs.
	A new Path Constraints TLV is defined for being carried within the		This document only defines generic encoding and procedures. Specific
	LSP_REQUIRED_ATTRIBUTE object [LSP-ATTR]. It is used to carry		Encoding and procedures depend on each path parameter and will be
	particular value such as upper or lower bounds for a set of path		addressed in separate documents.
	parameters or a value range. Values are fixed by the head-end LSR and
	are not modified along the path.
	A new COMPOSITION object is defined to compose link parameter values		Note that procedures specific to the inter-domain case (inter-area or
	and determine end-to-end significant parameters along the path of the		inter-AS) will be addressed in a future revision.
	LSP. It is updated at each hop, basically each hop combines received
	value with its own contribution to the path parameter.
	The procedure to signal an LSP with Path_Constraints is as follows:		3. Overview of the mechanism
	- The head-end sends a Path message that includes:		As mentioned in the previous section, it would be useful in various
	- A Path Constraints TLV, included in a LSP_REQUIRED_ATTRIBUTE		situations (e.g. loose paths), to signal Path_Constraints such as
	object, that encodes for each path constraint a set of		maximum delay or maximum hop count within RSVP-TE, and to aggregate
	parameters.		associated link parameters along the path, in order to determine
	- An COMPOSITION object that contains a set of path		actual path parameters such as path delay or path hop count, and
	parameters, initially set to the least significant value.		perform admission control on these parameters.
	- At each transit LSR, each value included in the COMPOSITION		A new Path Constraints TLV is defined for being carried within the
	object value is updated based on local hop contribution to		LSP_REQUIRED_ATTRIBUTE object [LSP-ATTR]. It is used to carry
	each path parameter. It is assumed that the composition function		upper bounds for a set of path parameters. These values are fixed by
	is uniquely defined for each of these parameters.		the head-end LSR and are not modified along the path.
	- The tail-end LSR performs admission control for each		A new RSVP AGGREGATION object is defined so as to aggregate link
	parameter included in the Path_Constraints TLV. For each		parameter values along the path and determine end-to-end path
			parameters. It is updated at each hop, basically each hop combines
			received value with its own contribution to the path parameter.
	Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt		The procedures to signal an LSP with Path_Constraints are as follows:
	parameter, the composed value in the COMPOSITION object is		- The head-end sends a Path message that includes:
	compared with the constraint value included as part of the Path
	Constraints TLV.
	Admission control formulas are specific to each parameter		Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt
	and are not addressed in this document. If all constraints
	are acceptable by the tail-end LSR, the later sends back a
	Resv message, reflecting the COMPOSITION object that is passed
	unchanged back to the head-end LSR.
	- In case one (or more) constraints are violated, the tail-end LSR		- A Path Constraints TLV, included in a LSP_REQUIRED_ATTRIBUTE
	sends a PathErr message with the Path_State_Removed flag set		object, that carries a set of path constraints.
	[RFC3473], and with a new Error code and value that indicates the
	violated constraint. The PathErr message also includes the
	COMPOSITION object that is passed unchanged back to the head-end
	LSR.
	4. Path_Constraints TLV		- An AGGREGATION object that contains a set of path
			parameters, initially set to the least significant value.
	4.1. Description		- On each LSR along the path, each value included in the
			AGGREGATION object is updated based on local hop contribution to
			each path parameter. Admission control is then performed for each
			parameter included in the Path_Constraints TLV. The aggregate
			value in the AGGREGATION object is compared with the path
			constraint value included as part of the Path Constraints TLV.
	The Path_Constraints TLV is defined as a new Attribute TLV of the LSP		- If all constraints are respected then if the LSR is at transit
	REQUIRED ATTRIBUTE object. It exactly follows the processing rules		the Path message is propagated downstream and if the LSR is at
	defined in [LSP-ATTR].		tail-end, the AGGREGATION object is reflected in a Resv message
			and passed unchanged back to the head-end LSR. .
	It contains a set of Path Parameter sub-TLVs, each encoding the		- In case one (or more) constraints are violated, the LSR
	constraint value for a given path parameter. Path Parameter sub-TLVs		sends back a PathErr message with the Path_State_Removed flag
	are to be specified on a per QoS service basis.		Set [RFC3473], and with a new Error code and value that
			indicates the violated constraint. The PathErr message also
			includes the AGGREGATION object that is passed unchanged back
			to the head-end LSR.
	4.2. Format		4. The Path_Constraints TLV
	The Path Constraints TLV is encoded as follows		4.1. Description
	0 1 2 3		The Path_Constraints TLV is defined as a new Attribute TLV of the LSP
	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		REQUIRED ATTRIBUTE object. It exactly follows the processing rules
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		defined in [LSP-ATTR].
	| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	// Path Parameters sub-TLVs //
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: Path_Constraints		It contains a set of Path Parameter sub-TLVs, each encoding the
			constraint value for a given path parameter.
	IANA has been asked to manage the space of TLV types in the		4.2. Format
	REQUIRED_LSP_ATTRIBUTES Object [LSP-ATTRIB]. This document suggest
	Type = 2 for the Path Constraints TLV.
	Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt		The Path Constraints TLV is encoded as follows
	4.2.1. Path Parameter sub-TLV		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 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			// Path Parameters sub-TLVs //
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Each path parameter sub-TLV encodes constraint value of a path		Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt
	parameter. It has the following format:
	0 1 2 3		Type: Path_Constraints
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	// Path Parameter Value //
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type:		IANA has been asked to manage the space of TLV types in the
			REQUIRED_LSP_ATTRIBUTES Object [LSP-ATTRIB]. This document suggest
			Type = 2 for the Path Constraints TLV.
	The identifier of the path parameter.		Value: A set of one or more Path Parameter sub-TLVs
	Length:		4.2.1. Path Parameter sub-TLV
	The length of the value field in bytes. Thus if no value field		A path parameter sub-TLV encodes the value of a path
	is present the length field contains the value zero.		parameter. It can be carried within a Path Constraints TLV of an
			LSP_REQUIRED_ATTRIBUTE object, or an AGGREGATION object. It has the
			following format:
	Each value field must be zero padded at the end to take it up		0 1 2 3
	to a four byte boundary - the padding is not included in the		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
	length so that a one byte value would be encoded in an eight		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	byte TLV with length field set to one.		|X| Type | Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			// Path Parameter Value //
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Path Parameter Value:		X: Break bit, used to indicate that at least one LSR on the path
			did not recognize and proceed the parameter.
	Scalar value of the path parameter. The unit will depend on		Type: 15 bits identifier of the path parameter.
	on the type of parameter and will be defined in the document
	that introduces the parameter.
	4.3. Elements of procedure		Length:
	An LSR that does not recognize a parameter type in the Path		The length of the value field in bytes. Thus if no value field
	Constraint TLV MUST reject the Path message using a Path Error with		is present the length field contains the value zero.
	Error Code "Unknown Path Parameter" and Error Value set to the
	parameter type.
	To avoid high rejection rate, a break bit (X) is introduced.		Each value field must be zero padded at the end to take it up
	Moreover, as values can be correlated to deliver a given service, it		to a four byte boundary - the padding is not included in the
	is expected that the processing of this bit will be defined such that		length so that a one byte value would be encoded in an eight
	it applies to the set of the corresponding Path Parameter sub-TLVs.		byte TLV with length field set to one.
	0 1 2 3		Path Parameter Value:
	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 |X| Flags | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt		Scalar value of the path parameter. The unit will depend on
			on the type of parameter and will be defined in the document
			that introduces the parameter.
	| |		4.3. Elements of procedure
	// Path Parameter Value //		Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	5. The COMPOSITION object		An LSR that does not recognize the Path Constraints TLV or recoginze
			it but does not support it MUST reject the Path message using an
			Error code "Unknown Attributes TLV" and an error value identifying
			the unknown TLV type code.
	The COMPOSITION object is used to build path parameters, by combining		An LSR that does not recognize a parameter type in the Path
	hop parameters along the signaled path.		Constraint TLV MUST set the break bit for this parameter.
	It is carried within a Path message and updated at each hop. This		5. The AGGREGATION object
	object is also be carried in Resv and PathErr message, where it is
	passed unchanged, with no update at any hop.
	5.1. Format		The AGGREGATION object is used to build path parameters, by
			cumulating hop parameters along the signaled path.
	The COMPOSITION object contains a set of Composed Path Parameter TLVs		It is carried within a Path message and updated at each hop. This
	whose encoding is defined in 2.2.1, each TLV corresponding to a given		object is also be carried in Resv and PathErr message, where it is
	accumulated parameter along the path.		passed unchanged.
	Note that a given parameter must have the same type, when carried in		5.1. Format
	the LSP_REQUIRED ATTRIBUTE object or in the COMPOSITION object.
	Class = 10bbbbbb, C-Type = Composed Path Parameter TLVs		The AGGREGATION object contains a set of Path Parameter TLVs
			whose encoding is defined in 4.2.1. Each TLV corresponds to a given
			accumulated parameter along the path.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		Note that a given parameter must have the same TLV type, when carried
	| |		in the LSP_REQUIRED ATTRIBUTE object or in the AGGREGATION object.
	| |
	// Composed Path Parameter TLVs //
	| |
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	To avoid a too massive rejection break bit (X) is introduced.		Class = 0bbbbbbb, C-Type = Path Parameter TLVs
	Moreover, as values can be correlated to deliver a given service, it
	is expected that the processing of this bit will be defined such that
	it applies to the set of the corresponding sub-TLVs.
	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 |X| Flags | Length |		// Path Parameter TLVs //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| |
	| |		| |
	// Composed Parameter Value //		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	5.2. Elements of procedure		5.2. Elements of procedure
	The ACCUMLATOR object has a C-Num of form 10bbbbbb. That is, an LSR		The AGGREGATION object has a C-Num of form 0bbbbbbb. That is, an LSR
	that does not recognize this object should discard it silently.		that does not recognize this object should reject the LSP and send
			back a PathErr with the appropriate error code.
	Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt		An LSR that does not recognize a parameter type in AGGREGATION object
			MUST set the break bit for this parameter.
	An LSR that recognize this object but does not recognize a path		Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt
	parameter should set the break bit X. It is upon tail-end LSR
	decision (and subsequently the head-end LSR) to decide whether a non-
	complete composition is satisfactory or not for the whole Path.
	6. Procedures to setup a TE-LSP with Path_Constraints		6. Procedures to setup a TE-LSP with Path Constraints
	6.1. Procedure for the Head-End LSR		6.1. Procedure for the Head-End LSR
	To signal a LSP subject to a set of path_constraints, the head-end		To signal a LSP subject to a set of path constraints, the head-end
	LSR sends a Path message that contains a Path Constraints TLV		LSR sends a Path message that contains a Path Constraints TLV
	included within a LSP_REQUIRED_ATTRIBUTE object. Path_constraints are		included within a LSP_REQUIRED_ATTRIBUTE object. Path_constraints are
	encoded within Path Parameter sub-TLVs.		encoded within Path Parameter sub-TLVs.
	Note that the type of constraints and constraint values may be		Note that the type of constraints and constraint values may be
	subject to change during the life of the LSP but are under full		subject to change during the life of the LSP but are under full
	control of the head-end LSR.		control of the head-end LSR.
	The Path message sent by the head-end LSR also contains an		The Path message sent by the head-end LSR also contains an
	COMPOSITION object. Values in path parameters TLVs are initialized		AGGREGATION object. Values in path parameters TLVs are initialized
	following rules specific to each parameter. These specific rules are		following rules specific to each parameter. These specific rules are
	out of the scope of this document, and will be addressed in documents		out of the scope of this document, and will be addressed in documents
	introducing the parameters.		introducing the parameters.
	Note that all path parameters present in the Path_Constraints TLV,		Note that all path parameters present in the Path_Constraints TLV,
	MUST also appear in the COMPOSITION Object. In return some path		MUST also appear in the AGGREGATION Object. In return some path
	parameters not subject to admission control may be present in the		parameters not subject to admission control may be present in the
	COMPOSITION object, and not in the Path_Constraints TLV.		AGGREGATION object, and not in the Path_Constraints TLV.
	On receipt of a Resv message with a COMPOSITION object, the head-end		Note that the break bit of all parameters in the AGGREGATION object
	LSR will be aware of the current LSP path parameters. The processing		and the Path Constraints TLV MUST be initially cleared.
	of these values by the Head-End LSR will be addressed in documents
	defining the path parameters.
	6.2. Procedure for a transit LSR		On receipt of a Resv message with a AGGREGATION object, the head-end
			LSR will be aware of the current LSP path parameters. The processing
			of these values by the Head-End LSR will be addressed in documents
			defining the path parameters.
	A Transit LSR MUST update each path parameter of a COMPOSITION object		6.2. Procedure for a transit/tail-end LSR
	received in a Path message, and forward the updated object in the
	Path message sent downstream. Basically, for each path parameter it
	should combine the received value with its own "contribution" to the
	parameter. Combination rule depend on the parameter type, and must be
	addressed in the document defining the path parameter.
	When its local contribution changes, a transit LSR SHOULD send a Path		On receipt of a Path message with an AGGREGATION object and no Path
	message downstream with an appropriately updated COMPOSITION object.		Constraint TLV, an LSR MUST update each recognized and supported path
			parameter of the AGGREGATION object. For each path parameter it has
			to accumulate the received value with its own "contribution" to the
			parameter. If the LSR does not recognize or recognize but does not
			support a given path parameter it should set the break bit of this
			parameter to 1.
			If the LSR is at transit it MUST forward the Path message downstream
			with the updated AGGREGATION object. If the LSR is at tail-end it
			MUST reflect the updated AGGREGATION object in a Resv message sent
			back to the head-end LSR.
	A COMPOSITION object included in a Resv message MUST be forwarded		On receipt of a Path message with an AGGREGATION object and a Path
	transparently by a transit LSR.		Constraint TLV in the LSP_REQUIRED_ATTRIBUTE object, an LSR MUST
			firstly update each path parameter of the AGGREGATION object. If a
			parameter is not recognized it should set the break bit of this
			parameter to 1. Then it MUST perform local admission control for each
			recognized and supported path parameter included in the Path
	The Path_Constraints TLV included in a Path/Resv message MUST be		Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt
	forwarded transparently by a transit LSR.
	Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt		Constraints TLV, by verifying that aggregated path parameters does
			not exceed path constraints.
	6.3. Procedure for tail-end LSRs		- If all constraints are respected and all break bit are cleared
			then if the LSR is at transit the Path message is forwarded
			downstream with the updated AGGREGATION object and if the LSR
			is at tail-end the updated AGGREGATION object is included in a
			Resv message sent back to the head-end LSR.
	On receipt of a Path message containing a COMPOSITION object and no		- If at least one constraint is violated, then the LSP MUST be
	Path_Constraints TLV, a tail-end LSR MUST reflect the COMPOSITION		rejected, whatever the break bit value and a PathErr is sent
	object unchanged in a Resv message upstream to the head-end LSR.		back to the Head-End LSR with the Path_State_Removed flag set
			and a new Error code ("path constraint violation"), and error
			value corresponding to the TLV type of the violated
			constraint. This PathErr message MUST also reflect the
			AGGREGATION object unchanged.
	On receipt of a Path message containing both a COMPOSITION object and		- If at least one locally supported parameter has the break bit
	a Path_Constraints TLV in the LSP_REQUIRED_ATTRIBUTE object, the		set and the constraint is respected, then the LSP may be
	tail-end LSR MUST perform an admission control for each path		rejected or not depending on local policy decision. If it is
	parameter constraint in the Path_Constraints TLV. Each path parameter		rejected a PAthErr message with the error code "Unsupported
	constraint must be compared, with the accumulated parameter value.		Path Parameter" and error value corresponding to the
	Comparison rules will be addressed in documents defining the path		unsupported TLV type MUST be generated.
	parameters.		This PathErr message MUST also reflect the AGGREGATION object
			unchanged.
	If no constraint is violated, the COMPOSITION object MUST be		- If there is at least one locally unsupported parameter then
	reflected unchanged in a Resv message sent upstream.		the LSP may be rejected or not depending on local policy
			decision. If it is rejected a PAthErr message with the error
			code "Unsupported Path Parameter" and error value
			corresponding to the unsupported TLV type MUST be generated.
			This PathErr message MUST also reflect the AGGREGATION object
			unchanged.
	If at least one constraint is violated, the LSP must be rejected, and		Note that path parameters included in the AGGREGATION object, but not
	the tail-end LSR must send a PathErr message with the		in the Path Constraints TLV are not subject to a local admission
	Path_State_Removed flag set, and with a new Error code (path		control.
	constraint violation, and error value corresponding to the violated
	constraint.
	This PathErr message MUST also reflect the COMPOSITION object		When its local contribution changes, a transit LSR SHOULD perform
	unchanged.		admission control and send a Path message downstream with an updated
			AGGREGATION object.
	7. Bi-directional LSPs		An AGGREGATION object included in a Resv message MUST be forwarded
			transparently by a transit LSR.
	TBD		The Path_Constraints TLV included in a Path/Resv message MUST be
			forwarded transparently by a transit LSR.
	8. IANA Consideration		The Break bit of a parameter TLV MUST never be cleared by any LSR.
	8.1. New RSVP C-Num and C-Type		Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt
	One new RSVP C-Num is defined in this document and should be		7. Procedures for Bidirectional LSPs
	assigned by IANA.
	o COMPOSITION object		TBD
	The C-Num should be of the form 10bbbbbb so that LSRs that do not		8. Procedures for inter-domain LSPs
	recognize the object will ignore the object and discard it silently.
	One C-Type is defined for this object and should be assigned by IANA.		TBD
	o Path Parameter TLVs		9. IANA Consideration
	Recommended C-Type value 1.		9.1. New RSVP C-Num and C-Type
	Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt		One new RSVP C-Num is defined in this document and should be
			assigned by IANA.
	8.2. New LSP Attributes TLV		o AGGREGATION object
	This document defines one LSP Attributes TLV type as		The C-Num should be of the form 0bbbbbbb so that LSRs that do not
	follows:		recognize the object reject the LSP.
	- TLV Type Suggested value = 2
	- TLV Name = Path_Constraints
	- allowed on LSP_REQUIRED_ATTRIBUTES object.
	8.3. New Path Parameters TLV Space:		One C-Type is defined for this object and should be assigned by IANA.
	The COMPOSITION object and the Path Constraints TLV defined above are		o Path Parameter TLVs
	constructed from TLVs. Each TLV correspond to a particular path
	parameter. Each TLV includes a 16-bit type identifier (the T-field).
	The same T-field values are applicable to the COMPOSITION object and
	the Path Constraints TLV.
	IANA is requested to manage TLV type identifiers as follows:		Recommended C-Type value = 1.
	- TLV Type (T-field value)		9.2. New LSP Attributes TLV
	- TLV Name
	8.4. New Error Codes		This document defines one LSP Attributes TLV type as
			follows:
			- TLV Type Suggested value = 2
			- TLV Name = Path_Constraints
			- allowed on LSP_REQUIRED_ATTRIBUTES object.
	This document defines the following new error codes and error values.		9.3. New Path Parameters TLV Space:
	Numeric values should be assigned by IANA.
	Error Code Error Value		The AGGREGATION object and the Path Constraints TLV defined above are
			constructed from TLVs. Each TLV correspond to a particular path
			parameter. Each TLV includes a 15-bit type identifier (the T-field).
			The same T-field values are applicable to the AGGREGATION object and
			the Path Constraints TLV.
	"Unknown Path parameter TLV" Identifies the unknown TLV type code.		IANA is requested to manage Path Parameter TLV type identifiers as
	"Path Constraint Violaton" Identifies the TLV type of the violated		follows:
	constraint.
	8.5. Security issues		- TLV Type (T-field value)
			- TLV Name: Name of the Path Parameter
			- RFC:
	This document adds one new object to the RSVP Path/Resv message, and		Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt
	a new TLV to the LSP_REQUIRED_ATTRIBUTE object.
	It does not introduce any new direct security issues and the reader		9.4. New Error Codes
	is referred to the security considerations expressed in [RFC2205],
	[RFC3209] and [RFC3473].
	9. Intellectual Property Considerations		This document defines the following new RSVP error codes and error
			values. Numeric values should be assigned by IANA.
	The IETF takes no position regarding the validity or scope of any		Error Code Error Value
	Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		"Unknown Path parameter TLV" Identifies the unknown TLV type code.
	on the procedures with respect to rights in RFC documents can be		"Path Constraint Violation" Identifies the TLV type of the
	found in BCP 78 and BCP 79.		violated constraint.
	Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt		9.5. Security issues
	Copies of IPR disclosures made to the IETF Secretariat and any		This document adds one new object to the RSVP Path/Resv message, and
	assurances of licenses to be made available, or the result of an		a new TLV to the LSP_REQUIRED_ATTRIBUTE object.
	attempt made to obtain a general license or permission for the use of		It does not introduce any new direct security issues and the reader
	such proprietary rights by implementers or users of this		is referred to the security considerations expressed in [RFC2205],
	specification can be obtained from the IETF on-line IPR repository at		[RFC3209] and [RFC3473].
	http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		10. Normative References
	copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.
	10. Normative References		[RFC2119] Bradner, S., 'Key words for use in RFCs to indicate
			requirements levels', RFC 2119, March 1997.
	[RFC2119] Bradner, S., "Key words for use in RFCs to indicate		[RFC3667] Bradner, S., 'IETF Rights in Contributions', BCP 78,
	requirements levels", RFC 2119, March 1997.		RFC 3667, February 2004.
	[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,		[RFC3668] Bradner, S., Ed., 'Intellectual Property Rights in IETF
	RFC 3667, February 2004.		Technology', BCP 79, RFC 3668, February 2004.
	[RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF		[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
	Technology", BCP 79, RFC 3668, February 2004.		'Resource ReSerVation Protocol (RSVP) -- Version 1, Functional
			Specification', RFC 2205, September 1997.
	[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,		[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,
	"Resource ReSerVation Protocol (RSVP) -- Version 1,		Srinivasan, V. and G. Swallow, 'RSVP-TE: Extensions
	Functional Specification", RFC 2205, September 1997.		to RSVP for LSP Tunnels', RFC 3209, December 2001.
	[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,		[RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label
	Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions		Switching (GMPLS) Signaling Functional Description",
	to RSVP for LSP Tunnels", RFC 3209, December 2001.		RFC 3471, January 2003.
	[RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label		[RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling -
	Switching (GMPLS) Signaling Functional Description",		RSVP-TE Extensions", RFC 3473, January 2003.
	RFC 3471, January 2003.
	[RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling -		[LSP-ATTR] A. Farrel, et. al. , "Encoding of Attributes for MPLS LSP
	RSVP-TE Extensions", RFC 3473, January 2003.		Establishment Using RSVP-TE" draft-ietf-mpls-rsvpte-
			attributes, work in progress.
	[LSP-ATTR] A. Farrel, et. al. , "Encoding of Attributes for MPLS		Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt
	LSP Establishment Using RSVP-TE", Work in Progress,
	draft-ietf-mpls-rsvpte-attributes-05.txt, May 2005.
	11. Informative References		11. Informative References
	[GMPLS-ARCH] E.Mannie (Editor) et al., "Generalized Multi-Protocol		[GMPLS-ARCH] E.Mannie (Editor) et al., "Generalized Multi-Protocol
	Label Switching (GMPLS) Architecture", RFC 3945, October		Label Switching (GMPLS) Architecture", Internet Draft,
	2005.		Work in Progress, draft-ietf-ccamp-gmpls-architecture-
			07.txt, May 2003.
	[INTER-DOMAIN-COMP] Vasseur JP., Ayyangar A., Zhang R., "Inter-		[PD-PATH-COMP] Vasseur, J.P., Ayyangar, A., Zhang, R., " A Per-domain
	domain MPLS Traffic Engineering LSP path		path computation method for computing Inter-domain
			Traffic Engineering (TE) Label Switched Path (LSP)",
			draft-ietf-ccamp-inter-domain-pd-path-comp, work in
			progress.
	Internet Draft draft-leroux-ccamp-rsvp-te-path-const-00.txt		12. Authors' Address:
	computation methods", (work in progress).		Jean-Louis Le Roux
			France Telecom
			2, avenue Pierre-Marzin
			22307 Lannion Cedex
			France
			jeanlouis.leroux@francetelecom.com
	12. Authors' Address		Dimitri Papadimitriou
			Alcatel
			Francis Wellensplein 1,
			B-2018 Antwerpen, Belgium
			Phone : +32 3 240 8491
			EMail: dimitri.papadimitriou@alcatel.be
	Jean-Louis Le Roux		13. Intellectual Property Statement
	France Telecom
	2, avenue Pierre-Marzin
	22307 Lannion Cedex
	France
	jeanlouis.leroux@francetelecom.com
	Dimitri Papadimitriou		The IETF takes no position regarding the validity or scope of any
	Alcatel		Intellectual Property Rights or other rights that might be claimed to
	Francis Wellensplein 1,		pertain to the implementation or use of the technology described in
	B-2018 Antwerpen, Belgium		this document or the extent to which any license under such rights
	Phone : +32 3 240 8491		might or might not be available; nor does it represent that it has
	EMail: dimitri.papadimitriou@alcatel.be		made any independent effort to identify any such rights. Information
			on the procedures with respect to rights in RFC documents can be
			found in BCP 78 and BCP 79.
	13. Full Copyright Statement		Copies of IPR disclosures made to the IETF Secretariat and any
			assurances of licenses to be made available, or the result of an
			attempt made to obtain a general license or permission for the use of
			such proprietary rights by implementers or users of this
			specification can be obtained from the IETF on-line IPR repository at
			http://www.ietf.org/ipr.
	Copyright (C) The Internet Society (2005). This document is subject		The IETF invites any interested party to bring to its attention any
	to the rights, licenses and restrictions contained in BCP 78, and		copyrights, patents or patent applications, or other proprietary
	except as set forth therein, the authors retain all their rights.		rights that may cover technology that may be required to implement
	This document and the information contained herein are provided on an		Internet Draft draft-leroux-ccamp-rsvp-te-path-constr-01.txt
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		this standard. Please address the information to the IETF at
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ietf-ipr@ietf.org.
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		Disclaimer of Validity
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
			ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
			INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
			INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Copyright Statement
			Copyright (C) The Internet Society (2005). This document is subject
			to the rights, licenses and restrictions contained in BCP 78, and
			except as set forth therein, the authors retain all their rights.
End of changes. 157 change blocks.
	453 lines changed or deleted		452 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/