idnits 2.17.1 draft-ietf-tewg-diff-te-mam-04.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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 583. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 335. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 344. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 350. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 589), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 446. ** Found boilerplate matching RFC 3978, Section 5.5 (on line 583), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 4 text on line 470. ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 11) being 73 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 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.) ** There are 3 instances of too long lines in the document, the longest one being 11 characters in excess of 72. ** 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 7043 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 380 looks like a reference -- Missing reference section? 'DSTE-REQ' on line 476 looks like a reference -- Missing reference section? 'DSTE-PROTO' on line 376 looks like a reference -- Missing reference section? 'GMPLS-RECOV' on line 416 looks like a reference -- Missing reference section? 'MPLS-BACKUP' on line 420 looks like a reference -- Missing reference section? 'DSTE-RDM' on line 396 looks like a reference -- Missing reference section? 'BC-CONS' on line 390 looks like a reference -- Missing reference section? 'BC-MODEL' on line 393 looks like a reference -- Missing reference section? 'IANA-CONS' on line 383 looks like a reference -- Missing reference section? 'OSPF-TE' on line 400 looks like a reference -- Missing reference section? 'ISIS-TE' on line 403 looks like a reference -- Missing reference section? 'RSVP-TE' on line 406 looks like a reference -- Missing reference section? 'DIFF-MPLS' on line 409 looks like a reference -- Missing reference section? 'DSTE-MAR' on line 412 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 5 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 Cisco Systems, Inc. 5 Waisum Lai 6 AT&T Labs 7 draft-ietf-tewg-diff-te-mam-04.txt 8 Expires: June 2005 December 2004 10 Maximum Allocation Bandwidth Constraints Model for 11 Diff-Serv-aware MPLS Traffic Engineering 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on June 13, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). All Rights Reserved. 44 Abstract 46 Maximum Allocation Model for DS-TE December 2004 48 This document provides specification for one Bandwidth Constraints 49 Model for Diff-Serv-aware MPLS Traffic Engineering, which is referred 50 to as the Maximum Allocation Model. 52 Specification of Requirements 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in [RFC2119]. 58 Table of Contents 60 1. Introduction...................................................2 61 2. Definitions....................................................3 62 3. Maximum Allocation Model Definition............................4 63 4. Example Formulas for Computing "Unreserved TE-Class [i]" with 64 Maximum Allocation Model..........................................6 65 5. Security Considerations........................................7 66 6. Acknowledgments................................................7 67 7. Intellectual Property Considerations...........................7 68 8. IANA Considerations............................................8 69 9. Normative References...........................................8 70 10. Informative References........................................9 71 11. Authors' Address:.............................................9 72 12. Full Copyright Statement.....................................10 73 Appendix A - Addressing [DSTE-REQ] Scenarios.....................10 74 Disclaimer of Validity...........................................12 75 Copyright Statement..............................................12 76 Acknowledgment...................................................12 78 1.Introduction 80 [DSTE-REQ] presents the Service Providers requirements for support of 81 Diff-Serv-aware MPLS Traffic Engineering (DS-TE). This includes the 82 fundamental requirement to be able to enforce different Bandwidth 83 Constraints for different classes of traffic. 85 [DSTE-REQ] also defines the concept of Bandwidth Constraints Model 86 for DS-TE and states that "The DS-TE technical solution MUST specify 87 at least one Bandwidth Constraints Model and MAY specify multiple 88 Bandwidth Constraints Models." 90 This document provides a detailed description of one particular 91 Bandwidth Constraints Model for DS-TE which is introduced in [DSTE- 92 REQ] and called the Maximum Allocation Model (MAM). 94 Maximum Allocation Model for DS-TE December 2004 96 [DSTE-PROTO] specifies the IGP and RSVP-TE signaling extensions for 97 support of DS-TE. These extensions support MAM. 99 2.Definitions 101 For readability a number of definitions from [DSTE-REQ] are repeated 102 here: 104 Class-Type (CT): the set of Traffic Trunks crossing a link that is 105 governed by a specific set of Bandwidth Constraints. CT is used for 106 the purposes of link bandwidth allocation, constraint based routing 107 and admission control. A given Traffic Trunk belongs to the same CT 108 on all links. 110 TE-Class: A pair of: 111 i. a Class-Type 112 ii. a preemption priority allowed for that Class-Type. This Formatted: 113 Bullets and 114 means that an LSP transporting a Traffic Trunk from 115 that Class-Type can use that preemption priority as the 116 set-up priority, as the holding priority or both. 118 A number of recovery mechanisms under investigation or specification 119 in the IETF take advantage of the concept of bandwidth sharing across 120 particular sets of LSPs. "Shared Mesh Restoration" in [GMPLS-RECOV] 121 and "Facility-based Computation Model" in [MPLS-BACKUP] are example 122 mechanisms which increase bandwidth efficiency by sharing bandwidth 123 across backup LSPs protecting against independent failures. To ensure 124 that the notion of "Reserved (CTc)" introduced in [DSTE-REQ] is 125 compatible with such a concept of bandwidth sharing across multiple 126 LSPs, the wording of the "Reserved (CTc)" definition provided in 127 [DSTE-REQ] is generalized into the following: 129 Reserved (CTc): For a given Class-Type CTc ( 0 <= c <= MaxCT ) ,let 130 us define "Reserved(CTc)" as the total amount of the bandwidth 131 reserved by all the established LSPs which belong to CTc. 133 With this generalization, the Maximum Allocation Model definition 134 provided in this document is compatible with Shared Mesh Restoration 135 defined in [GMPLS-RECOV], so that DS-TE and Shared Mesh Protection 136 can operate simultaneously, under the assumption that Shared Mesh 137 Restoration operates independently within each DS-TE Class-Type and 138 does not operate across Class-Types (for example back up 139 LSPs protecting Primary LSPs of CTx need to also belong to CTx; 140 Excess Traffic LSPs sharing bandwidth with Backup LSPs of CTx need to 141 also belong to CTx). 143 We also introduce the following definition: 145 Maximum Allocation Model for DS-TE December 2004 147 Reserved(CTb,q) : let us define "Reserved(CTb,q)" as the total amount 148 of the bandwidth reserved by all the established LSPs which belong to 149 CTb and have a holding priority of q. Note that if q and CTb do not 150 form one of the 8 possible configured TE-Classes, then there can not 151 be any established LSP which belong to CTb and have a holding 152 priority of q, so in that case, Reserved(CTb,q)=0. 154 3.Maximum Allocation Model Definition 156 MAM is defined in the following manner: 157 o Maximum Number of Bandwidth Constraints (MaxBC)= 158 Maximum Number of Class-Types (MaxCT) = 8 159 o for each value of c in the range 0 <= c <= (MaxCT - 1): 160 Reserved (CTc) <= BCc <= Max-Reservable-Bandwidth, 161 o SUM (Reserved(CTc)) <= Max-Reservable-Bandwidth 162 where the SUM is across all values of c in the range 163 0 <= c <= (MaxCT - 1) 165 A DS-TE LSR implementing MAM MUST support enforcement of Bandwidth 166 Constraints in compliance with this definition. 168 To increase the degree of bandwidth sharing among the different CTs, 169 the sum of Bandwidth Constraints may exceed the Maximum Reservable 170 Bandwidth, so that the following relationship may hold true: 171 o SUM (BCc) > Max-Reservable-Bandwidth, 172 where the SUM is across all values of c in the range 173 0 <= c <= (MaxCT - 1) 175 The sum of Bandwidth Constraints may also be equal to (or below) the 176 Maximum Reservable Bandwidth. In that case, the Maximum Reservable 177 Bandwidth does not actually constrain CT bandwidth reservations (in 178 other words, the 3rd bullet item of the MAM definition above will 179 never effectively come into play). This is because the 2nd bullet 180 item of the MAM definition above implies that: 181 SUM (reserved(CTc)) <= SUM (BCc) 182 and we assume here that 183 SUM (BCc) <= Maximum Reservable Bandwidth 184 therefore, it will always be true that: 185 SUM (Reserved(CTc)) <= Max-Reservable-Bandwidth. 187 Both preemption within a Class-Type and across Class-Types is 188 allowed. 190 Maximum Allocation Model for DS-TE December 2004 192 Where 8 Class-Types are active, the MAM Bandwidth Constraints can 193 also be expressed in the following way: 194 - All LSPs from CT7 use no more than BC7 195 - All LSPs from CT6 use no more than BC6 196 - All LSPs from CT5 use no more than BC5 197 - etc. 198 - 199 All LSPs from CT0 use no more than BC0 200 - 201 All LSPs from all CTs collectively use no more than the 202 Maximum Reservable Bandwidth 204 Purely for illustration purposes, the diagram below represents MAM in 205 a pictorial manner when 3 Class-Types are active: 207 I----------------------------I 208 <---BC0---> I 209 I---------I I 210 I I I 211 I CT0 I I 212 I I I 213 I---------I I 214 I I 215 I I 216 <-------BC1-------> I 217 I-----------------I I 218 I I I 219 I CT1 I I 220 I I I 221 I-----------------I I 222 I I 223 I I 224 <-----BC2-----> I 225 I-------------I I 226 I I I 227 I CT2 I I 228 I I I 229 I-------------I I 230 I I 231 I CT0+CT1+CT2 I 232 I I 233 I----------------------------I 235 <--Max Reservable Bandwidth--> 237 (Note that, in this illustration, the sum BC0 + BC1 + BC2 exceeds the 238 Max Reservable Bandwidth.) 240 Maximum Allocation Model for DS-TE December 2004 242 While more flexible/sophisticated Bandwidth Constraints Models can be 243 defined (and are indeed defined - see [DSTE-RDM]), the Maximum 244 Allocation Model is attractive in some DS-TE environments for the 245 following reasons: 246 - Network administrators generally find MAM simple and 247 intuitive 248 - MAM matches simple bandwidth control policies that Network 249 Administrators may want to enforce such as setting individual 250 Bandwidth Constraint for a given type of traffic (aka. Class- 251 Type) and simultaneously limit the aggregate of reserved 252 bandwidth across all types of traffic. 253 - MAM can be used in a way which ensures isolation across 254 Class-Types, whether preemption is used or not. 255 - MAM can simultaneously achieve isolation, bandwidth 256 efficiency and protection against QoS degradation of the 257 premium CT. 258 - MAM only requires limited protocol extensions such as the 259 ones defined in [DSTE-PROTO]. 261 MAM may not be attractive in some DS-TE environments because: 262 - MAM cannot simultaneously achieve isolation, bandwidth 263 efficiency and protection against QoS degradation of CTs 264 other than the Premium CT. 266 Additional considerations on the properties of MAM and its comparison 267 with RDM can be found in [BC-CONS] and [BC-MODEL]. 269 As a very simple example usage of the MAM Model, a network 270 administrator using one CT for Voice (CT1) and one CT for Data (CT0) 271 might configure on a given 2.5 Gb/s link: 272 - 273 BC0 = 2 Gb/s (i.e. Data is limited to 2 Gb/s) 274 - 275 BC1 = 1 Gb/s (i.e. Voice is limited to 1 Gb/s) 276 - 277 Maximum Reservable Bandwidth = 2.5 Gb/s (i.e. aggregate Data 278 + Voice is limited to 2.5 Gb/s) 280 4.Example Formulas for Computing "Unreserved TE-Class [i]" with Maximum 281 Allocation Model 283 As specified in [DSTE-PROTO], formulas for computing "Unreserved TE- 284 Class [i]" MUST reflect all of the Bandwidth Constraints relevant to 285 the CT associated with TE-Class[i], and thus, depend on the Bandwidth 286 Constraints Model. Thus, a DS-TE LSR implementing MAM MUST reflect 287 the MAM Bandwidth Constraints defined in section 3 above when 288 computing "Unreserved TE-Class [i]". 290 Maximum Allocation Model for DS-TE December 2004 292 Keeping in mind, as explained in [DSTE-PROTO], that details of 293 admission control algorithms as well as formulas for computing 294 "Unreserved TE-Class [i]" are outside the scope of the IETF work, we 295 provide in this section, for illustration purposes, an example of how 296 values for the unreserved bandwidth for TE-Class[i] might be computed 297 with MAM, assuming the basic admission control algorithm which simply 298 deducts the exact bandwidth of any established LSP from all of the 299 Bandwidth Constraints relevant to the CT associated with that LSP. 301 Then: 303 "Unreserved TE-Class [i]" = 305 MIN [ 306 [ BCc - SUM ( Reserved(CTc,q) ) ] for q <= p , 307 [ Max-Res-Bw - SUM (Reserved(CTb,q)) ] for q <= p and 0 <= b <= 7, 308 ] 310 where: 311 TE-Class [i] <--> < CTc , preemption p> 312 in the configured TE-Class mapping. 314 5.Security Considerations 316 Security considerations related to the use of DS-TE are discussed in 317 [DSTE-PROTO]. Those apply independently of the Bandwidth Constraints 318 Model, including MAM specified in this document. 320 6.Acknowledgments 322 A lot of the material in this document has been derived from ongoing 323 discussions within the TEWG work. This involved many people including 324 Jerry Ash and Dimitry Haskin. 326 7. Intellectual Property Considerations 328 The IETF takes no position regarding the validity or scope of any 329 Intellectual Property Rights or other rights that might be claimed to 330 pertain to the implementation or use of the technology described in 331 this document or the extent to which any license under such rights 332 might or might not be available; nor does it represent that it has 333 made any independent effort to identify any such rights. Information 334 on the procedures with respect to rights in RFC documents can be 335 found in BCP 78 and BCP 79. 337 Maximum Allocation Model for DS-TE December 2004 339 Copies of IPR disclosures made to the IETF Secretariat and any 340 assurances of licenses to be made available, or the result of an 341 attempt made to obtain a general license or permission for the use of 342 such proprietary rights by implementers or users of this 343 specification can be obtained from the IETF on-line IPR repository at 344 http://www.ietf.org/ipr. 346 The IETF invites any interested party to bring to its attention any 347 copyrights, patents or patent applications, or other proprietary 348 rights that may cover technology that may be required to implement 349 this standard. Please address the information to the IETF at 350 ietf-ipr@ietf.org. 352 8.IANA Considerations 354 [DSTE-PROTO] defines a new name space for "Bandwidth Constraints 355 Model Id". The guidelines for allocation of values in that name space 356 are detailed in section 14.1 of [DSTE-PROTO]. In accordance with 357 these guidelines, IANA was requested to assign a Bandwidth 358 Constraints Model Id for MAM from the range 0-127 (which is to be 359 managed as per the "Specification Required" policy defined in [IANA- 360 CONS]). 362 Bandwidth Constraints Model Id = TBD was allocated by IANA to MAM. 364 To be removed by the RFC editor at the time of 365 publication 366 We request IANA to assign value 1 for the MAM model. 367 Once the value has been assigned, please replace "TBD" above 368 by the assigned value. 369 371 9.Normative References 373 [DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv- 374 aware MPLS Traffic Engineering, RFC3564. 376 [DSTE-PROTO] Le Faucheur et al, Protocol extensions for support of 377 Diff-Serv-aware MPLS Traffic Engineering, draft-ietf-tewg-diff-te- 378 proto-08.txt, work in progress. 380 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 381 Requirement Levels, RFC2119 383 [IANA-CONS], T. Narten et al, "Guidelines for Writing an IANA 384 Considerations Section in RFCs", RFC2434. 386 Maximum Allocation Model for DS-TE December 2004 388 10.Informative References 390 [BC-CONS] Le Faucheur, "Considerations on Bandwidth Constraints Model 391 for DS-TE", draft-lefaucheur-tewg-russian-dolls-00.txt, June 2002. 393 [BC-MODEL] Lai, "Bandwidth Constraints Models for DS-TE", 394 draft-wlai-tewg-bcmodel-03.txt, work in progress. 396 [DSTE-RDM] Le Faucheur et al., "Russian Dolls Bandwidth Constraints 397 Model for Diff-Serv-aware MPLS Traffic Engineering", 398 draft-ietf-tewg-diff-te-russian-07.txt, work in progress. 400 [OSPF-TE] Katz et al., "Traffic Engineering (TE) Extensions to OSPF 401 Version 2", RFC3630. 403 [ISIS-TE] Smit et al., "Intermediate System to Intermediate System 404 (IS-IS) extensions for Traffic Engineering (TE)", RFC 3784. 406 [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 407 Tunnels", RFC 3209. 409 [DIFF-MPLS] Le Faucheur et al, "MPLS Support of Diff-Serv", RFC3270, 410 May 2002. 412 [DSTE-MAR] Ash, G., "Max Allocation with Reservation Bandwidth 413 Constraints Model for MPLS/DiffServ TE & Performance Comparisons", 414 Work In Progress. 416 [GMPLS-RECOV] Lang et al, "Generalized MPLS Recovery Functional 417 Specification", draft-ietf-ccamp-gmpls-recovery-functional-02.txt, 418 work in progress. 420 [MPLS-BACKUP] Vasseur et al, "MPLS Traffic Engineering Fast reroute: 421 bypass tunnel path computation for bandwidth protection", draft- 422 vasseur-mpls-backup-computation-02.txt, work in progress. 424 11.Authors' Address: 426 Francois Le Faucheur 427 Cisco Systems, Inc. 428 Village d'Entreprise Green Side - Batiment T3 429 400, Avenue de Roumanille 430 06410 Biot-Sophia Antipolis 431 France 432 Phone: +33 4 97 23 26 19 433 Email: flefauch@cisco.com Field Code 435 Maximum Allocation Model for DS-TE December 2004 437 Wai Sum Lai 438 AT&T Labs 439 200 Laurel Avenue 440 Middletown, New Jersey 07748, USA 441 Phone: (732) 420-3712 442 Email: wlai@att.com 444 12.Full Copyright Statement 446 Copyright (C) The Internet Society (2004). All Rights Reserved. 448 This document and translations of it may be copied and furnished to 449 others, and derivative works that comment on or otherwise explain it 450 or assist in its implementation may be prepared, copied, published 451 and distributed, in whole or in part, without restriction of any 452 kind, provided that the above copyright notice and this paragraph are 453 included on all such copies and derivative works. However, this 454 document itself may not be modified in any way, such as by removing 455 the copyright notice or references to the Internet Society or other 456 Internet organizations, except as needed for the purpose of 457 developing Internet standards in which case the procedures for 458 copyrights defined in the Internet Standards process must be 459 followed, or as required to translate it into languages other than 460 English. 462 The limited permissions granted above are perpetual and will not be 463 revoked by the Internet Society or its successors or assigns. 465 This document and the information contained herein is provided on an 466 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 467 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 468 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 469 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 470 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 472 Appendix A - Addressing [DSTE-REQ] Scenarios 474 This Appendix provides examples of how the Maximum Allocation 475 Bandwidth Constraints Model can be used to support each of the 476 scenarios described in [DSTE-REQ]. 478 1. Scenario 1: Limiting Amount of Voice 480 By configuring on every link: 481 - 482 Bandwidth Constraint 1 (for CT1=Voice) = "certain percentage" 483 of link capacity 485 Maximum Allocation Model for DS-TE December 2004 487 - 488 Bandwidth Constraint 0 (for CT0=Data) = link capacity (or a 489 constraint specific to data traffic) 490 - 491 Max Reservable Bandwidth = link capacity 493 By configuring: 494 - 495 every CT1/Voice TE-LSP with preemption =0 496 - 497 every CT0/Data TE-LSP with preemption =1 499 DS-TE with the Maximum Allocation Model will address all the 500 requirements: 501 - 502 amount of Voice traffic limited to desired percentage on 503 every link 504 - 505 data traffic capable of using all remaining link capacity (or 506 up to its own specific constraint) 507 - 508 voice traffic capable of preempting other traffic 510 2. Scenario 2: Maintain Relative Proportion of Traffic Classes 512 By configuring on every link: 513 - 514 BC2 (for CT2) = e.g. 45% of link capacity 515 - 516 BC1 (for CT1) = e.g. 35% of link capacity 517 - 518 BC0 (for CT0) = e.g.100% of link capacity 519 - 520 Max Reservable Bandwidth = link capacity 522 DS-TE with the Maximum Allocation Model will ensure that the amount 523 of traffic of each Class Type established on a link is within 524 acceptable levels as compared to the resources allocated to the 525 corresponding Diff-Serv PHBs regardless of which order the LSPs are 526 routed in, regardless of which preemption priorities are used by 527 which LSPs and regardless of failure situations. 529 By also configuring: 530 - 531 every CT2/Voice TE-LSP with preemption =0 532 - 533 every CT1/Premium Data TE-LSP with preemption =1 534 - 535 every CT0/Best-Effort TE-LSP with preemption =2 537 DS-TE with the Maximum Allocation Model will also ensure that: 538 - 539 CT2 Voice LSPs always have first preemption priority in order 540 to use the CT2 capacity 541 - 542 CT1 Premium Data LSPs always have second preemption priority 543 in order to use the CT1 capacity 544 - 545 Best-Effort can use up to link capacity whatever is left by 546 CT2 and CT1. 548 Optional automatic adjustment of Diff-Serv scheduling configuration 549 could be used for maintaining very strict relationship between amount 550 of established traffic of each Class Type and corresponding Diff-Serv 551 resources. 553 Maximum Allocation Model for DS-TE December 2004 555 3. Scenario 3: Guaranteed Bandwidth Services 557 By configuring on every link: 558 - 559 BC1 (for CT1) = "given" percentage of link bandwidth 560 (appropriate to achieve the QoS objectives of the Guaranteed 561 Bandwidth service) 562 - 563 BC0 (for CT0=Data) = link capacity (or a constraint specific 564 to data traffic) 565 - 566 Max Reservable Bandwidth = link capacity 568 DS-TE with the Maximum Allocation Model will ensure that the amount 569 of Guaranteed Bandwidth Traffic established on every link remains 570 below the given percentage so that it will always meet its QoS 571 objectives. At the same time it will allow traffic engineering of the 572 rest of the traffic such that links can be filled up (or limited to 573 the specific constraint for such traffic). 575 Disclaimer of Validity 577 This document and the information contained herein are provided on an 578 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 579 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 580 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 581 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 582 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 583 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 585 Copyright Statement 587 Copyright (C) The Internet Society (2004). This document is subject 588 to the rights, licenses and restrictions contained in BCP 78, and 589 except as set forth therein, the authors retain all their rights. 591 Acknowledgment 593 Funding for the RFC Editor function is currently provided by the 594 Internet Society.