idnits 2.17.1 draft-ietf-tewg-diff-te-mar-02.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 1 longer page, the longest (page 1) being 839 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.) ** There are 2 instances of too long lines in the document, the longest one being 3 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 824 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 64, but not defined == Unused Reference: 'KEY' is defined on line 405, but no explicit reference was found in the text == Unused Reference: 'ASH2' is defined on line 414, but no explicit reference was found in the text == Unused Reference: 'DIFF-MPLS' is defined on line 420, but no explicit reference was found in the text == Unused Reference: 'DIFFSERV' is defined on line 422, but no explicit reference was found in the text == Unused Reference: 'MPLS-ARCH' is defined on line 449, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 453, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 10 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: March 2004 6 October, 2003 8 Max Allocation with Reservation Bandwidth Constraint Model for 9 MPLS/DiffServ TE & 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 RFC2026. 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 (DSTE) requirements 36 document by giving a functional specification for the Maximum Allocation 37 with Reservation (MAR) bandwidth constraint model. Assumptions, 38 applicability, and examples of the operation of the MAR bandwidth 39 constraint model are presented. MAR performance is analyzed relative to 40 the criteria for selecting a bandwidth constraint model, in order to 41 provide guidance to user implementation of the model in their networks. 43 Table of Contents 45 1. Introduction 46 2. Definitions 47 3. Assumptions & Applicability 48 4. Functional Specification of the MAR Bandwidth Constraint Model 49 5. Setting Bandwidth Constraints 50 6. Example of MAR Operation 51 7. Summary 52 8. Security Considerations 53 9. Acknowledgments 54 10. Normative References 55 11. Informative References 56 12. Authors' Addresses 57 ANNEX A. MAR Operation & Performance Analysis 59 Specification of Requirements 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in [RFC2119]. 65 1. Introduction 67 DiffServ-aware MPLS traffic engineering (DSTE) requirements and protocol 68 extensions are specified in [DSTE-REQ, DSTE-PROTO]. A requirement for 69 DSTE implementation is the specification of bandwidth constraint models 70 for use with DSTE. The bandwidth constraint model provides the 'rules' 71 to support the allocation of bandwidth to individual class types (CTs). 72 CTs are groupings of service classes in the DSTE model, which are 73 provided separate bandwidth allocations, priorities, and QoS objectives. 74 Several CTs can share a common bandwidth pool on an integrated, 75 multiservice MPLS/DiffServ network. 77 This document is intended to complement the DSTE requirements document 78 [DSTE-REQ] by giving a functional specification for the Maximum 79 Allocation with Reservation (MAR) bandwidth constraint model. Examples 80 of the operation of the MAR bandwidth constraint model are presented. 81 MAR performance is analyzed relative to the criteria for selecting a 82 bandwidth constraint model, in order to provide guidance to user 83 implementation of the model in their networks. 85 Two other bandwidth constraint models are being specified for use in 86 DSTE: 88 1. maximum allocation model (MAM) [MAM] - the maximum allowable 89 bandwidth usage of each CT is explicitly specified. 90 2. Russian doll model (RDM) [RDM] - the maximum allowable bandwidth 91 usage is done cumulatively by grouping successive CTs according to 92 priority classes. 94 MAR is similar to MAM in that a maximum bandwidth allocation is given to 95 each CT. However, through the use of bandwidth reservation and 96 protection mechanisms, CTs are allowed to exceed their bandwidth 97 allocations under conditions of no congestion but revert to their 98 allocated bandwidths when overload and congestion occurs. 100 All bandwidth constraint models should meet these objectives: 102 1. applies equally when preemption is either enabled or disabled (when 103 preemption is disabled, the model still works 'reasonably' well), 104 2. Bandwidth efficiency, i.e., good bandwidth sharing among CTs under 105 both normal and overload conditions, 106 3. bandwidth isolation, i.e., a CT cannot hog the bandwidth of another 107 CT under overload conditions, 108 4. protection against QoS degradation, at least of the high-priority CTs 109 (e.g. high-priority voice, high-priority data, etc.), and 110 5. reasonably simple, i.e., does not require additional IGP extensions 111 and minimizes signaling load processing requirements. 113 In Annex A modeling analysis is presented which shows that the MAR model 114 meets all these objectives, and provides good network performance 115 relative to MAM and full sharing models, under normal and abnormal 116 operating conditions. It is demonstrated that simultaneously achieves 117 bandwidth efficiency, bandwidth isolation, and protection against QoS 118 degradation without preemption. 120 In Section 3 we give the assumptions and applicability, in Section 4 a 121 functional specification of the MAR bandwidth constraint model, and in 122 Section 5 we give examples of its operation. In Annex A, MAR 123 performance is analyzed relative to the criteria for selecting a 124 bandwidth constraint model, in order to provide guidance to user 125 implementation of the model in their networks. 127 2. Definitions 129 For readability a number of definitions from [DSTE-REQ, DSTE-PROTO] are 130 repeated here: 132 Traffic Trunk: an aggregation of traffic flows of the same class (i.e. 133 which are to be treated equivalently from the DSTE perspective) which 134 are placed inside an LSP. 136 Class-Type (CT): the set of Traffic Trunks crossing a link that is 137 governed by a specific set of Bandwidth constraints. CT is used for the 138 purposes of link bandwidth allocation, constraint based routing and 139 admission control. A given Traffic Trunk belongs to the same CT on all 140 links. 142 Up to 8 CTs (MaxCT = 8) are supported. They are referred to as CTc, 0 143 <= c <= MaxCT-1 = 7. Each CT is assigned either a Bandwidth 144 Constraint, or a set of Bandwidth Constraints. Up to 8 Bandwidth 145 Constraints (MaxBC = 8) are supported and they are referred to as BCc, 146 0 <= c <= MaxBC-1 = 7. 148 TE-Class: A pair of: i. a CT ii. a preemption priority allowed for that 149 CT. This means that an LSP transporting a Traffic Trunk from that CT can 150 use that preemption priority as the set-up priority, as the holding 151 priority or both. 153 MAX_RESERVABLE_BWk: maximum reservable bandwidth on link k specifies the 154 maximum bandwidth that may be reserved; this may be greater than the 155 maximum link bandwidth in which case the link may be oversubscribed 156 [KATZ-YEUNG]. 158 BCck: bandwidth constraint for CTc on link k = allocated (minimum 159 guaranteed) bandwidth for CTc on link k (see Section 4). 161 RBW_THRESk: reservation bandwidth threshold for link k (see Section 4). 163 RESERVED_BWck: reserved bandwidth-in-progress on CTc on link k (0 <3D c 164 <3D MaxCT-1), RESERVED_BWck 3D total amount of the bandwidth reserved 165 by all the established LSPs which belong to CTc. 167 UNRESERVED_BWck: unreserved link bandwidth on CTc on link k specifies 168 the amount of bandwidth not yet reserved for CTc, UNRESERVED_BWck 3D 169 MAX_RESERVABLE_BWk - sum [RESERVED_BWck (0 <3D c <3D MaxCT-1)]. 171 A number of recovery mechanisms under investigation in the IETF take 172 advantage of the concept of bandwidth sharing across particular sets of 173 LSPs. "Shared Mesh Restoration" in [GMPLS-RECOV] and "Facility-based 174 Computation Model" in [MPLS-BACKUP] are example mechanisms which 175 increase bandwidth efficiency by sharing bandwidth across backup LSPs 176 protecting against independent failures. To ensure that the notion of 177 RESERVED_BWck introduced in [DSTE-REQ] is compatible with such a concept 178 of bandwidth sharing across multiple LSPs, the wording of the definition 179 provided in [DSTE-REQ] is generalized. With this generalization, the 180 definition is compatible with Shared Mesh Restoration defined in 181 [GMPLS-RECOV], so that DSTE and Shared Mesh Protection can operate 182 simultaneously, under the assumption that Shared Mesh Restoration 183 operates independently within each DSTE Class-Type and does not operate 184 across Class-Types. For example, backup LSPs protecting primary LSPs of 185 CTc must also belong to CTc; excess traffic LSPs sharing bandwidth with 186 backup LSPs of CTc must also belong to CTc. 188 3. Assumptions & Applicability 190 In general, DSTE is a bandwidth allocation mechanism, for different 191 classes of traffic allocated to various CTs (e.g., voice, normal data, 192 best-effort data). Network operations functions such as capacity 193 design, bandwidth allocation, routing design, and network planning are 194 normally based on traffic measured load and forecast [ASH1]. 196 As such, the following assumptions are made according to the operation 197 of MAR: 199 1. connection admission control (CAC) allocates bandwidth for network 200 flows/LSPs according to the traffic load assigned to each CT, based on 201 traffic measurement and forecast. 202 2. CAC could allocate bandwidth per flow, per LSP, per traffic trunk, or 203 otherwise. That is, no specific assumption is made on a specific CAC 204 method, only that CT bandwidth allocation is related to the 205 measured/forecast traffic load, as per assumption #1. 206 3. CT bandwidth allocation is adjusted up or down according to 207 measured/forecast traffic load. No specific time period is assumed for 208 this adjustment, it could be short term (hours), daily, weekly, monthly, 209 or otherwise. 210 4. Capacity management and CT bandwidth allocation thresholds (e.g., 211 BCc) are designed according to traffic load, and are based on traffic 212 measurement and forecast. Again, no specific time period is assumed for 213 this adjustment, it could be short term (hours), daily, weekly, monthly, 214 or otherwise. 215 5. No assumption is made on the order in which traffic is allocated to 216 various CTs, again traffic allocation is assumed to be based only on 217 traffic load as it is measured and/or forecast. 218 6. If link bandwidth is exhausted on a given path for a flow/LSP/traffic 219 trunk, alternate paths may be attempted to satisfy CT bandwidth 220 allocation. 222 Note that the above assumptions are not unique to MAR, but are generic, 223 common assumptions for all BC models. 225 4. Functional Specification of the MAR Bandwidth Constraint Model 227 A DSTE LSR implementing MAR MUST support enforcement of bandwidth 228 constraints in compliance with the specifications in this Section. 230 In the MAR bandwidth constraint model, the bandwidth allocation control 231 for each CT is based on estimated bandwidth needs, bandwidth use, and 232 status of links. The LER makes needed bandwidth allocation changes, and 233 uses [RSVP-TE], for example, to determine if link bandwidth can be 234 allocated to a CT. Bandwidth allocated to individual CTs is protected as 235 needed but otherwise shared. Under normal non-congested network 236 conditions, all CTs/services fully share all available bandwidth. When 237 congestion occurs for a particular CTc, bandwidth reservation acts to 238 prohibit traffic from other CTs from seizing the allocated capacity for 239 CTc. 241 On a given link k, a small amount of bandwidth RBW_THRESk, the 242 reservation bandwidth threshold for link k, is reserved and governs the 243 admission control on link k. Also associated with each CTc on link k 244 are the allocated bandwidth constraints BCck to govern bandwidth 245 allocation and protection. The reservation bandwidth on a link, 246 RBW_THRESk, can be accessed when a given CTc has bandwidth-in-use 247 RESERVED_BWck below its allocated bandwidth constraint BCck. However, 248 if RESERVED_BWck exceeds its allocated bandwidth constraint BCck, then 249 the reservation bandwidth RBW_THRESk cannot be accessed. In this way, 250 bandwidth can be fully shared among CTs if available, but is otherwise 251 protected by bandwidth reservation methods. 253 Bandwidth can be accessed for a bandwidth request = DBW for CTc on a 254 given link k based on the following rules: 256 Table 1: Rules for Admitting LSP Bandwidth Request = DBW on Link k 258 For LSP on a high priority or normal priority CTc: 259 If RESERVED_BWck <= BCc: admit if DBW <= UNRESERVED_BWk 260 If RESERVED_BWck > BCc: admit if DBW <= UNRESERVED_BWk - RBW_THRESk 262 For LSP on a best-effort priority CTc: 263 allocated bandwidth BCc = 0; 264 DiffServ queuing admits BE packets only if there is available link 265 bandwidth; 267 The normal semantics of setup and holding priority are applied in the 268 MAR bandwidth constraint model, and cross-CT preemption is permitted 269 when preemption is enabled. 271 The bandwidth allocation rules defined in Table 1 are illustrated with 272 an example in Section 6 and simulation analysis in ANNEX A. 274 5. Setting Bandwidth Constraints 276 For a normal priority CTc, the bandwidth constraints BCck on link k are 277 set by allocating the maximum reservable bandwidth (MAX_RESERVABLE_BWk) 278 in proportion to the forecast or measured traffic load bandwidth 279 TRAF_LOAD_BWck for CTc on link k. That is: 281 PROPORTIONAL_BWck = TRAF_LOAD_BWck/[sum {TRAF_LOAD_BWck, c=0,MaxCT-1}] X 282 MAX_RESERVABLE_BWk 284 For normal priority CTc: 285 BCck = PROPORTIONAL_BWck 287 For a high priority CT, the bandwidth constraint BCck is set to a 288 multiple of the proportional bandwidth. That is: 290 For high priority CTc: 291 BCck = FACTOR X PROPORTIONAL_BWck 293 where FACTOR is set to a multiple of the proportional bandwidth (e.g., 294 FACTOR = 2 or 3 is typical). This results in some 'over-allocation' 295 of the maximum reservable bandwidth, and gives priority to the high 296 priority CTs. Normally the bandwidth allocated to high priority CTs 297 should be a relatively small fraction of the total link bandwidth, a 298 maximum of 10-15 percent being a reasonable guideline. 300 As stated in Section 4, the bandwidth allocated to a best-effort 301 priority CTc should be set to zero. That is: 303 For best-effort priority CTc: 304 BCck = 0 306 6. Example of MAR Operation 308 In the example, assume there are three class-types: CT0, CT1, CT2. We 309 consider a particular link with 311 MAX-RESERVABLE_BW = 100 313 And with the allocated bandwidth constraints set as follows: 315 BC0 = 30 316 BC1 = 20 317 BC2 = 20 319 These bandwidth constraints are based on the normal traffic loads, as 320 discussed in Section 5. With MAR, any of the CTs is allowed to exceed 321 its bandwidth constraint BCc as long a there is at least RBW_THRES 322 (reservation bandwidth threshold on the link) units of spare bandwidth 323 remaining. Let's assume 325 RBW_THRES = 10 327 So under overload, if 329 RESERVED_BW0 = 50 330 RESERVED_BW1 = 30 331 RESERVED_BW2 = 10 333 Therefore, for this loading 335 UNRESERVED_BW = 100 - 50 - 30 - 10 = 10 337 CT0 and CT1 can no longer increase their bandwidth on the link, since 338 they are above their BC values and there is only RBW_THRES=10 units of 339 spare bandwidth left on the link. But CT2 can take the additional 340 bandwidth (up to 10 units) if the demand arrives, since it is below its 341 BC value. 343 As also discussed in Section 4, if best effort traffic is present, it 344 can always seize whatever spare bandwidth is available on the link at 345 the moment, but is subject to being lost at the queues in favor of the 346 higher priority traffic. 348 Let's say an LSP arrives for CT0 needing 5 units of bandwidth (i.e., DBW 349 = 5). We need to decide based on Table 1 whether to admit this LSP or 350 not. Since for CT0 352 RESERVED_BW0 > BC0 (50 > 30), and 353 DBW > UNRESERVED_BW - RBW_THRES (i.e., 5 > 10 - 10) 355 Table 1 says the LSP is rejected/blocked. 357 Now let's say an LSP arrives for CT2 needing 5 units of bandwidth (i.e., 358 DBW = 5). We need to decide based on Table 1 whether to admit this 359 LSP or not. Since for CT2 361 RESERVED_BW2 < BC2 (10 < 20), and 362 DBW < UNRESERVED_BW (i.e., 10 - 10 < 5) 364 Table 1 says to admit the LSP. 366 Hence, in the above example, in the current state of the link and the 367 current CT loading, CT0 and CT1 can no longer increase their bandwidth 368 on the link, since they are above their BCc values and there is only 369 RBW_THRES=10 units of spare bandwidth left on the link. But CT2 can 370 take the additional bandwidth (up to 10 units) if the demand arrives, 371 since it is below its BCc value. 373 7. Summary 375 The proposed MAR bandwidth constraint model includes the following: a) 376 allocate bandwidth to individual CTs, b) protect allocated bandwidth by 377 bandwidth reservation methods, as needed, but otherwise fully share 378 bandwidth, c) differentiate high-priority, normal-priority, and 379 best-effort priority services, and d) provide admission control to 380 reject connection requests when needed to meet performance objectives. 381 Modeling results presented in Annex A show that MAR bandwidth allocation 382 a) achieves greater efficiency in bandwidth sharing while still 383 providing bandwidth isolation and protection against QoS degradation, 384 and b) achieves service differentiation for high-priority, 385 normal-priority, and best-effort priority services. 387 8. Security Considerations 389 No new security considerations are raised by this document, they are the 390 same as in the DSTE requirements document [DSTE-REQ]. 392 9. Acknowledgements 394 DSTE and bandwidth constraint models have been an active area of 395 discussion in the TEWG. I would like to thank Wai Sum Lai for his 396 support and review of this draft. I also appreciate helpful discussions 397 with Francois Le Faucheur. 399 10. Normative References 401 [DSTE-REQ] Le Faucheur, F., Lai, W., et. al., "Requirements for Support 402 of Diff-Serv-aware MPLS Traffic Engineering," RFC 3564, July 2003. 403 [DSTE-PROTO] Le Faucheur, F., et. al., "Protocol Extensions for Support 404 of Diff-Serv-aware MPLS Traffic Engineering," work in progress. 405 [KEY] Bradner, S., "Key words for Use in RFCs to Indicate Requirement 406 Levels", RFC 2119, March 1997. 408 11. Informative References 410 [AKI] Akinpelu, J. M., The Overload Performance of Engineered Networks 411 with Nonhierarchical & Hierarchical Routing, BSTJ, Vol. 63, 1984. 412 [ASH1] Ash, G. R., Dynamic Routing in Telecommunications Networks, 413 McGraw-Hill, 1998. 414 [ASH2] Ash, G. R., et. al., Routing Evolution in Multiservice Integrated 415 Voice/Data Networks, Proceeding of ITC-16, Edinburgh, June 1999. 416 [ASH3] Ash, G. R., Traffic Engineering & QoS Methods for IP-, ATM-, & 417 TDM-Based Multiservice Networks, work in progress. 418 [BUR] Burke, P. J., Blocking Probabilities Associated with Directional 419 Reservation, unpublished memorandum, 1961. 420 [DIFF-MPLS] Le Faucheur, F., et. al., "MPLS Support of Diff-Serv", RFC 421 3270, May 2002. 422 [DIFFSERV] Blake, S., et. al., "An Architecture for Differentiated 423 Services", RFC 2475, December 1998. 424 [DSTE-PERF] Lai, W., "Bandwidth Constraints Models for Diffserv-TE: 425 Performance Evaluation", work in progress. 426 [E.360.1 --> E.360.7] ITU-T Recommendations, "QoS Routing & Related 427 Traffic Engineering Methods for Multiservice TDM-, ATM-, & IP-Based 428 Networks". 429 [GMPLS-RECOV] Lang, J., et. al., "Generalized MPLS Recovery Functional 430 Specification", work in progress. 431 [KATZ-YEUNG] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 432 Extensions to OSPF Version 2," work in progress. 433 [KRU] Krupp, R. S., "Stabilization of Alternate Routing Networks", 434 Proceedings of ICC, Philadelphia, 1982. 435 [LAI] Lai, W., "Traffic Engineering for MPLS, Internet Performance and 436 Control of Network Systems III Conference", SPIE Proceedings Vol. 4865, 437 pp. 256-267, Boston, Massachusetts, USA, 29 July-1 August 2002 438 (http://www.columbia.edu/~ffl5/waisum/bcmodel.pdf). 439 [MAM] Le Faucheur, F., Lai, W., "Maximum Allocation Bandwidth 440 Constraints Model for Diff-Serv-aware MPLS Traffic Engineering", work in 441 progress. 442 [MPLS-BACKUP] Vasseur, J. P., et. al., "MPLS Traffic Engineering Fast 443 Reroute: Bypass Tunnel Path Computation for Bandwidth Protection", work 444 in progress. 445 [MUM] Mummert, V. S., "Network Management and Its Implementation on the 446 No. 4ESS, International Switching Symposium", Japan, 1976. 447 [NAK] Nakagome, Y., Mori, H., Flexible Routing in the Global 448 Communication Network, Proceedings of ITC-7, Stockholm, 1973. 449 [MPLS-ARCH] Rosen, E., et. al., "Multiprotocol Label Switching 450 Architecture," RFC 3031, January 2001. 451 [RDM] Le Faucheur, F., "Russian Dolls Bandwidth Constraints Model for 452 Diff-Serv-aware MPLS Traffic Engineering", work in progress. 453 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", 454 BCP 9, RFC 2026, October 1996. 455 [RSVP-TE] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP 456 Tunnels", RFC 3209, December 2001. 458 11. Authors' Addresses 460 Jerry Ash 461 AT&T 462 Room MT D5-2A01 463 200 Laurel Avenue 464 Middletown, NJ 07748, USA 465 Phone: +1 732-420-4578 466 Email: gash@att.com 468 ANNEX A - MAR Operation & Performance Analysis 470 A.1 MAR Operation 472 In the MAR bandwidth constraint model, the bandwidth allocation control 473 for each CT is based on estimated bandwidth needs, bandwidth use, and 474 status of links. The LER makes needed bandwidth allocation changes, and 475 uses [RSVP-TE], for example, to determine if link bandwidth can be 476 allocated to a CT. Bandwidth allocated to individual CTs is protected as 477 needed but otherwise shared. Under normal non-congested network 478 conditions, all CTs/services fully share all available bandwidth. When 479 congestion occurs for a particular CTc, bandwidth reservation acts to 480 prohibit traffic from other CTs from seizing the allocated capacity for 481 CTc. Associated with each CT is the allocated bandwidth constraint 482 (BCc) to govern bandwidth allocation and protection, these parameters 483 are illustrated with examples in this ANNEX. 485 In performing MAR bandwidth allocation for a given flow/LSP, the LER 486 first determines the egress LSR address, service-identity, and CT. The 487 connection request is allocated an equivalent bandwidth to be routed on 488 a particular CT. The LER then accesses the CT priority, QoS/traffic 489 parameters, and routing table between the LER and egress LSR, and sets 490 up the connection request using the MAR bandwidth allocation rules. The 491 LER selects a first choice path and determines if bandwidth can be 492 allocated on the path based on the MAR bandwidth allocation rules given 493 in Section 4. If the first choice path has insufficient bandwidth, the 494 LER may then try alternate paths, and again applies the MAR bandwidth 495 allocation rules now described. 497 MAR bandwidth allocation is done on a per-CT basis, in which aggregated 498 CT bandwidth is managed to meet the overall bandwidth requirements of CT 499 service needs. Individual flows/LSPs are allocated bandwidth in the 500 corresponding CT according to CT bandwidth availability. A fundamental 501 principle applied in MAR bandwidth allocation methods is the use of 502 bandwidth reservation techniques. 504 Bandwidth reservation gives preference to the preferred traffic by 505 allowing it to seize any idle bandwidth on a link, while allowing the 506 non-preferred traffic to only seize bandwidth if there is a minimum 507 level of idle bandwidth available called the reservation bandwidth 508 threshold RBW_THRES. Burke [BUR] first analyzed bandwidth reservation 509 behavior from the solution of the birth-death equations for the 510 bandwidth reservation model. Burke's model showed the relative 511 lost-traffic level for preferred traffic, which is not subject to 512 bandwidth reservation restrictions, as compared to non-preferred 513 traffic, which is subject to the restrictions. Bandwidth reservation 514 protection is robust to traffic variations and provides significant 515 dynamic protection of particular streams of traffic. It is widely used 516 in large-scale network applications [ASH1, MUM, AKI, KRU, NAK]. 518 Bandwidth reservation is used in MAR bandwidth allocation to control 519 sharing of link bandwidth across different CTs. On a given link, a 520 small amount of bandwidth RBW_THRES is reserved (say 1% of the total 521 link bandwidth), and the reservation bandwidth can be accessed when a 522 given CT has reserved bandwidth-in-progress RESERVED_BW below its 523 allocated bandwidth BC. That is, if the available link bandwidth 524 (unreserved idle link bandwidth UNRESERVED_BW) exceeds RBW_THRES, then 525 any CT is free to access the available bandwidth on the link. However, 526 if UNRESERVED_BW is less than RBW_THRES, then the CT can utilize the 527 available bandwidth only if its current bandwidth usage is below the 528 allocated amount BC. In this way, bandwidth can be fully shared among 529 CTs if available, but is protected by bandwidth reservation if below the 530 reservation level. 532 Through the bandwidth reservation mechanism, MAR bandwidth allocation 533 also gives preference to high-priority CTs, in comparison to 534 normal-priority and best-effort priority CTs. 536 Hence, bandwidth allocated to each CT is protected by bandwidth 537 reservation methods, as needed, but otherwise shared. Each LER monitors 538 CT bandwidth use on each CT, and determines if connection requests can 539 be allocated to the CT bandwidth. For example, for a bandwidth request 540 of DBW on a given flow/LSP, the LER determines the CT priority (high, 541 normal, or best-effort), CT bandwidth-in-use, and CT bandwidth 542 allocation thresholds, and uses these parameters to determine the 543 allowed load state threshold to which capacity can be allocated. In 544 allocating bandwidth DBW to a CT on given LSP, say A-B-E, each link in 545 the path is checked for available bandwidth in comparison to the allowed 546 load state. If bandwidth is unavailable on any link in path A-B-E, 547 another LSP could by tried, such as A-C-D-E. Hence determination of the 548 link load state is necessary for MAR bandwidth allocation, and two link 549 load states are distinguished: available (non-reserved) bandwidth 550 (ABW_STATE), and reserved-bandwidth (RBW_STATE). Management of CT 551 capacity uses the link state and the allowed load state threshold to 552 determine if a bandwidth allocation request can be accepted on a given 553 CT. 555 A.2 Analysis of MAR Performance 557 In this Annex, modeling analysis is presented in which MAR bandwidth 558 allocation is shown to provide good network performance relative to full 559 sharing models, under normal and abnormal operating conditions. A 560 large-scale MPLS/DiffServ TE simulation model is used, in which several 561 CTs with different priority classes share the pool of bandwidth on a 562 multiservice, integrated voice/data network. MAR methods have also been 563 analyzed in practice for TDM-based networks [ASH1], and in modeling 564 studies for IP-based networks [ASH2, ASH3, E.360]. 566 All bandwidth constraint models should meet these objectives: 568 1. applies equally when preemption is either enabled or disabled (when 569 preemption is disabled, the model still works 'reasonably' well), 570 2. Bandwidth efficiency, i.e., good bandwidth sharing among CTs under 571 both normal and overload conditions, 572 3. bandwidth isolation, i.e., a CT cannot hog the bandwidth of another 573 CT under overload conditions, 574 4. protection against QoS degradation, at least of the high-priority CTs 575 (e.g. high-priority voice, high-priority data, etc.), and 576 5. reasonably simple, i.e., does not require additional IGP extensions 577 and minimizes signaling load processing requirements. 579 The use of any given bandwidth constraint model has significant impacts 580 on the performance of a network, as explained later. Therefore, the 581 criteria used to select a model must enable us to evaluate how a 582 particular model delivers its performance, relative to other models. Lai 583 [LAI, DSTE-PERF] has analyzed the MA and RD models and provided valuable 584 insights into the relative performance of these models under various 585 network conditions. 587 In environments where preemption is not used, MAM is attractive because 588 a) it is good at achieving isolation, and b) it achieves reasonable 589 bandwidth efficiency with some QoS degradation of lower classes. When 590 preemption is used, RDM is attractive because it can achieve bandwidth 591 efficiency under normal load. However, RDM cannot provide service 592 isolation under high load or when preemption is not used. 594 Our performance analysis of MAR bandwidth allocation methods is based on 595 a full-scale, 135-node simulation model of a national network together 596 with a multiservice traffic demand model to study various scenarios and 597 tradeoffs [ASH3]. Three levels of traffic priority - high, normal, and 598 best effort -- are given across 5 CTs: normal priority voice, high 599 priority voice, normal priority data, high priority data, and best 600 effort data. 602 The performance analyses for overloads and failures include a) the MAR 603 bandwidth constraint model, as specified in Section 4, b) the MAM 604 bandwidth constraint model, and c) the No-DSTE bandwidth constraint 605 model. 607 The allocated bandwidth constraints for MAR are as described in Section 608 5: 610 Normal priority CTs: BCck = PROPORTIONAL_BWk, 611 High priority CTs: BCck = FACTOR X PROPORTIONAL_BWk 612 Best-effort priority CTs: BCck = 0 614 In the MAM bandwidth constraint model, the bandwidth constraints for 615 each CT are set to a multiple of the proportional bandwidth allocation: 617 Normal priority CTs: BCck = FACTOR1 X PROPORTIONAL_BWk, 618 High priority CTs: BCck = FACTOR2 X PROPORTIONAL_BWk 619 Best-effort priority CTs: BCck = 0 621 Simulations show that for MAM, the sum (BCc) should exceed 622 MAX_RESERVABLE_BWk for better efficiency, as follows: 624 1. The normal priority CTs the BCc values need to be over-allocated to 625 get reasonable performance. It was found that over-allocating by 100%, 626 that is, setting FACTOR1 = 2, gave reasonable performance. 627 2. The high priority CTs can be over-allocated by a larger multiple 628 FACTOR2 in MAM and this gives better performance. 630 The rather large amount of over-allocation improves efficiency but 631 somewhat defeats the 'bandwidth protection/isolation' needed with a BC 632 model, since one CT can now invade the bandwidth allocated to another 633 CT. Each CT is restricted to its allocated bandwidth constraint BCck, 634 which is the maximum level of bandwidth allocated to each CT on each 635 link, as in normal operation of MAM. 637 In the No-DSTE bandwidth constraint model, no reservation or protection 638 of CT bandwidth is applied, and bandwidth allocation requests are 639 admitted if bandwidth is available. Furthermore, no queueing priority 640 is applied to any of the CTs in the No-DSTE bandwidth constraint model. 642 Table 2 gives performance results for a six-times overload on a single 643 network node at Oakbrook IL. The numbers given in the table are the 644 total network percent lost (blocked) or delayed traffic. Note that in 645 the focused overload scenario studied here, the percent lost/delayed 646 traffic on the Oakbrook node is much higher than the network-wide 647 average values given. 649 Table 2 650 Performance Comparison for MAR, MAM, & No-DSTE 651 Bandwidth Constraint (BC) Models 652 6X Focused Overload on Oakbrook (Total Network % Lost/Delayed Traffic) 654 Class Type MAR BC MAM BC No-DSTE BC 655 Model Model Model 656 NORMAL PRIORITY VOICE 0.00 1.97 10.3009 657 HIGH PRIORITY VOICE 0.00 0.00 7.0509 658 NORMAL PRIORITY DATA 0.00 6.63 13.3009 659 HIGH PRIORITY DATA 0.00 0.00 7.0509 660 BEST EFFORT PRIORITY DATA 12.33 11.92 9.6509 662 Clearly the performance is better with MAR bandwidth allocation, and the 663 results show that performance improves when bandwidth reservation is 664 used. The reason for the poor performance of the No-DSTE model, without 665 bandwidth reservation, is due to the lack of protection of allocated 666 bandwidth. If we add the bandwidth reservation mechanism, then 667 performance of the network is greatly improved. 669 The simulations showed that the performance of MAM is quite sensitive to 670 the over-allocation factors discussed above. For example, if the BCc 671 values are proportionally allocated with FACTOR1 = 1, then the results 672 are much worse, as shown in Table 3: 674 Table 3 675 Performance Comparison for MAM Bandwidth Constraint Model 676 with Different Over-allocation Factors 677 6X Focused Overload on Oakbrook (Total Network % Lost/Delayed Traffic) 679 Class Type (FACTOR1 = 1) (FACTOR1 = 2) 680 NORMAL PRIORITY VOICE 31.69 1.9709 681 HIGH PRIORITY VOICE 0.00 0.0009 682 NORMAL PRIORITY DATA 31.22 6.6309 683 HIGH PRIORITY DATA 0.00 0.0009 684 BEST EFFORT PRIORITY DATA 8.76 11.9209 686 Table 4 illustrates the performance of the MAR, MAM, and No-DSTE 687 bandwidth constraint models for a high-day network load pattern with a 688 30% general overload. The numbers given in the table are the total 689 network percent lost (blocked) or delayed traffic. 691 Table 4 692 Performance Comparison for MAR, MAM, & No-DSTE 693 Bandwidth Constraint (BC) Models 694 50% General Overload (Total Network % Lost/Delayed Traffic) 696 Class Type MAR BC MAM BC No-DSTE BC 697 Model Model Model 698 NORMAL PRIORITY VOICE 0.02 0.13 7.9809 699 HIGH PRIORITY VOICE 0.00 0.00 8.9409 700 NORMAL PRIORITY DATA 0.00 0.26 6.9309 701 HIGH PRIORITY DATA 0.00 0.00 8.9409 702 BEST EFFORT PRIORITY DATA 10.41 10.39 8.4009 704 Again, we can see the performance is always better when MAR bandwidth 705 allocation and reservation is used. 707 Table 5 illustrates the performance of the MAR, MAM, and No-DSTE 708 bandwidth constraint models for a single link failure scenario (3 709 OC-48). The numbers given in the table are the total network percent 710 lost (blocked) or delayed traffic. 712 Table 5 713 Performance Comparison for MAR, MAM, & No-DSTE 714 Bandwidth Constraint (BC) Models 715 Single Link Failure (3 OC-48s) 716 (Total Network % Lost/Delayed Traffic) 718 Class Type MAR BC MAM BC No-DSTE BC 719 Model Model Model 720 NORMAL PRIORITY VOICE 0.00 0.62 0.5809 721 HIGH PRIORITY VOICE 0.00 0.31 0.2909 722 NORMAL PRIORITY DATA 0.00 0.48 0.4609 723 HIGH PRIORITY DATA 0.00 0.31 0.2909 724 BEST EFFORT PRIORITY DATA 0.12 0.72 0.6609 726 Again, we can see the performance is always better when MAR bandwidth 727 allocation and reservation is used. 729 Table 6 illustrates the performance of the MAR, MAM, and No-DSTE 730 bandwidth constraint models for a multiple link failure scenario (3 731 links with 3 OC-48, 3 OC-3, 4 OC-3 capacity, respectively). The numbers 732 given in the table are the total network percent lost (blocked) or 733 delayed traffic. 735 Table 6 736 Performance Comparison for MAR, MAM, & No-DSTE 737 Bandwidth Constraint (BC) Models 738 Multiple Link Failure (3 Links with 3 OC-48, 3 OC-3, 4 OC-3, Respectively) 739 (Total Network % Lost/Delayed Traffic) 741 Class Type MAR BC MAM BC No-DSTE BC 742 Model Model Model 743 NORMAL PRIORITY VOICE 0.00 0.91 0.8609 744 HIGH PRIORITY VOICE 0.00 0.44 0.4209 745 NORMAL PRIORITY DATA 0.00 0.70 0.6409 746 HIGH PRIORITY DATA 0.00 0.44 0.4209 747 BEST EFFORT PRIORITY DATA 0.14 1.03 0.9809 749 Again, we can see the performance is always better when MAR bandwidth 750 allocation and reservation is used. 752 Lai's results [LAI, DSTE-PERF] show the trade-off between bandwidth sharing 753 and service protection/isolation, using an analytic model of a single 754 link. He shows that RDM has a higher degree of sharing than MAM. 755 Furthermore, for a single link, the overall loss probability is the 756 smallest under full sharing and largest under MAM, with RDM being 757 intermediate. Hence, on a single link, Lai shows that the full sharing 758 model yields the highest link efficiency and MAM the lowest, and that 759 full sharing has the poorest service protection capability. 761 The results of the present study show that when considering a network 762 context, in which there are many links and multiple-link routing paths 763 are used, full sharing does not necessarily lead to maximum network-wide 764 bandwidth efficiency. In fact, the results in Table 4 show that the 765 No-DSTE model not only degrades total network throughput, but also 766 degrades the performance of every CT that should be protected. Allowing 767 more bandwidth sharing may improve performance up to a point, but can 768 severely degrade performance if care is not taken to protect allocated 769 bandwidth under congestion. 771 Both Lai's study and this study show that increasing the degree of 772 bandwidth sharing among the different CTs leads to a tighter coupling 773 between CTs. Under normal loading conditions, there is adequate capacity 774 for each CT, which minimizes the effect of such coupling. Under overload 775 conditions, when there is a scarcity of capacity, such coupling can 776 cause severe degradation of service, especially for the lower priority 777 CTs. 779 Thus, the objective of maximizing efficient bandwidth usage, as stated 780 in bandwidth constraint model objectives, must be exercised with care. 781 Due consideration needs to be given also to achieving bandwidth 782 isolation under overload, in order to minimize the effect of 783 interactions among the different CTs. The proper tradeoff of bandwidth 784 sharing and bandwidth isolation needs to be achieved in the selection of 785 a bandwidth constraint model. Bandwidth reservation supports greater 786 efficiency in bandwidth sharing while still providing bandwidth 787 isolation and protection against QoS degradation. 789 In summary, the proposed MAR bandwidth constraint model includes the 790 following: a) allocate bandwidth to individual CTs, b) protect allocated 791 bandwidth by bandwidth reservation methods, as needed, but otherwise 792 fully share bandwidth, c) differentiate high-priority, normal-priority, 793 and best-effort priority services, and d) provide admission control to 794 reject connection requests when needed to meet performance objectives. 796 In the modeling results, the MAR bandwidth constraint model compares 797 favorably with methods that do not use bandwidth reservation. In 798 particular, some of the conclusions from the modeling are as follows: 800 o MAR bandwidth allocation is effective in improving performance over 801 methods that lack bandwidth reservation and that allow more bandwidth 802 sharing under congestion, 803 o MAR achieves service differentiation for high-priority, 804 normal-priority, and best-effort priority services, 805 o bandwidth reservation supports greater efficiency in bandwidth sharing 806 while still providing bandwidth isolation and protection against QoS 807 degradation, and is critical to stable and efficient network 808 performance. 810 Full Copyright Statement 812 Copyright (C) The Internet Society (2003). All Rights Reserved. 814 This document and translations of it may be copied and furnished to 815 others, and derivative works that comment on or otherwise explain it or 816 assist in its implementation may be prepared, copied, published and 817 distributed, in whole or in part, without restriction of any kind, 818 provided that the above copyright notice and this paragraph are included 819 on all such copies and derivative works. 821 However, this document itself may not be modified in any way, such as by 822 removing the copyright notice or references to the Internet Society or 823 other Internet organizations, except as needed for the purpose of 824 developing Internet standards in which case the procedures for 825 copyrights defined in the Internet Standards process must be followed, 826 or as required to translate it into languages other than English. 828 The limited permissions granted above are perpetual and will not be 829 revoked by the Internet Society or its successors or assigns. 831 This document and the information contained herein is provided on an "AS 832 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 833 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 834 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 835 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 836 FITNESS FOR A PARTICULAR PURPOSE.