idnits 2.17.1 draft-ietf-tewg-diff-te-reqts-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 945 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([TEWG-FW]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 633 has weird spacing: '...pes are ident...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2702 (ref. 'TE-REQ') == Outdated reference: A later version (-05) exists of draft-ietf-tewg-framework-04 ** Downref: Normative reference to an Informational draft: draft-ietf-tewg-framework (ref. 'TEWG-FW') == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-04 == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-02 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'ISIS-TE') == Outdated reference: A later version (-09) exists of draft-ietf-mpls-rsvp-lsp-tunnel-08 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-cr-ldp-05 == Outdated reference: A later version (-08) exists of draft-ietf-diffserv-new-terms-04 ** Downref: Normative reference to an Informational draft: draft-ietf-diffserv-new-terms (ref. 'DIFF-NEW') Summary: 13 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Francois Le Faucheur, Editor 3 Thomas Nadeau 4 Cisco Systems, Inc. 6 Martin Tatham 7 BT 9 Thomas Telkamp 10 David Cooper 11 Global Crossing 13 Jim Boyle 14 Luca Martini 15 Level 3 Communications, LLC 17 Luyuan Fang 18 Waisum Lai 19 Jerry Ash 20 AT&T 22 Pete Hicks 23 Core Express 25 Angela Chiu 26 Celion Networks 28 William Townsend 29 Tenor Networks 31 Darek Skalecki 32 Nortel Networks 34 IETF Internet Draft 35 Expires: November, 2001 36 Document: draft-ietf-tewg-diff-te-reqts-01.txt June, 2001 38 Requirements for support of 39 Diff-Serv-aware MPLS Traffic Engineering 41 Status of this Memo 43 This document is an Internet-Draft and is in full conformance with 44 all provisions of Section 10 of RFC2026. Internet-Drafts are 45 Working documents of the Internet Engineering Task Force (IETF), its 46 areas, and its working groups. Note that other groups may also 47 distribute working documents as Internet-Drafts. 49 Internet-Drafts are draft documents valid for a maximum of six 50 months and may be updated, replaced, or obsoleted by other documents 52 Le Faucheur, et. al 1 54 Requirements for Diff-Serv Traffic Engineering June 2001 56 at any time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 The list of current Internet-Drafts can be accessed at 60 http://www.ietf.org/ietf/1id-abstracts.txt. 61 The list of Internet-Draft Shadow Directories can be accessed at 62 http://www.ietf.org/shadow.html. 64 Abstract 66 This document presents the Service Provider requirements for support 67 of Diff-Serv aware MPLS Traffic Engineering (DS-TE) as discussed in 68 the Traffic Engineering Working Group Framework document [TEWG-FW]. 70 1. Problem Statement 72 Diff-Serv is becoming prominent in providing scalable multi-class of 73 services in IP networks. 75 In some Diff-Serv networks where optimization of transmission 76 resources on a network-wide basis is not sought, MPLS Traffic 77 Engineering mechanisms may simply not be used in complement to Diff- 78 Serv mechanisms. 80 In other networks, where some optimization of transmission resources 81 is sought, Diff-Serv mechanisms ([DIFF-MPLS]) may be complemented by 82 existing MPLS Traffic Engineering mechanisms ([TE-REQ], [ISIS-TE], 83 [OSPF-TE], [RSVP-TE], [CR-LDP]) which operate on an aggregate basis 84 across all Diff-Serv Behavior Aggregates. In that case, Diff-Serv 85 and MPLS TE both provides their respective benefits (i.e. Diff-Serv 86 performs service differentiation at every hop, Traffic Engineering 87 achieves better distribution of the aggregate traffic load across 88 the set of network resources). However, they operate independently 89 of each other. In other words, MPLS Traffic Engineering performs 90 Constraint Based Routing and Admission Control with the same set of 91 global constraints for all Behavior Aggregates and without the 92 ability to use different sets of constraints for different Behavior 93 Aggregates. 95 In yet other networks where fine optimization of transmission 96 resources is sought, it may be beneficial to perform traffic 97 engineering at a per-class level instead of an aggregate level, in 98 order to further enhance networks in performance and efficiency as 99 discussed in [TEWG-FW]. By mapping a traffic trunk in a given class 100 on a separate LSP, it allows the traffic trunk to utilize resources 101 available to the given class on both shortest path(s) and non- 102 shortest paths and follow paths that meet constraints which are 103 specific to the given class. This is what we refer to as "Diff-Serv- 104 aware Traffic Engineering (DS-TE)". 106 Le Faucheur et. al 2 108 Requirements for Diff-Serv Traffic Engineering June 2001 110 This document focuses exclusively on the specific environments which 111 would benefit from DS-TE. In preview, networks where bandwidth is 112 scarce (e.g. transcontinental networks), where high priority traffic 113 can be significant compared to link speed on some links (e.g. 114 service provider networks with very large voice trunks), and where 115 the relative proportion of traffic across Behavior Aggregates is not 116 uniform across the whole topology are examples of networks where 117 Diff-Serv-aware Traffic Engineering may yield significant benefits. 119 This document focuses on intra-domain operations. Inter-domain 120 operations is not considered. 122 Below are examples of specific scenarios where Service Providers 123 require DS-TE. 125 1.1. Scenario 1: High Proportion of Voice 127 An IP/MPLS network may need to carry a significant amount of VoIP 128 (EF) traffic, compared to its link capacities. For example, 10,000 129 uncompressed calls at 20ms packetization result in about 1Gbps of IP 130 traffic, which is already significant on an OC-48c based network. In 131 case of topology changes such as link/node failure, EF traffic 132 levels can even approach the link bandwidths. 134 For delay/jitter reasons it is undesirable to carry more than a 135 certain percentage of EF traffic on any link. The rest of the 136 available link bandwidth can be used to route other classes 137 corresponding to delay/jitter insensitive traffic (e.g. Best Effort 138 Internet traffic). The exact determination of this percentage is 139 outside the scope of this requirements draft. 141 During normal operations, the VoIP traffic should be able to preempt 142 other classes of traffic (if these other classes are designated as 143 preemptable and they have lower preemption priority), 144 so that it will be able to use the shortest available path, only 145 constrained by the maximum defined VoIP link utilization 146 ratio/percentage. 148 Existing TE mechanisms only allow to do constraint based routing of 149 traffic based on a single bandwidth constraint common to all 150 classes, which does not satisfy the needs described here. 152 1.2. Scenario 2: Rerouting on Lower Speed facilities 154 An IP/MPLS network may support multiple classes of traffic. Assume 155 that a network topology includes OC48/192s links including {Chicago 156 to New York, New York to Washington DC, Washington DC to Dallas and 157 Dallas to Chicago} and some OC3/12s links along {Chicago to 158 Cleveland, Cleveland to Philadelphia, Philadelphia to New York}. 160 Le Faucheur et. al 3 162 Requirements for Diff-Serv Traffic Engineering June 2001 164 Assume also, as in previous scenario, that one (or more) high 165 priority class(es) of service has tight quality requirements which 166 could not be met if there was more traffic of this class on a link 167 than a "moderate" percentage of the link. 169 The OC48/192s and OC3/12s links may have been provisioned so that, 170 in steady state, there will be less high priority traffic than the 171 desired "moderate" percentage. For instance, the amount of high 172 priority traffic may be "relatively" small so that, in steady state, 173 the network administrator knows that it will never exceed 25 % of 174 any link capacity, without having to enforce this via separate 175 constraint based routing or Admission Control. To provide the 176 appropriate level of quality to each class of service, the network 177 administrator only needs to configure the Diff-Serv PHBs (scheduler 178 queues) appropriately. 180 However, under failure of some links, the remaining links may not 181 always be sufficient to ensure that after rerouting, high priority 182 traffic does not exceed the "moderate" percentage on all the links. 184 Consider a failure scenario in the topology above where the Chicago 185 to New York link is down while there is no failure of the OC3/12 186 links. As traffic is rerouted, it is possible that the jitter 187 sensitive high priority traffic will exceed the desired percentage 188 of link capacity of the links along the shorter, but lower capacity 189 routes. In our scenario, the "relatively small" amount of high 190 priority traffic of 25% worth of OC48/192s may turn into "excessive" 191 amount of high priority traffic on the OC3/12 links. 193 Current TE mechanisms allow high priority traffic to be rerouted 194 separately from the other classes of traffic (i.e. by building 195 separate TE-LSPs for high priority and for other classes). However, 196 current mechanisms only allow route computation to enforce a common 197 bandwidth constraint. Assuming that the network administrator elects 198 to give higher preemption priority to the high priority traffic (in 199 order to maximize its chances of being rerouted and also maximize 200 its chances of being rerouted on its shortest path), this may result 201 in high priority tunnels routed onto the OC3/12 links up to the full 202 capacity of the link. This would result in unacceptable degradation 203 of quality of the high priority traffic. 205 This leads to the requirement for DS-TE to be able to enforce a 206 different bandwidth constraint for different classes of traffic. In 207 the above example, the bandwidth constraint to be enforced for high 208 priority traffic may be the "moderate" percentage of each link 209 capacity, while the bandwidth constraint to be enforced for the rest 210 of the traffic may be the full link capacity. This would result in 211 high priority traffic/voice being rerouted first on the {Chicago to 212 Cleveland}, {Cleveland to Philadelphia} and {Philadelphia to New 213 York} links up to the "moderate" percentage of each of these links 214 and other classes of service to be routed on these links to fill up 215 the remaining capacity. Additional high priority traffic/voice which 217 Le Faucheur et. al 4 219 Requirements for Diff-Serv Traffic Engineering June 2001 221 cannot be rerouted over the {Chicago to Cleveland}, {Cleveland to 222 Philadelphia} and {Philadelphia to New York} links because it would 223 exceed their "moderate" percentage, will be rerouted along other 224 paths which excludes these links. 226 1.3. Scenario 3: Maintain relative proportion of traffic classes 228 Suppose an IP/MPLS network supports 3 classes of traffic. The 229 network administrator wants to perform Traffic Engineering to 230 distribute the traffic load. Assume also that proportion across 231 traffic classes varies significantly depending on the 232 source/destination POPs. 234 Then, with existing Traffic Engineering mechanisms, the proportion 235 of traffic from each class on a given link will vary depending on 236 multiple factors including: 237 - in which order the different TE-LSPs are routed 238 - the preemption priority associated with the different TE-LSPs 239 - failure situations leading to reroute 241 This may make it difficult or impossible for the network 242 administrator to configure the Diff-Serv PHBs (e.g. queue bandwidth) 243 to ensure that each traffic class gets the appropriate treatment. 245 This leads again to the requirement for DS-TE to be able to enforce 246 a different bandwidth constraint for different classes of traffic. 247 This could be used to ensure that, regardless of the order in which 248 tunnels are routed, regardless of their preemption priority and 249 regardless of the failure situation, the amount of traffic of each 250 class routed over a link matches the Diff-Serv scheduler 251 configuration on that link for the corresponding class (e.g. queue 252 bandwidth). 254 As an illustration of how DS-TE would address this scenario, the 255 network administrator may configure the service rate of Diff-Serv 256 queues to (45%,35%,20%) for classes (1,2,3) respectively. The 257 administrator would then build separate TE LSPs for each class and 258 associate to each LSP the bandwidth need for its class. The network 259 administrator may also want to give highest preemption priority to 260 the highest priority class and medium preemption priority to the 261 medium class. Then DS-TE could ensure that after a failure, class 1 262 traffic would be rerouted with first access at link capacity but 263 without exceeding its service rate of 45% of the link bandwidth. 264 Class 2 traffic would be rerouted with second access at the link 265 capacity but without exceeding its allotment. Note that where class 266 3 is the Best-Effort service, the requirement on DS-TE is to ensure 267 that the total amount of traffic routed across all classes does not 268 exceed the total link capacity of 100 (as opposed to separately 269 limiting the amount of Best Effort traffic to 20 even if there was 270 little class 1 and class 2 traffic). 272 Le Faucheur et. al 5 274 Requirements for Diff-Serv Traffic Engineering June 2001 276 In this scenario, DS-TE allowed to maintain a somewhat steady 277 distribution of different classes, even during rerouting. This 278 relied on the required capability of DS-TE to adjust the amount of 279 traffic of each class routed on a link based on the configuration of 280 the scheduler for that class. 282 Alternatively (or perhaps in addition), some network administrators 283 may want to solve the issue in the opposite way through the 284 scheduler configuration being dynamically tied into the amount of 285 bandwidth of the LSPs admitted for each class. This is an additional 286 requirement on DS-TE. 288 1.4. Scenario 4: Guaranteed Bandwidth Services 290 In addition to the Best effort service, an IP/MPLS network operator 291 may desire to offer a point-to-point "guaranteed bandwidth" service 292 whereby the provider pledges to provide a given level of performance 293 (bandwidth/delay/loss...) end-to-end through its network from an 294 ingress port to and egress port. The goal is to ensure all 295 "guaranteed" traffic within a subscribed traffic contract, will be 296 delivered within stated tolerances. 298 One approach for deploying such "guaranteed" service involves: 299 - dedicating a Diff-Serv PHB (or a Diff-Serv PSC as defined in 300 [DIFF-NEW]) to the "guaranteed" traffic 301 - policing guaranteed traffic on ingress against the traffic 302 contract and marking the "guaranteed" packets with the 303 corresponding DSCP/EXP value 305 Where very high level of performance is targeted for the 306 "guaranteed" service, it may be necessary to ensure that the amount 307 of "guaranteed" traffic remains below a given percentage of link 308 capacity on every link. Where the proportion of "guaranteed" traffic 309 is high, constraint based routing can be used to enforce such a 310 constraint. 312 However, the network operator may also want to simultaneously 313 perform Traffic Engineering of the rest of the traffic (i.e. non- 314 guaranteed traffic) which would require that constraint based 315 routing is also capable of enforcing another bandwidth constraint, 316 which would be less stringent than the one for guaranteed traffic. 318 Again, this combination of requirements can not be addressed with 319 existing TE mechanisms. DS-TE mechanisms allowing enforcement of a 320 different bandwidth constraint for guaranteed traffic and for non- 321 guaranteed traffic are required. 323 2. Detailed Requirements for DS-TE 325 Le Faucheur et. al 6 327 Requirements for Diff-Serv Traffic Engineering June 2001 329 2.1. DS-TE Compatibility 331 While DS-TE is required in a number of situations such as the ones 332 described above, it is important to keep in mind that using DS-TE 333 may impact scalability (as discussed later in this document) and 334 operational practices. DS-TE should only be used when existing TE 335 mechanisms combined with Diff-Serv can not address the network 336 design requirements. Many network operators may choose to not use 337 DS-TE, or to only use it in a limited scope within their network. 339 Thus, the DS-TE solution must be developed in such a way that: 340 (i) it raises no interoperability issues with existing deployed 341 TE mechanisms. Networks which do not require DS-TE must not 342 be impacted in any way. 343 (ii) it allows DS-TE deployment to the required level of 344 granularity and scope (e.g. only in a subset of the 345 topology, e.g. only for the number of Classes required in 346 the considered network) 348 2.2. Separate Bandwidth Constraints 350 [TEWG-FW] introduces the concept of Class-Types. The fundamental 351 requirement for DS-TE is to be able to enforce different bandwidth 352 constraints for different Class Types rather than a single one. 354 Based on the scenarios of section 1, DS-TE must allow the network 355 operator to configure the bandwidth constraints such that: 356 - DS-TE never routes more than P1% of EF on a given link 357 - DS-TE never routes more than P0% of EF+BE on that link,where 358 P1 and P0 are configurable separately. 360 Just for illustration purposes a network operator may configure 361 P1=70 and P0=100. In this case, DS-TE could have established at a 362 given time, for instance, : 363 - 70% worth of EF and 30% worth of BE, OR 364 - 50% worth of EF and 50% worth of BE, OR 365 - 0% worth of EF and 100% worth of BE. 366 Clearly, DS-TE would never establish more than 70% of EF TE-LSPs 367 even if there was very little or no BE TE-LSPs routed on the link. 369 Where 3 Class-Types are supported (e.g. CT2=EF, CT1=AF1+AF2, CT0=BE) 370 in the scenarios of section 1, DS-TE must allow the network operator 371 to configure the bandwidth constraints such that: 372 - DS-TE never routes more than say P2% of CT2 on a given link 373 - DS-TE never routes more than say P1% of CT2+CT1 on that link. 374 - DS-TE never routes more than say P0% of CT2+CT1+CT0 on that 375 link. 377 Just as an example, the network operator may configure P2=60, P1=80 378 and P0=100. In that case, DS-TE could have established at a given 379 time, for instance, : 381 Le Faucheur et. al 7 383 Requirements for Diff-Serv Traffic Engineering June 2001 385 - 60% worth of EF, 20% worth of AF and 20% worth of BE, OR 386 - 0% worth of EF, 80% worth of AF and 20% worth of BE, OR 387 - 40% worth of EF, 40% worth of AF and 20% worth of BE, OR 388 - 30% worth of EF, 30% worth of AF and 40% worth of BE. 389 Clearly, DS-TE would never establish more than 60% of EF TE-LSPs 390 even if there was very little or no AF and BE TE-LSPs routed on the 391 link. Similarly, DS-TE would never establish more than 80% worth of 392 EF+AF TE-LSPs even if there was very little or no BE TE-LSPs routed 393 on the link. 395 More generally, the bandwidth constraints enforced by DS-TE must 396 allow the following: 397 - if a high priority class does not use up all of its bandwidth, the 398 next highest priority should be able to make use of this unused 399 bandwidth. For instance, in the above example with 3 Class-Types, 400 if CT2/EF is only using 30% (instead of its maximum 60%), then 401 CT1/AF should be able to use up to 50%. However, if CT2/EF is 402 using its 60%, it is obviously necessary to limit CT1/AF to much 403 below 50% (i.e. to 20% in our example) in order to maintain CT2's 404 performance levels. 405 - If a lower priority class (e.g. AF) used some of the unused 406 bandwidth of a higher priority class (e.g. EF), the high priority 407 class should be able to reclaim this bandwidth where necessary 408 (i.e. preempt lower priority class - see section 2.5) 409 - lower priority class-Types (e.g Best Effort) should not be 410 completely starved by higher priority classes. 411 - Highest priority classes, should only be routed away from their 412 shortest path when they would exceed their own bandwidth 413 constraints. They should not be routed away from their shortest 414 path because of lower priority classes. 416 Therefore, where N Class-Types are supported, DS-TE must allow the 417 network operator to configure the following bandwidth constraints: 419 - never route more than P(N-1)% of CT(N-1) on a given link 420 - never route more than P(N-2)% of CT(N-1)+CT(N-2) on that 421 link. 422 - never route more than P(N-3)% of CT(N-1)+CT(N-2)+CT(N-3) on 423 that link. 424 - etc. 425 - never route more than P(0)% of CT(N-1)+CT(N-2)+... + CT(0) on 426 that link, 428 where P(N-1), P(N-2), ..., P(0) are each configurable separately for 429 every link. 431 DS-TE may optionally support additional bandwidth constraints. 433 2.3. Number of Class-Types 435 Le Faucheur et. al 8 437 Requirements for Diff-Serv Traffic Engineering June 2001 439 DS-TE must support a minimum of 4 Class-Types. 441 In a given network, DS-TE must not force the network administrator 442 to support the maximum number of Class-Types. The network 443 administrator must be able to deploy DS-TE for only 2, for only 3 or 444 for 4 Class-Types. 446 DS-TE must minimize the scalability impact when low number of Class- 447 Types are actually deployed. 449 DS-TE should be extensible to support more Class-Types if required. 451 2.4. Number of Classes 453 DS-TE should not constrain the number of classes that can be grouped 454 in a Class-Type. 456 2.5. Preemption 458 2.5.1. Preemption Within a Class-Type 460 DS-TE must support multiple preemption priorities within a given 461 Class-Type (i.e. between two TE LSPs from the same Class-Type). 462 Preemption within a Class-Type must operate in a similar way to how 463 preemption operates in existing TE: 465 expanding on the description of preemption in [TEWG-FW], a traffic 466 trunk of Class-Type CTx, say "A", can preempt another traffic trunk 467 of same Class-Type CTx, say "B", only if *all* of the following five 468 conditions hold: 469 (i) "A" has a relatively higher priority than "B", 470 (ii) "A" contends for a resource utilized by "B" (including link 471 bandwidth which must satisfy all the bandwidth constraints 472 relevant to CTx), 473 (iii) the resource cannot concurrently accommodate "A" and "B" 474 based on certain decision criteria, 475 (iv) "A" is preemptor enabled, and 476 (v) "B" is preemptable. 478 DS-TE must also allow the network operator to configure the TE-LSPs 479 of a given Class-Type so that they are all at the same preemption 480 priority and thus do not preempt each other. 482 2.5.2. Preemption Across Class-Types 484 DS-TE must support multiple preemption priorities across Class-Types 485 (i.e. between two TE LSPs from different Class-Types). Preemption 486 across Class-Types must operate in the following way: 488 Le Faucheur et. al 9 490 Requirements for Diff-Serv Traffic Engineering June 2001 492 a traffic trunk of Class-Type CTx, say "A", can preempt another 493 traffic trunk of another Class-Type CTy, say "B", only if *all* of 494 the following five conditions hold: 495 (i) "A" has a relatively higher priority than "B", 496 (ii) "A" contends for a resource utilized by "B" (including link 497 bandwidth which must satisfy all the bandwidth constraints 498 relevant to CTx). In other words, where preemption is used 499 across Class-Types, the high priority traffic in one Class- 500 Type must have the ability to pre-empt lower priority 501 traffic, but only while still within the constraint of the 502 maximum bandwidth available to that Class-Type., 503 (iii) the resource cannot concurrently accommodate "A" and "B" 504 based on certain decision criteria, 505 (iv) "A" is preemptor enabled, and 506 (v) "B" is preemptable. 508 As an example, let's consider the case described in section 2.2 509 where the following bandwidth constraints are configured: 510 - DS-TE never routes more than say 70% of EF on a given link 511 - DS-TE never routes more than 100% of EF+BE on that link. 513 Let's assume that DS-TE has actually established at a given time: 514 - 50% worth of EF TE-LSPs and 515 - 50% worth of BE TE-LSPs. 516 Let's also assume that a new EF TE-LSP worth 10% now needs to be 517 established and contends for this link. 518 Then, DS-TE must allow preemption across Class-Types so that, if so 519 desired by the network administrator, it is possible to preempt 10% 520 worth of already established BE TE-LSPs in order to establish the 521 new EF TE-LSP. Note that in this case, preemption is applicable 522 because the new EF TE-LSP contends for link bandwidth which satisfy 523 all the bandwidth constraints relevant to EF (new EF TE-LSPs of 524 50+10% would be below 70%, and new EF+BE TE-LSPs of 50+10+50-10% 525 would be within 100%). 527 Let's assume that the above preemption took place and DS-TE now has 528 actually established: 529 - 60% worth of EF TE-LSPs and 530 - 40% worth of BE TE-LSPs. 531 Let's also assume that another new TE-LSP worth 15% now needs to be 532 established. Then, preemption of BE TE-LSPs is not applicable 533 because the new EF TE-LSP would contend for link bandwidth which 534 would not satisfy the bandwidth constraints relevant to EF (new EF 535 TE-LSPs of 60+15% would exceed the 70%). 537 DS-TE must also allow the network operator to configure the TE-LSPs 538 so that preemption across Class-Types is precluded. 540 2.6. Resource Class Affinity 542 Le Faucheur et. al 10 544 Requirements for Diff-Serv Traffic Engineering June 2001 546 [TE-REQ] defines Resource class attributes associated with links and 547 defines resources affinity attributes associated with a traffic 548 trunk which can be used to specify the class of links which are to 549 be explicitly included or excluded from the path of the traffic 550 trunk. Because these attributes already have an open semantic and 551 can be used to implement whatever policy is required by the Service 552 Provider, no new attributes, nor extensions on existing attributes 553 are required. The only requirement on DS-TE is to allow separate 554 configuration of Resource Class Affinity attributes on the traffic 555 trunks corresponding to each different Class of Service. 557 2.7. Traffic Mapping 559 This section describes the requirement for an LSR which is the Head- 560 end of Diff-Serv-aware Traffic Engineering LSPs to map incoming 561 traffic onto these LSPs. 563 DS-TE must allow each Diff-Serv-aware Traffic Engineering LSP to be 564 configured with the following attributes: 565 - the set of Diff-Serv class(es) (more precisely "Ordered 566 Aggregate") that it can transport in accordance with [DIFF-MPLS] 567 - the Class-Type that must be taken into account so that 568 Constraint Based Routing enforces the relevant bandwidth 569 constraints. 571 DS-TE must support mapping of incoming traffic onto Diff-Serv-aware 572 Traffic Engineering LSPs in accordance with [DIFF-MPLS] so that only 573 packets that belong to the (set of) Behavior Aggregate(s) 574 transported over a given Diff-Serv-aware TE LSP should be mapped to 575 that LSP. In particular, where the Head-end LSR is also the MPLS 576 Edge LSR, determination of the Behavior Aggregate (and thus 577 determination of the egress Diff-Serv-aware TE LSP) is based on the 578 Diffserv Codepoint (DSCP) in the packet header. 580 2.8. Dynamic Adjustment of Diff-Serv PHBs 582 As discussed in section 1.4, DS-TE may support adjustment of Diff- 583 Serv PHBs parameters (e.g. queue bandwidth) based on the amount of 584 TE-LSPs established for each Class/Class-Type. 586 Where this behavior is supported, it must allow for disabling via 587 configuration (thus reverting to PHB treatment with static scheduler 588 configuration independent of DS-TE operations). 590 The dynamic adjustment must take account of the performance 591 requirements of each class when computing required adjustments. 593 2.9. Multiple TE Metrics 595 Le Faucheur et. al 11 597 Requirements for Diff-Serv Traffic Engineering June 2001 599 This document does not specifically discuss the need for multiple TE 600 metrics which is already work in progress. However, we note that DS- 601 TE can make immediate use of multiple TE metrics once those are 602 available simply by allowing TE-LSPs for different Classes of 603 Service to be routed based on a different TE Metric. 605 3. Solution Evaluation Criteria 607 Multiple solutions can be thought of in order to support the Diff- 608 Serv-aware TE Requirements discussed above. For example, some 609 solutions may require that all current TE protocols syntax (IGP, 610 RSVP-TE, CR-LDP) be extended in various ways to support multiple 611 bandwidth constraints rather than the existing single aggregate 612 bandwidth constraint. Alternatively, other solutions may keep the 613 existing TE protocols syntax unchanged but modify their semantic to 614 allow for the multiple bandwidth constraints. 616 This section identifies the evaluation criteria that should be used 617 to assess potential DS-TE solutions for selection. 619 3.1. Satisfying detailed requirements 621 The solution must address all the scenarios described in section 1 622 and satisfy all the requirements listed in section 2. 624 3.2. Flexibility 626 - number of Class Types that can be supported, compared to 627 number identified in Requirements section 628 - number of Classes within a Class-Type 630 3.3. Extendibility 632 - how far can the solution be extended in the future if 633 requirements for more Class-Types are identified in the 634 future. 636 3.4. Scalability 638 - impact on network scalability in what is propagated, 639 processed, stored and computed (IGP signaling, IGP 640 processing, IGP database, TE-Tunnel signaling ,...). 641 - how does scalability impact evolve with number of Class- 642 Types/Classes actually deployed in a network. In 643 particular, is it possible to keep overhead small for a 644 large networks which only use a small number of Class- 645 Types/Classes, while allowing higher number of Class- 646 Types/Classes in smaller networks which can bear higher 647 overhead) 649 Le Faucheur et. al 12 651 Requirements for Diff-Serv Traffic Engineering June 2001 653 3.5. Backward compatibility/Migration 655 - backward compatibility/migration with/from existing TE 656 mechanisms 657 - backward compatibility/migration when 658 increasing/decreasing the number of Class-Types actually 659 deployed in a given network. 661 4. Security Considerations 663 The solution developed to address the requirements defined in this 664 document must address security aspects. DS-TE is not expected to add 665 specific security requirements beyond those of Diff-Serv and 666 existing TE. Networks which employ diff-serv techniques might offer 667 some protection between classes for denial of service attacks. 668 Though depending on how the technology is employed, it is possible 669 for some (lower scheduled) traffic to be more susceptible to traffic 670 anomalies (which include denial of service attacks) occurring within 671 other (higher scheduled) classes. 673 References 675 [TE-REQ] Awduche et al, Requirements for Traffic Engineering over 676 MPLS, RFC2702, September 1999. 678 [TEWG-FW] Awduche et al, A Framework for Internet Traffic 679 Engineering, draft-ietf-tewg-framework-04.txt, April 2001. 681 [OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF, 682 draft-katz-yeung-ospf-traffic-04.txt, August 2001. 684 [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft- 685 ietf-isis-traffic-02.txt, September 2000. 687 [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 688 Tunnels", draft-ietf-mpls-rsvp-lsp-tunnel-08.txt, February 2001. 690 [DIFF-MPLS] Le Faucheur et al, "MPLS Support of Diff-Serv", draft- 691 ietf-mpls-diff-ext-09.txt, April 2001 693 [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", 694 draft-ietf-mpls-cr-ldp-05.txt, February 2001 696 [DIFF-NEW] Grossman, "New Terminology for Diffserv", work in 697 progress, draft-ietf-diffserv-new-terms-04.txt, March 2001. 699 Le Faucheur et. al 13 701 Requirements for Diff-Serv Traffic Engineering June 2001 703 Authors' Address: 705 Francois Le Faucheur 706 Cisco Systems, Inc. 707 Village d'Entreprise Green Side - Batiment T3 708 400, Avenue de Roumanille 709 06410 Biot-Sophia Antipolis 710 France 711 Phone: +33 4 97 23 26 19 712 Email: flefauch@cisco.com 714 Martin Tatham 715 BT 716 Adastral Park, 717 Martlesham Heath, 718 Ipswich IP5 3RE 719 UK 720 Phone: +44-1473-606349 721 Email: martin.tatham@bt.com 723 Thomas Telkamp 724 Global Crossing 725 Olympia 6 726 1213 NP Hilversum 727 The Netherlands 728 Phone: +31 35 655 651 729 E-mail: telkamp@gblx.net 731 David Cooper 732 Global Crossing 733 960 Hamlin Court 734 Sunnyvale, CA 94089 735 USA 736 Phone: +1 916 415 0437 737 E-mail: dcooper@gblx.net 739 Jim Boyle 740 Level 3 Communications, LLC. 741 1025 Eldorado Blvd. 742 Broomfield, CO, 80021 743 USA 744 Email: jboyle@Level3.net 746 Luca Martini 747 Level 3 Communications, LLC. 748 1025 Eldorado Blvd. 749 Broomfield, CO, 80021 750 USA 751 Email: luca@level3.net 753 Le Faucheur et. al 14 755 Requirements for Diff-Serv Traffic Engineering June 2001 757 Luyuan Fang 758 AT&T Labs 759 200 Laurel Avenue 760 Middletown, New Jersey 07748 761 USA 762 Phone: +1 732 420-1921 763 Email: luyuanfang@att.com 765 Gerald R. Ash 766 AT&T Labs 767 200 Laurel Avenue 768 Middletown, New Jersey 07748 769 USA 770 Phone: +1 732 420-4578 771 Email: gash@att.com 773 Wai Sum Lai 774 AT&T Labs 775 200 Laurel Avenue 776 Middletown, New Jersey 07748 777 USA 778 Phone: +1 732 420-3712 779 Email: wlai@att.com 781 Pete Hicks 782 CoreExpress, Inc 783 12655 Olive Blvd, Suite 500 784 St. Louis, MO 63141 785 USA 786 Phone: (314) 317-7504 787 Email: pete.hicks@coreexpress.net 789 Angela Chiu 790 Celion Networks 791 1 Sheila Drive, Suite 2 792 Tinton Falls, NJ 07724 793 Phone: +1-732 747 9987 794 Email: angela.chiu@celion.com 796 William Townsend 797 Tenor Networks 798 100 Nagog Park 799 Acton, MA 01720 800 Phone: +1-978-264-4900 801 Email: btownsend@tenornetworks.com 803 Thomas D. Nadeau 804 Cisco Systems, Inc. 805 250 Apollo Drive 806 Chelmsford, MA 01824 807 Phone: +1-978-244-3051 808 Email: tnadeau@cisco.com 810 Le Faucheur et. al 15 812 Requirements for Diff-Serv Traffic Engineering June 2001 814 Darek Skalecki 815 Nortel Networks 816 3500 Carling Ave, 817 Nepean K2H 8E9 818 Phone: +1-613-765-2252 819 Email: dareks@nortelnetworks.com 821 Le Faucheur et. al 16