idnits 2.17.1 draft-ietf-pce-dste-00.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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 418. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 394. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 401. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 407. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 1) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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 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 CLASSTYPE object. -- 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 (October 23, 2007) is 6023 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: 'RFC4124' is mentioned on line 94, but not defined == Unused Reference: 'RFC2119' is defined on line 326, but no explicit reference was found in the text == Unused Reference: 'RSVP-TE' is defined on line 329, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-pce-pcep-08 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Sivabalan, Ed. 3 Internet Draft J. Parker 4 Intended status: Standards Track S. Boutros 5 Expires: April 15, 2008 Cisco Systems, Inc. 7 K. Kumaki 8 KDDI Corporation 10 October 23, 2007 12 Diff-Serv Aware Class Type Object for Path Computation Element 13 Communication Protocol 14 draft-ietf-pce-dste-00.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that 19 any applicable patent or other IPR claims of which he or she is 20 aware have been or will be disclosed, and any of which he or she 21 becomes aware will be disclosed, in accordance with Section 6 of 22 BCP 79. 24 This document may not be modified, and derivative works of it 25 may not be created, except to publish it as an RFC and to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet 29 Engineering Task Force (IETF), its areas, and its working 30 groups. Note that other groups may also distribute working 31 documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other 35 documents at any time. It is inappropriate to use Internet- 36 Drafts as reference material or to cite them other than as "work 37 in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on April 15, 2007. 47 Abstract 49 This document specifies a CLASSTYPE object to support Diff-Serve 50 Aware Traffic Engineering (DS-TE) where path computation is 51 performed with an aid of Path Computation Element (PCE). 53 Conventions used in this document 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 56 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 57 "OPTIONAL" in this document are to be interpreted as described 58 in RFC-2119. 60 Table of Contents 62 1. Introduction................................................2 63 2. Terminology.................................................3 64 3. CLASSTYPE object............................................3 65 3.1. Object definition.........................................4 66 3.2. Path Computation Request Message with CLASSTYPE object....5 67 3.3. Handling of the CLASSTYPE object..........................5 68 3.4. Determination of Traffic Engineering Class (TE-Class).....6 69 3.5. Significance of Class-type and TE-Class...................6 70 3.6. Error Codes for CLASSTYPE object..........................6 71 4. Security Considerations.....................................7 72 5. IANA Considerations.........................................7 73 6. Acknowledgments.............................................7 74 7. References..................................................7 75 7.1. Normative References......................................7 76 Author's Addresses.............................................8 77 Intellectual Property Statement................................9 78 Disclaimer of Validity.........................................9 80 1. Introduction 82 The Internet Draft [PCEP-ID] specifies the Path Computation 83 Element communication Protocol (PCEP) for communications between 84 a Path Computation Client(PCC) and a Path Computation Element 85 (PCE), or between two PCEs, in compliance with [RFC4657]. 87 Differentiated Service aware MPLS Traffic Engineering (DS-TE) 88 addresses the fundamental requirement to be able to enforce 89 different bandwidth constraints for different classes of traffic 90 and describes mechanisms to achieve per-class traffic 91 engineering, rather than on an aggregate basis across all 92 classes by enforcing Bandwidth Constraints (BCs) on different 93 classes. Requirements for DS-TE and the associated protocol 94 extensions are specified in [RFC3564] and [RFC4124] 95 respectively. 97 As per [RFC4657], PCEP must support traffic class-type as an 98 MPLS TE specific constraint. However, in the present form, PCEP 99 [PCEP-ID] does not have the capability to specify the class-type 100 in the path computation request. 102 In this document, we define a new PCEP object called CLASSTYPE 103 which carries the class-type of the TE LSP in the path 104 computation request. During path computation, a PCE uses the 105 class-type to identify the bandwidth constraint of the TE-LSP. 107 2. Terminology 109 CT: Class type: A set of Traffic Trunks governed by a set of 110 bandwidth constraints. Used for the purpose of link bandwidth 111 allocation, constraint based routing and admission control. A 112 given Traffic Trunk belongs to the same CT on all links. 114 DS-TE: Diff-Serv Aware Traffic Engineering. 116 LSR: Label Switching Router. 118 LSP: Label Switched Path. 120 PCC: Path Computation Client: any client application requesting 121 a path computation to be performed by a Path Computation 122 Element. 124 PCE: Path Computation Element: an entity (component, application 125 or network node) that is capable of computing a network path or 126 route based on a network graph and applying computational 127 constraints. 129 PCEP Peer: an element involved in a PCEP session (i.e. a PCC or 130 the PCE). 132 TE-Class: A pair consisting of a class-type and a preemption 133 priority allowed for that class type. An LSP transporting a 134 Traffic Trunk from that class type can use that preemption 135 priority as the setup priority, the holding priority, or both. 137 TE LSP: Traffic Engineering Label Switched Path. 139 Traffic Trunk: An aggregation of traffic flows of the same class 140 (i.e. treated equivalently from the DS-TE perspective) which is 141 placed inside a TE LSP. 143 3. CLASSTYPE object 145 The CLASSTYPE object is optional and is used to specify the 146 class-type of a TE LSP. This object is meaningful only within 147 the path computation request, and is ignored in the path reply 148 message. If the TE LSP for which path is to be computed belongs 149 to Class 0, the path computation request MUST not contain the 150 CLASSTYPE object. This allows backward compatibility with PCE 151 that does not support CLASSTYPE object. 153 3.1. Object definition 155 The CLASSTYPE object contains a 32-bit word PCEP common object 156 header defined in [PCEP-ID] followed by another 32-bit word 157 object body as shown in Figure 1. 159 0 1 2 3 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Object-Class | OT |Res|P|I| Object Length (bytes) | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Reserved | CT | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 167 Figure 1 CLASSTYPE object format. 169 The fields in the object common header are processed as 170 specified in [PCEP-ID]. We explain these fields again for 171 completion. For more details, please refer to [PCEP-ID]. 173 Object-Class is to be assigned by IANA (recommended value=16). 175 Object-Type (OT) is to be assigned by IANA (recommended 176 value=1). 178 Res flags (2 bits). Reserved field. This field MUST be set to 179 zero on transmission and MUST be ignored on receipt. 181 P flag (1 bit): When the P flag is set, the CLASSTYPE object 182 MUST be taken into account by the PCE. Conversely, when the P 183 flag is cleared, the object is optional and the PCE is free to 184 ignore it if not supported. 186 I flag (1 bit): The PCE MAY include the ignored optional object 187 in its reply and set the I flag to indicate that the optional 188 object was ignored during path computation. 190 Object Length (16 bits). Specifies the total object length 191 including the header, in bytes. The Object Length field MUST 192 always be a multiple of 4, and at least 4. The maximum object 193 content length is 65528 bytes. 195 The CLASSTYPE object body contains the following fields: 197 CT: 3-bit field that indicates the class-type. Values allowed 198 are 1, 2, ... , 7. Value of 0 is Reserved. 200 Reserved: 29-bit reserved field. It MUST be set to zero on 201 transmission and MUST be ignored on receipt. 203 3.2. Path Computation Request Message with CLASSTYPE object 205 The draft [PCEP-ID] specifies the object orders in which objects 206 must be inserted in the PCEP messages. This document specifies 207 that the CLASSTYPE object be inserted after the END-POINT 208 objects as shown below: 210 The format of a PCReq message is as follows: 212 ::= 213 [] 214 215 where: 216 ::=[] 217 ::=[] 218 ::= 219 220 [] 221 [] 222 [] 223 [] 224 [] 225 [] 226 [] 227 where: 228 ::=[] 230 3.3. Handling of the CLASSTYPE object 232 If the LSP is associated with Class-Type N (1 <= N <= 7), the 233 PCC originating the path computation request MUST include the 234 CLASSTYPE object in the Path computation request message with 235 the Class-Type (CT) field set to N. 237 If a path computation request contains multiple CLASSTYPE 238 objects, only the first one is meaningful; subsequent CLASSTYPE 239 object(s) MUST be ignored and MUST NOT be forwarded. 241 If the CLASSTYPE object is not present in the path computation 242 request message, the LSR MUST associate the Class-Type 0 to the 243 LSP. 245 Path computation reply message MUST NOT include a CLASSTYPE 246 object. If a PCE needs to forward a path computation request 247 containing the CLASSTYPE object to another PCE, it MUST store 248 the class-type of the TE LSP in order to complete the path 249 computation when the path computation reply arrives. 251 A PCE receiving a path computation request message with the 252 CLASSTYPE object with P flag set that does not recognize the 253 CLASSTYPE object MUST reject the entire PCEP message and MUST 254 send a PCE error message with Error-Type="Unknown Object" or 255 "Not supported Object" defined in [PCEP-ID]. 257 A PCE receiving a path computation request message with the 258 CLASSTYPE object that recognizes the CLASSTYPE object, but 259 does not support the particular Class-Type, MUST send a PCE 260 error message towards the sender with the error type "Diff-Serv 261 aware TE Error" and an error value of "Unsupported Class-Type" 262 (new error code provided below). 264 A PCE receiving a path computation request message with the 265 CLASSTYPE object that recognizes the CLASSTYPE object, but 266 determines that the Class-Type value is not valid (i.e., Class 267 Type value 0), MUST send a PCE error towards the sender with the 268 error type "Diff-Serve aware TE Error" and an error value of 269 "Invalid Class-Type value" (new error code provided below). 271 3.4. Determination of Traffic Engineering Class (TE-Class) 273 As specified in RFC4124, a CT and a Preemption priority map to a 274 Traffic Engineering Class (TE-Class), and there can be up to 8 275 TE-classes. The TE-class value is used to determine the 276 unreserved bandwidth on the links during path computation. In 277 the case of a PCE, the CT value carried in the CLASSTYPE object 278 and the setup priority in the LSP Attribute (LSPA) object are 279 used to determine the TE-class corresponding to the path 280 computation request. If LSPA object is absent, the setup 281 priority is assumed to be 0. 283 3.5. Significance of Class-type and TE-Class 285 To ensure coherent DS-TE operation, a PCE and a PCC should have 286 a common understanding of a particular DS-TE classtype and TE- 287 Class. If a path computation request crosses an AS boundary, 288 these should have global significance in all domains. 289 Enforcement of this global significance is outside the scope of 290 this document. 292 3.6. Error Codes for CLASSTYPE object 294 This document defines the following error type and values: 296 Error-Type Meaning 297 11 Diff-Serve aware TE Error 298 Error-value=1: unsupported class-type. 299 Error-value=2: invalid class-type. 300 Error-value=3: class-type and setup priority does 301 not 302 form a configured TE class. 304 4. Security Considerations 306 This document does not introduce new security issues. The 307 security considerations pertaining to PCEP [PCEP-ID] remain 308 relevant. 310 5. IANA Considerations 312 IANA assigns value to PCEP parameters. Each PCEP object has an 313 Object-Class and an Object-Type. For the CLASSTYPE object, the 314 suggested values for Object-Class and Object-Type are 16 and 1 315 respectively. 317 6. Acknowledgments 319 The authors would like to thank Jean Philippe Vasseur for his 320 valuable comments. 322 7. References 324 7.1. Normative References 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, March 1997. 329 [RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T.,Srinivasan, 330 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 331 LSP Tunnels", RFC 3209, December 2001. 333 [RFC4124]Le Faucheur, F. and W. Lai, "Protocol Extensions for 334 Support of Diffserv-aware MPLS Traffic Engineering", 335 RFC 4124, June 2005. 337 [PCEP-ID] Path Computation Element (PCE) communication Protocol 338 (PCEP)", draft-ietf-pce-pcep-08.txt (work in 339 progress), February 2007. 341 7.2. Informative References 343 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element 344 (PCE) Communication Protocol Generic Requirements", 345 RFC 4657, September 2006. 347 [RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support 348 of Differentiated Services-aware MPLS Traffic 349 Engineering", RFC 3564, July 2003. 351 Author's Addresses 353 Siva Sivabalan 354 Cisco Systems, Inc. 355 2000 Innovation Drive 356 Kanata, Ontario, K2K 3E8 357 Canada 359 Email: msiva@cisco.com 361 Jon Parker 362 Cisco Systems, Inc. 363 2000 Innovation Drive 364 Kanata, Ontario, K2K 3E8 365 Canada 367 Email: jdparker@cisco.com 369 Sami Boutros 370 Cisco Systems, Inc. 371 2000 Innovation Drive 372 Kanata, Ontario, K2K 3E8 373 Canada 375 Email: sboutros@cisco.com 376 Kenji Kumaki 377 KDDI Corporation 378 Garden Air Tower Iidabashi, Chiyoda-ku 379 Tokyo, 102-8460 380 Japan 382 Email: ke-kumaki@kddi.com 384 Intellectual Property Statement 386 The IETF takes no position regarding the validity or scope of 387 any Intellectual Property Rights or other rights that might be 388 claimed to pertain to the implementation or use of the 389 technology described in this document or the extent to which any 390 license under such rights might or might not be available; nor 391 does it represent that it has made any independent effort to 392 identify any such rights. Information on the procedures with 393 respect to rights in RFC documents can be found in BCP 78 and 394 BCP 79. 396 Copies of IPR disclosures made to the IETF Secretariat and any 397 assurances of licenses to be made available, or the result of an 398 attempt made to obtain a general license or permission for the 399 use of such proprietary rights by implementers or users of this 400 specification can be obtained from the IETF on-line IPR 401 repository at http://www.ietf.org/ipr. 403 The IETF invites any interested party to bring to its attention 404 any copyrights, patents or patent applications, or other 405 proprietary rights that may cover technology that may be 406 required to implement this standard. Please address the 407 information to the IETF at ietf-ipr@ietf.org. 409 Disclaimer of Validity 411 This document and the information contained herein are provided 412 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 413 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 414 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 415 ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 416 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 417 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 418 OR FITNESS FOR A PARTICULAR PURPOSE. 420 Copyright Statement 422 Copyright (C) The IETF Trust (2007). 424 This document is subject to the rights, licenses and restrictions 425 contained in BCP 78, and except as set forth therein, the authors 426 retain all their rights. 428 Acknowledgment 430 Funding for the RFC Editor function is currently provided by the 431 Internet Society.