idnits 2.17.1 draft-minei-diffserv-te-multi-class-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 357. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 370. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2006) is 6518 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Ina Minei 3 Internet Draft Der-Hwa Gan 4 Expiration Date: December 2006 Kireeti Kompella 5 Category: Informational Juniper Networks 7 Xiaoming Li 8 China Unicom 10 June 2006 12 Extensions for Differentiated Services-aware Traffic Engineered LSPs 14 draft-minei-diffserv-te-multi-class-02.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 This document specifies the extensions necessary to set up multi- 41 class diffserv-aware traffic engineered label switched paths (LSPs). 42 A multi-class diffserv-te LSP carries traffic from multiple traffic 43 classes and is set up along a path that satisfies the bandwidth 44 constraints defined for each of the classes it carries. 46 Conventions used in this document 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in RFC 2119 [RFC2119]. 52 Table of Contents 54 1 Definitions ........................................... 3 55 2 Introduction .......................................... 3 56 3 Setup and holding preemption priorities ............... 4 57 4 Setting up multi-class RSVP-signaled LSPs ............. 5 58 4.1 The extended classtype object ......................... 5 59 4.2 RSVP signaling ........................................ 6 60 4.3 RSVP error processing ................................. 7 61 5 The extended-MAM bandwidth constraints model .......... 8 62 6 IGP extensions ........................................ 8 63 7 Migration issues ...................................... 8 64 8 Security considerations ............................... 9 65 9 Intellectual Property Statement ....................... 9 66 10 Acknowledgments ....................................... 9 67 11 References ............................................ 9 68 11.1 Normative References .................................. 10 69 12 Authors' Addresses .................................... 10 70 Full Copyright Statement .............................. 11 72 1. Definitions 74 For readability a number of definitions from [RFC3564] are repeated 75 here: 77 Traffic Trunk: an aggregation of traffic flows of the same class 78 [i.e. which are to be treated equivalently from the DS-TE perspec- 79 tive] which are placed inside a Label Switched Path. 81 Class-Type (CT): the set of Traffic Trunks crossing a link that is 82 governed by a specific set of Bandwidth constraints. CT is used for 83 the purposes of link bandwidth allocation, constraint based routing 84 and admission control. A given Traffic Trunk belongs to the same CT 85 on all links. 87 TE-Class: A pair of: 88 1. a Class-Type 89 2. a preemption priority allowed for that Class-Type. This means 90 that an LSP transporting a Traffic Trunk from that Class-Type 91 can use that preemption priority as the set-up priority, as the 92 holding priority or both. 94 2. Introduction 96 [RFC4124] defines the protocol extensions for setting up diffserv- 97 aware traffic engineered LSPs. An LSP set up according to [RFC4124] 98 carries traffic from a single diffserv class and is set up along a 99 path that satisfies the bandwidth constraints specified for this 100 class. In this case, a single Class-Type is configured per LSP. In 101 the rest of this document such an LSP is called single-class diff- 102 serv-TE LSP. Note that from a diffserv point of view, a single-class 103 LSP can be either an L-LSP or an E-LSP (as defined in [RFC3270]). 105 In some scenarios it is required to allow traffic with different 106 diffserv behaviors to be mapped to the same LSP and to traffic engi- 107 neer the LSP according to the bandwidth constraints for each one of 108 these classes. In this case, multiple Class-Types are configured per 109 LSP. In the rest of the document such an LSP is called a multi-class 110 diffserv-TE LSP. From a diffserv point of view, a multi-class LSP is 111 always an E-LSP. 113 An example scenario for multi-class LSPs comes in the context of ATM 114 trunk emulation using MPLS LSPs. In this case, it is preferable to 115 have all the traffic classes following the same path and exhibit the 116 same behavior in case of failure. 118 Another application of multi-class diffserv-TE LSPs is for reducing 119 the number of LSPs in a network by setting up reservations for sev- 120 eral classes in one LSP rather than one reservation per class. With 121 single class LSPs, the total number of LSPs in the network is equal 122 to the number of classes times the number of LSPs in the mesh. With 123 multi-class LSPs, the total number of LSPs is equal to the size of 124 the LSP mesh. The reduction in the number of LSPs is important from a 125 scaling and manageability point of view. 127 Here are a few observations regarding single-class and multi-class 128 LSPs: 129 o An LSP that is signaled using the extensions defined in this doc- 130 ument is not required to request bandwidth from multiple Class- 131 Types. As a special case, when the request is from a single 132 Class-Type, the LSP behaves as a single-class LSP and from a 133 diffserv point of view can be either an L-LSP or an E-LSP. There- 134 fore, conceptually, multi-class LSPs are a superset of single- 135 class LSPs. 137 o In order to achieve bandwidth reservation from several traffic 138 classes, two approaches can be taken: 1) create one multi-class 139 LSP or 2) create several single-class LSPs. Note however that the 140 two approaches have different properties in terms of: the number 141 of LSPs established, the path that is taken by traffic belonging 142 to different classes and the fate sharing between the different 143 classes. The choice of single-class or multi-class LSP is made 144 based on the requirements of the application and on the network 145 design. 147 o Both single-class and multi-class LSPs must integrate smoothly 148 with non-diffserv-te LSPs. 150 3. Setup and holding preemption priorities 152 As per existing TE, multi-class LSPs can be configured with a setup 153 and holding priority, each with a value between 0 and 7. The combi- 154 nation of the setup priority and each of the Class-Types for which 155 the multi-class LSP is set up and of the hold priority and each of 156 the Class-Types for which the multi-class LSP is set up, MUST be such 157 that together they form one of the (up to) 8 TE-Classes configured in 158 the TE-Class Mapping. This requirement is similar to the requirement 159 spelled out in [RFC4124] regarding the combination of priority and 160 class-type for single-class LSPs. 162 4. Setting up multi-class RSVP-signaled LSPs 164 4.1. The extended classtype object 166 To request LSP setup along a path with bandwidth constraints from 167 more than one Class-Type, a new object is defined, the extended- 168 classtype-object. This object has a class_num that ensures that a 169 node that doesn't recognize it will reject it and return an "Unknown 170 Object Num" error. According to the guidelines in [RFC3936], the val- 171 ues used are class_num 124 and "class class_type" 1. 173 The contents are a set of subobjects, each encoded as a TLV. 175 0 1 2 3 176 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 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Subobjects | 179 . ... . 180 . ... . 181 . ... . 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 A TLV has the following format: 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Type | Length | MBZ | CTi | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | BW requested for CTi (32-bit IEEE floating point number) | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 Length: 16 bits 195 The length contains the total length of the subobject in 196 bytes, including the type, length, mbz, CTi fields. 197 The length MUST be at least 8, and MUST be a multiple of 4. 199 Type : 8 bits 200 The type of the contents of the subobject. Currently defined 201 value is 202 1 - bandwidth 204 MBZ: 3 bits 205 This field is reserved. It must be set to zero on transmission 206 and must be ignored on receipt. 208 CT : 3 bits 209 Indicates the Class-Type. Values currently allowed are 0, 1, 210 2, ... , 7. Note that this is different from the definition 211 given in [RFC4124] where the value 0 is not allowed. 213 BW requested : 32 bits 214 Indicates the number of bytes (not bits) per second that need 215 to be reserved for the CT indicated. 217 4.2. RSVP signaling 219 The extended-classtype object is signaled in the PATH message, and 220 saved in the PSB at every hop. The extended-classtype object MUST NOT 221 be included in a RESV message. 223 The format of the Path message is as follows: 225 ::= [ ] 226 [ 227 ] 228 [ ] 229 [ ] 230 [ ] 231 [ ... ] 232 [ ] 234 ::= [ ] 235 [ ] 236 [ ] 238 When the classtype object is present, the values in the tspec are 239 ignored for admission control purposes and SHOULD be 0. 241 Admission control is performed for the requirements specified in each 242 of the (CT, BW) pairs in the extended-classtype object. Admission 243 control succeeds only if the requirements for all the (CT, BW) pairs 244 are satisfied. 246 Merging MUST NOT be performed among reservations that belong to LSPs 247 for which the extended-classtype object was signaled. 249 If the extended-classtype object is not present in the PATH message, 250 the LSR associates the LSP with CT0 and performs admission control 251 from the bandwidth/priority values for CT0. In the case where the LSP 252 is from a single class, and the class is CT0, the extended-classtype 253 object MAY be included in the PATH message. 255 4.3. RSVP error processing 257 If the extended-classtype object is not understood, an "Unknown 258 Object Num' error is returned. 260 An LSR that recognizes the extended-classtype object and that 261 receives a path message which contains the extended-classtype object 262 but which does not contain a LABEL_REQUEST object or which does not 263 have a session type of LSP_Tunnel_IPv4, MUST send a PathErr towards 264 the sender with the error code 'extended-classtype Error' and an 265 error value of 'Unexpected extended-classtype object'. These are 266 defined below. 268 An LSR receiving a Path message with the extended-classtype object, 269 which recognizes the object but does not support the particular 270 Class-Type, MUST send a PathErr towards the sender with the error 271 code 'extended-classtype Error' and an error value of 'Unsupported 272 Class-Type'. 274 An LSR receiving a Path message with the extended-classtype object, 275 which: 276 - recognizes the object, 277 - supports the particular Class-Type, but 278 - determines that the tuple formed by (i)this Class-Type and (ii) 279 the holding priority signaled in the same Path message, is not 280 one of the eight TE-classes configured in the TE-class mapping, 281 MUST send a PathErr towards the sender with an error value of 'CT and 282 holding priority do not form a configured TE-Class'. For setup prior- 283 ity, return 'CT and setup priority do not form a configured TE-class' 285 The error checking ensures that multi-class LSPs get established only 286 through LSRs that support multi-class diffserv-te LSPs and have con- 287 sistent TE-mappings with the ingress. 289 Errors related to the processing of the extended-classtype-object are 290 reported using the vendor-specific Error-Code "extended-classtype- 291 error" 252. The first four octets following the Error Value are 2636 292 - the vendor's SMI enterprise code in network octet order (as 293 required by [RFC3936]) 295 The error values are the same as defined in [RFC4124] for the 296 classtype object. The values 3, 6, 7 are not used with multi-class- 297 LSPs. 299 5. The extended-MAM bandwidth constraints model 301 A new BC model-id is defined, the extended-mam bandwidth model, with 302 value 254. The extended-mam model has the same behavior as the MAM 303 model [RFC4125]. 305 6. IGP extensions 307 [RFC4124] defines the bandwidth-constraint (BC) sub-tlv. The BC sub- 308 tlv includes the bandwidth model and a list of bandwidth-constraints. 309 In [RFC4124], the semantic of the "Unreserved Bandwidth" sub-TLV is 310 changed such that the eight bandwidth values advertised correspond to 311 the unreserved bandwidth for each of the TE-Class (instead of for 312 each preemption priority as per existing TE). This approach has two 313 drawbacks: 314 o It creates a flag day in the network with regards to the existing 315 TE LSPs set up without any diffserv properties, as explained in 316 [RFC4124]. 317 o It requires that LSPs from CT0 be set up at priorities such that 318 the combination of (CT0, priority) is one of the configured TE- 319 classes. Thus, the priorities asssigned to pre-existing CT0 LSPs 320 use up some of the TE-classes. 322 In the method documented here, when the bandwidth-model is extended- 323 mam, the semantic of the "Unreserved Bandwidth" sub-TLV is the same 324 as in existing TE and the bandwidth available per TE-class is adver- 325 tised in the BC sub-tlv. This approach achieves the following: 326 o There is no interference between the diffserv-aware LSPs and the 327 plain TE LSPs 328 o There are no migration issues when deploying this feature in a 329 network where TE LSPs are deployed. 330 o A total of 16 TE-classes are effectively created. 332 7. Migration issues 334 Since the semantics of the "Unreserved Bandwidth" sub-TLV are main- 335 tained unchanged, there are no migration issues when deploying multi- 336 class LSPs in a network where traffic engineering is already in use. 338 Single-class and multi-class LSPs cannot co-exist in the same net- 339 work. When both the multi-class and the single-class functionality 340 is required, the semantics of single-class LSPs can be provided by 341 the multi-class LSPs. 343 8. Security considerations 345 The same security considerations apply as for single-class diffserv- 346 TE LSPs [RFC4124]. 348 9. Intellectual Property Statement 350 The IETF takes no position regarding the validity or scope of any 351 Intellectual Property Rights or other rights that might be claimed to 352 pertain to the implementation or use of the technology described in 353 this document or the extent to which any license under such rights 354 might or might not be available; nor does it represent that it has 355 made any independent effort to identify any such rights. Information 356 on the procedures with respect to rights in RFC documents can be 357 found in BCP 78 and BCP 79. 359 Copies of IPR disclosures made to the IETF Secretariat and any assur- 360 ances of licenses to be made available, or the result of an attempt 361 made to obtain a general license or permission for the use of such 362 proprietary rights by implementers or users of this specification can 363 be obtained from the IETF on-line IPR repository at 364 http://www.ietf.org/ipr. 366 The IETF invites any interested party to bring to its attention any 367 copyrights, patents or patent applications, or other proprietary 368 rights that may cover technology that may be required to implement 369 this standard. Please address the information to the IETF at ietf- 370 ipr@ietf.org. 372 10. Acknowledgments 374 This work is the outcome of discussions with Arthi Ayyangar and Chai- 375 tanya Kodeboyina. The authors would like to thank them for their 376 suggestions and insight. The authors would like to thank Yakov 377 Rekhter and Peter Busschbach for their review. 379 11. References 380 11.1. Normative References 382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", RFC 2119. 385 [RFC3270] Le Faucheur et al, "MPLS Support of Diff-Serv", RFC3270. 387 [RFC3564] Le Faucheur et al, "Requirements for support of Diff-Serv- 388 aware MPLS Traffic Engineering", RFC3564. 390 [RFC3936] Kompella, K., Lang, J., "Procedures for Modifying the 391 Resource reSerVation Protocol (RSVP)", RFC3936. 393 [RFC4125] Le Faucheur, Lai, "Maximum Allocation Bandwidth Constraints 394 Model for DS-TE", RFC4125. 396 [RFC4124] Le Faucheur et al, "Protocol extensions for support of 397 Diff-Serv-aware MPLS Traffic Engineering", RFC4124. 399 12. Authors' Addresses 401 Ina Minei 402 Juniper Networks 403 1194 N.Mathilda Ave 404 Sunnyvale, CA 94089 405 e-mail: ina@juniper.net 407 Der-Hwa Gan 408 Juniper Networks 409 1194 N.Mathilda Ave 410 Sunnyvale, CA 94089 411 e-mail: dhg@juniper.net 413 Kireeti Kompella 414 Juniper Networks 415 1194 N.Mathilda Ave 416 Sunnyvale, CA 94089 417 e-mail: kireeti@juniper.net 419 Xiaoming Li 420 China United Telecommunications Corporation 421 No.133A, Xidan North Street, 422 Xicheng District, Beijing 100032, China 423 email: lixm@chinaunicom.com.cn 425 Full Copyright Statement 427 Copyright (C) The Internet Society (2006). This document is subject 428 to the rights, licenses and restrictions contained in BCP 78, and 429 except as set forth therein, the authors retain all their rights. 431 Additional copyright notices are not permitted in IETF Documents 432 except in the case where such document is the product of a joint 433 development effort between the IETF and another standards development 434 organization or the document is a republication of the work of 435 another standards organization. Such exceptions must be approved on 436 an individual basis by the IAB. 438 This document and the information contained herein are provided on an 439 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 440 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 441 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 442 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- 443 MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 444 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 446 Acknowledgement 448 Funding for the RFC Editor function is currently provided by the 449 Internet Society.