Internet Engineering Task Force Quintin Zhao Internet-Draft Suresh Babu Intended status: Standards Track Huawei Technology Expires: December 3, 2009 Daniel King Old Dog Consulting July 3, 2009 Multi-Class DSTE Support for the Path Computation Element Communication Protocol draft-zhao-pce-pcep-multiclass-type-dste-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 December 3, 2009. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Zhao, et al. Expires December 3, 2009 [Page 1] Internet-Draft Multi-Class DSTE Extension for PCEP June 2009 Abstract Diffserv-Aware Traffic Engineering (DS-TE) can be used by Service Providers to perform fine grain bandwidth management of a subset, or sub-pool, of traffic flows. Typically in DS-TE a diffserv class will use a single Label Switch Path (LSP) that satisfies the bandwidth required. Where traffic with different diffserv characteristics must be mapped to a single LSP. Multi-Class DS-TE can be used to select an LSP that satisfy the bandwidth requirement of all classes required. This document specifies the PCEP extentions to support Multi-Class Type DS-TE where path computation is performed with the aid of a Path Computation Element (PCE). Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Solution Chioces to Support the Multi-Class Type Object . . . 4 3.1. Solution Choice 1: Using the Existing Class Type Object to Support the Multi-Class Type Object . . . . . . 4 3.1.1. Request Message Format Extension . . . . . . . . . . . 4 3.1.2. Processing of CLASSTYPE Object and BANDWITH Object . . 5 3.2. Solution Chioces 2: Adding a new Multi Class DSTE Object to Support the Multi-Class Type . . . . . . . . . . 6 3.2.1. Request Message Format Extension . . . . . . . . . . . 6 3.2.2. New MULTICLASSDSTE Object Definition . . . . . . . . . 7 3.2.3. Processing of MULTICLASSDSTE Object . . . . . . . . . 8 4. Error Codes for CLASSTYPE Object . . . . . . . . . . . . . . . 9 5. Impact on Network Operation . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Zhao, et al. Expires December 3, 2009 [Page 2] Internet-Draft Multi Class DSTE Support for PCEP June 2009 1. Terminology Terminology used in this document For readability a number of definitions from [RFC3564] are repeated here: Traffic Trunk: an aggregation of traffic flows of the same class [i.e. which are to be treated equivalently from the DS-TE perspec- tive] which are placed inside a Label Switched Path. Class-Type (CT): the set of Traffic Trunks crossing a link that is governed by a specific set of Bandwidth constraints. CT is used for the purposes of link bandwidth allocation, constraint based routing and admission control. A given Traffic Trunk belongs to the same CT on all links. TE-Class: A pair of: 1. a Class-Type 2. a preemption priority allowed for that Class-Type. This means that an LSP transporting a Traffic Trunk from that Class-Type can use that preemption priority as the set-up priority, as the holding priority or both. Multiclass LSP: an LSP that can carry several class types. This document also uses the terminology defined in [RFC4655], [RFC4875], and [PCEP]. 2. Introduction [RFC5440] 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]. [RFC4124] defines the protocol extensions for setting up diffserv- aware traffic engineered LSPs. An LSP set up according to [RFC4124] carries traffic from a single diffserv class and is set up along a path that satisfies the bandwidth constraints specified for this class. In this case, a single Class-Type is configured per LSP. In some scenarios it is required to allow traffic with different diffserv behaviors to be mapped to the same LSP and to traffic engineer the LSP according to the bandwidth constraints for each one Zhao, et al. Expires December 3, 2009 [Page 3] Internet-Draft Multi Class DSTE Support for PCEP June 2009 of these classes. In this case, multiple Class-Types are configured per LSP. For further analysis and explanation of multi-class diffserv-TE LSPs see [MULTICLASS]. As defined in [RFC4657], PCEP must support traffic Class-Type as an MPLSTE-specific constraint. As per [RFC5455], it has defined a 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. But the Class-Type object only applies a single class type to the computation request. In this document, we will define extend the class-type object and the procedures to handle the requirement for the LSP path calculation which supports multiple class types [MULTICLASS]. 3. Solution Chioces to Support the Multi-Class Type Object There are two possible solutions proposed in this version of the draft. One solution is that we use the class object defined in [RFC5044] already and extend the request message to include multiple of the class type object in the request message and correspondingly includes multiple of bandwidth objects at the same time. The second choice is to add a new class type object for the multi class type. In this case the single class type will be signaled using the original class type object defined in [RFC5044] and it can also signal the class type using the new class type object defined here to signal multi class type or a single class type. [Editor Note] As this document evolves and working group feedback is gained, the authors identify and adopt a single solution. 3.1. Solution Choice 1: Using the Existing Class Type Object to Support the Multi-Class Type Object Path Computation Request Message with CLASSTYPE Object [RFC5440] specifies the order in which objects must be inserted in the PCEP messages. [RFC5044] specifies that the CLASSTYPE object be inserted after the END-POINT objects to signal a single class type. 3.1.1. Request Message Format Extension In this solution choice, we propose to expand the request message to support the multi class types to the following: Zhao, et al. Expires December 3, 2009 [Page 4] Internet-Draft Multi Class DSTE Support for PCEP June 2009 ::= [] where: ::=[] ::=[] ::= [] [] [] [] [] [] [] where: ::=[] ::=[] >::=[] Note that an implementation MUST form the PCEP messages using the object ordering rules specified using Backus-Naur Form. Please refer to [OBJ-ORD] for more details. Figure 1: Extended Request Message Format 3.1.2. Processing of CLASSTYPE Object and BANDWITH Object If the LSP is associated with m of Class-Type N (0 <= N <= 7), the PCC originating the PCReq MUST include m of CLASSTYPE objects in the PCReq message with the Class-Type (CT) field set to its corresponding class type. If a path computation request contains multiple CLASSTYPE objects. At the same time,m of BANDWIDTH objects are needed incldued in the request message. If the CLASSTYPE object is not present in the path computation request message, the LSR MUST associate the Class-Type 0 to the LSP. A path computation reply message MUST NOT include a CLASSTYPE object. If a PCE needs to forward a path computation request containing a number of CLASSTYPE objects 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- Zhao, et al. Expires December 3, 2009 [Page 5] Internet-Draft Multi Class DSTE Support for PCEP June 2009 Type="Unknown Object" or "Not supported object", defined in [RFC5440]. A PCE that recognizes the CLASSTYPE object, but finds that the P flag is not set in the CLASSTYPE object, MUST send PCE error message towards the sender with the error type and error value specified in [RFC5440]. 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 "Diffserv-aware TE error" and the error value of "Unsupported Class-Type" (Error-value 1). A PCE that recognizes the CLASSTYPE object, but determines that the Class-Type value is not valid, MUST send a PCE error towards the sender with the error type "Diffserv-aware TE error" and an error value of "Invalid Class-Type" (Error-value 2). 3.2. Solution Chioces 2: Adding a new Multi Class DSTE Object to Support the Multi-Class Type 3.2.1. Request Message Format Extension In this solution chioce, we propose to expand the request message to support the multi class types to the following: Zhao, et al. Expires December 3, 2009 [Page 6] Internet-Draft Multi Class DSTE Support for PCEP June 2009 ::= [] where: ::=[] ::=[] ::= [] [] [] [] [] [] [] [] where: ::=[] The defination of the MULTICLASSDSTE is explained in the next section in detail. Note that an implementation MUST form the PCEP messages using the object ordering rules specified using Backus-Naur Form. Please refer to [OBJ-ORD] for more details. Figure 2: Extended Request Message Format 3.2.2. New MULTICLASSDSTE Object Definition The MULTICLASSDSTE object contains a 32-bit word PCEP common object header defined in [RFC5440] followed by another one pair or more but not more than 8 pair of 32-bit word object body for the class type and the bandwidth body for each class type: Zhao, et al. Expires December 3, 2009 [Page 7] Internet-Draft Multi Class DSTE Support for PCEP June 2009 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 | bitmap of CT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BW requested for CT1 (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Muti CLass DSTE Object The fields in the common object header are processed as specified in [RFC5440]. The values of object class and object type are to be defined, respectively. If included, the MULTICLASSDSTE object must be taken into account by the PCE. As such, the P flag MUST be set. The I flag is ignored. The MULTICLASSDSTE object body contains the following fields: o Bit map of CT: 8-bit field that indicates each Class-Type. Each "bit" represents the presence of request for the CT. For example, if the bitmap is 00011010, that indicates CT1, CT3, CT4. o Reserved: 24-bit reserved field. It MUST be set to zero on transmission and MUST be ignored on receipt. o BW: The bandwidth request is for 32-bit IEEE floating point number. The number of the requested BW and the order of the BW requested are corresponding to the bitmap. For example, if the bitmap is 00011010, then there will be three BWs and they are in the order of BW1 for CT1, BW3 for CT3 and BW4 for CT4. 3.2.3. Processing of MULTICLASSDSTE Object If the LSP is associated with m of Class-Type N (0 <= N <= 7), the PCC originating the PCReq MUST include a MULTICLASSDSTE object in the PCReq message with m Class-Type (CT) field set to its corresponding class type and with the corresponding bandwidth requested for each CT. Zhao, et al. Expires December 3, 2009 [Page 8] Internet-Draft Multi Class DSTE Support for PCEP June 2009 If the CLASSTYPE object and MULTICLASSDSTE are present in the path computation request message, A PCE MUST send PCE error message towards the sender with the error type and error value specified in the later section of the document. If the CLASSTYPE object and MULTICLASSDSTE are not present in the path computation request message, the LSR MUST associate the Class- Type 0 to the LSP. A path computation reply message MUST NOT include a CLASSTYPE object. If a PCE needs to forward a path computation request containing a number of CLASSTYPE objects 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 MULTICLASSDSTE 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 [RFC5440]. A PCE that recognizes the MULTICLASSDSTE object, but finds that the P flag is not set in the CLASSTYPE object, MUST send PCE error message towards the sender with the error type and error value specified in [RFC5440]. A PCE that recognizes the MULTICLASS object, but does not support the particular Class-Type, MUST send a PCE error message towards the sender with the error type "Diffserv-aware TE error" and the error value of "Unsupported Class-Type" (Error-value 1). A PCE that recognizes the MULTICLASS object, but determines that the Class-Type value is not valid, MUST send a PCE error towards the sender with the error type "Diffserv-aware TE error" and an error value of "Invalid Class-Type" (Error-value 2). 4. Error Codes for CLASSTYPE Object TBD 5. Impact on Network Operation It is expected that use of PCEP extensions specified in this document does not have significant impact on network operations. Zhao, et al. Expires December 3, 2009 [Page 9] Internet-Draft Multi Class DSTE Support for PCEP June 2009 6. Security Considerations It is expected that use of PCEP extensions specified in this document does not have significant impact on Securitiy. 7. IANA Considerations A number of IANA considerations have been highlighted in the relevent sections of this document. Further clarifications of these requests will be made in a future version of this document. 8. Acknowledgement The authors would like to thank P Shastry for his inputs in this draft. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003. [RFC4124] Le Faucheur, F., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005. [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007. [RFC5044] Culley, P., Elzur, U., Recio, R., Bailey, S., and J. Carrier, "Marker PDU Aligned Framing for TCP Specification", RFC 5044, October 2007. [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC5455] Sivabalan, S., Parker, J., Boutros, S., and K. Kumaki, Zhao, et al. Expires December 3, 2009 [Page 10] Internet-Draft Multi Class DSTE Support for PCEP June 2009 "Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol", RFC 5455, March 2009. 9.2. Informative References [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006. [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009. [MULTICLASS] Minei, I., et al., "Extensions for Differentiated Services-aware Traffic Engineered LSPs", draft-minei- diffserv-te-multi-class, work in progress. Authors' Addresses Quintin Zhao Huawei Technology 125 Nagog Technology Park Acton, MA 01719 US Email: qzhao@huawei.com Suresh Babu Huawei Technology 125 Nagog Technology Park Acton, MA 01719 US Email: sureshbr@huawei.com Daniel King Old Dog Consulting Email: daniel@olddog.co.uk Zhao, et al. Expires December 3, 2009 [Page 11] Internet-Draft Multi Class DSTE Support for PCEP June 2009