idnits 2.17.1 draft-zhao-pce-pcep-multiclass-type-dste-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 16 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 3, 2009) is 5408 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'PCEP' is mentioned on line 115, but not defined == Missing Reference: 'OBJ-ORD' is mentioned on line 275, but not defined == Unused Reference: 'RFC2119' is defined on line 395, but no explicit reference was found in the text == Unused Reference: 'RFC5511' is defined on line 432, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3564 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Quintin Zhao 3 Internet-Draft Suresh Babu 4 Intended status: Standards Track Huawei Technology 5 Expires: December 3, 2009 Daniel King 6 Old Dog Consulting 7 July 3, 2009 9 Multi-Class DSTE Support for the Path Computation Element Communication 10 Protocol 11 draft-zhao-pce-pcep-multiclass-type-dste-00.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 3, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 Diffserv-Aware Traffic Engineering (DS-TE) can be used by Service 50 Providers to perform fine grain bandwidth management of a subset, or 51 sub-pool, of traffic flows. Typically in DS-TE a diffserv class will 52 use a single Label Switch Path (LSP) that satisfies the bandwidth 53 required. Where traffic with different diffserv characteristics must 54 be mapped to a single LSP. Multi-Class DS-TE can be used to select 55 an LSP that satisfy the bandwidth requirement of all classes 56 required. 58 This document specifies the PCEP extentions to support Multi-Class 59 Type DS-TE where path computation is performed with the aid of a Path 60 Computation Element (PCE). 62 Table of Contents 64 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Solution Chioces to Support the Multi-Class Type Object . . . 4 67 3.1. Solution Choice 1: Using the Existing Class Type 68 Object to Support the Multi-Class Type Object . . . . . . 4 69 3.1.1. Request Message Format Extension . . . . . . . . . . . 4 70 3.1.2. Processing of CLASSTYPE Object and BANDWITH Object . . 5 71 3.2. Solution Chioces 2: Adding a new Multi Class DSTE 72 Object to Support the Multi-Class Type . . . . . . . . . . 6 73 3.2.1. Request Message Format Extension . . . . . . . . . . . 6 74 3.2.2. New MULTICLASSDSTE Object Definition . . . . . . . . . 7 75 3.2.3. Processing of MULTICLASSDSTE Object . . . . . . . . . 8 76 4. Error Codes for CLASSTYPE Object . . . . . . . . . . . . . . . 9 77 5. Impact on Network Operation . . . . . . . . . . . . . . . . . 9 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 80 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 86 1. Terminology 88 Terminology used in this document 90 For readability a number of definitions from [RFC3564] are repeated 91 here: 93 Traffic Trunk: an aggregation of traffic flows of the same class 94 [i.e. which are to be treated equivalently from the DS-TE perspec- 95 tive] which are placed inside a Label Switched Path. 97 Class-Type (CT): the set of Traffic Trunks crossing a link that is 98 governed by a specific set of Bandwidth constraints. CT is used for 99 the purposes of link bandwidth allocation, constraint based routing 100 and admission control. A given Traffic Trunk belongs to the same CT 101 on all links. 103 TE-Class: A pair of: 105 1. a Class-Type 107 2. a preemption priority allowed for that Class-Type. This means 108 that an LSP transporting a Traffic Trunk from that Class-Type can use 109 that preemption priority as the set-up priority, as the holding 110 priority or both. 112 Multiclass LSP: an LSP that can carry several class types. 114 This document also uses the terminology defined in [RFC4655], 115 [RFC4875], and [PCEP]. 117 2. Introduction 119 [RFC5440] specifies the Path Computation Element Communication 120 Protocol (PCEP) for communications between a Path Computation Client 121 (PCC) and a Path Computation Element (PCE), or between two PCEs, in 122 compliance with [RFC4657]. 124 [RFC4124] defines the protocol extensions for setting up diffserv- 125 aware traffic engineered LSPs. An LSP set up according to [RFC4124] 126 carries traffic from a single diffserv class and is set up along a 127 path that satisfies the bandwidth constraints specified for this 128 class. In this case, a single Class-Type is configured per LSP. 130 In some scenarios it is required to allow traffic with different 131 diffserv behaviors to be mapped to the same LSP and to traffic 132 engineer the LSP according to the bandwidth constraints for each one 133 of these classes. In this case, multiple Class-Types are configured 134 per LSP. For further analysis and explanation of multi-class 135 diffserv-TE LSPs see [MULTICLASS]. 137 As defined in [RFC4657], PCEP must support traffic Class-Type as an 138 MPLSTE-specific constraint. As per [RFC5455], it has defined a PCEP 139 object called CLASSTYPE, which carries the Class-Type of the TE LSP 140 in the path computation request. During path computation, a PCE uses 141 the Class-Type to identify the bandwidth constraint of the TE LSP. 142 But the Class-Type object only applies a single class type to the 143 computation request. 145 In this document, we will define extend the class-type object and the 146 procedures to handle the requirement for the LSP path calculation 147 which supports multiple class types [MULTICLASS]. 149 3. Solution Chioces to Support the Multi-Class Type Object 151 There are two possible solutions proposed in this version of the 152 draft. One solution is that we use the class object defined in 153 [RFC5044] already and extend the request message to include multiple 154 of the class type object in the request message and correspondingly 155 includes multiple of bandwidth objects at the same time. 157 The second choice is to add a new class type object for the multi 158 class type. In this case the single class type will be signaled 159 using the original class type object defined in [RFC5044] and it can 160 also signal the class type using the new class type object defined 161 here to signal multi class type or a single class type. 163 [Editor Note] As this document evolves and working group feedback is 164 gained, the authors identify and adopt a single solution. 166 3.1. Solution Choice 1: Using the Existing Class Type Object to Support 167 the Multi-Class Type Object 169 Path Computation Request Message with CLASSTYPE Object [RFC5440] 170 specifies the order in which objects must be inserted in the PCEP 171 messages. [RFC5044] specifies that the CLASSTYPE object be inserted 172 after the END-POINT objects to signal a single class type. 174 3.1.1. Request Message Format Extension 176 In this solution choice, we propose to expand the request message to 177 support the multi class types to the following: 179 ::= 180 [] 181 182 where: 183 ::=[] 184 ::=[] 185 ::= 186 187 [] 188 [] 189 [] 190 [] 191 [] 192 [] 193 [] 194 where: 195 ::=[] 197 ::=[] 198 >::=[] 200 Note that an implementation MUST form the PCEP messages using the 201 object ordering rules specified using Backus-Naur Form. Please refer 202 to [OBJ-ORD] for more details. 204 Figure 1: Extended Request Message Format 206 3.1.2. Processing of CLASSTYPE Object and BANDWITH Object 208 If the LSP is associated with m of Class-Type N (0 <= N <= 7), the 209 PCC originating the PCReq MUST include m of CLASSTYPE objects in the 210 PCReq message with the Class-Type (CT) field set to its corresponding 211 class type. If a path computation request contains multiple 212 CLASSTYPE objects. At the same time,m of BANDWIDTH objects are 213 needed incldued in the request message. 215 If the CLASSTYPE object is not present in the path computation 216 request message, the LSR MUST associate the Class-Type 0 to the LSP. 217 A path computation reply message MUST NOT include a CLASSTYPE object. 219 If a PCE needs to forward a path computation request containing a 220 number of CLASSTYPE objects to another PCE, it MUST store the Class- 221 Type of the TE LSP in order to complete the path computation when the 222 path computation reply arrives. 224 A PCE that does not recognize the CLASSTYPE object MUST reject the 225 entire PCEP message and MUST send a PCE error message with Error- 226 Type="Unknown Object" or "Not supported object", defined in 227 [RFC5440]. 229 A PCE that recognizes the CLASSTYPE object, but finds that the P flag 230 is not set in the CLASSTYPE object, MUST send PCE error message 231 towards the sender with the error type and error value specified in 232 [RFC5440]. 234 A PCE that recognizes the CLASSTYPE object, but does not support the 235 particular Class-Type, MUST send a PCE error message towards the 236 sender with the error type "Diffserv-aware TE error" and the error 237 value of "Unsupported Class-Type" (Error-value 1). 239 A PCE that recognizes the CLASSTYPE object, but determines that the 240 Class-Type value is not valid, MUST send a PCE error towards the 241 sender with the error type "Diffserv-aware TE error" and an error 242 value of "Invalid Class-Type" (Error-value 2). 244 3.2. Solution Chioces 2: Adding a new Multi Class DSTE Object to 245 Support the Multi-Class Type 247 3.2.1. Request Message Format Extension 249 In this solution chioce, we propose to expand the request message to 250 support the multi class types to the following: 252 ::= 253 [] 254 255 where: 256 ::=[] 257 ::=[] 258 ::= 259 260 [] 261 [] 262 [] 263 [] 264 [] 265 [] 266 [] 267 [] 268 where: 269 ::=[] 271 The defination of the MULTICLASSDSTE is explained in the next section in detail. 273 Note that an implementation MUST form the PCEP messages using the 274 object ordering rules specified using Backus-Naur Form. Please refer 275 to [OBJ-ORD] for more details. 277 Figure 2: Extended Request Message Format 279 3.2.2. New MULTICLASSDSTE Object Definition 281 The MULTICLASSDSTE object contains a 32-bit word PCEP common object 282 header defined in [RFC5440] followed by another one pair or more but 283 not more than 8 pair of 32-bit word object body for the class type 284 and the bandwidth body for each class type: 286 0 1 2 3 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | PCEP common header | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Reserved | bitmap of CT | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | BW requested for CT1 (32-bit IEEE floating point number) | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | .... | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | .... | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 Figure 3: Muti CLass DSTE Object 302 The fields in the common object header are processed as specified in 303 [RFC5440]. The values of object class and object type are to be 304 defined, respectively. If included, the MULTICLASSDSTE object must 305 be taken into account by the PCE. As such, the P flag MUST be set. 306 The I flag is ignored. 308 The MULTICLASSDSTE object body contains the following fields: 310 o Bit map of CT: 8-bit field that indicates each Class-Type. Each 311 "bit" represents the presence of request for the CT. For example, 312 if the bitmap is 00011010, that indicates CT1, CT3, CT4. 314 o Reserved: 24-bit reserved field. It MUST be set to zero on 315 transmission and MUST be ignored on receipt. 317 o BW: The bandwidth request is for 32-bit IEEE floating point 318 number. The number of the requested BW and the order of the BW 319 requested are corresponding to the bitmap. For example, if the 320 bitmap is 00011010, then there will be three BWs and they are in 321 the order of BW1 for CT1, BW3 for CT3 and BW4 for CT4. 323 3.2.3. Processing of MULTICLASSDSTE Object 325 If the LSP is associated with m of Class-Type N (0 <= N <= 7), the 326 PCC originating the PCReq MUST include a MULTICLASSDSTE object in the 327 PCReq message with m Class-Type (CT) field set to its corresponding 328 class type and with the corresponding bandwidth requested for each 329 CT. 331 If the CLASSTYPE object and MULTICLASSDSTE are present in the path 332 computation request message, A PCE MUST send PCE error message 333 towards the sender with the error type and error value specified in 334 the later section of the document. 336 If the CLASSTYPE object and MULTICLASSDSTE are not present in the 337 path computation request message, the LSR MUST associate the Class- 338 Type 0 to the LSP. A path computation reply message MUST NOT include 339 a CLASSTYPE object. 341 If a PCE needs to forward a path computation request containing a 342 number of CLASSTYPE objects to another PCE, it MUST store the Class- 343 Type of the TE LSP in order to complete the path computation when the 344 path computation reply arrives. 346 A PCE that does not recognize the MULTICLASSDSTE object MUST reject 347 the entire PCEP message and MUST send a PCE error message with Error- 348 Type="Unknown Object" or "Not supported object", defined in 349 [RFC5440]. 351 A PCE that recognizes the MULTICLASSDSTE object, but finds that the P 352 flag is not set in the CLASSTYPE object, MUST send PCE error message 353 towards the sender with the error type and error value specified in 354 [RFC5440]. 356 A PCE that recognizes the MULTICLASS object, but does not support the 357 particular Class-Type, MUST send a PCE error message towards the 358 sender with the error type "Diffserv-aware TE error" and the error 359 value of "Unsupported Class-Type" (Error-value 1). 361 A PCE that recognizes the MULTICLASS object, but determines that the 362 Class-Type value is not valid, MUST send a PCE error towards the 363 sender with the error type "Diffserv-aware TE error" and an error 364 value of "Invalid Class-Type" (Error-value 2). 366 4. Error Codes for CLASSTYPE Object 368 TBD 370 5. Impact on Network Operation 372 It is expected that use of PCEP extensions specified in this document 373 does not have significant impact on network operations. 375 6. Security Considerations 377 It is expected that use of PCEP extensions specified in this document 378 does not have significant impact on Securitiy. 380 7. IANA Considerations 382 A number of IANA considerations have been highlighted in the relevent 383 sections of this document. Further clarifications of these requests 384 will be made in a future version of this document. 386 8. Acknowledgement 388 The authors would like to thank P Shastry for his inputs in this 389 draft. 391 9. References 393 9.1. Normative References 395 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 396 Requirement Levels", BCP 14, RFC 2119, March 1997. 398 [RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of 399 Differentiated Services-aware MPLS Traffic Engineering", 400 RFC 3564, July 2003. 402 [RFC4124] Le Faucheur, F., "Protocol Extensions for Support of 403 Diffserv-aware MPLS Traffic Engineering", RFC 4124, 404 June 2005. 406 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 407 "Extensions to Resource Reservation Protocol - Traffic 408 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 409 Switched Paths (LSPs)", RFC 4875, May 2007. 411 [RFC5044] Culley, P., Elzur, U., Recio, R., Bailey, S., and J. 412 Carrier, "Marker PDU Aligned Framing for TCP 413 Specification", RFC 5044, October 2007. 415 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 416 (PCE) Communication Protocol (PCEP)", RFC 5440, 417 March 2009. 419 [RFC5455] Sivabalan, S., Parker, J., Boutros, S., and K. Kumaki, 420 "Diffserv-Aware Class-Type Object for the Path Computation 421 Element Communication Protocol", RFC 5455, March 2009. 423 9.2. Informative References 425 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 426 Element (PCE)-Based Architecture", RFC 4655, August 2006. 428 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 429 Communication Protocol Generic Requirements", RFC 4657, 430 September 2006. 432 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 433 Used to Form Encoding Rules in Various Routing Protocol 434 Specifications", RFC 5511, April 2009. 436 [MULTICLASS] Minei, I., et al., "Extensions for Differentiated 437 Services-aware Traffic Engineered LSPs", draft-minei- 438 diffserv-te-multi-class, work in progress. 440 Authors' Addresses 442 Quintin Zhao 443 Huawei Technology 444 125 Nagog Technology Park 445 Acton, MA 01719 446 US 448 Email: qzhao@huawei.com 450 Suresh Babu 451 Huawei Technology 452 125 Nagog Technology Park 453 Acton, MA 01719 454 US 456 Email: sureshbr@huawei.com 458 Daniel King 459 Old Dog Consulting 461 Email: daniel@olddog.co.uk