idnits 2.17.1 draft-ietf-tewg-diff-te-proto-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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 34 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** 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: ---------------------------------------------------------------------------- == 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 (March 2004) is 7346 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) -- Looks like a reference, but probably isn't: '0' on line 657 -- Looks like a reference, but probably isn't: '1' on line 495 -- Looks like a reference, but probably isn't: '2' on line 496 -- Looks like a reference, but probably isn't: '3' on line 497 -- Looks like a reference, but probably isn't: '7' on line 658 == Missing Reference: 'N' is mentioned on line 995, but not defined ** Downref: Normative reference to an Informational RFC: RFC 3564 (ref. 'DSTE-REQ') ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. 'DIFF-ARCH') ** Downref: Normative reference to an Informational RFC: RFC 2702 (ref. 'TE-REQ') ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'ISIS-TE') ** Obsolete normative reference: RFC 2434 (ref. 'IANA-CONS') (Obsoleted by RFC 5226) == Outdated reference: A later version (-07) exists of draft-ietf-tewg-diff-te-russian-04 == Outdated reference: A later version (-04) exists of draft-ietf-tewg-diff-te-mam-02 == Outdated reference: A later version (-06) exists of draft-ietf-tewg-diff-te-mar-03 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-bundle-04 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-rsvp-lsp-fastreroute-03 Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEWG 2 Internet Draft Francois Le Faucheur 3 Editor 4 Document: draft-ietf-tewg-diff-te-proto-07.txt Cisco Systems, 5 Inc. 6 Expires: September 20024 March 2004 8 Protocol extensions for support of 9 Differentiated-Service-aware MPLS Traffic Engineering 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. Internet-Drafts are 15 Working documents of the Internet Engineering Task Force (IETF), its 16 areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Copyright Notice 31 Copyright (C) The Internet Society (2004). All Rights Reserved. 33 Abstract 35 This document specifies the protocol extensions for support of 36 Differentiated-Service-aware MPLS Traffic Engineering (DS-TE). This 37 includes generalization of the semantic of a number of IGP extensions 38 already defined for existing MPLS Traffic Engineering in RFC3630 and 39 RFC-TBD as well as additional IGP extensions beyond those. This also 40 includes extensions to RSVP-TE signaling beyond those already 41 specified in RFC3209 for existing MPLS Traffic Engineering. These 42 extensions address the Requirements for DS-TE spelt out in RFC3564. 44 To be removed by the RFC editor at the time of 45 publication: Please replace "TBD" above by the actual RFC 46 number when 48 Protocols for Diffserv-aware TE March 2004 50 an RFC number is allocated to [ISIS-TE] 51 53 Specification of Requirements 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in [RFC2119]. 59 Table of Contents 61 1. Introduction...................................................3 62 2. Contributing Authors...........................................4 63 3. Definitions....................................................4 64 4. Configurable Parameters........................................5 65 4.1.1. Link Parameters 5 66 4.1.2. Bandwidth Constraints (BCs) 5 67 4.1.3. Overbooking6 68 4.2. LSR Parameters............................................6 69 4.2.1. TE-Class Mapping 6 70 4.3. LSP Parameters............................................7 71 4.3.1. Class-Type 7 72 4.3.2. Setup and Holding Preemption Priorities 8 73 4.3.3. Class-Type/Preemption Relationship 8 74 4.4. Examples of Parameters Configuration......................8 75 4.4.1. Example 1 8 76 4.4.2. Example 2 9 77 4.4.3. Example 3 9 78 4.4.4. Example 4 10 79 4.4.5. Example 5 10 80 5. IGP Extensions for DS-TE......................................11 81 5.1. Bandwidth Constraints....................................11 82 5.2. Unreserved Bandwidth.....................................13 83 6. RSVP-TE Extensions for DS-TE..................................14 84 6.1. DS-TE related RSVP Messages Format.......................15 85 6.1.1. Path Message Format 15 86 6.2. CLASSTYPE Object.........................................15 87 6.2.1. CLASSTYPE object 16 88 6.3. Handling CLASSTYPE Object................................16 89 6.4. Non-support of the CLASSTYPE Object......................19 90 6.5. Error Codes For Diff-Serv-aware TE.......................19 91 7. DS-TE support with MPLS extensions............................20 92 7.1. DS-TE support and references to preemption priority......20 93 7.2. DS-TE support and references to Maximum Reservable Bandwidth 94 ..............................................................20 95 8. Constraint Based Routing......................................21 96 9. Diff-Serv scheduling..........................................21 97 10. Existing TE as a Particular Case of DS-TE....................21 99 Protocols for Diffserv-aware TE March 2004 101 11. Computing "Unreserved TE-Class [i]" and Admission Control Rules22 102 11.1. Computing "Unreserved TE-Class [i]".....................22 103 11.2. Admission Control Rules.................................23 104 12. Security Considerations......................................23 105 13. Acknowledgments..............................................23 106 14. IANA Considerations..........................................24 107 14.1. A new name space for Bandwidth Constraints Model Identifiers 108 ..............................................................24 109 14.2. A new name space for Error Values under the "Diff-Serv-aware 110 TE Error".....................................................24 111 14.3. Assignments made in this Document.......................24 112 14.3.1. Bandwidth Constraints sub-TLV for OSPF version 2 24 113 14.3.2. Bandwidth Constraints sub-TLV for ISIS 25 114 14.3.3. CLASSTYPE object for RSVP25 115 14.3.4. "Diff-Serv-aware TE Error" Error Code26 116 14.3.5. Error Values for "Diff-Serv-aware TE Error"26 117 15. Intellectual Property Considerations.........................27 118 16. Normative References.........................................27 119 17. Informative References.......................................28 120 18. Editor's Address:............................................28 121 19. Full Copyright Statement.....................................29 122 Appendix A - Prediction for Multiple Path Computation............29 123 Appendix B - Solution Evaluation.................................30 124 Appendix C - Interoperability with non DS-TE capable LSRs........32 126 1. Introduction 128 [DSTE-REQ] presents the Service Providers requirements for support of 129 Differentiated-Service (Diff-Serv)-aware MPLS Traffic Engineering 130 (DS-TE). This includes the fundamental requirement to be able to 131 enforce different bandwidth constraints for different classes of 132 traffic. 134 This document specifies the IGP and RSVP-TE signaling extensions 135 (beyond those already specified for existing MPLS Traffic Engineering 136 [OSPF-TE][ISIS-TE][RSVP-TE]) for support of the DS-TE requirements 137 spelt out in [DSTE-REQ] including environments relying on distributed 138 Constraint Based Routing (e.g. path computation involving Head-end 139 LSRs). 141 [DSTE-REQ] provides a definition and examples of Bandwidth 142 Constraints Models. The present document does not specify nor assume 143 a particular Bandwidth Constraints model. Specific Bandwidth 144 Constraints model are outside the scope of this document. While the 145 extensions for DS-TE specified in this document may not be sufficient 146 to support all the conceivable Bandwidth Constraints models, they do 147 support the "Russian Dolls" Model specified in [DSTE-RDM], the 149 Protocols for Diffserv-aware TE March 2004 151 "Maximum Allocation" Model specified in [DSTE-MAM] and the "Maximum 152 Allocation with Reservation" Model specified in [DSTE-MAR]. 154 2. Contributing Authors 156 This document was the collective work of several. The text and 157 content of this document was contributed by the editor and the co- 158 authors listed below. (The contact information for the editor appears 159 in Section 18, and is not repeated below.) 161 Jim Boyle Kireeti Kompella 162 Protocol Driven Networks, Inc. Juniper Networks, Inc. 163 1381 Kildaire Farm Road #288 1194 N. Mathilda Ave. 164 Cary, NC 27511, USA Sunnyvale, CA 94099 165 Phone: (919) 852-5160 Email: kireeti@juniper.net 166 Email: jboyle@pdnets.com 168 William Townsend Thomas D. Nadeau 169 Tenor Networks Cisco Systems, Inc. 170 100 Nagog Park 250 Apollo Drive 171 Acton, MA 01720 Chelmsford, MA 01824 172 Phone: +1-978-264-4900 Phone: +1-978-244-3051 173 Email: Email: tnadeau@cisco.com 174 btownsend@tenornetworks.com 176 Darek Skalecki 177 Nortel Networks 178 3500 Carling Ave, 179 Nepean K2H 8E9 180 Phone: +1-613-765-2252 181 Email: dareks@nortelnetworks.com 183 3. Definitions 185 For readability a number of definitions from [DSTE-REQ] are repeated 186 here: 188 Traffic Trunk: an aggregation of traffic flows of the same class 189 [i.e. which are to be treated equivalently from the DS-TE 190 perspective] which are placed inside a Label Switched Path. 192 Class-Type (CT): the set of Traffic Trunks crossing a link that is 193 governed by a specific set of Bandwidth constraints. CT is used for 194 the purposes of link bandwidth allocation, constraint based routing 195 and admission control. A given Traffic Trunk belongs to the same CT 196 on all links. 198 Protocols for Diffserv-aware TE March 2004 200 TE-Class: A pair of: 201 i. a Class-Type 202 ii. a preemption priority allowed for that Class-Type. This 203 means that an LSP transporting a Traffic Trunk from 204 that Class-Type can use that preemption priority as the 205 set-up priority, as the holding priority or both. 207 Definitions for a number of MPLS terms are not repeated here. Those 208 can be found in [MPLS-ARCH]. 210 4. Configurable Parameters 212 This section only discusses the differences with the configurable 213 parameters supported for MPLS Traffic Engineering as per [TE-REQ], 214 [ISIS-TE], [OSPF-TE], and [RSVP-TE]. All other parameters are 215 unchanged. 217 4.1.1. Link Parameters 219 4.1.2. Bandwidth Constraints (BCs) 221 [DSTE-REQ] states that "Regardless of the Bandwidth Constraints 222 Model, the DS-TE solution MUST allow support for up to 8 BCs." 224 For DS-TE, the existing "Maximum Reservable link bandwidth" parameter 225 is retained but its semantic is generalized and interpreted as the 226 aggregate bandwidth constraints across all Class-Types, so that, 227 independently of the Bandwidth Constraints Model in use: 228 SUM (Reserved (CTc)) <= Max Reservable Bandwidth, 229 where the SUM is across all values of "c" in the range 0 <= c <= 7. 231 Additionally, on every link, a DS-TE implementation MUST provide for 232 configuration of up to 8 additional link parameters which are the 233 eight potential Bandwidth Constraints i.e. BC0, BC1 , ... BC7. The 234 LSR MUST interpret these Bandwidth Constraints in accordance with the 235 supported Bandwidth Constraints Model (i.e. what bandwidth constraint 236 applies to what Class-Type and how). 238 Where the Bandwidth Constraints Model imposes some relationship among 239 the values to be configured for these Bandwidth Constraints, the LSR 240 MUST enforce those at configuration time. For example, when the 241 "Russian Doll" Bandwidth Constraints Model ([DSTE-RDM]) is used, the 242 LSR must ensure that BCi is configured smaller or equal to BCj, where 243 i is greater than j, and ensure that BC0 is equal to the Maximum 244 Reservable Bandwidth. As another example, when the Maximum Allocation 245 Model ([DSTE-MAM]) is used, the LSR must ensure that all BCi are 246 configured smaller or equal to the Maximum Reservable Bandwidth. 248 Protocols for Diffserv-aware TE March 2004 250 4.1.3. Overbooking 252 DS-TE enables a network administrator to apply different overbooking 253 (or underbooking) ratios for different CTs. 255 The principal methods to achieve this are the same as historically 256 used in existing TE deployment, which are : 257 (i) To take into account the overbooking/underbooking ratio 258 appropriate for the OA/CT associated with the considered LSP 259 at the time of establishing the bandwidth size of a given 260 LSP. We refer to this method as the "LSP Size Overbooking 261 method". AND/OR 262 (ii) To take into account the overbooking/underbooking ratio at 263 the time of configuring the Maximum Reservable 264 Bandwidth/Bandwidth Constraints and use values which are 265 larger(overbooking) or smaller(underbooking) than actually 266 supported by the link. We refer to this method as the "Link 267 Size Overbooking method". 269 The "LSP Size Overbooking" method and the "Link Size Overbooking" 270 method are expected to be sufficient in many DS-TE environments and 271 require no additional configurable parameters. Other overbooking 272 methods may involve such additional configurable parameters but are 273 beyond the scope of this document. 275 4.2. LSR Parameters 277 4.2.1. TE-Class Mapping 279 In line with [DSTE-REQ], the preemption attributes defined in [TE- 280 REQ] are retained with DS-TE and applicable within, and across, all 281 Class Types. The preemption attributes of setup priority and holding 282 priority retain existing semantics, and in particular these semantics 283 are not affected by the LSP Class Type. This means that if LSP1 284 contends with LSP2 for resources, LSP1 may preempt LSP2 if LSP1 has a 285 higher set-up preemption priority (i.e. lower numerical priority 286 value) than LSP2 holding preemption priority regardless of LSP1 CT 287 and LSP2 CT. 289 DS-TE LSRs MUST allow configuration of a TE-Class mapping whereby the 290 Class-Type and preemption level are configured for each of (up to) 8 291 TE-Classes. 293 This mapping is referred to as : 295 TE-Class[i] <--> < CTc , preemption p > 297 Where 0 <= i <= 7, 0 <= c <= 7, 0 <= p <= 7 299 Protocols for Diffserv-aware TE March 2004 301 Two TE-Classes must not be identical (i.e. have both the same Class- 302 Type and the same preemption priority). 304 There are no other restrictions on how any of the 8 Class-Types can 305 be paired up with any of the 8 preemption priorities to form a TE- 306 class. In particular, one given preemption priority can be paired up 307 with two (or more) different Class-Types to form two (or more) TE- 308 classes. Similarly, one Class-Type can be paired up with two (or 309 more) different preemption priorities to form two (or more) TE- 310 Classes. Also, there is no mandatory ordering relationship between 311 the TE-Class index (i.e. "i" above) and the Class-Type (i.e. "c" 312 above) or the preemption priority (i.e. "p" above) of the TE-Class. 314 Where the network administrator uses less than 8 TE-Classes, the DS- 315 TE LSR MUST allow remaining ones to be configured as "Unused". Note 316 that "Configuring all the 8 TE-Classes as "Unused" effectively 317 results in disabling TE/DS-TE since no TE/DS-TE LSP can be 318 established (nor even configured, since as described in section 4.3.3 319 below, the CT and preemption priorities configured for an LSP must 320 form one of the configured TE-Classes)". 322 To ensure coherent DS-TE operation, the network administrator MUST 323 configure exactly the same TE-Class Mapping on all LSRs of the DS-TE 324 domain. 326 When the TE-class mapping needs to be modified in the DS-TE domain, 327 care must be exercised during the transient period of reconfiguration 328 during which some DS-TE LSRs may be configured with the new TE-class 329 mapping while others are still configured with the old TE-class 330 mapping. It is recommended that active tunnels do not use any of the 331 TE-classes which are being modified during such a transient 332 reconfiguration period. 334 4.3. LSP Parameters 336 4.3.1. Class-Type 338 With DS-TE, LSRs MUST support, for every LSP, an additional 339 configurable parameter which indicates the Class-Type of the Traffic 340 Trunk transported by the LSP. 342 There is one and only one Class-Type configured per LSP. 344 The configured Class-Type indicates, in accordance with the supported 345 Bandwidth Constraints Model, the Bandwidth Constraints that MUST be 346 enforced for that LSP. 348 Protocols for Diffserv-aware TE March 2004 350 4.3.2. Setup and Holding Preemption Priorities 352 As per existing TE, DS-TE LSRs MUST allow every DS-TE LSP to be 353 configured with a setup and holding priority, each with a value 354 between 0 and 7. 356 4.3.3. Class-Type/Preemption Relationship 358 With DS-TE, the preemption priority configured for the setup priority 359 of a given LSP and the Class-Type configured for that LSP must be 360 such that, together, they form one of the (up to) 8 TE-Classes 361 configured in the TE-Class Mapping specified in section 4.2.1 above. 363 The preemption priority configured for the holding priority of a 364 given LSP and the Class-Type configured for that LSP must also be 365 such that, together, they form one of the (up to) 8 TE-Classes 366 configured in the TE-Class Mapping specified in section 4.2.1 above. 368 The LSR MUST enforce these two rules at configuration time. 370 4.4. Examples of Parameters Configuration 372 For illustrative purposes, we now present a few examples of how these 373 configurable parameters may be used. All these examples assume that 374 different bandwidth constraints need to be enforced for different 375 sets of Traffic Trunks (e.g. for Voice and for Data) so that two, or 376 more, Class-Types need to be used. 378 4.4.1. Example 1 380 The Network Administrator of a first network using two Class Types 381 (CT1 for Voice and CT0 for Data), may elect to configure the 382 following TE-Class Mapping to ensure that Voice LSPs are never driven 383 away from their shortest path because of Data LSPs: 385 TE-Class[0] <--> < CT1 , preemption 0 > 386 TE-Class[1] <--> < CT0 , preemption 1 > 387 TE-Class[i] <--> unused, for 2 <= i <= 7 389 Voice LSPs would then be configured with: 390 - CT=CT1, set-up priority =0, holding priority=0 392 Data LSPs would then be configured with: 393 - CT=CT0, set-up priority =1, holding priority=1 395 A new Voice LSP would then be able to preempt an existing Data LSP in 396 case they contend for resources. A Data LSP would never preempt a 397 Voice LSP. A Voice LSP would never preempt another Voice LSP. A Data 398 LSP would never preempt another Data LSP. 400 Protocols for Diffserv-aware TE March 2004 402 4.4.2. Example 2 404 The Network Administrator of another network may elect to configure 405 the following TE-Class Mapping in order to optimize global network 406 resource utilization by favoring placement of large LSPs closer to 407 their shortest path: 409 TE-Class[0] <--> < CT1 , preemption 0 > 410 TE-Class[1] <--> < CT0 , preemption 1 > 411 TE-Class[2] <--> < CT1 , preemption 2 > 412 TE-Class[3] <--> < CT0 , preemption 3 > 413 TE-Class[i] <--> unused, for 4 <= i <= 7 415 Large size Voice LSPs could be configured with: 416 - CT=CT1, set-up priority =0, holding priority=0 418 Large size Data LSPs could be configured with: 419 - CT=CT0, set-up priority = 1, holding priority=1 421 Small size Voice LSPs could be configured with: 422 - CT=CT1, set-up priority = 2, holding priority=2 424 Small size Data LSPs could be configured with: 425 - CT=CT0, set-up priority = 3, holding priority=3. 427 A new large size Voice LSP would then be able to preempt a small size 428 Voice LSP or any Data LSP in case they contend for resources. 429 A new large size Data LSP would then be able to preempt a small size 430 Data LSP or a small size Voice LSP in case they contend for 431 resources, but it would not be able to preempt a large size Voice 432 LSP. 434 4.4.3. Example 3 436 The Network Administrator of another network may elect to configure 437 the following TE-Class Mapping in order to ensure that Voice LSPs are 438 never driven away from their shortest path because of Data LSPs while 439 also achieving some optimization of global network resource 440 utilization by favoring placement of large LSPs closer to their 441 shortest path: 443 TE-Class[0] <--> < CT1 , preemption 0 > 444 TE-Class[1] <--> < CT1 , preemption 1 > 445 TE-Class[2] <--> < CT0 , preemption 2 > 446 TE-Class[3] <--> < CT0 , preemption 3 > 447 TE-Class[i] <--> unused, for 4 <= i <= 7 449 Large size Voice LSPs could be configured with: 451 Protocols for Diffserv-aware TE March 2004 453 - CT=CT1, set-up priority = 0, holding priority=0. 455 Small size Voice LSPs could be configured with: 456 - CT=CT1, set-up priority = 1, holding priority=1. 458 Large size Data LSPs could be configured with: 459 - CT=CT0, set-up priority = 2, holding priority=2. 461 Small size Data LSPs could be configured with: 462 - CT=CT0, set-up priority = 3, holding priority=3. 464 A Voice LSP could preempt a Data LSP if they contend for resources. A 465 Data LSP would never preempt a Voice LSP. A Large size Voice LSP 466 could preempt a small size Voice LSP if they contend for resources. A 467 Large size Data LSP could preempt a small size Data LSP if they 468 contend for resources. 470 4.4.4. Example 4 472 The Network Administrator of another network may elect to configure 473 the following TE-Class Mapping in order to ensure that no preemption 474 occurs in the DS-TE domain: 476 TE-Class[0] <--> < CT1 , preemption 0 > 477 TE-Class[1] <--> < CT0 , preemption 0 > 478 TE-Class[i] <--> unused, for 2 <= i <= 7 480 Voice LSPs would then be configured with: 481 - CT=CT1, set-up priority =0, holding priority=0 483 Data LSPs would then be configured with: 484 - CT=CT0, set-up priority =0, holding priority=0 486 No LSP would then be able to preempt any other LSP. 488 4.4.5. Example 5 490 The Network Administrator of another network may elect to configure 491 the following TE-Class Mapping in view of increased network stability 492 through a more limited use of preemption: 494 TE-Class[0] <--> < CT1 , preemption 0 > 495 TE-Class[1] <--> < CT1 , preemption 1 > 496 TE-Class[2] <--> < CT0 , preemption 1 > 497 TE-Class[3] <--> < CT0 , preemption 2 > 498 TE-Class[i] <--> unused, for 4 <= i <= 7 500 Large size Voice LSPs could be configured with: 501 - CT=CT1, set-up priority = 0, holding priority=0. 503 Protocols for Diffserv-aware TE March 2004 505 Small size Voice LSPs could be configured with: 506 - CT=CT1, set-up priority = 1, holding priority=0. 508 Large size Data LSPs could be configured with: 509 - CT=CT0, set-up priority = 2, holding priority=1. 511 Small size Data LSPs could be configured with: 512 - CT=CT0, set-up priority = 2, holding priority=2. 514 A new large size Voice LSP would be able to preempt a Data LSP in 515 case they contend for resources, but it would not be able to preempt 516 any Voice LSP even a small size Voice LSP. 518 A new small size Voice LSP would be able to preempt a small size Data 519 LSP in case they contend for resources, but it would not be able to 520 preempt a large size Data LSP or any Voice LSP. 522 A Data LSP would not be able to preempt any other LSP. 524 5. IGP Extensions for DS-TE 526 This section only discusses the differences with the IGP 527 advertisement supported for (aggregate) MPLS Traffic Engineering as 528 per [OSPF-TE] and [ISIS-TE]. The rest of the IGP advertisement is 529 unchanged. 531 5.1. Bandwidth Constraints 533 As detailed above in section 4.1.1, up to 8 Bandwidth Constraints 534 ( BCb, 0 <= b <= 7) are configurable on any given link. 536 With DS-TE, the existing "Maximum Reservable Bandwidth" sub-TLV 537 ([OSPF-TE], [ISIS-TE]) is retained with a generalized semantic so 538 that it MUST now be interpreted as the aggregate bandwidth constraint 539 across all Class-Types [ i.e. 540 SUM (Reserved (CTc)) <= Max Reservable Bandwidth], independently of 541 the Bandwidth Constraints Model. 543 This document also defines the following new optional sub-TLV to 544 advertise the eight potential Bandwidth Constraints (BC0 to BC7): 546 "Bandwidth Constraints" sub-TLV: 547 - Bandwidth Constraints Model Id (1 octet) 548 - Reserved (3 octets) 549 - Bandwidth Constraints (Nx4 octets) 551 Where: 553 Protocols for Diffserv-aware TE March 2004 555 - With OSPF, the sub-TLV is a sub-TLV of the "Link TLV" and its 556 sub-TLV type is TBD 558 - With ISIS, the sub-TLV is a sub-TLV of the "extended IS 559 reachability TLV" and its sub-TLV type is TBD (). 561 To be removed by the RFC editor at the time of 562 publication: When the sub-TLV numbers are allocated by IANA 563 for OSPF and ISIS, replace "TBD" in the two bullet points above by 564 the respective assigned value. See IANA Considerations section for 565 allocation request. 566 567 - Bandwidth Constraints Model Id: 1 octet identifier for the 568 Bandwidth Constraints Model currently in use by the LSR 569 initiating the IGP advertisement. See the IANA Considerations 570 section below for assignment of values in this name space. 572 - Reserved: a 3-octet field. This field should be set to zero 573 by the LSR generating the sub-TLV and should be ignored by 574 the LSR receiving the sub-TLV. 576 - Bandwidth Constraints: contains BC0, BC1,... BC(N-1). 577 Each Bandwidth Constraint is encoded on 32 bits in IEEE 578 floating point format. The units are bytes (not bits!) per 579 second. Where the configured TE-class mapping and the 580 Bandwidth Constraints model in use are such that BCh+1, 581 BCh+2, ...and BC7 are not relevant to any of the Class-Types 582 associated with a configured TE-class, it is RECOMMENDED that 583 only the Bandwidth Constraints from BC0 to BCh be advertised, 584 in order to minimize the impact on IGP scalability. 586 All relevant generic TLV encoding rules (including TLV format, 587 padding and alignment, as well as IEEE floating point format 588 encoding) defined in [OSPF-TE] and [ISIS-TE] are applicable to this 589 new sub-TLV. 591 The "Bandwidth Constraints" sub-TLV format is illustrated below: 593 0 1 2 3 594 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 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | BC Model Id | Reserved | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | BC0 value | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 // . . . // 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | BCh value | 604 Protocols for Diffserv-aware TE March 2004 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 A DS-TE LSR MAY optionally advertise Bandwidth Constraints. 610 A DS-TE LSR which does advertise Bandwidth Constraints MUST use the 611 new "Bandwidth Constraints" sub-TLV (in addition to the existing 612 Maximum Reservable Bandwidth sub-TLV) to do so. For example, 613 considering the case where a Service Provider deploys DS-TE with 614 TE-classes associated with CT0 and CT1 only, and where the Bandwidth 615 Constraints Model is such that only BC0 and BC1 are relevant to CT0 616 and CT1: a DS-TE LSR which does advertise Bandwidth Constraints would 617 include in the IGP advertisement the Maximum Reservable Bandwidth 618 sub-TLV as well as the "Bandwidth Constraints" sub-TLV, where the 619 former should contain the aggregate bandwidth constraint across all 620 CTs and the latter would contain BC0 and BC1. 622 A DS-TE LSR receiving the "Bandwidth Constraints" sub-TLV with a 623 Bandwidth Constraints Model Id which does not match the Bandwidth 624 Constraints Model it currently uses, SHOULD generate a warning to the 625 operator/management-system reporting the inconsistency between 626 Bandwidth Constraints Models used on different links. Also, in that 627 case, if the DS-TE LSR does not support the Bandwidth Constraints 628 Model designated by the Bandwidth Constraints Model Id, or if the DS- 629 TE LSR does not support operations with multiple simultaneous 630 Bandwidth Constraints Models, the DS-TE LSR MAY discard the 631 corresponding TLV. If the DS-TE LSR does support the Bandwidth 632 Constraints Model designated by the Bandwidth Constraints Model Id 633 and if the DS-TE LSR does support operations with multiple 634 simultaneous Bandwidth Constraints Models, the DS-TE LSR MAY accept 635 the corresponding TLV and allow operations with different Bandwidth 636 Constraints Models used in different parts of the DS-TE domain. 638 5.2. Unreserved Bandwidth 640 With DS-TE, the existing "Unreserved Bandwidth" sub-TLV is retained 641 as the only vehicle to advertise dynamic bandwidth information 642 necessary for Constraint Based Routing on Head-ends, except that it 643 is used with a generalized semantic. The Unreserved Bandwidth sub-TLV 644 still carries eight bandwidth values but they now correspond to the 645 unreserved bandwidth for each of the TE-Class (instead of for each 646 preemption priority as per existing TE). 648 More precisely, a DS-TE LSR MUST support the Unreserved Bandwidth 649 sub-TLV with a definition which is generalized into the following: 651 The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth 652 not yet reserved for each of the eight TE-classes, in IEEE floating 653 point format arranged in increasing order of TE-Class index, with 655 Protocols for Diffserv-aware TE March 2004 657 unreserved bandwidth for TE-Class [0] occurring at the start of the 658 sub-TLV, and unreserved bandwidth for TE-Class [7] at the end of the 659 sub-TLV. The unreserved bandwidth value for TE-Class [i] ( 0 <= i <= 660 7) is referred to as "Unreserved TE-Class [i]". It indicates the 661 bandwidth that is available, for reservation, to an LSP which : 662 - transports a Traffic Trunk from the Class-Type of TE- 663 Class[i], and 664 - has a setup priority corresponding to the preemption priority 665 of TE-Class[i]. 667 The units are bytes per second. 669 Since the bandwidth values are now ordered by TE-class index and thus 670 can relate to different CTs with different bandwidth constraints and 671 can relate to any arbitrary preemption priority, a DS-TE LSR MUST NOT 672 assume any ordered relationship among these bandwidth values. 674 With existing TE, since all preemption priorities reflect the same 675 (and only) bandwidth constraints and since bandwidth values are 676 advertised in preemption priority order, the following relationship 677 is always true, and is often assumed by TE implementations: 679 If i < j , then "Unreserved Bw [i]" >= "Unreserved Bw [j]" 681 With DS-TE, no relationship is to be assumed so that: 682 If i < j , then any of the following relationship may be true 683 "Unreserved TE-Class [i]" = "Unreserved TE-Class [j]" 684 OR 685 "Unreserved TE-Class [i]" > "Unreserved TE-Class [j]" 686 OR 687 "Unreserved TE-Class [i]" < "Unreserved TE-Class [j]". 689 Rules for computing "Unreserved TE-Class [i]" are specified in 690 section 11. 692 If TE-Class[i] is unused, the value advertised by the IGP in 693 "Unreserved TE-Class [i]" MUST be set to zero by the LSR generating 694 the IGP advertisement, and MUST be ignored by the LSR receiving the 695 IGP advertisement. 697 6. RSVP-TE Extensions for DS-TE 699 In this section we describe extensions to RSVP-TE for support of 700 Diff-Serv-aware MPLS Traffic Engineering. These extensions are in 701 addition to the extensions to RSVP defined in [RSVP-TE] for support 702 of (aggregate) MPLS Traffic Engineering and to the extensions to RSVP 703 defined in [DIFF-MPLS] for support of Diff-Serv over MPLS. 705 Protocols for Diffserv-aware TE March 2004 707 6.1. DS-TE related RSVP Messages Format 709 One new RSVP Object is defined in this document: the CLASSTYPE 710 Object. Detailed description of this Object is provided below. This 711 new Object is applicable to Path messages. This specification only 712 defines the use of the CLASSTYPE Object in Path messages used to 713 establish LSP Tunnels in accordance with [RSVP-TE] and thus 714 containing a Session Object with a C-Type equal to LSP_TUNNEL_IPv4 715 and containing a LABEL_REQUEST object. 717 Restrictions defined in [RSVP-TE] for support of establishment of LSP 718 Tunnels via RSVP-TE are also applicable to the establishment of LSP 719 Tunnels supporting DS-TE. For instance, only unicast LSPs are 720 supported and Multicast LSPs are for further study. 722 This new CLASSTYPE object is optional with respect to RSVP so that 723 general RSVP implementations not concerned with MPLS LSP set up do 724 not have to support this object. 726 An LSR supporting DS-TE MUST support the CLASSTYPE Object. 728 6.1.1. Path Message Format 730 The format of the Path message is as follows: 732 ::= [ ] 733 734 735 [ ] 736 737 [ ] 738 [ ] 739 [ ] 740 [ ... ] 741 [ ] 743 ::= [ ] 744 [ ] 745 [ ] 747 6.2. CLASSTYPE Object 749 The CLASSTYPE object Class Name is CLASSTYPE. Its Class Number is 750 TBD. Currently, there is only one defined C_Type which is C_Type 1. 751 The CLASSTYPE object format is shown below. 753 To be removed by the RFC editor at the time of 754 publication: When the RSVP Class-Num is assigned by IANA 755 replace "TBD" 757 Protocols for Diffserv-aware TE March 2004 759 above by the assigned value. See IANA Considerations section 760 for allocation request. 761 763 6.2.1. CLASSTYPE object 765 Class Number = TBD 766 Class Type = 1 768 To be removed by the RFC editor at the time of 769 publication: When the RSVP Class Number is assigned by IANA 770 replace "TBD" 771 above by the assigned value. See IANA Considerations section 772 for allocation request. 773 775 0 1 2 3 776 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 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | Reserved | CT | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 Reserved : 29 bits 782 This field is reserved. It must be set to zero on transmission 783 and must be ignored on receipt. 785 CT : 3 bits 786 Indicates the Class-Type. Values currently allowed are 787 1, 2, ... , 7. Value of 0 is Reserved. 789 6.3. Handling CLASSTYPE Object 791 To establish an LSP tunnel with RSVP, the sender LSR creates a Path 792 message with a session type of LSP_Tunnel_IPv4 and with a 793 LABEL_REQUEST object as per [RSVP-TE]. The sender LSR may also 794 include the DIFFSERV object as per [DIFF-MPLS]. 796 If the LSP is associated with Class-Type 0, the sender LSR MUST NOT 797 include the CLASSTYPE object in the Path message. This allows 798 backward compatibility with non-DSTE-configured or non-DSTE-capable 799 LSRs as discussed below in section 10 and Appendix C. 801 If the LSP is associated with Class-Type N (1 <= N <=7), the sender 802 LSR MUST include the CLASSTYPE object in the Path message with the 803 Class-Type (CT) field set to N. 805 Protocols for Diffserv-aware TE March 2004 807 If a path message contains multiple CLASSTYPE objects, only the first 808 one is meaningful; subsequent CLASSTYPE object(s) MUST be ignored and 809 MUST NOT be forwarded. 811 Each LSR along the path MUST record the CLASSTYPE object, when 812 present, in its path state block. 814 If the CLASSTYPE object is not present in the Path message, the LSR 815 MUST associate the Class-Type 0 to the LSP. 817 The destination LSR responding to the Path message by sending a Resv 818 message MUST NOT include a CLASSTYPE object in the Resv message 819 (whether the Path message contained a CLASSTYPE object or not). 821 During establishment of an LSP corresponding to the Class-Type N, the 822 LSR MUST perform admission control over the bandwidth available for 823 that particular Class-Type. 825 An LSR that recognizes the CLASSTYPE object and that receives a path 826 message which: 827 - contains the CLASSTYPE object, but 828 - which does not contain a LABEL_REQUEST object or which does 829 not have a session type of LSP_Tunnel_IPv4, 830 MUST send a PathErr towards the sender with the error code "Diff- 831 Serv-aware TE Error" and an error value of "Unexpected CLASSTYPE 832 object". Those are defined below in section 6.5. 834 An LSR receiving a Path message with the CLASSTYPE object, which: 835 - recognizes the CLASSTYPE object, but 836 - does not support the particular Class-Type, 837 MUST send a PathErr towards the sender with the error code "Diff- 838 Serv-aware TE Error" and an error value of "Unsupported Class-Type". 839 Those are defined below in section 6.5. 841 An LSR receiving a Path message with the CLASSTYPE object, which: 842 - recognizes the CLASSTYPE object, but 843 - determines that the Class-Type value is not valid (i.e. 844 Class-Type value 0), 845 MUST send a PathErr towards the sender with the error code "Diff- 846 Serv-aware TE Error" and an error value of "Invalid Class-Type 847 value". Those are defined below in section 6.5. 849 An LSR receiving a Path message with the CLASSTYPE object, which: 850 - recognizes the CLASSTYPE object, 851 - supports the particular Class-Type, but 852 - determines that the tuple formed by (i) this Class-Type and 853 (ii) the set-up priority signaled in the same Path message, 854 is not one of the eight TE-classes configured in the TE-class 855 mapping, 857 Protocols for Diffserv-aware TE March 2004 859 MUST send a PathErr towards the sender with the error code "Diff- 860 Serv-aware TE Error" and an error value of "CT and setup priority do 861 not form a configured TE-Class". Those are defined below in section 862 6.5. 864 An LSR receiving a Path message with the CLASSTYPE object, which: 865 - recognizes the CLASSTYPE object, 866 - supports the particular Class-Type, but 867 - determines that the tuple formed by (i) this Class-Type and 868 (ii) the holding priority signaled in the same Path message, 869 is not one of the eight TE-classes configured in the TE-class 870 mapping, 871 MUST send a PathErr towards the sender with the error code "Diff- 872 Serv-aware TE Error" and an error value of "CT and holding priority 873 do not form a configured TE-Class". Those are defined below in 874 section 6.5. 876 An LSR receiving a Path message with the CLASSTYPE object and with 877 the DIFFSERV object for an L-LSP, which: 878 - recognizes the CLASSTYPE object, 879 - has local knowledge of the relationship between Class-Types 880 and PSC (e.g. via configuration) 881 - based on this local knowledge, determines that the PSC 882 signaled in the DIFFSERV object is inconsistent with the 883 Class-Type signaled in the CLASSTYPE object, 884 MUST send a PathErr towards the sender with the error code "Diff- 885 Serv-aware TE Error" and an error value of "Inconsistency between 886 signaled PSC and signaled CT". Those are defined below in section 887 6.5. 889 An LSR receiving a Path message with the CLASSTYPE object and with 890 the DIFFSERV object for an E-LSP, which: 891 - recognizes the CLASSTYPE object, 892 - has local knowledge of the relationship between Class-Types 893 and PHBs (e.g. via configuration) 894 - based on this local knowledge, determines that the PHBs 895 signaled in the MAP entries of the DIFFSERV object are 896 inconsistent with the Class-Type signaled in the CLASSTYPE 897 object, 898 MUST send a PathErr towards the sender with the error code "Diff- 899 Serv-aware TE Error" and an error value of "Inconsistency between 900 signaled PHBs and signaled CT". Those are defined below in section 901 6.5. 903 An LSR MUST handle the situations where the LSP can not be accepted 904 for other reasons than those already discussed in this section, in 905 accordance with [RSVP-TE] and [DIFF-MPLS] (e.g. a reservation is 906 rejected by admission control, a label can not be associated). 908 Protocols for Diffserv-aware TE March 2004 910 6.4. Non-support of the CLASSTYPE Object 912 An LSR that does not recognize the CLASSTYPE object Class-Num MUST 913 behave in accordance with the procedures specified in [RSVP] for an 914 unknown Class-Num whose format is 0bbbbbbb (i.e. it must send a 915 PathErr with the error code "Unknown object class" toward the 916 sender). 918 An LSR that recognizes the CLASSTYPE object Class-Num but does not 919 recognize the CLASSTYPE object C-Type, MUST behave in accordance with 920 the procedures specified in [RSVP] for an unknown C-type (i.e. it 921 must send a PathErr with the error code "Unknown object C-Type" 922 toward the sender). 924 In both situations, this causes the path set-up to fail. The sender 925 SHOULD notify the operator/management-system that an LSP cannot be 926 established and possibly might take action to retry reservation 927 establishment without the CLASSTYPE object. 929 6.5. Error Codes For Diff-Serv-aware TE 931 In the procedures described above, certain errors must be reported as 932 a "Diff-Serv-aware TE Error". The value of the "Diff-Serv-aware TE 933 Error" error code is (TBD)(). 935 To be removed by the RFC editor at the time of 936 publication: When the "Diff-Serv-aware TE Error" Error Code is 937 assigned by 938 IANA, replace "TBD" above by the assigned value. 939 See IANA Considerations section for allocation request. 940 941 The following defines error values for the Diff-Serv-aware TE Error: 943 Value Error 945 1 Unexpected CLASSTYPE object 946 2 Unsupported Class-Type 947 3 Invalid Class-Type value 948 4 Class-Type and setup priority do not form a configured 949 TE-Class 950 5 Class-Type and holding priority do not form a 951 configured TE-Class 952 6 Inconsistency between signaled PSC and signaled 953 Class-Type 954 7 Inconsistency between signaled PHBs and signaled 955 Class-Type 957 See the IANA Considerations section for allocation of additional 958 Values. 960 Protocols for Diffserv-aware TE March 2004 962 7. DS-TE support with MPLS extensions. 964 There are a number of extensions to the initial base specification 965 for signaling [RSVP-TE] and IGP support for TE [OSPF-TE][ISIS-TE]. 966 Those include enhancements for generalization [GMPLS-SIG] 967 [GMPLS-ROUTE], as well as for additional functionality such as LSP 968 hierarchy [HIERARCHY], link bundling [BUNDLE] and fast restoration 969 [REROUTE]. These specifications may reference how to encode 970 information associated with certain preemption priorities, how to 971 treat LSPs at different preemption priorities, or otherwise specify 972 encodings or behavior that have a different meaning for an DS-TE 973 router. 975 In order for an implementation to support both this specification for 976 Diff-Serv-aware TE and a given MPLS enhancement such as those listed 977 above (but not limited to those), it MUST treat references to 978 "preemption priority" and to "Maximum Reservable Bandwidth" in a 979 generalized manner, such as it is used in this specification. 981 Additionally, current and future MPLS enhancements may include more 982 precise specification for how they interact with Diff-Serv-aware TE. 984 7.1. DS-TE support and references to preemption priority 986 When a router supports both Diff-Serv-aware TE and one of the MPLS 987 protocol extensions such as those mentioned above, encoding of values 988 of preemption priority in signaling or encoding of information 989 associated with preemption priorities in IGP defined for the MPLS 990 extension, MUST be considered to be an encoding of the same 991 information for the corresponding TE-Class. For instance, if an MPLS 992 enhancement specifies advertisement in IGP of a parameter for routing 993 information at preemption priority N, in a DS-TE environment it MUST 994 actually be interpreted as specifying advertisement of the same 995 routing information but for TE-Class [N]. On receipt, DS-TE routers 996 MUST interpret it as such as well. 998 When there is discussion on how to comparatively treat LSPs of 999 different preemption priority, a DS-TE LSR MUST treat the preemption 1000 priorities in this context as the preemption priorities associated 1001 with the TE-Classes of the LSPs in question. 1003 7.2. DS-TE support and references to Maximum Reservable Bandwidth 1005 When a router supports both Diff-Serv-aware TE and MPLS protocol 1006 extensions such as those mentioned above, advertisements of Maximum 1007 Reservable Bandwidth MUST be done with the generalized interpretation 1008 defined above in section 4.1.1 as the aggregate bandwidth constraint 1010 Protocols for Diffserv-aware TE March 2004 1012 across all Class-Types and MAY also allow the optional advertisement 1013 of all Bandwidth Constraints. 1015 8. Constraint Based Routing 1017 Let us consider the case where a path needs to be computed for an LSP 1018 whose Class-Type is configured to CTc and whose set-up preemption 1019 priority is configured to p. 1021 Then the pair of CTc and p will map to one of the TE-Classes defined 1022 in the TE-Class mapping. Let us refer to this TE-Class as TE- 1023 Class[i]. 1025 The Constraint Based Routing algorithm of a DS-TE LSR is still only 1026 required to perform path computation satisfying a single bandwidth 1027 constraint which is to fit in "Unreserved TE-Class [i]" as advertised 1028 by the IGP for every link. Thus, no changes are required to the 1029 existing TE Constraint Based Routing algorithm itself. 1031 The Constraint Based Routing algorithm MAY also take into account, 1032 when used, the optional additional information advertised in IGP such 1033 as the Bandwidth Constraints and the Maximum Reservable Bandwidth. As 1034 an example, the Bandwidth Constraints MIGHT be used as a tie-breaker 1035 criteria in situations where multiple paths, otherwise equally 1036 attractive, are possible. 1038 9. Diff-Serv scheduling 1040 The Class-Type signaled at LSP establishment MAY optionally be used 1041 by DS-TE LSRs to dynamically adjust the resources allocated to the 1042 Class-Type by the Diff-Serv scheduler. In addition, the Diff-Serv 1043 information (i.e. the PSC) signaled by the TE-LSP signaling protocols 1044 as specified in [DIFF-MPLS], if used, MAY optionally be used by DS-TE 1045 LSRs to dynamically adjust the resources allocated to a PSC/OA within 1046 a Class Type by the Diff-Serv scheduler. 1048 10. Existing TE as a Particular Case of DS-TE 1050 We observe that existing TE can be viewed as a particular case of 1051 DS-TE where: 1053 (i) a single Class-Type is used, 1054 (ii) all 8 preemption priorities are allowed for that Class- 1055 Type, and 1056 (iii) the following TE-Class Mapping is used: 1057 TE-Class[i] <--> < CT0 , preemption i > 1059 Protocols for Diffserv-aware TE March 2004 1061 Where 0 <= i <= 7. 1063 In that case, DS-TE behaves as existing TE. 1065 As with existing TE, the IGP advertises: 1066 - Unreserved Bandwidth for each of the 8 preemption priorities 1068 As with existing TE, the IGP may advertise: 1069 - Maximum Reservable Bandwidth containing a bandwidth 1070 constraint applying across all LSPs 1072 Since all LSPs transport traffic from CT0, RSVP-TE signaling is done 1073 without explicit signaling of the Class-Type (which is only used for 1074 other Class-Types than CT0 as explained in section 6) as with 1075 existing TE. 1077 11. Computing "Unreserved TE-Class [i]" and Admission Control Rules 1079 11.1. Computing "Unreserved TE-Class [i]" 1081 We first observe that, for existing TE, details on admission control 1082 algorithms for TE LSPs, and consequently details on formulas for 1083 computing the unreserved bandwidth, are outside the scope of the 1084 current IETF work. This is left for vendor differentiation. Note that 1085 this does not compromise interoperability across various 1086 implementations since the TE schemes rely on LSRs to advertise their 1087 local view of the world in terms of Unreserved Bw to other LSRs. This 1088 way, regardless of the actual local admission control algorithm used 1089 on one given LSR, Constraint Based Routing on other LSRs can rely on 1090 advertised information to determine whether an additional LSP will be 1091 accepted or rejected by the given LSR. The only requirement is that 1092 an LSR advertises unreserved bandwidth values which are consistent 1093 with its specific local admission control algorithm and take into 1094 account the holding preemption priority of established LSPs. 1096 In the context of DS-TE, again, details on admission control 1097 algorithms are left for vendor differentiation and formulas for 1098 computing the unreserved bandwidth for TE-Class[i] are outside the 1099 scope of this specification. However, DS-TE places the additional 1100 requirement on the LSR that the unreserved bandwidth values 1101 advertised MUST reflect all of the Bandwidth Constraints relevant to 1102 the CT associated with TE-Class[i] in accordance with the Bandwidth 1103 Constraints Model. Thus, formulas for computing "Unreserved TE-Class 1104 [i]" depend on the Bandwidth Constraints Model in use and MUST 1105 reflect how bandwidth constraints apply to CTs. Example formulas for 1106 computing "Unreserved TE-Class [i]" Model are provided for the 1108 Protocols for Diffserv-aware TE March 2004 1110 Russian Dolls Model and Maximum Allocation Model respectively in 1111 [DSTE-RDM] and [DSTE-MAM]. 1113 As with existing TE, DS-TE LSRs MUST consider the holding preemption 1114 priority of established LSPs (as opposed to their set-up preemption 1115 priority) for the purpose of computing the unreserved bandwidth for 1116 TE-Class [i]. 1118 11.2. Admission Control Rules 1120 A DS-TE LSR MUST support the following admission control rule: 1122 Regardless of how the admission control algorithm actually computes 1123 the unreserved bandwidth for TE-Class[i] for one of its local link, 1124 an LSP of bandwidth B, of set-up preemption priority p and of Class- 1125 Type CTc is admissible on that link if, and only if,: 1127 B <= Unreserved Bandwidth for TE-Class[i] 1129 Where 1131 - TE-Class [i] maps to < CTc , p > in the TE-Class mapping 1132 configured on the LSR. 1134 12. Security Considerations 1136 This document does not introduce additional security threats beyond 1137 those described for Diff-Serv ([DIFF-ARCH]) and MPLS Traffic 1138 Engineering ([TE-REQ], [RSVP-TE], [OSPF-TE], [ISIS-TE]) and the same 1139 security measures and procedures described in these documents apply 1140 here. For example, the approach for defense against theft- and 1141 denial-of-service attacks discussed in [DIFF-ARCH], which consists of 1142 the combination of traffic conditioning at DS boundary nodes along 1143 with security and integrity of the network infrastructure within a 1144 Diff-Serv domain, may be followed when DS-TE is in use. Also, as 1145 stated in [TE-REQ], it is specifically important that manipulation of 1146 administratively configurable parameters (such as those related to 1147 DS-TE LSPs) be executed in a secure manner by authorized entities. 1149 13. Acknowledgments 1151 We thank Martin Tatham, Angela Chiu and Pete Hicks for their earlier 1152 contribution in this work. We also thank Sanjaya Choudhury for his 1153 thorough review and suggestions. 1155 Protocols for Diffserv-aware TE March 2004 1157 14. IANA Considerations 1159 This document creates two new name spaces which are to be managed by 1160 IANA. Also, a number of assignments from existing name spaces have 1161 been made by IANA in this document. Those are discussed below. 1163 14.1. A new name space for Bandwidth Constraints Model Identifiers 1165 This document defines in section 5.1 a "Bandwidth Constraints Model 1166 Id" field (name space) within the "Bandwidth Constraints" sub-TLV, 1167 both for OSPF and ISIS. IANA is requested to create and maintain this 1168 new name space. The field for this namespace is 1 octet, and IANA 1169 guidelines for assignments for this field are as follows: 1171 o values in the range 0-127 are to be assigned according to 1172 the "Specification Required" policy defined in [IANA-CONS]. 1174 o values in the range 128-239 are not to be assigned at this 1175 time. Before any assignments can be made in this range, there MUST be 1176 a Standards Track RFC that specifies IANA Considerations that cover 1177 assignment within that range. 1179 o values in the range 240-255 are for experimental use; these 1180 will not be registered with IANA, and MUST NOT be mentioned by RFCs. 1182 14.2. A new name space for Error Values under the "Diff-Serv-aware TE 1183 Error" 1185 An Error Code is an 8-bit quantity defined in [RSVP] that appears in 1186 an ERROR_SPEC object to broadly define an error condition. With each 1187 Error Code there may be a 16-bit Error Value (which depends on the 1188 Error Code) that further specifies the cause of the error. 1190 This document defines in section 6.5 a new RSVP error code, the 1191 "Diff-Serv-aware TE Error" (see section 14.3.4). The Error Values for 1192 the "Diff-Serv-aware TE Error" constitute a new name space to be 1193 managed by IANA. 1195 This document defines, in section 6.5, values 1 through 7 in that 1196 name space (see section 14.3.5). 1198 Future allocations of values in this name space are to be assigned by 1199 IANA using the "Specification Required" policy defined in [IANA- 1200 CONS]. 1202 14.3. Assignments made in this Document 1204 14.3.1. Bandwidth Constraints sub-TLV for OSPF version 2 1206 Protocols for Diffserv-aware TE March 2004 1208 [OSPF-TE] creates a name space for the sub-TLV types within the "Link 1209 TLV" of the Traffic Engineering LSA and rules for management of this 1210 name space by IANA. 1212 This document defines in section 5.1 a new sub-TLV, the "Bandwidth 1213 Constraints" sub-TLV, for the OSPF "Link" TLV. In accordance with the 1214 IANA considerations provided in [OSPF-TE], a sub-TLV type in the 1215 range 10 to 32767 was requested and the value TBD has been assigned 1216 by IANA for the "Bandwidth Constraints" sub-TLV. 1218 To be removed by the RFC editor at the time of 1219 publication: When the sub-TLV Type is assigned by IANA replace 1220 "TBD" above 1221 by the assigned value. 1222 1223 14.3.2. Bandwidth Constraints sub-TLV for ISIS 1225 [ISIS-TE] creates a name space for the sub-TLV types within the ISIS 1226 "Extended IS Reachability" TLV and rules for management of this name 1227 space by IANA. 1229 This document defines in section 5.1 a new sub-TLV, the "Bandwidth 1230 Constraints" sub-TLV, for the ISIS "Extended IS Reachability" TLV. In 1231 accordance with the IANA considerations provided in [ISIS-TE], a sub- 1232 TLV type was requested and the value TBD has been assigned by IANA 1233 for the "Bandwidth Constraints" sub-TLV. 1235 To be removed by the RFC editor at the time of 1236 publication: When the sub-TLV Type is assigned by IANA replace 1237 "TBD" above 1238 by the assigned value. 1239 1240 14.3.3. CLASSTYPE object for RSVP 1242 [RSVP] defines the Class Number name space for RSVP object which is 1243 managed by IANA. Currently allocated Class Numbers are listed at 1244 "http://www.iana.org/assignments/rsvp-parameters" 1246 This document defines in section 6.2.1 a new RSVP object, the 1247 CLASSTYPE object. IANA was requested to assign a Class Number for 1248 this RSVP object from the range defined in section 3.10 of [RSVP] for 1249 those objects which, if not understood, cause the entire RSVP message 1250 to be rejected with an error code of "Unknown Object Class". Such 1251 objects are identified by a zero in the most significant bit of the 1252 class number (i.e. 1253 Class-Num = 0bbbbbbb). 1254 IANA assigned Class-Number TBD to the CLASSTYPE object. C_Type 1 is 1255 defined in this document for the CLASSTYPE object. 1257 Protocols for Diffserv-aware TE March 2004 1259 To be removed by the RFC editor at the time of 1260 publication: When the RSVP Class-Num is assigned by IANA 1261 replace "TBD" 1262 above by the assigned value. 1263 1264 14.3.4. "Diff-Serv-aware TE Error" Error Code 1266 [RSVP] defines the Error Code name space and rules for management of 1267 this name space by IANA. Currently allocated Error Codes are listed 1268 at "http://www.iana.org/assignments/rsvp-parameters" 1270 This document defines in section 6.5 a new RSVP Error Code, the 1271 "Diff-Serv-aware TE Error". In accordance with the IANA 1272 considerations provided in [RSVP], Error Code TBD was assigned by 1273 IANA to the "Diff-Serv-aware TE Error". 1275 To be removed by the RFC editor at the time of 1276 publication: When the RSVP Class-Num is assigned by IANA 1277 replace "TBD" 1278 above by the assigned value. 1279 1280 14.3.5. Error Values for "Diff-Serv-aware TE Error" 1282 An Error Code is an 8-bit quantity defined in [RSVP] that appears in 1283 an ERROR_SPEC object to broadly define an error condition. With each 1284 Error Code there may be a 16-bit Error Value (which depends on the 1285 Error Code) that further specifies the cause of the error. 1287 This document defines in section 6.5 a new RSVP error code, the 1288 "Diff-Serv-aware TE Error" (see section 14.3.4). The Error Values for 1289 the "Diff-Serv-aware TE Error" constitute a new name space to be 1290 managed by IANA. 1292 This document defines, in section 6.5, the following Error Values for 1293 the "Diff-Serv-aware TE Error": 1295 Value Error 1297 1 Unexpected CLASSTYPE object 1298 2 Unsupported Class-Type 1299 3 Invalid Class-Type value 1300 4 Class-Type and setup priority do not form a configured 1301 TE-Class 1302 5 Class-Type and holding priority do not form a 1303 configured TE-Class 1304 6 Inconsistency between signaled PSC and signaled 1305 Class-Type 1306 7 Inconsistency between signaled PHBs and signaled 1307 Class-Type 1309 Protocols for Diffserv-aware TE March 2004 1311 See section 14.2 for allocation of other values in that name space. 1313 15. Intellectual Property Considerations 1315 The IETF takes no position regarding the validity or scope of any 1316 intellectual property or other rights that might be claimed to 1317 pertain to the implementation or use of the technology described in 1318 this document or the extent to which any license under such rights 1319 might or might not be available; neither does it represent that it 1320 has made any effort to identify any such rights. Information on the 1321 IETF's procedures with respect to rights in standards-track and 1322 standards-related documentation can be found in RFC 2028. Copies of 1323 claims of rights made available for publication and any assurances of 1324 licenses to be made available, or the result of an attempt made to 1325 obtain a general license or permission for the use of such 1326 proprietary rights by implementors or users of this specification can 1327 be obtained from the IETF Secretariat. 1329 The IETF invites any interested party to bring to its attention any 1330 copyrights, patents or patent applications, or other proprietary 1331 rights which may cover technology that may be required to practice 1332 this standard. Please address the information to the IETF Executive 1333 Director. 1335 16. Normative References 1337 [DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv- 1338 aware MPLS Traffic Engineering, RFC3564, . 1340 [MPLS-ARCH] Rosen et al., "Multiprotocol Label Switching 1341 Architecture", RFC3031. 1343 [DIFF-ARCH] Blake et al., "An Architecture for Differentiated 1344 Services", RFC2475. 1346 [TE-REQ] Awduche et al., "Requirements for Traffic Engineering Over 1347 MPLS", RFC2702. 1349 [OSPF-TE] Katz et al., "Traffic Engineering (TE) Extensions to OSPF 1350 Version 2", RFC3630. 1352 [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft- 1353 ietf-isis-traffic-05.txt, work in progress. 1355 Protocols for Diffserv-aware TE March 2004 1357 [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 1358 Tunnels", RFC 3209. 1360 [RSVP] Braden et al, "Resource ReSerVation Protocol (RSVP) - Version 1361 1 Functional Specification", RFC 2205. 1363 [DIFF-MPLS] Le Faucheur et al, "MPLS Support of Diff-Serv", RFC3270. 1365 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 1366 Requirement Levels, RFC2119. 1368 [IANA-CONS], T. Narten et al, "Guidelines for Writing an IANA 1369 Considerations Section in RFCs", RFC2434. 1371 17. Informative References 1373 [DSTE-RDM] Le Faucheur et al., "Russian Dolls Bandwidth Constraints 1374 Model for DS-TE", draft-ietf-tewg-diff-te-russian-04.txt, work in 1375 progress. 1377 [DSTE-MAM] Le Faucheur, Lai, "Maximum Allocation Bandwidth 1378 Constraints Model for DS-TE", draft-ietf-tewg-diff-te-mam-02.txt, 1379 work in progress . 1381 [DSTE-MAR] Ash, "Max Allocation with Reservation Bandwidth 1382 Constraints Model for MPLS/DiffServ TE & Performance Comparisons", 1383 draft-ietf-tewg-diff-te-mar-03.txt, work in progress . 1385 [GMPLS-SIG] Berger et. al., "Generalized Multi-Protocol Label 1386 Switching (GMPLS) Signaling Functional Description", RFC3471 1388 [GMPLS-ROUTE] Kompella et. al., "Routing Extensions in Support of 1389 Generalized MPLS", draft-ietf-ccamp-gmpls-routing-09.txt, work in 1390 progress. 1392 [BUNDLE] Kompella, Rekhter, Berger, "Link Bundling in MPLS Traffic 1393 Engineering", draft-ietf-mpls-bundle-04.txt, work in progress. 1395 [HIERARCHY] Kompella, Rekhter, "LSP Hierarchy with Generalized MPLS 1396 TE", draft-ietf-mpls-lsp-hierarchy-08.txt, work in progress. 1398 [REROUTE] Pan et. al., "Fast Reroute Extensions to RSVP-TE for LSP 1399 Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt, work in 1400 progress. 1402 18. Editor's Address: 1404 Protocols for Diffserv-aware TE March 2004 1406 Francois Le Faucheur 1407 Cisco Systems, Inc. 1408 Village d'Entreprise Green Side - Batiment T3 1409 400, Avenue de Roumanille 1410 06410 Biot-Sophia Antipolis 1411 France 1412 Phone: +33 4 97 23 26 19 1413 Email: flefauch@cisco.com 1415 19. Full Copyright Statement 1417 Copyright (C) The Internet Society (2004). All Rights Reserved. 1419 This document and translations of it may be copied and furnished to 1420 others, and derivative works that comment on or otherwise explain it 1421 or assist in its implementation may be prepared, copied, published 1422 and distributed, in whole or in part, without restriction of any 1423 kind, provided that the above copyright notice and this paragraph are 1424 included on all such copies and derivative works. However, this 1425 document itself may not be modified in any way, such as by removing 1426 the copyright notice or references to the Internet Society or other 1427 Internet organizations, except as needed for the purpose of 1428 developing Internet standards in which case the procedures for 1429 copyrights defined in the Internet Standards process must be 1430 followed, or as required to translate it into languages other than 1431 English. 1433 The limited permissions granted above are perpetual and will not be 1434 revoked by the Internet Society or its successors or assigns. 1436 This document and the information contained herein is provided on an 1437 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1438 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1439 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1440 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1441 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1443 Appendix A - Prediction for Multiple Path Computation 1445 There are situations where a Head-End needs to compute paths for 1446 multiple LSPs over a short period of time. There are potential 1447 advantages for the Head-end in trying to predict the impact of the n- 1448 th LSP on the unreserved bandwidth when computing the path for the 1449 (n+1)-th LSP, before receiving updated IGP information. One example 1450 would be to perform better load-distribution of the multiple LSPs 1451 across multiple paths. Another example would be to avoid CAC 1452 rejection when the (n+1)-th LSP would no longer fit on a link after 1454 Protocols for Diffserv-aware TE March 2004 1456 establishment of the n-th LSP. While there are also a number of 1457 conceivable scenarios where doing such predictions might result in a 1458 worse situation, it is more likely to improve the situation. As a 1459 matter of fact, a number of network administrators have elected to 1460 use such predictions when deploying existing TE. 1462 Such predictions are local matters, are optional and are outside the 1463 scope of this specification. 1465 Where such predictions are not used, the optional Bandwidth 1466 Constraint sub-TLV and the optional Maximum Reservable Bandwidth sub- 1467 TLV need not be advertised in IGP for the purpose of path computation 1468 since the information contained in the Unreserved Bw sub-TLV is all 1469 that is required by Head-Ends to perform Constraint Based Routing. 1471 Where such predictions are used on Head-Ends, the optional Bandwidth 1472 Constraints sub-TLV and the optional Maximum Reservable Bandwidth 1473 sub-TLV MAY be advertised in IGP. This is in order for the Head-ends 1474 to predict as accurately as possible how an LSP affects unreserved 1475 bandwidth values for subsequent LSPs. 1477 Remembering that actual admission control algorithms are left for 1478 vendor differentiation, we observe that predictions can only be 1479 performed effectively when the Head-end LSR predictions are based on 1480 the same (or a very close) admission control algorithm as used by 1481 other LSRs. 1483 Appendix B - Solution Evaluation 1485 1. Satisfying Detailed Requirements 1487 This DS-TE Solution addresses all the scenarios presented in [DSTE- 1488 REQ]. 1490 It also satisfies all the detailed requirements presented in [DSTE- 1491 REQ]. 1493 The objective set out in the last paragraph of section "4.7 1494 overbooking" of [DSTE-REQ] is only partially addressed by this DS-TE 1495 solution. Through support of the "LSP Size Overbooking" and "Link 1496 Size Overbooking" methods, this DS-TE solution effectively allows CTs 1497 to have different overbooking ratios and simultaneously allows 1498 overbooking to be tweaked differently (collectively across all CTs) 1499 on different links. But, in a general sense, it does not allow the 1500 effective overbooking ratio of every CT to be tweaked differently in 1501 different parts of the network independently of other CTs, while 1502 maintaining accurate bandwidth accounting of how different CTs 1504 Protocols for Diffserv-aware TE March 2004 1506 mutually affect each other through shared Bandwidth Constraints (such 1507 as the Maximum Reservable Bandwidth). 1509 2. Flexibility 1511 This DS-TE solution supports 8 CTs. It is entirely flexible as to how 1512 Traffic Trunks are grouped together into a CT. 1514 3. Extendibility 1516 A maximum of 8 CTs is considered by the authors of this document as 1517 more than comfortable. A maximum of 8 TE-classes is considered by the 1518 authors of this document as sufficient. However, this solution could 1519 be extended to support more CTs or more TE-classes if deemed 1520 necessary in the future; This would necessitate additional IGP 1521 extensions beyond those specified in this document. 1523 Although the prime objective of this solution is support of Diff- 1524 Serv-aware Traffic Engineering, its mechanisms are not tightly 1525 coupled with Diff-Serv. This makes the solution amenable, or more 1526 easily extendable, for support of potential other future Traffic 1527 Engineering applications. 1529 4. Scalability 1531 This DS-TE solution is expected to have a very small scalability 1532 impact compared to existing TE. 1534 From an IGP viewpoint, the amount of mandatory information to be 1535 advertised is identical to existing TE. One additional sub-TLV has 1536 been specified, but its use is optional and it only contains a 1537 limited amount of static information (at most 8 Bandwidth 1538 Constraints). 1540 We expect no noticeable impact on LSP Path computation since, as with 1541 existing TE, this solution only requires CSPF to consider a single 1542 unreserved bandwidth value for any given LSP. 1544 From a signaling viewpoint we expect no significant impact due to 1545 this solution since it only requires processing of one additional 1546 information (the Class-Type) and does not significantly increase the 1547 likelihood of CAC rejection. Note that DS-TE has some inherent impact 1548 on LSP signaling in the sense that it assumes that different classes 1549 of traffic are split over different LSPs so that more LSPs need to be 1550 signaled; but this is due to the DS-TE concept itself and not to the 1551 actual DS-TE solution discussed here. 1553 5. Backward Compatibility/Migration 1555 Protocols for Diffserv-aware TE March 2004 1557 This solution is expected to allow smooth migration from existing TE 1558 to DS-TE. This is because existing TE can be supported as a 1559 particular configuration of DS-TE. This means that an "upgraded" LSR 1560 with a DS-TE implementation can directly interwork with an "old" LSR 1561 supporting existing TE only. 1563 This solution is expected to allow smooth migration when increasing 1564 the number of CTs actually deployed since it only requires 1565 configuration changes. however, these changes must be performed in a 1566 coordinated manner across the DS-TE domain. 1568 Appendix C - Interoperability with non DS-TE capable LSRs 1570 This DSTE solution allows operations in a hybrid network where some 1571 LSRs are DS-TE capable while some LSRs are not DS-TE capable, which 1572 may occur during migration phases. This Appendix discusses the 1573 constraints and operations in such hybrid networks. 1575 We refer to the set of DS-TE capable LSRs as the DS-TE domain. We 1576 refer to the set of non DS-TE capable (but TE capable) LSRs as the 1577 TE-domain. 1579 Hybrid operations requires that the TE-class mapping in the DS-TE 1580 domain is configured so that: 1581 - a TE-class exist for CT0 for every preemption priority 1582 actually used in the TE domain 1583 - the index in the TE-class mapping for each of these TE- 1584 classes is equal to the preemption priority. 1586 For example, imagine the TE domain uses preemption 2 and 3. Then, DS- 1587 TE can be deployed in the same network by including the following TE- 1588 classes in the TE-class mapping: 1589 i <---> CT preemption 1590 ==================================== 1591 2 CT0 2 1592 3 CT0 3 1594 Another way to look at this is to say that, the whole TE-class 1595 mapping does not have to be consistent with the TE domain, but the 1596 subset of this TE-Class mapping applicable to CT0 must effectively be 1597 consistent with the TE domain. 1599 Hybrid operations also requires that: 1600 - non DS-TE capable LSRs be configured to advertise the Maximum 1601 Reservable Bandwidth 1602 - DS-TE capable LSRs be configured to advertise Bandwidth 1603 Constraints (using the Max Reservable Bandwidth sub-TLV as 1605 Protocols for Diffserv-aware TE March 2004 1607 well as the Bandwidth Constraints sub-TLV, as specified in 1608 section 5.1 above). 1609 This allows DS-TE capable LSRs to unambiguously identify non DS-TE 1610 capable LSRs. 1612 Finally hybrid operations require that non DS-TE capable LSRs be able 1613 to accept Unreserved Bw sub-TLVs containing non decreasing bandwidth 1614 values (ie with Unreserved [p] < Unreserved [q] with p CT preemption 1639 ==================================== 1640 0 CT1 0 1641 1 CT1 1 1642 2 CT0 2 1643 3 CT0 3 1644 rest unused 1646 LSR0 is configured with a Max Reservable bandwidth=m01 for Link01. 1647 LSR1 is configured with a BC0=x0 a BC1=x1(possibly=0), and a Max 1648 Reservable Bandwidth=m10(possibly=m01) for Link01. 1650 LSR0 will advertise in IGP for Link01: 1651 - Max Reservable Bw sub-TLV = 1652 - Unreserved Bw sub-TLV = 1653 1655 Protocols for Diffserv-aware TE March 2004 1657 On receipt of such advertisement, LSR1 will: 1658 - understand that LSR0 is not DS-TE capable because it 1659 advertised a Max Reservable Bw sub-TLV and no Bandwidth 1660 Constraints sub-TLV 1661 - conclude that only CT0 LSPs can transit via LSR0 and that 1662 only the values CT0/2 and CT0/3 are meaningful in the 1663 Unreserved Bw sub-TLV. LSR1 may effectively behave as if the 1664 six other values contained in the Unreserved Bw sub-TLV were 1665 set to zero. 1667 LSR1 will advertise in IGP for Link01: 1668 - Max Reservable Bw sub-TLV = 1669 - Bandwidth Constraints sub-TLV = 1670 - Unreserved Bw sub-TLV = 1672 On receipt of such advertisement, LSR0 will: 1673 - Ignore the Bandwidth Constraints sub-TLV (unrecognized) 1674 - Correctly process CT0/2 and CT0/3 in the Unreserved Bw sub- 1675 TLV and use these values for CTO LSP establishment 1676 - Incorrectly believe that the other values contained in the 1677 Unreserved Bw sub-TLV relates to other preemption priorities 1678 for CT0, but will actually never use those since we assume 1679 that only preemption 2 and 3 are used in the TE domain.