idnits 2.17.1 draft-ietf-tewg-diff-te-proto-00.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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1849 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 914: '...is specification MUST support the CLAS...' RFC 2119 keyword, line 915: '...ype value 1, and MAY support other Cla...' RFC 2119 keyword, line 1049: '... An LSR MUST handle the situations wh...' RFC 2119 keyword, line 1125: '...is specification MUST support the Clas...' RFC 2119 keyword, line 1126: '...ype value 1, and MAY support other Cla...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 91 has weird spacing: '...rned by a spe...' == Line 530 has weird spacing: '...ionship is t...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'TE-REQ' is mentioned on line 190, but not defined == Missing Reference: 'DSTE-REQTS' is mentioned on line 118, but not defined -- Looks like a reference, but probably isn't: '0' on line 563 -- Looks like a reference, but probably isn't: '1' on line 563 -- Looks like a reference, but probably isn't: '2' on line 400 -- Looks like a reference, but probably isn't: '3' on line 401 -- Looks like a reference, but probably isn't: '7' on line 507 == Missing Reference: 'RSVP' is mentioned on line 1064, but not defined == Missing Reference: 'LDP' is mentioned on line 1266, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-tewg-diff-te-reqts-03 ** Downref: Normative reference to an Informational draft: draft-ietf-tewg-diff-te-reqts (ref. 'DSTE-REQ') == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-06 == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-04 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'ISIS-TE') ** Downref: Normative reference to an Unknown state RFC: RFC 32 (ref. 'CR-LDP') Summary: 10 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Francois Le Faucheur, Editor 3 Thomas Nadeau 4 Cisco Systems, Inc. 6 Jim Boyle 7 PDNets 9 Kireeti Kompella 10 Juniper Networks 12 William Townsend 13 Tenor Networks 15 Darek Skalecki 16 Nortel Networks 18 IETF Internet Draft 19 Expires: August, 2002 20 Document: draft-ietf-tewg-diff-te-proto-00.txt February, 2002 22 Protocol extensions for support of 23 Diff-Serv-aware MPLS Traffic Engineering 25 Status of this Memo 27 This document is an Internet-Draft and is in full conformance with 28 all provisions of Section 10 of RFC2026. Internet-Drafts are 29 Working documents of the Internet Engineering Task Force (IETF), its 30 areas, and its working groups. Note that other groups may also 31 distribute working documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 Abstract 45 This document specifies the IGP and signaling extensions and 46 procedures (beyond those already specified for existing MPLS Traffic 47 Engineering) for support of Diff-Serv-aware MPLS Traffic Engineering. 49 Le Faucheur, et. al 1 51 Protocols for Diff-Serv-aware TE February 2002 53 A Bandwidth Constraints model for Diff-Serv-aware Traffic Engineering 54 is also specified. 56 1. Introduction 58 [DSTE-REQ] presents the Service Providers requirements for support of 59 Diff-Serv-aware MPLS Traffic Engineering (DS-TE). This includes the 60 fundamental requirement to be able to enforce different bandwidth 61 constraints for different classes of traffic. 63 This document specifies: 64 - the IGP and signaling extensions and procedures (beyond those 65 already specified for existing MPLS Traffic Engineering 66 [OSPF-TE][ISIS-TE][RSVP-TE][CR-LDP]) for support of the DS-TE 67 requirements [DSTE-REQ] in environments relying on 68 distributed Constraint Based Routing (i.e. path computation 69 involving Head-end LSRs). 70 - A Bandwidth Constraint Model for DS-TE called the Russian 71 Dolls model. While Diff-Serv-aware implementations may 72 support other Bandwidth Constraints model, they must all 73 support the Russian Dolls model to ensure interoperability 74 across all implementations. 76 2. Definitions 78 [DSTE-REQ] discusses how a Head-end LSR may split the set of Ordered 79 Aggregates from the traffic to a given Tail-end into multiple Traffic 80 Trunks. Each Traffic Trunk is transported over a separate LSP which 81 is Constraint Based Routed individually. 83 For readability a number of definitions from [DSTE-REQ] are repeated 84 here: 86 Traffic Trunk: an aggregation of traffic flows of the same class 87 [i.e. which are to be treated equivalently from the DS-TE 88 perspective] which are placed inside a Label Switched Path. 90 Class-Type (CT): the set of Traffic Trunks crossing a link that is 91 governed by a specific set of Bandwidth constraints. CT is used for 92 the purposes of link bandwidth allocation, constraint based routing 93 and admission control. A given Traffic Trunk belongs to the same CT 94 on all links. 96 TE-Class: A pair of: 97 i. a Class-Type 98 ii. a preemption priority allowed for that Class-Type. This 99 means that an LSP transporting a Traffic Trunk from 100 that Class-Type can use that preemption priority as the 101 set-up priority, as the holding priority or both. 103 Le Faucheur et. al 2 105 Protocols for Diff-Serv-aware TE February 2002 107 3. Configurable Parameters 109 This section only discusses the differences with the configurable 110 parameters supported for MPLS Traffic Engineering as per [TE-REQ], 111 [ISIS-TE], [OSPF-TE], [RSVP-TE] and [CR-LDP]. All other parameters 112 are unchanged. 114 3.1. Link Parameters 116 3.1.1. Bandwidth Constraints (BCs) 118 [DSTE-REQTS] states that "Regardless of the Bandwidth Constraint 119 Model, the DS-TE solution must allow support for up to 8 BCs." 121 For DS-TE, the existing "Maximum Reservable link bandwidth" parameter 122 is retained but its semantic is generalized and interpreted as BC0. 124 Additionally, on every link, a DS-TE implementation must provide for 125 configuration of up to 7 additional link parameters which are the 126 seven other potential Bandwidth Constraints i.e. BC1, BC2 , ... BC7. 128 The LSR is responsible for interpreting these Bandwidth Constraints 129 in accordance with the supported Bandwidth Constraint Model (i.e. 130 what bandwidth constraint applies to what Class-Type and how). At any 131 one time, all LSRs of the DS-TE domain must support the same 132 Bandwidth Constraint Model. 134 Where the Bandwidth Constraint Model imposes some relationship among 135 the values to be configured for these Bandwidth Constraints, the LSR 136 is responsible for enforcing those at configuration time. For 137 example, with the "Russian Doll" Bandwidth Constraints Model defined 138 below in section 9, the LSR must ensure that BCi is configured 139 smaller or equal to BCj, where i is greater than j. 141 3.1.2. per-CT Local Overbooking Multiplier 143 DS-TE enables a network administrator to apply different overbooking 144 (or underbooking) ratios for different CTs. 146 The principal method to achieve this is the same as historically used 147 in existing TE deployment which is to take into account the over- 148 booking ratio appropriate for the OA/CT associated with the 149 considered LSP at the time of establishing the bandwidth size of a 150 given LSP. We refer to this as the "LSP size overbooking" method. 152 Since the overbooking ratio is factored into the LSP bandwidth (which 153 is invariable across all the links spanned by the LSP), using the 154 "LSP size overbooking" method alone effectively has the following 155 characteristics: 157 Le Faucheur et. al 3 159 Protocols for Diff-Serv-aware TE February 2002 161 - different overbooking ratios can effectively be enforced for 162 different CTs (by using a different overbooking ratios for 163 LSPs of different CTs) 164 - the overbooking ratio is the same on all links for a given CT 165 - the overbooking ratios can even be fine-tuned on a per-LSP 166 basis (i.e. different LSPs of the same CT may be sized based 167 on overbooking ratios which are tweaked differently). 169 The "LSP size overbooking" method is expected to be often sufficient 170 in many DS-TE environments and requires no additional configurable 171 parameters. 173 However, in the particular DS-TE environments where, for a given CT, 174 the overbooking ratio needs to be tweaked differently on different 175 links, a DS-TE implementation may allow the "LSP size overbooking" 176 method to be complemented by the use of the "local overbooking" 177 method. The "local overbooking" method relies on optional "per-CT 178 Local Overbooking Multipliers" which are configurable, on every link, 179 for every CT. The per-CT Local Overbooking Multiplier effectively 180 allows the network operator to increase/decrease", on some links, the 181 overbooking ratio already enforced by the "LSP size overbooking" 182 method. This is achieved by factoring the per-CT Local Overbooking 183 Multiplier in all local bandwidth accounting for the purposes of 184 admission control and IGP advertisement of unreserved bandwidths. 186 3.2. LSR Parameters 188 3.2.1. TE-Class Mapping 190 In line with [DSTE-REQ], the preemption attributes defined in [TE- 191 REQ] are retained with DS-TE and applicable across all Class Types. 192 The preemption attributes of setup priority and holding priority 193 retain existing semantics, and in particular these semantics are not 194 affected by the Ordered Aggregate transported by the LSP or by the 195 LSP's Class Type. This means that if LSP1 contends with LSP2 for 196 resources, LSP1 may preempt LSP2 if LSP1 has a higher set-up 197 preemption priority (i.e. lower numerical priority value) than LSP2's 198 holding preemption priority regardless of LSP1's OA/CT and LSP2's 199 OA/CT. 201 For DS-TE, LSRs must allow configuration of a TE-Class mapping 202 whereby the Class-Type and preemption level are configured for each 203 of (up to) 8 TE-Classes. 205 This mapping is referred to as : 207 TE-Class[i] <--> < CTc , preemption p > 209 Where 0 <= i <= 7, 0 <= c <= 7, 0 <= p <= 7 211 Le Faucheur et. al 4 213 Protocols for Diff-Serv-aware TE February 2002 215 Two TE-Classes must not be identical (i.e. have both the same Class- 216 Type and the same preemption priority). 218 Where the network administrator uses less than 8 TE-Classes, the 219 remaining ones must be configured as "Unused". 221 There are no other restrictions on how any of the 8 Class-Types can 222 be paired up with any of the 8 preemption priorities to form a TE- 223 class. In particular, one given preemption priority can be paired up 224 with two (or more) different Class-Types to form two (or more) TE- 225 classes. Similarly, one Class-Type can be paired up with two (or 226 more) different preemption priorities to form two (or more) TE- 227 Classes. Also, there is no mandatory ordering relationship between 228 the TE-Class index (i.e. "i" above) and the Class-Type (i.e. "c" 229 above) or the preemption priority (i.e. "p" above) of the TE-Class. 231 To ensure coherent DS-TE operation, the network administrator must 232 configure exactly the same TE-Class Mapping on all LSRs of the DS-TE 233 domain. 235 3.3. LSP Parameters 237 3.3.1. Class-Type 239 With DS-TE, LSRs must support, for every LSP, an additional 240 configurable parameter which indicates the Class-Type of the Traffic 241 Trunk transported by the LSP. 243 There is one and only one Class-Type configured per LSP. 245 The configured Class-Type indicates, in accordance with the supported 246 Bandwidth Constraint Model, what are the Bandwidth Constraints 247 applicable to that LSP. 249 3.3.2. Setup and Holding Preemption Priorities 251 As per existing TE, DS-TE assumes that every DS-TE LSP is configured 252 with a setup and holding priority, each with a value between 0 and 7. 254 3.3.3. Class-Type/Preemption Relationship 256 With DS-TE, the preemption priority configured for the setup priority 257 of a given LSP and the Class-Type configured for that LSP must be 258 such that, together, they form one of the (up to) 8 TE-Classes 259 configured in the TE-Class Mapping specified is section 3.2.1 above. 261 The preemption priority configured for the holding priority of a 262 given LSP and the Class-Type configured for that LSP must also be 263 such that, together, they form one of the (up to) 8 TE-Classes 264 configured in the TE-Class Mapping specified is section 3.2.1 above. 266 3.4. Examples of Parameters Configuration 268 Le Faucheur et. al 5 270 Protocols for Diff-Serv-aware TE February 2002 272 For illustrative purposes, we now present a few examples of how these 273 configurable parameters may be used. All these examples assume that 274 different bandwidth constraints need to be enforced for different 275 sets of Traffic Trunks (e.g. for Voice and for Data) so that two, or 276 more, Class-Types must be used. 278 3.4.1. Example 1 280 The Network Administrator of a first network using two Class Types 281 (CT1 for Voice and CT0 for Data), may elect to configure the 282 following TE-Class Mapping to ensure that Voice LSPs are never driven 283 away from their shortest path because of Data LSPs: 285 TE-Class[0] <--> < CT1 , preemption 0 > 286 TE-Class[1] <--> < CT0 , preemption 1 > 287 TE-Class[i] <--> unused, for 2 <= i <= 7 289 Voice LSPs would then be configured with: 290 - CT=CT1, set-up priority =0, holding priority=0 292 Data LSPs would then be configured with: 293 - CT=CT0, set-up priority =1, holding priority=1 295 A new Voice LSP would then be able to preempt an existing Data LSP in 296 case they contend for resources. A Data LSP would never preempt a 297 Voice LSP. A Voice LSP would never preempt another Voice LSP. A Data 298 LSP would never preempt another Data LSP. 300 3.4.2. Example 2 302 The Network Administrator of another network may elect to configure 303 the following TE-Class Mapping in order to optimize global network 304 resource utilization by favoring placement of large LSPs closer to 305 their shortest path: 307 TE-Class[0] <--> < CT1 , preemption 0 > 308 TE-Class[1] <--> < CT0 , preemption 1 > 309 TE-Class[2] <--> < CT1 , preemption 2 > 310 TE-Class[3] <--> < CT0 , preemption 3 > 311 TE-Class[i] <--> unused, for 4 <= i <= 7 313 Large size Voice LSPs could be configured with: 314 - CT=CT1, set-up priority =0, holding priority=0 316 Large size Data LSPs could be configured with: 317 - CT=CT0, set-up priority = 1, holding priority=1 319 Small size Voice LSPs could be configured with: 320 - CT=CT1, set-up priority = 2, holding priority=2 322 Small size Data LSPs could be configured with: 324 Le Faucheur et. al 6 326 Protocols for Diff-Serv-aware TE February 2002 328 - CT=CT0, set-up priority = 3, holding priority=3. 330 A new large size Voice LSP would then be able to preempt a small size 331 Voice LSP or any Data LSP in case they contend for resources. 332 A new large size Data LSP would then be able to preempt a small size 333 Data LSP or a small size Voice LSP in case they contend for 334 resources, but it would not be able to preempt a large size Voice 335 LSP. 337 3.4.3. Example 3 339 The Network Administrator of another network may elect to configure 340 the following TE-Class Mapping in order to ensure that Voice LSPs are 341 never driven away from their shortest path because of Data LSPs while 342 also achieving some optimization of global network resource 343 utilization by favoring placement of large LSPs closer to their 344 shortest path: 346 TE-Class[0] <--> < CT1 , preemption 0 > 347 TE-Class[1] <--> < CT1 , preemption 1 > 348 TE-Class[2] <--> < CT0 , preemption 2 > 349 TE-Class[3] <--> < CT0 , preemption 3 > 350 TE-Class[i] <--> unused, for 4 <= i <= 7 352 Large size Voice LSPs could be configured with: 353 - CT=CT1, set-up priority = 0, holding priority=0. 355 Small size Voice LSPs could be configured with: 356 - CT=CT1, set-up priority = 1, holding priority=1. 358 Large size Data LSPs could be configured with: 359 - CT=CT0, set-up priority = 2, holding priority=2. 361 Small size Data LSPs could be configured with: 362 - CT=CT0, set-up priority = 3, holding priority=3. 364 A Voice LSP could preempt a Data LSP if they contend for resources. A 365 Data LSP would never preempt a Voice LSP. A Large size Voice LSP 366 could preempt a small size Voice LSP if they contend for resources. A 367 Large size Data LSP could preempt a small size Data LSP if they 368 contend for resources. 370 3.4.4. Example 4 372 The Network Administrator of another network may elect to configure 373 the following TE-Class Mapping in order to ensure that no preemption 374 occurs in the DS-TE domain: 376 TE-Class[0] <--> < CT1 , preemption 0 > 377 TE-Class[1] <--> < CT0 , preemption 0 > 378 TE-Class[i] <--> unused, for 2 <= i <= 7 380 Le Faucheur et. al 7 382 Protocols for Diff-Serv-aware TE February 2002 384 Voice LSPs would then be configured with: 385 - CT=CT1, set-up priority =0, holding priority=0 387 Data LSPs would then be configured with: 388 - CT=CT0, set-up priority =0, holding priority=0 390 No LSP would then be able to preempt any other LSP. 392 3.4.5. Example 5 394 The Network Administrator of another network may elect to configure 395 the following TE-Class Mapping in view of increased network stability 396 through a more limited use of preemption: 398 TE-Class[0] <--> < CT1 , preemption 0 > 399 TE-Class[1] <--> < CT1 , preemption 1 > 400 TE-Class[2] <--> < CT0 , preemption 1 > 401 TE-Class[3] <--> < CT0 , preemption 2 > 402 TE-Class[i] <--> unused, for 4 <= i <= 7 404 Large size Voice LSPs could be configured with: 405 - CT=CT1, set-up priority = 0, holding priority=0. 407 Small size Voice LSPs could be configured with: 408 - CT=CT1, set-up priority = 1, holding priority=0. 410 Large size Data LSPs could be configured with: 411 - CT=CT0, set-up priority = 2, holding priority=1. 413 Small size Data LSPs could be configured with: 414 - CT=CT0, set-up priority = 2, holding priority=2. 416 A new large size Voice LSP would be able to preempt a Data LSP in 417 case they contend for resources, but it would not be able to preempt 418 any Voice LSP even a small size Voice LSP. 420 A new small size Voice LSP would be able to preempt a small size Data 421 LSP in case they contend for resources, but it would not be able to 422 preempt a large size Data LSP or any Voice LSP. 424 A Data LSP would not be able to preempt any other LSP. 426 4. IGP Advertisement 428 This section only discusses the differences with the IGP 429 advertisement supported for MPLS Traffic Engineering as per [OSPF-TE] 430 and [ISIS-TE]. The rest of the IGP advertisement is unchanged. 432 4.1. Bandwidth Constraints 434 Le Faucheur et. al 8 436 Protocols for Diff-Serv-aware TE February 2002 438 As detailed above in section 3.1.1, up to 8 Bandwidth Constraints ( 439 BCb, 0 <= b <= 7) are configurable on any given link. 441 With DS-TE, the existing "Maximum Reservable Bw" sub-TLV is retained 442 with a generalized semantic so that it is now interpreted as 443 Bandwidth Constraint 0 (BC0). 445 DS-TE also defines the following optional sub-TLV to advertise the 446 eight potential Bandwidth Constraints (BC0 to BC7): 448 "Bandwidth Constraints" sub-TLV: 449 TBD - Bandwidth Constraint Model Id (1 octet) 450 Bandwidth Constraints (Nx4 octets) 452 Where: 454 - Bandwidth Constraint Model Id: 1 octet identifier for the 455 Bandwidth Constraints Model currently in use by the LSR 456 initiating the IGP advertisement. 457 Values 0 to 127 are to be allocated by the TEWG to identify 458 Bandwidth Constraints Models defined in the TEWG. Value 0 459 identifies the Russian Doll Bandwidth Constraint Model 460 defined in section 9. 461 Values 128 to 255 are for experimental use. 463 - Bandwidth Constraints: contains BC0, BC1,... BCN-1. It is 464 recommended that only the Bandwidth Constraints corresponding 465 to active CTs be advertised in order to minimize the impact 466 on IGP scalability. 468 When DS-TE is deployed and only a single CT is used, the existing 469 "Maximum Reservable Bw" sub-TLV is used. 471 When DS-TE is deployed and multiple CTs are used, the new "Bandwidth 472 Constraints" sub-TLV is used. For example, where a Service Provider 473 deploys DS-TE with two active CTs, only two Bandwidth Constraints per 474 link would be meaningful (assuming, for instance, the Russian Doll 475 Bandwidth Constraint Model defined in section 9). The "Bandwidth 476 Constraints" sub-TLV would then be used and should contain BC0 and 477 BC1. 478 A DS-TE LSR receiving the "Bandwidth Constraints" sub-TLV with a 479 Bandwidth Constraint Model Id which does not match the Bandwidth 480 Constraint Model it currently uses, may generate an error indication 481 to the operator reporting the inconsistency between Bandwidth 482 Constraint Models used on different LSRs and may discard the 483 corresponding TLV. 485 4.2. Unreserved Bandwidth 487 With DS-TE, the existing "Unreserved Bandwidth" sub-TLV is retained 488 as the only vehicle to advertise dynamic bandwidth information 489 necessary for Constraint Based Routing on Head-ends, except that it 491 Le Faucheur et. al 9 493 Protocols for Diff-Serv-aware TE February 2002 495 is used with a generalized semantic. The Unreserved Bandwidth sub-TLV 496 still carries eight bandwidth values but they now correspond to the 497 unreserved bandwidth for each of the TE-Class (instead of for each 498 preemption as per existing TE). 500 More precisely, the Unreserved Bandwidth sub-TLV definition is 501 generalized into the following: 503 The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth 504 not yet reserved for each of the eight TE-classes, in IEEE floating 505 point format arranged in increasing order of TE-Class index, with 506 unreserved bandwidth for TE-Class [0] occurring at the start of the 507 sub-TLV, and unreserved bandwidth for TE-Class [7] at the end of the 508 sub-TLV. The unreserved bandwidth value for TE-Class [i] ( 0 <= i <= 509 7) is referred to as "Unreserved TE-Class [i]". It indicates the 510 bandwidth that is available, for reservation, to an LSP which : 511 - transports a Traffic Trunk from the Class-Type of TE- 512 Class[i], and 513 - has a setup priority corresponding to the preemption priority 514 of TE-Class[i]. 516 The units are bytes per second. 518 Since the bandwidth values are now ordered by TE-class index and thus 519 can relate to different CTs with different bandwidth constraints and 520 can relate to any arbitrary preemption priority, no ordered 521 relationship among these bandwidth values should be assumed. 523 With existing TE, since all preemption priorities reflect the same 524 (and only) bandwidth constraints and since bandwidth values are 525 advertised in preemption priority order, the following relationship 526 is always true, and is often assumed by TE implementations: 528 If i < j , then "Unreserved Bw [i]" >= "Unreserved Bw [j]" 530 With DS-TE, no relationship is to be assumed so that: 531 If i < j , then 532 "Unreserved TE-Class [i]" = "Unreserved TE-Class [j]" 533 OR 534 "Unreserved TE-Class [i]" > "Unreserved TE-Class [j]" 535 OR 536 "Unreserved TE-Class [i]" < "Unreserved TE-Class [j]". 538 Since some Bandwidth Constraints Models are such that a given Class- 539 Type is constrained by multiple Bandwidth Constraints (as in the case 540 of the Russian Doll Bandwidth Constraint Model specified in section 541 9), the value to be advertised by the IGP in "Unreserved TE-Class 542 [i]" must reflect all of the Bandwidth Constraints relevant to the CT 543 associated with TE-Class [i]. . 545 If TE-Class[i] is unused the value to be advertised by the IGP in 546 "Unreserved TE-Class [i]" is zero. 548 Le Faucheur et. al 10 550 Protocols for Diff-Serv-aware TE February 2002 552 4.3. Local Overbooking Multiplier 554 The following additional optional sub-TLV is defined for DS-TE: 556 "Local Overbooking Multiplier" sub-TLV: 557 TBD - per-CT Local Overbooking Multipliers (N x 1 octet) 559 where N is the number of per-CT Local Overbooking Multipliers 560 actually advertised. For example, where a Service Provider only 561 deploys DS-TE with two CTs and makes use of the Local Overbooking 562 method, the "Local Overbooking Multiplier" sub-TLV may optionally be 563 used and would then contain only LOM[0] and LOM[1] in order to 564 minimize the impact on IGP scalability. 566 Note that the use of this sub-TLV is only optional even when the 567 optional Local Overbooking method is actually used (and thus when the 568 Local Overbooking Multipliers parameters actually configured locally 569 on some or all links). Its use may assist in head-end prediction of 570 network response to LSP establishment. 572 5. LSP Signaling 574 This section only describes the signaling extensions beyond those 575 already specified for MPLS Traffic Engineering as per [RSVP-TE] and 576 [CR-LDP] and for Diff-Serv over MPLS as per [DIFF-MPLS]. 578 The Class-Type of the LSP is signaled in RSVP-TE and CR-LDP for DS-TE 579 in order for LSRs to enforce the appropriate bandwidth constraint(s) 580 for admission control and bandwidth accounting. 582 Protocol and procedure extensions for signaling of the Class-Type are 583 specified in details in Appendix A and B respectively for RSVP-TE and 584 CR-LDP. 586 6. Constraint Based Routing 588 Let us consider the case where a path needs to be computed for an LSP 589 whose Class-Type is configured to CTc and whose set-up preemption 590 priority is configured to p. 592 Then the pair of CTc and p will map to one of the TE-Classes defined 593 in the TE-Class mapping. Let us assume that this is the i-th TE-Class 594 i.e. TE-Class[i]. 596 The Constraint Based Routing algorithm is still only required to 597 perform path computation satisfying a single bandwidth constraint 598 which is to fit in "Unreserved TE-Class [i]" as advertised by the IGP 599 for every link. Thus, no changes are required to the existing TE 600 Constraint Based Routing algorithm itself. 602 Le Faucheur et. al 11 604 Protocols for Diff-Serv-aware TE February 2002 606 The Constraint Based Routing algorithm may also optionally take into 607 account, when used, the optional information advertised in IGP which 608 are the Bandwidth Constraints and the Local Overbooking Multipliers. 609 As an example, the Bandwidth Constraints might be used as a tie- 610 breaker criteria in situations where multiple paths, otherwise 611 equally attractive, are possible. 613 7. Diff-Serv scheduling 615 The Class-Type signaled at LSP establishment may optionally be used 616 by LSRs to dynamically adjust the resources allocated to the Class- 617 Type by the Diff-Serv scheduler. In addition, the Diff-Serv 618 information (i.e. the PSC) signaled by the TE-LSP signaling protocols 619 as specified in [DIFF-MPLS], if used, may optionally be used by LSRs 620 to dynamically adjust the resources allocated to a PSC/OA within a 621 Class Type by the Diff-Serv scheduler. 623 8. Existing TE as a Particular Case of DS-TE 625 We observe that existing TE can be viewed as a particular case of DS- 626 TE where: 628 (i) a single Class-Type is used, all 8 preemption priorities 629 are allowed for that Class-Type and the following TE-Class 630 Mapping is used: 632 TE-Class[i] <--> < CT0 , preemption i > 633 Where 0 <= i <= 7. 635 (ii) optional per-CT Local Overbooking Multipliers are not 636 used. 638 In that case, DS-TE behaves exactly as existing TE. 640 The IGP advertises: 641 - Unreserved Bandwidth for each of the 8 preemption priorities 642 - BC0= Maximum Reservable Bandwidth 644 Since all LSPs transport traffic from CT0, LSP Signaling is done 645 without explicit signaling of the Class-Type (which is only used for 646 other Class-Types than CT0 as explained in Appendix A and B). 648 9. Russian Doll Bandwidth Constraints Model 650 9.1. Definition 652 Le Faucheur et. al 12 654 Protocols for Diff-Serv-aware TE February 2002 656 [DSTE-REQ] introduces the concept of Bandwidth Constraint Model to 657 characterize the Bandwidth Constraints associated with CTs, but it 658 does not actually specify one particular Model. 660 Although multiple Bandwidth Constraints Models are conceivable and 661 may be supported by a given DS-TE implementation, DS-TE operation 662 requires that the same Bandwidth Constraint Model be actually used on 663 all LSRs of a given DS-TE domain. Thus, for multiple DS-TE 664 implementations to interoperate, they must support the same Bandwidth 665 Constraints Model. Consequently, this section specifies one default 666 Bandwidth Constraint Models which must be supported by all DS-TE 667 implementations to ensure interoperability. This Model is referred to 668 as the "Russian Dolls" Bandwidth Constraints model. DS-TE 669 implementations may also optionally support other Bandwidth 670 Constraints Models. 672 The "Russian Doll" model of Bandwidth Constraints is defined in the 673 following manner: 674 o Maximum Number of Bandwidth Constraints (MaxBC)= Maximum 675 Number of Class-Types (MaxCT) = 8 676 o All LSPs supporting Traffic Trunks from CTb (with 677 b<=c<=7) use no more than BCb i.e.: 678 - All LSPs from CT7 use no more than BC7 679 - All LSPs from CT6 and CT7 use no more than BC6 680 - All LSPs from CT5, CT6 and CT7 use no more than BC5 681 - etc. 682 - All LSPs from CT0, CT1,... CT7 use no more than BC0 684 Purely for illustration purposes, the diagram below represents the 685 Russian Doll Bandwidth Constraints model in a pictorial manner when 686 only 3 Class-Types are active: 688 I------------------------------------------------------I 689 I-------------------------------I I 690 I--------------I I I 691 I CT2 I CT2+CT1 I CT2+CT1+CT0 I 692 I--------------I I I 693 I-------------------------------I I 694 I------------------------------------------------------I 696 I-----BC2------> 697 I----------------------BC1------> 698 I---------------------------------------------BC0------> 700 While more flexible/sophisticated Bandwidth Constraints models can be 701 defined, the Russian Dolls model is an attractive trade-off for the 702 following reasons: 703 - Network administrators generally find it superior to the most 704 basic model of a single independent BC per CT (which, in 705 typical deployment scenarios, results in either capacity 707 Le Faucheur et. al 13 709 Protocols for Diff-Serv-aware TE February 2002 711 wastage, low priority Traffic Trunk starvation and/or 712 degradation of QoS objectives) 713 - network administrators generally find it sufficient for the 714 real life deployments currently anticipated (e.g. it 715 addresses all the scenarios described in [DSTE-REQ]) 716 - it remains simple and only requires limited protocol 717 extensions, while more sophisticated Bandwidth Constraints 718 model may require more complex extensions. 720 Another (or other) Bandwidth Constraints Model(s) may be specified 721 later if additional requirements emerge from Service Providers real 722 life deployment which cannot be addressed by the Russian Dolls model. 724 The Russian Doll Bandwidth Constraints Model can be supported with 725 the extensions defined earlier in this document for DS-TE. Note that 726 a number of other Bandwidth Constraints could also be supported with 727 these same extensions. Note also that not all Bandwidth Constraints 728 models could be supported with these extensions and those may require 729 additional or different extensions. Both of these situations are 730 beyond the scope of this specification. 732 As an example of the "Russian Doll" Bandwidth Constraints Model, a 733 network administrator using one CT for Voice (CT1) and one CT for 734 data (CT0) might configure on a given link: 735 - Existing Maximum Reservable Link Bandwidth (a.k.a. BC0) = 2.5 736 Gb/s (i.e. Voice + Data is limited to 2.5 Gb/s) 737 - Bandwidth Constraint 1 (a.k.a. BC1)= 1.5 Gb/s (i.e. Voice is 738 limited to 1.5 Gb/s). 740 9.2. Computing "Unreserved TE-Class [i]" 742 We first observe that, for existing TE, details on admission control 743 algorithms for TE LSPs, and consequently details on formulas for 744 computing the unreserved bandwidth, are outside the scope of the 745 current IETF work. This is left for vendor differentiation. Note that 746 this does not compromise interoperability across various 747 implementations since the TE schemes rely on LSRs to advertise their 748 local view of the world in terms of Unreserved Bw to other LSRs. This 749 way, regardless of the actual local admission control algorithm used 750 on one given LSR, Constraint Based Routing on other LSRs can rely on 751 advertised information to determine whether an additional LSP will be 752 accepted or rejected by the given LSR. The only requirement is that 753 an LSR advertises unreserved bandwidth values which are consistent 754 with its specific local admission control algorithm and take into 755 account the holding preemption priority of established LSPs. 757 In the context of DS-TE, again, details on admission control 758 algorithms are left for vendor differentiation and formulas for 759 computing the unreserved bandwidth for TE-Class[i] are outside the 760 scope of this specification. However, DS-TE places the additional 761 requirement on the LSR that the unreserved bandwidth values 763 Le Faucheur et. al 14 765 Protocols for Diff-Serv-aware TE February 2002 767 advertised must reflect all of the Bandwidth Constraints relevant to 768 the CT associated with TE-Class[i], as discussed in section 4.2. 770 As with existing TE, DS-TE assumes that the holding preemption 771 priority is the one considered for established LSPs (as opposed to 772 their set-up preemption priority) for the purpose of computing the 773 unreserved bandwidth for TE-Class [i]. 775 Example formulas for computing "Unreserved TE-Class [i]" are provided 776 in Appendix C. 778 9.3. Admission Control Rules 780 Regardless of how the admission control algorithm actually computes 781 the unreserved bandwidth for TE-Class[i] for one of its local link, 782 an LSP of bandwidth B , of set-up preemption priority p and of Class- 783 Type CTc is admissible on that link iff: 785 B <= unreserved bandwidth for TE-Class[i], AND 786 B <= Max Link Bandwidth 788 Where 790 - TE-Class [i] maps to < CTc , p > in the LSR's configured TE- 791 Class mapping 792 - Max Link Bandwidth is the maximum link bandwidth configured 793 on the link and advertised in IGP. 795 Note that this admission control rule assumes that the optional per- 796 CT Local Overbooking Multipliers are not used (i.e. LOM[c]=1). 798 10. Security Considerations 800 The solution is not expected to add specific security requirements 801 beyond those of Diff-Serv and existing TE. The security mechanisms 802 currently used with Diff-Serv and existing TE can be used with this 803 solution. 805 11. Acknowledgments 807 We thank Martin Tatham, Angela Chiu and Pete Hicks for their earlier 808 contribution in this work. 810 References 812 [DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv- 813 aware MPLS Traffic Engineering, draft-ietf-tewg-diff-te-reqts-03.txt, 814 February 2002. 816 Le Faucheur et. al 15 818 Protocols for Diff-Serv-aware TE February 2002 820 [OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF, draft- 821 katz-yeung-ospf-traffic-06.txt, October 2001. 823 [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft- 824 ietf-isis-traffic-04.txt, October 2001. 826 [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 827 Tunnels", RFC 3209, December 2001. 829 [CR-LDP] Jamoussi et al, "Constraint-Based LSP Setup using LDP", RFC 830 32 12, January 2002. 832 [DIFF-MPLS] Le Faucheur et al, "MPLS Support of Diff-Serv", draft- 833 ietf-mpls-diff-ext-09.txt, April 2001 835 Authors' Address: 837 Francois Le Faucheur 838 Cisco Systems, Inc. 839 Village d'Entreprise Green Side - Batiment T3 840 400, Avenue de Roumanille 841 06410 Biot-Sophia Antipolis 842 France 843 Phone: +33 4 97 23 26 19 844 Email: flefauch@cisco.com 846 Jim Boyle 847 Protocol Driven Networks 848 1381 Kildaire Farm Road #288 849 Cary, NC 27511 850 Phone: +1 919 852-5160 851 Email: jboyle@pdnets.com 853 Kireeti Kompella 854 Juniper Networks, Inc. 855 1194 N. Mathilda Ave. 856 Sunnyvale, CA 94099 857 Email: kireeti@juniper.net 859 William Townsend 860 Tenor Networks 861 100 Nagog Park 862 Acton, MA 01720 863 Phone: +1-978-264-4900 864 Email: btownsend@tenornetworks.com 866 Thomas D. Nadeau 867 Cisco Systems, Inc. 868 250 Apollo Drive 869 Chelmsford, MA 01824 870 Phone: +1-978-244-3051 872 Le Faucheur et. al 16 874 Protocols for Diff-Serv-aware TE February 2002 876 Email: tnadeau@cisco.com 878 Darek Skalecki 879 Nortel Networks 880 3500 Carling Ave, 881 Nepean K2H 8E9 882 Phone: +1-613-765-2252 883 Email: dareks@nortelnetworks.com 885 Appendix A - RSVP Extensions for Diff-Serv-aware TE 887 In this section we describe extensions to RSVP for support of 888 Diff-Serv-aware MPLS Traffic Engineering. These extensions are in 889 addition to the extensions to RSVP defined in [RSVP-TE] for support 890 of (aggregate) MPLS Traffic Engineering and to the extensions to RSVP 891 defined in [DIFF-MPLS] for support of Diff-Serv over MPLS. 893 1. Diff-Serv-aware TE related RSVP Messages Format 895 One new RSVP Object is defined in this document: the CLASSTYPE 896 Object. Detailed description of this Object is provided below. This 897 new Object is applicable to Path messages. This specification only 898 defines the use of the CLASSTYPE Object in Path messages used to 899 establish LSP Tunnels in accordance with [RSVP-TE] and thus 900 containing a Session Object with a C-Type equal to LSP_TUNNEL_IPv4 901 and containing a LABEL_REQUEST object. 903 Restrictions defined in [RSVP-TE] for support of establishment of LSP 904 Tunnels via RSVP are also applicable to the establishment of LSP 905 Tunnels supporting Diff-Serv-aware Traffic Engineering. For instance, 906 only unicast LSPs are supported and Multicast LSPs are for further 907 study. 909 This new CLASSTYPE object is optional with respect to RSVP so that 910 general RSVP implementations not concerned with MPLS LSP set up do 911 not have to support this object. 913 An LSR supporting Diff-Serv-aware Traffic Engineering in compliance 914 with this specification MUST support the CLASSTYPE Object. It MUST 915 support Class-Type value 1, and MAY support other Class-Type values. 917 1.1. Path Message Format 919 The format of the Path message is as follows: 921 ::= [ ] 922 923 924 [ ] 925 926 [ ] 928 Le Faucheur et. al 17 930 Protocols for Diff-Serv-aware TE February 2002 932 [ ] 933 [ ] 934 [ ... ] 935 [ ] 937 ::= [ ] 938 [ ] 939 [ ] 941 2. CLASSTYPE Object 943 The CLASSTYPE object format is shown below. 945 2.1. CLASSTYPE object 947 class = TBD, C_Type = 1 (need to get an official class num from the 948 IANA with the form 0bbbbbbb) 950 0 1 2 3 951 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 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 | Reserved | CT | 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 Reserved : 29 bits 957 This field is reserved. It must be set to zero on transmission 958 and must be ignored on receipt. 960 CT : 3 bits 961 Indicates the Class-Type. Values currently allowed are 1, 2, ... 962 , 7. 964 3. Handling CLASSTYPE Object 966 To establish an LSP tunnel with RSVP, the sender LSR creates a Path 967 message with a session type of LSP_Tunnel_IPv4 and with a 968 LABEL_REQUEST object as per [RSVP-TE]. The sender LSR may also 969 include the DIFFSERV object as per [DIFF-MPLS]. 971 If the LSP is associated with Class-Type 0, the sender LSR must not 972 include the CLASSTYPE object in the Path message. 974 If the LSP is associated with Class-Type N (1 <= N <=7), the sender 975 LSR must include the CLASSTYPE object in the Path message with the 976 Class-Type (CT) field set to N. 978 If a path message contains multiple CLASSTYPE objects, only the first 979 one is meaningful; subsequent CLASSTYPE object(s) must be ignored and 980 must not be forwarded. 982 Le Faucheur et. al 18 984 Protocols for Diff-Serv-aware TE February 2002 986 Each LSR along the path records the CLASSTYPE object, when present, 987 in its path state block. 989 If the CLASSTYPE object is not present in the Path message, the LSR 990 must associate the Class-Type 0 to the LSP. 992 The destination LSR responds to the Path message by sending a Resv 993 message without a CLASSTYPE object (whether the Path message 994 contained a CLASSTYPE object or not). 996 During establishment of an LSP corresponding to the Class-Type N, the 997 LSR performs admission control over the bandwidth available for that 998 particular Class-Type. 1000 An LSR that recognizes the CLASSTYPE object and that receives a path 1001 message which contains the CLASSTYPE object but which does not 1002 contain a LABEL_REQUEST object or which does not have a session type 1003 of LSP_Tunnel_IPv4, must send a PathErr towards the sender with the 1004 error code 'Diff-Serv-aware TE Error' and an error value of 1005 'Unexpected CLASSTYPE object'. Those are defined below in section 5. 1007 An LSR receiving a Path message with the CLASSTYPE object, which 1008 recognizes the CLASSTYPE object but does not support the particular 1009 Class-Type, must send a PathErr towards the sender with the error 1010 code 'Diff-Serv-aware TE Error' and an error value of 'Unsupported 1011 Class-Type'. Those are defined below in section 5. 1013 An LSR receiving a Path message with the CLASSTYPE object, which 1014 recognizes the CLASSTYPE object but determines that the Class-Type 1015 value is not valid (i.e. Class-Type value 0), must send a PathErr 1016 towards the sender with the error code 'Diff-Serv-aware TE Error' and 1017 an error value of 'Invalid Class-Type value'. Those are defined below 1018 in section 5. 1020 An LSR receiving a Path message with the CLASSTYPE object, which: 1021 - recognizes the CLASSTYPE object, 1022 - supports the particular Class-Type, but 1023 - determines that the tuple formed by (i) this Class-Type and 1024 (ii) the set-up priority signaled in the same Path message, 1025 is not one of the eight TE-classes configured in the TE-class 1026 mapping, 1027 must send a PathErr towards the sender with the error code 'Diff- 1028 Serv-aware TE Error' and an error value of 'CT and setup priority do 1029 not form a configured TE-Class'. Those are defined below in section 1030 5. 1032 An LSR receiving a Path message with the CLASSTYPE object, which: 1033 - recognizes the CLASSTYPE object, 1034 - supports the particular Class-Type, but 1035 - determines that the tuple formed by (i) this Class-Type and 1036 (ii) the holding priority signaled in the same Path message, 1038 Le Faucheur et. al 19 1040 Protocols for Diff-Serv-aware TE February 2002 1042 is not one of the eight TE-classes configured in the TE-class 1043 mapping, 1044 must send a PathErr towards the sender with the error code 'Diff- 1045 Serv-aware TE Error' and an error value of 'CT and holding priority 1046 do not form a configured TE-Class'. Those are defined below in 1047 section 5. 1049 An LSR MUST handle the situations where the LSP can not be accepted 1050 for other reasons than those already discussed in this section, in 1051 accordance with [RSVP-TE] and [DIFF-MPLS] (e.g. a reservation is 1052 rejected by admission control, a label can not be associated). 1054 4. Non-support of the CLASSTYPE Object 1056 An LSR that does not recognize the CLASSTYPE object Class-Num must 1057 behave in accordance with the procedures specified in [RSVP] for an 1058 unknown Class-Num whose format is 0bbbbbbb (i.e. it must send a 1059 PathErr with the error code 'Unknown object class' toward the 1060 sender). 1062 An LSR that recognizes the CLASSTYPE object Class-Num but does not 1063 recognize the CLASSTYPE object C-Type, must behave in accordance with 1064 the procedures specified in [RSVP] for an unknown C-type (i.e. it 1065 must send a PathErr with the error code 'Unknown object C-Type' 1066 toward the sender). 1068 In both situations, this causes the path set-up to fail. The sender 1069 should notify management that a LSP cannot be established and 1070 possibly might take action to retry reservation establishment without 1071 the CLASSTYPE object. 1073 5. Error Codes For Diff-Serv-aware TE 1075 In the procedures described above, certain errors must be reported as 1076 a 'Diff-Serv-aware TE Error'. The value of the 'Diff-Serv-aware TE 1077 Error' error code is (TBD). 1079 The following defines error values for the Diff-Serv-aware TE Error: 1081 Value Error 1083 1 Unexpected CLASSTYPE object 1084 2 Unsupported Class-Type 1085 3 Invalid Class-Type value 1086 4 CT and setup priority do not form a configured TE-Class 1087 5 CT and holding priority do not form a configured 1088 TE-Class 1090 Appendix B - CR-LDP Extensions for Diff-Serv-aware TE 1092 Le Faucheur et. al 20 1094 Protocols for Diff-Serv-aware TE February 2002 1096 CR-LDP, defined in [CR-LDP], is an extension to LDP, defined in 1097 [LDP], for support of (aggregate) MPLS Traffic Engineering. In this 1098 section we describe extensions to CR-LDP for support of Diff-Serv- 1099 aware MPLS Traffic Engineering. These extensions are in addition to 1100 the extensions to LDP defined in [DIFF-MPLS] for support of Diff-Serv 1101 over MPLS. They closely resemble the extensions to RSVP defined in 1102 the previous section. 1104 Note that extensions of this section for support of Diff-Serv-aware 1105 Traffic Engineering are not applicable to LDP due to the fact that 1106 LDP does not support MPLS Traffic Engineering and bandwidth 1107 reservation in particular. 1109 1. Diff-Serv-aware TE related CR-LDP Messages Encoding 1111 One new CR-LDP TLV is defined in this document: the Class Type TLV. 1112 Detailed description of this TLV is provided below. This new TLV is 1113 applicable to Label Request messages. 1115 Restrictions defined in [CR-LDP] for support of establishment of LSPs 1116 via CR-LDP are also applicable to the establishment of LSPs 1117 supporting Diff-Serv-aware Traffic Engineering: for instance, only 1118 unicast LSPs are supported and multicast LSPs are for further study. 1120 This new Class Type TLV is optional with respect to CR-LDP so that 1121 general CR-LDP implementations not concerned with Diff-Serv-aware 1122 Traffic Engineering are not required to support this TLV. 1124 An LSR supporting Diff-Serv-aware Traffic Engineering in compliance 1125 with this specification MUST support the Class Type TLV. It MUST 1126 support Class-Type value 1, and MAY support other Class-Type values. 1128 1.1. Label Request Message Encoding 1130 The encoding for the CR-LDP Label Request message is extended as 1131 follows, to optionally include the Class Type TLV: 1133 0 1 2 3 1134 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 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 |0| Label Request (0x0401) | Message Length | 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 | Message ID | 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 | FEC TLV | 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 | Diff-Serv TLV (LDP, optional) | 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 | Class Type TLV (CR-LDP optional) | 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 | Other CR-LDP TLVs | 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 Le Faucheur et. al 21 1151 Protocols for Diff-Serv-aware TE February 2002 1153 The extension is based on a related LDP extension, defined in [DIFF- 1154 MPLS], for support of Diff-Serv TLV but further extended for CR-LDP 1155 with CR-LDP TLVs. 1157 2. Class Type TLV 1159 The Class Type TLV has the following form: 1160 0 1 2 3 1161 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 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 |0|0| Class Type TLV | Length | 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 | Reserved | CT | 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 Reserved : 29 bits 1169 This field is reserved. It must be set to zero on transmission 1170 and must be ignored on receipt. 1172 CT : 3 bits 1173 Indicates the Class-Type. Values currently allowed are 1, 2, ... 1174 , 7. 1176 3. Handling Class Type TLV 1178 To establish an LSP using CR-LDP, an ingress LSR generates a Label 1179 Request message as per [CR-LDP]. This Label Request may optionally 1180 include the Diff-Serv TLV as defined in [DIFF-MPLS] for LDP but 1181 extended to CR-LDP. 1183 If the LSP is associated with Class-Type 0, the ingress LSR must not 1184 include the Class Type TLV in the Label Request message. 1186 If the LSP is associated with Class-Type N (1 <= N <= 7), the ingress 1187 LSR must include the Class Type TLV in the Label Request message with 1188 the Class-Type (CT) field set to N. 1190 If a Label Request message contains multiple Class Type TLVs, only 1191 the first one is meaningful; subsequent Class Type TLV(s) must be 1192 ignored and not forwarded. 1194 If the Class Type TLV is not present in the Label Request message, an 1195 LSR must associate the Class-Type 0 to the LSP. 1197 A downstream LSR sending a Label Mapping message in response to a 1198 Label Request message must not include the Class-Type TLV (whether 1199 the Class-Type TLV was included in the Label Request message or not). 1201 Le Faucheur et. al 22 1203 Protocols for Diff-Serv-aware TE February 2002 1205 During establishment of an LSP corresponding to the Class-Type N, an 1206 LSR performs admission control over the bandwidth available for that 1207 particular Class-Type. 1209 An LSR that recognizes the Class Type TLV and receives a Label 1210 Request message which contains the Class Type TLV but which does not 1211 contain any of the CR-LDP TLVs, must reject the label request by 1212 sending upstream a Notification message which includes the Status TLV 1213 with a Status Code of 'Unexpected Class-Type TLV'. This is defined 1214 below in section 4. This error can only occur when an LDP LSP as 1215 opposed to CR-LDP LSP is being established. As was already mentioned, 1216 Class Type TLV extension for Diff-Serv-aware Traffic Engineering is 1217 not applicable to LDP. 1219 An LSR receiving a Label Request message with the Class Type TLV, 1220 which recognizes the Class Type TLV but does not support the 1221 particular Class-Type, must reject the label request by sending 1222 upstream a Notification message which includes the Status TLV with a 1223 Status Code of 'Unsupported Class-Type'. This is defined below in 1224 section 4. 1226 An LSR receiving a Label Request message with the Class Type TLV, 1227 which recognizes the Class Type TLV but determines that the Class- 1228 Type value is not valid (i.e. Class-Type value 0), must reject the 1229 label request by sending upstream a Notification message which 1230 includes the Status TLV with a Status Code of 'Invalid Class-Type 1231 value'. This is defined below in section 4. 1233 An LSR receiving a Label Request message with the Class Type TLV, 1234 which: 1235 - recognizes the Class Type TLV, 1236 - supports the particular Class-Type, but 1237 - determines that the tuple formed by (i) this Class-Type and 1238 (ii) the set-up priority signaled in the same Label Request 1239 message, is not one of the eight TE-classes configured in 1240 the TE-class mapping, 1241 must reject the label request by sending upstream a Notification 1242 message which includes the Status TLV with a Status Code of 'CT and 1243 setup priority do not form a configured TE-Class'. This is defined 1244 below in section 4. 1246 An LSR receiving a Label Request message with the Class Type TLV, 1247 which: 1248 - recognizes the Class Type TLV, 1249 - supports the particular Class-Type, but 1250 - determines that the tuple formed by (i) this Class-Type and 1251 (ii) the holding priority signaled in the same Label Request 1252 message, is not one of the eight TE-classes configured in 1253 the TE-class mapping, 1254 must reject the label request by sending upstream a Notification 1255 message which includes the Status TLV with a Status Code of 'CT and 1257 Le Faucheur et. al 23 1259 Protocols for Diff-Serv-aware TE February 2002 1261 holding priority do not form a configured TE-Class'. This is defined 1262 below in section 4. 1264 An LSR MUST handle the situations where the LSP can not be accepted 1265 for other reasons than those already discussed in this section, in 1266 accordance with [CR-LDP], [LDP] and [DIFF-MPLS] (e.g. reservation 1267 rejected by admission control, a label can not be associated). 1269 4. Status Code Values for Diff-Serv-aware TE 1271 In the procedures described above, certain errors must be reported. 1272 The following values are defined for the Status Code field of the 1273 Status TLV: 1275 Status Code E Status Data 1277 Unexpected Class Type TLV 0 TBD 1278 Unsupported Class-Type 0 TBD 1279 Invalid Class-Type value 0 TBD 1280 CT and setup priority do not 0 TBD 1281 form a configured TE-Class 1282 CT and holding priority do not 0 TBD 1283 form a configured TE-Class' 1285 Appendix C - Example Formulas for Computing "Unreserved TE-Class [i]" 1287 Keeping in mind that details of admission control algorithms as well 1288 as formulas for computing "Unreserved TE-Class [i]" are outside the 1289 scope of this specification, we provide below, for illustration 1290 purposes, an example of how values for the unreserved bandwidth for 1291 TE-Class[i] might be computed, assuming: 1292 - the Russian Doll Bandwidth Constraints Model is used 1293 - the basic admission control algorithm which simply deducts 1294 the exact bandwidth of any established LSP from all of the 1295 Bandwidth Constraints relevant to the CT associated with that 1296 LSP. 1297 - the optional per-CT Local Overbooking Multipliers are not 1298 used (.i.e. LOM[c]=1, 0<= c <=7). 1300 We assume that: 1301 TE-Class [i] <--> < CTc , preemption p> 1302 in the configured TE-Class mapping. 1304 Let us define "Reserved(CTb,q)" as the sum of the bandwidth reserved 1305 by all established LSPs which belong to CTb and have a holding 1306 priority of q. Note that if q and CTb do not form one of the 8 1307 possible configured TE-Classes, then there can not be any established 1308 LSP which belong to CTb and have a holding priority of q, so in that 1309 case Reserved(CTb,q)=0. 1311 Le Faucheur et. al 24 1313 Protocols for Diff-Serv-aware TE February 2002 1315 For readability, formulas are first shown assuming only 4 CTs are 1316 active. The formulas below can be extended trivially to cover the 1317 cases where more CTs are used. 1319 If CTc = CT0, then "Unreserved TE-Class [i]" = 1320 [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 3 1322 If CTc = CT1, then "Unreserved TE-Class [i]" = 1323 MIN [ 1324 [ BC1 - SUM ( Reserved(CTb,q) ) ] for q <= p and 1 <= b <= 3, 1325 [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 3 1326 ] 1328 If CTc = CT2, then "Unreserved TE-Class [i]" = 1329 MIN [ 1330 [ BC2 - SUM ( Reserved(CTb,q) ) ] for q <= p and 2 <= b <= 3, 1331 [ BC1 - SUM ( Reserved(CTb,q) ) ] for q <= p and 1 <= b <= 3, 1332 [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 3 1333 ] 1335 If CTc = CT3, then "Unreserved TE-Class [i]" = 1336 MIN [ 1337 [ BC3 - SUM ( Reserved(CTb,q) ) ] for q <= p and 3 <= b <= 3, 1338 [ BC2 - SUM ( Reserved(CTb,q) ) ] for q <= p and 2 <= b <= 3, 1339 [ BC1 - SUM ( Reserved(CTb,q) ) ] for q <= p and 1 <= b <= 3, 1340 [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 3 1341 ] 1343 The formula can be generalized to 8 active CTs and expressed in a 1344 more compact way in the following: 1346 "Unreserved TE-Class [i]" = 1347 MIN [ 1348 [ BCc - SUM ( Reserved(CTb,q) ) ] for q <= p and c <= b <= 7, 1349 . . . 1350 [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 7, 1351 ] 1353 where: 1354 TE-Class [i] <--> < CTc , preemption p> 1355 in the configured TE-Class mapping. 1357 Appendix D - Prediction for Multiple Path Computation 1359 There are situations where a Head-End needs to compute paths for 1360 multiple LSPs. There are potential advantages for the Head-end in 1362 Le Faucheur et. al 25 1364 Protocols for Diff-Serv-aware TE February 2002 1366 trying to predict the impact of the n-th LSP on the unreserved 1367 bandwidth when computing the path for the (n+1)-th LSP, before 1368 receiving updated IGP information. One example would be to perform 1369 better load-distribution of the multiple LSPs across multiple paths. 1370 Another example would be to avoid CAC rejection when the (n+1)-th LSP 1371 would no longer fit on a link after establishment of the n-th LSP. 1372 While there are also a number of conceivable scenarios where doing 1373 such predictions might result in a worse situation, it is more likely 1374 to improve the situation. As a matter of fact, a number of network 1375 administrators have elected to use such predictions when deploying 1376 existing TE. 1378 Such predictions are local matters, are optional and are outside the 1379 scope of this specification. 1381 Where such predictions are not used, the optional Bandwidth 1382 Constraint sub-TLV and the optional Local Overbooking Multiplier sub- 1383 TLV need not be advertised in IGP since the information contained in 1384 the Unreserved Bw sub-TLV is all that is required by Head-Ends to 1385 perform Constraint Based Routing. 1387 Where such predictions are used on Head-Ends, the optional Bandwidth 1388 Constraint sub-TLV (and the optional Local Overbooking Multiplier 1389 sub-TLV if different overbooking ratios need to be supported on 1390 different links) may be advertised in IGP. This is in order for the 1391 Head-ends to predict as accurately as possible how an LSP affects 1392 unreserved bandwidth values for subsequent LSPs. 1394 Remembering that actual admission control algorithms are left for 1395 vendor differentiation, we observe that predictions may only be used 1396 effectively when the Head-end LSR predictions are based on the same 1397 (or a very close) admission control algorithm as used by other LSRs. 1399 Appendix E - Addressing [DSTE-REQ] Scenarios 1401 This Appendix provides examples of how the DS-TE solution can be used 1402 to support each of the scenario described in [DSTE-REQ]. 1404 1. Scenario 1: Limiting Amount of Voice 1406 By configuring on every link: 1407 - Bandwidth Constraint 1 (for CT1=Voice) = "certain percentage" 1408 of link capacity 1409 - BC0= Max Reservable Link Bandwidth = link capacity 1411 By configuring: 1412 - every CT1/Voice TE-LSP with preemption =0 1413 - every CT0/Data TE-LSP with preemption =1 1415 The proposed solution will address all the requirements: 1417 Le Faucheur et. al 26 1419 Protocols for Diff-Serv-aware TE February 2002 1421 - amount of Voice traffic limited to desired percentage on 1422 every link 1423 - data traffic capable of using all remaining link capacity 1424 - voice traffic capable of preempting other traffic 1426 2. Scenario 2: Maintain Relative Proportion of Traffic Classes 1428 By configuring on every link: 1429 - BC2 for CT2 = e.g. 45% 1430 - BC1 for CT1+CT2 = e.g. 80% 1431 - BC0 for CT0+CT1+CT2= e.g.100% 1433 The proposed DS-TE solution will ensure that the amount of traffic of 1434 each Class Type established on a link is within acceptable levels as 1435 compared to the resources allocated to the corresponding Diff-Serv 1436 PHBs regardless of which order the LSPs are routed in, regardless of 1437 which preemption priorities are used by which LSPs and regardless of 1438 failure situations. Optional automatic adjustment of Diff-Sev 1439 scheduling configuration could be used for maintaining very strict 1440 relationship between amount of established traffic of each Class Type 1441 and corresponding Diff-Serv resources. 1443 3. Scenario 3: Guaranteed Bandwidth Services 1445 By configuring on every link: 1446 - BC1 for CT1 = "given" percentage of bandwidth (appropriate to 1447 achieve the Guaranteed Bandwidth service's QoS objectives) 1448 - BC0 for CT0+CT1 = 100% 1450 The proposed DS-TE solution will ensure that the amount of Guaranteed 1451 Bandwidth Trafic established on every link remains below the given 1452 percentage so that it will always meet its QoS objectives. AT the 1453 same time it will allow traffic engineering of the rest of the 1454 traffic such that links can be filled up. 1456 Appendix F - Solution Evaluation 1458 1. Satisfying Detailed Requirements 1460 This DS-TE Solution address all the scenarios presented in [DSTE-REQ] 1461 as explained in Appendix E. It also satisfy all the detailed 1462 requirements presented in [DSTE-REQ]. 1464 2. Flexibility 1466 This DS-TE solution supports 8 CTs. It is entirely flexible as to how 1467 Traffic Trunks are grouped together into a CT. 1469 3. Extendibility 1471 Le Faucheur et. al 27 1473 Protocols for Diff-Serv-aware TE February 2002 1475 A maximum of 8 CTs is considered by the authors of this document as 1476 more than comfortable. However, this solution could be extended to 1477 support more CTs if deemed necessary in the future. However, this 1478 would necessitate additional IGP extensions beyond those specified in 1479 this document. 1481 4. Scalability 1483 This DS-TE solution is expected to have a very small scalability 1484 impact compared to existing TE. 1486 From an IGP viewpoint, the amount of mandatory information to be 1487 advertised is identical to existing TE. Two additional sub-TLVs have 1488 been specified, but their use is optional and those contained a 1489 limited amount of static information (at most 8 Bandwidth Constraints 1490 and 8 LOMs). 1492 We expect no noticeable impact on LSP Path computation since, as with 1493 existing TE, this solution only require CSPF to consider a single 1494 unreserved bandwidth value for any given LSP. 1496 From a signaling viewpoint we expect no significant impact due to 1497 this solution since it only requires processing of one additional 1498 information (the Class-Type) and does not significantly increase the 1499 likelihood of CAC rejection. Note that DS-TE has some inherent impact 1500 on LSP signaling in the sense that it assumes that different classes 1501 of traffic are split over different LSPs so that more LSPs need to be 1502 signaled; but this is due to the DS-TE concept itself and not to the 1503 actual DS-TE solution discussed here. 1505 5. Backward Compatibility/Migration 1507 This solution is expected to allow smooth migration from existing TE 1508 to DS-TE. This is because existing TE can be supported exactly as 1509 today as a particular configuration of DS-TE. This means that an 1510 "upgraded" LSR with a DS-TE implementation can directly interwork 1511 with an "old" LSR supporting existing TE only. 1513 This solution is expected to allow smooth migration when increasing 1514 the number of CTs actually deployed since it only requires 1515 configuration changes. however, these changes must be performed in a 1516 coordinated manner across the DS-TE domain. 1518 Le Faucheur et. al 28