idnits 2.17.1 draft-ietf-tewg-diff-te-russian-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 577. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 441. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 448. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 454. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 585), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 469. ** Found boilerplate matching RFC 3978, Section 5.5 (on line 577), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 4 text on line 496. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3978, Section 5.5 boilerplate, a section with a similar start was also found: This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2004) is 7065 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2119' on line 389 looks like a reference -- Missing reference section? 'DSTE-REQ' on line 502 looks like a reference -- Missing reference section? 'DSTE-PROTO' on line 385 looks like a reference -- Missing reference section? 'GMPLS-RECOV' on line 422 looks like a reference -- Missing reference section? 'MPLS-BACKUP' on line 426 looks like a reference -- Missing reference section? 'DSTE-MAM' on line 403 looks like a reference -- Missing reference section? 'BC-CONS' on line 397 looks like a reference -- Missing reference section? 'BC-MODEL' on line 400 looks like a reference -- Missing reference section? 'IANA-CONS' on line 392 looks like a reference -- Missing reference section? 'DSTE-MAR' on line 407 looks like a reference -- Missing reference section? 'OSPF-TE' on line 411 looks like a reference -- Missing reference section? 'ISIS-TE' on line 414 looks like a reference -- Missing reference section? 'RSVP-TE' on line 417 looks like a reference -- Missing reference section? 'DIFF-MPLS' on line 420 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEWG 3 Internet Draft Francois Le Faucheur 4 Editor 5 draft-ietf-tewg-diff-te-russian-07.txt Cisco Systems, 6 Inc. 7 Expires: June 2005 December 2004 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 subject to all provisions 15 of section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on June 13, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). All Rights Reserved. 43 Abstract 45 Russian Dolls Model for DS-TE December 2005 47 This document provides specification for one Bandwidth Constraints 48 Model for Diff-Serv-aware MPLS Traffic Engineering, which is referred 49 to as the Russian Dolls Model. 51 Specification of Requirements 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in [RFC2119]. 57 Table of Contents 59 1. Introduction...................................................2 60 2. Contributing Authors...........................................3 61 3. Definitions....................................................3 62 4. Russian Dolls Model Definition.................................4 63 5. Example Formulas for Computing "Unreserved TE-Class [i]" with 64 Russian Dolls Model...............................................6 65 6. Receiving both Maximum Reservable Bandwidth and Bandwidth 66 Constraints sub-TLVs..............................................7 67 7. Security Considerations........................................8 68 8. Acknowledgments................................................8 69 9. IANA Considerations............................................8 70 10. Normative References..........................................8 71 11. Informative References........................................9 72 12. Intellectual Property Considerations.........................10 73 13. Editor's Address:............................................10 74 14. Full Copyright Statement.....................................10 75 Appendix A - Addressing [DSTE-REQ] Scenarios.....................11 76 Disclaimer of Validity...........................................12 77 Copyright Statement..............................................13 78 Acknowledgment...................................................13 80 1.Introduction 82 [DSTE-REQ] presents the Service Providers requirements for support of 83 Diff-Serv-aware MPLS Traffic Engineering (DS-TE). This includes the 84 fundamental requirement to be able to enforce different Bandwidth 85 Constraints for different classes of traffic. 87 [DSTE-REQ] also defines the concept of Bandwidth Constraints Model 88 for DS-TE and states that "The DS-TE technical solution MUST specify 89 at least one Bandwidth Constraints Model and MAY specify multiple 90 Bandwidth Constraints Models." 92 Russian Dolls Model for DS-TE December 2005 94 This document provides a detailed description of one particular 95 Bandwidth Constraints Model for DS-TE which is introduced in [DSTE- 96 REQ] and called the Russian Dolls Model (RDM). 98 [DSTE-PROTO] specifies the IGP and RSVP-TE signaling extensions for 99 support of DS-TE. These extensions support RDM. 101 2.Contributing Authors 103 This document was the collective work of several. The text and 104 content of this document was contributed by the editor and the co- 105 authors listed below. (The contact information for the editor appears 106 in Section 11, and is not repeated below.) 108 Jim Boyle Kireeti Kompella 109 Protocol Driven Networks, Inc. Juniper Networks, Inc. 110 1381 Kildaire Farm Road #288 1194 N. Mathilda Ave. 111 Cary, NC 27511, USA Sunnyvale, CA 94099 112 Phone: (919) 852-5160 Email: kireeti@juniper.net 113 Email: jboyle@pdnets.com 115 William Townsend Thomas D. Nadeau 116 Tenor Networks Cisco Systems, Inc. 117 100 Nagog Park 250 Apollo Drive 118 Acton, MA 01720 Chelmsford, MA 01824 119 Phone: +1-978-264-4900 Phone: +1-978-244-3051 120 Email: Email: tnadeau@cisco.com 121 btownsend@tenornetworks.com 123 Darek Skalecki 124 Nortel Networks 125 3500 Carling Ave, 126 Nepean K2H 8E9 127 Phone: +1-613-765-2252 128 Email: dareks@nortelnetworks.com 130 3.Definitions 132 For readability a number of definitions from [DSTE-REQ] are repeated 133 here: 135 Class-Type (CT): the set of Traffic Trunks crossing a link that is 136 governed by a specific set of Bandwidth Constraints. CT is used for 137 the purposes of link bandwidth allocation, constraint based routing 138 and admission control. A given Traffic Trunk belongs to the same CT 139 on all links. 141 Russian Dolls Model for DS-TE December 2005 143 TE-Class: A pair of: 144 i. a Class-Type 145 ii. a preemption priority allowed for that Class-Type. This 146 means that an LSP transporting a Traffic Trunk from 147 that Class-Type can use that preemption priority as the 148 set-up priority, as the holding priority or both. 150 A number of recovery mechanisms under investigation or specification 151 in the IETF take advantage of the concept of bandwidth sharing across 152 particular sets of LSPs. "Shared Mesh Restoration" in [GMPLS-RECOV] 153 and "Facility-based Computation Model" in [MPLS-BACKUP] are example 154 mechanisms which increase bandwidth efficiency by sharing bandwidth 155 across backup LSPs protecting against independent failures. To ensure 156 that the notion of "Reserved (CTc)" introduced in [DSTE-REQ] is 157 compatible with such a concept of bandwidth sharing across multiple 158 LSPs, the wording of the "Reserved (CTc)" definition provided in 159 [DSTE-REQ] is generalized into the following: 161 Reserved (CTc): For a given Class-Type CTc ( 0 <= c <= MaxCT ) ,let 162 us define "Reserved(CTc)" as the total amount of the bandwidth 163 reserved by all the established LSPs which belong to CTc. 165 With this generalization, the Russian Dolls Model definition provided 166 in this document is compatible with Shared Mesh Restoration defined 167 in [GMPLS-RECOV], so that DS-TE and Shared Mesh Protection can 168 operate simultaneously, under the assumption that Shared Mesh 169 Restoration operates independently within each DS-TE Class-Type and 170 does not operate across Class-Types (for example back up 171 LSPs protecting Primary LSPs of CTx need to also belong to CTx; 172 Excess Traffic LSPs sharing bandwidth with Backup LSPs of CTx need to 173 also belong to CTx). 175 We also introduce the following definition: 177 Reserved(CTb,q) : let us define "Reserved(CTb,q)" as the total amount 178 of the bandwidth reserved by all the established LSPs which belong to 179 CTb and have a holding priority of q. Note that if q and CTb do not 180 form one of the 8 possible configured TE-Classes, then there can not 181 be any established LSP which belong to CTb and have a holding 182 priority of q, so in that case, Reserved(CTb,q)=0. 184 4.Russian Dolls Model Definition 186 RDM is defined in the following manner: 187 o Maximum Number of Bandwidth Constraints (MaxBC)= 188 Maximum Number of Class-Types (MaxCT) = 8 189 o for each value of b in the range 0 <= b <= (MaxCT - 1): 191 Russian Dolls Model for DS-TE December 2005 193 SUM (Reserved (CTc)) <= BCb, 194 Where the SUM is across all values of c in the 195 range b <= c <= (MaxCT - 1) 196 o BC0= Maximum Reservable Bandwidth, so that 197 SUM (Reserved(CTc)) <= Max-Reservable-Bw, 198 where the SUM is across all values of c in the 199 range 0 <= c <= (MaxCT - 1) 201 A DS-TE LSR implementing RDM MUST support enforcement of Bandwidth 202 Constraints in compliance with this definition. 204 Both preemption within a Class-Type and across Class-Types is 205 allowed. 207 Where 8 Class-Types are active, the RDM Bandwidth Constraints can 208 also be expressed in the following way: 209 - All LSPs from CT7 use no more than BC7 210 - All LSPs from CT6 and CT7 use no more than BC6 211 - All LSPs from CT5, CT6 and CT7 use no more than BC5 212 - etc. 213 - All LSPs from CT0, CT1,... CT7 use no more than 214 BC0 = "Maximum Reservable Bandwidth" 216 Purely for illustration purposes, the diagram below represents the 217 Russian Dolls Bandwidth Constraints Model in a pictorial manner when 218 3 Class-Types are active: 220 I------------------------------------------------------I 221 I-------------------------------I I 222 I--------------I I I 223 I CT2 I CT2+CT1 I CT2+CT1+CT0 I 224 I--------------I I I 225 I-------------------------------I I 226 I------------------------------------------------------I 228 I-----BC2------> 229 I----------------------BC1------> 230 I------------------------------BC0=Max Reservable Bw---> 232 While simpler Bandwidth Constraints models or, conversely, more 233 flexible/sophisticated Bandwidth Constraints models can be defined, 234 the Russian Dolls Model is attractive in some DS-TE environments for 235 the following reasons: 236 - Although a little less intuitive than the Maximum Allocation 237 Model (see[DSTE-MAM]), RDM is still a simple model to 238 conceptualize. 240 Russian Dolls Model for DS-TE December 2005 242 - RDM can be used to simultaneously ensure bandwidth efficiency 243 and protection against QoS degradation of all Class-Types, 244 whether preemption is used or not. 245 - RDM can be used in conjunction with preemption to 246 simultaneously achieve isolation across Class-Types (so that 247 each Class-Type is guaranteed its share of bandwidth no 248 matter the level of contention by other classes), bandwidth 249 efficiency and protection against QoS degradation of all 250 Class-Types. 251 - RDM only requires limited protocol extensions such as the 252 ones defined in [DSTE-PROTO]. 254 RDM may not be attractive in some DS-TE environments for the 255 following reasons: 256 - if the usage of preemption is precluded for some 257 administrative reason, while RDM can still ensure bandwidth 258 efficiency and protection against QoS degradation of all CTs, 259 RDM cannot guarantee isolation across Class-Types. 261 Additional considerations on the properties of RDM can be found in 262 [BC-CONS] and [BC-MODEL]. 264 As a simple example usage of the "Russian Dolls" Bandwidth 265 Constraints Model, a network administrator using one CT for Voice 266 (CT1) and one CT for data (CT0) might configure on a given link: 267 - BC0 = Max-Reservable-Bw= 2.5 Gb/s (i.e. Voice + Data is 268 limited to 2.5 Gb/s) 269 - BC1= 1.5 Gb/s (i.e. Voice is limited to 1.5 Gb/s). 271 5.Example Formulas for Computing "Unreserved TE-Class [i]" with Russian 272 Dolls Model 274 As specified in [DSTE-PROTO], formulas for computing "Unreserved TE- 275 Class [i]" MUST reflect all of the Bandwidth Constraints relevant to 276 the CT associated with TE-Class[i], and thus, depend on the Bandwidth 277 Constraints Model. Thus, a DS-TE LSR implementing RDM MUST reflect 278 the RDM Bandwidth Constraints defined in section 4 above when 279 computing "Unreserved TE-Class [i]". 281 Keeping in mind, as explained in [DSTE-PROTO], that details of 282 admission control algorithms as well as formulas for computing 283 "Unreserved TE-Class [i]" are outside the scope of the IETF work, we 284 provide in this section, for illustration purposes, an example of how 285 values for the unreserved bandwidth for TE-Class[i] might be computed 286 with RDM, assuming the basic admission control algorithm which simply 287 deducts the exact bandwidth of any established LSP from all of the 288 Bandwidth Constraints relevant to the CT associated with that LSP. 290 Russian Dolls Model for DS-TE December 2005 292 We assume that: 293 TE-Class [i] <--> < CTc , preemption p> 294 in the configured TE-Class mapping. 296 For readability, formulas are first shown assuming only 3 CTs are 297 active. The formulas are then extended to cover the cases where more 298 CTs are used. 300 If CTc = CT0, then "Unreserved TE-Class [i]" = 301 [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 2 303 If CTc = CT1, then "Unreserved TE-Class [i]" = 304 MIN [ 305 [ BC1 - SUM ( Reserved(CTb,q) ) ] for q <= p and 1 <= b <= 2, 306 [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 2 307 ] 309 If CTc = CT2, then "Unreserved TE-Class [i]" = 310 MIN [ 311 [ BC2 - SUM ( Reserved(CTb,q) ) ] for q <= p and 2 <= b <= 2, 312 [ BC1 - SUM ( Reserved(CTb,q) ) ] for q <= p and 1 <= b <= 2, 313 [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 2 314 ] 316 The formula can be generalized to 8 active CTs and expressed in a 317 more compact way in the following: 319 "Unreserved TE-Class [i]" = 320 MIN [ 321 [ BCc - SUM ( Reserved(CTb,q) ) ] for q <= p and c <= b <= 7, 322 [ BC(c-1) - SUM ( Reserved(CTb,q) ) ] for q <= p and (c-1)<= b <= 7, 323 . . . 324 [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 7, 325 ] 326 where: 327 TE-Class [i] <--> < CTc , preemption p> 328 in the configured TE-Class mapping. 330 6.Receiving both Maximum Reservable Bandwidth and Bandwidth Constraints 331 sub-TLVs 333 [DSTE-PROTO] states that 334 " A DS-TE LSR which does advertise Bandwidth Constraints MUST use the 335 new "Bandwidth Constraints" sub-TLV (in addition to the existing 336 Maximum Reservable Bandwidth sub-TLV) to do so." 338 Russian Dolls Model for DS-TE December 2005 340 With RDM, BC0 is equal to the Maximum Reservable Bandwidth since they 341 both represent the aggregate constraint across all Class-Types. Thus, 342 a DS-TE LSR receiving both the "Maximum Reservable Bw" sub-TLV and 343 the new "Bandwidth Constraints" sub-TLV (which contains BC0) for a 344 given link where the RDM model is used, MAY ignore the "Maximum 345 Reservable Bw" sub-TLV. 347 7.Security Considerations 349 Security considerations related to the use of DS-TE are discussed in 350 [DSTE-PROTO]. Those apply independently of the Bandwidth Constraints 351 Model, including RDM specified in this document. 353 8.Acknowledgments 355 We thank Martin Tatham for his key contribution in this work. Tatiana 356 Renko is also warmly thanked for her instantiation of the Russian 357 Doll. 359 9.IANA Considerations 361 [DSTE-PROTO] defines a new name space for "Bandwidth Constraints 362 Model Id". The guidelines for allocation of values in that name space 363 are detailed in section 14.1 of [DSTE-PROTO]. In accordance with 364 these guidelines, IANA was requested to assign a Bandwidth 365 Constraints Model Id for RDM from the range 0-127 (which is to be 366 managed as per the "Specification Required" policy defined in [IANA- 367 CONS]). 369 Bandwidth Constraints Model Id = TBD was allocated by IANA to RDM. 371 To be removed by the RFC editor at the time of 372 publication 373 We request IANA to assign value 0 for the RDM model. 374 Once the value has been assigned, please replace "TBD" above 375 by the assigned value. 376 378 10.Normative References 380 [DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv- 381 aware MPLS Traffic Engineering, RFC3564. 383 Russian Dolls Model for DS-TE December 2005 385 [DSTE-PROTO] Le Faucheur et al, Protocol extensions for support of 386 Diff-Serv-aware MPLS Traffic Engineering, draft-ietf-tewg-diff-te- 387 proto-08.txt, work in progress. 389 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 390 Requirement Levels, RFC2119, March 1997. 392 [IANA-CONS], T. Narten et al, "Guidelines for Writing an IANA 393 Considerations Section in RFCs", RFC2434. 395 11.Informative References 397 [BC-CONS] Le Faucheur, "Considerations on Bandwidth Constraints Model 398 for DS-TE", draft-lefaucheur-tewg-russian-dolls-00.txt, June 2002. 400 [BC-MODEL] Lai, "Bandwidth Constraints Models for DS-TE", 401 draft-wlai-tewg-bcmodel-03.txt, work in progress. 403 [DSTE-MAM] Le Faucheur, Lai, "Maximum Allocation Bandwidth 404 Constraints Model for Diff-Serv-aware MPLS Traffic Engineering", 405 draft-ietf-tewg-diff-tet-mam-04.txt, work in progress. 407 [DSTE-MAR] Ash, "Max Allocation with Reservation Bandwidth 408 Constraints Model for MPLS/DiffServ TE & Performance Comparisons", 409 work in progress. 411 [OSPF-TE] Katz et al., "Traffic Engineering (TE) Extensions to OSPF 412 Version 2", RFC3630. 414 [ISIS-TE] Smit, Li, "Intermediate System to Intermediate System (IS- 415 IS) extensions for Traffic Engineering (TE)", RFC 3784. 417 [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 418 Tunnels", RFC 3209. 420 [DIFF-MPLS] Le Faucheur et al, "MPLS Support of Diff-Serv", RFC3270. 422 [GMPLS-RECOV] Lang et al, "Generalized MPLS Recovery Functional 423 Specification", draft-ietf-ccamp-gmpls-recovery-functional-02.txt, 424 work in progress. 426 [MPLS-BACKUP] Vasseur et al, "MPLS Traffic Engineering Fast reroute: 427 bypass tunnel path computation for bandwidth protection", draft- 428 vasseur-mpls-backup-computation-02.txt, work in progress. 430 Russian Dolls Model for DS-TE December 2005 432 12. Intellectual Property Considerations 434 The IETF takes no position regarding the validity or scope of any 435 Intellectual Property Rights or other rights that might be claimed to 436 pertain to the implementation or use of the technology described in 437 this document or the extent to which any license under such rights 438 might or might not be available; nor does it represent that it has 439 made any independent effort to identify any such rights. Information 440 on the procedures with respect to rights in RFC documents can be 441 found in BCP 78 and BCP 79. 443 Copies of IPR disclosures made to the IETF Secretariat and any 444 assurances of licenses to be made available, or the result of an 445 attempt made to obtain a general license or permission for the use of 446 such proprietary rights by implementers or users of this 447 specification can be obtained from the IETF on-line IPR repository at 448 http://www.ietf.org/ipr. 450 The IETF invites any interested party to bring to its attention any 451 copyrights, patents or patent applications, or other proprietary 452 rights that may cover technology that may be required to implement 453 this standard. Please address the information to the IETF at 454 ietf-ipr@ietf.org. 456 13.Editor's Address: 458 Francois Le Faucheur 459 Cisco Systems, Inc. 460 Village d'Entreprise Green Side - Batiment T3 461 400, Avenue de Roumanille 462 06410 Biot-Sophia Antipolis 463 France 464 Phone: +33 4 97 23 26 19 465 Email: flefauch@cisco.com 467 14.Full Copyright Statement 469 Copyright (C) The Internet Society (2004). All Rights Reserved. 471 This document and translations of it may be copied and furnished to 472 others, and derivative works that comment on or otherwise explain it 473 or assist in its implementation may be prepared, copied, published 474 and distributed, in whole or in part, without restriction of any 475 kind, provided that the above copyright notice and this paragraph are 476 included on all such copies and derivative works. However, this 477 document itself may not be modified in any way, such as by removing 479 Russian Dolls Model for DS-TE December 2005 481 the copyright notice or references to the Internet Society or other 482 Internet organizations, except as needed for the purpose of 483 developing Internet standards in which case the procedures for 484 copyrights defined in the Internet Standards process must be 485 followed, or as required to translate it into languages other than 486 English. 488 The limited permissions granted above are perpetual and will not be 489 revoked by the Internet Society or its successors or assigns. 491 This document and the information contained herein is provided on an 492 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 493 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 494 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 495 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 496 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 498 Appendix A - Addressing [DSTE-REQ] Scenarios 500 This Appendix provides examples of how the Russian Dolls Bandwidth 501 Constraints Model can be used to support each of the scenarios 502 described in [DSTE-REQ]. 504 1. Scenario 1: Limiting Amount of Voice 506 By configuring on every link: 507 - Bandwidth Constraint 1 (for CT1=Voice) = "certain percentage" 508 of link capacity 509 - BC0 (for CT1=Voice + CT0= Data) = link capacity 511 By configuring: 512 - every CT1/Voice TE-LSP with preemption =0 513 - every CT0/Data TE-LSP with preemption =1 515 DS-TE with the Russian Dolls Model will address all the requirements: 516 - amount of Voice traffic limited to desired percentage on 517 every link 518 - data traffic capable of using all remaining link capacity 519 - voice traffic capable of preempting other traffic 521 2. Scenario 2: Maintain Relative Proportion of Traffic Classes 523 By configuring on every link: 524 - BC2 (for CT2) = e.g. 45% 525 - BC1 (for CT1+CT2) = e.g. 80% 526 - BC0 (for CT0+CT1+CT2) = e.g.100% 528 Russian Dolls Model for DS-TE December 2005 530 DS-TE with the Russian Dolls Model will ensure that the amount of 531 traffic of each Class Type established on a link is within acceptable 532 levels as compared to the resources allocated to the corresponding 533 Diff-Serv PHBs regardless of which order the LSPs are routed in, 534 regardless of which preemption priorities are used by which LSPs and 535 regardless of failure situations. 537 By also configuring: 538 - every CT2/Voice TE-LSP with preemption =0 539 - every CT1/Premium Data TE-LSP with preemption =1 540 - every CT0/Best-Effort TE-LSP with preemption =2 542 DS-TE with the Russian Dolls Model will also ensure that: 543 - CT2 Voice LSPs always have first preemption priority in order 544 to use the CT2 capacity 545 - CT1 Premium Data LSPs always have second preemption priority 546 in order to use the CT1 capacity 547 - Best-Effort can use up to link capacity whatever is left by 548 CT2 and CT1. 550 Optional automatic adjustment of Diff-Serv scheduling configuration 551 could be used for maintaining very strict relationship between amount 552 of established traffic of each Class Type and corresponding Diff-Serv 553 resources. 555 3. Scenario 3: Guaranteed Bandwidth Services 557 By configuring on every link: 558 - BC1 (for CT1) = "given" percentage of link bandwidth 559 (appropriate to achieve the Guaranteed Bandwidth service's 560 QoS objectives) 561 - BC0 (for CT0+CT1) = 100% of link bandwidth 563 DS-TE with the Russian Dolls Model will ensure that the amount of 564 Guaranteed Bandwidth Traffic established on every link remains below 565 the given percentage so that it will always meet its QoS objectives. 566 At the same time it will allow traffic engineering of the rest of the 567 traffic such that links can be filled up. 569 Disclaimer of Validity 571 This document and the information contained herein are provided on an 572 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 573 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 574 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 575 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 576 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 577 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 579 Russian Dolls Model for DS-TE December 2005 581 Copyright Statement 583 Copyright (C) The Internet Society (2004). This document is subject 584 to the rights, licenses and restrictions contained in BCP 78, and 585 except as set forth therein, the authors retain all their rights. 587 Acknowledgment 589 Funding for the RFC Editor function is currently provided by the 590 Internet Society.