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