idnits 2.17.1 draft-ietf-tewg-diff-te-mar-04.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 7) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 11 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 36 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 956 has weird spacing: '...cedures for...' -- 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: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 69, but not defined == Unused Reference: 'KEY' is defined on line 451, but no explicit reference was found in the text == Unused Reference: 'ASH2' is defined on line 462, but no explicit reference was found in the text == Unused Reference: 'ASH3' is defined on line 464, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 500, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (ref. 'IANA-CONS') (Obsoleted by RFC 5226) Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Jerry Ash 2 Internet Draft AT&T 3 Category: Experimental 4 5 Expiration Date: July 2004 6 January, 2004 8 Max Allocation with Reservation Bandwidth Constraints Model for 9 DiffServ-aware MPLS Traffic Engineering & Performance Comparisons 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC 2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document complements the DiffServ-aware MPLS TE (DS-TE) requirements 36 document by giving a functional specification for the Maximum Allocation 37 with Reservation (MAR) Bandwidth Constraints Model. Assumptions, 38 applicability, and examples of the operation of the MAR Bandwidth 39 Constraints Model are presented. MAR performance is analyzed relative to 40 the criteria for selecting a Bandwidth Constraints Model, in order to 41 provide guidance to user implementation of the model in their networks. 43 Internet Draft MAR Bandwidth Constraints Model for DS-TE Jan 04 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 3. Assumptions & Applicability . . . . . . . . . . . . . . . . . 5 50 4. Functional Specification of the MAR Bandwidth Constraints Model 6 51 5. Setting Bandwidth Constraints . . . . . . . . . . . . . . . . 7 52 6. Example of MAR Operation . . . . . . . . . . . . . . . . . . . 7 53 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 54 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 55 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 56 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 57 11. Normative References . . . . . . . . . . . . . . . . . . . . 9 58 12. Informative References . . . . . . . . . . . . . . . . . . . 9 59 13. Intellectual Property Statement . . . . . . . . . . . . . . . 10 60 14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11 61 Appendix A. MAR Operation & Performance Analysis . . . . . . . . 11 62 Appendix B. Bandwidth Prediction for Path Computation . . . . . . 17 64 Specification of Requirements 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in [RFC2119]. 70 Internet Draft MAR Bandwidth Constraints Model for DS-TE Jan 04 72 1. Introduction 74 DiffServ-aware MPLS traffic engineering (DS-TE) requirements and protocol 75 extensions are specified in [DSTE-REQ, DSTE-PROTO]. A requirement for 76 DS-TE implementation is the specification of Bandwidth Constraints Models 77 for use with DS-TE. The Bandwidth Constraints Model provides the 'rules' 78 to support the allocation of bandwidth to individual class types (CTs). 79 CTs are groupings of service classes in the DS-TE model, which are 80 provided separate bandwidth allocations, priorities, and QoS objectives. 81 Several CTs can share a common bandwidth pool on an integrated, 82 multiservice MPLS/DiffServ network. 84 This document is intended to complement the DS-TE requirements document 85 [DSTE-REQ] by giving a functional specification for the Maximum 86 Allocation with Reservation (MAR) Bandwidth Constraints Model. Examples 87 of the operation of the MAR Bandwidth Constraints Model are presented. 88 MAR performance is analyzed relative to the criteria for selecting a 89 Bandwidth Constraints Model, in order to provide guidance to user 90 implementation of the model in their networks. 92 Two other Bandwidth Constraints Models are being specified for use in 93 DS-TE: 95 1. Maximum Allocation Model (MAM) [MAM] - the maximum allowable 96 bandwidth usage of each CT is explicitly specified. 97 2. Russian Doll Model (RDM) [RDM] - the maximum allowable bandwidth 98 usage is done cumulatively by grouping successive CTs according to 99 priority classes. 101 MAR is similar to MAM in that a maximum bandwidth allocation is given to 102 each CT. However, through the use of bandwidth reservation and 103 protection mechanisms, CTs are allowed to exceed their bandwidth 104 allocations under conditions of no congestion but revert to their 105 allocated bandwidths when overload and congestion occurs. 107 All Bandwidth Constraints Models should meet these objectives: 109 1. applies equally when preemption is either enabled or disabled (when 110 preemption is disabled, the model still works 'reasonably' well), 111 2. bandwidth efficiency, i.e., good bandwidth sharing among CTs under 112 both normal and overload conditions, 113 3. bandwidth isolation, i.e., a CT cannot hog the bandwidth of another 114 CT under overload conditions, 115 4. protection against QoS degradation, at least of the high-priority CTs 116 (e.g. high-priority voice, high-priority data, etc.), and 117 5. reasonably simple, i.e., does not require additional IGP extensions 118 and minimizes signaling load processing requirements. 120 In Appendix A modeling analysis is presented which shows that the MAR 121 Model meets all these objectives, and provides good network performance 122 relative to MAM and full sharing models, under normal and abnormal 123 operating conditions. It is demonstrated that simultaneously achieves 124 bandwidth efficiency, bandwidth isolation, and protection against QoS 125 degradation without preemption. 127 Internet Draft MAR Bandwidth Constraints Model for DS-TE Jan 04 129 In Section 3 we give the assumptions and applicability, in Section 4 a 130 functional specification of the MAR Bandwidth Constraints Model, and in 131 Section 5 we give examples of its operation. In Appendix A, MAR 132 performance is analyzed relative to the criteria for selecting a 133 Bandwidth Constraints Model, in order to provide guidance to user 134 implementation of the model in their networks. In Appendix B, 135 bandwidth prediction for path computation is discussed. 137 2. Definitions 139 For readability a number of definitions from [DSTE-REQ, DSTE-PROTO] are 140 repeated here: 142 Traffic Trunk: an aggregation of traffic flows of the same class (i.e. 143 which are to be treated equivalently from the DS-TE perspective) which 144 are placed inside an LSP. 146 Class-Type (CT): the set of Traffic Trunks crossing a link that is 147 governed by a specific set of Bandwidth constraints. CT is used for the 148 purposes of link bandwidth allocation, constraint based routing and 149 admission control. A given Traffic Trunk belongs to the same CT on all 150 links. 152 Up to 8 CTs (MaxCT = 8) are supported. They are referred to as CTc, 0 153 <= c <= MaxCT-1 = 7. Each CT is assigned either a Bandwidth 154 Constraint, or a set of Bandwidth Constraints. Up to 8 Bandwidth 155 Constraints (MaxBC = 8) are supported and they are referred to as BCc, 156 0 <= c <= MaxBC-1 = 7. 158 TE-Class: A pair of: i. a CT ii. a preemption priority allowed for that 159 CT. This means that an LSP transporting a Traffic Trunk from that CT can 160 use that preemption priority as the set-up priority, as the holding 161 priority or both. 163 MAX_RESERVABLE_BWk: maximum reservable bandwidth on link k specifies the 164 maximum bandwidth that may be reserved; this may be greater than the 165 maximum link bandwidth in which case the link may be oversubscribed 166 [OSPF-TE]. 168 BCck: bandwidth constraint for CTc on link k = allocated (minimum 169 guaranteed) bandwidth for CTc on link k (see Section 4). 171 RBW_THRESk: reservation bandwidth threshold for link k (see Section 4). 173 RESERVED_BWck: reserved bandwidth-in-progress on CTc on link k (0 <= c 174 <= MaxCT-1), RESERVED_BWck = total amount of the bandwidth reserved 175 by all the established LSPs which belong to CTc. 177 UNRESERVED_BWk: unreserved link bandwidth on link k specifies the 178 amount of bandwidth not yet reserved for any CT, UNRESERVED_BWk = 179 MAX_RESERVABLE_BWk - sum [RESERVED_BWck (0 <= c <= MaxCT-1)]. 181 Internet Draft MAR Bandwidth Constraints Model for DS-TE Jan 04 183 UNRESERVED_BWck: unreserved link bandwidth on CTc on link k specifies 184 the amount of bandwidth not yet reserved for CTc, UNRESERVED_BWck = 185 UNRESERVED_BWk - delta0/1(CTck) * RBW-THRESk 186 where 187 delta0/1(CTck) = 0 if RESERVED_BWck < BCck 188 delta0/1(CTck) = 1 if RESERVED_BWck >= BCck 190 A number of recovery mechanisms under investigation in the IETF take 191 advantage of the concept of bandwidth sharing across particular sets of 192 LSPs. "Shared Mesh Restoration" in [GMPLS-RECOV] and "Facility-based 193 Computation Model" in [MPLS-BACKUP] are example mechanisms which 194 increase bandwidth efficiency by sharing bandwidth across backup LSPs 195 protecting against independent failures. To ensure that the notion of 196 RESERVED_BWck introduced in [DSTE-REQ] is compatible with such a concept 197 of bandwidth sharing across multiple LSPs, the wording of the definition 198 provided in [DSTE-REQ] is generalized. With this generalization, the 199 definition is compatible with Shared Mesh Restoration defined in 200 [GMPLS-RECOV], so that DS-TE and Shared Mesh Protection can operate 201 simultaneously, under the assumption that Shared Mesh Restoration 202 operates independently within each DS-TE Class-Type and does not operate 203 across Class-Types. For example, backup LSPs protecting primary LSPs of 204 CTc must also belong to CTc; excess traffic LSPs sharing bandwidth with 205 backup LSPs of CTc must also belong to CTc. 207 3. Assumptions & Applicability 209 In general, DS-TE is a bandwidth allocation mechanism, for different 210 classes of traffic allocated to various CTs (e.g., voice, normal data, 211 best-effort data). Network operations functions such as capacity 212 design, bandwidth allocation, routing design, and network planning are 213 normally based on traffic measured load and forecast [ASH1]. 215 As such, the following assumptions are made according to the operation 216 of MAR: 218 1. connection admission control (CAC) allocates bandwidth for network 219 flows/LSPs according to the traffic load assigned to each CT, based on 220 traffic measurement and forecast. 221 2. CAC could allocate bandwidth per flow, per LSP, per traffic trunk, or 222 otherwise. That is, no specific assumption is made on a specific CAC 223 method, only that CT bandwidth allocation is related to the 224 measured/forecast traffic load, as per assumption #1. 225 3. CT bandwidth allocation is adjusted up or down according to 226 measured/forecast traffic load. No specific time period is assumed for 227 this adjustment, it could be short term (hours), daily, weekly, monthly, 228 or otherwise. 229 4. Capacity management and CT bandwidth allocation thresholds (e.g., 230 BCc) are designed according to traffic load, and are based on traffic 231 measurement and forecast. Again, no specific time period is assumed for 232 this adjustment, it could be short term (hours), daily, weekly, monthly, 233 or otherwise. 234 5. No assumption is made on the order in which traffic is allocated to 235 various CTs, again traffic allocation is assumed to be based only on 236 traffic load as it is measured and/or forecast. 238 Internet Draft MAR Bandwidth Constraints Model for DS-TE Jan 04 240 6. If link bandwidth is exhausted on a given path for a flow/LSP/traffic 241 trunk, alternate paths may be attempted to satisfy CT bandwidth 242 allocation. 244 Note that the above assumptions are not unique to MAR, but are generic, 245 common assumptions for all BC Models. 247 4. Functional Specification of the MAR Bandwidth Constraints Model 249 A DS-TE LSR implementing MAR MUST support enforcement of bandwidth 250 constraints in compliance with the specifications in this Section. 252 In the MAR Bandwidth Constraints Model, the bandwidth allocation control 253 for each CT is based on estimated bandwidth needs, bandwidth use, and 254 status of links. The LER makes needed bandwidth allocation changes, and 255 uses [RSVP-TE], for example, to determine if link bandwidth can be 256 allocated to a CT. Bandwidth allocated to individual CTs is protected as 257 needed but otherwise shared. Under normal non-congested network 258 conditions, all CTs/services fully share all available bandwidth. When 259 congestion occurs for a particular CTc, bandwidth reservation acts to 260 prohibit traffic from other CTs from seizing the allocated capacity for 261 CTc. 263 On a given link k, a small amount of bandwidth RBW_THRESk, the 264 reservation bandwidth threshold for link k, is reserved and governs the 265 admission control on link k. Also associated with each CTc on link k 266 are the allocated bandwidth constraints BCck to govern bandwidth 267 allocation and protection. The reservation bandwidth on a link, 268 RBW_THRESk, can be accessed when a given CTc has bandwidth-in-use 269 RESERVED_BWck below its allocated bandwidth constraint BCck. However, 270 if RESERVED_BWck exceeds its allocated bandwidth constraint BCck, then 271 the reservation bandwidth RBW_THRESk cannot be accessed. In this way, 272 bandwidth can be fully shared among CTs if available, but is otherwise 273 protected by bandwidth reservation methods. 275 Bandwidth can be accessed for a bandwidth request = DBW for CTc on a 276 given link k based on the following rules: 278 Table 1: Rules for Admitting LSP Bandwidth Request = DBW on Link k 280 For LSP on a high priority or normal priority CTc: 281 If RESERVED_BWck <= BCc: admit if DBW <= UNRESERVED_BWk 282 If RESERVED_BWck > BCc: admit if DBW <= UNRESERVED_BWk - RBW_THRESk; 283 or, equivalently: 284 If DBW <= UNRESERVED_BWck, admit the LSP. 286 For LSP on a best-effort priority CTc: 287 allocated bandwidth BCc = 0; 288 DiffServ queuing admits BE packets only if there is available link 289 bandwidth. 291 The normal semantics of setup and holding priority are applied in the 292 MAR Bandwidth Constraints Model, and cross-CT preemption is permitted 293 when preemption is enabled. 295 Internet Draft MAR Bandwidth Constraints Model for DS-TE Jan 04 297 The bandwidth allocation rules defined in Table 1 are illustrated with 298 an example in Section 6 and simulation analysis in Appendix A. 300 5. Setting Bandwidth Constraints 302 For a normal priority CTc, the bandwidth constraints BCck on link k are 303 set by allocating the maximum reservable bandwidth (MAX_RESERVABLE_BWk) 304 in proportion to the forecast or measured traffic load bandwidth 305 TRAF_LOAD_BWck for CTc on link k. That is: 307 PROPORTIONAL_BWck = TRAF_LOAD_BWck/[sum {TRAF_LOAD_BWck, c=0,MaxCT-1}] X 308 MAX_RESERVABLE_BWk 310 For normal priority CTc: 311 BCck = PROPORTIONAL_BWck 313 For a high priority CT, the bandwidth constraint BCck is set to a 314 multiple of the proportional bandwidth. That is: 316 For high priority CTc: 317 BCck = FACTOR X PROPORTIONAL_BWck 319 where FACTOR is set to a multiple of the proportional bandwidth (e.g., 320 FACTOR = 2 or 3 is typical). This results in some 'over-allocation' 321 of the maximum reservable bandwidth, and gives priority to the high 322 priority CTs. Normally the bandwidth allocated to high priority CTs 323 should be a relatively small fraction of the total link bandwidth, a 324 maximum of 10-15 percent being a reasonable guideline. 326 As stated in Section 4, the bandwidth allocated to a best-effort 327 priority CTc should be set to zero. That is: 329 For best-effort priority CTc: 330 BCck = 0 332 6. Example of MAR Operation 334 In the example, assume there are three class-types: CT0, CT1, CT2. We 335 consider a particular link with 337 MAX-RESERVABLE_BW = 100 339 And with the allocated bandwidth constraints set as follows: 341 BC0 = 30 342 BC1 = 20 343 BC2 = 20 345 These bandwidth constraints are based on the normal traffic loads, as 346 discussed in Section 5. With MAR, any of the CTs is allowed to exceed 347 its bandwidth constraint BCc as long a there is at least RBW_THRES 348 (reservation bandwidth threshold on the link) units of spare bandwidth 349 remaining. Let's assume 351 RBW_THRES = 10 352 Internet Draft MAR Bandwidth Constraints Model for DS-TE Jan 04 354 So under overload, if 356 RESERVED_BW0 = 50 357 RESERVED_BW1 = 30 358 RESERVED_BW2 = 10 360 Therefore, for this loading 362 UNRESERVED_BW = 100 - 50 - 30 - 10 = 10 364 CT0 and CT1 can no longer increase their bandwidth on the link, since 365 they are above their BC values and there is only RBW_THRES=10 units of 366 spare bandwidth left on the link. But CT2 can take the additional 367 bandwidth (up to 10 units) if the demand arrives, since it is below its 368 BC value. 370 As also discussed in Section 4, if best effort traffic is present, it 371 can always seize whatever spare bandwidth is available on the link at 372 the moment, but is subject to being lost at the queues in favor of the 373 higher priority traffic. 375 Let's say an LSP arrives for CT0 needing 5 units of bandwidth (i.e., DBW 376 = 5). We need to decide based on Table 1 whether to admit this LSP or 377 not. Since for CT0 379 RESERVED_BW0 > BC0 (50 > 30), and 380 DBW > UNRESERVED_BW - RBW_THRES (i.e., 5 > 10 - 10) 382 Table 1 says the LSP is rejected/blocked. 384 Now let's say an LSP arrives for CT2 needing 5 units of bandwidth (i.e., 385 DBW = 5). We need to decide based on Table 1 whether to admit this 386 LSP or not. Since for CT2 388 RESERVED_BW2 < BC2 (10 < 20), and 389 DBW < UNRESERVED_BW (i.e., 5 < 10) 391 Table 1 says to admit the LSP. 393 Hence, in the above example, in the current state of the link and the 394 current CT loading, CT0 and CT1 can no longer increase their bandwidth 395 on the link, since they are above their BCc values and there is only 396 RBW_THRES=10 units of spare bandwidth left on the link. But CT2 can 397 take the additional bandwidth (up to 10 units) if the demand arrives, 398 since it is below its BCc value. 400 7. Summary 402 The proposed MAR Bandwidth Constraints Model includes the following: a) 403 allocate bandwidth to individual CTs, b) protect allocated bandwidth by 404 bandwidth reservation methods, as needed, but otherwise fully share 405 bandwidth, c) differentiate high-priority, normal-priority, and 406 best-effort priority services, and d) provide admission control to 407 reject connection requests when needed to meet performance objectives. 408 Modeling results presented in Appendix A show that MAR bandwidth 409 allocation a) achieves greater efficiency in bandwidth sharing while 410 Internet Draft MAR Bandwidth Constraints Model for DS-TE Jan 04 412 still providing bandwidth isolation and protection against QoS 413 degradation, and b) achieves service differentiation for high-priority, 414 normal-priority, and best-effort priority services. 416 8. Security Considerations 418 Security considerations related to the use of DS-TE are discussed in 419 [DSTE-PROTO]. Those apply independently of the Bandwidth Constraints 420 Model, including MAR specified in this document. 422 9. Acknowledgements 424 DS-TE and Bandwidth Constraints Models have been an active area of 425 discussion in the TEWG. I would like to thank Wai Sum Lai for his 426 support and review of this draft. I also appreciate helpful discussions 427 with Francois Le Faucheur. 429 10. IANA Considerations 431 [DSTE-PROTO] defines a new name space for "Bandwidth Constraints Model 432 Id". The guidelines for allocation of values in that name space are 433 detailed in Section 14 of [DSTE-PROTO]. In accordance with these 434 guidelines, IANA was requested to assign a Bandwidth Constraints Model 435 Id for MAR from the range 0-127 (which is to be managed as per the 436 "Specification Required" policy defined in [IANA-CONS]). 438 Bandwidth Constraints Model Id = TBD was allocated by IANA to MAR. 440 To be removed by the RFC editor at the time of publication 441 We request IANA to assign value 2 for the MAR model. Once the value 442 has been assigned, please replace "TBD" above by the assigned value. 443 445 11. Normative References 447 [DSTE-REQ] Le Faucheur, F., Lai, W., et. al., "Requirements for Support 448 of Diff-Serv-aware MPLS Traffic Engineering," RFC 3564, July 2003. 449 [DSTE-PROTO] Le Faucheur, F., et. al., "Protocol Extensions for Support 450 of Diff-Serv-aware MPLS Traffic Engineering," work in progress. 451 [KEY] Bradner, S., "Key words for Use in RFCs to Indicate Requirement 452 Levels", RFC 2119, March 1997. 453 [IANA-CONS] Narten, T., "Guidelines for Writing an IANA Considerations 454 Section in RFCs," RFC 2434, October 1998. 456 12. Informative References 458 [AKI] Akinpelu, J. M., "The Overload Performance of Engineered Networks 459 with Nonhierarchical & Hierarchical Routing," BSTJ, Vol. 63, 1984. 460 [ASH1] Ash, G. R., "Dynamic Routing in Telecommunications Networks," 461 McGraw-Hill, 1998. 462 [ASH2] Ash, G. R., et. al., "Routing Evolution in Multiservice Integrated 463 Voice/Data Networks," Proceeding of ITC-16, Edinburgh, June 1999. 464 [ASH3] Ash, G. R., "Performance Evaluation of QoS-Routing Methods for 465 IP-Based Multiservice Networks," Computer Communications Magazine, 466 May 2003. 468 Internet Draft MAR Bandwidth Constraints Model for DS-TE Jan 04 470 TDM-Based Multiservice Networks, work in progress. 471 [BUR] Burke, P. J., Blocking Probabilities Associated with Directional 472 Reservation, unpublished memorandum, 1961. 473 [DSTE-PERF] Lai, W., "Bandwidth Constraints Models for DiffServ-TE: 474 Performance Evaluation", work in progress. 475 [E.360.1 --> E.360.7] ITU-T Recommendations, "QoS Routing & Related 476 Traffic Engineering Methods for Multiservice TDM-, ATM-, & IP-Based 477 Networks". 478 [GMPLS-RECOV] Lang, J., et. al., "Generalized MPLS Recovery Functional 479 Specification", work in progress. 480 [KRU] Krupp, R. S., "Stabilization of Alternate Routing Networks", 481 Proceedings of ICC, Philadelphia, 1982. 482 [LAI] Lai, W., "Traffic Engineering for MPLS, Internet Performance and 483 Control of Network Systems III Conference", SPIE Proceedings Vol. 4865, 484 pp. 256-267, Boston, Massachusetts, USA, 29 July-1 August 2002 485 (http://www.columbia.edu/~ffl5/waisum/bcmodel.pdf). 486 [MAM] Le Faucheur, F., Lai, W., "Maximum Allocation Bandwidth 487 Constraints Model for Diff-Serv-aware MPLS Traffic Engineering", work in 488 progress. 489 [MPLS-BACKUP] Vasseur, J. P., et. al., "MPLS Traffic Engineering Fast 490 Reroute: Bypass Tunnel Path Computation for Bandwidth Protection", work 491 in progress. 492 [MUM] Mummert, V. S., "Network Management and Its Implementation on the 493 No. 4ESS, International Switching Symposium", Japan, 1976. 494 [NAK] Nakagome, Y., Mori, H., Flexible Routing in the Global 495 Communication Network, Proceedings of ITC-7, Stockholm, 1973. 496 [OSPF-TE] Katz, D., et. al., "Traffic Engineering (TE) Extensions to 497 OSPF Version 2," RFC 3630, September 2003. 498 [RDM] Le Faucheur, F., "Russian Dolls Bandwidth Constraints Model for 499 Diff-Serv-aware MPLS Traffic Engineering", work in progress. 500 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", 501 BCP 9, RFC 2026, October 1996. 502 [RSVP-TE] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP 503 Tunnels", RFC 3209, December 2001. 505 13. Intellectual Property Statement 507 The IETF takes no position regarding the validity or scope of any 508 intellectual property or other rights that might be claimed to 509 pertain to the implementation or use of the technology described in 510 this document or the extent to which any license under such rights 511 might or might not be available; neither does it represent that it 512 has made any effort to identify any such rights. Information on the 513 IETF's procedures with respect to rights in standards-track and 514 standards-related documentation can be found in RFC 2028. Copies of 515 claims of rights made available for publication and any assurances of 516 licenses to be made available, or the result of an attempt made to 517 obtain a general license or permission for the use of such 518 proprietary rights by implementors or users of this specification can 519 be obtained from the IETF Secretariat. 521 Internet Draft MAR Bandwidth Constraints Model for DS-TE Jan 04 523 The IETF invites any interested party to bring to its attention any 524 copyrights, patents or patent applications, or other proprietary 525 rights which may cover technology that may be required to practice 526 this standard. Please address the information to the IETF Executive 527 Director. 529 14. Authors' Addresses 531 Jerry Ash 532 AT&T 533 Room MT D5-2A01 534 200 Laurel Avenue 535 Middletown, NJ 07748, USA 536 Phone: +1 732-420-4578 537 Email: gash@att.com 539 Appendix A. MAR Operation & Performance Analysis 541 A.1 MAR Operation 543 In the MAR Bandwidth Constraints Model, the bandwidth allocation control 544 for each CT is based on estimated bandwidth needs, bandwidth use, and 545 status of links. The LER makes needed bandwidth allocation changes, and 546 uses [RSVP-TE], for example, to determine if link bandwidth can be 547 allocated to a CT. Bandwidth allocated to individual CTs is protected as 548 needed but otherwise shared. Under normal non-congested network 549 conditions, all CTs/services fully share all available bandwidth. When 550 congestion occurs for a particular CTc, bandwidth reservation acts to 551 prohibit traffic from other CTs from seizing the allocated capacity for 552 CTc. Associated with each CT is the allocated bandwidth constraint 553 (BCc) to govern bandwidth allocation and protection, these parameters 554 are illustrated with examples in this Appendix. 556 In performing MAR bandwidth allocation for a given flow/LSP, the LER 557 first determines the egress LSR address, service-identity, and CT. The 558 connection request is allocated an equivalent bandwidth to be routed on 559 a particular CT. The LER then accesses the CT priority, QoS/traffic 560 parameters, and routing table between the LER and egress LSR, and sets 561 up the connection request using the MAR bandwidth allocation rules. The 562 LER selects a first choice path and determines if bandwidth can be 563 allocated on the path based on the MAR bandwidth allocation rules given 564 in Section 4. If the first choice path has insufficient bandwidth, the 565 LER may then try alternate paths, and again applies the MAR bandwidth 566 allocation rules now described. 568 MAR bandwidth allocation is done on a per-CT basis, in which aggregated 569 CT bandwidth is managed to meet the overall bandwidth requirements of CT 570 service needs. Individual flows/LSPs are allocated bandwidth in the 571 corresponding CT according to CT bandwidth availability. A fundamental 572 principle applied in MAR bandwidth allocation methods is the use of 573 bandwidth reservation techniques. 575 Bandwidth reservation gives preference to the preferred traffic by 576 allowing it to seize any idle bandwidth on a link, while allowing the 577 non-preferred traffic to only seize bandwidth if there is a minimum 578 level of idle bandwidth available called the reservation bandwidth 579 Internet Draft MAR Bandwidth Constraints Model for DS-TE Jan 04 581 threshold RBW_THRES. Burke [BUR] first analyzed bandwidth reservation 582 behavior from the solution of the birth-death equations for the 583 bandwidth reservation model. Burke's model showed the relative 584 lost-traffic level for preferred traffic, which is not subject to 585 bandwidth reservation restrictions, as compared to non-preferred 586 traffic, which is subject to the restrictions. Bandwidth reservation 587 protection is robust to traffic variations and provides significant 588 dynamic protection of particular streams of traffic. It is widely used 589 in large-scale network applications [ASH1, MUM, AKI, KRU, NAK]. 591 Bandwidth reservation is used in MAR bandwidth allocation to control 592 sharing of link bandwidth across different CTs. On a given link, a 593 small amount of bandwidth RBW_THRES is reserved (say 1% of the total 594 link bandwidth), and the reservation bandwidth can be accessed when a 595 given CT has reserved bandwidth-in-progress RESERVED_BW below its 596 allocated bandwidth BC. That is, if the available link bandwidth 597 (unreserved idle link bandwidth UNRESERVED_BW) exceeds RBW_THRES, then 598 any CT is free to access the available bandwidth on the link. However, 599 if UNRESERVED_BW is less than RBW_THRES, then the CT can utilize the 600 available bandwidth only if its current bandwidth usage is below the 601 allocated amount BC. In this way, bandwidth can be fully shared among 602 CTs if available, but is protected by bandwidth reservation if below the 603 reservation level. 605 Through the bandwidth reservation mechanism, MAR bandwidth allocation 606 also gives preference to high-priority CTs, in comparison to 607 normal-priority and best-effort priority CTs. 609 Hence, bandwidth allocated to each CT is protected by bandwidth 610 reservation methods, as needed, but otherwise shared. Each LER monitors 611 CT bandwidth use on each CT, and determines if connection requests can 612 be allocated to the CT bandwidth. For example, for a bandwidth request 613 of DBW on a given flow/LSP, the LER determines the CT priority (high, 614 normal, or best-effort), CT bandwidth-in-use, and CT bandwidth 615 allocation thresholds, and uses these parameters to determine the 616 allowed load state threshold to which capacity can be allocated. In 617 allocating bandwidth DBW to a CT on given LSP, say A-B-E, each link in 618 the path is checked for available bandwidth in comparison to the allowed 619 load state. If bandwidth is unavailable on any link in path A-B-E, 620 another LSP could by tried, such as A-C-D-E. Hence determination of the 621 link load state is necessary for MAR bandwidth allocation, and two link 622 load states are distinguished: available (non-reserved) bandwidth 623 (ABW_STATE), and reserved-bandwidth (RBW_STATE). Management of CT 624 capacity uses the link state and the allowed load state threshold to 625 determine if a bandwidth allocation request can be accepted on a given 626 CT. 628 A.2 Analysis of MAR Performance 630 In this Appendix, modeling analysis is presented in which MAR bandwidth 631 allocation is shown to provide good network performance relative to full 632 sharing models, under normal and abnormal operating conditions. A 633 large-scale DiffServ-aware MPLS traffic engineering simulation model is 634 used, in which several CTs with different priority classes share the pool 635 of bandwidth on a multiservice, integrated voice/data network. MAR 636 methods have also been analyzed in practice for TDM-based networks [ASH1], 637 Internet Draft MAR Bandwidth Constraints Model for DS-TE Jan 04 639 and in modeling studies for IP-based networks [ASH2, ASH3, E.360]. 641 All Bandwidth Constraints Models should meet these objectives: 643 1. applies equally when preemption is either enabled or disabled (when 644 preemption is disabled, the model still works 'reasonably' well), 645 2. bandwidth efficiency, i.e., good bandwidth sharing among CTs under 646 both normal and overload conditions, 647 3. bandwidth isolation, i.e., a CT cannot hog the bandwidth of another 648 CT under overload conditions, 649 4. protection against QoS degradation, at least of the high-priority CTs 650 (e.g. high-priority voice, high-priority data, etc.), and 651 5. reasonably simple, i.e., does not require additional IGP extensions 652 and minimizes signaling load processing requirements. 654 The use of any given Bandwidth Constraints Model has significant impacts 655 on the performance of a network, as explained later. Therefore, the 656 criteria used to select a model must enable us to evaluate how a 657 particular model delivers its performance, relative to other models. Lai 658 [LAI, DSTE-PERF] has analyzed the MAM and RDM Models and provided 659 valuable insights into the relative performance of these models under 660 various network conditions. 662 In environments where preemption is not used, MAM is attractive because 663 a) it is good at achieving isolation, and b) it achieves reasonable 664 bandwidth efficiency with some QoS degradation of lower classes. When 665 preemption is used, RDM is attractive because it can achieve bandwidth 666 efficiency under normal load. However, RDM cannot provide service 667 isolation under high load or when preemption is not used. 669 Our performance analysis of MAR bandwidth allocation methods is based on 670 a full-scale, 135-node simulation model of a national network together 671 with a multiservice traffic demand model to study various scenarios and 672 tradeoffs [ASH3, E.360]. Three levels of traffic priority - high, 673 normal, and best effort -- are given across 5 CTs: normal priority voice, 674 high priority voice, normal priority data, high priority data, and best 675 effort data. 677 The performance analyses for overloads and failures include a) the MAR 678 Bandwidth Constraints Model, as specified in Section 4, b) the MAM 679 Bandwidth Constraints Model, and c) the No-DSTE Bandwidth Constraints 680 Model. 682 The allocated bandwidth constraints for MAR are as described in Section 683 5: 685 Normal priority CTs: BCck = PROPORTIONAL_BWk, 686 High priority CTs: BCck = FACTOR X PROPORTIONAL_BWk 687 Best-effort priority CTs: BCck = 0 689 In the MAM Bandwidth Constraints Model, the bandwidth constraints for 690 each CT are set to a multiple of the proportional bandwidth allocation: 692 Normal priority CTs: BCck = FACTOR1 X PROPORTIONAL_BWk, 693 High priority CTs: BCck = FACTOR2 X PROPORTIONAL_BWk 694 Best-effort priority CTs: BCck = 0 695 Internet Draft MAR Bandwidth Constraints Model for DS-TE Jan 04 697 Simulations show that for MAM, the sum (BCc) should exceed 698 MAX_RESERVABLE_BWk for better efficiency, as follows: 700 1. The normal priority CTs the BCc values need to be over-allocated to 701 get reasonable performance. It was found that over-allocating by 100%, 702 that is, setting FACTOR1 = 2, gave reasonable performance. 703 2. The high priority CTs can be over-allocated by a larger multiple 704 FACTOR2 in MAM and this gives better performance. 706 The rather large amount of over-allocation improves efficiency but 707 somewhat defeats the 'bandwidth protection/isolation' needed with a BC 708 Model, since one CT can now invade the bandwidth allocated to another 709 CT. Each CT is restricted to its allocated bandwidth constraint BCck, 710 which is the maximum level of bandwidth allocated to each CT on each 711 link, as in normal operation of MAM. 713 In the No-DSTE Bandwidth Constraints Model, no reservation or protection 714 of CT bandwidth is applied, and bandwidth allocation requests are 715 admitted if bandwidth is available. Furthermore, no queuing priority 716 is applied to any of the CTs in the No-DSTE Bandwidth Constraints Model. 718 Table 2 gives performance results for a six-times overload on a single 719 network node at Oakbrook IL. The numbers given in the table are the 720 total network percent lost (blocked) or delayed traffic. Note that in 721 the focused overload scenario studied here, the percent lost/delayed 722 traffic on the Oakbrook node is much higher than the network-wide 723 average values given. 725 Table 2 726 Performance Comparison for MAR, MAM, & No-DSTE 727 Bandwidth Constraints (BC) Models 728 6X Focused Overload on Oakbrook (Total Network % Lost/Delayed Traffic) 730 Class Type MAR BC MAM BC No-DSTE BC 731 Model Model Model 732 NORMAL PRIORITY VOICE 0.00 1.97 10.30 733 HIGH PRIORITY VOICE 0.00 0.00 7.05 734 NORMAL PRIORITY DATA 0.00 6.63 13.30 735 HIGH PRIORITY DATA 0.00 0.00 7.05 736 BEST EFFORT PRIORITY DATA 12.33 11.92 9.65 738 Clearly the performance is better with MAR bandwidth allocation, and the 739 results show that performance improves when bandwidth reservation is 740 used. The reason for the poor performance of the No-DSTE Model, without 741 bandwidth reservation, is due to the lack of protection of allocated 742 bandwidth. If we add the bandwidth reservation mechanism, then 743 performance of the network is greatly improved. 745 The simulations showed that the performance of MAM is quite sensitive to 746 the over-allocation factors discussed above. For example, if the BCc 747 values are proportionally allocated with FACTOR1 = 1, then the results 748 are much worse, as shown in Table 3: 750 Internet Draft MAR Bandwidth Constraints Model for DS-TE Jan 04 752 Table 3 753 Performance Comparison for MAM Bandwidth Constraints Model 754 with Different Over-allocation Factors 755 6X Focused Overload on Oakbrook (Total Network % Lost/Delayed Traffic) 757 Class Type (FACTOR1 = 1) (FACTOR1 = 2) 758 NORMAL PRIORITY VOICE 31.69 1.97 759 HIGH PRIORITY VOICE 0.00 0.00 760 NORMAL PRIORITY DATA 31.22 6.63 761 HIGH PRIORITY DATA 0.00 0.00 762 BEST EFFORT PRIORITY DATA 8.76 11.92 764 Table 4 illustrates the performance of the MAR, MAM, and No-DSTE 765 Bandwidth Constraints Models for a high-day network load pattern with a 766 50% general overload. The numbers given in the table are the total 767 network percent lost (blocked) or delayed traffic. 769 Table 4 770 Performance Comparison for MAR, MAM, & No-DSTE 771 Bandwidth Constraints (BC) Models 772 50% General Overload (Total Network % Lost/Delayed Traffic) 774 Class Type MAR BC MAM BC No-DSTE BC 775 Model Model Model 776 NORMAL PRIORITY VOICE 0.02 0.13 7.98 777 HIGH PRIORITY VOICE 0.00 0.00 8.94 778 NORMAL PRIORITY DATA 0.00 0.26 6.93 779 HIGH PRIORITY DATA 0.00 0.00 8.94 780 BEST EFFORT PRIORITY DATA 10.41 10.39 8.40 782 Again, we can see the performance is always better when MAR bandwidth 783 allocation and reservation is used. 785 Table 5 illustrates the performance of the MAR, MAM, and No-DSTE 786 Bandwidth Constraints Models for a single link failure scenario (3 787 OC-48). The numbers given in the table are the total network percent 788 lost (blocked) or delayed traffic. 790 Table 5 791 Performance Comparison for MAR, MAM, & No-DSTE 792 Bandwidth Constraints (BC) Models 793 Single Link Failure (2 OC-48) 794 (Total Network % Lost/Delayed Traffic) 796 Class Type MAR BC MAM BC No-DSTE BC 797 Model Model Model 798 NORMAL PRIORITY VOICE 0.00 0.62 0.63 799 HIGH PRIORITY VOICE 0.00 0.31 0.32 800 NORMAL PRIORITY DATA 0.00 0.48 0.50 801 HIGH PRIORITY DATA 0.00 0.31 0.32 802 BEST EFFORT PRIORITY DATA 0.12 0.72 0.63 804 Again, we can see the performance is always better when MAR bandwidth 805 allocation and reservation is used. 807 Internet Draft MAR Bandwidth Constraints Model for DS-TE Jan 04 809 Table 6 illustrates the performance of the MAR, MAM, and No-DSTE 810 Bandwidth Constraints Models for a multiple link failure scenario (3 811 links with 3 OC-48, 3 OC-3, 4 OC-3 capacity, respectively). The numbers 812 given in the table are the total network percent lost (blocked) or 813 delayed traffic. 815 Table 6 816 Performance Comparison for MAR, MAM, & No-DSTE 817 Bandwidth Constraints (BC) Models 818 Multiple Link Failure (3 Links with 2 OC-48, 2 OC-12, 1 OC-12, Respectively) 819 (Total Network % Lost/Delayed Traffic) 821 Class Type MAR BC MAM BC No-DSTE BC 822 Model Model Model 823 NORMAL PRIORITY VOICE 0.00 0.91 0.92 824 HIGH PRIORITY VOICE 0.00 0.44 0.44 825 NORMAL PRIORITY DATA 0.00 0.70 0.72 826 HIGH PRIORITY DATA 0.00 0.44 0.44 827 BEST EFFORT PRIORITY DATA 0.14 1.03 1.04 829 Again, we can see the performance is always better when MAR bandwidth 830 allocation and reservation is used. 832 Lai's results [LAI, DSTE-PERF] show the trade-off between bandwidth sharing 833 and service protection/isolation, using an analytic model of a single 834 link. He shows that RDM has a higher degree of sharing than MAM. 835 Furthermore, for a single link, the overall loss probability is the 836 smallest under full sharing and largest under MAM, with RDM being 837 intermediate. Hence, on a single link, Lai shows that the full sharing 838 model yields the highest link efficiency and MAM the lowest, and that 839 full sharing has the poorest service protection capability. 841 The results of the present study show that when considering a network 842 context, in which there are many links and multiple-link routing paths 843 are used, full sharing does not necessarily lead to maximum network-wide 844 bandwidth efficiency. In fact, the results in Table 4 show that the 845 No-DSTE Model not only degrades total network throughput, but also 846 degrades the performance of every CT that should be protected. Allowing 847 more bandwidth sharing may improve performance up to a point, but can 848 severely degrade performance if care is not taken to protect allocated 849 bandwidth under congestion. 851 Both Lai's study and this study show that increasing the degree of 852 bandwidth sharing among the different CTs leads to a tighter coupling 853 between CTs. Under normal loading conditions, there is adequate capacity 854 for each CT, which minimizes the effect of such coupling. Under overload 855 conditions, when there is a scarcity of capacity, such coupling can 856 cause severe degradation of service, especially for the lower priority 857 CTs. 859 Thus, the objective of maximizing efficient bandwidth usage, as stated 860 in Bandwidth Constraints Model objectives, must be exercised with care. 861 Due consideration needs to be given also to achieving bandwidth 862 isolation under overload, in order to minimize the effect of 863 interactions among the different CTs. The proper tradeoff of bandwidth 864 sharing and bandwidth isolation needs to be achieved in the selection of 865 Internet Draft MAR Bandwidth Constraints Model for DS-TE Jan 04 867 a Bandwidth Constraints Model. Bandwidth reservation supports greater 868 efficiency in bandwidth sharing while still providing bandwidth 869 isolation and protection against QoS degradation. 871 In summary, the proposed MAR Bandwidth Constraints Model includes the 872 following: a) allocate bandwidth to individual CTs, b) protect allocated 873 bandwidth by bandwidth reservation methods, as needed, but otherwise 874 fully share bandwidth, c) differentiate high-priority, normal-priority, 875 and best-effort priority services, and d) provide admission control to 876 reject connection requests when needed to meet performance objectives. 878 In the modeling results, the MAR Bandwidth Constraints Model compares 879 favorably with methods that do not use bandwidth reservation. In 880 particular, some of the conclusions from the modeling are as follows: 882 o MAR bandwidth allocation is effective in improving performance over 883 methods that lack bandwidth reservation and that allow more bandwidth 884 sharing under congestion, 885 o MAR achieves service differentiation for high-priority, 886 normal-priority, and best-effort priority services, 887 o bandwidth reservation supports greater efficiency in bandwidth sharing 888 while still providing bandwidth isolation and protection against QoS 889 degradation, and is critical to stable and efficient network 890 performance. 892 Appendix B. Bandwidth Prediction for Path Computation 894 As discussed in [DSTE-PROTO], there there are potential advantages for a 895 Head-end in trying to predict the impact of an LSP on the unreserved 896 bandwidth when computing the path for the LSP. One example would be to 897 perform better load-distribution of multiple LSPs across multiple 898 paths. Another example would be to avoid CAC rejection when the LSP 899 would no longer fit on a link after establishment. 901 Where such predictions are used on Head-ends, the optional Bandwidth 902 Constraints sub-TLV and the optional Maximum Reservable Bandwidth 903 sub-TLV MAY be advertised in the IGP. This can be used by Head-ends 904 to predict how an LSP affects unreserved bandwidth values. Such 905 predictions can be made with MAR by using the unreserved bandwidth 906 values advertised by the IGP, as discussed in Sections 2 and 4: 908 UNRESERVED_BWck = MAX_RESERVABLE_BWk - UNRESERVED_BWk - 909 delta0/1(CTck) * RBW-THRESk 911 where 913 delta0/1(CTck) = 0 if RESERVED_BWck < BCck 914 delta0/1(CTck) = 1 if RESERVED_BWck >= BCck 916 Furthermore, the following estimate can be made for RBW_THRESk: 918 RBW_THRESk = RBW_% * MAX_RESERVABLE_BWk, 920 where RBW_% is a locally configured variable, which could take on 921 different values for different link speeds. This information 922 could be used in conjunction with the BC sub-TLV, 923 Internet Draft MAR Bandwidth Constraints Model for DS-TE Jan 04 925 MAX_RESERVABLE_BW sub-TLV, and UNRESERVED_BW sub-TLV to make 926 predictions of available bandwidth on each link for each CT. 927 Since admission control algorithms are left for vendor differentiation, 928 predictions can only be performed effectively when the Head-end LSR 929 predictions are based on the same (or a very close) admission control 930 algorithm as used by other LSRs. 932 There may be occasional rejected LSPs when head-ends are establishing 933 LSPs through a common link. As an example, consider some link L, and 934 two head-ends H1 and H2. If only H1 or only H2 is establishing LSPs 935 through L, then the prediction is accurate. But, if both H1 and H2 are 936 establishing LSPs through L at the same time, then the prediction 937 would not work perfectly. That is, the CAC will occasionally run into a 938 rejected LSP on a link with such 'race' conditions. Also, as mentioned 939 in Appendix A, such prediction is optional and outside the scope of the 940 document. 942 Full Copyright Statement 944 Copyright (C) The Internet Society (2004). All Rights Reserved. 946 This document and translations of it may be copied and furnished to 947 others, and derivative works that comment on or otherwise explain it or 948 assist in its implementation may be prepared, copied, published and 949 distributed, in whole or in part, without restriction of any kind, 950 provided that the above copyright notice and this paragraph are included 951 on all such copies and derivative works. 953 However, this document itself may not be modified in any way, such as by 954 removing the copyright notice or references to the Internet Society or 955 other Internet organizations, except as needed for the purpose of 956 developing Internet standards in which case the procedures for 957 copyrights defined in the Internet Standards process must be followed, 958 or as required to translate it into languages other than English. 960 The limited permissions granted above are perpetual and will not be 961 revoked by the Internet Society or its successors or assigns. 963 This document and the information contained herein is provided on an "AS 964 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 965 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 966 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 967 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 968 FITNESS FOR A PARTICULAR PURPOSE.