idnits 2.17.1 draft-lefaucheur-tewg-russian-dolls-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 529 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 235 has weird spacing: '... ideal if ba...' -- 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) == Outdated reference: A later version (-07) exists of draft-ietf-tewg-diff-te-reqts-05 ** 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-01 ** Downref: Normative reference to an Informational RFC: RFC 3260 (ref. 'DIFF-NEW') Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Francois Le Faucheur, 3 Cisco Systems, Inc. 5 IETF Internet Draft 6 Expires: December, 2002 7 Document: draft-lefaucheur-tewg-russian-dolls-00.txt June, 2002 9 Considerations on Bandwidth Constraints Models 10 for DS-TE 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 input for the selection of a default Bandwidth 33 Constraints Model for Diff-Serv-aware MPLS Traffic Engineering (DS- 34 TE). 36 It discusses a number of considerations on Bandwidth Constraints 37 Models and how the Maximum Allocation Model and the Russian Dolls 38 Model address these considerations. 40 While this document may not exhaustively cover all possible 41 considerations for selection of a Bandwidth Constraints model, we 42 feel it covers the most important considerations for practical DS-TE 43 deployment. 45 We conclude that the Russian Dolls Bandwidth Constraint Model is a 46 good default Bandwidth Constraint Model for DS-TE. 48 Le Faucheur 1 50 Considerations on BC Models for DS-TE June 2002 52 1. Introduction 54 [DSTE-REQ] presents the Service Providers requirements for support of 55 Diff-Serv-aware MPLS Traffic Engineering (DS-TE). [DSTE-REQ] states 56 that a default Bandwidth Constraints Model must be specified as part 57 of the DS-TE solution. The purpose of such a default model is to 58 ensure that there is at least one common Bandwidth Constraints model 59 implementation across various vendors equipment in order to allow for 60 easier deployment of DS-TE. 62 Note that additional Bandwidth Constraints models may also be 63 specified and supported by DS-TE implementations. 65 2. Terminology 67 Section 3.3 of [DSTE-REQ] describes two examples of Bandwidth 68 Constraints Models. 70 The first example uses a separate, independent Bandwidth Constraint 71 (BC) for each Class-type (CT). We refer to this model as the Maximum 72 Allocation Model or MAM. 74 With MAM, the Bandwidth Constraints are defined in the following 75 manner: 76 All LSPs supporting Traffic Trunks from CTc use no more than BCc 78 For example, when 3 CTs are used with MAM: 79 - sum (CT0) <= BC0 80 - sum (CT1) <= BC1 81 - sum (CT2) <= BC2 83 For illustration purposes, on a link of 100 unit of bandwidth where 84 three CTs are used, the network administrator might then configure 85 BC0=30, BC1= 50, BC2=20 such that: 86 - All LSPs supporting Traffic Trunks from CT0 use no more than 87 30 (e.g. Voice <= 30) 88 - All LSPs supporting Traffic Trunks from CT1 use no more than 89 50 (e.g. Premium Data <= 50) 90 - All LSPs supporting Traffic Trunks from CT2 use no more than 91 20 (e.g. Best Effort <= 20) 93 The second example is the Russian Dolls Model. We refer to it as the 94 RDM. More details can also be found on the RDM in section 9 and 95 Appendix C of [DSTE-PROTO]. 97 With RDM, the Bandwidth Constraints are defined in the following 98 manner: 99 BCb is the constraint that bounds the total bandwidth used by 100 all LSPs supporting Traffic Trunks from all class types CTn, 101 where b <= n < M, M being the number of class-types used in the 102 network. 104 Le Faucheur 2 106 Considerations on BC Models for DS-TE June 2002 108 For example, when 3 CTs are used with RDM (M=3): 109 - sum (CT0+CT1+CT2) <= BC0 110 - sum (CT1+CT2) <= BC1 111 - sum (CT2) <= BC2 113 For illustration purposes, on a link of 100 units of bandwidth where 114 three CTs are used, the network administrator might then configure 115 BC0=100, BC1= 80, BC2=60 such that 116 - All LSPs supporting Traffic Trunks from CT2 use no more than 117 60 (e.g. Voice <= 60) 118 - All LSPs supporting Traffic Trunks from CT1 or CT2 use no 119 more than 80 (e.g. Voice + Premium Data <= 80) 120 - All LSPs supporting Traffic Trunks from CT0 or CT1 or CT2 use 121 no more than 100 (e.g. Voice + Premium Data + Best Effort <= 122 100). 124 3. Considerations 126 3.1. Canonical DS-TE Deployment 128 For easier discussion of the considerations below, we consider an 129 example DS-TE deployment which we refer to as the canonical DS-TE 130 deployment. 132 The canonical DS-TE deployment is characterized by: 133 - 3 Class-Types : 134 o CT2 for real-time PHB Scheduling Class(es) (PSCs; see 135 [DIFF-NEW]) 136 o CT1 for low-loss PSCs 137 o CT0 for other PSCs (e.g. Best Effort) 138 - CT2 needs high preemption priority(ies) to ensure placement 139 of such traffic as close as possible to its shortest path. 140 - CT1 needs medium preemption priority(ies) to ensure CT1 141 traffic is as close as possible to its shortest path, but 142 without forcing some CT2 traffic further away from its own 143 shortest path. 144 - CT0 only needs low preemption priority(ies) as its QoS 145 objectives can be accommodated, if necessary, by paths 146 relatively further away from their shortest path as long as 147 they satisfy the bandwidth/resources constraints. 149 Note that although we always refer to the canonical DS-TE deployment 150 in the discussion below, the discussion also applies to other 151 deployment scenarios. 153 3.2. Canonical Set of DS-TE Objectives 155 The considerations below stem from a set of typical practical 156 objectives sought in DS-TE deployment scenarios. We refer to those as 157 the canonical set of DS-TE objectives. This set includes: 159 Le Faucheur 3 161 Considerations on BC Models for DS-TE June 2002 163 - Diff-Serv QoS enforcement. We wish to use the DS-TE Bandwidth 164 Constraints to ensure the respective QoS performance targets 165 of the various Diff-Serv Behavior Aggregates are always met 166 regardless of the actual demand of LSPs across all CTs. 168 - Avoiding bandwidth wastage. If bandwidth is not used to 169 establish LSPs of a given CT, this bandwidth should be 170 available for use by other CTs, as long as it does not 171 compromise the previous objective. This is also referred to 172 as achieving efficient bandwidth sharing across CTs. Note 173 that we are talking about use of bandwidth in the control 174 plane for Constraint Based Routing and not about use of 175 bandwidth in the data plane. Diff-Serv PHB implementations 176 are responsible for achieving efficient bandwidth sharing in 177 the data plane, e.g. through use of work-conserving 178 scheduling algorithms). 180 - Avoiding starvation of Best-Effort traffic (considering that 181 when preemption is used, Best-Effort LSPs are typically 182 granted low preemption priority). 184 3.3. Avoiding Wastage and QoS Degradation simultaneously 186 MAM can not simultaneously protect against both bandwidth wastage and 187 QoS degradation. With MAM: 189 - EITHER, one configures Bandwidth Constraints so that that SUM 190 (BCi) <= link bandwidth. 191 Then, significant bandwidth wastage can occur because whenever a CT 192 is not using its bandwidth, this bandwidth cannot be used by other 193 CTs. 194 Consider the example where the link has 100 units of bandwidth and 195 BC0=35, BC1=35 and BC2=30. If, Sum (bandwidth of all LSPs of CT2)= 196 10, then LSPs of CT0 are still limited to 35 and LSPs of CT1 to 35, 197 so that 20 units of bandwidth will go wasted. 199 - OR, one configures Bandwidth Constraints so that SUM (BCi) 200 exceeds link bandwidth. 201 Then, constraint-based routing and admission control can not protect 202 against aggregate congestion and associated QoS degradation. 203 Consider the example where a link has 100 units of bandwidth and 204 BC0=70, BC1=70 and BC2=50. Then, the router performing admission 205 control for that link will accept establishment of LSPs whose sum 206 across all classes can reach 190, far exceeding the link capacity. 207 Note that this could result in QoS degradation not just on CT0 LSPs 208 but also on CT1 LSPs (for example if there are 60 units of CT1 LSP 209 established and 50 units of CT2 LSPs, which totals to 110% of link 210 capacity, it is clear that CT1 will experience QoS degradation. 211 (Depending on the scheduler used, CT2 might also experience 212 degradation.) 214 Le Faucheur 4 216 Considerations on BC Models for DS-TE June 2002 218 RDM, by contrast, can simultaneously protect well against bandwidth 219 wastage (i.e. achieve efficient bandwidth sharing across CTs) and 220 protect against QoS degradation. This is because the recursiveness of 221 Bandwidth Constraints always allows a CT to make use of what is left 222 over by the previous CT. For example, whatever is unused by CT2 can 223 be reused by CT1, whatever is unused by CT1 and CT2 will be reused by 224 CT0 since CT0 is only constrained collectively with CT1 and CT2 by 225 BC0. Yet RDM can avoid QoS degradation by separately constraining the 226 amount of real-time traffic as well as the amount of real-time plus 227 low-loss traffic (see also section 3.5 below). We note that RDM does 228 not completely remove the possibility of conceivable bandwidth 229 wastage. However, we also observe that: 230 - it considerably reduces this risk, as compared to MAM, by 231 effectively constraining CTs collectively and thus always 232 giving the opportunity to reuse the unused bandwidth to all 233 CTs with smaller numerical indexes. So even if it does not 234 give such opportunity to all other CTs (which would be the 235 ideal if bandwidth wastage were the only concern) it does 236 provide many opportunities for bandwidth reuse. 237 - the remaining conceivable bandwidth wastage scenarios in RDM 238 may be more or less inevitable anyway to meet QoS objectives 239 of Diff-Serv classes. Therefore these scenarios do not really 240 represent bandwidth wastage due to the BC model itself. For 241 example, a conceivable bandwidth wastage scenario with RDM is 242 when there is little CT0 demand, and a heavy CT1 and CT2 243 demand. Bandwidth may be considered wasted since some CT1/CT2 244 demand will get rejected even if link is not fully used 245 (since CT2+CT1 is limited by BC1 below link capacity). But 246 limiting CT1 and CT2 to less than link capacity collectively, 247 even when there is no CT0 traffic, is probably necessary 248 anyway to ensure the QoS objectives of low-delay and low-loss 249 traffic are met. So such a bandwidth wastage can be seen as 250 largely inevitable since accepting more CT1/CT2 traffic would 251 eventually result in QoS degradation. In fact, such 252 "bandwidth wastage" may be seen as desirable in order to 253 avoid QoS degradation. 255 3.4. Avoiding Starvation of Best-Effort Traffic 257 In typical DS-TE deployment scenario, MAM does not effectively 258 protect low priority traffic (ie CT0) against starvation. 260 With MAM, in order to avoid the bandwidth wastage issue pointed out 261 above, BC1 and BC2 need to be configured as high as possible. Yet to 262 avoid QoS degradation of CT1 and CT2, BC1 and BC2 need to be 263 configured so that BC1+BC2 is below link capacity. So, it is expected 264 that in practise, BC1 and BC2 would be commonly configured so that 265 BC1+BC2 is just slightly below link capacity - say to "capacity minus 266 small-delta". Since, when preemption is used, CT0 traffic is 267 typically granted low preemption priorities (to maximize QoS 268 performance of CT1 and CT2 traffic), whenever CT1 and CT2 traffic are 269 grabbing all their allowed resources, CT0 traffic will be starved out 271 Le Faucheur 5 273 Considerations on BC Models for DS-TE June 2002 275 and left with only "small-delta" units of bandwidth. Increasing the 276 value of "small-delta" to alleviate CT0 starvation could be done, but 277 this would be at the cost of increasing bandwidth wastage. 279 With RDM, low priority traffic (i.e. CT0) may be well protected 280 against starvation, regardless of the preemption priority it uses, by 281 setting BC1 (which constrains CT1 + CT2 traffic) to less than link 282 capacity, thus ensuring that the required capacity is left for CT0. 284 3.5. Diff-Serv QoS Enforcement Objective 286 DS-TE allows enforcement of different Bandwidth Constraints. These 287 multiple Bandwidth Constraints can be useful to pursue multiple 288 different goals. 290 One such goal is the "Diff-Serv QoS enforcement objective" identified 291 above in the set of canonical DS-TE objectives. This objective is to 292 ensure that the respective QoS performance targets for the Diff-Serv 293 PSC(s) belonging to each CT are met. In other words, the Bandwidth 294 Constraints are used to control the distribution of traffic across 295 the various CTs so that the traffic load submitted to the various 296 PHBs/PSCs activated on the links is compatible with their respective 297 targeted QoS performance. In that context, DS-TE can be seen as a 298 form of aggregate admission control for Diff-Serv. 300 Other goals relate more to how resources can be apportioned across 301 different classes in order to address some Service Provider policy. 302 We refer to such goals as "Policy goals". An example of a policy goal 303 would be the desire to limit the amount of traffic that Best Effort 304 traffic may be able to use on a given link to a certain level (even 305 if going beyond that level would not result in degradation of the QoS 306 objectives). 308 We feel that, while addressing policy goals is highly desirable, 309 addressing the Diff-Serv QoS enforcement objective well is of 310 paramount importance, as this is the most fundamental thrust behind 311 DS-TE (ie being Diff-Serv-aware as opposed to being aware of generic 312 policy classes). 314 We feel that RDM is a much more natural match to the Diff-Serv QoS 315 enforcement objective than MAM because: 316 - when there is no CT1 and CT2 traffic, there is typically no 317 need to limit CT0 traffic below "link capacity" in order to 318 meet CT0 traffic QoS objectives. 319 o RDM will not unnecessary limit CT0 traffic when there is 320 no CT1 and CT2 traffic since the only constraint 321 applying to CT0 is that CT0+CT1+CT2 <= BC0. 322 o To avoid unnecessarily limiting CT0 when there is no CT1 323 and CT2 traffic, MAM would have to have its BC0 324 configured to "link capacity". This means that 325 BC0+BC1+BC2 would significantly exceed link capacity 327 Le Faucheur 6 329 Considerations on BC Models for DS-TE June 2002 331 resulting in significant QoS degradation whenever there 332 is CT1 and/or CT2 traffic. 333 - When there is some CT1 and CT2 traffic, it is typically 334 useful to effectively limit CT0 to whatever is left over by 335 CT1 and CT2 from the link capacity, in order to maintain CT0 336 traffic QoS objectives (since the CT1/CT2 PHBs will typically 337 be configured so that they are granted the 338 bandwidth/resources they require for CT1 and CT2 traffic). 339 o RDM naturally limits CT0 to whatever is left by CT1 and 340 CT2 since CT0 is effectively limited by BC0-CT1-CT2. 341 o To limit CT0 to whatever is left over by CT1 and CT2 in 342 all cases, MAM would have to configure BC0 to a value 343 smaller than ("link capacity"-BC1-BC2) which would be 344 very small if not equal to zero, unless significant 345 bandwidth wastage is tolerated. 346 - Similarly, intuition (as well as some experimental 347 observations) suggests that it is efficient to collectively 348 limit CT1 and CT2. This enables CT1 to effectively make full 349 use of whatever bandwidth hasn't been used by CT2 to avoid 350 bandwidth wastage, while protecting CT1 traffic from QoS 351 degradation by constraining CT1 more tightly as the amount of 352 CT2 traffic increases. In simple terms, if there is less 353 real-time (CT2) traffic established on the link, the link can 354 take up more low-loss (CT1) traffic without QoS degradation 355 of the low loss traffic (assuming appropriate configuration 356 of the PHBs on the link or assuming dynamic adjustment of the 357 PHBs). 358 o RDM naturally limits CT1 and CT2 collectively via BC1. 359 o MAM cannot naturally limit CT1 depending on the amount 360 of CT2 traffic. 362 4. Conclusions 364 Considering that: 366 - other Bandwidth Constraints Models can be defined in addition 367 to the default model to address less typical/more complex 368 deployment scenarios 369 - the Russian Dolls Model matches very well the canonical DS-TE 370 objectives in the canonical DS-TE deployment scenario (as 371 well as many other practical deployment scenarios) 373 we recommend selecting the Russian Dolls Model as the default model 374 for DS-TE. 376 5. Security Considerations 378 No new security considerations are raised by this document. Those are 379 the same as the ones mentioned in [DSTE-REQ]. 381 Le Faucheur 7 383 Considerations on BC Models for DS-TE June 2002 385 6. Acknowledgments 387 We thank Bruce Davie for his review and recommendations. 389 References 391 [DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv- 392 aware MPLS Traffic Engineering, draft-ietf-tewg-diff-te-reqts-05.txt, 393 June 2002. 395 [DSTE-PROTO] Le Faucheur et al, Protocol extensions for support of 396 Diff-Serv-aware MPLS Traffic Engineering, draft-ietf-tewg-diff-te- 397 proto-01.txt, June 2002. 399 [DIFF-NEW] Grossman, " New Terminology and Clarifications for 400 Diffserv ", RFC3260, April 2002. 402 Author's Address: 404 Francois Le Faucheur 405 Cisco Systems, Inc. 406 Village d'Entreprise Green Side - Batiment T3 407 400, Avenue de Roumanille 408 06410 Biot-Sophia Antipolis 409 France 410 Phone: +33 4 97 23 26 19 411 Email: flefauch@cisco.com 413 Le Faucheur 8