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