Network Working Group Fatai Zhang Internet Draft Suresh B R Young Lee SenthilKumarS Category: Standards Track Jun Sun Huawei Expires: August 20, 2010 February 21 2010 Extensions to the Path Computation Element Communication Protocol for Traffic Engineering Label Switched Paths in GMPLS Networks draft-zhang-pce-pcep-extensions-for-gmpls-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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. This Internet-Draft will expire on August 20, 2010. Abstract This document defines the extensions for the Path Computation Element Communication Protocol (PCEP) to support the establishment of TE LSPs in GMPLS networks. zhang Expires August 2010 [Page 1] draft-zhang-pce-pcep-extensions-for-gmps-00.txt February 2010 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 [RFC2119]. Table of Contents 1. Introduction.................................................2 1.1. Requirements Language...................................3 2. Terminology..................................................3 3. PCEP Requirements............................................3 4. Protocol Procedure and Extensions............................4 4.1. SWITCH-LAYER Object.....................................4 4.2. END-POINTS Object Extension.............................4 4.2.1. Destination Prefix Information TLV.................4 4.3. New Object - QoS........................................5 4.3.1. Traffic Parameters TLV.............................6 4.3.2. LSP Protection Information TLV.....................7 4.3.3. SWITCH-LAYER and QoS Object in PCReq and PCRep.....7 4.4. NO-PATH Object Extension................................8 4.4.1. Extensions to NO-PATH-VECTOR TLV...................9 4.5. Additional Error Type and Error Values Defined..........9 5. Liveness Detection and Monitoring...........................10 6. IANA Considerations.........................................10 6.1. New PCEP Object........................................10 6.2. New PCEP TLVs..........................................11 6.3. PCEP NO-PATH-VECTOR TLV Flag Field.....................11 6.4. New PCEP Error Codes...................................12 7. Security Considerations.....................................12 8. Acknowledgements............................................12 9. References..................................................12 9.1. Normative References...................................12 9.2. Informative References.................................14 10. Authors' Addresses.........................................14 1. Introduction RFC4655 defines the PCE based architecture and explains how a PCE may compute LSPs in MPLS Traffic Engineering (TE) and GMPLS) networks at the request of Path Computation Clients (PCCs). zhang Expires August 2010 [Page 2] draft-zhang-pce-pcep-extensions-for-gmps-00.txt February 2010 RFC5440 specifies the PCEP for communication between a PCC and a PCE, or between two PCEs, in compliance with RFC4657. However, that it does not provide a mechanism to request path computation for establishing TE LSPs in GMPLS networks such as SDH network. [GMPLS- REQ] addresses the functional requirements for GMPLS in PCE application. This document describes the protocol extensions to PCEP to support path computation for TE LSP in GMPLS networks. 1.1. Requirements Language 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 RFC2119. 2. Terminology The following terminology is used in this document. PCC: Path Computation Client. Any client application requesting a path computation to be performed by the 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. PCEP: Path Computation Element Communication Protocol. PCEP is a request/response protocol used for the communication between a PCC and a PCE, or between two PCEs. PCEP Peer: An element involved in a PCEP session (For example, a PCC or a PCE). PCEP Session: The PCEP session is a logical connection established automatically between the PCEP peers. This document also uses the terminology defined in RFC4655, and RFC5440. 3. PCEP Requirements This section summarizes the PCEP extensions for GMPLS. This document introduces no new messages for PCEP. However, extensions have been introduced to the existing PCEP objects, sub-objects and TLVs. Also, zhang Expires August 2010 [Page 3] draft-zhang-pce-pcep-extensions-for-gmps-00.txt February 2010 a few new objects and TLVs have been introduced to support network type and QoS. The details on the PCEP objects and TLVs are mentioned below: Enhanced Objects o PCEP End Point (IPv4/Node ID) Object o PCEP NO-PATH Object Newly Introduced Object o PCEP QoS Object Newly Introduced TLVs o Destination Prefix Information o Traffic Parameters o LSP Protection Information 4. Protocol Procedure and Extensions 4.1. SWITCH-LAYER Object The PCE architecture can be extended to support various network types such as SDH, WDM, OTN, and PTN and so on. PCE MAY select the appropriate policy profile depending on the current path request which is applicable to a particular network type. The SWITCH-LAYER object is an OPTIONAL object and MUST be carried only in PCReq and PCRep message specifying the encoding and switching type of the network, to which the path request belongs to. This object is defined in [INTER-LAYER] (Section 3.2). 4.2. END-POINTS Object Extension The END-POINTS object is used in a PCReq message to specify the source IP address and the destination IP address of the path for which a path computation is requested. New OPTIONAL TLV is defined that is to be carried in the END-POINTS object for the path that depends on destination prefix information. 4.2.1. Destination Prefix Information TLV The Destination Prefix Information TLV is a new OPTIONAL TLV. It MUST only appear inside END-POINTS (IPv4/Node ID) object. The receiver SHOULD ignore the Destination Prefix Information TLV if it appears in zhang Expires August 2010 [Page 4] draft-zhang-pce-pcep-extensions-for-gmps-00.txt February 2010 any other object other than END-POINTS object. This TLV contains the prefix length for the destination IPv4 address and will appear when prefix length is in the range between 0 and 32 (inclusive). The format of the Destination Prefix Information 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 = 20 | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination | Flags |E| Reserved | | Prefix Length | Field |M| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Destination Prefix Length (8-bits) - Specifies the prefix length of the destination IPv4 address. Flags Field (7-bits) - Reserved for future to define new flags. It MUST be filled with zeros and SHOULD be ignored by the receiver. EM- Exact Prefix Match (1-bit) - Specifies whether exact prefix match is required for the destination IPv4 address. Bit EM Type 0 Exact prefix match is not required 1 Exact prefix match is required Reserved (16-bits) - Reserved. MUST be set to zero and SHOULD be ignored by the receiver. 4.3. New Object - QoS When a PCC requests a PCE for a route, and if PCE provides the response to the request, it MAY be useful for the PCC and the PCE to include the traffic parameters. These traffic parameters specify a base set of capabilities for GMPLS networks such as Service Level Agreement (SLA), protection scheme, segment recovery, concatenation, transparency, and so on. The QoS object handles the quality of service parameters for TE-LSPs in GMPLS networks. The QoS object can be included in the PCReq and PCRep messages by the PCC and PCE respectively. It represents the parameters that become necessary to manage bandwidth in the networks. When a PCE cannot find a path by satisfying a set of constraints requested by the PCC, the zhang Expires August 2010 [Page 5] draft-zhang-pce-pcep-extensions-for-gmps-00.txt February 2010 PCE may also include the original constraint so as to indicate the reason for an unsuccessful computation in the NO-PATH object. Based on the available service parameters proposed by a PCE, the PCC MAY decide to resend the path requests. These parameters ensure that the applications are guaranteed the network resources they need, despite varying traffic load. The format of the QoS object 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Object Class | OT |Res|P|I| Object Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Traffic Parameters TLV // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // LSP Protection Information TLV // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Object Class (8-bits) - Specifies the class of the object (Value = 25). OT - Object Type (4-bits) - Specifies the type of the object (Value = 1). 4.3.1. Traffic Parameters TLV For different networks, different traffic parameters should be embedded in the Traffic Parameters TLV, which is a new OPTIONAL TLV. The following types are defined currently: Object Type Name Remarks 34 SDH-Traffic SDH/Sonet networks 35 G.709-Traffic OTN digital wrapper 36 WSON-Traffic WSON 37 Ethernet-Traffic Ethernet 38 PTN TBD For SDH-Traffic, the contents of this object are identical in encoding to the contents of the Resource Reservation Protocol Traffic zhang Expires August 2010 [Page 6] draft-zhang-pce-pcep-extensions-for-gmps-00.txt February 2010 Engineering Extensions (RSVP-TE)SONET and SDH Parameters defined in RFC4606 (section 2.1). For G.709-Traffic, the contents of this object are identical with the Traffic Parameters defined in [OTN-SIG]. For WSON-Traffic and Ethernet-Traffic, we can refer to [WSON-SIG] and [Eth-Traffic]. 4.3.2. LSP Protection Information TLV The LSP Protection Information TLV is a new OPTIONAL TLV and MUST only appear inside QoS object. This TLV contains the LSP recovery attributes, LSP association and protection constraints that are required during signaling to support end-to-end LSP recovery. The information of end-to-end LSP recovery during GMPLS signaling is already defined in RFC4872 and RFC4873. Henceforth, the contents of LSP Protection Information TLV defined in this document is identical to the Protection Object defined in RFC4873 (section 6.1). LSP Protection Information TLV type is 40. 4.3.3. SWITCH-LAYER and QoS Object in PCReq and PCRep As mentioned earlier the SWITCH-LAYER and QoS object MAY be included in the PCReq message. These objects are OPTIONAL, and if QoS object is present only one instance of SDH-ASON QoS parameters TLV or LSP protection TLV must be included. If multiple instances of TLV or some other TLV is present, then the complete message has to be discarded without performing any further processing. The format of the PCReq message including the SWITCH-LAYER and QoS object is as follows: ::= [] where: ::= [] ::= [] ::= zhang Expires August 2010 [Page 7] draft-zhang-pce-pcep-extensions-for-gmps-00.txt February 2010 [] [] [] [] [[]] [] [] The format of the PCRep message is as follows: ::= where: ::= [] ::= [] [] [] ::= [] ::= where: ::= [] [] [] [] [] ::= [] 4.4. NO-PATH Object Extension The NO-PATH object is used in PCRep messages in response to an unsuccessful path computation request (the PCE could not find a path by satisfying the set of constraints). In this scenario, PCE MUST include a NO-PATH object in the PCRep message. zhang Expires August 2010 [Page 8] draft-zhang-pce-pcep-extensions-for-gmps-00.txt February 2010 The NO-PATH object carries the NO-PATH-VECTOR TLV that specifies more information on the reasons that led to a negative reply. In case of GMPLS networks there could be some more additional constraints that led to the failure like protection mismatch, lack of resources, and so on. Few new flags have been introduced in 32-bit flag field of the NO-PATH-VECTOR TLV and no modifications have been made in the NO-PATH object. 4.4.1. Extensions to NO-PATH-VECTOR TLV The modified NO-PATH-VECTOR TLV carrying the additional information 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 = 1 | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |N|P|U|U|N| | Field |R|M|S|D|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NP - PCE currently unavailable UD - Unknown destination US - Unknown source New fields PM and NR are defined in the 28th and 27th bit of the Flags field respectively. PM - Protection Mismatch (1-bit). Specifies the mismatch of the protection type in the request. NR - No Resource (1-bit). Specifies that the resources are not currently sufficient to provide the path. 4.5. Additional Error Type and Error Values Defined A PCEP-ERROR object is used to report a PCEP error and is characterized by an Error-Type that specifies the type of error and an Error-value that provides additional information about the error type. An additional error type and few error values are defined to represent some of the errors related to the newly identified objects related to GMPLS networks. zhang Expires August 2010 [Page 9] draft-zhang-pce-pcep-extensions-for-gmps-00.txt February 2010 For each PCEP error, an Error-Type and an Error-value are defined. Error-Type 1 to 10 is already defined in RFC5440. Additional Error- values are defined for Error-Type 10 and a new Error-Type 14 is introduced. Error-Type Error-value 10 Reception of an invalid object Error-value=2: LSP Protection Information TLV missing in QoS object. Error-value=3: TLV missing in QoS object. Error-value=4: Multiple instance of TLV present in QoS object. Error-value=5: Unsupported TLV present in QoS object. Error-value=6: Traffic Parameters TLV missing in QoS object. 14 Path computation failure Error-value=1: Unacceptable response message. Error-value=2: QoS object missing in request message. 5. Liveness Detection and Monitoring This document makes no change to the basic operation of PCEP and so there are no changes to the requirements for liveness detection and monitoring set out in RFC4657 and RFC5440. 6. IANA Considerations IANA assigns values to the PCEP protocol objects and TLVs. IANA is requested to make some allocations for the newly defined objects and TLVs introduced in this document. Also, IANA is requested to manage the space of flags that are newly added in the TLVs. 6.1. New PCEP Object IANA is requested to make some allocations for the QoS object: zhang Expires August 2010 [Page 10] draft-zhang-pce-pcep-extensions-for-gmps-00.txt February 2010 Object-Class Value Name Reference 25 QoS Object-Type-1 This document (section 4.5) 6.2. New PCEP TLVs IANA is requested to create a registry for the following TLVs: Value Meaning Reference 20 Destination Prefix Information This document (section 4.1.1) 34 SDH-Traffic This document (section 4.2.1) 35 G.709-Traffic This document (section 4.2.1) 36 WSON-Traffic This document (section 4.2.1) 37 Ethernet-Traffic This document (section 4.2.1) 40 LSP Protection Information This document (section 4.2.2) 6.3. PCEP NO-PATH-VECTOR TLV Flag Field IANA is requested to update the registry that manages the Flag field of the NO-PATH-VECTOR TLV. New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities: o Bit number (counting from bit 0 as the most significant bit) o Name Flag o Reference Code space of the Flag field (NO-PATH-VECTOR TLV). Bit Number Name Reference 27 No Resource (NR) This document (section 4.2.1) 28 Protection Mismatch (PM) This document (section 4.2.1) zhang Expires August 2010 [Page 11] draft-zhang-pce-pcep-extensions-for-gmps-00.txt February 2010 6.4. New PCEP Error Codes As descried in Section 4.5, new PCEP Error-Type and Error Values are defined. IANA is requested to manage the code space of the Error object. Error-Type Error-value 10 Reception of an invalid object Error-value=2: LSP Protection Information TLV missing in QoS object. Error-value=3: TLV missing in QoS object. Error-value=4: Multiple instance of TLV present in QoS object. Error-value=5: Unsupported TLV present in QoS object. Error-value=6: Traffic Parameters TLV missing in QoS object. 14 Path computation failure Error-value=1: Unacceptable response message. Error-value=2: QoS object missing in request message. 7. Security Considerations The protocol extensions defined in this document do not substantially change the nature of PCEP. Therefore, the security considerations set out in RFC5440 apply unchanged. 8. Acknowledgements The authors would like to thank Cyril Margaria, Pradeep Shastry, Thiyagarajan Manickam, and Hemalatha G for their suggestions during the development of this draft. 9. References 9.1. Normative References [GMPLS-REQ] Otani, Ogaki, Caviglia, and Fatai Zhang, "Requirements for GMPLS applications of PCE", July 2009. zhang Expires August 2010 [Page 12] draft-zhang-pce-pcep-extensions-for-gmps-00.txt February 2010 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [RFC3209] Bradner, S., "RSVP-TE: Extensions to RSVP for LSP Tunnels", March 1997. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", January 2003. [RFC3477] Kompella, K. and Y. Rekhter, "Signaling Unnumbered Links in Resource Reservation Protocol - Traffic Engineering (RSVP-TE)", January 2003. [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", May 2005. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", May 2008. [RFC4872] J.P.Lang,Y.Rekhter, D. Papadimitriou "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", May 2007. [RFC4873] J.P.Lang, I. Bryskin, D. Papadimitriou, A. Farrel "GMPLS Segment Recovery", May 2007. [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", February 2003. [OTN-SIG] Fatai Zhang, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control", draft-zhang- ccamp-gmpls-evolving-g709, in progress. [WSON-SIG] G. Bernstein, Young Lee, Ed., "Signaling Extensions for Wavelength Switched Optical Networks", draft-bernstein- ccamp-wson-signaling, in progress. [Eth-Traffic] D. Papadimitriou " Ethernet Traffic Parameters ", draft-ietf-ccamp-ethernet-traffic-parameters", in progress. zhang Expires August 2010 [Page 13] draft-zhang-pce-pcep-extensions-for-gmps-00.txt February 2010 9.2. Informative References [RFC4655] Vasseur, J. and J. Ash, "A Path Computation Element (PCE)-Based Architecture", August 2006. [RFC4657] Ash, J. and J. Roux, "Path Computation Element (PCE) Communication Protocol Generic Requirements", September 2006. [RFC4674] Roux, J., "Requirements for Path Computation Element (PCE) Discovery", October 2006. [RFC5088] Roux, J., "OSPF Protocol Extensions for PCE Discovery", January 2008. [RFC5440] Ash, J. and J. Roux, "Path Computation Element (PCE) communication Protocol (PCEP)", March 2009. [INTER-LAYER] E.Oki, Tomorini Takeda, J.Roux, A.Farrel,"Extensions to the Path Computation Element communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering" [RFC3471] L.Berger," Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", Jan 2003 10. Authors' Addresses Fatai Zhang Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R.China Email: zhangfatai@huawei.com Suresh BR Huawei Technologies Shenzhen China Email: sureshbr@huawei.com Young Lee Huawei Technologies 1700 Alma Drive, Suite 100 zhang Expires August 2010 [Page 14] draft-zhang-pce-pcep-extensions-for-gmps-00.txt February 2010 Plano, TX 75075 USA Phone: (972) 509-5599 (x2240) Email: ylee@huawei.com SenthilKumar S Huawei Technologies Shenzhen China Email: senthilkumars@huawei.com Jun Sun Huawei Technologies Shenzhen China Email: johnsun@huawei.com Intellectual Property The IETF Trust 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 any IETF 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. Copies of Intellectual Property 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 any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are zhang Expires August 2010 [Page 15] draft-zhang-pce-pcep-extensions-for-gmps-00.txt February 2010 published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. Disclaimer of Validity All IETF Documents and the information contained therein 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 THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. zhang Expires August 2010 [Page 16]