< draft-leroux-pce-contract-id-00.txt		draft-leroux-pce-contract-id-01.txt >
	Network Working Group J.L. Le Roux		Network Working Group J.L. Le Roux
	Internet Draft France Telecom		Internet Draft France Telecom
	Category: Standard Track		Category: Standard Track
	Expires: September 2007 R. Jacob		Expires: September 2007 R. Jacob
	Brighthaul		Brighthaul
			R. Douville
			Alcatel-Lucent
	March 2007		March 2007
	Carrying a Contract Identifier in the PCE communication Protocol (PCEP)		Carrying a Contract Identifier in the PCE communication Protocol (PCEP)
	draft-leroux-pce-contract-id-00.txt		draft-leroux-pce-contract-id-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 2, line 10 ¶		skipping to change at page 2, line 10 ¶
	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
	The Path Computation Element (PCE) based architecture can be used for		The Path Computation Element (PCE) based architecture can be used for
	computing Traffic Engineered Label Switched Paths (TE LSP) that		computing Traffic Engineered Label Switched Paths (TE LSP) that
	traverse multiple Autonomous Systems (AS) in MultiProtocol Label		traverse multiple Autonomous Systems (AS) in MultiProtocol Label
	Switching (MPLS) and Generalized MPLS (GMPLS) networks. This requires		Switching (MPLS) and Generalized MPLS (GMPLS) networks. This may
	communication between PCEs in each AS, based upon on the PCE		require communication between PCEs in each AS, based upon on the PCE
	communication Protocol (PCEP). When ASes belong to distinct service		communication Protocol (PCEP). When ASes belong to distinct service
	providers, a per-service negotiation and activation procedure may be		providers, a per-service negotiation and activation procedure may be
	required before starting PCE based path computation. For the sake of		required before starting PCE based path computation. For the sake of
	illustration, the IPSphere Forum (IPSF) is currently specifying an		illustration, the IPSphere Forum (IPSF) is currently specifying an
	architecture so as to automate the negotiation and activation of such		architecture so as to automate the negotiation and activation of such
	an inter-provider TE LSP service. The result of such negotiation is a		an inter-provider TE LSP service. The result of such negotiation is a
	per-service contract identifier that needs to be carried in PCEP, so		per-service contract identifier that needs to be carried in PCEP, so
	that PCEs can apply inter-provider path computation policies. For		that PCEs can apply inter-provider path computation policies. For
	that purpose, this draft defines an extension to the PCEP protocol so		that purpose, this draft defines an extension to the PCEP protocol so
	as to carry a contract ID in request messages.		as to carry a contract ID in request messages.
	skipping to change at page 2, line 33 ¶		skipping to change at page 2, line 33 ¶
	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. Terminology.................................................3		1. Terminology.................................................3
	2. Introduction................................................3		2. Introduction................................................3
	3. PCEP CONTRACT-ID Object Definition..........................4		3. PCEP CONTRACT-ID Object definition..........................4
	3.1. Carrying the CONTRACT-ID Object in PCReq Messages...........5		3.1. Carrying the CONTRACT-ID object in PCReq messages...........5
	4. Elements of Procedure.......................................6		4. Elements of procedure.......................................6
	5. IANA Considerations.........................................7		5. IANA Considerations.........................................7
	5.1. CONTRACT-ID Object..........................................7		5.1. CONTRACT-ID Object..........................................7
	5.2. PCEP Error Value............................................7		5.2. PCEP Error values...........................................7
	6. Backward Compatibility......................................7		6. Backward Compatibility......................................7
	7. Security Considerations.....................................7		7. Security Considerations.....................................7
	8. Manageability Considerations................................7		8. Manageability Considerations................................7
	9. Acknowledgments.............................................7		9. Acknowledgments.............................................7
	10. References..................................................8		10. References..................................................8
	10.1. Normative References........................................8		10.1. Normative references........................................8
	10.2. Informative References......................................8		10.2. Informative references......................................8
	11. Author's Addresses:.........................................8		11. Author's Addresses:.........................................8
	12. Intellectual Property Statement.............................9		12. Intellectual Property Statement.............................9
	1. Terminology		1. Terminology
	Terminology used in this document		Terminology used in this document
	PCC: Path Computation Client: Any client application requesting a		PCC: Path Computation Client: Any client application requesting a
	path computation to be performed by a Path Computation Element.		path computation to be performed by a Path Computation Element.
	PCE: Path Computation Element: An entity (component, application,		PCE: Path Computation Element: An entity (component, application,
	or network node) that is capable of computing a network path or		or network node) that is capable of computing a network path or
	route based on a network graph, and applying computational		route based on a network graph, and applying computational
	constraints.		constraints.
	BRPC: Backward Recursive PCE based path Computation. Procedure		BRPC: Backward Recursive PCE based path Computation. Procedure
	relying on inter-PCE communication to compute shortest inter-		relying on inter-PCE communication to compute shortest inter-
	domain Traffic Engineering Label Switched Paths.		domain Traffic Engineering Label Switched Paths.
	Inter-AS TE LSP: A TE LSP whose path transits two or more		Inter-AS TE LSP: A TE LSP whose path transits two or more
	ASes or sub-ASes (BGP confederations). That is a TE-LSP that		ASes or sub-ASes (BGP confederations). That is a TE LSP that
	crosses at least one AS boundary.		crosses at least one AS boundary.
	Inter-Provider TE LSP: A TE LSP whose path transits two or more		Inter-Provider TE LSP: A TE LSP whose path transits two or more
	providers. That is a TE-LSP that crosses at least one provider		providers. That is a TE LSP that crosses at least one provider
	boundary.		boundary.
	PCEP: Path Computation Element communication Protocol.		PCEP: Path Computation Element communication Protocol.
	TE LSP: Traffic Engineered Label Switched Path.		TE LSP: Traffic Engineered Label Switched Path.
	AS: Autonomous System.		AS: Autonomous System.
	UUID: Universally Unique IDentifier.		UUID: Universally Unique IDentifier.
	skipping to change at page 4, line 35 ¶		skipping to change at page 4, line 35 ¶
	service contract identifier in request messages. A new PCEP CONTRACT-		service contract identifier in request messages. A new PCEP CONTRACT-
	ID object is defined, to be carried in PCReq messages, the content of		ID object is defined, to be carried in PCReq messages, the content of
	which is transparent and not processed at the PCEP level. The		which is transparent and not processed at the PCEP level. The
	CONTRACT-ID object is communicated to a service Policy Decision Point		CONTRACT-ID object is communicated to a service Policy Decision Point
	(PDP) to apply policies (request acceptance/rejection, TE parameters		(PDP) to apply policies (request acceptance/rejection, TE parameters
	filtering/translation, next-AS determination, etc.). There is no		filtering/translation, next-AS determination, etc.). There is no
	assumption on the way the object is communicated to the PDP, as well		assumption on the way the object is communicated to the PDP, as well
	as on the actual location of the PDP; this is beyond the scope of		as on the actual location of the PDP; this is beyond the scope of
	this document.		this document.
	3. PCEP CONTRACT-ID Object Definition		Note that the use of policies within the PCE Architecture is
			extensively discussed in [PCE-POLICY].
			3. PCEP CONTRACT-ID Object definition
	The PCEP CONTRACT-ID object defined in this document is compliant		The PCEP CONTRACT-ID object defined in this document is compliant
	with the PCEP object format defined in [PCEP].		with the PCEP object format defined in [PCEP].
	The PCEP CONTRACT-ID object is optional, it MAY be carried within a		The PCEP CONTRACT-ID object is optional, it MAY be carried within a
	PCReq message. It carries the identifier of the TE LSP service		PCReq message. It carries the identifier of the TE LSP service
	contract that has been negotiated and instantiated at the service		contract that has been negotiated and instantiated at the service
	level, between all service providers along the LSP path. It allows		level, between all service providers along the LSP path. It allows
	applying policies to the inter-provider path computation requests,		applying policies to the inter-provider path computation requests,
	based upon a beforehand agreed service.		based upon the beforehand agreed service.
	When carried in a PCEP message, this object has to be supported by		When carried in a PCReq message, this object has to be supported by
	the PCE, and hence, according to [PCEP], the P flag in the object		the PCE, and hence, according to [PCEP], the P flag in the object
	header MUST always be set.		header MUST always be set.
	The Contract-ID Object-Class is to be assigned by IANA (recommended		The Contract-ID Object-Class is to be assigned by IANA (recommended
	value=19).		value=19).
	The Contract-ID Object-Type is to be assigned by IANA (recommended		The Contract-ID Object-Type is to be assigned by IANA (recommended
	value=1).		value=1).
	The format of the Contract-ID object body is as follows:		The format of the Contract-ID object body is as follows:
	skipping to change at page 5, line 21 ¶		skipping to change at page 5, line 26 ¶
	| |		| |
	| 128 bit Contract-ID |		| 128 bit Contract-ID |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Contract-ID (128 bit): Identifier of the inter-provider TE LSP		Contract-ID (128 bit): Identifier of the inter-provider TE LSP
	service, instantiated at the service level. It is encoded as a		service, instantiated at the service level. It is encoded as a
	Universally Unique IDentifier (UUID) as per defined in [RFC4122].		Universally Unique IDentifier (UUID) as per defined in [RFC4122].
	3.1. Carrying the CONTRACT-ID Object in PCReq Messages		3.1. Carrying the CONTRACT-ID object in PCReq messages
	The CONTRACT-ID object MAY be carried within a PCReq message. It is		The CONTRACT-ID object MAY be carried within a PCReq message. It is
	carried after the RP object for which it applies.		carried after the RP object for which it applies.
	The format of the PCReq message, defined in [PCEP], is updated as		The format of the PCReq message, defined in [PCEP], is updated as
	follows:		follows:
	<PCReq Message>::= <Common Header>		<PCReq Message>::= <Common Header>
	[<SVEC-list>]		[<SVEC-list>]
	<request-list>		<request-list>
	skipping to change at page 6, line 5 ¶		skipping to change at page 6, line 5 ¶
	[<LSPA>]		[<LSPA>]
	[<BANDWIDTH>]		[<BANDWIDTH>]
	[<metric-list>]		[<metric-list>]
	[<RRO>]		[<RRO>]
	[<IRO>]		[<IRO>]
	[<LOAD-BALANCING>]		[<LOAD-BALANCING>]
	where:		where:
	<metric-list>::=<METRIC>[<metric-list>]		<metric-list>::=<METRIC>[<metric-list>]
	4. Elements of Procedure		4. Elements of procedure
	The CONTRACT-ID object MAY be used during PCE based inter-provider		The CONTRACT-ID object MAY be used during PCE based inter-provider
	path computation with inter-PCE Communication.		path computation with inter-PCE communication.
	The P bit in the object header MUST always be set.		The P bit in the object header MUST always be set.
	On receipt of a PCReq message with a CONTRACT-ID object, a PCE MUST		On receipt of a PCReq message with a CONTRACT-ID object, a PCE MUST
	proceed as follows:		proceed as follows:
	- If the object is unknown or unsupported, the PCE follows		- If the object is unknown or unsupported, the PCE follows
	procedures defined in [PCEP], that is, as the P flag is set, it		procedures defined in [PCEP], that is, as the P flag is set, it
	sends a PCErr message with error type unknown object (type		sends a PCErr message with error type unknown object (type
	3), or unsupported object (type 4) respectively.		3), or unsupported object (type 4) respectively.
	skipping to change at page 6, line 32 ¶		skipping to change at page 6, line 32 ¶
	Point (PDP) so as to apply service policies based upon the		Point (PDP) so as to apply service policies based upon the
	contract identifier (this may include request acceptance /		contract identifier (this may include request acceptance /
	rejection, TE parameters filtering / translation, next-AS		rejection, TE parameters filtering / translation, next-AS
	determination, etc.):		determination, etc.):
	- If the request is accepted and the PCReq message has		- If the request is accepted and the PCReq message has
	to be propagated to a downstream PCE, the downstream		to be propagated to a downstream PCE, the downstream
	PCReq message MUST contain a CONTRACT-ID object whose		PCReq message MUST contain a CONTRACT-ID object whose
	contract id value is determined by policy decision; this		contract id value is determined by policy decision; this
	may be the same or a distinct value (to support cases		may be the same or a distinct value (to support cases
	where the next provider PCE has a different contractID).		where the next provider PCE has a different contract
			ID).
	- If the request is rejected, the PCReq message MUST not		- If the request is rejected due to service policies,
	be propagated downstream, and the PCE MUST send upstream		the PCReq message MUST not be propagated downstream, and
	a PCErr message with error-type policy violation (type5)		the PCE MUST send upstream a PCErr message with error-
	and new error value "service admission control failure"		type policy violation (type 5) and an error value
	(defined in this document).		indicating the reasons for the rejection. Three new
			error values are defined in this document for service
			policies: "service admission control failure", "service
			parameter violation", and "unknown contract ID".
	5. IANA Considerations		5. IANA Considerations
	5.1. CONTRACT-ID Object		5.1. CONTRACT-ID Object
	The IANA has been requested to manage the PCEP Objects code point		The IANA has been requested to manage the PCEP Objects code point
	registry (see [PCEP]).		registry (see [PCEP]).
	This document defines a new PCEP object, the CONTRACT-ID object to		This document defines a new PCEP object, the CONTRACT-ID object to
	be carried in PCReq messages. The IANA is requested to make the		be carried in PCReq messages. The IANA is requested to make the
	following allocation (suggested value):		following allocation (suggested value):
	Object Name Object Name Reference		Object Name Object Name Reference
	Class Type		Class Type
	19 CONTRACT-ID 1 Contract (this document)		19 CONTRACT-ID 1 Contract (this document)
	Identifier		Identifier
	5.2. PCEP Error Value		5.2. PCEP Error values
	A new error values is defined for the error type "policy violation":		Three new error values are defined for the error type "policy
			violation":
	Error-type Meaning and error values Reference		Error-type Meaning and error values Reference
	5 Policy violation		5 Policy violation
	Error-value=5: service admission control (this doc)		Error-value=5: service admission control (this doc)
	failure (request rejected)		failure (request rejected)
			Error-value=6: service parameter violation (this doc)
			(request rejected)
			Error-value=7: unknown contract-ID (this doc)
			(request rejected)
	6. Backward Compatibility		6. Backward Compatibility
	TBC		TBC
	7. Security Considerations		7. Security Considerations
	TBC		TBC
	8. Manageability Considerations		8. Manageability Considerations
	TBC		TBC
	9. Acknowledgments		9. Acknowledgments
	TBC		We would like to thank Dimitri Papadimitriou for the useful comments.
	10. References		10. References
	10.1. Normative References		10.1. Normative references
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",		[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
	RFC 2740, December 1999.		RFC 2740, December 1999.
	[RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation		[RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation
	Element (PCE)-based Architecture", RFC4655, august 2006.		Element (PCE)-based Architecture", RFC4655, august 2006.
	[PCEP] Vasseur, Le Roux, et al., "Path Computation Element (PCE)		[PCEP] Vasseur, Le Roux, et al., "Path Computation Element (PCE)
	communication Protocol (PCEP) - Version 1", draft-ietf-pce-pcep, work		communication Protocol (PCEP) - Version 1", draft-ietf-pce-pcep, work
	in progress.		in progress.
	[RFC4122] P. Leach, M. Mealling, R. Salz, " A Universally Unique		[RFC4122] P. Leach, M. Mealling, R. Salz, " A Universally Unique
	IDentifier (UUID) URN Namespace", RFC4122, July 2005.		IDentifier (UUID) URN Namespace", RFC4122, July 2005.
	10.2. Informative References		10.2. Informative references
	[RFC4657] Ash, J., Le Roux, J.L., "PCE Communication Protocol Generic		[RFC4657] Ash, J., Le Roux, J.L., "PCE Communication Protocol Generic
	Requirements", RFC4657, September 2006.		Requirements", RFC4657, September 2006.
	[BRPC] Vasseur, Zhang, Bitar, Le Roux, " A Backward Recursive PCE-		[BRPC] Vasseur, Zhang, Bitar, Le Roux, " A Backward Recursive PCE-
	based Computation (BRPC) procedure to compute shortest inter-domain		based Computation (BRPC) procedure to compute shortest inter-domain
	Traffic Engineering Label Switched Paths", draft-ietf-pce-brpc, work		Traffic Engineering Label Switched Paths", draft-ietf-pce-brpc, work
	in progress.		in progress.
	[IPSF-IC-MPLS] Drai, R., Jacob, Y., Le Roux, J.L., Vasseur, J.P.,		[IPSF-IC-MPLS] Drai, R., Jacob, Y., Le Roux, J.L., Vasseur, J.P.,
	"Inter-Carrier Traffic-Engineering LSP Component use-case		"Inter-Carrier Traffic-Engineering LSP Component use-case
	architecture spec", IPSF Reference Architecture WG draft, work in		architecture spec", IPSF Reference Architecture WG draft, work in
	progress.		progress.
			[PCE-POLICY] Bryskin, Papadimitriou, Berger, "Policy Enabled Path
			Computation Framework", draft-ietf-pce-policy-enabled-path-comp, work
			in progress.
	11. Author's Addresses:		11. Author's Addresses:
	Jean-Louis Le Roux		Jean-Louis Le Roux
	France Telecom		France Telecom
	2, avenue Pierre-Marzin		2, avenue Pierre-Marzin
	22307 Lannion Cedex		22307 Lannion Cedex
	FRANCE		FRANCE
	Email: jeanlouis.leroux@orange-ftgroup.com		Email: jeanlouis.leroux@orange-ftgroup.com
	Ron Jacob		Ron Jacob
	Brighthaul		Brighthaul
	16 Galgalei Haplada, Herzelia		16 Galgalei Haplada, Herzelia
	ISRAEL		ISRAEL
	Email: ron@brighthaul.com		Email: ron@brighthaul.com
			Richard Douville
			Alcatel-Lucent
			Centre de Villarceaux
			91620 Nozay
			FRANCE
			Email: richard.Douville@alcatel-lucent.fr
	12. Intellectual Property Statement		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.
End of changes. 27 change blocks.
	31 lines changed or deleted		56 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/