< draft-ietf-pce-disco-proto-igp-00.txt		draft-ietf-pce-disco-proto-igp-01.txt >
	Network Working Group J.L. Le Roux (Editor)		Network Working Group J.L. Le Roux (Editor)
	Internet Draft France Telecom		Internet Draft France Telecom
	Category: Standard Track J.P. Vasseur (Editor)		Category: Standard Track
	Expires: May 2006 Cisco System Inc.		Expires: September 2006 J.P. Vasseur (Editor)
			Cisco System Inc.
	Yuichi Ikejiri		Yuichi Ikejiri
	NTT		NTT Communications
	December 2005		Raymond Zhang
			BT Infonet
			March 2006
	IGP protocol extensions for Path Computation Element (PCE) Discovery		IGP protocol extensions for Path Computation Element (PCE) Discovery
	draft-ietf-pce-disco-proto-igp-00.txt		draft-ietf-pce-disco-proto-igp-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		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		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.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that other		Task Force (IETF), its areas, and its working groups. Note that other
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 45 ¶
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Abstract		Abstract
	In various situations it would be highly useful for a Path		There are various circumstances in which it is highly desirable for a
	Computation Client (PCC) to be able to dynamically and automatically		Path Computation Client (PCC) to be able to dynamically and
	discover a set of Path Computation Element(s) (PCE), along with some		automatically discover a set of Path Computation Element(s) (PCE),
	of information relevant for PCE selection. When the PCE is an LSR		along with some of information that can used for PCE selection. When
	participating to the IGP, or even a server participating passively to		the PCE is an LSR participating to the IGP, or even a server
	the IGP, a simple and efficient way for PCE discovery, consists of		participating passively to the IGP, a simple and efficient way for
	relying on IGP flooding. For that purpose this document defines		PCE discovery consists of relying on IGP flooding. For that purpose
	simple OSPF and ISIS extensions for the advertisement of PCE		this document defines OSPF and ISIS extensions for the advertisement
	Discovery information within and across IGP areas.		of PCE Discovery information within an IGP area or the entire routing
			domain.
	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 this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC-2119.		document are to be interpreted as described in RFC-2119.
	Table of Contents		Table of Contents
	1. Note........................................................3		1. Note........................................................3
	2. Terminology.................................................3		2. Terminology.................................................3
	3. Introduction................................................4		3. Introduction................................................4
	4. PCE Discovery Information...................................5		4. Overview....................................................5
	4.1. Description.................................................5		4.1. PCE Information.............................................5
	4.2. Mandatory versus optional PCE information...................5		4.1.1. PCE Discovery Information...................................5
	4.3. Flooding scope..............................................5		4.1.2. PCE Status Information......................................6
	4.4. Frequency of change.........................................6		4.2. Flooding scope..............................................6
	5. OSPF extensions.............................................6		5. OSPF extensions.............................................6
	5.1. The OSPF PCED TLV...........................................6		5.1. The OSPF PCED TLV...........................................6
	5.1.1. PCE-ADDRESS sub-TLV.........................................7		5.1.1. PCE-ADDRESS sub-TLV.........................................8
	5.1.2. PATH-SCOPE sub-TLV..........................................8		5.1.2. PATH-SCOPE sub-TLV..........................................8
	5.1.3. PCE-DOMAINS sub-TLV.........................................9		5.1.3. PCE-DOMAINS sub-TLV........................................10
	5.1.3.1. IPv4 area ID DOMAIN sub-TLV..............................10		5.1.3.1. IPv4 area ID DOMAIN sub-TLV..............................11
	5.1.3.2. IPv6 area ID DOMAIN sub-TLV..............................11		5.1.3.2. IPv6 area ID DOMAIN sub-TLV..............................11
	5.1.3.3. AS Number sub-TLV........................................11		5.1.3.3. AS Number sub-TLV........................................12
	5.1.4. PCE-DEST-DOMAINS sub-TLV...................................11		5.1.4. PCE-DEST-DOMAINS sub-TLV...................................12
	5.1.5. The GENERAL-CAP sub-TLV....................................12		5.1.5. GENERAL-CAP sub-TLV........................................13
	5.1.6. The PATH-COMP-CAP sub-TLV..................................13		5.1.6. The PATH-COMP-CAP sub-TLV..................................14
	5.2. Elements of Procedure......................................14		5.2. The OSPF PCES TLV..........................................15
	6. ISIS extensions............................................16		5.2.1. The CONGESTION sub-TLV.....................................16
	6.1. IS-IS PCED TLV format......................................16		5.3. Elements of Procedure......................................16
	6.1.1. PCE-ADDRESS sub-TLV........................................17		5.3.1. PCED TLV Procedure.........................................17
	6.1.2. The PATH-SCOPE sub-TLV.....................................17		5.3.2. PCES TLV procedure.........................................17
	6.1.3. PCE-DOMAINS sub-TLV........................................19		6. ISIS extensions............................................19
	6.1.3.1. Area ID DOMAIN sub-TLV...................................19		6.1. IS-IS PCED TLV format......................................19
	6.1.3.2. AS Number DOMAIN sub-TLV.................................19		6.1.1. PCE-ADDRESS sub-TLV........................................20
	6.1.4. PCE-DEST-DOMAINS sub-TLV...................................20		6.1.2. The PATH-SCOPE sub-TLV.....................................20
	6.1.5. GENERAL-CAP sub-TLV........................................20		6.1.3. PCE-DOMAINS sub-TLV........................................22
	6.1.6. The PATH-COMP-CAP sub-TLV..................................21		6.1.3.1. Area ID DOMAIN sub-TLV...................................22
	6.2. Elements of procedure......................................22		6.1.3.2. AS Number DOMAIN sub-TLV.................................23
	7. Backward compatibility.....................................22		6.1.4. PCE-DEST-DOMAINS sub-TLV...................................23
	8. Security Considerations....................................22		6.1.5. GENERAL-CAP sub-TLV........................................23
	9. IANA considerations........................................22		6.1.6. The PATH-COMP-CAP sub-TLV..................................24
	9.1. OSPF TLVs..................................................22		6.2. The ISIS PCES TLV..........................................25
	9.2. ISIS TLVs..................................................23		6.2.1. The CONGESTION sub-TLV.....................................25
	9.3. Capability bits............................................23		6.3. Elements of Procedure......................................26
	10. Security Considerations....................................24		6.3.1. PCED TLV Procedure.........................................26
	11. References.................................................24		6.3.2. PCES TLV procedure.........................................27
	11.1. Normative references.......................................24		7. Backward compatibility.....................................27
	11.2. Informative references.....................................24		8. IANA considerations........................................28
	12. Authors' Addresses:........................................25		8.1. OSPF TLVs..................................................28
	13. Intellectual Property Statement............................25		8.2. ISIS TLVs..................................................28
			8.3. Capability bits............................................29
			9. Security Considerations....................................29
			10. References.................................................29
			10.1. Normative references........................................29
			10.2. Informative references......................................30
			11. Authors' Addresses:........................................30
			12. Intellectual Property Statement............................31
	1. Note		1. Note
	This document specifies new TLVs and sub-TLVs to be carried within		This document specifies new TLVs and sub-TLVs to be carried within
	the OSPF Router information LSA ([OSPF-CAP]) and ISIS Router		the OSPF Router information LSA ([OSPF-CAP]) and ISIS Router
	Capability TLV ([ISIS-CAP]). Because this document does not introduce		Capability TLV ([ISIS-CAP]) respectively. Because this document does
	any new element of procedure it will be discussed within the PCE		not introduce any new element of procedure it will be discussed
	Working Group with a review of the OSPF and ISIS Working Groups.		within the PCE Working Group with a review of the OSPF and ISIS
	Furthermore, once stabilized, it may be decided to split the document		Working Groups. Furthermore, once stabilized, it may be decided to
	in two documents addressing the OSPF and ISIS aspects respectively.		split the document in two documents addressing the OSPF and ISIS
			aspects respectively.
	2. Terminology		2. Terminology
	Terminology used in this document		Terminology used in this document
	LSR: Label Switch Router		ABR: IGP Area Border Router (OSPF ABR or ISIS L1L2 router).
	TE LSP: Traffic Engineered Label Switched Path
	PCE: Path Computation Element: an entity (component, application,
	or network node) that is capable of computing a network path or
	route based on a network graph, and applying computational
	constraints.
	PCC: Path Computation Client: any client application requesting a
	path computation to be performed by a Path Computation Element.
	IGP Area: OSPF Area or ISIS level		AS: Autonomous System.
	ABR: IGP Area Border Router (OSPF ABR or ISIS L1L2 router)		ASBR: AS Border Router.
	AS: Autonomous System		Domain: any collection of network elements within a common sphere
			of address management or path computational responsibility.
			Examples of domains include IGP areas and Autonomous Systems.
	ASBR: AS Border Router		IGP Area: OSPF Area or ISIS level.
	Intra-area TE LSP: A TE LSP whose path does not cross IGP area		Intra-area TE LSP: A TE LSP whose path does not cross IGP area
	boundaries.		boundaries.
	Inter-area TE LSP: A TE LSP whose path transits through		Inter-area TE LSP: A TE LSP whose path transits through
	two or more IGP areas.		two or more IGP areas.
	Inter-AS MPLS TE LSP: A TE LSP whose path transits		Inter-AS MPLS TE LSP: A TE LSP whose path transits
	through two or more ASes or sub-ASes (BGP confederations).		through two or more ASes or sub-ASes (BGP confederations).
	Domain: any collection of network elements within a common sphere		LSR: Label Switch Router.
	of address management or path computational responsibility.
	Examples of domains include IGP areas and Autonomous Systems.		PCC: Path Computation Client: any client application requesting a
			path computation to be performed by a Path Computation Element.
			PCE: Path Computation Element: an entity (component, application,
			or network node) that is capable of computing a network path or
			route based on a network graph, and applying computational
			constraints.
			PCECP: Path Computation Element Communication Protocol.
			TE LSP: Traffic Engineered Label Switched Path
	3. Introduction		3. Introduction
	[PCE-ARCH] describes the motivations and architecture for a PCE-based		[PCE-ARCH] describes the motivations and architecture for a PCE-based
	path computation model for MPLS and GMPLS TE LSPs. The model allows		path computation model for MPLS and GMPLS TE LSPs. The model allows
	the separation of PCE from PCC (also referred to as non co-located		the separation of PCE from PCC (also referred to as non co-located
	PCE) and allows cooperation between PCEs. This relies on a		PCE) and allows cooperation between PCEs. This relies on a
	communication protocol between PCC and PCE, and between PCEs, whose		communication protocol between PCC and PCE, and between PCEs. The
	generic requirements are listed in [PCE-COM-REQ].		requirements for such communication protocol can be found in [PCECP-
			REQ] and the communication protocol is defined in [PCEP].
	The PCE architecture requires, of course, that a PCC be aware of the		The PCE architecture requires, of course, that a PCC be aware of the
	location of one or more PCEs in its domain, and also potentially of		location of one or more PCEs in its domain, and also potentially of
	some PCEs in other domains, e.g. in case of inter-domain path		some PCEs in other domains, e.g. in case of inter-domain TE LSP
	computation.		computation.
	A network may comprise a large number of PCEs with potentially		A network may comprise a large number of PCEs with potentially
	distinct capabilities. In such context it would be highly desirable		distinct capabilities. In such context it would be highly desirable
	to have a mechanism for automatic and dynamic PCE discovery, which		to have a mechanism for automatic and dynamic PCE discovery, which
	would allow PCCs to automatically discover a set of PCEs, including		would allow PCCs to automatically discover a set of PCEs, along with
	information required for PCE selection, and to dynamically detect new		additional information required for PCE selection, and to dynamically
	PCEs or any modification of PCE information. This includes the		detect new PCEs or any modification of PCE information.
	discovery by a PCC of a set of one or more PCEs in its domain, and
	potentially in some other domains. The latter is a desirable function
	in the case of inter-domain path computation for example.
	Detailed requirements for such a PCE discovery mechanism are		Detailed requirements for such a PCE discovery mechanism are
	described in [PCE-DISCO-REQ].		described in [PCE-DISCO-REQ].
			Moreover, it may also be useful to discover when a PCE experiences
			some processing congestion state and exits such state in order for
			the PCCs to take some appropriate actions (e.g. redirect to another
			PCE). Note that the PCE selection algorithm is out of the scope of
			this document.
	When PCCs are LSRs participating to the IGP (OSPF, ISIS), and PCEs		When PCCs are LSRs participating to the IGP (OSPF, ISIS), and PCEs
	are LSRs participating to the IGP or any network servers		are LSRs or a servers also participating to the IGP, an efficient
	participating to the IGP, an efficient mechanism for PCE discovery		mechanism for PCE discovery within an IGP routing domain consists of
	consists of relying on IGP advertisement.		relying on IGP advertisements.
	This document defines OSPF and ISIS extensions allowing a PCE		This document defines OSPF and ISIS extensions allowing a PCE
	participating to the IGP to advertise its location along with some		participating in the IGP to advertise its location along with some
	information useful for PCE selection so as to satisfy dynamic PCE		information useful for PCE selection so as to satisfy dynamic PCE
	discovery requirements set forth in [PCE-DISC-REQ].		discovery requirements set forth in [PCE-DISC-REQ]. This document
			also defines extensions allowing a PCE participating to the IGP to
			advertise its potential processing congestion state.
	Generic capability mechanisms have been defined in [OSPF-CAP] and		Generic capability mechanisms have been defined in [OSPF-CAP] and
	[ISIS-CAP] for OSPF and ISIS respectively the purpose of which is to		[ISIS-CAP] for OSPF and ISIS respectively the purpose of which is to
	allow a router to advertise its capability within an IGP area or an		allow a router to advertise its capability within an IGP area or an
	entire routing domain. This perfectly fits with the aforementioned		entire routing domain. Such IGP extensions fully satisfy the
	dynamic PCE discovery requirements. Thus, a new TLV (named the PCE		aforementioned dynamic PCE discovery requirements.
	Discovery (PCED) TLV) is defined for ISIS and OSPF to be carried
	within the ISIS Capability TLV ([ISIS-CAP]) for ISIS and the OSPF
	Router Information LSA ([OSPF-CAP]).
	The PCE discovery information is detailed in section 3. Protocol		This document defines two new TLVs (named the PCE Discovery (PCED)
	extensions and procedures are defined in section 4 and 5 for ISIS and		TLV and the PCE Status (PCES) TLV) for ISIS and OSPF to be carried
	OSPF respectively. This document does not define any new OSPF or ISIS		within the ISIS Capability TLV ([ISIS-CAP]) and the OSPF Router
	element of procedure but how the procedures defined in [OSPF-CAP] and		Information LSA ([OSPF-CAP]).
	[ISIS-CAP] should be used.
	The routing extensions defined in this document allow for PCE		The PCE information advertised is detailed in section 4. Protocol
	discovery within and across IGP areas. Solutions for PCE discovery		extensions and procedures are defined in section 5 and 6 for ISIS and
	across AS boundaries are for further study.		OSPF respectively.
	4. PCE Discovery Information		This document does not define any new OSPF or ISIS element of
			procedure but how the procedures defined in [OSPF-CAP] and [ISIS-CAP]
			should be used.
	4.1. Description		The routing extensions defined in this document allow for PCE
			discovery within an IGP Routing domain. Solutions for PCE discovery
			across AS boundaries are beyond the scope of this document, and for
			further study.
	The PCE Discovery information allows for dynamic discovery of PCEs.		4. Overview
	This information is advertised by means of IGP advertisements by
	PCE(s) participating to the IGP. It allows all PCCs participating to
	the IGP to dynamically discover PCEs along with information useful
	for PCE selection.
	Such dynamic PCE discovery has various advantages:		4.1. PCE Information
	- Simplified PCC configuration,
	- Reduces risk of misconfiguration,
	- Dynamic detection of a new PCE,
	- Dynamic detection of any change in PCE information
	- Dynamic detection of PCE aliveness (PCE liveness may require
	additional mechanisms provided by the PCC-PCE communication
	protocol)
	4.2. Mandatory versus optional PCE information		PCE information advertised within the IGP includes PCE Discovery
			Information and PCE Status information.
			4.1.1. PCE Discovery Information
	The PCE Discovery information is comprised of:		The PCE Discovery information is comprised of:
	- The PCE location: This is a set of one ore more IPv4 and or IPv6		- The PCE location: This is a set of one or more IPv4 and or IPv6
	addresses used to reach the PCE. These are basically loopback		addresses that MUST be used to reach the PCE. It is RECOMMENDED to
	addresses always reachable provided that the PCE is still alive.		use loopback addresses always reachable.
	- The PCE inter-domain functions: this refers to the PCE path		- The PCE inter-domain functions: this refers to the PCE path
	computation scope (i.e. inter-area, inter-AS, inter-layer…).		computation scope (i.e. inter-area, inter-AS, inter-layer…).
	- The PCE domain(s): This is the set domain(s) where the PCE has		- The PCE domain(s): This is the set domain(s) where the PCE has
	visibility and can compute paths.		visibility and can compute paths.
	- The set of destination domain(s) towards which a PCE can compute		- The PCE Destination domain(s): This is the set of destination
	paths.		domain(s) towards which a PCE can compute paths.
			- A set of general PCECP capabilities (e.g. support for request
			prioritization) and path computation specific capabilities
			(e.g. supported constraints, supported objective functions…).
	- A set of general PCE capabilities (e.g. support for request
	prioritization) and path computation specific PCE capabilities
	(e.g. supported constraints, supported objective functions…)
	These are two variable length sets of bits flags, where each bit		These are two variable length sets of bits flags, where each bit
	represent a given PCE capability.		represent a given PCE capability.
	4.3. Flooding scope		It may also contain optional elements to describe more complex
			capabilities.
	The PCE Discovery information can be flooded locally within the IGP
	area the PCE belongs to, or globally across the entire routing
	domain. Note that some PCEs may belong to multiple areas, in which
	case the flooding scope can correspond to these areas. This could be
	the case of an ABR for instance that can advertise its PCE
	information within the backbone area and/or a subset of its attached
	IGP area(s).
	4.4. Frequency of change
	The rate at which PCE information is advertised must be controlled so		PCE Discovery information is by nature a static information that does
	as to not impact by any mean the IGP scalability. Changes in PCE		not change with PCE activity. Changes in PCE Discovery information
	information may occur as result of PCE configuration updates, PCE		may occur as a result of PCE configuration updates, PCE
	deployment/activation or PCE deactivation/suppression. Hence, this		deployment/activation or PCE deactivation/suppression. Hence, this
	information is not expected to change frequently.		information is not expected to change frequently.
			4.1.2. PCE Status Information
			The PCE Status is optional information that can be used to report a
			PCE processing congested state along with an estimated congestion
			duration. This dynamic information may change with PCE activity.
			Procedures for a PCE to move from a processing congested state to a
			non congested state are beyond the scope of this document, but the
			rate at which a PCE Status change is advertised MUST not impact by
			any mean the IGP scalability. Particular attention should be given on
			procedures to avoid state oscillations.
			4.2. Flooding scope
			The flooding scope for PCE Discovery Information can be limited to
			one or more IGP areas the PCE belongs to or can be extended across
			the entire routing domain.
			Note that some PCEs may belong to multiple areas, in which case the
			flooding scope may comprise these areas. This could be the case of an
			ABR for instance advertising its PCE information within the backbone
			area and/or a subset of its attached IGP area(s).
	5. OSPF extensions		5. OSPF extensions
	5.1. The OSPF PCED TLV		5.1. The OSPF PCED TLV
	The OSPF PCE Discovery TLV (PCED TLV) is made of a set of non-ordered		The OSPF PCE Discovery TLV (PCED TLV) is made of a set of non-ordered
	sub-TLVs.		sub-TLVs.
	The format of the OSPF PCED TLV and its sub-TLVs is the identical as		The format of the OSPF PCED TLV and its sub-TLVs is the identical as
	the TLV format used by the Traffic Engineering Extensions to OSPF		the TLV format used by the Traffic Engineering Extensions to OSPF
	[OSPF-TE]. That is, the TLV is composed of 2 octets for the type, 2		[OSPF-TE]. That is, the TLV is composed of 2 octets for the type, 2
	skipping to change at page 7, line 4 ¶		skipping to change at page 7, line 26 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type To be defined by IANA (suggested value=2)		Type To be defined by IANA (suggested value=2)
	Length Variable		Length Variable
	Value This comprises one or more sub-TLVs		Value This comprises one or more sub-TLVs
	Sub-TLVs types are under IANA control.		Sub-TLVs types are under IANA control.
	Currently five sub-TLVs are defined (type values to be assigned by		Currently five sub-TLVs are defined (type values to be assigned by
	IANA):		IANA):
	Sub-TLV type Length Name		Sub-TLV type Length Name
	1 variable PCE-ADDRESS sub-TLV		1 variable PCE-ADDRESS sub-TLV
	2 4 PATH-SCOPE sub-TLV		2 4 PATH-SCOPE sub-TLV
	3 variable PCE-DOMAINS sub-TLV		3 variable PCE-DOMAINS sub-TLV
	4 variable PCE-DEST-DOMAINS sub-TLV		4 variable PCE-DEST-DOMAINS sub-TLV
	5 variable GENERAL-CAP sub-TLV		5 variable GENERAL-CAP sub-TLV
	6 variable PATH-COMP-CAP sub-TLV		6 variable PATH-COMP-CAP sub-TLV
	The sub-TLVs PCE-ADDRESS and PATH SCOPE MUST always be present within		The sub-TLVs PCE-ADDRESS and PATH SCOPE MUST always be present within
	the PCED TLV.		the PCED TLV.
	The sub-TLVs PCE-DOMAINS and DEST-DOMAINS, MUST only be present in		The sub-TLVs PCE-DOMAINS and PCE-DEST-DOMAINS are optional. They MUST
	some particular inter-domain cases.		be present only in some specific inter-domain cases.
	The GENERAL-CAP and PATH-COMP-CAP are optional and MAY be present in		The GENERAL-CAP and PATH-COMP-CAP sub-TLVs are optional and MAY be
	the PCED TLV to facilitate PCE selection.		present in the PCED TLV to facilitate the PCE selection process.
	Any non recognized sub-TLV MUST be silently ignored.		Any non recognized sub-TLV MUST be silently ignored.
	Additional sub-TLVs could be added in the future to advertise		Additional sub-TLVs could be added in the future to advertise
	additional information.		additional information.
	The PCED TLV is carried within an OSPF Router Information LSA which		The PCED TLV is carried within an OSPF Router Information LSA
	is defined in [OSPF-CAP].		defined in [OSPF-CAP], the opaque type of which is determined by the
			desired flooding scope.
	5.1.1. PCE-ADDRESS sub-TLV		5.1.1. PCE-ADDRESS sub-TLV
	The PCE-ADDRESS sub-TLV specifies the IP address to be used to reach		The PCE-ADDRESS sub-TLV specifies the IP address that MUST be used to
	the PCE. This address will typically be a loop-back address that is		reach the PCE. It is RECOMMENDED to make use of a loop-back address
	always reachable, provided that the PCE is alive.		that is always reachable, provided that the PCE is alive.
	The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the		The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the
	PCED TLV.		PCED TLV. The PCE-ADDRESS sub-TLV MUST appear at least once in the
			PCED sub-TLV originated by a PCE. It MAY appear multiple times, for
			instance when the PCE has both an IPv4 and IPv6 address.
	The format of the PCE-ADDRESS sub-TLV is as follows:		The format of the PCE-ADDRESS sub-TLV is as follows:
	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 |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| address-type | Reserved |		| address-type | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	// PCE IP Address //		// PCE IP Address //
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	PCE-ADDRESS sub-TLV format		PCE-ADDRESS sub-TLV format
	Type To be assigned by IANA (suggested value =1)		Type To be assigned by IANA (suggested value =1)
	Length 8 or 20		Length 4 (IPv4) or 16 (IPv6)
	Address-type:		Address-type:
	1 IPv4		1 IPv4
	2 IPv6		2 IPv6
	PCE IP Address: The IP address to be used to reach the PCE.		PCE IP Address: The IP address to be used to reach the PCE.
	This is the address that will be used for		This is the address that will be used for
	setting up PCC-PCE communication sessions.		setting up PCC-PCE communication sessions.
	The PCE-ADDRESS sub-TLV MUST appear at least once in the PCED sub-TLV
	originated by a PCE. It MAY appear multiple times, for instance when
	the PCE has both an IPv4 and IPv6 address.
	5.1.2. PATH-SCOPE sub-TLV		5.1.2. PATH-SCOPE sub-TLV
	The PATH-SCOPE sub-TLV indicates the PCE path computation scope; in		The PATH-SCOPE sub-TLV indicates the PCE path computation scope(s),
	other words the ability of the PCE to compute or take part into the		which refers to the PCE ability to compute or take part into the
	computation of intra-area, inter-area, inter-AS or inter-layer_TE		computation of intra-area, inter-area, inter-AS or inter-layer_TE
	LSP(s).		LSP(s).
	The PATH-SCOPE sub-TLV is mandatory; it MUST be present within the		The PATH-SCOPE sub-TLV is mandatory; it MUST be present within the
	PCED TLV. There MUST be exactly one PATH-SCOPE sub-TLV within each		PCED TLV. There MUST be exactly one PATH-SCOPE sub-TLV within each
	PCED TLV.		PCED TLV.
	The PATH-SCOPE sub-TLV contains a set of bit flags indicating the		The PATH-SCOPE sub-TLV contains a set of bit flags indicating the
	supported path scopes (intra-area, inter-area, inter-AS, inter-layer)		supported path scopes (intra-area, inter-area, inter-AS, inter-layer)
	and two fields indicating PCE preferences.		and four fields indicating PCE preferences.
	The PATH-SCOPE sub-TLV has the following format:		The PATH-SCOPE sub-TLV has the following format:
	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 |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0|1|2|3|4|5| Reserved |PrefR|PrefS| Reserved |		|0|1|2|3|4|5| Reserved |PrefL|PrefR|PrefS|PrefY| Res |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type To be defined by IANA (suggested value =3)		Type To be defined by IANA (suggested value =3)
	Length Variable		Length Variable
	Value This comprises a 2 bytes flag where each bit		Value This comprises a 2 bytes flag where each bit
	represents a supported path scope, as well as two		represents a supported path scope, as well as four
	preference fields allowing to specify PCE preferences.		preference fields allowing to specify PCE preferences.
	The following bits are defined:		The following bits are defined:
	Bit Path Scope		Bit Path Scope
	0 L bit: Can compute intra-area path		0 L bit: Can compute intra-area path
	1 R bit: Can act as PCE for inter-area TE LSPs		1 R bit: Can act as PCE for inter-area TE LSPs
	computation		computation
	2 Rd bit: Can act as a default PCE for inter-area TE LSPs		2 Rd bit: Can act as a default PCE for inter-area TE LSPs
	skipping to change at page 9, line 4 ¶		skipping to change at page 9, line 29 ¶
	The following bits are defined:		The following bits are defined:
	Bit Path Scope		Bit Path Scope
	0 L bit: Can compute intra-area path		0 L bit: Can compute intra-area path
	1 R bit: Can act as PCE for inter-area TE LSPs		1 R bit: Can act as PCE for inter-area TE LSPs
	computation		computation
	2 Rd bit: Can act as a default PCE for inter-area TE LSPs		2 Rd bit: Can act as a default PCE for inter-area TE LSPs
	computation		computation
	3 S bit: Can act as PCE for inter-AS TE LSPs computation		3 S bit: Can act as PCE for inter-AS TE LSPs computation
	4 Sd bit: Can act as a default PCE for inter-AS TE LSPs		4 Sd bit: Can act as a default PCE for inter-AS TE LSPs
	computation		computation
	5 Y bit: Can compute or take part into the computation of		5 Y bit: Can compute or take part into the computation of
	paths across layers.		paths across layers.
	Pref field: PCE’s preference		Pref-L field: PCE's preference for intra-area TE LSPs computation.
	Pref-S field: PCE’s preference for inter-AS TE LSPs computation		Pref-R field: PCE’s preference for inter-area TE LSPs computation.
			Pref-S field: PCE’s preference for inter-AS TE LSPs computation.
			Pref-Y field: PCE's preference for inter-layer TE LSPs computation.
			Res: Reserved for future usage.
	The bits L, R, S and Y bits are set when the PCE can act as a PCE for		The bits L, R, S and Y bits are set when the PCE can act as a PCE for
	intra-area, inter-area, inter-AS and inter-layer TE LSPs computation		intra-area, inter-area, inter-AS and inter-layer TE LSPs computation
	respectively. These bits are non exclusive.		respectively. These bits are non exclusive.
	When set the Rd bit indicates that the PCE can act as a default PCE		When set the Rd bit indicates that the PCE can act as a default PCE
	for inter-area TE LSPs computation, it means that it can compute path		for inter-area TE LSPs computation (the PCE can compute path for any
	for any destination area. Similarly, when set the Sd bit indicates		destination area). Similarly, when set the Sd bit indicates that the
	that the PCE can act as a default PCE for inter-AS TE LSPs		PCE can act as a default PCE for inter-AS TE LSPs computation (the
	computation, it means that it can compute path for any destination		PCE can compute path for any destination AS).
	AS.
	When the Rd bit is set the PCE-DEST-DOMAIN TLV (see 5.1.4) does not		When the Rd bit is set the PCE-DEST-DOMAIN TLV (see 5.1.4) does not
	comprise any Area ID DOMAIN sub-TLV.		contain any Area ID DOMAIN sub-TLV.
	When the Sd bit is set the PCE-DEST-DOMAIN TLV does not comprise any
	AS DOMAIN sub-TLV.
	The PrefR and PrefS fields are 3-bit long and allow the PCE to		Similarly, when the Sd bit is set the PCE-DEST-DOMAIN TLV does not
	specify a preference where 7 reflects the highest preference. For the		contain any AS DOMAIN sub-TLV.
	sake of illustration, consider the situation where N ABRs act as PCEs
	for inter-area TE LSPs computation. An operator may decide to		The PrefL, PrefR, PrefS and PrefY fields are 3-bit long and allow the
	configure a preference to each PCE that could be used to load balance		PCE to specify a preference for each computation scope, where 7
	the path computation load with respect to their respective CPU		reflects the highest preference. Such preference can be used for
			weighted load balancing of requests. An operator may decide to
			configure a preference to each PCE so as to balance the path
			computation load among them, with respect to their respective CPU
	capacity. The algorithms used by a PCC to load balance its path		capacity. The algorithms used by a PCC to load balance its path
	computation requests according to such PCE’s preference is out of the		computation requests according to such PCE’s preference is out of the
	scope of this document.		scope of this document. Same or distinct preferences may be used for
			different scopes. For instance an operator that wants a PCE capable
			of both inter-area and inter-AS computation to be used preferably for
			inter-AS computation may configure a PrefS higher than the PrefR.
			When the L bit, R bit, S or Y bit are cleared the PrefL, PrefR,
			PrefS, PrefY bit MUST respectively be set to 0.
	5.1.3. PCE-DOMAINS sub-TLV		5.1.3. PCE-DOMAINS sub-TLV
	The PCE-DOMAINS sub-TLV specifies the set of domains (areas, AS)		The PCE-DOMAINS sub-TLV specifies the set of domains (areas, AS)
	where the PCE has topology visibility and can compute paths. It		where the PCE has topology visibility and can compute paths. It
	contains a set of one or more sub-TLVs where each sub-TLV identifies		contains a set of one or more sub-TLVs where each sub-TLV identifies
	a domain.		a domain.
	The PCE-DOMAINS sub-TLV MUST only be present when PCE domains cannot		The PCE-DOMAINS sub-TLV MUST be present when PCE domains cannot be
	be inferred by other IGP information, for instance when the PCE is		inferred by other IGP information, for instance when the PCE is
	inter-domain capable (i.e. when the R bit or S bit is set) and the		inter-domain capable (i.e. when the R bit or S bit is set) and the
	flooding scope the entire routing domain.		flooding scope is the entire routing domain.
	The PCE-DOMAINS sub-TLV has the following format:		The PCE-DOMAINS sub-TLV has the following format:
	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 |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	// DOMAIN sub-TLVs //		// DOMAIN sub-TLVs //
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type To be defined by IANA (suggested value =3)		Type To be defined by IANA (suggested value =3)
	Length Variable		Length Variable
	Value This comprises a set of one or more DOMAIN sub-TLVs		Value This comprises a set of one or more DOMAIN sub-TLVs
	where each DOMAIN sub-TLV identifies a domain where		where each DOMAIN sub-TLV identifies a domain where
	the PCE has topology visibility and can compute TE LSP		the PCE has topology visibility and can compute paths.
	paths.
	Sub-TLVs types are under IANA control.		Sub-TLVs types are under IANA control.
	Currently three DOMAIN sub-TLVs are defined (suggested type values to		Currently three DOMAIN sub-TLVs are defined (suggested type values to
	be assigned by IANA):		be assigned by IANA):
	Sub-TLV type Length Name		Sub-TLV type Length Name
	1 variable IPv4 area ID sub-TLV		1 variable IPv4 area ID sub-TLV
	2 variable IPv6 area ID sub-TLV		2 variable IPv6 area ID sub-TLV
	3 variable AS number sub-TLV		3 variable AS number sub-TLV
	skipping to change at page 11, line 48 ¶		skipping to change at page 12, line 30 ¶
	AS Number: AS number identifying an AS. When coded on two		AS Number: AS number identifying an AS. When coded on two
	bytes (which is the current defined format as the		bytes (which is the current defined format as the
	time of writing this document), the AS Number field		time of writing this document), the AS Number field
	MUST have its left two bytes set to 0.		MUST have its left two bytes set to 0.
	5.1.4. PCE-DEST-DOMAINS sub-TLV		5.1.4. PCE-DEST-DOMAINS sub-TLV
	The PCE-DEST-DOMAINS sub-TLV specifies the set of destination domains		The PCE-DEST-DOMAINS sub-TLV specifies the set of destination domains
	(areas, AS) toward which a PCE can compute path. It means that the		(areas, AS) toward which a PCE can compute path. It means that the
	PCE can compute or take part in the computation of inter-domain LSPs		PCE can compute or take part in the computation of inter-domain LSPs
	whose destination is located in one of these domains. It contains a		whose destinations are located within one of these domains. It
	set of one or more sub-TLVs where each sub-TLV identifies a domain.		contains a set of one or more sub-TLVs where each sub-TLV identifies
			a domain.
	The PCE-DEST-DOMAINS sub-TLV has the following format:		The PCE-DEST-DOMAINS sub-TLV has the following format:
	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 |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	// DOMAIN sub-TLVs //		// DOMAIN sub-TLVs //
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type To be defined by IANA (suggested value =3)		Type To be defined by IANA (suggested value =3)
	Length Variable		Length Variable
	Value This comprises a set of one or more Area and/or AS		Value This comprises a set of one or more Area and/or AS
	DOMAIN sub-TLVs where each DOMAIN sub-TLV identifies a		DOMAIN sub-TLVs where each DOMAIN sub-TLV identifies a
	domain toward which a PCE can compute paths.		domain toward which a PCE can compute paths.
	The PCE-DEST-DOMAINS sub-TLV MUST include at least one DOMAIN sub-		The PCE-DEST-DOMAINS sub-TLV MUST be present if the R bit is set and
	TLV.		the Rd bit is cleared, and/or, if the S bit is set and the Sd bit is
			cleared.
	The PCE-DEST-DOMAINS sub-TLV is optional. It MUST be present only if
	the R bit is set and the Rd bit is cleared, and/or, if the S bit is
	set and the Sd bit is cleared.
	The PCE-DEST-DOMAINS sub-TLV MUST include at least one area ID sub-		The PCE-DEST-DOMAINS sub-TLV MUST include at least one DOMAIN sub-
	TLV, if the R bit of the PATH-SCOPE TLV is set and the Rd bit of the		TLV. It MUST include at least one area ID sub-TLV, if the R bit of
	PATH-SCOPE TLV is cleared.		the PATH-SCOPE TLV is set and the Rd bit of the PATH-SCOPE TLV is
	Similarly, the PCE-DEST- DOMAINS sub-TLV MUST include at least one AS		cleared. Similarly, it MUST include at least one AS number sub-TLV if
	number sub-TLV if the S bit of the PATH-SCOPE TLV is set and the Sd		the S bit of the PATH-SCOPE TLV is set and the Sd bit of the PATH-
	bit of the PATH-SCOPE TLV is cleared.		SCOPE TLV is cleared.
	5.1.5. The GENERAL-CAP sub-TLV		5.1.5. GENERAL-CAP sub-TLV
	The GENERAL-CAP sub-TLV is used to indicate general PCE capabilities.		The GENERAL-CAP sub-TLV is an optional TLV used to indicate PCECP
	The GENERAL-CAP sub-TLV is optional. It MAY be carried within the		related capabilities.
	PCED TLV.
	The value field of the GENERAL-CAP sub-TLV is made of bit flags,		The value field of the GENERAL-CAP sub-TLV is made of bit flags,
	where each bit corresponds to a general PCE capability.		where each bit corresponds to a general PCE capability. It MAY also
			include optional sub-TLVs to encode more complex capabilities.
	The format of the GENERAL-CAP sub-TLV is as follows:		The format of the GENERAL-CAP sub-TLV is as follows:
	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 |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| General PCE Capabilities |		| General PCE Capabilities |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 13, line 36 ¶		skipping to change at page 14, line 15 ¶
	Bit Capabilities		Bit Capabilities
	0 P bit: Support for Request prioritization.		0 P bit: Support for Request prioritization.
	1 M bit: Support for multiple messages within the same		1 M bit: Support for multiple messages within the same
	request message.		request message.
	2-31 Reserved for future assignments by IANA.		2-31 Reserved for future assignments by IANA.
	5.1.6. The PATH-COMP-CAP sub-TLV		5.1.6. The PATH-COMP-CAP sub-TLV
	The PATH-COMP-CAP sub-TLV is used to indicate path computation		The PATH-COMP-CAP sub-TLV is an optional TLV used to indicate path
	specific capabilities of a PCE.		computation specific capabilities. It is made of a set of bit flags,
	The PATH-COMP-CAP sub-TLV is optional. It MAY be carried within the		where each bit correspond to a path computation capability. It MAY
	PCED TLV.		also include optional sub-TLVs to encode more complex capabilities.
	This is a series of bit flags, where each bit correspond to a path
	computation capability.
	The format of the PATH-COMP-CAP sub-TLV is as follows:		The format of the PATH-COMP-CAP sub-TLV is as follows:
	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 |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Path Computation Capabilities |		| Path Computation Capabilities |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 14, line 28 ¶		skipping to change at page 15, line 7 ¶
	currently defined.		currently defined.
	IANA is requested to manage the space of PCE path commutation		IANA is requested to manage the space of PCE path commutation
	capability bit flags.		capability bit flags.
	The following bits in the first capability flag are to be assigned by		The following bits in the first capability flag are to be assigned by
	IANA:		IANA:
	Bit Capabilities		Bit Capabilities
	0 M bit: Capability to compute P2P paths in MPLS-TE networks		0 G bit: Capability to handle GMPLS contraints
	1 G bit: Capability to compute P2P paths in GMPLS networks		1 B bit: Capability to compute bidirectional paths
	2 D bit: Capability to compute link/node/SRLG diverse paths		2 D bit: Capability to compute link/node/SRLG diverse paths
	3 L bit: Capability to compute load-balanced paths		3 L bit: Capability to compute load-balanced paths
	4 S bit: Capability to compute a set of paths in a		4 S bit: Capability to compute a set of paths in a
	synchronized Manner		synchronized Manner
	5 O bit: Support for multiple objective functions		5 O bit: Support for multiple objective functions
	6-31 Reserved for future assignments by IANA.		6-31 Reserved for future assignments by IANA.
	The M, G, D, L, S and O bits are not exclusive.		The G, B, D, L, S and O bits are not exclusive.
	5.2. Elements of Procedure		5.2. The OSPF PCES TLV
	The PCED TLV is carried within an OSPF Router information opaque LSA		The OSPF PCE Status TLV (PCES TLV) carries information related to PCE
	(opaque type of 4, opaque ID of 0) which is defined in [OSPF-CAP].		processing congestion state.
			The PCES TLV is carried within an OSPF Router Information LSA which
			is defined in [OSPF-CAP].
			The OSPF PCES TLV has the following format:
			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 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			// PCE ADDRESS sub-TLV //
			// CONGESTION sub-TLV //
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Type To be defined by IANA (suggested value=3)
			Length Variable
			Value This comprises a PCE ADDRESS sub-TLV, identifying the
			PCE and a CONGESTION sub-TLV that contains congestion
			information.
			Sub-TLV types are under IANA control.
			Currently two sub-TLVs are defined (type values to be assigned by
			IANA):
			Sub-TLV type Length Name
			1 variable PCE-ADDRESS sub-TLV
			2 4 CONGESTION sub-TLV
			The PCE-ADDRESS and CONGESTION sub-TLVs MUST be present once
			in a PCES TLV. The PCE-ADDRESS sub-TLV is defined in section 5.1.1.
			It carries one of the PCE IP addresses and is used to identify the
			PCE the processing congestion state information is applied to. This
			is required as the PCES and PCED TLVs may be carried in separate
			Router Information LSAs.
			Any non recognized sub-TLV MUST be silently ignored.
			Additional sub-TLVs could be added in the future to advertise
			additional congestion information.
			5.2.1. The CONGESTION sub-TLV
			The CONGESTION sub-TLV is used to indicate whether a PCE experiences
			a processing congestion state or not along with optionally the
			expected PCE congestion duration.
			The CONGESTION sub-TLV is mandatory. It MUST be carried once within
			the PCES TLV.
			The format of the CONGESTION sub-TLV is as follows:
			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 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|C| Reserved | Congestion Duration |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Type To be assigned by IANA (suggested value =2)
			Length 4
			Value
			-C bit: When set this indicates that the PCE experiences
			congestion and cannot support any new request. When
			cleared this indicates that the PCE does not
			experiences congestion an can support a new request.
			-Congestion Duration: 2-bytes, the estimated PCE congestion
			duration in seconds.
			When C is set and the Congestion Duration field is equal to 0, this
			means that the Congestion Duration is unknown.
			When C is cleared the Congestion Duration MUST be set to 0.
			5.3. Elements of Procedure
			The PCED and PCES TLV are carried within an OSPF Router information
			opaque LSA (opaque type of 4, opaque ID of 0) which is defined in
			[OSPF-CAP]. As the PCES information is likely to change more
			frequently than the PCED information, it is RECOMMENDED to carry PCES
			and PCED TLVs in separate Router Information LSAs, so as not to carry
			all PCED information each time the PCE status changes.
			5.3.1. PCED TLV Procedure
	A router MUST originate a new OSPF router information LSA whenever		A router MUST originate a new OSPF router information LSA whenever
	the content of any of the carried TLVs changes or whenever		the content of the PCED TLV changes or whenever required by the
	required by the regular OSPF procedure (LSA refresh (every		regular OSPF procedure (LSA refresh (every LSRefreshTime)).
	LSRefreshTime)).
	The PCED TLV may be carried within a type 10 or 11 router information		The PCED TLV may be carried within a type 10 or 11 router information
	LSA depending on the flooding scope of the PCE information.		LSA depending on the flooding scope of the PCE information.
	If the flooding scope is local to an area then it MUST be carried		If the flooding scope is local to an area then it MUST be carried
	within a type 10 router information LSA.		within a type 10 router information LSA.
	If the flooding scope is the entire domain then it MUST be carried		If the flooding scope is the entire domain then it MUST be carried
	within type 11 router information LSA.		within type 11 router information LSA.
	Note that when the L bit of the PATH-SCOPE TLV is set and the R bit		Note that when the L bit of the PATH-SCOPE TLV is set and the R bit
	and S bit are cleared, the flooding scope MUST be local, and the PCED		and S bit are cleared, the flooding scope MUST be local, and the PCED
	TLV MUST be carried within a type 10 Router Information LSA.		TLV MUST be carried within a type 10 Router Information LSA.
	PCED TLVs are OPTIONAL. When an OSPF LSA does not contain any PCED		PCED sub-TLVs are OPTIONAL. When an OSPF LSA does not contain
	TLV, this means that the PCE information of that node is unknown.		any PCED sub-TLV, this means that the PCE information of that
			node is unknown.
	Note that a change in PCED information MUST not trigger normal SPF		Note that a change in PCED information MUST not trigger any SPF
	computation.		computation.
			The way PCEs retrieve their own information is out of the scope of
			this document. Some information may be configured on the PCE (e.g.
			address, preferences, scope) and other information may be
			automatically retrieved by the PCE (e.g. areas of visibility).
			5.3.2. PCES TLV procedure
			A router MUST originate a new OSPF router information LSA whenever
			the content of the PCES TLV changes or whenever required by the
			regular OSPF procedure (LSA refresh (every LSRefreshTime)).
			When a PCE enters into a processing congestion state, the conditions
			of which are implementation dependent, it SHOULD originate a Router
			Information LSA with a PCES TLV with the C bit set, and optionally a
			non-null expected congestion duration.
			When a PCE leaves the processing congestion state, the conditions of
			which are implementation dependent, there are two cases:
			- If the congestion duration in the previously originated PCES
			TLV was null, it SHOULD originate a PCES TLV with the C bit cleared
			and a null congestion duration;
			- If the congestion duration in the previously originated PCES
			TLV was non null, it MAY not originate a PCES TLV. Note that in some
			particular cases it may be desired to originate a PCES TLV with the C
			bit cleared if the saturation duration was over estimated.
			The congestion duration allows reducing the amount of OSPF flooding,
			as only uncongested-congested state transitions are flooded.
			It is expected that a proper implementation will support dampening
			algorithms so as to dampen OSPF flooding in order to not impact the
			OSPF scalability. It is recommended to introduce some hysteresis for
			saturation state transition, so as to avoid state oscillations that
			may impact OSPF performances. For instance two thresholds could be
			configured: A resource saturation upper-threshold and a resource
			saturation lower-threshold. An LSR enters the congested state when
			the CPU load reaches the upper threshold and leaves the congested
			state when the CPU load goes under the lower threshold.
			Upon receipt of an updated PCES TLV a PCC should take appropriate
			actions. In particular, the PCC should stop sending requests to a
			congested PCE, and should gradually start sending again requests to a
			no longer congested PCE. Such PCC procedures are out of the scope of
			this document.
	6. ISIS extensions		6. ISIS extensions
	6.1. IS-IS PCED TLV format		6.1. IS-IS PCED TLV format
	The IS-IS PCED TLV is made of various non ordered sub-TLVs.		The IS-IS PCED TLV is made of various non ordered sub-TLVs.
	The format of the IS-IS PCED TLV and its sub-TLVs is the same as the		The format of the IS-IS PCED TLV and its sub-TLVs is the same as the
	TLV format used by the Traffic Engineering Extensions to IS-IS [ISIS-		TLV format used by the Traffic Engineering Extensions to IS-IS [ISIS-
	TE]. That is, the TLV is composed of 1 octet for the		TE]. That is, the TLV is composed of 1 octet for the type, 1 octet
	type, 1 octet specifying the TLV length and a value field.		specifying the TLV length and a value field.
	The IS-IS PCED TLV has the following format:		The IS-IS PCED TLV has the following format:
	TYPE: To be assigned by IANA		TYPE: To be assigned by IANA
	LENGTH: Variable		LENGTH: Variable
	VALUE: set of sub-TLVs		VALUE: set of sub-TLVs
	Sub-TLVs types are under IANA control.		Sub-TLVs types are under IANA control.
	Currently five sub-TLVs are defined (suggested type values to be		Currently five sub-TLVs are defined (suggested type values to be
	assigned by IANA):		assigned by IANA):
	Sub-TLV type Length Name		Sub-TLV type Length Name
	1 variable PCE-ADDRESS sub-TLV		1 variable PCE-ADDRESS sub-TLV
	2 2 PATH-SCOPE sub-TLV		2 3 PATH-SCOPE sub-TLV
	3 variable PCE-DOMAINS sub-TLV		3 variable PCE-DOMAINS sub-TLV
	4 variable PCE-DEST-DOMAINS sub-TLV		4 variable PCE-DEST-DOMAINS sub-TLV
	5 variable GENERAL-CAP sub-TLV		5 variable GENERAL-CAP sub-TLV
	6 variable PATH-COMP-CAP sub-TLV		6 variable PATH-COMP-CAP sub-TLV
	The sub-TLVs PCE-ADDRESS and PATH-SCOPE MUST always be present within		The sub-TLVs PCE-ADDRESS and PATH-SCOPE MUST always be present within
	the PCED TLV.		the PCED TLV.
	The sub-TLVs PCE-DOMAINS and DEST-DOMAINS, MUST only be present in		The sub-TLVs PCE-DOMAINS and PCE-DEST-DOMAINS are optional. They MUST
	some particular inter-domain cases.		be present only in some specific inter-domain cases.
	The GENERAL-CAP and PATH-COMP-CAP are optional and MAY be present in		The GENERAL-CAP and PATH-COMP-CAP are optional and MAY be present in
	the PCED TLV to facilitate PCE selection.		the PCED TLV to facilitate the PCE selection process.
	Any non recognized sub-TLV MUST be silently ignored.		Any non recognized sub-TLV MUST be silently ignored.
	Additional sub-TLVs could be added in the future to advertise		Additional sub-TLVs could be added in the future to advertise
	additional PCE information.		additional PCE information.
	The PCED TLV is carried within an ISIS CAPABILITY TLV which is		The PCED TLV is carried within an ISIS CAPABILITY TLV defined in
	defined in [ISIS-CAP].		[ISIS-CAP], whose S bit is determined by the desired flooding scope.
	6.1.1. PCE-ADDRESS sub-TLV		6.1.1. PCE-ADDRESS sub-TLV
	The PCE-ADDRESS sub-TLV specifies the IP address to be used to reach		The PCE-ADDRESS sub-TLV specifies the IP address that MUST be used to
	the PCE. This address will typically be a loop-back address that is		reach the PCE. It is RECOMMENDED to make use of a loop-back addresse
	always reachable, provided the PCE is alive.		that is always reachable, provided the PCE is alive.
	The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the		The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the
	PCED TLV.		PCED TLV.
	The PCE-ADDRESS sub-TLV has the following format:		The PCE-ADDRESS sub-TLV has the following format:
	TYPE: To be assigned by IANA (Suggested value =1)		TYPE: To be assigned by IANA (Suggested value =1)
	LENGTH: 4 for IPv4 address and 16 for IPv6 address		LENGTH: 4 for IPv4 address and 16 for IPv6 address
	VALUE: This comprises one octet indicating the address-type and 4		VALUE: This comprises one octet indicating the address-type and 4
	or 16 octets encoding the IPv4 or IPv6 address to be used		or 16 octets encoding the IPv4 or IPv6 address to be used
	to reach the PCE		to reach the PCE
	skipping to change at page 17, line 31 ¶		skipping to change at page 20, line 31 ¶
	Address-type:		Address-type:
	1 IPv4		1 IPv4
	2 IPv6		2 IPv6
	The PCE-ADDRESS sub-TLV MUST appear at least once in the PCED sub-LTV		The PCE-ADDRESS sub-TLV MUST appear at least once in the PCED sub-LTV
	originated by a PCE. It MAY appear multiple times, for instance when		originated by a PCE. It MAY appear multiple times, for instance when
	the PCE has both an IPv4 and IPv6 address.		the PCE has both an IPv4 and IPv6 address.
	6.1.2. The PATH-SCOPE sub-TLV		6.1.2. The PATH-SCOPE sub-TLV
	The PATH-SCOPE sub-TLV indicates the PCE path computation scope; in		The PATH-SCOPE sub-TLV indicates the PCE path computation scope which
	other words the ability of the PCE to compute or take part into the		refers to the PCE ability to compute or take part into the
	computation of intra-area, inter-area, inter-AS or inter-layer_TE		computation of intra-area, inter-area, inter-AS or inter-layer_TE
	LSP(s).		LSP(s).
	The PATH-SCOPE sub-TLV is mandatory; it MUST be present within the		The PATH-SCOPE sub-TLV is mandatory; it MUST be present within the
	PCED TLV. There MUST be exactly one PATH-SCOPE sub-TLV within each		PCED TLV. There MUST be exactly one PATH-SCOPE sub-TLV within each
	PCED TLV.		PCED TLV.
	The PATH-SCOPE sub-TLV contains a set of bit flags indicating the		The PATH-SCOPE sub-TLV contains a set of bit flags indicating the
	supported path scopes (intra-area, inter-area, inter-AS, inter-layer)		supported path scopes (intra-area, inter-area, inter-AS, inter-layer)
	and two fields indicating PCE preferences.		and four fields indicating PCE preferences.
	The PATH-SCOPE sub-TLV has the following format:		The PATH-SCOPE sub-TLV has the following format:
	TYPE: To be assigned by IANA (Suggested value =2)		TYPE: To be assigned by IANA (Suggested value =2)
	LENGTH: Variable		LENGTH: 3
	VALUE: This comprises a one-byte flag of bits where each bit		VALUE: This comprises a one-byte flag of bits where each bit
	represents a supported path scope, followed by a one-byte		represents a supported path scope, followed by a 2-bytes
	preference field indicating PCE preferences.		preferences field indicating PCE preferences.
	Here is the structure of the bits flag:		Here is the structure of the bit flag:
	0 1 2 3 4 5 6 7		+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+		|0|1|2|3|4|5|Res|
	|0|1|2|3|4|5|Res|		+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+
	Bit Path Scope		Bit Path Scope
	0 L bit: Can compute intra-area path		0 L bit: Can compute intra-area path
	1 R bit: Can act as PCE for inter-area TE LSPs		1 R bit: Can act as PCE for inter-area TE LSPs
	computation		computation
	2 Rd bit: Can act as a default PCE for inter-area TE LSPs		2 Rd bit: Can act as a default PCE for inter-area TE LSPs
	computation		computation
	3 S bit: Can act as PCE for inter-AS TE LSPs computation		3 S bit: Can act as PCE for inter-AS TE LSPs computation
	4 Sd bit: Can act as a default PCE for inter-AS TE LSPs		4 Sd bit: Can act as a default PCE for inter-AS TE LSPs
	computation		computation
	5 Y bit: Can compute or take part into the computation of		5 Y bit: Can compute or take part into the computation of
	paths across layers		paths across layers
			6-7 Reserved for future usage.
	Here is the structure of the preference field		Here is the structure of the preferences field
	0 1 2 3 4 5 6 7		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+		|PrefL|PrefR|PrefS|PrefY| Res |
	|PrefR|PrefS|Res|		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+
	PrefR field: PCE’s preference for inter-area TE LSPs computation		Pref-L field: PCE's preference for intra-area TE LSPs computation.
	PrefS field: PCE’s preference for inter-AS TE LSPs computation		Pref-R field: PCE’s preference for inter-area TE LSPs computation.
			Pref-S field: PCE’s preference for inter-AS TE LSPs computation.
			Pref-Y field: PCE's preference for inter-layer TE LSPs computation.
			Res: Reserved for future usage.
	The bits L, R, S and Y bits are set when the PCE can act as a PCE for		The bits L, R, S and Y bits are set when the PCE can act as a PCE for
	intra-area, inter-area, inter-AS and inter-layer TE LSPs computation		intra-area, inter-area, inter-AS and inter-layer TE LSPs computation
	respectively. These bits are non exclusive.		respectively. These bits are non exclusive.
	When set the Rd bit indicates that the PCE can act as a default PCE		When set the Rd bit indicates that the PCE can act as a default PCE
	for inter-area TE LSPs computation, it means that it can compute path		for inter-area TE LSPs computation (the PCE can compute path for any
	for any destination area. Similarly, when set the Sd bit indicates		destination area). Similarly, when set the Sd bit indicates that the
	that the PCE can act as a default PCE for inter-AS TE LSPs		PCE can act as a default PCE for inter-AS TE LSPs computation (the
	computation, it means that it can compute path for any destination		PCE can compute path for any destination AS).
	AS.
	When the Rd bit is set the PCE-DEST-DOMAINS TLV (see 6.1.4) does not		When the Rd bit is set the PCE-DEST-DOMAIN TLV (see 5.1.4) does not
	comprise any Area ID DOMAIN sub-TLV. When the Sd bit is set the PCE-		contain any Area ID DOMAIN sub-TLV.
	DEST-DOMAINS TLV does not comprise any AS DOMAIN sub-TLV.
	The PrefR and PrefS fields are 3-bit long and allow the PCE to		Similarly, when the Sd bit is set the PCE-DEST-DOMAIN TLV does not
	specify a preference where 7 reflects the highest preference. For the		contain any AS DOMAIN sub-TLV.
	sake of illustration, consider the situation where N ABRs act as PCEs
	for inter-area TE LSPs computation. An operator may decide to		The PrefL, PrefR, PrefS and PrefY fields are 3-bit long and allow the
	configure a preference to each PCE that could be used to load balance		PCE to specify a preference for each computation scope, where 7
	the path computation load with respect to their respective CPU		reflects the highest preference. Such preference can be used for
	capacity. The algorithms used by a PCC to load balance its path		weighted load balancing of requests. An operator may decide to
			configure a preference to each PCE so as to balance the path
			computation load among them, with respect to their respective CPU
			capacity. The algorithms used by a PCC to balance its path
	computation requests according to such PCE’s preference is out of the		computation requests according to such PCE’s preference is out of the
	scope of this document		scope of this document. Same or distinct preferences may be used for
			different scopes. For instance an operator that wants a PCE capable
			of both inter-area and inter-AS computation to be used preferably for
			inter-AS computation may configure a PrefS higher than the PrefR.
			When the L bit, R bit, S or Y bit are cleared the PrefL, PrefR,
			PrefS, PrefY bit MUST respectively be set to 0.
	6.1.3. PCE-DOMAINS sub-TLV		6.1.3. PCE-DOMAINS sub-TLV
	The PCE-DOMAINS sub-TLV specifies the set of domains (areas, AS)		The PCE-DOMAINS sub-TLV specifies the set of domains (areas or AS)
	where the PCE has topology visibility and can compute paths. It		where the PCE has topology visibility and can compute paths. It
	contains a set of one or more sub-TLVs where each sub-TLV identifies		contains a set of one or more sub-TLVs where each sub-TLV identifies
	a domain.		a domain.
	The PCE-DOMAINS sub-TLV MUST only be present when PCE domains cannot		The PCE-DOMAINS sub-TLV MUST be present when PCE domains cannot be
	be inferred by other IGP information, for instance when the PCE is		inferred by other IGP information, for instance when the PCE is
	inter-domain capable (i.e. when the R bit or S bit is set) and the		inter-domain capable (i.e. when the R bit or S bit is set) and the
	flooding scope is the entire routing domain.		flooding scope is the entire routing domain.
	The PCE-DOMAINS sub-TLV has the following format:		The PCE-DOMAINS sub-TLV has the following format:
	TYPE: To be assigned by IANA (Suggested value =2)		TYPE: To be assigned by IANA (Suggested value =2)
	LENGTH: Variable		LENGTH: Variable
	VALUE: This comprises a set of one or more DOMAIN sub-TLVs where		VALUE: This comprises a set of one or more DOMAIN sub-TLVs where
	each DOMAIN sub-TLV identifies a domain where the PCE has		each DOMAIN sub-TLV identifies a domain where the PCE has
	topology visibility and can compute paths		topology visibility and can compute paths
	skipping to change at page 20, line 17 ¶		skipping to change at page 23, line 24 ¶
	VALUE: AS number identifying an AS. When coded on two		VALUE: AS number identifying an AS. When coded on two
	bytes (which is the current defined format as the		bytes (which is the current defined format as the
	time of writing this document), the AS Number field		time of writing this document), the AS Number field
	MUST have its left two bytes set to 0.		MUST have its left two bytes set to 0.
	6.1.4. PCE-DEST-DOMAINS sub-TLV		6.1.4. PCE-DEST-DOMAINS sub-TLV
	The PCE-DEST-DOMAINS sub-TLV specifies the set of destination domains		The PCE-DEST-DOMAINS sub-TLV specifies the set of destination domains
	(areas, AS) toward which a PCE can compute path. It means that the		(areas, AS) toward which a PCE can compute path. It means that the
	PCE can compute or take part in the computation of inter-domain LSPs		PCE can compute or take part in the computation of inter-domain LSPs
	whose destination is located in one of these domains. It contains a		whose destinations are located within one of these domains. It
	set of one or more DOMAIN sub-TLVs where each DOMAIN sub-TLV		contains a set of one or more DOMAIN sub-TLVs where each DOMAIN sub-
	identifies a domain.		TLV identifies a domain.
	The PCE-DEST-DOMAINS sub-TLV has the following format:		The PCE-DEST-DOMAINS sub-TLV has the following format:
	TYPE: To be assigned by IANA (Suggested value =2)		TYPE: To be assigned by IANA (Suggested value =3)
	LENGTH: Variable		LENGTH: Variable
	VALUE: This comprises a set of one or more Area or/and AS DOMAIN sub-		VALUE: This comprises a set of one or more Area or/and AS DOMAIN sub-
	TLVs where each sub-TLV identifies a destination domain toward		TLVs where each sub-TLV identifies a destination domain toward
	which a PCE can compute path.		which a PCE can compute path.
	At least one DOMAIN sub-TLV MUST be present in the PCE-DEST-DOMAINS		The PCE-DEST-DOMAINS sub-TLV MUST be present if the R bit is set and
	sub-TLV.		the Rd bit is cleared, and/or, if the S bit is set and the Sd bit is
			cleared.
	The PCE-DEST-DOMAINS sub-TLV is optional. It MUST be present only if
	the R bit is set and the Rd bit is cleared, and/or, if the S bit is
	set and the Sd bit is cleared.
	The PCE-DEST-DOMAINS sub-TLV MUST include at least one area ID sub-		The PCE-DEST-DOMAINS sub-TLV MUST include at least one DOMAIN sub-
	TLV, if the R bit of the PATH-SCOPE TLV is set and the Rd bit of the		TLV. It MUST include at least one area ID sub-TLV, if the R bit of
	PATH-SCOPE TLV is cleared. Similarly, the PCE-DEST-DOMAINS sub-TLV		the PATH-SCOPE TLV is set and the Rd bit of the PATH-SCOPE TLV is
	MUST include at least one AS number sub-TLV if the S bit of the PATH-		cleared. Similarly, it MUST include at least one AS number sub-TLV if
	SCOPE TLV is set and the Sd bit of the PATH-SCOPE TLV is cleared.		the S bit of the PATH-SCOPE TLV is set and the Sd bit of the PATH-
			SCOPE TLV is cleared.
	6.1.5. GENERAL-CAP sub-TLV		6.1.5. GENERAL-CAP sub-TLV
	The GENERAL-CAP sub-TLV is used to indicate general PCE capabilities.		The GENERAL-CAP sub-TLV is an optional TLV used to indicate PCECP
	The GENERAL-CAP sub-TLV is optional. It MAY be carried within the		related capabilities.
	PCED TLV.
	This is a series of bits flags, where each bit corresponds to a		This is a series of bits flags, where each bit corresponds to a
	general PCE capability.		general PCE capability. It MAY also include optional sub-TLVs to
			encode more complex capabilities.
	The GENERAL-CAP sub-TLV has the following format:		The GENERAL-CAP sub-TLV has the following format:
	TYPE: To be assigned by IANA (Suggested value =4)		TYPE: To be assigned by IANA (Suggested value =4)
	LENGTH: It is set to N. N starts from 1 and can be increased when		LENGTH: It is set to N. N starts from 1 and can be increased when
	there is a need. Each octet is referred to as a		there is a need. Each octet is referred to as a
	capability flag.		capability flag.
	VALUE: This comprises one or more general PCE capability		VALUE: This comprises one or more general PCE capability
	flags.		flags.
	The following bits in the first capability flag are to be assigned by		The following bits in the first capability flag are to be assigned by
	IANA:		IANA:
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|P|M| Reserved |		|P|M| Reserved |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	P bit: Support for request prioritization.		P bit: Support for request prioritization.
	M bit: Support for multiple messages within the same request message.		M bit: Support for multiple messages within the same request message.
	Reserved bits are for future assignment by IANA.		Reserved bits are for future assignment by IANA.
	6.1.6. The PATH-COMP-CAP sub-TLV		6.1.6. The PATH-COMP-CAP sub-TLV
	The PATH-COMP-CAP sub-TLV is used to indicate path computation		The PATH-COMP-CAP sub-TLV is an optional TLV used to indicate path
	specific capabilities of a PCE.		computation specific capabilities of a PCE.
	The PATH-COMP-CAP sub-TLV is optional. It MAY be carried within the
	PCED TLV.
	This is a series of bit flags, where each bit correspond to a path		This is a series of bit flags, where each bit correspond to a path
	computation capability.		computation capability. It MAY also include optional sub-TLVs to
			encode more complex capabilities.
	The PATH-COMP-CAP sub-TLV has the following format:		The PATH-COMP-CAP sub-TLV has the following format:
	TYPE: To be assigned by IANA (suggested value = 5)		TYPE: To be assigned by IANA (suggested value = 5)
	LENGTH: It is set to N. N starts from 1 and can be increased		LENGTH: It is set to N. N starts from 1 and can be increased
	when there is a need. Each octet is referred to as a		when there is a need. Each octet is referred to as a
	capability flag.		capability flag.
	VALUE: This comprises one or more Path Computation specific PCE		VALUE: This comprises one or more Path Computation specific PCE
	capability flags.		capability flags.
	The following bits in the first capability flag are to be assigned by		The following bits in the first capability flag are to be assigned by
	IANA.		IANA.
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|M|G|D|L|S|0|Res|		|M|G|D|L|S|0|Res|
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	M bit: Capability to compute P2P paths in MPLS-TE networks		G bit: Capability to handle GMPLS constraints
	G bit: Capability to compute P2P paths in GMPLS networks		B bit: Capability to compute bidirectional paths
	D bit: Capability to compute link/node/SRLG diverse paths		D bit: Capability to compute link/node/SRLG diverse paths
	L bit: Capability to compute load-balanced paths		L bit: Capability to compute load-balanced paths
	S bit: Capability to compute a set of paths in a		S bit: Capability to compute a set of paths in a
	synchronized Manner		synchronized Manner
	O bit: Support for multiple objective functions		O bit: Support for multiple objective functions
	Reserved bits are for future assignment by IANA.		Reserved bits are for future assignment by IANA.
	6.2. Elements of procedure		The G, B, D, L, S and O bits are not exclusive.
	The PCED TLV is carried within an IS-IS CAPABILITY TLV defined in		6.2. The ISIS PCES TLV
	[IS-IS-CAP].
	An IS-IS router MUST originate a new IS-IS LSP whenever the content		The ISIS PCE Status TLV (PCES TLV) carries information related to PCE
			processing congestion state.
			The PCES TLV is carried within an ISIS Capability TLV which is
			defined in [ISIS-CAP].
			The ISIS PCES TLV has the following format:
			TYPE: To be assigned by IANA
			LENGTH: Variable
			VALUE: set of sub-TLVs
			Sub-TLVs types are under IANA control.
			Currently two sub-TLVs are defined (suggested type values to be
			assigned by IANA):
			Sub-TLV type Length Name
			1 variable PCE-ADDRESS sub-TLV
			2 3 CONGESTION sub-TLV
			The PCE-ADDRESS and CONGESTION sub-TLVs MUST be present once
			in a PCES TLV. The PCE-ADDRESS sub-TLV is defined in section 6.1.1.
			It carries one of the PCE IP addresses and is used to identify the
			PCE the processing congestion state information is applied to. This
			is required as the PCES and PCED TLVs may be carried in separate
			ISIS Capability TLVs.
			Any non recognized sub-TLV MUST be silently ignored.
			Additional sub-TLVs could be added in the future to advertise
			additional congestion information.
			6.2.1. The CONGESTION sub-TLV
			The CONGESTION sub-TLV is used to indicate whether a PCE experiences
			a processing congestion state or not along with optionally the PCE
			expected congestion duration.
			The CONGESTION sub-TLV is mandatory. It MUST be carried once within
			the PCES TLV.
			The format of the CONGESTION sub-TLV is as follows:
			TYPE: To be assigned by IANA (Suggested value =2)
			LENGTH: 3
			VALUE: This comprises a one-byte flag of bits indicating the
			congestion status, followed by a 2-bytes field indicating the
			congestion duration.
			Here is the TLV structure
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|C| Reserved| Congestion Duration |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Value
			-C bit: When set this indicates that the PCE experiences
			congestion and cannot support any new request. When
			cleared this indicates that the PCE does not
			experiences congestion an can support a new request.
			-Congestion Duration: 2-bytes, the estimated PCE congestion
			duration in seconds.
			When C is set and the Congestion Duration field is equal to 0, this
			means that the Congestion Duration is unknown.
			When C is cleared the Congestion Duration MUST be set to 0.
			6.3. Elements of Procedure
			The PCED and PCES TLV are carried within an ISIS Capability TLV which
			is defined in [ISIS-CAP]. As PCES information is likely to change
			more frequently than the PCED information, it is RECOMMENDED to carry
			PCES and PCED TLVs in separate ISIS Capability TLVs, so as not to
			carry all PCED information each time the PCE status changes.
			6.3.1. PCED TLV Procedure
			An ISIS router MUST originate a new ISIS LSP whenever the content
	of any of the PCED TLV changes or whenever required by the regular		of any of the PCED TLV changes or whenever required by the regular
	IS-IS procedure (LSP refresh).		ISIS procedure (LSP refresh).
	When the scope of the PCED TLV is area local it MUST be carried		When the scope of the PCED TLV is area local it MUST be carried
	within an ISIS CAPABILITY TLV having the S bit cleared.		within an ISIS CAPABILITY TLV having the S bit cleared.
	When the scope of the PCED TLV is the entire domain, the PCED TLV		When the scope of the PCED TLV is the entire domain, the PCED TLV
	MUST be carried within an ISIS CAPABILITY TLV having the S bit set.		MUST be carried within an ISIS CAPABILITY TLV having the S bit set.
	Note that when the L bit of the PATH-SCOPE sub-TLV is set and the R		Note that when only the L bit of the PATH-SCOPE sub-TLV is set and
	and S bits are cleared the flooding scope MUST be local.		the flooding scope MUST be local.
	PCED TLVs are OPTIONAL. When an IS-IS LSP does not contain any PCED		PCED sub-TLVs are OPTIONAL. When an ISIS LSP does not contain
	TLV, this means that the PCE information of that node is unknown.		any PCED sub-TLV, this means that the PCE information of
			that node is unknown.
	Note that a change in PCED information MUST not trigger normal SPF		Note that a change in PCED information MUST not trigger any SPF
	computation.		computation.
	7. Backward compatibility		The way PCEs retrieve their own information is out of the scope of
			this document. Some information may be configured (e.g. address,
			preferences, scope) and other information may be automatically
			retrieved (e.g. areas of visibility).
	The PCED TLVs defined in this document do not introduce any		6.3.2. PCES TLV procedure
	interoperability issue. For OSPF, a router not supporting the PCED
	TLV SHOULD just silently ignore the TLV as specified in RFC2370. For
	IS-IS a router not supporting the PCED TLV SHOULD just silently
	ignore the TLV.
	8. Security Considerations		An ISIS router MUST originate a new ISIS LSP whenever the content
			of any of the PCES TLV changes or whenever required by the regular
			IS-IS procedure (LSP refresh).
	No new security issues are raised in this document.		When a PCE enters into a processing congestion state, the conditions
			of which are implementation dependent, it SHOULD originate a new ISIS
			LSP with a Capability TLV carrying a PCES TLV with the C bit set and
			optionally a non-null expected congestion duration.
	9. IANA considerations		When a PCE leaves the processing congestion state, the conditions of
			which are implementation dependent, there are two cases:
			- If the congestion duration in the previously originated PCES
			TLV was null, it SHOULD originate a PCES TLV with the C bit cleared
			and a null congestion duration;
			- If the congestion duration in the previously originated PCES
			TLV was non null, it MAY not originate a PCES TLV. Note that in some
			particular cases it may be desired to originate a PCES TLV with the C
			bit cleared if the saturation duration was over estimated.
	9.1. OSPF TLVs		The congestion duration allows reducing the amount of ISIS flooding,
			as only uncongested-congested state transitions are flooded.
			It is expected that a proper implementation will support dampening
			algorithms so as to dampen ISIS flooding in order to not impact the
			ISIS scalability. It is recommended to introduce some hysteresis for
			congestion state transition, so as to avoid state oscillations that
			may impact ISIS performances. For instance two thresholds could be
			configured: A resource saturation upper-threshold and a resource
			saturation lower-threshold. An LSR enters the congested state when
			the CPU load reaches the upper threshold and leaves the congested
			state when the CPU load goes under the lower threshold.
			Upon receipt of an updated PCES TLV a PCC should take appropriate
			actions. In particular, the PCC should stop sending requests to a
			congested PCE, and should gradually start sending again requests to a
			no longer congested PCE. Such PCC procedures are out of the scope of
			this document.
			7. Backward compatibility
			The PCED and PCEs TLVs defined in this document do not introduce any
			interoperability issue.
			For OSPF, a router not supporting the PCED/PCES TLVs SHOULD just
			silently ignore the TLVs as specified in [RFC2370].
			For ISIS a router not supporting the PCED/PCES TLVs SHOULD just
			silently ignore the TLV.
			8. IANA considerations
			8.1. OSPF TLVs
	IANA will assign a new codepoint for the OSPF PCED TLV defined in		IANA will assign a new codepoint for the OSPF PCED TLV defined in
	this document and carried within the Router Information LSA.		this document and carried within the Router Information LSA.
	Five sub-TLVs types are defined for this TLV and should be assigned		Five sub-TLVs types are defined for this TLV and should be assigned
	by IANA:		by IANA:
	-PCE-ADDRESS sub-TLV (suggested value = 1)		-PCE-ADDRESS sub-TLV (suggested value = 1)
	-PATH-SCOPE sub-TLV (suggested value = 2)		-PATH-SCOPE sub-TLV (suggested value = 2)
	-PCE-DOMAINS sub-TLV (suggested value = 3)		-PCE-DOMAINS sub-TLV (suggested value = 3)
	-PCE-DEST-DOMAINS sub-TLV (suggested value =4)		-PCE-DEST-DOMAINS sub-TLV (suggested value =4)
	-GENERAL-CAP sub-TLV (suggested value = 5)		-GENERAL-CAP sub-TLV (suggested value = 5)
	-PATH-COMP-CAP sub-TLV (suggested value = 6)		-PATH-COMP-CAP sub-TLV (suggested value = 6)
	Three sub-TLVs types are defined for the PCE-DOMAINS and PCE-DEST-		Three sub-TLVs types are defined for the PCE-DOMAINS and PCE-DEST-
	DOMAINS TLVs and should be assigned by IANA:		DOMAINS TLVs and should be assigned by IANA:
	-IPv4 area ID sub-TLV (suggested value = 1)		-IPv4 area ID sub-TLV (suggested value = 1)
	-IPv6 area ID sub-TLV (suggested value = 2)		-IPv6 area ID sub-TLV (suggested value = 2)
	-AS number sub-TLV (suggested value = 3)		-AS number sub-TLV (suggested value = 3)
	9.2. ISIS TLVs		IANA will assign a new codepoint for the OSPF PCES TLV defined in
			this document and carried within the Router Information LSA.
			Two sub-TLVs types are defined for this TLV and should be assigned by
			IANA:
			-PCE-ADDRESS sub-TLV (suggested value = 1)
			-CONGESTION sub-TLV (suggested value = 2)
			8.2. ISIS TLVs
	IANA will assign a new codepoint for the PCED TLV defined in this		IANA will assign a new codepoint for the PCED TLV defined in this
	document and carried within the ISIS CAPABILITY TLV.		document and carried within the ISIS CAPABILITY TLV.
	Five sub-TLVs types are defined for the PCED TLV and should be		Five sub-TLVs types are defined for the PCED TLV and should be
	assigned by IANA:		assigned by IANA:
	-PCE-ADDRESS sub-TLV (suggested value = 1)		-PCE-ADDRESS sub-TLV (suggested value = 1)
	-PATH-SCOPE sub-TLV (suggested value = 2)		-PATH-SCOPE sub-TLV (suggested value = 2)
	-PCE-DOMAINS sub-TLV (suggested value = 3)		-PCE-DEST-DOMAINS sub-TLV (suggested value = 3)
	-GENERAL-CAP sub-TLV (suggested value = 4)		-PCE-DOMAINS sub-TLV (suggested value = 4)
	-PATH-COMP-CAP sub-TLV (suggested value = 5)		-GENERAL-CAP sub-TLV (suggested value = 5)
			-PATH-COMP-CAP sub-TLV (suggested value = 6)
	Two sub-TLVs types are defined for the PCE-DOMAINS and PCE-DEST-		Two sub-TLVs types are defined for the PCE-DOMAINS and PCE-DEST-
	DOMAINS TLVs and should be assigned by IANA:		DOMAINS TLVs and should be assigned by IANA:
	-Area ID sub-TLV (suggested value = 1)		-Area ID sub-TLV (suggested value = 1)
	-AS number sub-TLV (suggested value = 2)		-AS number sub-TLV (suggested value = 2)
	9.3. Capability bits		IANA will assign a new codepoint for the ISIS PCES TLV defined in
			this document and carried within the ISIS CAPABILITY TLV.
			Two sub-TLVs types are defined for this TLV and should be assigned by
			IANA:
			-PCE-ADDRESS sub-TLV (suggested value = 1)
			-CONGESTION sub-TLV (suggested value = 2)
			8.3. Capability bits
	IANA is requested to manage the space of general and path computation		IANA is requested to manage the space of general and path computation
	specific PCE capability bits flags, numbering them in the usual IETF		specific PCE capability bits flags, numbering them in the usual IETF
	notation starting at zero and continuing at least through 31.		notation starting at zero and continuing at least through 31.
	New bit numbers may be allocated only by an IETF Consensus action.		New bit numbers may be allocated only by an IETF Consensus action.
	Each bit should be tracked with the following qualities:		Each bit should be tracked with the following qualities:
	- Bit number		- Bit number
	- Defining RFC		- Defining RFC
	- Name of bit		- Name of bit
	Currently two bits are defined in the first general PCE capability		Currently two bits are defined in the first general PCE capability
	flag. Here are the suggested values:		flag. Here are the suggested values:
	-0: Support for Request prioritization.		-0: Support for Request prioritization.
	-1: Support for multiple messages within the same request message		-1: Support for multiple messages within the same request message
	Currently six bits are defined in the first path computation specific		Currently six bits are defined in the first path computation specific
	PCE capability flag. Here are the suggested values:		PCE capability flag. Here are the suggested values:
	-0: Capability to compute P2P paths in MPLS-TE networks		-0: Capability to handle GMPLS Constraints
	-1: Capability to compute P2P paths in GMPLS networks		-1: Capability to compute bidirectional paths
	-2: Capability to compute link/node/SRLG diverse paths		-2: Capability to compute link/node/SRLG diverse paths
	-3: Capability to compute load-balanced paths		-3: Capability to compute load-balanced paths
	-4: Capability to compute a set of paths in a		-4: Capability to compute a set of paths in a
	synchronized Manner		synchronized Manner
	-5: Support for multiple objective functions		-5: Support for multiple objective functions
	10. Security Considerations		9. Security Considerations
	No new security issues are raised in this document.		To be completed in further revisions.
	11. References		10. References
	11.1. Normative references		10.1. Normative references
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119, March 1997.
			[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
			3667, February 2004.
			[BCP79] Bradner, S., "Intellectual Property Rights in IETF
			Technology", RFC 3979, March 2005.
	[OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.		[OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
			[RFC2370] Coltun, R., “The OSPF Opaque LSA Option”, RFC 2370, July
			1998.
	[IS-IS] "Intermediate System to Intermediate System Intra-Domain		[IS-IS] "Intermediate System to Intermediate System Intra-Domain
	Routing Exchange Protocol " ISO 10589.		Routing Exchange Protocol " ISO 10589.
	[IS-IS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and		[IS-IS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
	dual environments", RFC 1195, December 1990.		dual environments", RFC 1195, December 1990.
	[OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering		[OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
	Extensions to OSPF Version 2", RFC 3630, September 2003.		Extensions to OSPF Version 2", RFC 3630, September 2003.
	[IS-IS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic		[IS-IS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic
	skipping to change at page 24, line 41 ¶		skipping to change at page 30, line 34 ¶
	[IS-IS-CAP] Vasseur, J.P. et al., "IS-IS extensions for advertising		[IS-IS-CAP] Vasseur, J.P. et al., "IS-IS extensions for advertising
	router information", draft-ietf-isis-caps, work in progress.		router information", draft-ietf-isis-caps, work in progress.
	[PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation		[PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation
	Element (PCE) Architecture", draft-ietf-pce-architecture, work in		Element (PCE) Architecture", draft-ietf-pce-architecture, work in
	progress.		progress.
	[PCE-DISCO-REQ] Le Roux, J.L., et al. "Requirements for PCE		[PCE-DISCO-REQ] Le Roux, J.L., et al. "Requirements for PCE
	discovery", draft-ietf-pce-discovery-reqs, work in progress		discovery", draft-ietf-pce-discovery-reqs, work in progress
	11.2. Informative references		10.2. Informative references
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
	3667, February 2004.
	[RFC3668] Bradner, S., "Intellectual Property Rights in IETF
	Technology", BCP 79, RFC 3668, February 2004.
	[PCE-COM-REQ] Ash, J., Le Roux, J.L., " PCE Communication Protocol		[PCECP-REQ] Ash, J., Le Roux, J.L., " PCE Communication Protocol
	Generic Requirements", draft-ietf-pce-comm-protocol-gen-reqs, work in		Generic Requirements", draft-ietf-pce-comm-protocol-gen-reqs, work in
	progress.		progress.
	12. Authors' Addresses:		[PCEP] Vasseur et al., “Path Computation Element (PCE) communication
			Protocol (PCEP) - Version 1”, draft-ietf-pce-pcep-01.txt, work in
			progress.
	Jean-Louis Le Roux		11. Authors' Addresses:
			Jean-Louis Le Roux (Editor)
	France Telecom		France Telecom
	2, avenue Pierre-Marzin		2, avenue Pierre-Marzin
	22307 Lannion Cedex		22307 Lannion Cedex
	FRANCE		FRANCE
	Email: jeanlouis.leroux@francetelecom.com		Email: jeanlouis.leroux@francetelecom.com
	Jean-Philippe Vasseur		Jean-Philippe Vasseur (Editor)
	Cisco Systems, Inc.		Cisco Systems, Inc.
	300 Beaver Brook Road		1414 Massachusetts avenue
	Boxborough , MA - 01719		Boxborough , MA - 01719
	USA		USA
	Email: jpv@cisco.com		Email: jpv@cisco.com
	Yuichi Ikejiri		Yuichi Ikejiri
	NTT Communications Corporation		NTT Communications Corporation
	1-1-6, Uchisaiwai-cho, Chiyoda-ku		1-1-6, Uchisaiwai-cho, Chiyoda-ku
	Tokyo 100-8019		Tokyo 100-8019
	JAPAN		JAPAN
	Email: y.ikejiri@ntt.com		Email: y.ikejiri@ntt.com
	13. Intellectual Property Statement		Raymond Zhang
			BT Infonet
			2160 E. Grand Ave.
			El Segundo, CA 90025
			USA
			Email: raymond_zhang@infonet.com
			12. Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		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		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	skipping to change at page 26, line 16 ¶		skipping to change at page 32, line 4 ¶
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
			Copyright (C) The Internet Society (2006). This document is subject
	Copyright (C) The Internet Society (2005). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
End of changes. 141 change blocks.
	347 lines changed or deleted		663 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/