Network Working Group S. Sivabalan, Ed. Internet Draft J. Parker Intended status: Standards Track S. Boutros Expires:
November 23, 2008May 2, 2009 Cisco Systems, Inc. K. Kumaki KDDI Corporation May 23,November 3, 2008 Diff-Serv Aware Class Type Object for Path Computation Element Communication Protocol draft-ietf-pce-dste-01.txtdraft-ietf-pce-dste-02.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 This Internet-Draft will expire on November 23, 2008.May 2, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document specifies a CLASSTYPE object to support Diff-Serve Aware Traffic Engineering (DS-TE) where path computation is performed with an aid of Path Computation Element (PCE). 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 Error! Reference source not found.. Table of Contents 1. Introduction...................................................2 2. Terminology....................................................3 3. CLASSTYPE Object...............................................4 3.1. Object Definition.........................................4 3.2. Path Computation Request message with CLASSTYPE Object....4 3.3. Processing CLASSTYPE Object...............................5 3.4. Determination of Traffic Engineering Class (TE-Class).....6 3.5. Significance of Class-Type and TE-Class...................6 3.6. Error Codes for CLASSTYPE Object..........................6 4. Security Considerations........................................6Considerations........................................7 5. IANA Considerations............................................7 6. Acknowledgments................................................7 6.1. Normative References......................................7References......................................8 6.2. Informative References....................................8 Author's Addresses................................................8 Intellectual Property Statement...................................9 Disclaimer of Validity............................................9 1. Introduction The Internet Draft [PCEP-ID] specifies the Path Computation Element communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs, in compliance with [RFC4657]. Differentiated Service aware MPLS Traffic Engineering (DS-TE) addresses the fundamental requirement to be able to enforce different bandwidth constraints for different classes of traffic. It describes mechanisms to achieve per-class traffic engineering, rather than on an aggregate basis across all classes by enforcing Bandwidth Constraints (BCs) on different classes. Requirements for DS-TE and the associated protocol extensions are specified in [RFC3564] and [RFC4124] respectively. As per [RFC4657], PCEP must support traffic class-type as an MPLS TE specific constraint. However, in the present form, PCEP [PCEP-ID] does not have the capability to specify the class-type in the path computation request. In this document, we define a new PCEP object called CLASSTYPE which carries the class-type of the TE LSP in the path computation request. During path computation, a PCE uses the class-type to identify the bandwidth constraint of the TE-LSP. 2. Terminology CT: Class type: A set of Traffic Trunks governed by a set of bandwidth constraints. Used for the purpose of link bandwidth allocation, constraint based routing and admission control. A given Traffic Trunk belongs to the same CT on all links. DS-TE: Diff-Serv Aware Traffic Engineering. LSR: Label Switching Router. LSP: Label Switched Path. 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. PCEP Peer: an element involved in a PCEP session (i.e. a PCC or the PCE). TE-Class: A pair consisting of a class-type and a preemption priority allowed for that class type. An LSP transporting a Traffic Trunk from that class type can use that preemption priority as the setup priority, the holding priority, or both. TE LSP: Traffic Engineering Label Switched Path. Traffic Trunk: An aggregation of traffic flows of the same class (i.e. treated equivalently from the DS-TE perspective) which is placed inside a TE LSP. 3. CLASSTYPE Object The CLASSTYPE object is optional and is used to specify the class- type of a TE LSP. This object is meaningful only within the path computation request, and is ignored in the path reply message. If the TE LSP for which the path is to be computed belongs to Class 0, the path computation request MUST NOT contain the CLASSTYPE object. This allows backward compatibility with PCE that does not support the CLASSTYPE object. 3.1. Object Definition The CLASSTYPE object contains a 32-bit word PCEP common object header defined in [PCEP-ID] followed by another 32-bit word object body as shown in Figure 1. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCEP common header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | CT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 CLASSTYPE object format. The fields in the object common header are processed as specified in [PCEP-ID]. The values of object class and object type are 22 and 1 respectively. If included, CLASSTYPE object must be taken into account by PCE. As such, the P flag MUST be set. I flag is ignored. The CLASSTYPE object body contains the following fields: CT: 3-bit field that indicates the class-type. Values allowed are 1, 2, ... , 7. Value of 0 is Reserved. Reserved: 29-bit reserved field. It MUST be set to zero on transmission and MUST be ignored on receipt. 3.2. Path Computation Request message with CLASSTYPE Object [PCEP-ID] specifies the object orders in which objects must be inserted in the PCEP messages. This document specifies that the CLASSTYPE object be inserted after the END-POINT objects as shown below: The format of a PCReq message is as follows: <PCReq Message>::= <Common Header> [<SVEC-list>] <request-list> where: <svec-list>::=<SVEC>[<svec-list>] <request-list>::=<request>[<request-list>] <request>::= <RP> <END-POINTS> [<CLASSTYPE>] [<LSPA>] [<BANDWIDTH>] [<metric-list>] [<RRO>] [<IRO>] [<LOAD-BALANCING>] where: <metric-list>::=<METRIC>[<metric-list>] Note that an implementation MUST form the PCEP messages using the object ordering rules specified using Backus-Naur Form. Please refer [OBJ-ORD] for more details. 3.3. Processing CLASSTYPE Object If the LSP is associated with Class-Type N (1 <= N <= 7), the PCC originating the path computation request MUST include the CLASSTYPE object in the Path computation request message with the Class-Type (CT) field set to N. If a path computation request contains multiple CLASSTYPE objects, only the first one is meaningful; subsequent CLASSTYPE object(s) MUST be ignored and MUST NOT be forwarded. If the CLASSTYPE object is not present in the path computation request message, the LSR MUST associate the Class-Type 0 to the LSP. Path computation reply message MUST NOT include a CLASSTYPE object. If a PCE needs to forward a path computation request containing the CLASSTYPE object to another PCE, it MUST store the class-type of the TE LSP in order to complete the path computation when the path computation reply arrives. A PCE that does not recognize the CLASSTYPE object MUST reject the entire PCEP message and MUST send a PCE error message with Error- Type="Unknown Object" or "Not supported Object" defined in [PCEP-ID]. A PCE that recognizes the CLASSTYPE object finds that P flag is not set in the CLASSTYPE object, it MUST send PCE error message towards the sender with the with the error type and error value specified in [PCEP-ID]. A PCE that recognizes the CLASSTYPE object, but does not support the particular Class-Type, MUST send a PCE error message towards the sender with the error type "Diff-Serv aware TE Error" and the error value of "Unsupported Class-Type" (new error code provided below). A PCE that recognizes the CLASSTYPE object, but determines that the Class-Type value is not valid (i.e., Class Type value 0), MUST send a PCE error towards the sender with the error type "Diff-Serve aware TE Error" and an error value of "Invalid Class-Type value" (new error code provided below). 3.4. Determination of Traffic Engineering Class (TE-Class) As specified in RFC4124, a CT and a Preemption priority map to a Traffic Engineering Class (TE-Class), and there can be up to 8 TE- classes. The TE-class value is used to determine the unreserved bandwidth on the links during path computation. In the case of a PCE, the CT value carried in the CLASSTYPE object and the setup priority in the LSP Attribute (LSPA) object are used to determine the TE-class corresponding to the path computation request. If LSPA object is absent, the setup priority is assumed to be 0. 3.5. Significance of Class-Type and TE-Class To ensure coherent DS-TE operation, a PCE and a PCC should have a common understanding of a particular DS-TE classtype and TE-Class. If a path computation request crosses an AS boundary, these should have global significance in all domains. Enforcement of this global significance is outside the scope of this document. 3.6. Error Codes for CLASSTYPE Object This document defines the following error type and values: Error-Type Meaning 12 Diff-Serve aware TE Error Error-value=1: unsupported class-type. Error-value=2: invalid class-type. Error-value=3: class-type and setup priority does not form a configured TE class. 4. Security Considerations This document does not introduce new security issues. The security considerations pertaining to PCEP [PCEP-ID] remain relevant. 5. IANA Considerations IANA maintains a registry of parameters for PCEP. This contains a sub-registry for PCEP objects. IANA is requested to make new allocation from this registry as follows: Object-Class Name Reference 22 CLASSTYPE draft-ietf-pce-dste-01.txtdraft-ietf-pce-dste-02.txt Object-Type 1: Class Type draft-ietf-pce-dste-01.txtdraft-ietf-pce-dste-02.txt IANA is requested to make new allocation for error types and values as follows: Error-Type Meaning Reference 12 Diff-Serv aware TE error draft-ietf-pce-dste-01.txtdraft-ietf-pce-dste-02.txt Error-value = 1: draft-ietf-pce-dste-01.txtdraft-ietf-pce-dste-02.txt Unsupported class-type Error-value = 2: draft-ietf-pce-dste-01.txtdraft-ietf-pce-dste-02.txt Invalid class-type Error-value = 3: draft-ietf-pce-dste-01.txtdraft-ietf-pce-dste-02.txt Class type and setup priority does not form a configured TE class 6. Acknowledgments The authors would like to thank Jean Philippe Vasseur, Adrian Farrel and Zafar Ali for their valuable comments. References 6.1. Normative References [RFC4124] Le Faucheur, F. and W. Lai, "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005. [PCEP-ID] Path Computation Element (PCE) communication Protocol (PCEP)", draft-ietf-pce-pcep-12.txtdraft-ietf-pce-pcep-18.txt (work in progress), SeptemberNovember 2008. 6.2. Informative References [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006. [RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003. [OBJ-ORD] Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications", draft-farrel-rtg- common-bnf-07.txt, November 2008. Author's Addresses Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Canada Email: firstname.lastname@example.org Jon Parker Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Canada Email: email@example.com Sami Boutros Cisco Systems, Inc. 3750 Cisco Way San Jose, California 95134 USA Email: firstname.lastname@example.org Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku Tokyo, 102-8460 Japan Email: email@example.com 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 firstname.lastname@example.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 Copyright (C) The IETF Trust (2008). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.