idnits 2.17.1 draft-lefaucheur-diff-te-mam-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 abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 359 -- Looks like a reference, but probably isn't: '1' on line 360 == Unused Reference: 'OSPF-TE' is defined on line 403, but no explicit reference was found in the text == Unused Reference: 'ISIS-TE' is defined on line 406, but no explicit reference was found in the text == Unused Reference: 'RSVP-TE' is defined on line 409, but no explicit reference was found in the text == Unused Reference: 'DIFF-MPLS' is defined on line 412, but no explicit reference was found in the text ** 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-03 == Outdated reference: A later version (-06) exists of draft-wlai-tewg-bcmodel-00 == Outdated reference: A later version (-07) exists of draft-ietf-tewg-diff-te-russian-01 == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-09 == 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 3 Cisco Systems, Inc. 5 IETF Internet Draft 6 Expires: April, 2002 7 Document: draft-lefaucheur-diff-te-mam-00.txt February, 2003 9 Maximum Allocation 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 specification for one Bandwidth Constraints 33 model for Diff-Serv-aware MPLS Traffic Engineering, which is referred 34 to as the Maximum Allocation Model. 36 Summary for Sub-IP related Internet Drafts 38 RELATED DOCUMENTS: 39 draft-ietf-tewg-diff-te-reqts-07.txt 40 draft-ietf-tewg-diff-te-proto-03.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 1 51 Maximum Allocation Model for DS-TE February 2003 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 specifying bandwidth constraints model 59 for Diff-Serv-aware MPLS Traffic Engineering. This document specifies 60 one particular bandwidth constraints model. 62 Specification of Requirements 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in [RFC2119]. 68 1. Introduction 70 [DSTE-REQ] presents the Service Providers requirements for support of 71 Diff-Serv-aware MPLS Traffic Engineering (DS-TE). This includes the 72 fundamental requirement to be able to enforce different bandwidth 73 constraints for different classes of traffic. 75 [DSTE-REQ] also defines the concept of Bandwidth Constraint Models 76 for DS-TE and states that "The DS-TE technical solution MUST specify 77 at least one bandwidth constraint model and MAY specify multiple 78 Bandwidth Constraints models." 80 This document provides a detailed description of one particular 81 Bandwidth Constraint model for DS-TE which is introduced in [DSTE- 82 REQ] and called the Maximum Allocation Model (MAM). 84 [DSTE-PROTO] specifies the IGP and RSVP-TE signaling extensions for 85 support of DS-TE. These extensions support MAM. 87 2. Definitions 89 For readability a number of definitions from [DSTE-REQ] are repeated 90 here: 92 Class-Type (CT): the set of Traffic Trunks crossing a link that is 93 governed by a specific set of Bandwidth Constraints. CT is used for 94 the purposes of link bandwidth allocation, constraint based routing 95 and admission control. A given Traffic Trunk belongs to the same CT 96 on all links. 98 TE-Class: A pair of: 99 i. a Class-Type 101 Le Faucheur et. al 2 103 Maximum Allocation Model for DS-TE February 2003 105 ii. a preemption priority allowed for that Class-Type. This 106 means that an LSP transporting a Traffic Trunk from 107 that Class-Type can use that preemption priority as the 108 set-up priority, as the holding priority or both. 110 "Reserved (CTc)": For a given Class-Type CTc ( 0 <= c <= MaxCT ) ,let 111 us define "Reserved(CTc)" as the sum of the bandwidth reserved by all 112 established LSPs which belong to CTc. 114 The following definition from [DSTE-PROTO] is also repeated here: 116 Normalised(CTc) : let us define "Normalised(CTc)" as 117 "Reserved(CTc)/LOM(c)", where LOM (c) is the Local Overbooking 118 Multiplier for CTc defined in [DSTE-PROTO]. 120 We also introduce the following definitions: 122 Reserved(CTb,q) : let us define "Reserved(CTb,q)" as the sum of the 123 bandwidth reserved by all established LSPs which belong to CTb and 124 have a holding priority of q. Note that if q and CTb do not form one 125 of the 8 possible configured TE-Classes, then there can not be any 126 established LSP which belong to CTb and have a holding priority of q, 127 so in that case Reserved(CTb,q)=0. 129 Normalised(CTc,q) let us define "ormalised(CTc,q)" as 130 "Reserved(CTc/q) / LOM(c)", where LOM (c) is the Local Overbooking 131 Multiplier for CTc defined in [DSTE-PROTO]. 133 3. Maximum Allocation Model Definition 135 MAM is defined in the following manner (assuming for now that the 136 optional per-CT Local Overbooking Multipliers defined in [DSTE-PROTO] 137 are not used - i.e. LOM[c]=1 , 0<=c<=7 ): 138 o Maximum Number of Bandwidth Constraints (MaxBC)= Maximum 139 Number of Class-Types (MaxCT) = 8 140 o for each value of b in the range 0 <= b <= (MaxCT - 1): 141 Reserved (CTb) <= BCb, 143 A DS-TE LSR implementing MAM MUST support enforcement of bandwidth 144 constraints in compliance with this definition. 146 Where 8 Class-Types are active, the MAM bandwidth constraints can 147 also be expressed in the following way: 148 - All LSPs from CT7 use no more than BC7 149 - All LSPs from CT6 use no more than BC6 150 - All LSPs from CT5 use no more than BC5 151 - etc. 152 - All LSPs from CT0 use no more than BC0 154 Purely for illustration purposes, the diagram below represents MAM in 155 a pictorial manner when 3 Class-Types are active: 157 Le Faucheur et. al 3 159 Maximum Allocation Model for DS-TE February 2003 161 I--------------II-------------II-------------I 162 I CT2 II CT1 II CT0 I 163 I--------------II-------------II-------------I 165 <-----BC2------><-----BC1-----><-----BC0-----> 167 While more flexible/sophisticated Bandwidth Constraints models can be 168 defined (and are indeed defined - see [RDM]) , the Maximum Allocation 169 Model is attractive in some DS-TE environments for the following 170 reasons: 171 - Network administrators generally find MAM extremely simple 172 and intuitive 173 - MAM matches simple bandwidth control policies that Network 174 Administrators may want to enforce (i.e. set aside a fixed 175 chunk of bandwidth for a given type of traffic (aka. Class- 176 Type). 177 - MAM can be used in a way which ensures very strict isolation 178 across Class-Types, so that each Class-Type is guaranteed its 179 share of bandwidth no matter the level of contention by other 180 classes, whether preemption is used or not. 181 - MAM can simultaneously achieve isolation, bandwidth 182 efficiency and protection against QoS degradation of the 183 premium CT. 184 - MAM only requires limited protocol extensions such as the 185 ones defined in [DSTE-PROTO]. 187 MAM may not be attractive in some DS-TE environments because: 188 - MAM cannot simultaneously achieve isolation, bandwidth 189 efficiency and protection against QoS degradation of CTs 190 other than the Premium CT. 192 Additional considerations on the properties of MAM can be found in 193 [BC-CONS] and [BC-MODEL]. 195 As a very simple example usage of the MAM Model, a network 196 administrator using one CT for Voice (CT1) and one CT for Data (CT0) 197 might configure on a given 2.5 Gb/s link: 198 - BC0 = 1.5 Gb/s (i.e. Data is limited to 1.5 Gb/s) 199 - BC1 = 1 Gb/s (i.e. Voice is limited to 1 Gb/s). 201 4. Example Formulas for Computing "Unreserved TE-Class [i]" with 202 Maximum Allocation 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. Thus, a DS-TE LSR implementing MAM MUST reflect 208 the MAM bandwidth constraints defined in section 3 above when 209 computing "Unreserved TE-Class [i]". 211 Le Faucheur et. al 4 213 Maximum Allocation Model for DS-TE February 2003 215 Keeping in mind, as explained in [DSTE-PROTO], that details of 216 admission control algorithms as well as formulas for computing 217 "Unreserved TE-Class [i]" are outside the scope of the IETF work, we 218 provide in this section, for illustration purposes, an example of how 219 values for the unreserved bandwidth for TE-Class[i] might be computed 220 with MAM, assuming: 221 - the basic admission control algorithm which simply deducts 222 the exact bandwidth of any established LSP from all of the 223 Bandwidth Constraints relevant to the CT associated with that 224 LSP. 225 - the optional per-CT Local Overbooking Multipliers are not 226 used (.i.e. LOM[c]=1, 0<= c <=7). 228 Then: 230 "Unreserved TE-Class [i]" = 231 [ BCc - SUM ( Reserved(CTc,q) ) ] for q <= p 233 where: 234 TE-Class [i] <--> < CTc , preemption p> 235 in the configured TE-Class mapping. 237 5. Support of Optional Local Overbooking Method 239 We remind the reader that, as discussed in [DSTE-PROTO], the 240 "LSP/link size overbooking" method (which does not use the Local 241 Overbooking Multipliers - LOMs-) is expected to be sufficient in many 242 DS-TE environments. It is expected that the optional Local 243 Overbooking method (and LOMs) would only be used in specific 244 environments, in particular where different overbooking ratios need 245 to be enforced on different links of the DS-TE domain and cross- 246 effect of overbooking across CTs needs to be accounted for very 247 accurately. 249 This section discusses the impact of the optional local overbooking 250 method on MAM and associated rules and formula. This is only 251 applicable in the cases where the optional local overbooking method 252 is indeed supported by the DS-TE LSRs and actually deployed. 254 5.1. Maximum Allocation Model Definition With Local Overbooking 256 As specified in [DSTE-PROTO], when the optional Local Overbooking 257 method is supported, the bandwidth constraints MUST be applied to 258 "Normalised(CTc)" rather than to "Reserved(CTc)". Thus, when the 259 optional Local Overbooking method is supported, the MAM definition is 260 extended in the following manner: 261 - Maximum Number of Bandwidth Constraints (MaxBC)= Maximum 262 Number of Class-Types (MaxCT) = 8 263 - for each value of b in the range 0 <= b <= (MaxCT - 1): 264 Normalised(CTb) <= BCb, 266 Le Faucheur et. al 5 268 Maximum Allocation Model for DS-TE February 2003 270 A DS-TE LSR implementing MAM and implementing the optional Local 271 Overbooking method MUST support enforcement of bandwidth constraints 272 in compliance with this extended definition. 274 Purely for illustration purposes, the diagram below represents the 275 Russian Doll Bandwidth Constraints model in a pictorial manner when 3 276 Class-Types are active and the local overbooking method is used: 278 I-------------------II-------------------II--------------------I 279 I Normalised(CT2) II Normalised(CT1) II Normalised(CT0) I 280 I-------------------II-------------------II--------------------I 282 <--------BC2--------><--------BC1--------><--------BC0---------> 284 5.2. Example Formulas for Computing "Unreserved TE-Class [i]" With 285 Local Overbooking 287 A DS-TE LSR implementing MAM and implementing the optional Local 288 Overbooking method MUST reflect the MAM bandwidth constraints defined 289 in section 5.1 above when computing "Unreserved TE-Class [i]". 291 Again, keeping in mind that details of admission control algorithms 292 as well as formulas for computing "Unreserved TE-Class [i]" are 293 outside the scope of the IETF work, we provide in this section, for 294 illustration purposes, an example of how values for the unreserved 295 bandwidth for TE-Class[i] might be computed with MAM, assuming: 296 - the basic admission control algorithm which simply deducts 297 the exact bandwidth of any established LSP from all of the 298 Bandwidth Constraints relevant to the CT associated with that 299 LSP. 300 - the optional per-CT Local Overbooking Multipliers are used. 302 When the optional local overbooking method is supported, the example 303 generalized formula of section 4 becomes: 305 "Unreserved TE-Class [i]" = 306 LOM(c) x [ BCc - SUM ( Normalised(CTc,q) ) ] for q <= p , 308 Or, equivalently: 310 "Unreserved TE-Class [i]" = 311 [ LOM(c) x BCc ] - SUM ( Reserved (CTc,q) ) for q <= p , 313 where: 314 TE-Class [i] <--> < CTc , preemption p> 315 in the configured TE-Class mapping. 317 5.3. Example Usage of LOM 319 Le Faucheur et. al 6 321 Maximum Allocation Model for DS-TE February 2003 323 To illustrate usage of the local overbooking method with MAM, let's 324 consider a DS-TE deployment where two CTs (CT0 for data and CT1 for 325 voice) and a single preemption priority are used. 327 The TE-Class mapping is the following: 329 TE-Class <--> CT, preemption 330 ============================== 331 0 CT0, 0 332 1 CT1, 0 333 rest unused 335 Let's assume that on a given link, BCs and LOMs are configured in the 336 following way: 337 BC0 = 200 338 BC1 = 100 339 LOM(0) = 4 (i.e. = 400%) 340 LOM(1) = 2 (i.e. = 200%) 342 Let's further assume that the DS-TE LSR uses the example formulas 343 presented above for computing unreserved bandwidth values. 345 If there is no established LSP on the considered link, the LSR will 346 advertise for that link in IGP : 347 Unreserved TE-Class [0] = 4 x (200 - 0/4)= 800 348 Unreserved TE-Class [1] = 2 x (100- 0/2) = 200 349 Note again that these values advertised for Unreserved Bandwidth are 350 larger than BC1 and BC0. 352 If there is only a single established LSP, with CT=CT0 and BW=100, 353 the LSR will advertise: 354 Unreserved TE-Class [0] = 4 x (200 - 100/4)= 700 355 Unreserved TE-Class [1] = 2 x (100- 0/2) = 200 357 If there is only a single established LSP, with CT=CT1 and BW=100, 358 the LSR will advertise: 359 Unreserved TE-Class [0] = 4 x (200 - 0/4) = 800 360 Unreserved TE-Class [1] = 2 x (100- 100/2) = 100 362 6. Security Considerations 364 Security considerations related to the use of DS-TE are discussed in 365 [DSTE-PROTO]. Those apply independently of the Bandwidth Constraints 366 model, including MAM specified in this document. 368 7. Acknowledgments 370 A lot of the material in this document has been derived from ongoing 371 discussions within the TEWG work. This involved many people including 372 Jerry Ash, Waisum Lai and Dimitry Haskin. 374 Le Faucheur et. al 7 376 Maximum Allocation Model for DS-TE February 2003 378 8. Normative References 380 [DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv- 381 aware MPLS Traffic Engineering, draft-ietf-tewg-diff-te-reqts-07.txt, 382 February 2003. 384 [DSTE-PROTO] Le Faucheur et al, Protocol extensions for support of 385 Diff-Serv-aware MPLS Traffic Engineering, draft-ietf-tewg-diff-te- 386 proto-03.txt, February 2003 388 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 389 Requirement Levels, RFC2119, March 1997. 391 9. Informative References 393 [BC-CONS] Le Faucheur, "Considerations on Bandwidth Constraints Model 394 for DS-TE", draft-lefaucheur-tewg-russian-dolls-00.txt, June 2002. 396 [BC-MODEL] Lai, "Bandwidth Constraints Models for DS-TE", 397 draft-wlai-tewg-bcmodel-00.txt, June 2002. 399 [RDM] Le Faucheur et al., "Russian Dolls Bandwidth Constraints Model 400 for Diff-Serv-aware MPLS Traffic Engineering", 401 draft-ietf-tewg-diff-te-russian-01.txt, February 2003 403 [OSPF-TE] Katz et al., Traffic Engineering Extensions to OSPF, 404 draft-katz-yeung-ospf-traffic-09.txt, October 2002. 406 [ISIS-TE] Smit et al., IS-IS extensions for Traffic Engineering, 407 draft-ietf-isis-traffic-04.txt, December 2002. 409 [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 410 Tunnels", RFC 3209, December 2001. 412 [DIFF-MPLS] Le Faucheur et al, "MPLS Support of Diff-Serv", RFC3270, 413 May 2002. 415 10. Author's Address: 417 Francois Le Faucheur 418 Cisco Systems, Inc. 419 Village d'Entreprise Green Side - Batiment T3 420 400, Avenue de Roumanille 421 06410 Biot-Sophia Antipolis 422 France 423 Phone: +33 4 97 23 26 19 424 Email: flefauch@cisco.com 426 Le Faucheur et. al 8