idnits 2.17.1 draft-ietf-tewg-diff-te-russian-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. == 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 727 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 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 205: '... Class [i]" MUST reflect all of the B...' RFC 2119 keyword, line 310: '...ndwidth constraints MUST be applied to...' RFC 2119 keyword, line 313: '...model definition MUST be extended in t...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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) -- Looks like a reference, but probably isn't: '0' on line 445 -- Looks like a reference, but probably isn't: '1' on line 446 == Unused Reference: 'OSPF-TE' is defined on line 479, but no explicit reference was found in the text == Unused Reference: 'ISIS-TE' is defined on line 486, but no explicit reference was found in the text == Unused Reference: 'RSVP-TE' is defined on line 489, but no explicit reference was found in the text == Unused Reference: 'DIFF-MPLS' is defined on line 492, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-tewg-diff-te-reqts-06 ** Downref: Normative reference to an Informational draft: draft-ietf-tewg-diff-te-reqts (ref. 'DSTE-REQ') == Outdated reference: A later version (-08) exists of draft-ietf-tewg-diff-te-proto-02 == Outdated reference: A later version (-06) exists of draft-wlai-tewg-bcmodel-00 == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-08 == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-04 Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Francois Le Faucheur, Editor 3 Cisco Systems, Inc. 5 IETF Internet Draft 6 Expires: April, 2002 7 Document: draft-ietf-tewg-diff-te-russian-00.txt October, 2002 9 Russian Dolls Bandwidth Constraints Model for 10 Diff-Serv-aware MPLS Traffic Engineering 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. Internet-Drafts are 16 Working documents of the Internet Engineering Task Force (IETF), its 17 areas, and its working groups. Note that other groups may also 18 distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document provides a detailed description of a candidate 33 Bandwidth Constraints model for Diff-Serv-aware MPLS Traffic 34 Engineering, which is referred to as the Russian Dolls model. 36 Summary for Sub-IP related Internet Drafts 38 RELATED DOCUMENTS: 39 draft-ietf-tewg-diff-te-reqts-06.txt 40 draft-ietf-tewg-diff-te-proto-02.txt 42 WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK 43 This ID is a Working Group document of the TE Working Group. 45 WHY IS IT TARGETED AT THIS WG(s) 46 TEWG is responsible for specifying protocol extensions for support of 47 Diff-Serv-aware MPLS Traffic Engineering. 49 Le Faucheur, et. al 1 51 Russian Dolls model for DS-TE October 2002 53 JUSTIFICATION 54 The TEWG charter states that "This will entail verification and 55 review of the Diffserv requirements in the WG Framework document and 56 initial specification of how these requirements can be met through 57 use and potentially expansion of existing protocols." 58 In line with this, the TEWG is in the process of selecting bandwidth 59 constraints model for Diff-Serv-aware MPLS Traffic Engineering. This 60 document describes one bandwidth constraints model under 61 consideration. 63 1. Introduction 65 [DSTE-REQ] presents the Service Providers requirements for support of 66 Diff-Serv-aware MPLS Traffic Engineering (DS-TE). This includes the 67 fundamental requirement to be able to enforce different bandwidth 68 constraints for different classes of traffic. 70 [DSTE-REQ] also defines the concept of Bandwidth Constraint Models 71 for DS-TE and states that "The DS-TE technical solution must specify 72 one default bandwidth constraint model which must be supported by any 73 DS-TE implementation. However, additional bandwidth constraint models 74 may also be specified." 76 This document provides a more detailed description of one particular 77 Bandwidth Constraint model introduced in [DSTE-REQ] which is called 78 the Russian Dolls model. The Russian Dolls model is one of the 79 candidate models under consideration by the TEWG for selection of the 80 default bandwidth constraints model and/or of optional additional 81 models. 83 [DSTE-PROTO] specifies the IGP and RSVP-TE signaling extensions for 84 support of DS-TE. These extensions support the Russian Dolls model. 86 Considerations on the Russian Dolls model are provided in [RUSSIAN- 87 CONS] and [BCMODEL]. 89 2. Contributing Authors 91 This document was the collective work of several. The text and 92 content of this document was contributed by the editor and the co- 93 authors listed below. (The contact information for the editor appears 94 in Section 11, and is not repeated below.) 96 Jim Boyle Kireeti Kompella 97 Protocol Driven Networks, Inc. Juniper Networks, Inc. 98 1381 Kildaire Farm Road #288 1194 N. Mathilda Ave. 99 Cary, NC 27511, USA Sunnyvale, CA 94099 100 Phone: (919) 852-5160 Email: kireeti@juniper.net 101 Email: jboyle@pdnets.com 103 Le Faucheur et. al 2 105 Russian Dolls model for DS-TE October 2002 107 William Townsend Thomas D. Nadeau 108 Tenor Networks Cisco Systems, Inc. 109 100 Nagog Park 250 Apollo Drive 110 Acton, MA 01720 Chelmsford, MA 01824 111 Phone: +1-978-264-4900 Phone: +1-978-244-3051 112 Email: Email: tnadeau@cisco.com 113 btownsend@tenornetworks.com 115 Darek Skalecki 116 Nortel Networks 117 3500 Carling Ave, 118 Nepean K2H 8E9 119 Phone: +1-613-765-2252 120 Email: dareks@nortelnetworks.com 122 3. Definitions 124 For readability a number of definitions from [DSTE-REQ] are repeated 125 here: 127 Class-Type (CT): the set of Traffic Trunks crossing a link that is 128 governed by a specific set of Bandwidth Constraints. CT is used for 129 the purposes of link bandwidth allocation, constraint based routing 130 and admission control. A given Traffic Trunk belongs to the same CT 131 on all links. 133 TE-Class: A pair of: 134 i. a Class-Type 135 ii. a preemption priority allowed for that Class-Type. This 136 means that an LSP transporting a Traffic Trunk from 137 that Class-Type can use that preemption priority as the 138 set-up priority, as the holding priority or both. 140 4. Russian Dolls Model Definition 142 The "Russian Dolls" model is defined in the following manner 143 (assuming for now that the optional per-CT Local Overbooking 144 Multipliers defined in [DSTE-PROTO] are not used - i.e. LOM[c]=1 , 145 0<=c<=7 ): 146 o Maximum Number of Bandwidth Constraints (MaxBC)= Maximum 147 Number of Class-Types (MaxCT) = 8 148 o All LSPs supporting Traffic Trunks from CTc (with 149 b<=c<=7) use no more than BCb i.e.: 150 - All LSPs from CT7 use no more than BC7 151 - All LSPs from CT6 and CT7 use no more than BC6 152 - All LSPs from CT5, CT6 and CT7 use no more than BC5 153 - etc. 154 - All LSPs from CT0, CT1,... CT7 use no more than BC0 156 Le Faucheur et. al 3 158 Russian Dolls model for DS-TE October 2002 160 Purely for illustration purposes, the diagram below represents the 161 Russian Doll Bandwidth Constraints model in a pictorial manner when 3 162 Class-Types are active: 164 I------------------------------------------------------I 165 I-------------------------------I I 166 I--------------I I I 167 I CT2 I CT2+CT1 I CT2+CT1+CT0 I 168 I--------------I I I 169 I-------------------------------I I 170 I------------------------------------------------------I 172 I-----BC2------> 173 I----------------------BC1------> 174 I---------------------------------------------BC0------> 176 While simpler or, conversely, more flexible/sophisticated Bandwidth 177 Constraints models can be defined, the Russian Dolls model is an 178 attractive trade-off for the following reasons: 179 - Network administrators generally find it superior to the 180 basic Maximum Allocation model consisting of a single 181 independent BC per CT (which, in typical deployment scenarios 182 may result in either capacity wastage, low priority Traffic 183 Trunk starvation and/or degradation of QoS objectives). 184 - network administrators generally find it sufficient for the 185 real life deployments currently anticipated (e.g. it 186 addresses all the scenarios described in [DSTE-REQ] as 187 illustrated in Appendix A below). 188 - it remains simple and only requires limited protocol 189 extensions, while more sophisticated Bandwidth Constraints 190 model may require more complex extensions. 192 More details on the properties of the Russian Dolls model can be 193 found in [RUSSIAN-CONS] and [BCMODEL]. 195 As a simple example usage of the "Russian Doll" Bandwidth Constraints 196 Model, a network administrator using one CT for Voice (CT1) and one 197 CT for data (CT0) might configure on a given link: 198 - BC0 = 2.5 Gb/s (i.e. Voice + Data is limited to 2.5 Gb/s) 199 - BC1= 1.5 Gb/s (i.e. Voice is limited to 1.5 Gb/s). 201 5. Example Formulas for Computing "Unreserved TE-Class [i]" with 202 Russian Dolls Model 204 As specified in [DSTE-PROTO], formulas for computing "Unreserved TE- 205 Class [i]" MUST reflect all of the Bandwidth Constraints relevant to 206 the CT associated with TE-Class[i], and thus, depend on the Bandwidth 207 Constraints Model. 209 Le Faucheur et. al 4 211 Russian Dolls model for DS-TE October 2002 213 Keeping in mind, as explained in [DSTE-PROTO], that details of 214 admission control algorithms as well as formulas for computing 215 "Unreserved TE-Class [i]" are outside the scope of the IETF work, we 216 provide in this section, for illustration purposes, an example of how 217 values for the unreserved bandwidth for TE-Class[i] might be computed 218 with the Russian Dolls model, assuming: 219 - the basic admission control algorithm which simply deducts 220 the exact bandwidth of any established LSP from all of the 221 Bandwidth Constraints relevant to the CT associated with that 222 LSP. 223 - the optional per-CT Local Overbooking Multipliers are not 224 used (.i.e. LOM[c]=1, 0<= c <=7). 226 We assume that: 227 TE-Class [i] <--> < CTc , preemption p> 228 in the configured TE-Class mapping. 230 Let us define "Reserved(CTb,q)" as the sum of the bandwidth reserved 231 by all established LSPs which belong to CTb and have a holding 232 priority of q. Note that if q and CTb do not form one of the 8 233 possible configured TE-Classes, then there can not be any established 234 LSP which belong to CTb and have a holding priority of q, so in that 235 case Reserved(CTb,q)=0. 237 For readability, formulas are first shown assuming only 4 CTs are 238 active. The formulas are then extended to cover the cases where more 239 CTs are used. 241 If CTc = CT0, then "Unreserved TE-Class [i]" = 242 [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 3 244 If CTc = CT1, then "Unreserved TE-Class [i]" = 245 MIN [ 246 [ BC1 - SUM ( Reserved(CTb,q) ) ] for q <= p and 1 <= b <= 3, 247 [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 3 248 ] 250 If CTc = CT2, then "Unreserved TE-Class [i]" = 251 MIN [ 252 [ BC2 - SUM ( Reserved(CTb,q) ) ] for q <= p and 2 <= b <= 3, 253 [ BC1 - SUM ( Reserved(CTb,q) ) ] for q <= p and 1 <= b <= 3, 254 [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 3 255 ] 257 If CTc = CT3, then "Unreserved TE-Class [i]" = 258 MIN [ 259 [ BC3 - SUM ( Reserved(CTb,q) ) ] for q <= p and 3 <= b <= 3, 260 [ BC2 - SUM ( Reserved(CTb,q) ) ] for q <= p and 2 <= b <= 3, 261 [ BC1 - SUM ( Reserved(CTb,q) ) ] for q <= p and 1 <= b <= 3, 263 Le Faucheur et. al 5 265 Russian Dolls model for DS-TE October 2002 267 [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 3 268 ] 270 The formula can be generalized to 8 active CTs and expressed in a 271 more compact way in the following: 273 "Unreserved TE-Class [i]" = 274 MIN [ 275 [ BCc - SUM ( Reserved(CTb,q) ) ] for q <= p and c <= b <= 7, 276 . . . 277 [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 7, 278 ] 280 where: 281 TE-Class [i] <--> < CTc , preemption p> 282 in the configured TE-Class mapping. 284 6. Support of Optional Local Overbooking Method 286 We remind the reader that, as discussed in [DSTE-PROTO], the 287 "LSP/link size overbooking" method (which does not use the Local 288 Overbooking Multipliers - LOMs-) is expected to be sufficient in many 289 DS-TE environments. It is expected that the optional Local 290 Overbooking method (and LOMs) would only be used in specific 291 environments, in particular where different overbooking ratios need 292 to be enforced on different links of the DS-TE domain and cross- 293 effect of overbooking across CTs needs to be accounted for very 294 accurately. 296 This section discusses the impact of the optional local overbooking 297 method on the Russian Dolls model and associated rules and formula. 298 This is only applicable in the cases where the optional local 299 overbooking method is indeed supported by the DS-TE LSRs and actually 300 deployed. 302 6.1. Russian Dolls Model Definition With Local Overbooking 304 Let us define "Reserved(CTc)" as the sum of the bandwidth reserved by 305 all established LSPs which belong to CTc. 307 Let us define "Normalised(CTc)" as "Reserved(CTc)/LOM(c)". 309 As specified in [DSTE-PROTO], when the optional Local Overbooking 310 method is supported, the bandwidth constraints MUST be applied to 311 "Normalised(CTc)" rather than to "Reserved(CTc)". Thus, when the 312 optional Local Overbooking method is supported, the "Russian Doll" 313 model definition MUST be extended in the following manner: 314 - Maximum Number of Bandwidth Constraints (MaxBC)= Maximum 315 Number of Class-Types (MaxCT) = 8 316 - SUM [ Normalised(CTc), for b<=c<=7 ] <= BCb i.e.: 318 Le Faucheur et. al 6 320 Russian Dolls model for DS-TE October 2002 322 o [ Normalised(CT7) ] <= BC7 323 o [ Normalised(CT6) + Normalised(CT7) ] <= BC6 324 o [ Normalised(CT5) + Normalised(CT6) + 325 Normalised(CT7) ] <= BC5 326 o etc. 327 o [ Normalised(CT0) + Normalised(CT1) + 328 ... 329 Normalised(CT6) + Normalised(CT7) ] <= BC0 331 Purely for illustration purposes, the diagram below represents the 332 Russian Doll Bandwidth Constraints model in a pictorial manner when 3 333 Class-Types are active and the local overbooking method is used: 335 I--------------------------------------------------------------I 336 I-----------------------------------------I Normalised(CT2) I 337 I--------------------I Normalised(CT2) I + I 338 I Normalised(CT2) I + I Normalised(CT1) I 339 I--------------------I Normalised(CT1) I + I 340 I-----------------------------------------I Normalised(CT0) I 341 I--------------------------------------------------------------I 343 I--------BC2---------> 344 I-------------------------BC1-------------> 345 I-----------------------------------------------BC0------------> 347 6.2. Example Formulas for Computing "Unreserved TE-Class [i]" With 348 Local Overbooking 350 Again, keeping in mind that details of admission control algorithms 351 as well as formulas for computing "Unreserved TE-Class [i]" are 352 outside the scope of the IETF work, we provide in this section, for 353 illustration purposes, an example of how values for the unreserved 354 bandwidth for TE-Class[i] might be computed with the Russian Dolls 355 model, assuming: 356 - the basic admission control algorithm which simply deducts 357 the exact bandwidth of any established LSP from all of the 358 Bandwidth Constraints relevant to the CT associated with that 359 LSP. 360 - the optional per-CT Local Overbooking Multipliers are used. 362 When the optional local overbooking method is supported, the example 363 generalized formula of section 5 becomes: 365 "Unreserved TE-Class [i]" = 366 LOM(c) x MIN [ 367 [ BCc - SUM ( Normalised(CTb,q) ) ] for q <= p and c <= b <= 7, 368 . . . 369 [ BC0 - SUM ( Normalised(CTb,q) ) ] for q <= p and 0 <= b <= 7, 370 ] 372 where: 374 Le Faucheur et. al 7 376 Russian Dolls model for DS-TE October 2002 378 - TE-Class [i] <--> < CTc , preemption p> 379 in the configured TE-Class mapping. 380 - Normalised(CTb,q) = Reserved(CTb/q)/LOM(b) 382 6.3. Example Usage of LOM 384 To illustrate usage of the local overbooking method with the Russian 385 Dolls model, let's consider a DS-TE deployment where two CTs (CT0 for 386 data and CT1 for voice) and a single preemption priority are used. 388 The TE-Class mapping is the following: 390 TE-Class <--> CT, preemption 391 ============================== 392 0 CT0, 0 393 1 CT1, 0 394 rest unused 396 Let's assume that on a given link, BCs and LOMs are configured in the 397 following way: 398 BC0 = 200 399 BC1 = 100 400 LOM(0) = 4 (i.e. = 400%) 401 LOM(1) = 2 (i.e. = 200%) 403 Let's further assume that the DS-TE LSR uses the example formulas 404 presented above for computing unreserved bandwidth values. 406 If there is no established LSP on the considered link, the LSR will 407 advertise for that link in IGP : 408 Unreserved TE-Class [0] = 4 x (200 - 0/4 - 0/2 )= 800 409 Unreserved TE-Class [1] = 2 x (100- 0/2) = 200 410 Note again that these values advertised for Unreserved Bandwidth are 411 larger than BC1 and BC0. 413 If there is only a single established LSP, with CT=CT0 and BW=100, 414 the LSR will advertise: 415 Unreserved TE-Class [0] = 4 x (200 - 100/4 - 0/2 )=700 416 Unreserved TE-Class [1] = 2 x (100- 0/2) = 200 418 If there is only a single established LSP, with CT=CT1 and BW=100, 419 the LSR will advertise: 420 Unreserved TE-Class [0] = 4 x (200 - 0/4 - 100/2 )= 600 421 Unreserved TE-Class [1] = 2 x (100- 100/2) = 100 422 Note that the impact of an LSP on the unreserved bandwidth of a CT 423 does not depend only on the LOM for that CT: it also depends on the 424 LOM for the CT of the LSP. This can be seen in our example. A BW=100 425 tunnel affects Unreserved 426 CT0 twice as much if it is a CT1 tunnel, than if it is a CT0 tunnel. 427 It reduces Unreserved CTO by 200 (800->600) rather than by 100 428 (800->700). This is because LOM(1) is half as big as LOM(0). This 430 Le Faucheur et. al 8 432 Russian Dolls model for DS-TE October 2002 434 illustrates why the local overbooking method allows very fine 435 accounting of cross-effect of overbooking across CTs, as compared 436 with the LSP/link size overbooking method. 438 If there are two established LSPs, one with CT=CT1 and BW=100 and one 439 with CT=CT0 and BW=100, the LSR will advertise: 440 Unreserved TE-Class [0] = 4 x (200 - 100/4 - 100/2) = 500 441 Unreserved TE-Class [1] = 2 x (100 - 100/2) = 100 443 If there are two LSPs established, one with CT=CT1 and BW=100, and 444 one with CT=CT0 and BW=480, the LSR will advertise: 445 Unreserved TE-Class [0] = 4 x (200 - 480/4 - 100/2) = 120 446 Unreserved TE-Class [1] = 2 x MIN [ (200 - 480/4 - 100/2), 447 (100 - 100/2) ] 448 = 2 x MIN [ 30, 50 ] 449 = 60 451 7. Security Considerations 453 No new security considerations are raised by this document; they are 454 the same as in the DS-TE requirements document [DSTE-REQ]. 456 8. Acknowledgments 458 We thank Martin Tatham for his earlier contribution in this work. 460 9. Normative References 462 [DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv- 463 aware MPLS Traffic Engineering, draft-ietf-tewg-diff-te-reqts-06.txt, 464 September 2002. 466 [DSTE-PROTO] Le Faucheur et al, Protocol extensions for support of 467 Diff-Serv-aware MPLS Traffic Engineering, draft-ietf-tewg-diff-te- 468 proto-02.txt, October 2002. 470 10. Informative References 472 [RUSSIAN-CONS] Le Faucheur, "Considerations on Bandwidth Constraints 473 Model for DS-TE", draft-lefaucheur-tewg-russian-dolls-00.txt, June 474 2002. 476 [BCMODEL] Lai, "Bandwidth Constraints Models for DS-TE", 477 draft-wlai-tewg-bcmodel-00.txt, June 2002. 479 [OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF, draft- 480 katz-yeung-ospf-traffic-08.txt, September 2002. 482 Le Faucheur et. al 9 484 Russian Dolls model for DS-TE October 2002 486 [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft- 487 ietf-isis-traffic-04.txt, August 2001. 489 [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 490 Tunnels", RFC 3209, December 2001. 492 [DIFF-MPLS] Le Faucheur et al, "MPLS Support of Diff-Serv", RFC3270, 493 May 2002. 495 11. Editor's Address: 497 Francois Le Faucheur 498 Cisco Systems, Inc. 499 Village d'Entreprise Green Side - Batiment T3 500 400, Avenue de Roumanille 501 06410 Biot-Sophia Antipolis 502 France 503 Phone: +33 4 97 23 26 19 504 Email: flefauch@cisco.com 506 Appendix A - Addressing [DSTE-REQ] Scenarios 508 This Appendix provides examples of how the Russian Dolls Model 509 Bandwidth Constraints model can be used to support each of the 510 scenarios described in [DSTE-REQ]. 512 1. Scenario 1: Limiting Amount of Voice 514 By configuring on every link: 515 - Bandwidth Constraint 1 (for CT1=Voice) = "certain percentage" 516 of link capacity 517 - BC0 (for CT1=Voice + CT0= Data) = link capacity 519 By configuring: 520 - every CT1/Voice TE-LSP with preemption =0 521 - every CT0/Data TE-LSP with preemption =1 523 DS-TE with the Russian Dolls model will address all the requirements: 524 - amount of Voice traffic limited to desired percentage on 525 every link 526 - data traffic capable of using all remaining link capacity 527 - voice traffic capable of preempting other traffic 529 2. Scenario 2: Maintain Relative Proportion of Traffic Classes 531 By configuring on every link: 532 - BC2 (for CT2) = e.g. 45% 533 - BC1 (for CT1+CT2) = e.g. 80% 534 - BC0 (for CT0+CT1+CT2) = e.g.100% 536 Le Faucheur et. al 10 538 Russian Dolls model for DS-TE October 2002 540 DS-TE with the Russian Dolls model will ensure that the amount of 541 traffic of each Class Type established on a link is within acceptable 542 levels as compared to the resources allocated to the corresponding 543 Diff-Serv PHBs regardless of which order the LSPs are routed in, 544 regardless of which preemption priorities are used by which LSPs and 545 regardless of failure situations. Optional automatic adjustment of 546 Diff-Sev scheduling configuration could be used for maintaining very 547 strict relationship between amount of established traffic of each 548 Class Type and corresponding Diff-Serv resources. 550 3. Scenario 3: Guaranteed Bandwidth Services 552 By configuring on every link: 553 - BC1 (for CT1) = "given" percentage of link bandwidth 554 (appropriate to achieve the Guaranteed Bandwidth service's 555 QoS objectives) 556 - BC0 (for CT0+CT1) = 100% of link bandwidth 558 DS-TE with the Russian Dolls model will ensure that the amount of 559 Guaranteed Bandwidth Trafic established on every link remains below 560 the given percentage so that it will always meet its QoS objectives. 561 At the same time it will allow traffic engineering of the rest of the 562 traffic such that links can be filled up. 564 Le Faucheur et. al 11