idnits 2.17.1 draft-ietf-tewg-diff-te-reqts-02.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. == 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 925 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 ([TEWG-FW]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 527 has weird spacing: '... of the use o...' == Line 568 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: 'DIFF-ARCH' is mentioned on line 115, but not defined == Unused Reference: 'AF' is defined on line 610, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-mpls-cr-ldp-05 == Outdated reference: A later version (-08) exists of draft-ietf-diffserv-new-terms-04 ** Downref: Normative reference to an Informational draft: draft-ietf-diffserv-new-terms (ref. 'DIFF-NEW') == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-02 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'ISIS-TE') == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-04 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-rsvp-lsp-tunnel-08 == Outdated reference: A later version (-05) exists of draft-ietf-tewg-framework-04 ** Downref: Normative reference to an Informational draft: draft-ietf-tewg-framework (ref. 'TEWG-FW') ** Downref: Normative reference to an Informational RFC: RFC 2702 (ref. 'TE-REQ') -- Possible downref: Non-RFC (?) normative reference: ref. 'SURVIV-REQ' Summary: 10 errors (**), 0 flaws (~~), 12 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: May, 2002 35 Document: draft-ietf-tewg-diff-te-reqts-02.txt November, 2001 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 Traffic EngineeringNovember 2001 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) as discussed in 66 the Traffic Engineering Working Group Framework document [TEWG-FW]. 68 1. Introduction 70 1.1. Problem Statement 72 Diff-Serv is becoming prominent in providing scalable network 73 designs supporting multiple classes of services. 75 In some Diff-Serv networks where optimization of transmission 76 resources on a network-wide basis is not sought, MPLS Traffic 77 Engineering (TE) mechanisms may simply not be used. 79 In other networks, where optimization of transmission resources is 80 sought, Diff-Serv mechanisms [DIFF-MPLS] need to be complemented by 81 existing MPLS Traffic Engineering mechanisms [TE-REQ] [ISIS-TE] 82 [OSPF-TE] [RSVP-TE] [CR-LDP] which operate on an aggregate basis 83 across all classes of service. In this case, Diff-Serv and MPLS TE 84 both provide their respective benefits. 86 Where fine-grained optimization of transmission resources is sought, 87 it is necessary to perform traffic engineering at a per-class level 88 instead of an aggregate level, in order to further enhance networks 89 in performance and efficiency as discussed in [TEWG-FW]. By mapping 90 the traffic from a given class of service on a separate LSP, it 91 allows this traffic to utilize resources available to the given 92 class on both shortest path and non-shortest paths and follow paths 93 that meet engineering constraints which are specific to the given 94 class. This is what we refer to as "Diff-Serv-aware Traffic 95 Engineering (DS-TE)". 97 This document focuses exclusively on the specific environments which 98 would benefit from DS-TE. Some examples include: 100 - networks where bandwidth is scarce (e.g. transcontinental 101 networks) 102 - networks with significant amounts of delay-sensitive traffic 103 - networks where the relative proportion of traffic across 104 classes of service is not uniform 106 Le Faucheur et. al 2 108 Requirements for Diff-Serv Traffic EngineeringNovember 2001 110 This document focuses on intra-domain operation. Inter-domain 111 operation is not considered. 113 1.2. Definitions 115 For the convenience of the reader, relevant Diffserv ([DIFF-ARCH], 116 [DIFF-NEW]) definitions are repeated herein. 118 Behavior Aggregate (BA): a collection of packets with the same 119 codepoint crossing a link in a particular direction. 121 PHB Scheduling Class (PSC): A PHB group for which a common 122 constraint is that ordering of at least those packets belonging 123 to the same microflow must be preserved. 125 Ordered Aggregate (OA): a set of BAs that share an ordering 126 constraint. The set of PHBs that are applied to this set of 127 Behavior Aggregates constitutes a PHB scheduling class. 129 We also repeat the following definition from [TE-REQ]: 131 Traffic Trunk: an aggregation of traffic flows of the same class 132 which are placed inside a Label Switched Path. 133 [Note: in the context of the present document, "flows of the 134 same class" is to be interpreted as "flows from the same 135 Forwarding Equivalence Class which are to be treated 136 equivalently from the DS-TE perspective".] 138 1.3. Mapping of traffic to LSPs 140 A network may have multiple classes of traffic it wishes to service. 141 Recalling from [DIFF-MPLS], there are several options on how the 142 Diff-Serv Ordered Aggregates (OAs) can be split into multiple 143 Traffic Trunks for mapping onto LSPs when using DSTE. 145 One option is to split traffic into Traffic Trunks which each 146 comprises traffic from multiple OAs. This option is typically used 147 when aggregate traffic engineering is deployed using current MPLS TE 148 mechanisms. Note that this LSP is then, by definition, an E-LSP as 149 defined in [DIFF-MPLS]. 151 Another option is to split traffic into Traffic Trunks which each 152 comprises traffic from a single OA. DS-TE assumes this mode of 153 operation. Note that the LSP used to transport such a Traffic Trunk 154 may then be an L-LSP (as defined in [DIFF-MPLS]) or may be an E-LSP 155 onto which a single (or a subset of the) OA is transported. Thus, 156 traffic from a given node to another given node, is split into 157 multiple Traffic Trunks which are transported over separate LSPs, 158 which can potentially follow a different path through the network. 159 DS-TE precisely takes advantage of this fact and indeed computes a 160 separate path for each LSP. In so doing, DS-TE can take into account 162 Le Faucheur et. al 3 164 Requirements for Diff-Serv Traffic EngineeringNovember 2001 166 the specific requirements of the Traffic Trunk transported on each 167 LSP (e.g. bandwidth requirement, preemption priority). Moreover DS- 168 TE can take into account the specific resources which have been 169 allocated inside the network to different sets of Traffic Trunks 170 (e.g. PHB resources allocated to be used by all the Traffic Trunks 171 of a given OA) and specific engineering constraints to be enforced 172 for these sets of Traffic Trunks (e.g. limit all Traffic Trunks from 173 a given OA to x% of link capacity). In brief, DS-TE achieves per LSP 174 constraint based routing with paths that tightly match the specific 175 objectives of each Traffic Trunk and of each OA to whom the traffic 176 Trunk belongs. 178 2. Application Scenarios 180 2.1. Scenario 1: Limiting Proportion of Classes on a Link 182 An IP/MPLS network may need to carry a significant amount of VoIP 183 traffic compared to its link capacity. For example, 10,000 184 uncompressed calls at 20ms packetization result in about 1Gbps of IP 185 traffic, which is significant on an OC-48c based network. In case of 186 topology changes such as link/node failure, VoIP traffic levels can 187 even approach the full bandwidth on certain links. 189 For delay/jitter reasons it is undesirable to carry more than a 190 certain percentage of VoIP traffic on any link. The rest of the 191 available link bandwidth can be used to route other classes 192 corresponding to delay/jitter insensitive traffic (e.g. Best Effort 193 Internet traffic). The exact determination of this "certain" 194 percentage is outside the scope of this requirements draft. 196 During normal operations, the VoIP traffic should be able to preempt 197 other classes of traffic (if these other classes are designated as 198 preemptable and they have lower preemption priority), 199 so that it will be able to use the shortest available path, only 200 constrained by the maximum defined link utilization ratio/percentage 201 of the VoIP class. 203 Existing TE mechanisms only allow constraint based routing of 204 traffic based on a single bandwidth constraint common to all 205 classes, which does not satisfy the needs described here. This leads 206 to the requirement for DS-TE to be able to enforce a different 207 bandwidth constraint for different classes of traffic. In the above 208 example, the bandwidth constraint to be enforced for VoIP traffic 209 may be the "certain" percentage of each link capacity, while the 210 bandwidth constraint to be enforced for the rest of the classes 211 might have their own constraints or have access to the rest of the 212 link capacity. 214 2.2. Scenario 2: Maintain relative proportion of traffic classes 216 Le Faucheur et. al 4 218 Requirements for Diff-Serv Traffic EngineeringNovember 2001 220 Suppose an IP/MPLS network supports 3 classes of traffic. The 221 network administrator wants to perform Traffic Engineering to 222 distribute the traffic load. Assume also that proportion across 223 traffic classes varies significantly depending on the 224 source/destination POPs. 226 With existing TE mechanisms, the proportion of traffic from each 227 class on a given link will vary depending on multiple factors 228 including: 229 - in which order the different TE-LSPs are routed 230 - the preemption priority associated with the different TE-LSPs 231 - link/node failure situations 233 This may make it difficult or impossible for the network 234 administrator to configure the Diff-Serv PHBs (e.g. queue bandwidth) 235 to ensure that each traffic class gets the appropriate treatment. 236 This leads again to the requirement for DS-TE to be able to enforce 237 a different bandwidth constraint for different classes of traffic. 238 This could be used to ensure that, regardless of the order in which 239 tunnels are routed, regardless of their preemption priority and 240 regardless of the failure situation, the amount of traffic of each 241 class routed over a link matches the Diff-Serv scheduler 242 configuration on that link for the corresponding class (e.g. queue 243 bandwidth). 245 As an illustration of how DS-TE would address this scenario, the 246 network administrator may configure the service rate of Diff-Serv 247 queues to (45%,35%,20%) for classes (1,2,3) respectively. The 248 administrator would then split the traffic into separate Traffic 249 Trunks for each class and associate a bandwidth to each LSP 250 transporting those Traffic Trunks. The network administrator may 251 also want to configure preemption priorities of each LSP in order to 252 give highest restoration priority to the highest priority class and 253 medium priority to the medium class. Then DS-TE could ensure that 254 after a failure, class 1 traffic would be rerouted with first access 255 at link capacity but without exceeding its service rate of 45% of 256 the link bandwidth. Class 2 traffic would be rerouted with second 257 access at the link capacity but without exceeding its allotment. 258 Note that where class 3 is the Best-Effort service, the requirement 259 on DS-TE may be to ensure that the total amount of traffic routed 260 across all classes does not exceed the total link capacity of 100% 261 (as opposed to separately limiting the amount of Best Effort traffic 262 to 20 even if there was little class 1 and class 2 traffic). 264 In this scenario, DS-TE allowed for the maintenance of a more steady 265 distribution of classes, even during rerouting. This relied on the 266 required capability of DS-TE to adjust the amount of traffic of each 267 class routed on a link based on the configuration of the scheduler 268 and the amount of bandwidth available for each class. 270 Alternatively, some network administrators may want to solve the 271 problem by having the scheduler dynamically adjusted based on the 273 Le Faucheur et. al 5 275 Requirements for Diff-Serv Traffic EngineeringNovember 2001 277 amount of bandwidth of the LSPs admitted for each class. This is an 278 additional requirement on DS-TE. 280 2.3. Scenario 3: Guaranteed Bandwidth Services 282 In addition to the Best effort service, an IP/MPLS network operator 283 may desire to offer a point-to-point "guaranteed bandwidth" service 284 whereby the provider pledges to provide a given level of performance 285 (bandwidth/delay/loss...) end-to-end through its network from an 286 ingress port to and egress port. The goal is to ensure all 287 "guaranteed" traffic within a subscribed traffic contract, will be 288 delivered within stated tolerances. 290 One approach for deploying such "guaranteed" service involves: 291 - dedicating a Diff-Serv PHB (or a Diff-Serv PSC as defined in 292 [DIFF-NEW]) to the "guaranteed" traffic 293 - policing guaranteed traffic on ingress against the traffic 294 contract and marking the "guaranteed" packets with the 295 corresponding DSCP/EXP value 297 Where very high level of performance is targeted for the 298 "guaranteed" service, it may be necessary to ensure that the amount 299 of "guaranteed" traffic remains below a given percentage of link 300 capacity on every link. Where the proportion of "guaranteed" traffic 301 is high, constraint based routing can be used to enforce such a 302 constraint. 304 However, the network operator may also want to simultaneously 305 perform Traffic Engineering of the rest of the traffic (i.e. non- 306 guaranteed traffic) which would require that constraint based 307 routing is also capable of enforcing a differnet bandwidth 308 constraint, which would be less stringent than the one for 309 guaranteed traffic. 311 Again, this combination of requirements can not be addressed with 312 existing TE mechanisms. DS-TE mechanisms allowing enforcement of a 313 different bandwidth constraint for guaranteed traffic and for non- 314 guaranteed traffic are required. 316 3. Detailed Requirements for DS-TE 318 This section specifies the functionality that the above scenarios 319 require out of DS-TE implementations. Actual technical protocol 320 mechanisms and procedures to achieve such functionality are outside 321 the scope of this document. 323 3.1. DS-TE Compatibility 325 While DS-TE is required in a number of situations such as the ones 326 described above, it is important to keep in mind that using DS-TE 327 may impact scalability (as discussed later in this document) and 329 Le Faucheur et. al 6 331 Requirements for Diff-Serv Traffic EngineeringNovember 2001 333 operational practices. DS-TE should only be used when existing TE 334 mechanisms combined with Diff-Serv cannot address the network design 335 requirements. Many network operators may choose to not use DS-TE, or 336 to only use it in a limited scope within their network. 338 Thus, the DS-TE solution must be developed in such a way that: 340 (i) it raises no interoperability issues with existing deployed 341 TE mechanisms. 342 (ii) it allows DS-TE deployment to the required level of 343 granularity and scope (e.g. only in a subset of the 344 topology, or only for the number of classes required in the 345 considered network) 347 3.2. Class-Types 349 The fundamental requirement for DS-TE is to be able to enforce 350 different bandwidth constraints for different sets of Traffic 351 Trunks. 353 [TEWG-FW] introduces the concept of Class-Types when discussing 354 operations of MPLS Traffic Engineering in a Diff-Serv environment. 356 DS-TE refines this definition into the following: 358 Class-Type (CT): the set of Traffic Trunks which share the 359 exact same Bandwidth Constraint, or set of Bandwidth 360 Constraints, on all links, for the purpose of Constraint 361 Based Routing and Admission Control. 363 Note that different LSPs transporting Traffic Trunks from the same 364 CT may be using the same or different preemption priorities as 365 explained in more details in section 3.4 below. 367 For illustration purposes, let's consider the case of a network 368 running 4 Diff-Serv classes of services respectively based on the EF 369 PHB, the AF1x PSC, the AF2x PSC and the BE PHB. The network 370 administrator may decide to deploy DS-TE in the following way: 371 o from every DS-TE Head-end to every DS-TE Tail-end, split 372 traffic into 4 Traffic Trunks: one for traffic of each Diff- 373 Serv class 374 o because the QoS objectives for the AF1x Traffic Trunks and 375 for the AF2x Traffic Trunks may be of similar nature (e.g. 376 both targeting low loss albeit at different levels perhaps), 377 the same (set of) Bandwidth Constraint(s) may be applied 378 collectively over the AF1x Traffic Trunks and the AF2x 379 Traffic Trunks. Thus, the network administrator may only 380 define three CTs: one for the EF Traffic Trunks, one for the 381 AF1x and AF2x Traffic Trunks and one for the Best Effort 382 Traffic Trunks. 384 Le Faucheur et. al 7 386 Requirements for Diff-Serv Traffic EngineeringNovember 2001 388 DS-TE must support at least 2 CTs and up to a maximum of 8 CTs. 389 Those are referred to as CTc, 0 <= c <= MaxCT-1 = 7. 391 In a given network, DS-TE must not require the network administrator 392 to always deploy the maximum number of CTs. The network 393 administrator must be able to deploy only the number of CTs actually 394 utilized. 396 3.3. Bandwidth Constraints 398 We refer to a Bandwidth Constraint Model as the set of rules 399 defining: 400 - the maximum number of Bandwidth Constraints; and 401 - which CTs each Bandwidth Constraint applies to and how. 403 By definition of CT, each CT is assigned either a Bandwidth 404 Constraint, or a set of Bandwidth Constraints. 406 We refer to the Bandwidth Constraints as BCb, 0 <= b <= MaxBC-1 408 Different models of Bandwidth Constraints are conceivable for 409 control of the CTs. 411 For example, a simple model of separate Bandwidth Constraints per CT 412 could be defined. This model is defined by: 413 - MaxBC= MaxCT 414 - All LSPs supporting Traffic Trunks from CTc use no more than BCc 416 For illustration purposes, on a link of 100 unit of bandwidth where 417 three CTs are used, the network administrator might then configure 418 BC0=30, BC1= 50, BC3=20 such 419 - All LSPs supporting Traffic Trunks from CT0 use no more than 30 420 (e.g. Voice <= 30) 421 - All LSPs supporting Traffic Trunks from CT1 use no more than 50 422 (e.g. Premium Data <= 50) 423 - All LSPs supporting Traffic Trunks from CT2 use no more than 20 424 (e.g. Best Effort <= 20) 426 As another example, a "Russian Doll" model of Bandwidth Constraints 427 may be defined whereby: 428 - MaxBC= MaxCT 429 - All LSPs supporting Traffic Trunks from CTc (with 0<=c<=b) use no 430 more than BCc 432 For illustration purposes, on a link of 100 units of bandwidth where 433 three CTs are used, the network administrator might then configure 434 BC0=60, BC1= 80, BC3=100 such 435 - All LSPs supporting Traffic Trunks from CT0 use no more than 60 436 (e.g. Voice <= 60) 437 - All LSPs supporting Traffic Trunks from CT0 or CT1 use no more 438 than 80 (e.g. Voice + Premium Data <= 80) 440 Le Faucheur et. al 8 442 Requirements for Diff-Serv Traffic EngineeringNovember 2001 444 - All LSPs supporting Traffic Trunks from CT0 or CT1 or CT2 use no 445 more than 100 (e.g. Voice + Premium Data + Best Effort <= 100). 447 More complex Bandwidth Constraints model can also be conceived. 448 Those could involve arbitrary relationships between BCb and CTc. 449 Those could also involve additional concepts such as associating 450 minimum reserved bandwidth to a CT. 452 At the time of writing, it is not clear whether a single model of 453 Bandwidth Constraints is sufficient, which one it should be and how 454 flexible this model really needs to be and what are the implications 455 on the DS-TE technical solution and its implementations. 457 We expect that Bandwidth Constraints models will be refined as part 458 of the specification of the DSTE technical solution. 460 3.4. Preemption 462 [TEWG-FW] defines the notion of preemption and preemption priority. 463 DS-TE must retain full support of such preemption. 465 The preemption attribute defined in [TE-REQ] must be retained and 466 applicable across all Class Types. The preemption attributes of 467 setup priority and holding priority must retain existing semantics, 468 and in particular the preemption must operate independently of Class 469 Types. This means that if LSP1 contends with LSP2 for resources, 470 LSP1 may preempt LSP2 if LSP1 has a higher preemption priority (i.e. 471 lower numerical priority value) regardless of LSP1's OA/CT and 472 LSP2's OA/CT. 474 In other words, DS-TE must offer eight(8) preemption priority levels 475 to be used by an LSP, that are completely orthogonal to that any 476 other LSP's attributes (eg LSP's OA, LSP's Class Type, etc.). 478 Thus, DS-TE must allow two different LSPs transporting Traffic 479 Trunks of the same Class-Type to use different preemption 480 priorities, and allow the LSP with higher priority to preempt the 481 other one when they contend for resources. 483 Similarly, DS-TE must allow two different LSPs transporting Traffic 484 Trunks from different Class-Types to use different preemption 485 priorities, and allow the LSP with higher priority to preempt the 486 other one when they contend for resources. 488 3.5. Dynamic Adjustment of Diff-Serv PHBs 490 As discussed in section 2.2, DS-TE may support adjustment of Diff- 491 Serv PHBs parameters (e.g. queue bandwidth) based on the amount of 492 TE-LSPs established for each Class/Class-Type. 494 Le Faucheur et. al 9 496 Requirements for Diff-Serv Traffic EngineeringNovember 2001 498 Where this behavior is supported, it must allow for disabling via 499 configuration (thus reverting to PHB treatment with static scheduler 500 configuration independent of DS-TE operations). 502 The dynamic adjustment must take account of the performance 503 requirements of each class when computing required adjustments. 505 3.6. Overbooking 507 Existing TE mechanisms allow overbooking to be applied on LSPs for 508 Constraint Based Routing and admission control. Historically this 509 has been achieved in TE deployment through factoring overbooking 510 ratios at the time of sizing the LSP bandwidth and/or at the time of 511 configuring the Maximum Reservable Bandwidth on links. 513 DS-TE must also allow overbooking and must effectively allow 514 different overbooking ratios to be enforced for different CTs. 516 DS-TE should optionally allow the effective overbooking ratio of a 517 given CT to be tweaked differently in different parts of the 518 network. 520 3.7. Restoration 522 With existing TE, restoration policies use standard priority 523 mechanisms such as, for example, the preemption priority to 524 effectively control the order/importance of LSPs for restoration 525 purposes. 527 DS-TE must ensure that similar application of the use of standard 528 priority mechanisms for implementation of restoration policy are not 529 prevented since those are expected to be required for achieving the 530 survivability requirements of DS-TE networks. 532 Further discussion of restoration requirements are presented in the 533 output document of the TEWG Requirements Design Team [SURVIV-REQ]. 535 4. Solution Evaluation Criteria 537 A range of solutions is possible for the support of the DS-TE 538 requirements discussed above. For example, some solutions may 539 require that all current TE protocols syntax (IGP, RSVP-TE, CR-LDP) 540 be extended in various ways. For instance, current TE protocols 541 could be modified to support multiple bandwidth constraints rather 542 than the existing single aggregate bandwidth constraint. 543 Alternatively, other solutions may keep the existing TE protocols 544 syntax unchanged but modify their semantic to allow for the multiple 545 bandwidth constraints. 547 This section identifies the evaluation criteria that should be used 548 to assess potential DS-TE solutions for selection. 550 Le Faucheur et. al 10 552 Requirements for Diff-Serv Traffic EngineeringNovember 2001 554 4.1. Satisfying detailed requirements 556 The solution must address all the scenarios described in section 2 557 and satisfy all the requirements listed in section 3. 559 4.2. Flexibility 561 - number of Class Types that can be supported, compared to 562 number identified in Requirements section 563 - number of Classes within a Class-Type 565 4.3. Extendibility 567 - how far can the solution be extended in the future if 568 requirements for more Class-Types are identified in the 569 future. 571 4.4. Scalability 573 - impact on network scalability in what is propagated, 574 processed, stored and computed (IGP signaling, IGP 575 processing, IGP database, TE-Tunnel signaling ,...). 576 - how does scalability impact evolve with number of Class- 577 Types/Classes actually deployed in a network. In 578 particular, is it possible to keep overhead small for a 579 large networks which only use a small number of Class- 580 Types/Classes, while allowing higher number of Class- 581 Types/Classes in smaller networks which can bear higher 582 overhead) 584 4.5. Backward compatibility/Migration 586 - backward compatibility/migration with/from existing TE 587 mechanisms 588 - backward compatibility/migration when 589 increasing/decreasing the number of Class-Types actually 590 deployed in a given network. 592 5. Security Considerations 594 The solution developed to address the requirements defined in this 595 document must address security aspects. DS-TE is not expected to add 596 specific security requirements beyond those of Diff-Serv and 597 existing TE. Networks which employ Diff-Serv techniques might offer 598 some protection between classes for denial of service attacks. 599 Though depending on how the technology is employed, it is possible 600 for some (lower scheduled) traffic to be more susceptible to traffic 601 anomalies (which include denial of service attacks) occurring within 602 other (higher scheduled) classes. 604 Le Faucheur et. al 11 606 Requirements for Diff-Serv Traffic EngineeringNovember 2001 608 References 610 [AF] Heinanen, J et al., "Assured Forwarding PHB Group", RFC2597 612 [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", 613 draft-ietf-mpls-cr-ldp-05.txt, February 2001 615 [DIFF-MPLS] Le Faucheur et al, "MPLS Support of Diff-Serv", draft- 616 ietf-mpls-diff-ext-09.txt, April 2001 618 [DIFF-NEW] Grossman, "New Terminology for Diffserv", work in 619 progress, draft-ietf-diffserv-new-terms-04.txt, March 2001. 621 [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft- 622 ietf-isis-traffic-02.txt, September 2000. 624 [OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF, 625 draft-katz-yeung-ospf-traffic-04.txt, August 2001. 627 [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 628 Tunnels", draft-ietf-mpls-rsvp-lsp-tunnel-08.txt, February 2001. 630 [TEWG-FW] Awduche et al, A Framework for Internet Traffic 631 Engineering, draft-ietf-tewg-framework-04.txt, April 2001. 633 [TE-REQ] Awduche et al, Requirements for Traffic Engineering over 634 MPLS, RFC2702, September 1999. 636 [SURVIV-REQ] W.S. Lai, D. McDysan, J. Boyle, M. Carlzon, R. Coltun, 637 T, Griffin, E. Kern, and T. Reddington, "Network Hierarchy and 638 Multilayer Survivability," work in progress, October 2001. 640 Authors' Address: 642 Francois Le Faucheur 643 Cisco Systems, Inc. 644 Village d'Entreprise Green Side - Batiment T3 645 400, Avenue de Roumanille 646 06410 Biot-Sophia Antipolis 647 France 648 Phone: +33 4 97 23 26 19 649 Email: flefauch@cisco.com 651 Martin Tatham 652 BT 653 Adastral Park, 654 Martlesham Heath, 655 Ipswich IP5 3RE 657 Le Faucheur et. al 12 659 Requirements for Diff-Serv Traffic EngineeringNovember 2001 661 UK 662 Phone: +44-1473-606349 663 Email: martin.tatham@bt.com 665 Thomas Telkamp 666 Global Crossing 667 Olympia 6 668 1213 NP Hilversum 669 The Netherlands 670 Phone: +31 35 655 651 671 Email: telkamp@gblx.net 673 David Cooper 674 Global Crossing 675 960 Hamlin Court 676 Sunnyvale, CA 94089 677 USA 678 Phone: (916) 415-0437 679 Email: dcooper@gblx.net 681 Jim Boyle 682 Protocol Driven Networks, Inc. 683 1381 Kildaire Farm Road #288 684 Cary, NC 27511 685 USA 686 Phone: (919) 852-5160 687 Email: jboyle@pdnets.com 689 Luyuan Fang 690 AT&T Labs 691 200 Laurel Avenue 692 Middletown, New Jersey 07748 693 Phone: (732) 420-1921 694 Email: luyuanfang@att.com 696 Gerald R. Ash 697 AT&T Labs 698 200 Laurel Avenue 699 Middletown, New Jersey 07748 700 Phone: (732) 420-4578 701 Email: gash@att.com 703 Wai Sum Lai 704 AT&T Labs 705 200 Laurel Avenue 706 Middletown, New Jersey 07748 707 Phone: (732) 420-3712 708 Email: wlai@att.com 710 Pete Hicks 711 CoreExpress, Inc 712 12655 Olive Blvd, Suite 500 714 Le Faucheur et. al 13 716 Requirements for Diff-Serv Traffic EngineeringNovember 2001 718 St. Louis, MO 63141 719 Phone: (314) 317-7504 720 Email: pete.hicks@coreexpress.net 722 Angela Chiu 723 Celion Networks 724 1 Sheila Drive, Suite 2 725 Tinton Falls, NJ 07724 726 Phone: (732) 747-9987 727 Email: angela.chiu@celion.com 729 William Townsend 730 Tenor Networks 731 100 Nagog Park 732 Acton, MA 01720 733 Phone: +1 978-264-4900 734 Email: btownsend@tenornetworks.com 736 Thomas D. Nadeau 737 Cisco Systems, Inc. 738 250 Apollo Drive 739 Chelmsford, MA 01824 740 Phone: (978) 244-3051 741 Email: tnadeau@cisco.com 743 Darek Skalecki 744 Nortel Networks 745 3500 Carling Ave, 746 Nepean K2H 8E9 747 Phone: (613) 765-2252 748 Email: dareks@nortelnetworks.com 750 Le Faucheur et. al 14