Network Working Group Ina Minei Internet Draft Der-Hwa Gan Expiration Date: December 2006 Kireeti Kompella Category: Informational Juniper Networks Xiaoming Li China Unicom June 2006 Extensions for Differentiated Services-aware Traffic Engineered LSPs draft-minei-diffserv-te-multi-class-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. Abstract This document specifies the extensions necessary to set up multi- class diffserv-aware traffic engineered label switched paths (LSPs). A multi-class diffserv-te LSP carries traffic from multiple traffic classes and is set up along a path that satisfies the bandwidth constraints defined for each of the classes it carries. Minei, et al. [Page 1] Internet Draft draft-minei-diffserv-te-multi-class-02.txt June 2006 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 [RFC2119]. Table of Contents 1 Definitions ........................................... 3 2 Introduction .......................................... 3 3 Setup and holding preemption priorities ............... 4 4 Setting up multi-class RSVP-signaled LSPs ............. 5 4.1 The extended classtype object ......................... 5 4.2 RSVP signaling ........................................ 6 4.3 RSVP error processing ................................. 7 5 The extended-MAM bandwidth constraints model .......... 8 6 IGP extensions ........................................ 8 7 Migration issues ...................................... 8 8 Security considerations ............................... 9 9 Intellectual Property Statement ....................... 9 10 Acknowledgments ....................................... 9 11 References ............................................ 9 11.1 Normative References .................................. 10 12 Authors' Addresses .................................... 10 Full Copyright Statement .............................. 11 Minei, et al. [Page 2] Internet Draft draft-minei-diffserv-te-multi-class-02.txt June 2006 1. Definitions 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. 2. Introduction [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 the rest of this document such an LSP is called single-class diff- serv-TE LSP. Note that from a diffserv point of view, a single-class LSP can be either an L-LSP or an E-LSP (as defined in [RFC3270]). In some scenarios it is required to allow traffic with different diffserv behaviors to be mapped to the same LSP and to traffic engi- neer the LSP according to the bandwidth constraints for each one of these classes. In this case, multiple Class-Types are configured per LSP. In the rest of the document such an LSP is called a multi-class diffserv-TE LSP. From a diffserv point of view, a multi-class LSP is always an E-LSP. An example scenario for multi-class LSPs comes in the context of ATM trunk emulation using MPLS LSPs. In this case, it is preferable to have all the traffic classes following the same path and exhibit the same behavior in case of failure. Another application of multi-class diffserv-TE LSPs is for reducing Minei, et al. [Page 3] Internet Draft draft-minei-diffserv-te-multi-class-02.txt June 2006 the number of LSPs in a network by setting up reservations for sev- eral classes in one LSP rather than one reservation per class. With single class LSPs, the total number of LSPs in the network is equal to the number of classes times the number of LSPs in the mesh. With multi-class LSPs, the total number of LSPs is equal to the size of the LSP mesh. The reduction in the number of LSPs is important from a scaling and manageability point of view. Here are a few observations regarding single-class and multi-class LSPs: o An LSP that is signaled using the extensions defined in this doc- ument is not required to request bandwidth from multiple Class- Types. As a special case, when the request is from a single Class-Type, the LSP behaves as a single-class LSP and from a diffserv point of view can be either an L-LSP or an E-LSP. There- fore, conceptually, multi-class LSPs are a superset of single- class LSPs. o In order to achieve bandwidth reservation from several traffic classes, two approaches can be taken: 1) create one multi-class LSP or 2) create several single-class LSPs. Note however that the two approaches have different properties in terms of: the number of LSPs established, the path that is taken by traffic belonging to different classes and the fate sharing between the different classes. The choice of single-class or multi-class LSP is made based on the requirements of the application and on the network design. o Both single-class and multi-class LSPs must integrate smoothly with non-diffserv-te LSPs. 3. Setup and holding preemption priorities As per existing TE, multi-class LSPs can be configured with a setup and holding priority, each with a value between 0 and 7. The combi- nation of the setup priority and each of the Class-Types for which the multi-class LSP is set up and of the hold priority and each of the Class-Types for which the multi-class LSP is set up, MUST be such that together they form one of the (up to) 8 TE-Classes configured in the TE-Class Mapping. This requirement is similar to the requirement spelled out in [RFC4124] regarding the combination of priority and class-type for single-class LSPs. Minei, et al. [Page 4] Internet Draft draft-minei-diffserv-te-multi-class-02.txt June 2006 4. Setting up multi-class RSVP-signaled LSPs 4.1. The extended classtype object To request LSP setup along a path with bandwidth constraints from more than one Class-Type, a new object is defined, the extended- classtype-object. This object has a class_num that ensures that a node that doesn't recognize it will reject it and return an "Unknown Object Num" error. According to the guidelines in [RFC3936], the val- ues used are class_num 124 and "class class_type" 1. The contents are a set of subobjects, each encoded as a TLV. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subobjects | . ... . . ... . . ... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A TLV has the following format: 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 | Length | MBZ | CTi | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BW requested for CTi (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: 16 bits The length contains the total length of the subobject in bytes, including the type, length, mbz, CTi fields. The length MUST be at least 8, and MUST be a multiple of 4. Type : 8 bits The type of the contents of the subobject. Currently defined value is 1 - bandwidth MBZ: 3 bits This field is reserved. It must be set to zero on transmission and must be ignored on receipt. CT : 3 bits Minei, et al. [Page 5] Internet Draft draft-minei-diffserv-te-multi-class-02.txt June 2006 Indicates the Class-Type. Values currently allowed are 0, 1, 2, ... , 7. Note that this is different from the definition given in [RFC4124] where the value 0 is not allowed. BW requested : 32 bits Indicates the number of bytes (not bits) per second that need to be reserved for the CT indicated. 4.2. RSVP signaling The extended-classtype object is signaled in the PATH message, and saved in the PSB at every hop. The extended-classtype object MUST NOT be included in a RESV message. The format of the Path message is as follows: ::= [ ] [ ] [ ] [ ] [ ] [ ... ] [ ] ::= [ ] [ ] [ ] When the classtype object is present, the values in the tspec are ignored for admission control purposes and SHOULD be 0. Admission control is performed for the requirements specified in each of the (CT, BW) pairs in the extended-classtype object. Admission control succeeds only if the requirements for all the (CT, BW) pairs are satisfied. Merging MUST NOT be performed among reservations that belong to LSPs for which the extended-classtype object was signaled. If the extended-classtype object is not present in the PATH message, the LSR associates the LSP with CT0 and performs admission control from the bandwidth/priority values for CT0. In the case where the LSP is from a single class, and the class is CT0, the extended-classtype Minei, et al. [Page 6] Internet Draft draft-minei-diffserv-te-multi-class-02.txt June 2006 object MAY be included in the PATH message. 4.3. RSVP error processing If the extended-classtype object is not understood, an "Unknown Object Num' error is returned. An LSR that recognizes the extended-classtype object and that receives a path message which contains the extended-classtype object but which does not contain a LABEL_REQUEST object or which does not have a session type of LSP_Tunnel_IPv4, MUST send a PathErr towards the sender with the error code 'extended-classtype Error' and an error value of 'Unexpected extended-classtype object'. These are defined below. An LSR receiving a Path message with the extended-classtype object, which recognizes the object but does not support the particular Class-Type, MUST send a PathErr towards the sender with the error code 'extended-classtype Error' and an error value of 'Unsupported Class-Type'. An LSR receiving a Path message with the extended-classtype object, which: - recognizes the object, - supports the particular Class-Type, but - determines that the tuple formed by (i)this Class-Type and (ii) the holding priority signaled in the same Path message, is not one of the eight TE-classes configured in the TE-class mapping, MUST send a PathErr towards the sender with an error value of 'CT and holding priority do not form a configured TE-Class'. For setup prior- ity, return 'CT and setup priority do not form a configured TE-class' The error checking ensures that multi-class LSPs get established only through LSRs that support multi-class diffserv-te LSPs and have con- sistent TE-mappings with the ingress. Errors related to the processing of the extended-classtype-object are reported using the vendor-specific Error-Code "extended-classtype- error" 252. The first four octets following the Error Value are 2636 - the vendor's SMI enterprise code in network octet order (as required by [RFC3936]) The error values are the same as defined in [RFC4124] for the classtype object. The values 3, 6, 7 are not used with multi-class- LSPs. Minei, et al. [Page 7] Internet Draft draft-minei-diffserv-te-multi-class-02.txt June 2006 5. The extended-MAM bandwidth constraints model A new BC model-id is defined, the extended-mam bandwidth model, with value 254. The extended-mam model has the same behavior as the MAM model [RFC4125]. 6. IGP extensions [RFC4124] defines the bandwidth-constraint (BC) sub-tlv. The BC sub- tlv includes the bandwidth model and a list of bandwidth-constraints. In [RFC4124], the semantic of the "Unreserved Bandwidth" sub-TLV is changed such that the eight bandwidth values advertised correspond to the unreserved bandwidth for each of the TE-Class (instead of for each preemption priority as per existing TE). This approach has two drawbacks: o It creates a flag day in the network with regards to the existing TE LSPs set up without any diffserv properties, as explained in [RFC4124]. o It requires that LSPs from CT0 be set up at priorities such that the combination of (CT0, priority) is one of the configured TE- classes. Thus, the priorities asssigned to pre-existing CT0 LSPs use up some of the TE-classes. In the method documented here, when the bandwidth-model is extended- mam, the semantic of the "Unreserved Bandwidth" sub-TLV is the same as in existing TE and the bandwidth available per TE-class is adver- tised in the BC sub-tlv. This approach achieves the following: o There is no interference between the diffserv-aware LSPs and the plain TE LSPs o There are no migration issues when deploying this feature in a network where TE LSPs are deployed. o A total of 16 TE-classes are effectively created. 7. Migration issues Since the semantics of the "Unreserved Bandwidth" sub-TLV are main- tained unchanged, there are no migration issues when deploying multi- class LSPs in a network where traffic engineering is already in use. Single-class and multi-class LSPs cannot co-exist in the same net- work. When both the multi-class and the single-class functionality is required, the semantics of single-class LSPs can be provided by the multi-class LSPs. Minei, et al. [Page 8] Internet Draft draft-minei-diffserv-te-multi-class-02.txt June 2006 8. Security considerations The same security considerations apply as for single-class diffserv- TE LSPs [RFC4124]. 9. 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 assur- ances 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. 10. Acknowledgments This work is the outcome of discussions with Arthi Ayyangar and Chai- tanya Kodeboyina. The authors would like to thank them for their suggestions and insight. The authors would like to thank Yakov Rekhter and Peter Busschbach for their review. 11. References Minei, et al. [Page 9] Internet Draft draft-minei-diffserv-te-multi-class-02.txt June 2006 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119. [RFC3270] Le Faucheur et al, "MPLS Support of Diff-Serv", RFC3270. [RFC3564] Le Faucheur et al, "Requirements for support of Diff-Serv- aware MPLS Traffic Engineering", RFC3564. [RFC3936] Kompella, K., Lang, J., "Procedures for Modifying the Resource reSerVation Protocol (RSVP)", RFC3936. [RFC4125] Le Faucheur, Lai, "Maximum Allocation Bandwidth Constraints Model for DS-TE", RFC4125. [RFC4124] Le Faucheur et al, "Protocol extensions for support of Diff-Serv-aware MPLS Traffic Engineering", RFC4124. 12. Authors' Addresses Ina Minei Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089 e-mail: ina@juniper.net Der-Hwa Gan Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089 e-mail: dhg@juniper.net Kireeti Kompella Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089 e-mail: kireeti@juniper.net Xiaoming Li China United Telecommunications Corporation No.133A, Xidan North Street, Xicheng District, Beijing 100032, China email: lixm@chinaunicom.com.cn Minei, et al. [Page 10] Internet Draft draft-minei-diffserv-te-multi-class-02.txt June 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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. Additional copyright notices are not permitted in IETF Documents except in the case where such document is the product of a joint development effort between the IETF and another standards development organization or the document is a republication of the work of another standards organization. Such exceptions must be approved on an individual basis by the IAB. 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 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Minei, et al. [Page 11]