Network Working Group J.L. Le Roux Internet Draft France Telecom Category: Standard Track Expires: September 2007 R. Jacob Brighthaul R. Douville Alcatel-Lucent March 2007 Carrying a Contract Identifier in the PCE communication Protocol (PCEP) draft-leroux-pce-contract-id-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Le Roux, Jacob, Douville PCE Contract ID [Page 1] Internet Draft draft-leroux-pce-contract-id-01.txt March 2007 Abstract The Path Computation Element (PCE) based architecture can be used for computing Traffic Engineered Label Switched Paths (TE LSP) that traverse multiple Autonomous Systems (AS) in MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. This may require communication between PCEs in each AS, based upon on the PCE communication Protocol (PCEP). When ASes belong to distinct service providers, a per-service negotiation and activation procedure may be required before starting PCE based path computation. For the sake of illustration, the IPSphere Forum (IPSF) is currently specifying an architecture so as to automate the negotiation and activation of such 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 that PCEs can apply inter-provider path computation policies. For that purpose, this draft defines an extension to the PCEP protocol so as to carry a contract ID in request messages. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. Table of Contents 1. Terminology.................................................3 2. Introduction................................................3 3. PCEP CONTRACT-ID Object definition..........................4 3.1. Carrying the CONTRACT-ID object in PCReq messages...........5 4. Elements of procedure.......................................6 5. IANA Considerations.........................................7 5.1. CONTRACT-ID Object..........................................7 5.2. PCEP Error values...........................................7 6. Backward Compatibility......................................7 7. Security Considerations.....................................7 8. Manageability Considerations................................7 9. Acknowledgments.............................................7 10. References..................................................8 10.1. Normative references........................................8 10.2. Informative references......................................8 11. Author's Addresses:.........................................8 12. Intellectual Property Statement.............................9 Le Roux, Jacob, Douville PCE Contract ID [Page 2] Internet Draft draft-leroux-pce-contract-id-01.txt March 2007 1. Terminology Terminology used in this document 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. BRPC: Backward Recursive PCE based path Computation. Procedure relying on inter-PCE communication to compute shortest inter- domain Traffic Engineering Label Switched Paths. 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 crosses at least one AS boundary. 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 boundary. PCEP: Path Computation Element communication Protocol. TE LSP: Traffic Engineered Label Switched Path. AS: Autonomous System. UUID: Universally Unique IDentifier. IPSF: IPSphere Forum. 2. Introduction The PCE-based network architecture [RFC4655] defines a Path Computation Element (PCE) as an entity capable of computing TE LSP paths based on a network graph, and applying computational constraints. A PCE serves path computation requests sent by Path Computation Clients (PCC). The PCE communication Protocol (PCEP) [PCEP], allows for communication between a PCC and a PCE or between two PCEs, in compliance with requirements and guidelines set forth in [RFC4657]. Such interactions include path computation requests and path computation replies. The computation of inter-AS TE LSPs may rely on the Backward Recursive PCE based path Computation (BRPC) procedure that allows Le Roux, Jacob, Douville PCE Contract ID [Page 3] Internet Draft draft-leroux-pce-contract-id-01.txt March 2007 computing shortest inter-domain paths ([BRPC]). This relies upon one PCE per AS, with PCEP based inter-PCE communication. The computation of inter-provider TE LSPs may require, at the service and management plane levels, a preliminary service negotiation and activation procedure, between the set of providers the LSP will traverse. For the sake of illustration, the IPSphere Forum (IPSF) is currently working on a framework for the automatic negotiation and activation of an inter-provider TE LSP service [IPSF-IC-MPLS]. The result of such a negotiation is a contract identifier in the form of a Universally Unique IDentifier (UUID) (as per defined in [RFC4122]), which is then used to identify the agreed service and apply policies to control plane messages, including request acceptance/rejection as well as Traffic Engineering parameters filtering and translation. This contract identifier has to be carried in the PCEP protocol so that path computation requests can be policed according to the beforehand agreed service. For that purpose, this draft defines extensions to the PCE communication Protocol (PCEP) so as to transparently transport a service contract identifier in request messages. A new PCEP CONTRACT- ID object is defined, to be carried in PCReq messages, the content of which is transparent and not processed at the PCEP level. The CONTRACT-ID object is communicated to a service Policy Decision Point (PDP) to apply policies (request acceptance/rejection, TE parameters filtering/translation, next-AS determination, etc.). There is no 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 this document. 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 with the PCEP object format defined in [PCEP]. The PCEP CONTRACT-ID object is optional, it MAY be carried within a PCReq message. It carries the identifier of the TE LSP service contract that has been negotiated and instantiated at the service level, between all service providers along the LSP path. It allows applying policies to the inter-provider path computation requests, based upon the beforehand agreed service. 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 header MUST always be set. Le Roux, Jacob, Douville PCE Contract ID [Page 4] Internet Draft draft-leroux-pce-contract-id-01.txt March 2007 The Contract-ID Object-Class is to be assigned by IANA (recommended value=19). The Contract-ID Object-Type is to be assigned by IANA (recommended value=1). The format of the Contract-ID object body 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | 128 bit Contract-ID | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Contract-ID (128 bit): Identifier of the inter-provider TE LSP service, instantiated at the service level. It is encoded as a Universally Unique IDentifier (UUID) as per defined in [RFC4122]. 3.1. Carrying the CONTRACT-ID object in PCReq messages The CONTRACT-ID object MAY be carried within a PCReq message. It is carried after the RP object for which it applies. The format of the PCReq message, defined in [PCEP], is updated as follows: ::= [] where: ::= [] ::=[] ::= [] [] [] [] [] [] [] where: ::=[] Le Roux, Jacob, Douville PCE Contract ID [Page 5] Internet Draft draft-leroux-pce-contract-id-01.txt March 2007 4. Elements of procedure The CONTRACT-ID object MAY be used during PCE based inter-provider path computation with inter-PCE communication. 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 proceed as follows: - If the object is unknown or unsupported, the PCE follows procedures defined in [PCEP], that is, as the P flag is set, it sends a PCErr message with error type unknown object (type 3), or unsupported object (type 4) respectively. - If the object is supported, it MUST not be processed at the PCEP level and MUST be transparently passed to a Policy Decision Point (PDP) so as to apply service policies based upon the contract identifier (this may include request acceptance / rejection, TE parameters filtering / translation, next-AS determination, etc.): - If the request is accepted and the PCReq message has to be propagated to a downstream PCE, the downstream PCReq message MUST contain a CONTRACT-ID object whose contract id value is determined by policy decision; this may be the same or a distinct value (to support cases where the next provider PCE has a different contract ID). - If the request is rejected due to service policies, the PCReq message MUST not be propagated downstream, and the PCE MUST send upstream a PCErr message with error- type policy violation (type 5) and an error value 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". Le Roux, Jacob, Douville PCE Contract ID [Page 6] Internet Draft draft-leroux-pce-contract-id-01.txt March 2007 5. IANA Considerations 5.1. CONTRACT-ID Object The IANA has been requested to manage the PCEP Objects code point registry (see [PCEP]). This document defines a new PCEP object, the CONTRACT-ID object to be carried in PCReq messages. The IANA is requested to make the following allocation (suggested value): Object Name Object Name Reference Class Type 19 CONTRACT-ID 1 Contract (this document) Identifier 5.2. PCEP Error values Three new error values are defined for the error type "policy violation": Error-type Meaning and error values Reference 5 Policy violation Error-value=5: service admission control (this doc) 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 TBC 7. Security Considerations TBC 8. Manageability Considerations TBC 9. Acknowledgments We would like to thank Dimitri Papadimitriou for the useful comments. Le Roux, Jacob, Douville PCE Contract ID [Page 7] Internet Draft draft-leroux-pce-contract-id-01.txt March 2007 10. References 10.1. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999. [RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation Element (PCE)-based Architecture", RFC4655, august 2006. [PCEP] Vasseur, Le Roux, et al., "Path Computation Element (PCE) communication Protocol (PCEP) - Version 1", draft-ietf-pce-pcep, work in progress. [RFC4122] P. Leach, M. Mealling, R. Salz, " A Universally Unique IDentifier (UUID) URN Namespace", RFC4122, July 2005. 10.2. Informative references [RFC4657] Ash, J., Le Roux, J.L., "PCE Communication Protocol Generic Requirements", RFC4657, September 2006. [BRPC] Vasseur, Zhang, Bitar, Le Roux, " A Backward Recursive PCE- based Computation (BRPC) procedure to compute shortest inter-domain Traffic Engineering Label Switched Paths", draft-ietf-pce-brpc, work in progress. [IPSF-IC-MPLS] Drai, R., Jacob, Y., Le Roux, J.L., Vasseur, J.P., "Inter-Carrier Traffic-Engineering LSP Component use-case architecture spec", IPSF Reference Architecture WG draft, work in 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: Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE Email: jeanlouis.leroux@orange-ftgroup.com Le Roux, Jacob, Douville PCE Contract ID [Page 8] Internet Draft draft-leroux-pce-contract-id-01.txt March 2007 Ron Jacob Brighthaul 16 Galgalei Haplada, Herzelia ISRAEL Email: ron@brighthaul.com Richard Douville Alcatel-Lucent Centre de Villarceaux 91620 Nozay FRANCE Email: richard.Douville@alcatel-lucent.fr 12. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Le Roux, Jacob, Douville PCE Contract ID [Page 9] Internet Draft draft-leroux-pce-contract-id-01.txt March 2007 Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Le Roux, Jacob, Douville PCE Contract ID [Page 10]