idnits 2.17.1 draft-ietf-tewg-diff-te-reqts-05.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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 373 has weird spacing: '...rned by a spe...' == Line 723 has weird spacing: '... of the use o...' == Line 765 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) == Missing Reference: 'BC-MODEL' is mentioned on line 516, 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') == 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 ** Obsolete normative reference: RFC 3272 (ref. 'TEWG-FW') (Obsoleted by RFC 9522) ** Downref: Normative reference to an Informational RFC: RFC 2702 (ref. 'TE-REQ') -- Possible downref: Non-RFC (?) normative reference: ref. 'SURVIV-REQ' Summary: 11 errors (**), 0 flaws (~~), 8 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: December, 2002 35 Document: draft-ietf-tewg-diff-te-reqts-05.txt June 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 EngineeringJune 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. Specification for this solution itself is outside the 70 scope of this document. 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 EngineeringJune 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 In the context of the present document, "flows of the same class" is 153 to be interpreted as "flows from the same Forwarding Equivalence 154 Class which are to be treated equivalently from the DS-TE 155 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 EngineeringJune 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 traffic forming 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 EngineeringJune 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 EngineeringJune 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 EngineeringJune 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 We refine 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 Mapping of OAs to Class-Types is flexible. Different OAs can be 383 mapped to different CTs, multiple OAs can be mapped to the same CT 384 and one OA can be mapped to multiple CTs. 386 Le Faucheur et. al 7 388 Requirements for Diff-Serv-aware Traffic EngineeringJune 2002 390 For illustration purposes, let's consider the case of a network 391 running 4 Diff-Serv classes of services respectively based on the EF 392 PHB [EF], the AF1x PSC [AF], the AF2x PSC and the Default (i.e. 393 Best-Effort) PHB [DIFF-FIELD]. The network administrator may decide 394 to deploy DS-TE in the following way: 395 o from every DS-TE Head-end to every DS-TE Tail-end, split 396 traffic into 4 Traffic Trunks: one for traffic of each Diff- 397 Serv class 398 o because the QoS objectives for the AF1x Traffic Trunks and 399 for the AF2x Traffic Trunks may be of similar nature (e.g. 400 both targeting low loss albeit at different levels perhaps), 401 the same (set of) Bandwidth Constraint(s) may be applied 402 collectively over the AF1x Traffic Trunks and the AF2x 403 Traffic Trunks. Thus, the network administrator may only 404 define three CTs: one for the EF Traffic Trunks, one for the 405 AF1x and AF2x Traffic Trunks and one for the Best Effort 406 Traffic Trunks. 408 As another example of mapping of OAs to CTs, a network operator may 409 split the EF traffic into two different sets of traffic trunks, so 410 that each set of traffic trunks is subject to different constraints 411 on the bandwidth it can access. In this case, two distinct CTs are 412 defined for EF: one for the EF traffic subject to the first (set of) 413 bandwidth constraint(s), the other for the EF traffic subject to the 414 second (set of) bandwidth constraint(s). 416 DS-TE must support at least 2 CTs and up to 8 CTs. Those are 417 referred to as CTc, 0 <= c <= MaxCT-1 = 7. 419 In a given network, DS-TE must not require the network administrator 420 to always deploy the maximum number of CTs. The network 421 administrator must be able to deploy only the number of CTs actually 422 utilized. 424 3.3. Bandwidth Constraints 426 We refer to a Bandwidth Constraint Model as the set of rules 427 defining: 428 - the maximum number of Bandwidth Constraints; and 429 - which CTs each Bandwidth Constraint applies to and how. 431 By definition of CT, each CT is assigned either a Bandwidth 432 Constraint, or a set of Bandwidth Constraints. 434 We refer to the Bandwidth Constraints as BCb, 0 <= b <= MaxBC-1 436 Different models of Bandwidth Constraints are conceivable for 437 control of the CTs. 439 For example, a model with one separate Bandwidth Constraint per CT 440 could be defined. This model is defined by: 441 - MaxBC= MaxCT 443 Le Faucheur et. al 8 445 Requirements for Diff-Serv-aware Traffic EngineeringJune 2002 447 - All LSPs supporting Traffic Trunks from CTc use no more than BCc 449 For illustration purposes, on a link of 100 unit of bandwidth where 450 three CTs are used, the network administrator might then configure 451 BC0=30, BC1= 50, BC2=20 such that: 452 - All LSPs supporting Traffic Trunks from CT0 use no more than 30 453 (e.g. Voice <= 30) 454 - All LSPs supporting Traffic Trunks from CT1 use no more than 50 455 (e.g. Premium Data <= 50) 456 - All LSPs supporting Traffic Trunks from CT2 use no more than 20 457 (e.g. Best Effort <= 20) 459 As another example, a "Russian Doll" model of Bandwidth Constraints 460 may be defined whereby: 461 - MaxBC= MaxCT 462 - All LSPs supporting Traffic Trunks from CTc (with b<=c<=7) use no 463 more than BCb 465 For illustration purposes, on a link of 100 units of bandwidth where 466 three CTs are used, the network administrator might then configure 467 BC0=100, BC1= 80, BC2=60 such that: 468 - All LSPs supporting Traffic Trunks from CT2 use no more than 60 469 (e.g. Voice <= 60) 470 - All LSPs supporting Traffic Trunks from CT1 or CT2 use no more 471 than 80 (e.g. Voice + Premium Data <= 80) 472 - All LSPs supporting Traffic Trunks from CT0 or CT1 or CT2 use no 473 more than 100 (e.g. Voice + Premium Data + Best Effort <= 100). 475 Other Bandwidth Constraints model can also be conceived. Those could 476 involve arbitrary relationships between BCb and CTc. Those could 477 also involve additional concepts such as associating minimum 478 reservable bandwidth to a CT. 480 At the time of writing this document, it is not clear whether a 481 single model of Bandwidth Constraints is sufficient, which one it 482 should be and how flexible this model really needs to be and what 483 are the implications on the DS-TE technical solution and its 484 implementations. Work is currently in progress to investigate the 485 performance and trade-offs of different operational aspects of 486 Bandwidth Constraints models. The DS-TE technical solution must 487 specify one default bandwidth constraint model which must be 488 supported by any DS-TE implementation. However, additional bandwidth 489 constraint models may also be specified. The purpose of such a 490 default model is to ensure that there is at least one common 491 Bandwidth Constraints model implementation across various vendors 492 equipment and allows for easier deployment of DS-TE. However, this 493 does not preclude a network operator to activate different Bandwidth 494 Constraints models on different links in a network, if he/she wishes 495 to do so. 497 In the selection of a default model, at least the following criteria 498 are expected to be considered: 500 Le Faucheur et. al 9 502 Requirements for Diff-Serv-aware Traffic EngineeringJune 2002 504 (1) addresses the scenarios in Section 2 505 (2) works well under both normal and overload conditions 506 (3) applies equally when preemption is either enabled or disabled 507 (4) minimizes signaling load processing requirements 508 (5) maximizes efficient use of the network 510 In selection criteria (2), "normal condition" means that the network 511 is attempting to establish a volume of DS-TE LSPs for which it is 512 designed; "overload condition" means that the network is attempting 513 to establish a volume of DS-TE LSPs beyond the one it is designed 514 for; "works well" means that under these conditions, the network 515 should be able to sustain the expected performance, e.g., under 516 overload it is x times worse than its normal performance [BC-MODEL]. 518 These selection criteria will be further discussed and refined as 519 part of the ongoing work on BC model selection. In particular, the 520 applicability of criterion (5) needs to be qualified. 522 Regardless of the Bandwidth Constraint Model, the DS-TE solution 523 must allow support for up to 8 BCs. 525 3.4. Preemption and TE-Classes 527 [TEWG-FW] defines the notion of preemption and preemption priority. 528 DS-TE must retain full support of such preemption. However, a 529 network administrator preferring not to use preemption for user 530 traffic should be able to disable the preemption mechanisms 531 described below. 533 The preemption attributes defined in [TE-REQ] must be retained and 534 applicable across all Class Types. The preemption attributes of 535 setup priority and holding priority must retain existing semantics, 536 and in particular these semantics must not be affected by the 537 Ordered Aggregate transported by the LSP or by the LSP's Class Type. 538 This means that if LSP1 contends with LSP2 for resources, LSP1 may 539 preempt LSP2 if LSP1 has a higher set-up preemption priority (i.e. 540 lower numerical priority value) than LSP2's holding preemption 541 priority regardless of LSP1's OA/CT and LSP2's OA/CT. 543 We introduce the following definition: 545 TE-Class: A pair of: 546 (i) a Class-Type 547 (ii) a preemption priority allowed for that Class- 548 Type. This means that an LSP transporting a 549 Traffic Trunk from that Class-Type can use that 550 preemption priority as the set-up priority, as 551 the holding priority or both. 553 Note that by definition: 554 - for a given Class-Type, there may be one or multiple TE-classes 555 using that Class-Type, each using a different preemption priority 557 Le Faucheur et. al 10 559 Requirements for Diff-Serv-aware Traffic EngineeringJune 2002 561 - for a given preemption priority, there may be one or multiple TE- 562 Class(es) using that preemption priority, each using a different 563 Class-Type. 565 DS-TE must allow all LSPs transporting Traffic Trunks of a given 566 Class-Type to use the same preemption priority. In other words, DS- 567 TE must allow a Class-Type to be used by single TE-Class. This 568 effectively allows the network administrator to ensure that no 569 preemption happens within that Class-Type, when so desired. 571 As an example, the DS-TE solution must allow the network 572 administrator to define a Class-Type comprising a single TE-class 573 using preemption 0. 575 DS-TE must allow two LSPs transporting Traffic Trunks of the same 576 Class-Type to use different preemption priorities, and allow the LSP 577 with higher (numerically lower) set-up priority to preempt the LSP 578 with lower (numerically higher) holding priority when they contend 579 for resources. In other words, DS-TE must allow multiple TE-Classes 580 to be defined for a given Class-Type. This effectively allows the 581 network administrator to enable preemption within a Class-Type, when 582 so desired. 584 As an example, the DS-TE solution must allow the network 585 administrator to define a Class-Type comprising three TE-Classes; 586 one using preemption 0, one using preemption 1 and one using 587 preemption 4. 589 DS-TE must allow two LSPs transporting Traffic Trunks from different 590 Class-Types to use different preemption priorities, and allow the 591 LSP with higher setup priority to preempt the one with lower holding 592 priority when they contend for resources. 594 As an example, the DS-TE solution must allow the network 595 administrator to define two Class-Types (CT0 and CT1) each 596 comprising two TE-Classes where say: 597 -one TE-Class groups CT0 and preemption 0 598 -one TE-Class groups CT0 and preemption 2 599 -one TE-Class groups CT1 and preemption 1 600 -one TE-Class groups CT1 and preemption 3 602 The network administrator would then, in particular, be able to : 603 - transport a CT0 Traffic Trunk over an LSP with setup priority=0 604 and holding priority=0 605 - transport a CT0 Traffic Trunk over an LSP with setup priority=2 606 and holding priority=0 607 - transport a CT1 Traffic Trunk over an LSP with setup priority=1 608 and holding priority=1 609 - transport a CT1 Traffic Trunk over an LSP with setup priority=3 610 and holding priority=1. 612 Le Faucheur et. al 11 614 Requirements for Diff-Serv-aware Traffic EngineeringJune 2002 616 The network administrator would then, in particular, NOT be able 617 to : 618 - transport a CT0 Traffic Trunk over an LSP with setup priority=1 619 and holding priority=1 620 - transport a CT1 Traffic Trunk over an LSP with setup priority=0 621 and holding priority=0 623 DS-TE must allow two LSPs transporting Traffic Trunks from different 624 Class-Types to use the same preemption priority. In other words, the 625 DS-TE solution must allow TE-classes using different CTs to use the 626 same preemption priority. This effectively allows the network 627 administrator to ensure that no preemption happens across Class- 628 Types, if so desired. 630 As an example, the DS-TE solution must allow the network 631 administrator to define three Class-Types (CT0, CT1 and CT2) each 632 comprising one TE-Class which uses preemption 0. In that case, no 633 preemption will ever occur. 635 Since there are 8 preemption priorities and up to 8 Class-Types, 636 there could theoretically be up to 64 TE-Classes in a network. This 637 is felt to be beyond current practical requirements. The current 638 practical requirement is that the DS-TE solution must allow support 639 for up to 8 TE-classes. The DS-TE solution must allow these TE- 640 classes to comprise any arbitrary subset of 8 (or less) from the 641 (64) possible combinations of (8) Class-Types and (8) preemption 642 priorities. 644 As with existing TE, an LSP which gets preempted is torn down at 645 preemption time. The Head-end of the preempted LSP may then attempt 646 to reestablish that LSP, which involves recomputing a path by 647 Constraint Based Routing based on updated available bandwidth 648 information and then signaling for LSP establishment along the new 649 path. It must be noted that there may be cases where the preempted 650 LSP cannot be reestablished (e.g. no possible path satisfying LSP 651 bandwidth constraints as well as other constraints). In such cases, 652 the Head-end behavior is left to implementation. It may involve 653 periodic attempts at reestablishing the LSP, relaxing of the LSP 654 constraints, or other behaviors. 656 3.5. Mapping of Traffic to LSPs 658 The DS-TE solution must allow operation over E-LSPs onto which 659 traffic from a single OA is transported. 661 The DS-TE solution must allow operation over L-LSPs. 663 The DS-TE solution may allow operation over E-LSPs onto which 664 traffic from multiple OAs is transported, under the condition that 665 traffic from those OAs can effectively be treated by DS-TE as a 666 single atomic traffic trunk (in particular this means that traffic 667 from those multiple OAs is routed as a whole based on a single 669 Le Faucheur et. al 12 671 Requirements for Diff-Serv-aware Traffic EngineeringJune 2002 673 collective bandwidth requirement, a single affinity attribute, a 674 single preemption level, a single Class-Type, ...). In that case, it 675 is also assumed that OAs are grouped together in a consistent manner 676 throughout the DS-TE domain (e.g. if OA1 and OA2 are transported 677 together on an E-LSP, then there will not be any L-LSP transporting 678 OA1 or OA2 on its own and there will not be any E-LSP transporting 679 OA1 or OA2 with another OA). 681 3.6. Dynamic Adjustment of Diff-Serv PHBs 683 As discussed in section 2.2, DS-TE may support adjustment of Diff- 684 Serv PHBs parameters (e.g. queue bandwidth) based on the amount of 685 TE-LSPs established for each OA/Class-Type. Such dynamic adjustment 686 is optional. It is a local matter to the LSR and as such is outside 687 the scope of this specification. 689 Where this dynamic adjustment is supported, it must allow for 690 disabling via configuration (thus reverting to PHB treatment with 691 static scheduler configuration independent of DS-TE operations). It 692 may involve a number of configurable parameters which are outside 693 the scope of this specification. Those may include configurable 694 parameters controlling how scheduling resources (e.g. service rates) 695 need to be apportioned across multiple OAs when those belong to the 696 same Class-Type and are transported together on the same E-LSP. 698 The dynamic adjustment must take account of the performance 699 requirements of each class when computing required adjustments. 701 3.7. Overbooking 703 Existing TE mechanisms allow overbooking to be applied on LSPs for 704 Constraint Based Routing and admission control. Historically this 705 has been achieved in TE deployment through factoring overbooking 706 ratios at the time of sizing the LSP bandwidth and/or at the time of 707 configuring the Maximum Reservable Bandwidth on links. 709 DS-TE must also allow overbooking and must effectively allow 710 different overbooking ratios to be enforced for different CTs. 712 DS-TE should optionally allow the effective overbooking ratio of a 713 given CT to be tweaked differently in different parts of the 714 network. 716 3.8. Restoration 718 With existing TE, restoration policies use standard priority 719 mechanisms such as, for example, the preemption priority to 720 effectively control the order/importance of LSPs for restoration 721 purposes. 723 DS-TE must ensure that similar application of the use of standard 724 priority mechanisms for implementation of restoration policy are not 726 Le Faucheur et. al 13 728 Requirements for Diff-Serv-aware Traffic EngineeringJune 2002 730 prevented since those are expected to be required for achieving the 731 survivability requirements of DS-TE networks. 733 Further discussion of restoration requirements are presented in the 734 output document of the TEWG Requirements Design Team [SURVIV-REQ]. 736 4. Solution Evaluation Criteria 738 A range of solutions is possible for the support of the DS-TE 739 requirements discussed above. For example, some solutions may 740 require that all current TE protocols syntax (IGP, RSVP-TE, CR-LDP) 741 be extended in various ways. For instance, current TE protocols 742 could be modified to support multiple bandwidth constraints rather 743 than the existing single aggregate bandwidth constraint. 744 Alternatively, other solutions may keep the existing TE protocols 745 syntax unchanged but modify their semantic to allow for the multiple 746 bandwidth constraints. 748 This section identifies the evaluation criteria that should be used 749 to assess potential DS-TE solutions for selection. 751 4.1. Satisfying detailed requirements 753 The solution must address all the scenarios described in section 2 754 and satisfy all the requirements listed in section 3. 756 4.2. Flexibility 758 - number of Class Types that can be supported, compared to 759 number identified in Requirements section 760 - number of Classes within a Class-Type 762 4.3. Extendibility 764 - how far can the solution be extended in the future if 765 requirements for more Class-Types are identified in the 766 future. 768 4.4. Scalability 770 - impact on network scalability in what is propagated, 771 processed, stored and computed (IGP signaling, IGP 772 processing, IGP database, TE-Tunnel signaling ,...). 773 - how does scalability impact evolve with number of Class- 774 Types/Classes actually deployed in a network. In 775 particular, is it possible to keep overhead small for a 776 large networks which only use a small number of Class- 777 Types/Classes, while allowing higher number of Class- 778 Types/Classes in smaller networks which can bear higher 779 overhead) 781 Le Faucheur et. al 14 783 Requirements for Diff-Serv-aware Traffic EngineeringJune 2002 785 4.5. Backward compatibility/Migration 787 - backward compatibility/migration with/from existing TE 788 mechanisms 789 - backward compatibility/migration when 790 increasing/decreasing the number of Class-Types actually 791 deployed in a given network. 793 5. Security Considerations 795 The solution developed to address the requirements defined in this 796 document must address security aspects. DS-TE is not expected to add 797 specific security requirements beyond those of Diff-Serv and 798 existing TE. Networks which employ Diff-Serv techniques might offer 799 some protection between classes for denial of service attacks. 800 Though depending on how the technology is employed, it is possible 801 for some (lower scheduled) traffic to be more susceptible to traffic 802 anomalies (which include denial of service attacks) occurring within 803 other (higher scheduled) classes. 805 References 807 [AF] Heinanen, J et al., "Assured Forwarding PHB Group", RFC2597 809 [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", 810 RFC3212, January 2002 812 [DIFF-ARCH] Blake et al., "An Architecture for Differentiated 813 Services", RFC2475. 815 [DIFF-FIELD] Nichols et al., "Definition of the Differentiated 816 Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC2474. 818 [DIFF-MPLS] Le Faucheur et al, "Multi-Protocol Label Switching 819 (MPLS) Support of Differentiated Services", RFC3270, May 2002. 821 [DIFF-NEW] Grossman, " New Terminology and Clarifications for 822 Diffserv ", RFC3260, April 2002. 824 [EF] Davie et al., "An Expedited Forwarding PHB (Per-Hop Behavior)", 825 RFC3246, March 2002. 827 [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft- 828 ietf-isis-traffic-04.txt, August 2001. 830 [OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF, 831 draft-katz-yeung-ospf-traffic-06.txt, October 2001. 833 Le Faucheur et. al 15 835 Requirements for Diff-Serv-aware Traffic EngineeringJune 2002 837 [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 838 Tunnels", RFC 3209, December 2001. 840 [TEWG-FW] Awduche et al, Overview and Principles of Internet Traffic 841 Engineering, RFC3272, May 2002. 843 [TE-REQ] Awduche et al, Requirements for Traffic Engineering over 844 MPLS, RFC2702, September 1999. 846 [SURVIV-REQ] W.S. Lai, D. McDysan, J. Boyle, M. Carlzon, R. Coltun, 847 T, Griffin, E. Kern, and T. Reddington, "Network Hierarchy and 848 Multilayer Survivability," work in progress, October 2001. 850 Authors' Address: 852 Francois Le Faucheur 853 Cisco Systems, Inc. 854 Village d'Entreprise Green Side - Batiment T3 855 400, Avenue de Roumanille 856 06410 Biot-Sophia Antipolis 857 France 858 Phone: +33 4 97 23 26 19 859 Email: flefauch@cisco.com 861 Martin Tatham 862 BT 863 Adastral Park, 864 Martlesham Heath, 865 Ipswich IP5 3RE 866 UK 867 Phone: +44-1473-606349 868 Email: martin.tatham@bt.com 870 Thomas Telkamp 871 Global Crossing 872 Olympia 6 873 1213 NP Hilversum 874 The Netherlands 875 Phone: +31 35 655 651 876 Email: telkamp@gblx.net 878 David Cooper 879 Global Crossing 880 960 Hamlin Court 881 Sunnyvale, CA 94089 882 USA 883 Phone: (916) 415-0437 884 Email: dcooper@gblx.net 886 Jim Boyle 888 Le Faucheur et. al 16 890 Requirements for Diff-Serv-aware Traffic EngineeringJune 2002 892 Protocol Driven Networks, Inc. 893 1381 Kildaire Farm Road #288 894 Cary, NC 27511 895 USA 896 Phone: (919) 852-5160 897 Email: jboyle@pdnets.com 899 Luyuan Fang 900 AT&T Labs 901 200 Laurel Avenue 902 Middletown, New Jersey 07748 903 Phone: (732) 420-1921 904 Email: luyuanfang@att.com 906 Gerald R. Ash 907 AT&T Labs 908 200 Laurel Avenue 909 Middletown, New Jersey 07748 910 Phone: (732) 420-4578 911 Email: gash@att.com 913 Wai Sum Lai 914 AT&T Labs 915 200 Laurel Avenue 916 Middletown, New Jersey 07748 917 Phone: (732) 420-3712 918 Email: wlai@att.com 920 Pete Hicks 921 CoreExpress, Inc 922 12655 Olive Blvd, Suite 500 923 St. Louis, MO 63141 924 Phone: (314) 317-7504 925 Email: pete.hicks@coreexpress.net 927 Angela Chiu 928 Celion Networks 929 1 Sheila Drive, Suite 2 930 Tinton Falls, NJ 07724 931 Phone: (732) 747-9987 932 Email: angela.chiu@celion.com 934 William Townsend 935 Tenor Networks 936 100 Nagog Park 937 Acton, MA 01720 938 Phone: +1 978-264-4900 939 Email: btownsend@tenornetworks.com 941 Thomas D. Nadeau 942 Cisco Systems, Inc. 943 250 Apollo Drive 945 Le Faucheur et. al 17 947 Requirements for Diff-Serv-aware Traffic EngineeringJune 2002 949 Chelmsford, MA 01824 950 Phone: (978) 244-3051 951 Email: tnadeau@cisco.com 953 Darek Skalecki 954 Nortel Networks 955 3500 Carling Ave, 956 Nepean K2H 8E9 957 Phone: (613) 765-2252 958 Email: dareks@nortelnetworks.com 960 Le Faucheur et. al 18