idnits 2.17.1 draft-ietf-tewg-diff-te-proto-08.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.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1742. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1370. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1385. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1748), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 1467. ** Found boilerplate matching RFC 3978, Section 5.5 (on line 1742), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 4 text on line 1494. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 35 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The abstract seems to contain references ([RFC2119], [ISIS-TE]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3978, Section 5.5 boilerplate, a section with a similar start was also found: This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. == 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 (December 2004) is 7062 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 section? 'ISIS-TE' on line 1404 looks like a reference -- Missing reference section? 'RFC2119' on line 1415 looks like a reference -- Missing reference section? 'DSTE-REQ' on line 1547 looks like a reference -- Missing reference section? 'OSPF-TE' on line 1401 looks like a reference -- Missing reference section? 'RSVP-TE' on line 1407 looks like a reference -- Missing reference section? 'DSTE-RDM' on line 1423 looks like a reference -- Missing reference section? 'DSTE-MAM' on line 1429 looks like a reference -- Missing reference section? 'DSTE-MAR' on line 1433 looks like a reference -- Missing reference section? 'MPLS-ARCH' on line 1392 looks like a reference -- Missing reference section? 'TE-REQ' on line 1398 looks like a reference -- Missing reference section? '0' on line 684 looks like a reference -- Missing reference section? '1' on line 526 looks like a reference -- Missing reference section? '2' on line 527 looks like a reference -- Missing reference section? '3' on line 528 looks like a reference -- Missing reference section? '7' on line 685 looks like a reference -- Missing reference section? 'DIFF-MPLS' on line 1413 looks like a reference -- Missing reference section? 'RSVP' on line 1410 looks like a reference -- Missing reference section? 'GMPLS-SIG' on line 1437 looks like a reference -- Missing reference section? 'GMPLS-ROUTE' on line 1440 looks like a reference -- Missing reference section? 'HIERARCHY' on line 1447 looks like a reference -- Missing reference section? 'BUNDLE' on line 1444 looks like a reference -- Missing reference section? 'REROUTE' on line 1450 looks like a reference -- Missing reference section? 'N' on line 1045 looks like a reference -- Missing reference section? 'DIFF-ARCH' on line 1395 looks like a reference -- Missing reference section? 'IANA-CONS' on line 1418 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 32 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEWG 3 Internet Draft Francois Le Faucheur 4 Editor 5 Document: draft-ietf-tewg-diff-te-proto-08.txt Cisco Systems, 6 Inc. 7 Expires: June 2005 December 2004 9 Protocol extensions for support of 10 Differentiated-Service-aware MPLS Traffic Engineering 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on June 13, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). All Rights Reserved. 43 Abstract 45 This document specifies the protocol extensions for support of 46 Differentiated-Service-aware MPLS Traffic Engineering (DS-TE). This 47 includes generalization of the semantic of a number of IGP extensions 49 Protocols for Diffserv-aware TE December 2004 51 already defined for existing MPLS Traffic Engineering in RFC3630 and 52 RFC-TBD as well as additional IGP extensions beyond those. This also 53 includes extensions to RSVP-TE signaling beyond those already 54 specified in RFC3209 for existing MPLS Traffic Engineering. These 55 extensions address the Requirements for DS-TE spelt out in RFC3564. 57 To be removed by the RFC editor at the time of 58 publication: Please replace "TBD" above by the actual RFC 59 number when 60 an RFC number is allocated to [ISIS-TE] 61 63 Specification of Requirements 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in [RFC2119]. 69 Table of Contents 71 1. Introduction...................................................3 72 2. Contributing Authors...........................................4 73 3. Definitions....................................................5 74 4. Configurable Parameters........................................5 75 4.1. Link Parameters...........................................5 76 4.1.1. Bandwidth Constraints (BCs) 5 77 4.1.2. Overbooking6 78 4.2. LSR Parameters............................................6 79 4.2.1. TE-Class Mapping 7 80 4.3. LSP Parameters............................................8 81 4.3.1. Class-Type 8 82 4.3.2. Setup and Holding Preemption Priorities 8 83 4.3.3. Class-Type/Preemption Relationship 8 84 4.4. Examples of Parameters Configuration......................8 85 4.4.1. Example 1 8 86 4.4.2. Example 2 9 87 4.4.3. Example 3 10 88 4.4.4. Example 4 10 89 4.4.5. Example 5 11 90 5. IGP Extensions for DS-TE......................................11 91 5.1. Bandwidth Constraints....................................11 92 5.2. Unreserved Bandwidth.....................................14 93 6. RSVP-TE Extensions for DS-TE..................................15 94 6.1. DS-TE related RSVP Messages Format.......................15 95 6.1.1. Path Message Format 15 96 6.2. CLASSTYPE Object.........................................16 97 6.2.1. CLASSTYPE object 16 98 6.3. Handling CLASSTYPE Object................................16 99 6.4. Non-support of the CLASSTYPE Object......................19 101 Protocols for Diffserv-aware TE December 2004 103 6.5. Error Codes For Diff-Serv-aware TE.......................19 104 7. DS-TE support with MPLS extensions............................20 105 7.1. DS-TE support and references to preemption priority......21 106 7.2. DS-TE support and references to Maximum Reservable Bandwidth 107 ..............................................................21 108 8. Constraint Based Routing......................................21 109 9. Diff-Serv scheduling..........................................22 110 10. Existing TE as a Particular Case of DS-TE....................22 111 11. Computing "Unreserved TE-Class [i]" and Admission Control Rules22 112 11.1. Computing "Unreserved TE-Class [i]".....................23 113 11.2. Admission Control Rules.................................23 114 12. Security Considerations......................................24 115 13. Acknowledgments..............................................24 116 14. IANA Considerations..........................................24 117 14.1. A new name space for Bandwidth Constraints Model Identifiers 118 ..............................................................24 119 14.2. A new name space for Error Values under the "Diff-Serv-aware 120 TE Error".....................................................24 121 14.3. Assignments made in this Document.......................25 122 14.3.1. Bandwidth Constraints sub-TLV for OSPF version 2 25 123 14.3.2. Bandwidth Constraints sub-TLV for ISIS 25 124 14.3.3. CLASSTYPE object for RSVP26 125 14.3.4. "Diff-Serv-aware TE Error" Error Code26 126 14.3.5. Error Values for "Diff-Serv-aware TE Error"26 127 15. Intellectual Property Considerations.........................27 128 16. Normative References.........................................28 129 17. Informative References.......................................28 130 18. Editor's Address:............................................29 131 19. Full Copyright Statement.....................................29 132 Appendix A - Prediction for Multiple Path Computation............30 133 Appendix B - Solution Evaluation.................................31 134 Appendix C - Interoperability with non DS-TE capable LSRs........32 135 Disclaimer of Validity...........................................35 136 Copyright Statement..............................................35 137 Acknowledgment...................................................35 139 1.Introduction 141 [DSTE-REQ] presents the Service Providers requirements for support of 142 Differentiated-Service (Diff-Serv)-aware MPLS Traffic Engineering 143 (DS-TE). This includes the fundamental requirement to be able to 144 enforce different bandwidth constraints for different classes of 145 traffic. 147 This document specifies the IGP and RSVP-TE signaling extensions 148 (beyond those already specified for existing MPLS Traffic Engineering 149 [OSPF-TE][ISIS-TE][RSVP-TE]) for support of the DS-TE requirements 150 spelled out in [DSTE-REQ] including environments relying on 152 Protocols for Diffserv-aware TE December 2004 154 distributed Constraint Based Routing (e.g. path computation involving 155 Head-end LSRs). 157 [DSTE-REQ] provides a definition and examples of Bandwidth 158 Constraints Models. The present document does not specify nor assume 159 a particular Bandwidth Constraints model. Specific Bandwidth 160 Constraints model are outside the scope of this document. While the 161 extensions for DS-TE specified in this document may not be sufficient 162 to support all the conceivable Bandwidth Constraints models, they do 163 support the "Russian Dolls" Model specified in [DSTE-RDM], the 164 "Maximum Allocation" Model specified in [DSTE-MAM] and the "Maximum 165 Allocation with Reservation" Model specified in [DSTE-MAR]. 167 There may be differences between the quality of service expressed and 168 obtained with Diffserv without DS-TE and with DS-TE. Because DS-TE 169 uses Constraint Based Routing, and because of the type of admission 170 control capabilities it adds to Diffserv, DS-TE has capabilities for 171 traffic that Diffserv does not: Diffserv does not indicate 172 preemption, by intent, whereas DS-TE describes multiple levels of 173 preemption for its Class Types. Also, Diffserv does not support any 174 means of explicitly controlling overbooking, while DS-TE allows this. 175 When considering a complete quality of service environment, with 176 Diffserv routers and DS-TE, it is important to consider these 177 differences carefully. 179 2.Contributing Authors 181 This document was the collective work of several. The text and 182 content of this document was contributed by the editor and the co- 183 authors listed below. (The contact information for the editor appears 184 in Section 18, and is not repeated below.) 186 Jim Boyle Kireeti Kompella 187 Protocol Driven Networks, Inc. Juniper Networks, Inc. 188 1381 Kildaire Farm Road #288 1194 N. Mathilda Ave. 189 Cary, NC 27511, USA Sunnyvale, CA 94099 190 Phone: (919) 852-5160 Email: kireeti@juniper.net 191 Email: jboyle@pdnets.com 193 William Townsend Thomas D. Nadeau 194 Tenor Networks Cisco Systems, Inc. 195 100 Nagog Park 250 Apollo Drive 196 Acton, MA 01720 Chelmsford, MA 01824 197 Phone: +1-978-264-4900 Phone: +1-978-244-3051 198 Email: Email: tnadeau@cisco.com 199 btownsend@tenornetworks.com 201 Darek Skalecki 202 Nortel Networks 204 Protocols for Diffserv-aware TE December 2004 206 3500 Carling Ave, 207 Nepean K2H 8E9 208 Phone: +1-613-765-2252 209 Email: dareks@nortelnetworks.com 211 3.Definitions 213 For readability a number of definitions from [DSTE-REQ] are repeated 214 here: 216 Traffic Trunk: an aggregation of traffic flows of the same class 217 [i.e. which are to be treated equivalently from the DS-TE 218 perspective] which are placed inside a Label Switched Path. 220 Class-Type (CT): the set of Traffic Trunks crossing a link that is 221 governed by a specific set of Bandwidth constraints. CT is used for 222 the purposes of link bandwidth allocation, constraint based routing 223 and admission control. A given Traffic Trunk belongs to the same CT 224 on all links. 226 TE-Class: A pair of: 227 i. a Class-Type 228 ii. a preemption priority allowed for that Class-Type. This 229 means that an LSP transporting a Traffic Trunk from 230 that Class-Type can use that preemption priority as the 231 set-up priority, as the holding priority or both. 233 Definitions for a number of MPLS terms are not repeated here. Those 234 can be found in [MPLS-ARCH]. 236 4.Configurable Parameters 238 This section only discusses the differences with the configurable 239 parameters supported for MPLS Traffic Engineering as per [TE-REQ], 240 [ISIS-TE], [OSPF-TE], and [RSVP-TE]. All other parameters are 241 unchanged. 243 4.1.Link Parameters 245 4.1.1.Bandwidth Constraints (BCs) 247 [DSTE-REQ] states that "Regardless of the Bandwidth Constraints 248 Model, the DS-TE solution MUST allow support for up to 8 BCs." 250 For DS-TE, the existing "Maximum Reservable link bandwidth" parameter 251 is retained but its semantic is generalized and interpreted as the 253 Protocols for Diffserv-aware TE December 2004 255 aggregate bandwidth constraints across all Class-Types, so that, 256 independently of the Bandwidth Constraints Model in use: 257 SUM (Reserved (CTc)) <= Max Reservable Bandwidth, 258 where the SUM is across all values of "c" in the range 0 <= c <= 7. 260 Additionally, on every link, a DS-TE implementation MUST provide for 261 configuration of up to 8 additional link parameters which are the 262 eight potential Bandwidth Constraints i.e. BC0, BC1 , ... BC7. The 263 LSR MUST interpret these Bandwidth Constraints in accordance with the 264 supported Bandwidth Constraints Model (i.e. what bandwidth constraint 265 applies to what Class-Type and how). 267 Where the Bandwidth Constraints Model imposes some relationship among 268 the values to be configured for these Bandwidth Constraints, the LSR 269 MUST enforce those at configuration time. For example, when the 270 "Russian Doll" Bandwidth Constraints Model ([DSTE-RDM]) is used, the 271 LSR MUST ensure that BCi is configured smaller or equal to BCj, where 272 i is greater than j, and ensure that BC0 is equal to the Maximum 273 Reservable Bandwidth. As another example, when the Maximum Allocation 274 Model ([DSTE-MAM]) is used, the LSR MUST ensure that all BCi are 275 configured smaller or equal to the Maximum Reservable Bandwidth. 277 4.1.2.Overbooking 279 DS-TE enables a network administrator to apply different overbooking 280 (or underbooking) ratios for different CTs. 282 The principal methods to achieve this are the same as historically 283 used in existing TE deployment, which are : 284 (i) To take into account the overbooking/underbooking ratio 285 appropriate for the OA/CT associated with the considered LSP 286 at the time of establishing the bandwidth size of a given 287 LSP. We refer to this method as the "LSP Size Overbooking 288 method". AND/OR 289 (ii) To take into account the overbooking/underbooking ratio at 290 the time of configuring the Maximum Reservable 291 Bandwidth/Bandwidth Constraints and use values which are 292 larger(overbooking) or smaller(underbooking) than actually 293 supported by the link. We refer to this method as the "Link 294 Size Overbooking method". 296 The "LSP Size Overbooking" method and the "Link Size Overbooking" 297 method are expected to be sufficient in many DS-TE environments and 298 require no additional configurable parameters. Other overbooking 299 methods may involve such additional configurable parameters but are 300 beyond the scope of this document. 302 4.2.LSR Parameters 304 Protocols for Diffserv-aware TE December 2004 306 4.2.1.TE-Class Mapping 308 In line with [DSTE-REQ], the preemption attributes defined in [TE- 309 REQ] are retained with DS-TE and applicable within, and across, all 310 Class Types. The preemption attributes of setup priority and holding 311 priority retain existing semantics, and in particular these semantics 312 are not affected by the LSP Class Type. This means that if LSP1 313 contends with LSP2 for resources, LSP1 may preempt LSP2 if LSP1 has a 314 higher set-up preemption priority (i.e. lower numerical priority 315 value) than LSP2 holding preemption priority regardless of LSP1 CT 316 and LSP2 CT. 318 DS-TE LSRs MUST allow configuration of a TE-Class mapping whereby the 319 Class-Type and preemption level are configured for each of (up to) 8 320 TE-Classes. 322 This mapping is referred to as : 324 TE-Class[i] <--> < CTc , preemption p > 326 Where 0 <= i <= 7, 0 <= c <= 7, 0 <= p <= 7 328 Two TE-Classes MUST NOT be identical (i.e. have both the same Class- 329 Type and the same preemption priority). 331 There are no other restrictions on how any of the 8 Class-Types can 332 be paired up with any of the 8 preemption priorities to form a TE- 333 class. In particular, one given preemption priority can be paired up 334 with two (or more) different Class-Types to form two (or more) TE- 335 classes. Similarly, one Class-Type can be paired up with two (or 336 more) different preemption priorities to form two (or more) TE- 337 Classes. Also, there is no mandatory ordering relationship between 338 the TE-Class index (i.e. "i" above) and the Class-Type (i.e. "c" 339 above) or the preemption priority (i.e. "p" above) of the TE-Class. 341 Where the network administrator uses less than 8 TE-Classes, the DS- 342 TE LSR MUST allow remaining ones to be configured as "Unused". Note 343 that "Configuring all the 8 TE-Classes as "Unused" effectively 344 results in disabling TE/DS-TE since no TE/DS-TE LSP can be 345 established (nor even configured, since as described in section 4.3.3 346 below, the CT and preemption priorities configured for an LSP MUST 347 form one of the configured TE-Classes)". 349 To ensure coherent DS-TE operation, the network administrator MUST 350 configure exactly the same TE-Class Mapping on all LSRs of the DS-TE 351 domain. 353 When the TE-class mapping needs to be modified in the DS-TE domain, 354 care ought to be exercised during the transient period of 355 reconfiguration during which some DS-TE LSRs may be configured with 357 Protocols for Diffserv-aware TE December 2004 359 the new TE-class mapping while others are still configured with the 360 old TE-class mapping. It is recommended that active tunnels do not 361 use any of the TE-classes which are being modified during such a 362 transient reconfiguration period. 364 4.3.LSP Parameters 366 4.3.1.Class-Type 368 With DS-TE, LSRs MUST support, for every LSP, an additional 369 configurable parameter which indicates the Class-Type of the Traffic 370 Trunk transported by the LSP. 372 There is one and only one Class-Type configured per LSP. 374 The configured Class-Type indicates, in accordance with the supported 375 Bandwidth Constraints Model, the Bandwidth Constraints that MUST be 376 enforced for that LSP. 378 4.3.2.Setup and Holding Preemption Priorities 380 As per existing TE, DS-TE LSRs MUST allow every DS-TE LSP to be 381 configured with a setup and holding priority, each with a value 382 between 0 and 7. 384 4.3.3.Class-Type/Preemption Relationship 386 With DS-TE, the preemption priority configured for the setup priority 387 of a given LSP and the Class-Type configured for that LSP MUST be 388 such that, together, they form one of the (up to) 8 TE-Classes 389 configured in the TE-Class Mapping specified in section 4.2.1 above. 391 The preemption priority configured for the holding priority of a 392 given LSP and the Class-Type configured for that LSP MUST also be 393 such that, together, they form one of the (up to) 8 TE-Classes 394 configured in the TE-Class Mapping specified in section 4.2.1 above. 396 The LSR MUST enforce these two rules at configuration time. 398 4.4.Examples of Parameters Configuration 400 For illustrative purposes, we now present a few examples of how these 401 configurable parameters may be used. All these examples assume that 402 different bandwidth constraints need to be enforced for different 403 sets of Traffic Trunks (e.g. for Voice and for Data) so that two, or 404 more, Class-Types need to be used. 406 4.4.1.Example 1 408 Protocols for Diffserv-aware TE December 2004 410 The Network Administrator of a first network using two Class Types 411 (CT1 for Voice and CT0 for Data), may elect to configure the 412 following TE-Class Mapping to ensure that Voice LSPs are never driven 413 away from their shortest path because of Data LSPs: 415 TE-Class[0] <--> < CT1 , preemption 0 > 416 TE-Class[1] <--> < CT0 , preemption 1 > 417 TE-Class[i] <--> unused, for 2 <= i <= 7 419 Voice LSPs would then be configured with: 420 - CT=CT1, set-up priority =0, holding priority=0 422 Data LSPs would then be configured with: 423 - CT=CT0, set-up priority =1, holding priority=1 425 A new Voice LSP would then be able to preempt an existing Data LSP in 426 case they contend for resources. A Data LSP would never preempt a 427 Voice LSP. A Voice LSP would never preempt another Voice LSP. A Data 428 LSP would never preempt another Data LSP. 430 4.4.2.Example 2 432 The Network Administrator of another network may elect to configure 433 the following TE-Class Mapping in order to optimize global network 434 resource utilization by favoring placement of large LSPs closer to 435 their shortest path: 437 TE-Class[0] <--> < CT1 , preemption 0 > 438 TE-Class[1] <--> < CT0 , preemption 1 > 439 TE-Class[2] <--> < CT1 , preemption 2 > 440 TE-Class[3] <--> < CT0 , preemption 3 > 441 TE-Class[i] <--> unused, for 4 <= i <= 7 443 Large size Voice LSPs could be configured with: 444 - CT=CT1, set-up priority =0, holding priority=0 446 Large size Data LSPs could be configured with: 447 - CT=CT0, set-up priority = 1, holding priority=1 449 Small size Voice LSPs could be configured with: 450 - CT=CT1, set-up priority = 2, holding priority=2 452 Small size Data LSPs could be configured with: 453 - CT=CT0, set-up priority = 3, holding priority=3. 455 A new large size Voice LSP would then be able to preempt a small size 456 Voice LSP or any Data LSP in case they contend for resources. 457 A new large size Data LSP would then be able to preempt a small size 458 Data LSP or a small size Voice LSP in case they contend for 460 Protocols for Diffserv-aware TE December 2004 462 resources, but it would not be able to preempt a large size Voice 463 LSP. 465 4.4.3.Example 3 467 The Network Administrator of another network may elect to configure 468 the following TE-Class Mapping in order to ensure that Voice LSPs are 469 never driven away from their shortest path because of Data LSPs while 470 also achieving some optimization of global network resource 471 utilization by favoring placement of large LSPs closer to their 472 shortest path: 474 TE-Class[0] <--> < CT1 , preemption 0 > 475 TE-Class[1] <--> < CT1 , preemption 1 > 476 TE-Class[2] <--> < CT0 , preemption 2 > 477 TE-Class[3] <--> < CT0 , preemption 3 > 478 TE-Class[i] <--> unused, for 4 <= i <= 7 480 Large size Voice LSPs could be configured with: 481 - CT=CT1, set-up priority = 0, holding priority=0. 483 Small size Voice LSPs could be configured with: 484 - CT=CT1, set-up priority = 1, holding priority=1. 486 Large size Data LSPs could be configured with: 487 - CT=CT0, set-up priority = 2, holding priority=2. 489 Small size Data LSPs could be configured with: 490 - CT=CT0, set-up priority = 3, holding priority=3. 492 A Voice LSP could preempt a Data LSP if they contend for resources. A 493 Data LSP would never preempt a Voice LSP. A Large size Voice LSP 494 could preempt a small size Voice LSP if they contend for resources. A 495 Large size Data LSP could preempt a small size Data LSP if they 496 contend for resources. 498 4.4.4.Example 4 500 The Network Administrator of another network may elect to configure 501 the following TE-Class Mapping in order to ensure that no preemption 502 occurs in the DS-TE domain: 504 TE-Class[0] <--> < CT1 , preemption 0 > 505 TE-Class[1] <--> < CT0 , preemption 0 > 506 TE-Class[i] <--> unused, for 2 <= i <= 7 508 Voice LSPs would then be configured with: 509 - CT=CT1, set-up priority =0, holding priority=0 511 Data LSPs would then be configured with: 513 Protocols for Diffserv-aware TE December 2004 515 - CT=CT0, set-up priority =0, holding priority=0 517 No LSP would then be able to preempt any other LSP. 519 4.4.5.Example 5 521 The Network Administrator of another network may elect to configure 522 the following TE-Class Mapping in view of increased network stability 523 through a more limited use of preemption: 525 TE-Class[0] <--> < CT1 , preemption 0 > 526 TE-Class[1] <--> < CT1 , preemption 1 > 527 TE-Class[2] <--> < CT0 , preemption 1 > 528 TE-Class[3] <--> < CT0 , preemption 2 > 529 TE-Class[i] <--> unused, for 4 <= i <= 7 531 Large size Voice LSPs could be configured with: 532 - CT=CT1, set-up priority = 0, holding priority=0. 534 Small size Voice LSPs could be configured with: 535 - CT=CT1, set-up priority = 1, holding priority=0. 537 Large size Data LSPs could be configured with: 538 - CT=CT0, set-up priority = 2, holding priority=1. 540 Small size Data LSPs could be configured with: 541 - CT=CT0, set-up priority = 2, holding priority=2. 543 A new large size Voice LSP would be able to preempt a Data LSP in 544 case they contend for resources, but it would not be able to preempt 545 any Voice LSP even a small size Voice LSP. 547 A new small size Voice LSP would be able to preempt a small size Data 548 LSP in case they contend for resources, but it would not be able to 549 preempt a large size Data LSP or any Voice LSP. 551 A Data LSP would not be able to preempt any other LSP. 553 5.IGP Extensions for DS-TE 555 This section only discusses the differences with the IGP 556 advertisement supported for (aggregate) MPLS Traffic Engineering as 557 per [OSPF-TE] and [ISIS-TE]. The rest of the IGP advertisement is 558 unchanged. 560 5.1.Bandwidth Constraints 562 As detailed above in section 4.1.1, up to 8 Bandwidth Constraints 563 ( BCb, 0 <= b <= 7) are configurable on any given link. 565 Protocols for Diffserv-aware TE December 2004 567 With DS-TE, the existing "Maximum Reservable Bandwidth" sub-TLV 568 ([OSPF-TE], [ISIS-TE]) is retained with a generalized semantic so 569 that it MUST now be interpreted as the aggregate bandwidth constraint 570 across all Class-Types [ i.e. 571 SUM (Reserved (CTc)) <= Max Reservable Bandwidth], independently of 572 the Bandwidth Constraints Model. 574 This document also defines the following new optional sub-TLV to 575 advertise the eight potential Bandwidth Constraints (BC0 to BC7): 577 "Bandwidth Constraints" sub-TLV: 578 - Bandwidth Constraints Model Id (1 octet) 579 - Reserved (3 octets) 580 - Bandwidth Constraints (Nx4 octets) 582 Where: 584 - With OSPF, the sub-TLV is a sub-TLV of the "Link TLV" and its 585 sub-TLV type is TBD 587 - With ISIS, the sub-TLV is a sub-TLV of the "extended IS 588 reachability TLV" and its sub-TLV type is TBD (). 590 To be removed by the RFC editor at the time of 591 publication: When the sub-TLV numbers are allocated by IANA 592 for OSPF and ISIS, replace "TBD" in the two bullet points above by 593 the respective assigned value. See IANA Considerations section for 594 allocation request. 595 596 - Bandwidth Constraints Model Id: 1 octet identifier for the 597 Bandwidth Constraints Model currently in use by the LSR 598 initiating the IGP advertisement. See the IANA Considerations 599 section below for assignment of values in this name space. 601 - Reserved: a 3-octet field. This field should be set to zero 602 by the LSR generating the sub-TLV and should be ignored by 603 the LSR receiving the sub-TLV. 605 - Bandwidth Constraints: contains BC0, BC1,... BC(N-1). 606 Each Bandwidth Constraint is encoded on 32 bits in IEEE 607 floating point format. The units are bytes (not bits!) per 608 second. Where the configured TE-class mapping and the 609 Bandwidth Constraints model in use are such that BCh+1, 610 BCh+2, ...and BC7 are not relevant to any of the Class-Types 611 associated with a configured TE-class, it is RECOMMENDED that 612 only the Bandwidth Constraints from BC0 to BCh be advertised, 613 in order to minimize the impact on IGP scalability. 615 Protocols for Diffserv-aware TE December 2004 617 All relevant generic TLV encoding rules (including TLV format, 618 padding and alignment, as well as IEEE floating point format 619 encoding) defined in [OSPF-TE] and [ISIS-TE] are applicable to this 620 new sub-TLV. 622 The "Bandwidth Constraints" sub-TLV format is illustrated below: 624 0 1 2 3 625 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 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | BC Model Id | Reserved | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | BC0 value | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 // . . . // 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | BCh value | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 A DS-TE LSR MAY optionally advertise Bandwidth Constraints. 638 A DS-TE LSR which does advertise Bandwidth Constraints MUST use the 639 new "Bandwidth Constraints" sub-TLV (in addition to the existing 640 Maximum Reservable Bandwidth sub-TLV) to do so. For example, 641 considering the case where a Service Provider deploys DS-TE with 642 TE-classes associated with CT0 and CT1 only, and where the Bandwidth 643 Constraints Model is such that only BC0 and BC1 are relevant to CT0 644 and CT1: a DS-TE LSR which does advertise Bandwidth Constraints would 645 include in the IGP advertisement the Maximum Reservable Bandwidth 646 sub-TLV as well as the "Bandwidth Constraints" sub-TLV, where the 647 former should contain the aggregate bandwidth constraint across all 648 CTs and the latter would contain BC0 and BC1. 650 A DS-TE LSR receiving the "Bandwidth Constraints" sub-TLV with a 651 Bandwidth Constraints Model Id which does not match the Bandwidth 652 Constraints Model it currently uses, SHOULD generate a warning to the 653 operator/management-system reporting the inconsistency between 654 Bandwidth Constraints Models used on different links. Also, in that 655 case, if the DS-TE LSR does not support the Bandwidth Constraints 656 Model designated by the Bandwidth Constraints Model Id, or if the DS- 657 TE LSR does not support operations with multiple simultaneous 658 Bandwidth Constraints Models, the DS-TE LSR MAY discard the 659 corresponding TLV. If the DS-TE LSR does support the Bandwidth 660 Constraints Model designated by the Bandwidth Constraints Model Id 661 and if the DS-TE LSR does support operations with multiple 662 simultaneous Bandwidth Constraints Models, the DS-TE LSR MAY accept 663 the corresponding TLV and allow operations with different Bandwidth 664 Constraints Models used in different parts of the DS-TE domain. 666 Protocols for Diffserv-aware TE December 2004 668 5.2.Unreserved Bandwidth 670 With DS-TE, the existing "Unreserved Bandwidth" sub-TLV is retained 671 as the only vehicle to advertise dynamic bandwidth information 672 necessary for Constraint Based Routing on Head-ends, except that it 673 is used with a generalized semantic. The Unreserved Bandwidth sub-TLV 674 still carries eight bandwidth values but they now correspond to the 675 unreserved bandwidth for each of the TE-Class (instead of for each 676 preemption priority as per existing TE). 678 More precisely, a DS-TE LSR MUST support the Unreserved Bandwidth 679 sub-TLV with a definition which is generalized into the following: 681 The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth 682 not yet reserved for each of the eight TE-classes, in IEEE floating 683 point format arranged in increasing order of TE-Class index, with 684 unreserved bandwidth for TE-Class [0] occurring at the start of the 685 sub-TLV, and unreserved bandwidth for TE-Class [7] at the end of the 686 sub-TLV. The unreserved bandwidth value for TE-Class [i] ( 0 <= i <= 687 7) is referred to as "Unreserved TE-Class [i]". It indicates the 688 bandwidth that is available, for reservation, to an LSP which : 689 - transports a Traffic Trunk from the Class-Type of TE- 690 Class[i], and 691 - has a setup priority corresponding to the preemption priority 692 of TE-Class[i]. 694 The units are bytes per second. 696 Since the bandwidth values are now ordered by TE-class index and thus 697 can relate to different CTs with different bandwidth constraints and 698 can relate to any arbitrary preemption priority, a DS-TE LSR MUST NOT 699 assume any ordered relationship among these bandwidth values. 701 With existing TE, since all preemption priorities reflect the same 702 (and only) bandwidth constraints and since bandwidth values are 703 advertised in preemption priority order, the following relationship 704 is always true, and is often assumed by TE implementations: 706 If i < j , then "Unreserved Bw [i]" >= "Unreserved Bw [j]" 708 With DS-TE, no relationship is to be assumed so that: 709 If i < j , then any of the following relationship may be true 710 "Unreserved TE-Class [i]" = "Unreserved TE-Class [j]" 711 OR 712 "Unreserved TE-Class [i]" > "Unreserved TE-Class [j]" 713 OR 714 "Unreserved TE-Class [i]" < "Unreserved TE-Class [j]". 716 Rules for computing "Unreserved TE-Class [i]" are specified in 717 section 11. 719 Protocols for Diffserv-aware TE December 2004 721 If TE-Class[i] is unused, the value advertised by the IGP in 722 "Unreserved TE-Class [i]" MUST be set to zero by the LSR generating 723 the IGP advertisement, and MUST be ignored by the LSR receiving the 724 IGP advertisement. 726 6.RSVP-TE Extensions for DS-TE 728 In this section we describe extensions to RSVP-TE for support of 729 Diff-Serv-aware MPLS Traffic Engineering. These extensions are in 730 addition to the extensions to RSVP defined in [RSVP-TE] for support 731 of (aggregate) MPLS Traffic Engineering and to the extensions to RSVP 732 defined in [DIFF-MPLS] for support of Diff-Serv over MPLS. 734 6.1.DS-TE related RSVP Messages Format 736 One new RSVP Object is defined in this document: the CLASSTYPE 737 Object. Detailed description of this Object is provided below. This 738 new Object is applicable to Path messages. This specification only 739 defines the use of the CLASSTYPE Object in Path messages used to 740 establish LSP Tunnels in accordance with [RSVP-TE] and thus 741 containing a Session Object with a C-Type equal to LSP_TUNNEL_IPv4 742 and containing a LABEL_REQUEST object. 744 Restrictions defined in [RSVP-TE] for support of establishment of LSP 745 Tunnels via RSVP-TE are also applicable to the establishment of LSP 746 Tunnels supporting DS-TE. For instance, only unicast LSPs are 747 supported and Multicast LSPs are for further study. 749 This new CLASSTYPE object is optional with respect to RSVP so that 750 general RSVP implementations not concerned with MPLS LSP set up do 751 not have to support this object. 753 An LSR supporting DS-TE MUST support the CLASSTYPE Object. 755 6.1.1.Path Message Format 757 The format of the Path message is as follows: 759 ::= [ ] 760 761 762 [ ] 763 764 [ ] 765 [ ] 766 [ ] 767 [ ... ] 768 [ ] 770 Protocols for Diffserv-aware TE December 2004 772 ::= [ ] 773 [ ] 774 [ ] 776 6.2.CLASSTYPE Object 778 The CLASSTYPE object Class Name is CLASSTYPE. Its Class Number is 779 TBD. Currently, there is only one defined C_Type which is C_Type 1. 780 The CLASSTYPE object format is shown below. 782 To be removed by the RFC editor at the time of 783 publication: When the RSVP Class-Num is assigned by IANA 784 replace "TBD" 785 above by the assigned value. See IANA Considerations section 786 for allocation request. 787 789 6.2.1.CLASSTYPE object 791 Class Number = TBD 792 Class Type = 1 794 To be removed by the RFC editor at the time of 795 publication: When the RSVP Class Number is assigned by IANA 796 replace "TBD" 797 above by the assigned value. See IANA Considerations section 798 for allocation request. 799 801 0 1 2 3 802 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 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | Reserved | CT | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 Reserved : 29 bits 808 This field is reserved. It MUST be set to zero on transmission 809 and MUST be ignored on receipt. 811 CT : 3 bits 812 Indicates the Class-Type. Values currently allowed are 813 1, 2, ... , 7. Value of 0 is Reserved. 815 6.3.Handling CLASSTYPE Object 817 To establish an LSP tunnel with RSVP, the sender LSR creates a Path 818 message with a session type of LSP_Tunnel_IPv4 and with a 820 Protocols for Diffserv-aware TE December 2004 822 LABEL_REQUEST object as per [RSVP-TE]. The sender LSR may also 823 include the DIFFSERV object as per [DIFF-MPLS]. 825 If the LSP is associated with Class-Type 0, the sender LSR MUST NOT 826 include the CLASSTYPE object in the Path message. This allows 827 backward compatibility with non-DSTE-configured or non-DSTE-capable 828 LSRs as discussed below in section 10 and Appendix C. 830 If the LSP is associated with Class-Type N (1 <= N <=7), the sender 831 LSR MUST include the CLASSTYPE object in the Path message with the 832 Class-Type (CT) field set to N. 834 If a path message contains multiple CLASSTYPE objects, only the first 835 one is meaningful; subsequent CLASSTYPE object(s) MUST be ignored and 836 MUST NOT be forwarded. 838 Each LSR along the path MUST record the CLASSTYPE object, when 839 present, in its path state block. 841 If the CLASSTYPE object is not present in the Path message, the LSR 842 MUST associate the Class-Type 0 to the LSP. 844 The destination LSR responding to the Path message by sending a Resv 845 message MUST NOT include a CLASSTYPE object in the Resv message 846 (whether the Path message contained a CLASSTYPE object or not). 848 During establishment of an LSP corresponding to the Class-Type N, the 849 LSR MUST perform admission control over the bandwidth available for 850 that particular Class-Type. 852 An LSR that recognizes the CLASSTYPE object and that receives a path 853 message which: 854 - contains the CLASSTYPE object, but 855 - which does not contain a LABEL_REQUEST object or which does 856 not have a session type of LSP_Tunnel_IPv4, 857 MUST send a PathErr towards the sender with the error code "Diff- 858 Serv-aware TE Error" and an error value of "Unexpected CLASSTYPE 859 object". Those are defined below in section 6.5. 861 An LSR receiving a Path message with the CLASSTYPE object, which: 862 - recognizes the CLASSTYPE object, but 863 - does not support the particular Class-Type, 864 MUST send a PathErr towards the sender with the error code "Diff- 865 Serv-aware TE Error" and an error value of "Unsupported Class-Type". 866 Those are defined below in section 6.5. 868 An LSR receiving a Path message with the CLASSTYPE object, which: 869 - recognizes the CLASSTYPE object, but 870 - determines that the Class-Type value is not valid (i.e. 871 Class-Type value 0), 873 Protocols for Diffserv-aware TE December 2004 875 MUST send a PathErr towards the sender with the error code "Diff- 876 Serv-aware TE Error" and an error value of "Invalid Class-Type 877 value". Those are defined below in section 6.5. 879 An LSR receiving a Path message with the CLASSTYPE object, which: 880 - recognizes the CLASSTYPE object, 881 - supports the particular Class-Type, but 882 - determines that the tuple formed by (i) this Class-Type and 883 (ii) the set-up priority signaled in the same Path message, 884 is not one of the eight TE-classes configured in the TE-class 885 mapping, 886 MUST send a PathErr towards the sender with the error code "Diff- 887 Serv-aware TE Error" and an error value of "CT and setup priority do 888 not form a configured TE-Class". Those are defined below in section 889 6.5. 891 An LSR receiving a Path message with the CLASSTYPE object, which: 892 - recognizes the CLASSTYPE object, 893 - supports the particular Class-Type, but 894 - determines that the tuple formed by (i) this Class-Type and 895 (ii) the holding priority signaled in the same Path message, 896 is not one of the eight TE-classes configured in the TE-class 897 mapping, 898 MUST send a PathErr towards the sender with the error code "Diff- 899 Serv-aware TE Error" and an error value of "CT and holding priority 900 do not form a configured TE-Class". Those are defined below in 901 section 6.5. 903 An LSR receiving a Path message with the CLASSTYPE object, which: 904 - recognizes the CLASSTYPE object, 905 - supports the particular Class-Type, but 906 - determines that the tuple formed by (i) this Class-Type and 907 (ii) the setup priority signaled in the same Path message, 908 is not one of the eight TE-classes configured in the TE-class 909 mapping, AND 910 - determines that the tuple formed by (i) this Class-Type and 911 (ii) the holding priority signaled in the same Path message, 912 is not one of the eight TE-classes configured in the TE-class 913 mapping 914 MUST send a PathErr towards the sender with the error code "Diff- 915 Serv-aware TE Error" and an error value of "CT and setup priority do 916 not form a configured TE-Class AND CT and holding priority do not 917 form a configured TE-Class". Those are defined below in section 6.5. 919 An LSR receiving a Path message with the CLASSTYPE object and with 920 the DIFFSERV object for an L-LSP, which: 921 - recognizes the CLASSTYPE object, 922 - has local knowledge of the relationship between Class-Types 923 and PSC (e.g. via configuration) 925 Protocols for Diffserv-aware TE December 2004 927 - based on this local knowledge, determines that the PSC 928 signaled in the DIFFSERV object is inconsistent with the 929 Class-Type signaled in the CLASSTYPE object, 930 MUST send a PathErr towards the sender with the error code "Diff- 931 Serv-aware TE Error" and an error value of "Inconsistency between 932 signaled PSC and signaled CT". Those are defined below in section 933 6.5. 935 An LSR receiving a Path message with the CLASSTYPE object and with 936 the DIFFSERV object for an E-LSP, which: 937 - recognizes the CLASSTYPE object, 938 - has local knowledge of the relationship between Class-Types 939 and PHBs (e.g. via configuration) 940 - based on this local knowledge, determines that the PHBs 941 signaled in the MAP entries of the DIFFSERV object are 942 inconsistent with the Class-Type signaled in the CLASSTYPE 943 object, 944 MUST send a PathErr towards the sender with the error code "Diff- 945 Serv-aware TE Error" and an error value of "Inconsistency between 946 signaled PHBs and signaled CT". Those are defined below in section 947 6.5. 949 An LSR MUST handle the situations where the LSP can not be accepted 950 for other reasons than those already discussed in this section, in 951 accordance with [RSVP-TE] and [DIFF-MPLS] (e.g. a reservation is 952 rejected by admission control, a label can not be associated). 954 6.4.Non-support of the CLASSTYPE Object 956 An LSR that does not recognize the CLASSTYPE object Class-Num MUST 957 behave in accordance with the procedures specified in [RSVP] for an 958 unknown Class-Num whose format is 0bbbbbbb (i.e. it MUST send a 959 PathErr with the error code "Unknown object class" toward the 960 sender). 962 An LSR that recognizes the CLASSTYPE object Class-Num but does not 963 recognize the CLASSTYPE object C-Type, MUST behave in accordance with 964 the procedures specified in [RSVP] for an unknown C-type (i.e. it 965 MUST send a PathErr with the error code "Unknown object C-Type" 966 toward the sender). 968 In both situations, this causes the path set-up to fail. The sender 969 SHOULD notify the operator/management-system that an LSP cannot be 970 established and possibly might take action to retry reservation 971 establishment without the CLASSTYPE object. 973 6.5.Error Codes For Diff-Serv-aware TE 975 Protocols for Diffserv-aware TE December 2004 977 In the procedures described above, certain errors are reported as a 978 "Diff-Serv-aware TE Error". The value of the "Diff-Serv-aware TE 979 Error" error code is (TBD). 981 To be removed by the RFC editor at the time of 982 publication: When the "Diff-Serv-aware TE Error" Error Code is 983 assigned by 984 IANA, replace "TBD" above by the assigned value. 985 See IANA Considerations section for allocation request. 986 987 The following defines error values for the Diff-Serv-aware TE Error: 989 Value Error 991 1 Unexpected CLASSTYPE object 992 2 Unsupported Class-Type 993 3 Invalid Class-Type value 994 4 Class-Type and setup priority do not form a configured 995 TE-Class 996 5 Class-Type and holding priority do not form a 997 configured TE-Class 998 6 Class-Type and setup priority do not form a configured 999 TE-Class AND Class-Type and holding priority do not form 1000 a configured TE-Class 1001 7 Inconsistency between signaled PSC and signaled 1002 Class-Type 1003 8 Inconsistency between signaled PHBs and signaled 1004 Class-Type 1006 See the IANA Considerations section for allocation of additional 1007 Values. 1009 7.DS-TE support with MPLS extensions. 1011 There are a number of extensions to the initial base specification 1012 for signaling [RSVP-TE] and IGP support for TE [OSPF-TE][ISIS-TE]. 1013 Those include enhancements for generalization ([GMPLS-SIG] and 1014 [GMPLS-ROUTE]), as well as for additional functionality such as LSP 1015 hierarchy [HIERARCHY], link bundling [BUNDLE] and fast restoration 1016 [REROUTE]. These specifications may reference how to encode 1017 information associated with certain preemption priorities, how to 1018 treat LSPs at different preemption priorities, or otherwise specify 1019 encodings or behavior that have a different meaning for a DS-TE 1020 router. 1022 In order for an implementation to support both this specification for 1023 Diff-Serv-aware TE and a given MPLS enhancement such as those listed 1024 above (but not limited to those), it MUST treat references to 1026 Protocols for Diffserv-aware TE December 2004 1028 "preemption priority" and to "Maximum Reservable Bandwidth" in a 1029 generalized manner, such as it is used in this specification. 1031 Additionally, current and future MPLS enhancements may include more 1032 precise specification for how they interact with Diff-Serv-aware TE. 1034 7.1.DS-TE support and references to preemption priority 1036 When a router supports both Diff-Serv-aware TE and one of the MPLS 1037 protocol extensions such as those mentioned above, encoding of values 1038 of preemption priority in signaling or encoding of information 1039 associated with preemption priorities in IGP defined for the MPLS 1040 extension, MUST be considered to be an encoding of the same 1041 information for the corresponding TE-Class. For instance, if an MPLS 1042 enhancement specifies advertisement in IGP of a parameter for routing 1043 information at preemption priority N, in a DS-TE environment it MUST 1044 actually be interpreted as specifying advertisement of the same 1045 routing information but for TE-Class [N]. On receipt, DS-TE routers 1046 MUST interpret it as such as well. 1048 When there is discussion on how to comparatively treat LSPs of 1049 different preemption priority, a DS-TE LSR MUST treat the preemption 1050 priorities in this context as the preemption priorities associated 1051 with the TE-Classes of the LSPs in question. 1053 7.2.DS-TE support and references to Maximum Reservable Bandwidth 1055 When a router supports both Diff-Serv-aware TE and MPLS protocol 1056 extensions such as those mentioned above, advertisements of Maximum 1057 Reservable Bandwidth MUST be done with the generalized interpretation 1058 defined above in section 4.1.1 as the aggregate bandwidth constraint 1059 across all Class-Types and MAY also allow the optional advertisement 1060 of all Bandwidth Constraints. 1062 8.Constraint Based Routing 1064 Let us consider the case where a path needs to be computed for an LSP 1065 whose Class-Type is configured to CTc and whose set-up preemption 1066 priority is configured to p. 1068 Then the pair of CTc and p will map to one of the TE-Classes defined 1069 in the TE-Class mapping. Let us refer to this TE-Class as TE- 1070 Class[i]. 1072 The Constraint Based Routing algorithm of a DS-TE LSR is still only 1073 required to perform path computation satisfying a single bandwidth 1074 constraint which is to fit in "Unreserved TE-Class [i]" as advertised 1075 by the IGP for every link. Thus, no changes are required to the 1076 existing TE Constraint Based Routing algorithm itself. 1078 Protocols for Diffserv-aware TE December 2004 1080 The Constraint Based Routing algorithm MAY also take into account, 1081 when used, the optional additional information advertised in IGP such 1082 as the Bandwidth Constraints and the Maximum Reservable Bandwidth. As 1083 an example, the Bandwidth Constraints MIGHT be used as a tie-breaker 1084 criteria in situations where multiple paths, otherwise equally 1085 attractive, are possible. 1087 9.Diff-Serv scheduling 1089 The Class-Type signaled at LSP establishment MAY optionally be used 1090 by DS-TE LSRs to dynamically adjust the resources allocated to the 1091 Class-Type by the Diff-Serv scheduler. In addition, the Diff-Serv 1092 information (i.e. the PSC) signaled by the TE-LSP signaling protocols 1093 as specified in [DIFF-MPLS], if used, MAY optionally be used by DS-TE 1094 LSRs to dynamically adjust the resources allocated to a PSC/OA within 1095 a Class Type by the Diff-Serv scheduler. 1097 10.Existing TE as a Particular Case of DS-TE 1099 We observe that existing TE can be viewed as a particular case of 1100 DS-TE where: 1102 (i) a single Class-Type is used, 1103 (ii) all 8 preemption priorities are allowed for that Class- 1104 Type, and 1105 (iii) the following TE-Class Mapping is used: 1106 TE-Class[i] <--> < CT0 , preemption i > 1107 Where 0 <= i <= 7. 1109 In that case, DS-TE behaves as existing TE. 1111 As with existing TE, the IGP advertises: 1112 - Unreserved Bandwidth for each of the 8 preemption priorities 1114 As with existing TE, the IGP may advertise: 1115 - Maximum Reservable Bandwidth containing a bandwidth 1116 constraint applying across all LSPs 1118 Since all LSPs transport traffic from CT0, RSVP-TE signaling is done 1119 without explicit signaling of the Class-Type (which is only used for 1120 other Class-Types than CT0 as explained in section 6) as with 1121 existing TE. 1123 11.Computing "Unreserved TE-Class [i]" and Admission Control Rules 1125 Protocols for Diffserv-aware TE December 2004 1127 11.1.Computing "Unreserved TE-Class [i]" 1129 We first observe that, for existing TE, details on admission control 1130 algorithms for TE LSPs, and consequently details on formulas for 1131 computing the unreserved bandwidth, are outside the scope of the 1132 current IETF work. This is left for vendor differentiation. Note that 1133 this does not compromise interoperability across various 1134 implementations since the TE schemes rely on LSRs to advertise their 1135 local view of the world in terms of Unreserved Bw to other LSRs. This 1136 way, regardless of the actual local admission control algorithm used 1137 on one given LSR, Constraint Based Routing on other LSRs can rely on 1138 advertised information to determine whether an additional LSP will be 1139 accepted or rejected by the given LSR. The only requirement is that 1140 an LSR advertises unreserved bandwidth values which are consistent 1141 with its specific local admission control algorithm and take into 1142 account the holding preemption priority of established LSPs. 1144 In the context of DS-TE, again, details on admission control 1145 algorithms are left for vendor differentiation and formulas for 1146 computing the unreserved bandwidth for TE-Class[i] are outside the 1147 scope of this specification. However, DS-TE places the additional 1148 requirement on the LSR that the unreserved bandwidth values 1149 advertised MUST reflect all of the Bandwidth Constraints relevant to 1150 the CT associated with TE-Class[i] in accordance with the Bandwidth 1151 Constraints Model. Thus, formulas for computing "Unreserved TE-Class 1152 [i]" depend on the Bandwidth Constraints Model in use and MUST 1153 reflect how bandwidth constraints apply to CTs. Example formulas for 1154 computing "Unreserved TE-Class [i]" Model are provided for the 1155 Russian Dolls Model and Maximum Allocation Model respectively in 1156 [DSTE-RDM] and [DSTE-MAM]. 1158 As with existing TE, DS-TE LSRs MUST consider the holding preemption 1159 priority of established LSPs (as opposed to their set-up preemption 1160 priority) for the purpose of computing the unreserved bandwidth for 1161 TE-Class [i]. 1163 11.2.Admission Control Rules 1165 A DS-TE LSR MUST support the following admission control rule: 1167 Regardless of how the admission control algorithm actually computes 1168 the unreserved bandwidth for TE-Class[i] for one of its local link, 1169 an LSP of bandwidth B, of set-up preemption priority p and of 1170 Class-Type CTc is admissible on that link if, and only if,: 1172 B <= Unreserved Bandwidth for TE-Class[i] 1174 Where 1176 Protocols for Diffserv-aware TE December 2004 1178 - TE-Class [i] maps to < CTc , p > in the TE-Class mapping 1179 configured on the LSR. 1181 12.Security Considerations 1183 This document does not introduce additional security threats beyond 1184 those described for Diff-Serv ([DIFF-ARCH]) and MPLS Traffic 1185 Engineering ([TE-REQ], [RSVP-TE], [OSPF-TE], [ISIS-TE]) and the same 1186 security measures and procedures described in these documents apply 1187 here. For example, the approach for defense against theft- and 1188 denial-of-service attacks discussed in [DIFF-ARCH], which consists of 1189 the combination of traffic conditioning at DS boundary nodes along 1190 with security and integrity of the network infrastructure within a 1191 Diff-Serv domain, may be followed when DS-TE is in use. Also, as 1192 stated in [TE-REQ], it is specifically important that manipulation of 1193 administratively configurable parameters (such as those related to 1194 DS-TE LSPs) be executed in a secure manner by authorized entities. 1196 13.Acknowledgments 1198 We thank Martin Tatham, Angela Chiu and Pete Hicks for their earlier 1199 contribution in this work. We also thank Sanjaya Choudhury for his 1200 thorough review and suggestions. 1202 14.IANA Considerations 1204 This document creates two new name spaces which are to be managed by 1205 IANA. Also, a number of assignments from existing name spaces have 1206 been made by IANA in this document. Those are discussed below. 1208 14.1.A new name space for Bandwidth Constraints Model Identifiers 1210 This document defines in section 5.1 a "Bandwidth Constraints Model 1211 Id" field (name space) within the "Bandwidth Constraints" sub-TLV, 1212 both for OSPF and ISIS. IANA is requested to create and maintain this 1213 new name space. The field for this namespace is 1 octet, and IANA 1214 guidelines for assignments for this field are as follows: 1216 o values in the range 0-239 are to be assigned according to 1217 the "Specification Required" policy defined in [IANA-CONS]. 1219 o values in the range 240-255 are reserved for "Private Use" as 1220 defined in [IANA-CONS]. 1222 14.2.A new name space for Error Values under the "Diff-Serv-aware TE 1223 Error" 1225 Protocols for Diffserv-aware TE December 2004 1227 An Error Code is an 8-bit quantity defined in [RSVP] that appears in 1228 an ERROR_SPEC object to broadly define an error condition. With each 1229 Error Code there may be a 16-bit Error Value (which depends on the 1230 Error Code) that further specifies the cause of the error. 1232 This document defines in section 6.5 a new RSVP error code, the 1233 "Diff-Serv-aware TE Error" (see section 14.3.4). The Error Values for 1234 the "Diff-Serv-aware TE Error" constitute a new name space to be 1235 managed by IANA. 1237 This document defines, in section 6.5, values 1 through 7 in that 1238 name space (see section 14.3.5). 1240 Future allocations of values in this name space are to be assigned by 1241 IANA using the "Specification Required" policy defined in 1242 [IANA-CONS]. 1244 14.3.Assignments made in this Document 1246 14.3.1.Bandwidth Constraints sub-TLV for OSPF version 2 1248 [OSPF-TE] creates a name space for the sub-TLV types within the "Link 1249 TLV" of the Traffic Engineering LSA and rules for management of this 1250 name space by IANA. 1252 This document defines in section 5.1 a new sub-TLV, the "Bandwidth 1253 Constraints" sub-TLV, for the OSPF "Link" TLV. In accordance with the 1254 IANA considerations provided in [OSPF-TE], a sub-TLV type in the 1255 range 10 to 32767 was requested and the value TBD has been assigned 1256 by IANA for the "Bandwidth Constraints" sub-TLV. 1258 To be removed by the RFC editor at the time of 1259 publication: 1260 When the sub-TLV Type is assigned by IANA replace "TBD" above by the 1261 assigned value. 1262 1264 14.3.2.Bandwidth Constraints sub-TLV for ISIS 1266 [ISIS-TE] creates a name space for the sub-TLV types within the ISIS 1267 "Extended IS Reachability" TLV and rules for management of this name 1268 space by IANA. 1270 This document defines in section 5.1 a new sub-TLV, the "Bandwidth 1271 Constraints" sub-TLV, for the ISIS "Extended IS Reachability" TLV. In 1272 accordance with the IANA considerations provided in [ISIS-TE], a 1273 sub-TLV type was requested and the value TBD has been assigned by 1274 IANA for the "Bandwidth Constraints" sub-TLV. 1276 Protocols for Diffserv-aware TE December 2004 1278 To be removed by the RFC editor at the time of 1279 publication: 1280 When the sub-TLV Type is assigned by IANA replace "TBD" above by the 1281 assigned value. 1282 1284 14.3.3.CLASSTYPE object for RSVP 1286 [RSVP] defines the Class Number name space for RSVP object which is 1287 managed by IANA. Currently allocated Class Numbers are listed at 1288 "http://www.iana.org/assignments/rsvp-parameters" 1290 This document defines in section 6.2.1 a new RSVP object, the 1291 CLASSTYPE object. IANA was requested to assign a Class Number for 1292 this RSVP object from the range defined in section 3.10 of [RSVP] for 1293 those objects which, if not understood, cause the entire RSVP message 1294 to be rejected with an error code of "Unknown Object Class". Such 1295 objects are identified by a zero in the most significant bit of the 1296 class number (i.e. 1297 Class-Num = 0bbbbbbb). 1298 IANA assigned Class-Number TBD to the CLASSTYPE object. C_Type 1 is 1299 defined in this document for the CLASSTYPE object. 1301 To be removed by the RFC editor at the time of 1302 publication: 1303 When the RSVP Class-Num is assigned by IANA replace "TBD" above by 1304 the assigned value. 1305 1307 14.3.4."Diff-Serv-aware TE Error" Error Code 1309 [RSVP] defines the Error Code name space and rules for management of 1310 this name space by IANA. Currently allocated Error Codes are listed 1311 at "http://www.iana.org/assignments/rsvp-parameters" 1313 This document defines in section 6.5 a new RSVP Error Code, the 1314 "Diff-Serv-aware TE Error". In accordance with the IANA 1315 considerations provided in [RSVP], Error Code TBD was assigned by 1316 IANA to the "Diff-Serv-aware TE Error". 1318 To be removed by the RFC editor at the time of 1319 publication: 1320 When the RSVP Class-Num is assigned by IANA replace "TBD" above by 1321 the assigned value. 1322 1324 14.3.5.Error Values for "Diff-Serv-aware TE Error" 1326 An Error Code is an 8-bit quantity defined in [RSVP] that appears in 1327 an ERROR_SPEC object to broadly define an error condition. With each 1329 Protocols for Diffserv-aware TE December 2004 1331 Error Code there may be a 16-bit Error Value (which depends on the 1332 Error Code) that further specifies the cause of the error. 1334 This document defines in section 6.5 a new RSVP error code, the 1335 "Diff-Serv-aware TE Error" (see section 14.3.4). The Error Values for 1336 the "Diff-Serv-aware TE Error" constitute a new name space to be 1337 managed by IANA. 1339 This document defines, in section 6.5, the following Error Values for 1340 the "Diff-Serv-aware TE Error": 1342 Value Error 1344 1 Unexpected CLASSTYPE object 1345 2 Unsupported Class-Type 1346 3 Invalid Class-Type value 1347 4 Class-Type and setup priority do not form a configured 1348 TE-Class 1349 5 Class-Type and holding priority do not form a 1350 configured TE-Class 1351 6 Class-Type and setup priority do not form a configured 1352 TE-Class AND Class-Type and holding priority do not form 1353 a configured TE-Class 1354 7 Inconsistency between signaled PSC and signaled 1355 Class-Type 1356 8 Inconsistency between signaled PHBs and signaled 1357 Class-Type 1359 See section 14.2 for allocation of other values in that name space. 1361 15. Intellectual Property Considerations 1363 The IETF takes no position regarding the validity or scope of any 1364 Intellectual Property Rights or other rights that might be claimed to 1365 pertain to the implementation or use of the technology described in 1366 this document or the extent to which any license under such rights 1367 might or might not be available; nor does it represent that it has 1368 made any independent effort to identify any such rights. Information 1369 on the procedures with respect to rights in RFC documents can be 1370 found in BCP 78 and BCP 79. 1372 Copies of IPR disclosures made to the IETF Secretariat and any 1373 assurances of licenses to be made available, or the result of an 1374 attempt made to obtain a general license or permission for the use of 1375 such proprietary rights by implementers or users of this 1376 specification can be obtained from the IETF on-line IPR repository at 1377 http://www.ietf.org/ipr. 1379 Protocols for Diffserv-aware TE December 2004 1381 The IETF invites any interested party to bring to its attention any 1382 copyrights, patents or patent applications, or other proprietary 1383 rights that may cover technology that may be required to implement 1384 this standard. Please address the information to the IETF at 1385 ietf-ipr@ietf.org. 1387 16.Normative References 1389 [DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv- 1390 aware MPLS Traffic Engineering, RFC3564. 1392 [MPLS-ARCH] Rosen et al., "Multiprotocol Label Switching 1393 Architecture", RFC3031. 1395 [DIFF-ARCH] Blake et al., "An Architecture for Differentiated 1396 Services", RFC2475. 1398 [TE-REQ] Awduche et al., "Requirements for Traffic Engineering Over 1399 MPLS", RFC2702. 1401 [OSPF-TE] Katz et al., "Traffic Engineering (TE) Extensions to OSPF 1402 Version 2", RFC3630. 1404 [ISIS-TE] Smit, Li, "Intermediate System to Intermediate System 1405 (IS-IS) extensions for Traffic Engineering (TE)", RFC 3784. 1407 [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 1408 Tunnels", RFC 3209. 1410 [RSVP] Braden et al, "Resource ReSerVation Protocol (RSVP) - Version 1411 1 Functional Specification", RFC 2205. 1413 [DIFF-MPLS] Le Faucheur et al, "MPLS Support of Diff-Serv", RFC3270. 1415 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 1416 Requirement Levels, RFC2119. 1418 [IANA-CONS], T. Narten et al, "Guidelines for Writing an IANA 1419 Considerations Section in RFCs", RFC2434. 1421 17.Informative References 1423 [DSTE-RDM] Le Faucheur et al., "Russian Dolls Bandwidth Constraints 1424 Model for DS-TE", draft-ietf-tewg-diff-te-russian-07.txt, work in 1425 progress. 1427 Protocols for Diffserv-aware TE December 2004 1429 [DSTE-MAM] Le Faucheur, Lai, "Maximum Allocation Bandwidth 1430 Constraints Model for DS-TE", draft-ietf-tewg-diff-te-mam-04.txt, 1431 work in progress . 1433 [DSTE-MAR] Ash, "Max Allocation with Reservation Bandwidth 1434 Constraints Model for MPLS/DiffServ TE & Performance Comparisons", 1435 draft-ietf-tewg-diff-te-mar-03.txt, work in progress . 1437 [GMPLS-SIG] Berger et. al., "Generalized Multi-Protocol Label 1438 Switching (GMPLS) Signaling Functional Description", RFC3471 1440 [GMPLS-ROUTE] Kompella et. al., "Routing Extensions in Support of 1441 Generalized MPLS", draft-ietf-ccamp-gmpls-routing-09.txt, work in 1442 progress. 1444 [BUNDLE] Kompella, Rekhter, Berger, "Link Bundling in MPLS Traffic 1445 Engineering", draft-ietf-mpls-bundle-04.txt, work in progress. 1447 [HIERARCHY] Kompella, Rekhter, "LSP Hierarchy with Generalized MPLS 1448 TE", draft-ietf-mpls-lsp-hierarchy-08.txt, work in progress. 1450 [REROUTE] Pan et. al., "Fast Reroute Extensions to RSVP-TE for LSP 1451 Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt, work in 1452 progress. 1454 18.Editor's Address: 1456 Francois Le Faucheur 1457 Cisco Systems, Inc. 1458 Village d'Entreprise Green Side - Batiment T3 1459 400, Avenue de Roumanille 1460 06410 Biot-Sophia Antipolis 1461 France 1462 Phone: +33 4 97 23 26 19 1463 Email: flefauch@cisco.com 1465 19.Full Copyright Statement 1467 Copyright (C) The Internet Society (2004). All Rights Reserved. 1469 This document and translations of it may be copied and furnished to 1470 others, and derivative works that comment on or otherwise explain it 1471 or assist in its implementation may be prepared, copied, published 1472 and distributed, in whole or in part, without restriction of any 1473 kind, provided that the above copyright notice and this paragraph are 1474 included on all such copies and derivative works. However, this 1475 document itself may not be modified in any way, such as by removing 1476 the copyright notice or references to the Internet Society or other 1478 Protocols for Diffserv-aware TE December 2004 1480 Internet organizations, except as needed for the purpose of 1481 developing Internet standards in which case the procedures for 1482 copyrights defined in the Internet Standards process must be 1483 followed, or as required to translate it into languages other than 1484 English. 1486 The limited permissions granted above are perpetual and will not be 1487 revoked by the Internet Society or its successors or assigns. 1489 This document and the information contained herein is provided on an 1490 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1491 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1492 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1493 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1494 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1496 Appendix A - Prediction for Multiple Path Computation 1498 There are situations where a Head-End needs to compute paths for 1499 multiple LSPs over a short period of time. There are potential 1500 advantages for the Head-end in trying to predict the impact of the n- 1501 th LSP on the unreserved bandwidth when computing the path for the 1502 (n+1)-th LSP, before receiving updated IGP information. One example 1503 would be to perform better load-distribution of the multiple LSPs 1504 across multiple paths. Another example would be to avoid CAC 1505 rejection when the (n+1)-th LSP would no longer fit on a link after 1506 establishment of the n-th LSP. While there are also a number of 1507 conceivable scenarios where doing such predictions might result in a 1508 worse situation, it is more likely to improve the situation. As a 1509 matter of fact, a number of network administrators have elected to 1510 use such predictions when deploying existing TE. 1512 Such predictions are local matters, are optional and are outside the 1513 scope of this specification. 1515 Where such predictions are not used, the optional Bandwidth 1516 Constraint sub-TLV and the optional Maximum Reservable Bandwidth sub- 1517 TLV need not be advertised in IGP for the purpose of path computation 1518 since the information contained in the Unreserved Bw sub-TLV is all 1519 that is required by Head-Ends to perform Constraint Based Routing. 1521 Where such predictions are used on Head-Ends, the optional Bandwidth 1522 Constraints sub-TLV and the optional Maximum Reservable Bandwidth 1523 sub-TLV MAY be advertised in IGP. This is in order for the Head-ends 1524 to predict as accurately as possible how an LSP affects unreserved 1525 bandwidth values for subsequent LSPs. 1527 Remembering that actual admission control algorithms are left for 1528 vendor differentiation, we observe that predictions can only be 1530 Protocols for Diffserv-aware TE December 2004 1532 performed effectively when the Head-end LSR predictions are based on 1533 the same (or a very close) admission control algorithm as used by 1534 other LSRs. 1536 Appendix B - Solution Evaluation 1538 1. Satisfying Detailed Requirements 1540 This DS-TE Solution addresses all the scenarios presented in [DSTE- 1541 REQ]. 1543 It also satisfies all the detailed requirements presented in [DSTE- 1544 REQ]. 1546 The objective set out in the last paragraph of section "4.7 1547 overbooking" of [DSTE-REQ] is only partially addressed by this DS-TE 1548 solution. Through support of the "LSP Size Overbooking" and "Link 1549 Size Overbooking" methods, this DS-TE solution effectively allows CTs 1550 to have different overbooking ratios and simultaneously allows 1551 overbooking to be tweaked differently (collectively across all CTs) 1552 on different links. But, in a general sense, it does not allow the 1553 effective overbooking ratio of every CT to be tweaked differently in 1554 different parts of the network independently of other CTs, while 1555 maintaining accurate bandwidth accounting of how different CTs 1556 mutually affect each other through shared Bandwidth Constraints (such 1557 as the Maximum Reservable Bandwidth). 1559 2. Flexibility 1561 This DS-TE solution supports 8 CTs. It is entirely flexible as to how 1562 Traffic Trunks are grouped together into a CT. 1564 3. Extendibility 1566 A maximum of 8 CTs is considered by the authors of this document as 1567 more than comfortable. A maximum of 8 TE-classes is considered by the 1568 authors of this document as sufficient. However, this solution could 1569 be extended to support more CTs or more TE-classes if deemed 1570 necessary in the future; This would necessitate additional IGP 1571 extensions beyond those specified in this document. 1573 Although the prime objective of this solution is support of Diff- 1574 Serv-aware Traffic Engineering, its mechanisms are not tightly 1575 coupled with Diff-Serv. This makes the solution amenable, or more 1576 easily extendable, for support of potential other future Traffic 1577 Engineering applications. 1579 4. Scalability 1581 Protocols for Diffserv-aware TE December 2004 1583 This DS-TE solution is expected to have a very small scalability 1584 impact compared to existing TE. 1586 From an IGP viewpoint, the amount of mandatory information to be 1587 advertised is identical to existing TE. One additional sub-TLV has 1588 been specified, but its use is optional and it only contains a 1589 limited amount of static information (at most 8 Bandwidth 1590 Constraints). 1592 We expect no noticeable impact on LSP Path computation since, as with 1593 existing TE, this solution only requires CSPF to consider a single 1594 unreserved bandwidth value for any given LSP. 1596 From a signaling viewpoint we expect no significant impact due to 1597 this solution since it only requires processing of one additional 1598 information (the Class-Type) and does not significantly increase the 1599 likelihood of CAC rejection. Note that DS-TE has some inherent impact 1600 on LSP signaling in the sense that it assumes that different classes 1601 of traffic are split over different LSPs so that more LSPs need to be 1602 signaled; but this is due to the DS-TE concept itself and not to the 1603 actual DS-TE solution discussed here. 1605 5. Backward Compatibility/Migration 1607 This solution is expected to allow smooth migration from existing TE 1608 to DS-TE. This is because existing TE can be supported as a 1609 particular configuration of DS-TE. This means that an "upgraded" LSR 1610 with a DS-TE implementation can directly interwork with an "old" LSR 1611 supporting existing TE only. 1613 This solution is expected to allow smooth migration when increasing 1614 the number of CTs actually deployed since it only requires 1615 configuration changes. However, these changes need to be performed in 1616 a coordinated manner across the DS-TE domain. 1618 Appendix C - Interoperability with non DS-TE capable LSRs 1620 This DSTE solution allows operations in a hybrid network where some 1621 LSRs are DS-TE capable while some LSRs are not DS-TE capable, which 1622 may occur during migration phases. This Appendix discusses the 1623 constraints and operations in such hybrid networks. 1625 We refer to the set of DS-TE capable LSRs as the DS-TE domain. We 1626 refer to the set of non DS-TE capable (but TE capable) LSRs as the 1627 TE-domain. 1629 Hybrid operations requires that the TE-class mapping in the DS-TE 1630 domain is configured so that: 1632 Protocols for Diffserv-aware TE December 2004 1634 - a TE-class exist for CT0 for every preemption priority 1635 actually used in the TE domain 1636 - the index in the TE-class mapping for each of these TE- 1637 classes is equal to the preemption priority. 1639 For example, imagine the TE domain uses preemption 2 and 3. Then, DS- 1640 TE can be deployed in the same network by including the following TE- 1641 classes in the TE-class mapping: 1642 i <---> CT preemption 1643 ==================================== 1644 2 CT0 2 1645 3 CT0 3 1647 Another way to look at this is to say that, the whole TE-class 1648 mapping does not have to be consistent with the TE domain, but the 1649 subset of this TE-Class mapping applicable to CT0 has to effectively 1650 be consistent with the TE domain. 1652 Hybrid operations also requires that: 1653 - non DS-TE capable LSRs be configured to advertise the Maximum 1654 Reservable Bandwidth 1655 - DS-TE capable LSRs be configured to advertise Bandwidth 1656 Constraints (using the Max Reservable Bandwidth sub-TLV as 1657 well as the Bandwidth Constraints sub-TLV, as specified in 1658 section 5.1 above). 1659 This allows DS-TE capable LSRs to unambiguously identify non DS-TE 1660 capable LSRs. 1662 Finally hybrid operations require that non DS-TE capable LSRs be able 1663 to accept Unreserved Bw sub-TLVs containing non decreasing bandwidth 1664 values (ie with Unreserved [p] < Unreserved [q] with p CT preemption 1692 ==================================== 1693 0 CT1 0 1694 1 CT1 1 1695 2 CT0 2 1696 3 CT0 3 1697 rest unused 1699 LSR0 is configured with a Max Reservable bandwidth=m01 for Link01. 1700 LSR1 is configured with a BC0=x0 a BC1=x1(possibly=0), and a Max 1701 Reservable Bandwidth=m10(possibly=m01) for Link01. 1703 LSR0 will advertise in IGP for Link01: 1704 - Max Reservable Bw sub-TLV = 1705 - Unreserved Bw sub-TLV = 1706 1708 On receipt of such advertisement, LSR1 will: 1709 - understand that LSR0 is not DS-TE capable because it 1710 advertised a Max Reservable Bw sub-TLV and no Bandwidth 1711 Constraints sub-TLV 1712 - conclude that only CT0 LSPs can transit via LSR0 and that 1713 only the values CT0/2 and CT0/3 are meaningful in the 1714 Unreserved Bw sub-TLV. LSR1 may effectively behave as if the 1715 six other values contained in the Unreserved Bw sub-TLV were 1716 set to zero. 1718 LSR1 will advertise in IGP for Link01: 1719 - Max Reservable Bw sub-TLV = 1720 - Bandwidth Constraints sub-TLV = 1721 - Unreserved Bw sub-TLV = 1723 On receipt of such advertisement, LSR0 will: 1724 - Ignore the Bandwidth Constraints sub-TLV (unrecognized) 1725 - Correctly process CT0/2 and CT0/3 in the Unreserved Bw sub- 1726 TLV and use these values for CTO LSP establishment 1727 - Incorrectly believe that the other values contained in the 1728 Unreserved Bw sub-TLV relates to other preemption priorities 1729 for CT0, but will actually never use those since we assume 1730 that only preemption 2 and 3 are used in the TE domain. 1732 Protocols for Diffserv-aware TE December 2004 1734 Disclaimer of Validity 1736 This document and the information contained herein are provided on an 1737 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1738 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1739 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1740 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1741 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1742 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1744 Copyright Statement 1746 Copyright (C) The Internet Society (2004). This document is subject 1747 to the rights, licenses and restrictions contained in BCP 78, and 1748 except as set forth therein, the authors retain all their rights. 1750 Acknowledgment 1752 Funding for the RFC Editor function is currently provided by the 1753 Internet Society.