idnits 2.17.1 draft-ietf-tewg-diff-te-reqts-06.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 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 1189 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 429 has weird spacing: '...rned by a spe...' == Line 784 has weird spacing: '... of the use o...' == Line 821 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.) -- The document date (September 2002) is 7866 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'BC-MODEL' is mentioned on line 571, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. 'DIFF-ARCH') ** Downref: Normative reference to an Informational RFC: RFC 3260 (ref. 'DIFF-NEW') ** Obsolete normative reference: RFC 3272 (ref. 'TEWG-FW') (Obsoleted by RFC 9522) ** Downref: Normative reference to an Informational RFC: RFC 2702 (ref. 'TE-REQ') == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-04 == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-06 Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Francois Le Faucheur, Editor 3 Cisco Systems, Inc. 5 Waisum Lai, Co-editor 6 AT&T 8 IETF Internet Draft 9 Expires: March, 2003 10 Document: draft-ietf-tewg-diff-te-reqts-06.txt September 2002 12 Requirements for support of 13 Diff-Serv-aware MPLS Traffic Engineering 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are 19 Working documents of the Internet Engineering Task Force (IETF), its 20 areas, and its working groups. Note that other groups may also 21 distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as reference 26 material 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/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 presents the Service Provider requirements for support 36 of Diff-Serv aware MPLS Traffic Engineering (DS-TE). 38 Its objective is to provide guidance for the definition, selection 39 and specification of a technical solution addressing these 40 requirements. Specification for this solution itself is outside the 41 scope of this document. 43 A problem statement is first provided. Then, the document describes 44 example applications scenarios identified by Service Providers where 45 existing MPLS Traffic Engineering mechanisms fall short and Diff- 46 Serv-aware Traffic Engineering is required. The detailed 47 requirements that need to be addressed by the technical solution are 48 also reviewed. Finally, the document identifies the evaluation 49 criteria that should be considered for selection and definition of 50 the technical solution. 52 Le Faucheur, et. al 1 54 Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 56 1. Introduction 58 1.1. Problem Statement 60 Diff-Serv is becoming prominent in providing scalable network 61 designs supporting multiple classes of services. 63 In some Diff-Serv networks where optimization of transmission 64 resources on a network-wide basis is not sought, MPLS Traffic 65 Engineering (TE) mechanisms may simply not be used. 67 In other networks, where optimization of transmission resources is 68 sought, Diff-Serv mechanisms [DIFF-MPLS] need to be complemented by 69 existing MPLS Traffic Engineering mechanisms [TE-REQ] [ISIS-TE] 70 [OSPF-TE] [RSVP-TE] [CR-LDP] which operate on an aggregate basis 71 across all Diff-Serv classes of service. In this case, Diff-Serv and 72 MPLS TE both provide their respective benefits. 74 Where fine-grained optimization of transmission resources is sought, 75 it is necessary to perform traffic engineering at a per-class level 76 instead of an aggregate level, in order to further enhance networks 77 in performance and efficiency as discussed in [TEWG-FW]. By mapping 78 the traffic from a given Diff-Serv class of service on a separate 79 LSP, it allows this traffic to utilize resources available to the 80 given class on both shortest path and non-shortest paths and follow 81 paths that meet engineering constraints which are specific to the 82 given class. This is what we refer to as "Diff-Serv-aware Traffic 83 Engineering (DS-TE)". 85 This document focuses exclusively on the specific environments which 86 would benefit from DS-TE. Some examples include: 88 - networks where bandwidth is scarce (e.g. transcontinental 89 networks) 90 - networks with significant amounts of delay-sensitive traffic 91 - networks where the relative proportion of traffic across 92 classes of service is not uniform 94 This document focuses on intra-domain operation. Inter-domain 95 operation is not considered. 97 1.2. Definitions 99 For the convenience of the reader, relevant Diffserv ([DIFF-ARCH], 100 [DIFF-NEW] and [DIFF-PDB]) definitions are repeated herein. 102 Behavior Aggregate (BA): a collection of packets with the same 103 (Diff-Serv) codepoint crossing a link in a particular direction. 105 Le Faucheur et. al 2 107 Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 109 Per-Hop-Behavior (PHB): the externally observable forwarding 110 behavior applied at a DS-compliant node to a Diff-Serv behavior 111 aggregate. 113 PHB Scheduling Class (PSC): A PHB group for which a common 114 constraint is that ordering of at least those packets belonging 115 to the same microflow must be preserved. 117 Ordered Aggregate (OA): a set of BAs that share an ordering 118 constraint. The set of PHBs that are applied to this set of 119 Behavior Aggregates constitutes a PHB scheduling class. 121 Traffic Aggregate (TA): a collection of packets with a codepoint 122 that maps to the same PHB, usually in a DS domain or some subset 123 of a DS domain. A traffic aggregate marked for the foo PHB is 124 referred to as the "foo traffic aggregate" or "foo aggregate" 125 interchangeably. This generalizes the concept of Behavior 126 Aggregate from a link to a network. 128 We also repeat the following definition from [TE-REQ]: 130 Traffic Trunk: an aggregation of traffic flows of the same class 131 which are placed inside a Label Switched Path. 133 In the context of the present document, "flows of the same class" is 134 to be interpreted as "flows from the same Forwarding Equivalence 135 Class which are to be treated equivalently from the DS-TE 136 perspective". 138 We refer to the set of TAs corresponding to the set of PHBs of a 139 given PSC, as a {TA}PSC. We also loosely refer to a {TA}PSC as a 140 Diff-Serv class of service, or class-of service. 142 We refer to the collection of packets which belong to a given Traffic 143 Aggregate and are associated with a given MPLS Forwarding Equivalence 144 Class (FEC) as a . 146 We refer to the set of whose TAs belong to a given {TA}PSC 147 as a . 149 1.3. Mapping of traffic to LSPs 151 A network may have multiple Traffic Aggregates (TAs) it wishes to 152 service. Recalling from [DIFF-MPLS], there are several options on 153 how the set of of a given FEC can be split into 154 Traffic Trunks for mapping onto LSPs when running MPLS Traffic 155 Engineering. 157 One option is to not split this set of so that each 158 Traffic Trunk comprises traffic from all the {TA}/PSC . This option 159 is typically used when aggregate traffic engineering is deployed 160 using current MPLS TE mechanisms. In that case, all the 162 Le Faucheur et. al 3 164 Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 166 of a given FEC are routed collectively according to a 167 single shared set of constraints and will follow the same path. Note 168 that the LSP transporting such a Traffic Trunk is, by definition, an 169 E-LSP as defined in [DIFF-MPLS]. 171 Another option is to split the different of a given 172 FEC into multiple Traffic Trunks on the basis of the {TA}PSC. In 173 other words, traffic from a given node to another given node, is 174 split based on the classes of service, into multiple Traffic Trunks 175 which are transported over separate LSPs, which can potentially 176 follow a different path through the network. DS-TE precisely takes 177 advantage of this fact and indeed computes a separate path for each 178 LSP. In so doing, DS-TE can take into account the specific 179 requirements of the Traffic Trunk transported on each LSP (e.g. 180 bandwidth requirement, preemption priority). Moreover DS-TE can take 181 into account specific engineering constraints to be enforced for 182 these sets of Traffic Trunks (e.g. limit all Traffic Trunks 183 transporting a particular {TA}PSC to x% of link capacity). In brief, 184 DS-TE achieves per LSP constraint based routing with paths that 185 tightly match the specific objectives of the traffic forming the 186 corresponding Traffic Trunk. 188 For simplicity, and because this is the specific topic of this 189 document, the above paragraphs in this section only considered 190 splitting traffic of a given FEC into multiple Traffic Aggregates on 191 the basis of {TA}PSC. However, it must be noted that, in addition to 192 this, traffic from every {TA}PSC may also be split into multiple 193 Traffic Trunks for load balancing purposes. 195 2. Contributing Authors 197 This document was the collective work of several. The text and 198 content of this document was contributed by the editors and the co- 199 authors listed below. (The contact information for the editors 200 appears in Section 9, and is not repeated below.) 202 Martin Tatham Thomas Telkamp 203 BT Global Crossing 204 Adastral Park, Martlesham Heath, Oudkerkhof 51, 3512 GJ Utrecht 205 Ipswich IP5 3RE, UK The Netherlands 206 Phone: +44-1473-606349 Phone: +31 30 238 1250 207 Email: martin.tatham@bt.com Email: telkamp@gblx.net 209 David Cooper Jim Boyle 210 Global Crossing Protocol Driven Networks, Inc. 211 960 Hamlin Court 1381 Kildaire Farm Road #288 212 Sunnyvale, CA 94089, USA Cary, NC 27511, USA 213 Phone: (916) 415-0437 Phone: (919) 852-5160 214 Email: dcooper@gblx.net Email: jboyle@pdnets.com 216 Le Faucheur et. al 4 218 Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 220 Luyuan Fang Gerald R. Ash 221 AT&T Labs AT&T Labs 222 200 Laurel Avenue 200 Laurel Avenue 223 Middletown, New Jersey 07748, USA Middletown, New Jersey 07748,USA 224 Phone: (732) 420-1921 Phone: (732) 420-4578 225 Email: luyuanfang@att.com Email: gash@att.com 227 Pete Hicks Angela Chiu 228 CoreExpress, Inc Celion Networks 229 12655 Olive Blvd, Suite 500 1 Sheila Drive, Suite 2 230 St. Louis, MO 63141, USA Tinton Falls, NJ 07724, USA 231 Phone: (314) 317-7504 Phone: (732) 747-9987 232 Email: pete.hicks@coreexpress.net Email: angela.chiu@celion.com 234 William Townsend Thomas D. Nadeau 235 Tenor Networks Cisco Systems, Inc. 236 100 Nagog Park 250 Apollo Drive 237 Acton, MA 01720, USA Chelmsford, MA 01824, USA 238 Phone: +1 978-264-4900 Phone: (978) 244-3051 239 Email:btownsend@tenornetworks.com Email: tnadeau@cisco.com 241 Darek Skalecki 242 Nortel Networks 243 3500 Carling Ave, 244 Nepean K2H 8E9, 245 Phone: (613) 765-2252 246 Email: dareks@nortelnetworks.com 248 3. Application Scenarios 250 3.1. Scenario 1: Limiting Proportion of Classes on a Link 252 An IP/MPLS network may need to carry a significant amount of VoIP 253 traffic compared to its link capacity. For example, 10,000 254 uncompressed calls at 20ms packetization result in about 1Gbps of IP 255 traffic, which is significant on an OC-48c based network. In case of 256 topology changes such as link/node failure, VoIP traffic levels can 257 even approach the full bandwidth on certain links. 259 For delay/jitter reasons it is undesirable to carry more than a 260 certain percentage of VoIP traffic on any link. The rest of the 261 available link bandwidth can be used to route other classes 262 corresponding to delay/jitter insensitive traffic (e.g. Best Effort 263 Internet traffic). The exact determination of this "certain" 264 percentage is outside the scope of this requirements document. 266 During normal operations, the VoIP traffic should be able to preempt 267 other classes of traffic (if these other classes are designated as 268 preemptable and they have lower preemption priority), 270 Le Faucheur et. al 5 272 Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 274 so that it will be able to use the shortest available path, only 275 constrained by the maximum defined link utilization ratio/percentage 276 of the VoIP class. 278 Existing TE mechanisms only allow constraint based routing of 279 traffic based on a single bandwidth constraint common to all 280 classes, which does not satisfy the needs described here. This leads 281 to the requirement for DS-TE to be able to enforce a different 282 bandwidth constraint for different classes of traffic. In the above 283 example, the bandwidth constraint to be enforced for VoIP traffic 284 may be the "certain" percentage of each link capacity, while the 285 bandwidth constraint to be enforced for the rest of the classes 286 might have their own constraints or have access to the rest of the 287 link capacity. 289 3.2. Scenario 2: Maintain relative proportion of traffic classes 291 Suppose an IP/MPLS network supports 3 classes of traffic. The 292 network administrator wants to perform Traffic Engineering to 293 distribute the traffic load. Assume also that proportion across 294 traffic classes varies significantly depending on the 295 source/destination POPs. 297 With existing TE mechanisms, the proportion of traffic from each 298 class on a given link will vary depending on multiple factors 299 including: 300 - in which order the different TE-LSPs are routed 301 - the preemption priority associated with the different TE-LSPs 302 - link/node failure situations 304 This may make it difficult or impossible for the network 305 administrator to configure the Diff-Serv PHBs (e.g. queue bandwidth) 306 to ensure that each traffic class gets the appropriate treatment. 307 This leads again to the requirement for DS-TE to be able to enforce 308 a different bandwidth constraint for different classes of traffic. 309 This could be used to ensure that, regardless of the order in which 310 tunnels are routed, regardless of their preemption priority and 311 regardless of the failure situation, the amount of traffic of each 312 class routed over a link matches the Diff-Serv scheduler 313 configuration on that link for the corresponding class (e.g. queue 314 bandwidth). 316 As an illustration of how DS-TE would address this scenario, the 317 network administrator may configure the service rate of Diff-Serv 318 queues to (45%,35%,20%) for classes (1,2,3) respectively. The 319 administrator would then split the traffic into separate Traffic 320 Trunks for each class and associate a bandwidth to each LSP 321 transporting those Traffic Trunks. The network administrator may 322 also want to configure preemption priorities of each LSP in order to 323 give highest restoration priority to the highest priority class and 324 medium priority to the medium class. Then DS-TE could ensure that 325 after a failure, class 1 traffic would be rerouted with first access 327 Le Faucheur et. al 6 329 Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 331 at link capacity but without exceeding its service rate of 45% of 332 the link bandwidth. Class 2 traffic would be rerouted with second 333 access at the link capacity but without exceeding its allotment. 334 Note that where class 3 is the Best-Effort service, the requirement 335 on DS-TE may be to ensure that the total amount of traffic routed 336 across all classes does not exceed the total link capacity of 100% 337 (as opposed to separately limiting the amount of Best Effort traffic 338 to 20 even if there was little class 1 and class 2 traffic). 340 In this scenario, DS-TE allowed for the maintenance of a more steady 341 distribution of classes, even during rerouting. This relied on the 342 required capability of DS-TE to adjust the amount of traffic of each 343 class routed on a link based on the configuration of the scheduler 344 and the amount of bandwidth available for each class. 346 Alternatively, some network administrators may want to solve the 347 problem by having the scheduler dynamically adjusted based on the 348 amount of bandwidth of the LSPs admitted for each class. This is an 349 additional requirement on DS-TE. 351 3.3. Scenario 3: Guaranteed Bandwidth Services 353 In addition to the Best effort service, an IP/MPLS network operator 354 may desire to offer a point-to-point "guaranteed bandwidth" service 355 whereby the provider pledges to provide a given level of performance 356 (bandwidth/delay/loss...) end-to-end through its network from an 357 ingress port to and egress port. The goal is to ensure all 358 "guaranteed" traffic within a subscribed traffic contract, will be 359 delivered within stated tolerances. 361 One approach for deploying such "guaranteed" service involves: 362 - dedicating a Diff-Serv PHB (or a Diff-Serv PSC as defined in 363 [DIFF-NEW]) to the "guaranteed" traffic 364 - policing guaranteed traffic on ingress against the traffic 365 contract and marking the "guaranteed" packets with the 366 corresponding DSCP/EXP value 368 Where very high level of performance is targeted for the 369 "guaranteed" service, it may be necessary to ensure that the amount 370 of "guaranteed" traffic remains below a given percentage of link 371 capacity on every link. Where the proportion of "guaranteed" traffic 372 is high, constraint based routing can be used to enforce such a 373 constraint. 375 However, the network operator may also want to simultaneously 376 perform Traffic Engineering of the rest of the traffic (i.e. non- 377 guaranteed traffic) which would require that constraint based 378 routing is also capable of enforcing a different bandwidth 379 constraint, which would be less stringent than the one for 380 guaranteed traffic. 382 Le Faucheur et. al 7 384 Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 386 Again, this combination of requirements can not be addressed with 387 existing TE mechanisms. DS-TE mechanisms allowing enforcement of a 388 different bandwidth constraint for guaranteed traffic and for non- 389 guaranteed traffic are required. 391 4. Detailed Requirements for DS-TE 393 This section specifies the functionality that the above scenarios 394 require out of DS-TE implementations. Actual technical protocol 395 mechanisms and procedures to achieve such functionality are outside 396 the scope of this document. 398 4.1. DS-TE Compatibility 400 While DS-TE is required in a number of situations such as the ones 401 described above, it is important to keep in mind that using DS-TE 402 may impact scalability (as discussed later in this document) and 403 operational practices. DS-TE should only be used when existing TE 404 mechanisms combined with Diff-Serv cannot address the network design 405 requirements. Many network operators may choose to not use DS-TE, or 406 to only use it in a limited scope within their network. 408 Thus, the DS-TE solution must be developed in such a way that: 410 (i) it raises no interoperability issues with existing deployed 411 TE mechanisms. 412 (ii) it allows DS-TE deployment to the required level of 413 granularity and scope (e.g. only in a subset of the 414 topology, or only for the number of classes required in the 415 considered network) 417 4.2. Class-Types 419 The fundamental requirement for DS-TE is to be able to enforce 420 different bandwidth constraints for different sets of Traffic 421 Trunks. 423 [TEWG-FW] introduces the concept of Class-Types when discussing 424 operations of MPLS Traffic Engineering in a Diff-Serv environment. 426 We refine this definition into the following: 428 Class-Type (CT): the set of Traffic Trunks crossing a link, 429 that is governed by a specific set of Bandwidth 430 constraints. CT is used for the purposes of link bandwidth 431 allocation, constraint based routing and admission control. 432 A given Traffic Trunk belongs to the same CT on all links. 434 Note that different LSPs transporting Traffic Trunks from the same 435 CT may be using the same or different preemption priorities as 436 explained in more details in section 3.4 below. 438 Le Faucheur et. al 8 440 Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 442 Mapping of {TA}PSC to Class-Types is flexible. Different {TA}PSC can 443 be mapped to different CTs, multiple {TA}PSC can be mapped to the 444 same CT and one {TA}PSC can be mapped to multiple CTs. 446 For illustration purposes, let's consider the case of a network 447 running 4 Diff-Serv classes of services respectively based on the EF 448 PHB [EF], the AF1x PSC [AF], the AF2x PSC and the Default (i.e. 449 Best-Effort) PHB [DIFF-FIELD]. The network administrator may decide 450 to deploy DS-TE in the following way: 451 o from every DS-TE Head-end to every DS-TE Tail-end, split 452 traffic into 4 Traffic Trunks: one for traffic of each Diff- 453 Serv class 454 o because the QoS objectives for the AF1x Traffic Trunks and 455 for the AF2x Traffic Trunks may be of similar nature (e.g. 456 both targeting low loss albeit at different levels perhaps), 457 the same (set of) Bandwidth Constraint(s) may be applied 458 collectively over the AF1x Traffic Trunks and the AF2x 459 Traffic Trunks. Thus, the network administrator may only 460 define three CTs: one for the EF Traffic Trunks, one for the 461 AF1x and AF2x Traffic Trunks and one for the Best Effort 462 Traffic Trunks. 464 As another example of mapping of {TA}PSC to CTs, a network operator 465 may split the EF traffic into two different sets of traffic trunks, 466 so that each set of traffic trunks is subject to different 467 constraints on the bandwidth it can access. In this case, two 468 distinct CTs are defined for EF: one for the EF traffic subject to 469 the first (set of) bandwidth constraint(s), the other for the EF 470 traffic subject to the second (set of) bandwidth constraint(s). 472 DS-TE must support at least 2 CTs and up to 8 CTs. Those are 473 referred to as CTc, 0 <= c <= MaxCT-1 = 7. 475 In a given network, DS-TE must not require the network administrator 476 to always deploy the maximum number of CTs. The network 477 administrator must be able to deploy only the number of CTs actually 478 utilized. 480 4.3. Bandwidth Constraints 482 We refer to a Bandwidth Constraint Model as the set of rules 483 defining: 484 - the maximum number of Bandwidth Constraints; and 485 - which CTs each Bandwidth Constraint applies to and how. 487 By definition of CT, each CT is assigned either a Bandwidth 488 Constraint, or a set of Bandwidth Constraints. 490 We refer to the Bandwidth Constraints as BCb, 0 <= b <= MaxBC-1 492 Le Faucheur et. al 9 494 Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 496 Different models of Bandwidth Constraints are conceivable for 497 control of the CTs. 499 For example, a model with one separate Bandwidth Constraint per CT 500 could be defined. This model is defined by: 501 - MaxBC= MaxCT 502 - All LSPs supporting Traffic Trunks from CTc use no more than BCc 504 For illustration purposes, on a link of 100 unit of bandwidth where 505 three CTs are used, the network administrator might then configure 506 BC0=30, BC1= 50, BC2=20 such that: 507 - All LSPs supporting Traffic Trunks from CT0 use no more than 30 508 (e.g. Voice <= 30) 509 - All LSPs supporting Traffic Trunks from CT1 use no more than 50 510 (e.g. Premium Data <= 50) 511 - All LSPs supporting Traffic Trunks from CT2 use no more than 20 512 (e.g. Best Effort <= 20) 514 As another example, a "Russian Doll" model of Bandwidth Constraints 515 may be defined whereby: 516 - MaxBC= MaxCT 517 - All LSPs supporting Traffic Trunks from CTc (with b<=c<=7) use no 518 more than BCb 520 For illustration purposes, on a link of 100 units of bandwidth where 521 three CTs are used, the network administrator might then configure 522 BC0=100, BC1= 80, BC2=60 such that: 523 - All LSPs supporting Traffic Trunks from CT2 use no more than 60 524 (e.g. Voice <= 60) 525 - All LSPs supporting Traffic Trunks from CT1 or CT2 use no more 526 than 80 (e.g. Voice + Premium Data <= 80) 527 - All LSPs supporting Traffic Trunks from CT0 or CT1 or CT2 use no 528 more than 100 (e.g. Voice + Premium Data + Best Effort <= 100). 530 Other Bandwidth Constraints model can also be conceived. Those could 531 involve arbitrary relationships between BCb and CTc. Those could 532 also involve additional concepts such as associating minimum 533 reservable bandwidth to a CT. 535 At the time of writing this document, it is not clear whether a 536 single model of Bandwidth Constraints is sufficient, which one it 537 should be and how flexible this model really needs to be and what 538 are the implications on the DS-TE technical solution and its 539 implementations. Work is currently in progress to investigate the 540 performance and trade-offs of different operational aspects of 541 Bandwidth Constraints models. The DS-TE technical solution must 542 specify one default bandwidth constraint model which must be 543 supported by any DS-TE implementation. However, additional bandwidth 544 constraint models may also be specified. The purpose of such a 545 default model is to ensure that there is at least one common 546 Bandwidth Constraints model implementation across various vendors 547 equipment and allows for easier deployment of DS-TE. However, this 549 Le Faucheur et. al 10 551 Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 553 does not preclude a network operator to activate different Bandwidth 554 Constraints models on different links in a network, if he/she wishes 555 to do so. 557 In the selection of a default model, at least the following criteria 558 are expected to be considered: 559 (1) addresses the scenarios in Section 2 560 (2) works well under both normal and overload conditions 561 (3) applies equally when preemption is either enabled or disabled 562 (4) minimizes signaling load processing requirements 563 (5) maximizes efficient use of the network 565 In selection criteria (2), "normal condition" means that the network 566 is attempting to establish a volume of DS-TE LSPs for which it is 567 designed; "overload condition" means that the network is attempting 568 to establish a volume of DS-TE LSPs beyond the one it is designed 569 for; "works well" means that under these conditions, the network 570 should be able to sustain the expected performance, e.g., under 571 overload it is x times worse than its normal performance [BC-MODEL]. 573 These selection criteria will be further discussed and refined as 574 part of the ongoing work on BC model selection. In particular, the 575 applicability of criterion (5) needs to be qualified. 577 Regardless of the Bandwidth Constraint Model, the DS-TE solution 578 must allow support for up to 8 BCs. 580 4.4. Preemption and TE-Classes 582 [TEWG-FW] defines the notion of preemption and preemption priority. 583 DS-TE must retain full support of such preemption. However, a 584 network administrator preferring not to use preemption for user 585 traffic should be able to disable the preemption mechanisms 586 described below. 588 The preemption attributes defined in [TE-REQ] must be retained and 589 applicable across all Class Types. The preemption attributes of 590 setup priority and holding priority must retain existing semantics, 591 and in particular these semantics must not be affected by the 592 Ordered Aggregate transported by the LSP or by the LSP's Class Type. 593 This means that if LSP1 contends with LSP2 for resources, LSP1 may 594 preempt LSP2 if LSP1 has a higher set-up preemption priority (i.e. 595 lower numerical priority value) than LSP2's holding preemption 596 priority regardless of LSP1's OA/CT and LSP2's OA/CT. 598 We introduce the following definition: 600 TE-Class: A pair of: 601 (i) a Class-Type 602 (ii) a preemption priority allowed for that Class- 603 Type. This means that an LSP transporting a 604 Traffic Trunk from that Class-Type can use that 606 Le Faucheur et. al 11 608 Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 610 preemption priority as the set-up priority, as 611 the holding priority or both. 613 Note that by definition: 614 - for a given Class-Type, there may be one or multiple TE-classes 615 using that Class-Type, each using a different preemption priority 616 - for a given preemption priority, there may be one or multiple TE- 617 Class(es) using that preemption priority, each using a different 618 Class-Type. 620 DS-TE must allow all LSPs transporting Traffic Trunks of a given 621 Class-Type to use the same preemption priority. In other words, DS- 622 TE must allow a Class-Type to be used by single TE-Class. This 623 effectively allows the network administrator to ensure that no 624 preemption happens within that Class-Type, when so desired. 626 As an example, the DS-TE solution must allow the network 627 administrator to define a Class-Type comprising a single TE-class 628 using preemption 0. 630 DS-TE must allow two LSPs transporting Traffic Trunks of the same 631 Class-Type to use different preemption priorities, and allow the LSP 632 with higher (numerically lower) set-up priority to preempt the LSP 633 with lower (numerically higher) holding priority when they contend 634 for resources. In other words, DS-TE must allow multiple TE-Classes 635 to be defined for a given Class-Type. This effectively allows the 636 network administrator to enable preemption within a Class-Type, when 637 so desired. 639 As an example, the DS-TE solution must allow the network 640 administrator to define a Class-Type comprising three TE-Classes; 641 one using preemption 0, one using preemption 1 and one using 642 preemption 4. 644 DS-TE must allow two LSPs transporting Traffic Trunks from different 645 Class-Types to use different preemption priorities, and allow the 646 LSP with higher setup priority to preempt the one with lower holding 647 priority when they contend for resources. 649 As an example, the DS-TE solution must allow the network 650 administrator to define two Class-Types (CT0 and CT1) each 651 comprising two TE-Classes where say: 652 -one TE-Class groups CT0 and preemption 0 653 -one TE-Class groups CT0 and preemption 2 654 -one TE-Class groups CT1 and preemption 1 655 -one TE-Class groups CT1 and preemption 3 657 The network administrator would then, in particular, be able to : 658 - transport a CT0 Traffic Trunk over an LSP with setup priority=0 659 and holding priority=0 660 - transport a CT0 Traffic Trunk over an LSP with setup priority=2 661 and holding priority=0 663 Le Faucheur et. al 12 665 Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 667 - transport a CT1 Traffic Trunk over an LSP with setup priority=1 668 and holding priority=1 669 - transport a CT1 Traffic Trunk over an LSP with setup priority=3 670 and holding priority=1. 672 The network administrator would then, in particular, NOT be able 673 to : 674 - transport a CT0 Traffic Trunk over an LSP with setup priority=1 675 and holding priority=1 676 - transport a CT1 Traffic Trunk over an LSP with setup priority=0 677 and holding priority=0 679 DS-TE must allow two LSPs transporting Traffic Trunks from different 680 Class-Types to use the same preemption priority. In other words, the 681 DS-TE solution must allow TE-classes using different CTs to use the 682 same preemption priority. This effectively allows the network 683 administrator to ensure that no preemption happens across Class- 684 Types, if so desired. 686 As an example, the DS-TE solution must allow the network 687 administrator to define three Class-Types (CT0, CT1 and CT2) each 688 comprising one TE-Class which uses preemption 0. In that case, no 689 preemption will ever occur. 691 Since there are 8 preemption priorities and up to 8 Class-Types, 692 there could theoretically be up to 64 TE-Classes in a network. This 693 is felt to be beyond current practical requirements. The current 694 practical requirement is that the DS-TE solution must allow support 695 for up to 8 TE-classes. The DS-TE solution must allow these TE- 696 classes to comprise any arbitrary subset of 8 (or less) from the 697 (64) possible combinations of (8) Class-Types and (8) preemption 698 priorities. 700 As with existing TE, an LSP which gets preempted is torn down at 701 preemption time. The Head-end of the preempted LSP may then attempt 702 to reestablish that LSP, which involves recomputing a path by 703 Constraint Based Routing based on updated available bandwidth 704 information and then signaling for LSP establishment along the new 705 path. It must be noted that there may be cases where the preempted 706 LSP cannot be reestablished (e.g. no possible path satisfying LSP 707 bandwidth constraints as well as other constraints). In such cases, 708 the Head-end behavior is left to implementation. It may involve 709 periodic attempts at reestablishing the LSP, relaxing of the LSP 710 constraints, or other behaviors. 712 4.5. Mapping of Traffic to LSPs 714 The DS-TE solution must allow operation over E-LSPs onto which a 715 single is transported. 717 The DS-TE solution must allow operation over L-LSPs. 719 Le Faucheur et. al 13 721 Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 723 The DS-TE solution may allow operation over E-LSPs onto which 724 multiple of a given FEC are transported, under the 725 condition that those multiple can effectively be 726 treated by DS-TE as a single atomic traffic trunk (in particular 727 this means that those multiple are routed as a whole 728 based on a single collective bandwidth requirement, a single 729 affinity attribute, a single preemption level, a single Class-Type, 730 ...). In that case, it is also assumed that the multiple {TA}PSCs 731 are grouped together in a consistent manner throughout the DS-TE 732 domain (e.g. if and are transported 733 together on an E-LSP, then there will not be any L-LSP transporting 734 or on its own, and there will not be 735 any E-LSP transporting and/or with 736 ). 738 4.6. Dynamic Adjustment of Diff-Serv PHBs 740 As discussed in section 2.2, DS-TE may support adjustment of Diff- 741 Serv PHBs parameters (e.g. queue bandwidth) based on the amount of 742 TE-LSPs established for each OA/Class-Type. Such dynamic adjustment 743 is optional. It is a local matter to the LSR and as such is outside 744 the scope of this specification. 746 Where this dynamic adjustment is supported, it must allow for 747 disabling via configuration (thus reverting to PHB treatment with 748 static scheduler configuration independent of DS-TE operations). It 749 may involve a number of configurable parameters which are outside 750 the scope of this specification. Those may include configurable 751 parameters controlling how scheduling resources (e.g. service rates) 752 need to be apportioned across multiple OAs when those belong to the 753 same Class-Type and are transported together on the same E-LSP. 755 The dynamic adjustment must take account of the performance 756 requirements of each class when computing required adjustments. 758 4.7. Overbooking 760 Existing TE mechanisms allow overbooking to be applied on LSPs for 761 Constraint Based Routing and admission control. Historically this 762 has been achieved in TE deployment through factoring overbooking 763 ratios at the time of sizing the LSP bandwidth and/or at the time of 764 configuring the Maximum Reservable Bandwidth on links. 766 DS-TE must also allow overbooking and must effectively allow 767 different overbooking ratios to be enforced for different CTs. 769 DS-TE should optionally allow the effective overbooking ratio of a 770 given CT to be tweaked differently in different parts of the 771 network. 773 4.8. Restoration 775 Le Faucheur et. al 14 777 Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 779 With existing TE, restoration policies use standard priority 780 mechanisms such as, for example, the preemption priority to 781 effectively control the order/importance of LSPs for restoration 782 purposes. 784 DS-TE must ensure that similar application of the use of standard 785 priority mechanisms for implementation of restoration policy are not 786 prevented since those are expected to be required for achieving the 787 survivability requirements of DS-TE networks. 789 Further discussion of restoration requirements are presented in the 790 output document of the TEWG Requirements Design Team [SURVIV-REQ]. 792 5. Solution Evaluation Criteria 794 A range of solutions is possible for the support of the DS-TE 795 requirements discussed above. For example, some solutions may 796 require that all current TE protocols syntax (IGP, RSVP-TE, CR-LDP) 797 be extended in various ways. For instance, current TE protocols 798 could be modified to support multiple bandwidth constraints rather 799 than the existing single aggregate bandwidth constraint. 800 Alternatively, other solutions may keep the existing TE protocols 801 syntax unchanged but modify their semantic to allow for the multiple 802 bandwidth constraints. 804 This section identifies the evaluation criteria that should be used 805 to assess potential DS-TE solutions for selection. 807 5.1. Satisfying detailed requirements 809 The solution must address all the scenarios described in section 2 810 and satisfy all the requirements listed in section 3. 812 5.2. Flexibility 814 - number of Class Types that can be supported, compared to 815 number identified in Requirements section 816 - number of Classes within a Class-Type 818 5.3. Extendibility 820 - how far can the solution be extended in the future if 821 requirements for more Class-Types are identified in the 822 future. 824 5.4. Scalability 826 - impact on network scalability in what is propagated, 827 processed, stored and computed (IGP signaling, IGP 828 processing, IGP database, TE-Tunnel signaling ,...). 830 Le Faucheur et. al 15 832 Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 834 - how does scalability impact evolve with number of Class- 835 Types/Classes actually deployed in a network. In 836 particular, is it possible to keep overhead small for a 837 large networks which only use a small number of Class- 838 Types/Classes, while allowing higher number of Class- 839 Types/Classes in smaller networks which can bear higher 840 overhead) 842 5.5. Backward compatibility/Migration 844 - backward compatibility/migration with/from existing TE 845 mechanisms 846 - backward compatibility/migration when 847 increasing/decreasing the number of Class-Types actually 848 deployed in a given network. 850 6. Security Considerations 852 The solution developed to address the requirements defined in this 853 document must address security aspects. DS-TE is not expected to add 854 specific security requirements beyond those of Diff-Serv and 855 existing TE. Networks which employ Diff-Serv techniques might offer 856 some protection between classes for denial of service attacks. 857 Though depending on how the technology is employed, it is possible 858 for some (lower scheduled) traffic to be more susceptible to traffic 859 anomalies (which include denial of service attacks) occurring within 860 other (higher scheduled) classes. 862 7. Acknowledgemnt 864 We thank David Allen for his help in aligning with up-to-date 865 Diff-Serv terminology. 867 8. Normative References 869 [AF] Heinanen, J et al., "Assured Forwarding PHB Group", RFC2597 871 [DIFF-ARCH] Blake et al., "An Architecture for Differentiated 872 Services", RFC2475. 874 [DIFF-MPLS] Le Faucheur et al, "Multi-Protocol Label Switching 875 (MPLS) Support of Differentiated Services", RFC3270, May 2002. 877 [DIFF-NEW] Grossman, " New Terminology and Clarifications for 878 Diffserv ", RFC3260, April 2002. 880 [EF] Davie et al., "An Expedited Forwarding PHB (Per-Hop Behavior)", 881 RFC3246, March 2002. 883 Le Faucheur et. al 16 885 Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 887 [TEWG-FW] Awduche et al, Overview and Principles of Internet Traffic 888 Engineering, RFC3272, May 2002. 890 [TE-REQ] Awduche et al, Requirements for Traffic Engineering over 891 MPLS, RFC2702, September 1999. 893 9. Informative References 895 [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", 896 RFC3212, January 2002 898 [DIFF-FIELD] Nichols et al., "Definition of the Differentiated 899 Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC2474. 901 [DIFF-PDB] Nichols et al., "Definition of Differentiated Services 902 Per Domain Behaviors and Rules for their Specification", RFC3086. 904 [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft- 905 ietf-isis-traffic-04.txt, August 2001. 907 [OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF, 908 draft-katz-yeung-ospf-traffic-06.txt, October 2001. 910 [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 911 Tunnels", RFC 3209, December 2001. 913 [SURVIV-REQ] W.S. Lai, D. McDysan, J. Boyle, M. Carlzon, R. Coltun, 914 T, Griffin, E. Kern, and T. Reddington, "Network Hierarchy and 915 Multilayer Survivability," work in progress, October 2001. 917 10. Editors' Address: 919 Francois Le Faucheur 920 Cisco Systems, Inc. 921 Village d'Entreprise Green Side - Batiment T3 922 400, Avenue de Roumanille 923 06410 Biot-Sophia Antipolis, France 924 Phone: +33 4 97 23 26 19 925 Email: flefauch@cisco.com 927 Wai Sum Lai 928 AT&T Labs 929 200 Laurel Avenue 930 Middletown, New Jersey 07748, USA 931 Phone: (732) 420-3712 932 Email: wlai@att.com 934 Le Faucheur et. al 17 936 Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 938 Le Faucheur et. al 18