idnits 2.17.1 draft-ietf-tewg-diff-te-reqts-03.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 1123 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.) ** 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 ([DSTE-PROTO]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 668 has weird spacing: '... of the use o...' == Line 705 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 2475 (ref. 'DIFF-ARCH') ** Downref: Normative reference to an Informational draft: draft-ietf-diffserv-new-terms (ref. 'DIFF-NEW') == Outdated reference: A later version (-08) exists of draft-ietf-tewg-diff-te-proto-00 ** Downref: Normative reference to an Informational draft: draft-ietf-diffserv-ef-supplemental (ref. 'EF') == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-04 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'ISIS-TE') == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-06 ** Downref: Normative reference to an Informational draft: draft-ietf-tewg-principles (ref. 'TEWG-FW') ** Downref: Normative reference to an Informational RFC: RFC 2702 (ref. 'TE-REQ') -- Possible downref: Non-RFC (?) normative reference: ref. 'SURVIV-REQ' Summary: 13 errors (**), 0 flaws (~~), 7 warnings (==), 3 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 PDNets 16 Waisum Lai, Co-editor 17 Luyuan Fang 18 Jerry Ash 19 AT&T 21 Pete Hicks 22 Core Express 24 Angela Chiu 25 Celion Networks 27 William Townsend 28 Tenor Networks 30 Darek Skalecki 31 Nortel Networks 33 IETF Internet Draft 34 Expires: August, 2002 35 Document: draft-ietf-tewg-diff-te-reqts-03.txt February 2002 37 Requirements for support of 38 Diff-Serv-aware MPLS Traffic Engineering 40 Status of this Memo 42 This document is an Internet-Draft and is in full conformance with 43 all provisions of Section 10 of RFC2026. Internet-Drafts are 44 Working documents of the Internet Engineering Task Force (IETF), its 45 areas, and its working groups. Note that other groups may also 46 distribute working documents as Internet-Drafts. 48 Internet-Drafts are draft documents valid for a maximum of six 49 months and may be updated, replaced, or obsoleted by other documents 50 at any time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 Le Faucheur, et. al 1 55 Requirements for Diff-Serv-aware Traffic Engineering Feb 2002 57 The list of current Internet-Drafts can be accessed at 58 http://www.ietf.org/ietf/1id-abstracts.txt. 59 The list of Internet-Draft Shadow Directories can be accessed at 60 http://www.ietf.org/shadow.html. 62 Abstract 64 This document presents the Service Provider requirements for support 65 of Diff-Serv aware MPLS Traffic Engineering (DS-TE). 67 Its objective is to provide guidance for the definition, selection 68 and specification of a technical solution addressing these 69 requirements. This solution is progressed separately in [DSTE- 70 PROTO]. 72 A problem statement is first provided. Then, the document describes 73 example applications scenarios identified by Service Providers where 74 existing MPLS Traffic Engineering mechanisms fall short and Diff- 75 Serv-aware Traffic Engineering is required. The detailed 76 requirements that need to be addressed by the technical solution are 77 also reviewed. Finally, the document identifies the evaluation 78 criteria that should be considered for selection and definition of 79 the technical solution. 81 1. Introduction 83 1.1. Problem Statement 85 Diff-Serv is becoming prominent in providing scalable network 86 designs supporting multiple classes of services. 88 In some Diff-Serv networks where optimization of transmission 89 resources on a network-wide basis is not sought, MPLS Traffic 90 Engineering (TE) mechanisms may simply not be used. 92 In other networks, where optimization of transmission resources is 93 sought, Diff-Serv mechanisms [DIFF-MPLS] need to be complemented by 94 existing MPLS Traffic Engineering mechanisms [TE-REQ] [ISIS-TE] 95 [OSPF-TE] [RSVP-TE] [CR-LDP] which operate on an aggregate basis 96 across all classes of service. In this case, Diff-Serv and MPLS TE 97 both provide their respective benefits. 99 Where fine-grained optimization of transmission resources is sought, 100 it is necessary to perform traffic engineering at a per-class level 101 instead of an aggregate level, in order to further enhance networks 102 in performance and efficiency as discussed in [TEWG-FW]. By mapping 103 the traffic from a given class of service on a separate LSP, it 104 allows this traffic to utilize resources available to the given 105 class on both shortest path and non-shortest paths and follow paths 107 Le Faucheur et. al 2 109 Requirements for Diff-Serv-aware Traffic Engineering Feb 2002 111 that meet engineering constraints which are specific to the given 112 class. This is what we refer to as "Diff-Serv-aware Traffic 113 Engineering (DS-TE)". 115 This document focuses exclusively on the specific environments which 116 would benefit from DS-TE. Some examples include: 118 - networks where bandwidth is scarce (e.g. transcontinental 119 networks) 120 - networks with significant amounts of delay-sensitive traffic 121 - networks where the relative proportion of traffic across 122 classes of service is not uniform 124 This document focuses on intra-domain operation. Inter-domain 125 operation is not considered. 127 1.2. Definitions 129 For the convenience of the reader, relevant Diffserv ([DIFF-ARCH], 130 [DIFF-NEW]) definitions are repeated herein. 132 Behavior Aggregate (BA): a collection of packets with the same 133 (Diff-Serv) codepoint crossing a link in a particular direction. 135 Per-Hop-Behavior (PHB): the externally observable forwarding 136 behavior applied at a DS-compliant node to a Diff-Serv behavior 137 aggregate. 139 PHB Scheduling Class (PSC): A PHB group for which a common 140 constraint is that ordering of at least those packets belonging 141 to the same microflow must be preserved. 143 Ordered Aggregate (OA): a set of BAs that share an ordering 144 constraint. The set of PHBs that are applied to this set of 145 Behavior Aggregates constitutes a PHB scheduling class. 147 We also repeat the following definition from [TE-REQ]: 149 Traffic Trunk: an aggregation of traffic flows of the same class 150 which are placed inside a Label Switched Path. 152 [Note: in the context of the present document, "flows of the 153 same class" is to be interpreted as "flows from the same 154 Forwarding Equivalence Class which are to be treated 155 equivalently from the DS-TE perspective".] 157 1.3. Mapping of traffic to LSPs 159 A network may have multiple classes of traffic it wishes to service. 160 Recalling from [DIFF-MPLS], there are several options on how traffic 161 from multiple OAs of a given Forwarding Equivalence Class can be 163 Le Faucheur et. al 3 165 Requirements for Diff-Serv-aware Traffic Engineering Feb 2002 167 split into Traffic Trunks for mapping onto LSPs when running MPLS 168 Traffic Engineering. 170 One option is to not split traffic from the different OAs so that 171 each Traffic Trunk combines traffic from all OAs. This option is 172 typically used when aggregate traffic engineering is deployed using 173 current MPLS TE mechanisms. In that case, traffic from all OAs is 174 routed collectively according to a single shared set of constraints 175 and will follow the same path. Note that the LSP transporting such a 176 Traffic Trunk is, by definition, an E-LSP as defined in [DIFF-MPLS]. 178 Another option is to split traffic from the different OAs into 179 multiple Traffic Trunks. In other words, traffic from a given node 180 to another given node, is split into multiple Traffic Trunks which 181 are transported over separate LSPs, which can potentially follow a 182 different path through the network. DS-TE precisely takes advantage 183 of this fact and indeed computes a separate path for each LSP. In so 184 doing, DS-TE can take into account the specific requirements of the 185 Traffic Trunk transported on each LSP (e.g. bandwidth requirement, 186 preemption priority). Moreover DS-TE can take into account specific 187 engineering constraints to be enforced for these sets of Traffic 188 Trunks (e.g. limit all Traffic Trunks transporting a given set of 189 OAs to x% of link capacity). In brief, DS-TE achieves per LSP 190 constraint based routing with paths that tightly match the specific 191 objectives of the OA(s) comprising the corresponding Traffic Trunk. 193 2. Application Scenarios 195 2.1. Scenario 1: Limiting Proportion of Classes on a Link 197 An IP/MPLS network may need to carry a significant amount of VoIP 198 traffic compared to its link capacity. For example, 10,000 199 uncompressed calls at 20ms packetization result in about 1Gbps of IP 200 traffic, which is significant on an OC-48c based network. In case of 201 topology changes such as link/node failure, VoIP traffic levels can 202 even approach the full bandwidth on certain links. 204 For delay/jitter reasons it is undesirable to carry more than a 205 certain percentage of VoIP traffic on any link. The rest of the 206 available link bandwidth can be used to route other classes 207 corresponding to delay/jitter insensitive traffic (e.g. Best Effort 208 Internet traffic). The exact determination of this "certain" 209 percentage is outside the scope of this requirements draft. 211 During normal operations, the VoIP traffic should be able to preempt 212 other classes of traffic (if these other classes are designated as 213 preemptable and they have lower preemption priority), 214 so that it will be able to use the shortest available path, only 215 constrained by the maximum defined link utilization ratio/percentage 216 of the VoIP class. 218 Le Faucheur et. al 4 220 Requirements for Diff-Serv-aware Traffic Engineering Feb 2002 222 Existing TE mechanisms only allow constraint based routing of 223 traffic based on a single bandwidth constraint common to all 224 classes, which does not satisfy the needs described here. This leads 225 to the requirement for DS-TE to be able to enforce a different 226 bandwidth constraint for different classes of traffic. In the above 227 example, the bandwidth constraint to be enforced for VoIP traffic 228 may be the "certain" percentage of each link capacity, while the 229 bandwidth constraint to be enforced for the rest of the classes 230 might have their own constraints or have access to the rest of the 231 link capacity. 233 2.2. Scenario 2: Maintain relative proportion of traffic classes 235 Suppose an IP/MPLS network supports 3 classes of traffic. The 236 network administrator wants to perform Traffic Engineering to 237 distribute the traffic load. Assume also that proportion across 238 traffic classes varies significantly depending on the 239 source/destination POPs. 241 With existing TE mechanisms, the proportion of traffic from each 242 class on a given link will vary depending on multiple factors 243 including: 244 - in which order the different TE-LSPs are routed 245 - the preemption priority associated with the different TE-LSPs 246 - link/node failure situations 248 This may make it difficult or impossible for the network 249 administrator to configure the Diff-Serv PHBs (e.g. queue bandwidth) 250 to ensure that each traffic class gets the appropriate treatment. 251 This leads again to the requirement for DS-TE to be able to enforce 252 a different bandwidth constraint for different classes of traffic. 253 This could be used to ensure that, regardless of the order in which 254 tunnels are routed, regardless of their preemption priority and 255 regardless of the failure situation, the amount of traffic of each 256 class routed over a link matches the Diff-Serv scheduler 257 configuration on that link for the corresponding class (e.g. queue 258 bandwidth). 260 As an illustration of how DS-TE would address this scenario, the 261 network administrator may configure the service rate of Diff-Serv 262 queues to (45%,35%,20%) for classes (1,2,3) respectively. The 263 administrator would then split the traffic into separate Traffic 264 Trunks for each class and associate a bandwidth to each LSP 265 transporting those Traffic Trunks. The network administrator may 266 also want to configure preemption priorities of each LSP in order to 267 give highest restoration priority to the highest priority class and 268 medium priority to the medium class. Then DS-TE could ensure that 269 after a failure, class 1 traffic would be rerouted with first access 270 at link capacity but without exceeding its service rate of 45% of 271 the link bandwidth. Class 2 traffic would be rerouted with second 272 access at the link capacity but without exceeding its allotment. 273 Note that where class 3 is the Best-Effort service, the requirement 275 Le Faucheur et. al 5 277 Requirements for Diff-Serv-aware Traffic Engineering Feb 2002 279 on DS-TE may be to ensure that the total amount of traffic routed 280 across all classes does not exceed the total link capacity of 100% 281 (as opposed to separately limiting the amount of Best Effort traffic 282 to 20 even if there was little class 1 and class 2 traffic). 284 In this scenario, DS-TE allowed for the maintenance of a more steady 285 distribution of classes, even during rerouting. This relied on the 286 required capability of DS-TE to adjust the amount of traffic of each 287 class routed on a link based on the configuration of the scheduler 288 and the amount of bandwidth available for each class. 290 Alternatively, some network administrators may want to solve the 291 problem by having the scheduler dynamically adjusted based on the 292 amount of bandwidth of the LSPs admitted for each class. This is an 293 additional requirement on DS-TE. 295 2.3. Scenario 3: Guaranteed Bandwidth Services 297 In addition to the Best effort service, an IP/MPLS network operator 298 may desire to offer a point-to-point "guaranteed bandwidth" service 299 whereby the provider pledges to provide a given level of performance 300 (bandwidth/delay/loss...) end-to-end through its network from an 301 ingress port to and egress port. The goal is to ensure all 302 "guaranteed" traffic within a subscribed traffic contract, will be 303 delivered within stated tolerances. 305 One approach for deploying such "guaranteed" service involves: 306 - dedicating a Diff-Serv PHB (or a Diff-Serv PSC as defined in 307 [DIFF-NEW]) to the "guaranteed" traffic 308 - policing guaranteed traffic on ingress against the traffic 309 contract and marking the "guaranteed" packets with the 310 corresponding DSCP/EXP value 312 Where very high level of performance is targeted for the 313 "guaranteed" service, it may be necessary to ensure that the amount 314 of "guaranteed" traffic remains below a given percentage of link 315 capacity on every link. Where the proportion of "guaranteed" traffic 316 is high, constraint based routing can be used to enforce such a 317 constraint. 319 However, the network operator may also want to simultaneously 320 perform Traffic Engineering of the rest of the traffic (i.e. non- 321 guaranteed traffic) which would require that constraint based 322 routing is also capable of enforcing a differnet bandwidth 323 constraint, which would be less stringent than the one for 324 guaranteed traffic. 326 Again, this combination of requirements can not be addressed with 327 existing TE mechanisms. DS-TE mechanisms allowing enforcement of a 328 different bandwidth constraint for guaranteed traffic and for non- 329 guaranteed traffic are required. 331 Le Faucheur et. al 6 333 Requirements for Diff-Serv-aware Traffic Engineering Feb 2002 335 3. Detailed Requirements for DS-TE 337 This section specifies the functionality that the above scenarios 338 require out of DS-TE implementations. Actual technical protocol 339 mechanisms and procedures to achieve such functionality are outside 340 the scope of this document. 342 3.1. DS-TE Compatibility 344 While DS-TE is required in a number of situations such as the ones 345 described above, it is important to keep in mind that using DS-TE 346 may impact scalability (as discussed later in this document) and 347 operational practices. DS-TE should only be used when existing TE 348 mechanisms combined with Diff-Serv cannot address the network design 349 requirements. Many network operators may choose to not use DS-TE, or 350 to only use it in a limited scope within their network. 352 Thus, the DS-TE solution must be developed in such a way that: 354 (i) it raises no interoperability issues with existing deployed 355 TE mechanisms. 356 (ii) it allows DS-TE deployment to the required level of 357 granularity and scope (e.g. only in a subset of the 358 topology, or only for the number of classes required in the 359 considered network) 361 3.2. Class-Types 363 The fundamental requirement for DS-TE is to be able to enforce 364 different bandwidth constraints for different sets of Traffic 365 Trunks. 367 [TEWG-FW] introduces the concept of Class-Types when discussing 368 operations of MPLS Traffic Engineering in a Diff-Serv environment. 370 DS-TE refines this definition into the following: 372 Class-Type (CT): the set of Traffic Trunks crossing a link 373 that is governed by a specific set of Bandwidth 374 constraints. CT is used for the purposes of link bandwidth 375 allocation, constraint based routing and admission control. 376 A given Traffic Trunk belongs to the same CT on all links. 378 Note that different LSPs transporting Traffic Trunks from the same 379 CT may be using the same or different preemption priorities as 380 explained in more details in section 3.4 below. 382 For illustration purposes, let's consider the case of a network 383 running 4 Diff-Serv classes of services respectively based on the EF 384 PHB [EF], the AF1x PSC [AF], the AF2x PSC and the Default (i.e. 386 Le Faucheur et. al 7 388 Requirements for Diff-Serv-aware Traffic Engineering Feb 2002 390 Best-Effort) PHB [DIFF-FIELD]. The network administrator may decide 391 to deploy DS-TE in the following way: 392 o from every DS-TE Head-end to every DS-TE Tail-end, split 393 traffic into 4 Traffic Trunks: one for traffic of each Diff- 394 Serv class 395 o because the QoS objectives for the AF1x Traffic Trunks and 396 for the AF2x Traffic Trunks may be of similar nature (e.g. 397 both targeting low loss albeit at different levels perhaps), 398 the same (set of) Bandwidth Constraint(s) may be applied 399 collectively over the AF1x Traffic Trunks and the AF2x 400 Traffic Trunks. Thus, the network administrator may only 401 define three CTs: one for the EF Traffic Trunks, one for the 402 AF1x and AF2x Traffic Trunks and one for the Best Effort 403 Traffic Trunks. 405 As another example, a network operator may split the EF traffic into 406 two different sets of traffic trunks, so that each set of traffic 407 trunks is subject to different constraints on the bandwidth it can 408 access. In this case, two distinct CTs are defined: one for the EF 409 traffic subject to the first (set of) bandwidth constraint(s), the 410 other for the EF traffic subject to the second (set of) bandwidth 411 constraint(s). 413 DS-TE must support at least 2 CTs and up to 8 CTs. Those are 414 referred to as CTc, 0 <= c <= MaxCT-1 = 7. 416 In a given network, DS-TE must not require the network administrator 417 to always deploy the maximum number of CTs. The network 418 administrator must be able to deploy only the number of CTs actually 419 utilized. 421 3.3. Bandwidth Constraints 423 We refer to a Bandwidth Constraint Model as the set of rules 424 defining: 425 - the maximum number of Bandwidth Constraints; and 426 - which CTs each Bandwidth Constraint applies to and how. 428 By definition of CT, each CT is assigned either a Bandwidth 429 Constraint, or a set of Bandwidth Constraints. 431 We refer to the Bandwidth Constraints as BCb, 0 <= b <= MaxBC-1 433 Different models of Bandwidth Constraints are conceivable for 434 control of the CTs. 436 For example, a model with one separate Bandwidth Constraint per CT 437 could be defined. This model is defined by: 438 - MaxBC= MaxCT 439 - All LSPs supporting Traffic Trunks from CTc use no more than BCc 441 Le Faucheur et. al 8 443 Requirements for Diff-Serv-aware Traffic Engineering Feb 2002 445 For illustration purposes, on a link of 100 unit of bandwidth where 446 three CTs are used, the network administrator might then configure 447 BC0=30, BC1= 50, BC3=20 such 448 - All LSPs supporting Traffic Trunks from CT0 use no more than 30 449 (e.g. Voice <= 30) 450 - All LSPs supporting Traffic Trunks from CT1 use no more than 50 451 (e.g. Premium Data <= 50) 452 - All LSPs supporting Traffic Trunks from CT2 use no more than 20 453 (e.g. Best Effort <= 20) 455 As another example, a "Russian Doll" model of Bandwidth Constraints 456 may be defined whereby: 457 - MaxBC= MaxCT 458 - All LSPs supporting Traffic Trunks from CTc (with b<=c<=7) use no 459 more than BCb 461 For illustration purposes, on a link of 100 units of bandwidth where 462 three CTs are used, the network administrator might then configure 463 BC0=100, BC1= 80, BC2=60 such 464 - All LSPs supporting Traffic Trunks from CT2 use no more than 60 465 (e.g. Voice <= 60) 466 - All LSPs supporting Traffic Trunks from CT0 or CT1 use no more 467 than 80 (e.g. Voice + Premium Data <= 80) 468 - All LSPs supporting Traffic Trunks from CT0 or CT1 or CT2 use no 469 more than 100 (e.g. Voice + Premium Data + Best Effort <= 100). 471 Other Bandwidth Constraints model can also be conceived. Those could 472 involve arbitrary relationships between BCb and CTc. Those could 473 also involve additional concepts such as associating minimum 474 reservable bandwidth to a CT. 476 At the time of writing, it is not clear whether a single model of 477 Bandwidth Constraints is sufficient, which one it should be and how 478 flexible this model really needs to be and what are the implications 479 on the DS-TE technical solution and its implementations. Technical 480 solutions should outline their default bandwidth constraint model. 482 We expect that Bandwidth Constraints models will be refined as part 483 of the specification of the DSTE technical solution. 485 Regardless of the Bandwidth Constraint Model, the DS-TE solution 486 must allow support for up to 8 BCs. 488 3.4. Preemption and TE-Classes 490 [TEWG-FW] defines the notion of preemption and preemption priority. 491 DS-TE must retain full support of such preemption. However, a 492 network administrator preferring not to use preemption for user 493 traffic should be able to disable the preemption mechanisms 494 described below. 496 Le Faucheur et. al 9 498 Requirements for Diff-Serv-aware Traffic Engineering Feb 2002 500 The preemption attributes defined in [TE-REQ] must be retained and 501 applicable across all Class Types. The preemption attributes of 502 setup priority and holding priority must retain existing semantics, 503 and in particular these semantics must not be affected by the 504 Ordered Aggregate transported by the LSP or by the LSP's Class Type. 505 This means that if LSP1 contends with LSP2 for resources, LSP1 may 506 preempt LSP2 if LSP1 has a higher set-up preemption priority (i.e. 507 lower numerical priority value) than LSP2's holding preemption 508 priority regardless of LSP1's OA/CT and LSP2's OA/CT. 510 We introduce the following definition: 512 TE-Class: A pair of: 513 (i) a Class-Type 514 (ii) a preemption priority allowed for that Class- 515 Type. This means that an LSP transporting a 516 Traffic Trunk from that Class-Type can use that 517 preemption priority as the set-up priority, as 518 the holding priority or both. 520 Note that by definition: 521 - for a given Class-Type, there may be one or multiple TE-classes 522 using that Class-Type, each using a different preemption priority 523 - for a given preemption priority, there may be one or multiple TE- 524 Class(es) using that preemption priority, each using a different 525 Class-Type. 527 DS-TE must allow all LSPs transporting Traffic Trunks of a given 528 Class-Type to use the same preemption priority. In other words, DS- 529 TE must allow a Class-Type to be used by single TE-Class. This 530 effectively allows the network administrator to ensure that no 531 preemption happens within that Class-Type, when so desired. 533 As an example, the DS-TE solution must allow the network 534 administrator to define a Class-Type comprising a single TE-class 535 using preemption 0. 537 DS-TE must allow two LSPs transporting Traffic Trunks of the same 538 Class-Type to use different preemption priorities, and allow the LSP 539 with higher (numerically lower) set-up priority to preempt the LSP 540 with lower (numerically higher) holding priority when they contend 541 for resources. In other words, DS-TE must allow multiple TE-Classes 542 to be defined for a given Class-Type. This effectively allows the 543 network administrator to enable preemption within a Class-Type, when 544 so desired. 545 As an example, the DS-TE solution must allow the network 546 administrator to define a Class-Type comprising three TE-Classes; 547 one using preemption 0, one using preemption 1 and one using 548 preemption 4. 549 DS-TE must allow two LSPs transporting Traffic Trunks from different 550 Class-Types to use different preemption priorities, and allow the 552 Le Faucheur et. al 10 554 Requirements for Diff-Serv-aware Traffic Engineering Feb 2002 556 LSP with higher setup priority to preempt the one with lower holding 557 priority when they contend for resources. 559 As an example, the DS-TE solution must allow the network 560 administrator to define two Class-Types (CT0 and CT1) each 561 comprising two TE-Classes where say: 562 -one TE-Class groups CT0 and preemption 0 563 -one TE-Class groups CT0 and preemption 2 564 -one TE-Class groups CT1 and preemption 1 565 -one TE-Class groups CT1 and preemption 3 567 The network administrator would then, in particular, be able to : 568 - transport a CT0 Traffic Trunk over an LSP with setup priority=0 569 and holding priority=0 570 - transport a CT0 Traffic Trunk over an LSP with setup priority=2 571 and holding priority=0 572 - transport a CT1 Traffic Trunk over an LSP with setup priority=1 573 and holding priority=1 574 - transport a CT0 Traffic Trunk over an LSP with setup priority=3 575 and holding priority=1. 577 The network administrator would then, in particular, NOT be able 578 to : 579 - transport a CT0 Traffic Trunk over an LSP with setup priority=1 580 and holding priority=1 581 - transport a CT1 Traffic Trunk over an LSP with setup priority=0 582 and holding priority=0 584 DS-TE must allow two LSPs transporting Traffic Trunks from different 585 Class-Types to use the same preemption priority. In other words, the 586 DS-TE solution must allow TE-classes using different CTs to use the 587 same preemption priority. This effectively allows the network 588 administrator to ensure that no preemption happens across Class- 589 Types, if so desired. 591 As an example, the DS-TE solution must allow the network 592 administrator to define three Class-Types (CT0, CT1 and CT2) each 593 comprising one TE-Class which uses preemption 0. In that case, no 594 preemption will ever occur. 596 Since there are 8 preemption priorities and up to 8 Class-Types, 597 there could theoretically be up to 64 TE-Classes in a network. This 598 is felt to be beyond current practical requirements. The current 599 practical requirement is that the DS-TE solution must allow support 600 for up to 8 TE-classes. The DS-TE solution must allow these TE- 601 classes to comprise any arbitrary subset of 8 (or less) from the 602 (64) possible combinations of (8) Class-Types and (8) preemption 603 priorities. 605 3.5. Mapping of Traffic to LSPs 607 Le Faucheur et. al 11 609 Requirements for Diff-Serv-aware Traffic Engineering Feb 2002 611 The DS-TE solution must allow operation over E-LSPs onto which 612 traffic from a single OA is transported. 614 The DS-TE solution must allow operation over L-LSPs. 616 The DS-TE solution may allow operation over E-LSPs onto which 617 traffic from multiple OAs is transported, under the condition that 618 traffic from those OAs can effectively be treated by DS-TE as a 619 single atomic traffic trunk (in particular this means that traffic 620 from those multiple OAs is routed as a whole based on a single 621 collective bandwidth requirement, a single affinity attribute, a 622 single preemption level, a single Class-Type, ...). In that case, it 623 is also assumed that OAs are grouped together in a consistent manner 624 throughout the DS-TE domain (e.g. if OA1 and OA2 are transported 625 together on an E-LSP, then there will not be any L-LSP transporting 626 OA1 or OA2 on its own and there will not be any E-LSP transporting 627 OA1 or OA2 with another OA). 629 3.6. Dynamic Adjustment of Diff-Serv PHBs 631 As discussed in section 2.2, DS-TE may support adjustment of Diff- 632 Serv PHBs parameters (e.g. queue bandwidth) based on the amount of 633 TE-LSPs established for each Class/Class-Type. 635 Where this behavior is supported, it must allow for disabling via 636 configuration (thus reverting to PHB treatment with static scheduler 637 configuration independent of DS-TE operations). 639 The dynamic adjustment must take account of the performance 640 requirements of each class when computing required adjustments. 642 3.7. Overbooking 644 Existing TE mechanisms allow overbooking to be applied on LSPs for 645 Constraint Based Routing and admission control. Historically this 646 has been achieved in TE deployment through factoring overbooking 647 ratios at the time of sizing the LSP bandwidth and/or at the time of 648 configuring the Maximum Reservable Bandwidth on links. 650 DS-TE must also allow overbooking and must effectively allow 651 different overbooking ratios to be enforced for different CTs. 653 DS-TE should optionally allow the effective overbooking ratio of a 654 given CT to be tweaked differently in different parts of the 655 network. 657 3.8. Restoration 659 With existing TE, restoration policies use standard priority 660 mechanisms such as, for example, the preemption priority to 661 effectively control the order/importance of LSPs for restoration 662 purposes. 664 Le Faucheur et. al 12 666 Requirements for Diff-Serv-aware Traffic Engineering Feb 2002 668 DS-TE must ensure that similar application of the use of standard 669 priority mechanisms for implementation of restoration policy are not 670 prevented since those are expected to be required for achieving the 671 survivability requirements of DS-TE networks. 673 Further discussion of restoration requirements are presented in the 674 output document of the TEWG Requirements Design Team [SURVIV-REQ]. 676 4. Solution Evaluation Criteria 678 A range of solutions is possible for the support of the DS-TE 679 requirements discussed above. For example, some solutions may 680 require that all current TE protocols syntax (IGP, RSVP-TE, CR-LDP) 681 be extended in various ways. For instance, current TE protocols 682 could be modified to support multiple bandwidth constraints rather 683 than the existing single aggregate bandwidth constraint. 684 Alternatively, other solutions may keep the existing TE protocols 685 syntax unchanged but modify their semantic to allow for the multiple 686 bandwidth constraints. 688 This section identifies the evaluation criteria that should be used 689 to assess potential DS-TE solutions for selection. 691 4.1. Satisfying detailed requirements 693 The solution must address all the scenarios described in section 2 694 and satisfy all the requirements listed in section 3. 696 4.2. Flexibility 698 - number of Class Types that can be supported, compared to 699 number identified in Requirements section 700 - number of Classes within a Class-Type 702 4.3. Extendibility 704 - how far can the solution be extended in the future if 705 requirements for more Class-Types are identified in the 706 future. 708 4.4. Scalability 710 - impact on network scalability in what is propagated, 711 processed, stored and computed (IGP signaling, IGP 712 processing, IGP database, TE-Tunnel signaling ,...). 713 - how does scalability impact evolve with number of Class- 714 Types/Classes actually deployed in a network. In 715 particular, is it possible to keep overhead small for a 716 large networks which only use a small number of Class- 718 Le Faucheur et. al 13 720 Requirements for Diff-Serv-aware Traffic Engineering Feb 2002 722 Types/Classes, while allowing higher number of Class- 723 Types/Classes in smaller networks which can bear higher 724 overhead) 726 4.5. Backward compatibility/Migration 728 - backward compatibility/migration with/from existing TE 729 mechanisms 730 - backward compatibility/migration when 731 increasing/decreasing the number of Class-Types actually 732 deployed in a given network. 734 5. Security Considerations 736 The solution developed to address the requirements defined in this 737 document must address security aspects. DS-TE is not expected to add 738 specific security requirements beyond those of Diff-Serv and 739 existing TE. Networks which employ Diff-Serv techniques might offer 740 some protection between classes for denial of service attacks. 741 Though depending on how the technology is employed, it is possible 742 for some (lower scheduled) traffic to be more susceptible to traffic 743 anomalies (which include denial of service attacks) occurring within 744 other (higher scheduled) classes. 746 References 748 [AF] Heinanen, J et al., "Assured Forwarding PHB Group", RFC2597 750 [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", 751 RFC3212, January 2002 753 [DIFF-ARCH] Blake et al., "An Architecture for Differentiated 754 Services", RFC2475. 756 [DIFF-FIELD] Nichols et al., "Definition of the Differentiated 757 Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC2474. 759 [DIFF-MPLS] Le Faucheur et al, "MPLS Support of Diff-Serv", draft- 760 ietf-mpls-diff-ext-09.txt, April 2001 762 [DIFF-NEW] Grossman, "New Terminology for Diffserv", work in 763 progress, draft-ietf-diffserv-new-terms-08.txt, January 2002. 765 [DSTE-PROTO] Le Faucheur et al., "Protocol Extensions for support of 766 Diff-Serv-aware MPLS Traffic Engineering", draft-ietf-tewg-diff-te- 767 proto-00.txt, February 2002. 769 [EF] Davie et al., "An Expedited Forwarding PHB", work in progress, 770 draft-ietf-diffserv-ef-supplemental-01.txt, September 2001. 772 Le Faucheur et. al 14 774 Requirements for Diff-Serv-aware Traffic Engineering Feb 2002 776 [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft- 777 ietf-isis-traffic-04.txt, August 2001. 779 [OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF, 780 draft-katz-yeung-ospf-traffic-06.txt, October 2001. 782 [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 783 Tunnels", RFC 3209, December 2001. 785 [TEWG-FW] Awduche et al, Overview and Principles of Internet Traffic 786 Engineering, draft-ietf-tewg-principles-02.txt, November 2001. 788 [TE-REQ] Awduche et al, Requirements for Traffic Engineering over 789 MPLS, RFC2702, September 1999. 791 [SURVIV-REQ] W.S. Lai, D. McDysan, J. Boyle, M. Carlzon, R. Coltun, 792 T, Griffin, E. Kern, and T. Reddington, "Network Hierarchy and 793 Multilayer Survivability," work in progress, October 2001. 795 Authors' Address: 797 Francois Le Faucheur 798 Cisco Systems, Inc. 799 Village d'Entreprise Green Side - Batiment T3 800 400, Avenue de Roumanille 801 06410 Biot-Sophia Antipolis 802 France 803 Phone: +33 4 97 23 26 19 804 Email: flefauch@cisco.com 806 Martin Tatham 807 BT 808 Adastral Park, 809 Martlesham Heath, 810 Ipswich IP5 3RE 811 UK 812 Phone: +44-1473-606349 813 Email: martin.tatham@bt.com 815 Thomas Telkamp 816 Global Crossing 817 Olympia 6 818 1213 NP Hilversum 819 The Netherlands 820 Phone: +31 35 655 651 821 Email: telkamp@gblx.net 823 David Cooper 824 Global Crossing 825 960 Hamlin Court 827 Le Faucheur et. al 15 829 Requirements for Diff-Serv-aware Traffic Engineering Feb 2002 831 Sunnyvale, CA 94089 832 USA 833 Phone: (916) 415-0437 834 Email: dcooper@gblx.net 836 Jim Boyle 837 Protocol Driven Networks, Inc. 838 1381 Kildaire Farm Road #288 839 Cary, NC 27511 840 USA 841 Phone: (919) 852-5160 842 Email: jboyle@pdnets.com 844 Luyuan Fang 845 AT&T Labs 846 200 Laurel Avenue 847 Middletown, New Jersey 07748 848 Phone: (732) 420-1921 849 Email: luyuanfang@att.com 851 Gerald R. Ash 852 AT&T Labs 853 200 Laurel Avenue 854 Middletown, New Jersey 07748 855 Phone: (732) 420-4578 856 Email: gash@att.com 858 Wai Sum Lai 859 AT&T Labs 860 200 Laurel Avenue 861 Middletown, New Jersey 07748 862 Phone: (732) 420-3712 863 Email: wlai@att.com 865 Pete Hicks 866 CoreExpress, Inc 867 12655 Olive Blvd, Suite 500 868 St. Louis, MO 63141 869 Phone: (314) 317-7504 870 Email: pete.hicks@coreexpress.net 872 Angela Chiu 873 Celion Networks 874 1 Sheila Drive, Suite 2 875 Tinton Falls, NJ 07724 876 Phone: (732) 747-9987 877 Email: angela.chiu@celion.com 879 William Townsend 880 Tenor Networks 881 100 Nagog Park 882 Acton, MA 01720 884 Le Faucheur et. al 16 886 Requirements for Diff-Serv-aware Traffic Engineering Feb 2002 888 Phone: +1 978-264-4900 889 Email: btownsend@tenornetworks.com 891 Thomas D. Nadeau 892 Cisco Systems, Inc. 893 250 Apollo Drive 894 Chelmsford, MA 01824 895 Phone: (978) 244-3051 896 Email: tnadeau@cisco.com 898 Darek Skalecki 899 Nortel Networks 900 3500 Carling Ave, 901 Nepean K2H 8E9 902 Phone: (613) 765-2252 903 Email: dareks@nortelnetworks.com 905 Le Faucheur et. al 17