idnits 2.17.1 draft-ietf-pce-dste-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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 415. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 392. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 399. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 405. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 304 has weird spacing: '...E error draf...' -- 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 (November 3, 2008) is 5651 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) == Outdated reference: A later version (-19) exists of draft-ietf-pce-pcep-18 == Outdated reference: A later version (-09) exists of draft-farrel-rtg-common-bnf-07 Summary: 1 error (**), 0 flaws (~~), 4 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: May 2, 2009 Cisco Systems, Inc. 7 K. Kumaki 8 KDDI Corporation 10 November 3, 2008 12 Diff-Serv Aware Class Type Object for 13 Path Computation Element Communication Protocol 14 draft-ietf-pce-dste-02.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 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 This Internet-Draft will expire on May 2, 2009. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2008). 46 Abstract 48 This document specifies a CLASSTYPE object to support Diff-Serve 49 Aware Traffic Engineering (DS-TE) where path computation is performed 50 with an aid of Path Computation Element (PCE). 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC-2119 Error! 57 Reference source not found.. 59 Table of Contents 61 1. Introduction...................................................2 62 2. Terminology....................................................3 63 3. CLASSTYPE Object...............................................4 64 3.1. Object Definition.........................................4 65 3.2. Path Computation Request message with CLASSTYPE Object....4 66 3.3. Processing CLASSTYPE Object...............................5 67 3.4. Determination of Traffic Engineering Class (TE-Class).....6 68 3.5. Significance of Class-Type and TE-Class...................6 69 3.6. Error Codes for CLASSTYPE Object..........................6 70 4. Security Considerations........................................7 71 5. IANA Considerations............................................7 72 6. Acknowledgments................................................7 73 6.1. Normative References......................................8 74 6.2. Informative References....................................8 75 Author's Addresses................................................8 76 Intellectual Property Statement...................................9 77 Disclaimer of Validity............................................9 79 1. Introduction 81 The Internet Draft [PCEP-ID] specifies the Path Computation Element 82 communication Protocol (PCEP) for communications between a Path 83 Computation Client (PCC) and a Path Computation Element (PCE), or 84 between two PCEs, in compliance with [RFC4657]. 86 Differentiated Service aware MPLS Traffic Engineering (DS-TE) 87 addresses the fundamental requirement to be able to enforce different 88 bandwidth constraints for different classes of traffic. It describes 89 mechanisms to achieve per-class traffic engineering, rather than on 90 an aggregate basis across all classes by enforcing Bandwidth 91 Constraints (BCs) on different classes. Requirements for DS-TE and 92 the associated protocol extensions are specified in [RFC3564] and 93 [RFC4124] respectively. 95 As per [RFC4657], PCEP must support traffic class-type as an MPLS TE 96 specific constraint. However, in the present form, PCEP [PCEP-ID] 97 does not have the capability to specify the class-type in the path 98 computation request. 100 In this document, we define a new PCEP object called CLASSTYPE which 101 carries the class-type of the TE LSP in the path computation request. 102 During path computation, a PCE uses the class-type to identify the 103 bandwidth constraint of the TE-LSP. 105 2. Terminology 107 CT: Class type: A set of Traffic Trunks governed by a set of 108 bandwidth constraints. Used for the purpose of link bandwidth 109 allocation, constraint based routing and admission control. A given 110 Traffic Trunk belongs to the same CT on all links. 112 DS-TE: Diff-Serv Aware Traffic Engineering. 114 LSR: Label Switching Router. 116 LSP: Label Switched Path. 118 PCC: Path Computation Client: any client application requesting a 119 path computation to be performed by a Path Computation Element. 121 PCE: Path Computation Element: an entity (component, application or 122 network node) that is capable of computing a network path or route 123 based on a network graph and applying computational constraints. 125 PCEP Peer: an element involved in a PCEP session (i.e. a PCC or the 126 PCE). 128 TE-Class: A pair consisting of a class-type and a preemption priority 129 allowed for that class type. An LSP transporting a Traffic Trunk from 130 that class type can use that preemption priority as the setup 131 priority, the holding priority, or both. 133 TE LSP: Traffic Engineering Label Switched Path. 135 Traffic Trunk: An aggregation of traffic flows of the same class 136 (i.e. treated equivalently from the DS-TE perspective) which is 137 placed inside a TE LSP. 139 3. CLASSTYPE Object 141 The CLASSTYPE object is optional and is used to specify the class- 142 type of a TE LSP. This object is meaningful only within the path 143 computation request, and is ignored in the path reply message. If the 144 TE LSP for which the path is to be computed belongs to Class 0, the 145 path computation request MUST NOT contain the CLASSTYPE object. This 146 allows backward compatibility with PCE that does not support the 147 CLASSTYPE object. 149 3.1. Object Definition 151 The CLASSTYPE object contains a 32-bit word PCEP common object header 152 defined in [PCEP-ID] followed by another 32-bit word object body as 153 shown in Figure 1. 155 0 1 2 3 156 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 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | PCEP common header | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Reserved | CT | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 Figure 1 CLASSTYPE object format. 165 The fields in the object common header are processed as specified in 166 [PCEP-ID]. The values of object class and object type are 22 and 1 167 respectively. If included, CLASSTYPE object must be taken into 168 account by PCE. As such, the P flag MUST be set. I flag is ignored. 170 The CLASSTYPE object body contains the following fields: 172 CT: 3-bit field that indicates the class-type. Values allowed are 1, 173 2, ... , 7. Value of 0 is Reserved. 175 Reserved: 29-bit reserved field. It MUST be set to zero on 176 transmission and MUST be ignored on receipt. 178 3.2. Path Computation Request message with CLASSTYPE Object 180 [PCEP-ID] specifies the object orders in which objects must be 181 inserted in the PCEP messages. This document specifies that the 182 CLASSTYPE object be inserted after the END-POINT objects as shown 183 below: 185 The format of a PCReq message is as follows: 187 ::= 188 [] 189 190 where: 191 ::=[] 192 ::=[] 193 ::= 194 195 [] 196 [] 197 [] 198 [] 199 [] 200 [] 201 [] 202 where: 203 ::=[] 205 Note that an implementation MUST form the PCEP messages using the 206 object ordering rules specified using Backus-Naur Form. Please refer 207 [OBJ-ORD] for more details. 209 3.3. Processing CLASSTYPE Object 211 If the LSP is associated with Class-Type N (1 <= N <= 7), the PCC 212 originating the path computation request MUST include the CLASSTYPE 213 object in the Path computation request message with the Class-Type 214 (CT) field set to N. 216 If a path computation request contains multiple CLASSTYPE objects, 217 only the first one is meaningful; subsequent CLASSTYPE object(s) MUST 218 be ignored and MUST NOT be forwarded. 220 If the CLASSTYPE object is not present in the path computation 221 request message, the LSR MUST associate the Class-Type 0 to the LSP. 223 Path computation reply message MUST NOT include a CLASSTYPE object. 224 If a PCE needs to forward a path computation request containing the 225 CLASSTYPE object to another PCE, it MUST store the class-type of the 226 TE LSP in order to complete the path computation when the path 227 computation reply arrives. 229 A PCE that does not recognize the CLASSTYPE object MUST reject the 230 entire PCEP message and MUST send a PCE error message with Error- 231 Type="Unknown Object" or "Not supported Object" defined in [PCEP-ID]. 233 A PCE that recognizes the CLASSTYPE object finds that P flag is not 234 set in the CLASSTYPE object, it MUST send PCE error message towards 235 the sender with the with the error type and error value specified in 236 [PCEP-ID]. 238 A PCE that recognizes the CLASSTYPE object, but does not support the 239 particular Class-Type, MUST send a PCE error message towards the 240 sender with the error type "Diff-Serv aware TE Error" and the error 241 value of "Unsupported Class-Type" (new error code provided below). 243 A PCE that recognizes the CLASSTYPE object, but determines that the 244 Class-Type value is not valid (i.e., Class Type value 0), MUST send a 245 PCE error towards the sender with the error type "Diff-Serve aware TE 246 Error" and an error value of "Invalid Class-Type value" (new error 247 code provided below). 249 3.4. Determination of Traffic Engineering Class (TE-Class) 251 As specified in RFC4124, a CT and a Preemption priority map to a 252 Traffic Engineering Class (TE-Class), and there can be up to 8 TE- 253 classes. The TE-class value is used to determine the unreserved 254 bandwidth on the links during path computation. In the case of a PCE, 255 the CT value carried in the CLASSTYPE object and the setup priority 256 in the LSP Attribute (LSPA) object are used to determine the TE-class 257 corresponding to the path computation request. If LSPA object is 258 absent, the setup priority is assumed to be 0. 260 3.5. Significance of Class-Type and TE-Class 262 To ensure coherent DS-TE operation, a PCE and a PCC should have a 263 common understanding of a particular DS-TE classtype and TE-Class. 264 If a path computation request crosses an AS boundary, these should 265 have global significance in all domains. Enforcement of this global 266 significance is outside the scope of this document. 268 3.6. Error Codes for CLASSTYPE Object 270 This document defines the following error type and values: 272 Error-Type Meaning 274 12 Diff-Serve aware TE Error 275 Error-value=1: unsupported class-type. 276 Error-value=2: invalid class-type. 277 Error-value=3: class-type and setup priority does not 278 form a configured TE class. 280 4. Security Considerations 282 This document does not introduce new security issues. The security 283 considerations pertaining to PCEP [PCEP-ID] remain relevant. 285 5. IANA Considerations 287 IANA maintains a registry of parameters for PCEP. This contains a 288 sub-registry for PCEP objects. IANA is requested to make new 289 allocation from this registry as follows: 291 Object-Class Name Reference 293 22 CLASSTYPE draft-ietf-pce-dste-02.txt 295 Object-Type 297 1: Class Type draft-ietf-pce-dste-02.txt 299 IANA is requested to make new allocation for error types and values 300 as follows: 302 Error-Type Meaning Reference 304 12 Diff-Serv aware TE error draft-ietf-pce-dste-02.txt 306 Error-value = 1: draft-ietf-pce-dste-02.txt 308 Unsupported class-type 310 Error-value = 2: draft-ietf-pce-dste-02.txt 312 Invalid class-type 314 Error-value = 3: draft-ietf-pce-dste-02.txt 316 Class type and setup priority 318 does not form a configured TE class 320 6. Acknowledgments 322 The authors would like to thank Jean Philippe Vasseur, Adrian 323 Farrel and Zafar Ali for their valuable comments. 325 References 327 6.1. Normative References 329 [RFC4124] Le Faucheur, F. and W. Lai, "Protocol Extensions for 330 Support of Diffserv-aware MPLS Traffic Engineering", RFC 331 4124, June 2005. 333 [PCEP-ID] Path Computation Element (PCE) communication Protocol 334 (PCEP)", draft-ietf-pce-pcep-18.txt (work in progress), 335 November 2008. 337 6.2. Informative References 339 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 340 Communication Protocol Generic Requirements", RFC 4657, 341 September 2006. 343 [RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of 344 Differentiated Services-aware MPLS Traffic Engineering", 345 RFC 3564, July 2003. 347 [OBJ-ORD] Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used 348 in Various Protocol Specifications", draft-farrel-rtg- 349 common-bnf-07.txt, November 2008. 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 368 Sami Boutros 369 Cisco Systems, Inc. 370 3750 Cisco Way 371 San Jose, California 95134 372 USA 374 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 383 Intellectual Property Statement 385 The IETF takes no position regarding the validity or scope of any 386 Intellectual Property Rights or other rights that might be claimed to 387 pertain to the implementation or use of the technology described in 388 this document or the extent to which any license under such rights 389 might or might not be available; nor does it represent that it has 390 made any independent effort to identify any such rights. Information 391 on the procedures with respect to rights in RFC documents can be 392 found in BCP 78 and BCP 79. 394 Copies of IPR disclosures made to the IETF Secretariat and any 395 assurances of licenses to be made available, or the result of an 396 attempt made to obtain a general license or permission for the use of 397 such proprietary rights by implementers or users of this 398 specification can be obtained from the IETF on-line IPR repository at 399 http://www.ietf.org/ipr. 401 The IETF invites any interested party to bring to its attention any 402 copyrights, patents or patent applications, or other proprietary 403 rights that may cover technology that may be required to implement 404 this standard. Please address the information to the IETF at 405 ietf-ipr@ietf.org. 407 Disclaimer of Validity 409 This document and the information contained herein are provided on an 410 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 411 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 412 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 413 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 414 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 415 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 417 Copyright Statement 419 Copyright (C) The IETF Trust (2008). 421 This document is subject to the rights, licenses and restrictions 422 contained in BCP 78, and except as set forth therein, the authors 423 retain all their rights. 425 Acknowledgment 427 Funding for the RFC Editor function is currently provided by the 428 Internet Society.