idnits 2.17.1 draft-ietf-mpls-diff-te-reqts-00.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 754 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 ([DIFF-TE-OSPF], [TEWG-FW], [DIFF-TE-ISIS], [DIFF-TE-EXT]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 232: '...is specification MUST support at least...' RFC 2119 keyword, line 233: '... and MAY support a total of 3 or 4 C...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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: 'DIFFF-TE-ISIS' is mentioned on line 128, but not defined == Missing Reference: 'TE MIB' is mentioned on line 460, but not defined == Unused Reference: 'LDP' is defined on line 624, but no explicit reference was found in the text == Unused Reference: 'TEMIB' is defined on line 630, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2702 (ref. 'TE-REQ') == Outdated reference: A later version (-05) exists of draft-ietf-tewg-framework-02 ** Downref: Normative reference to an Informational draft: draft-ietf-tewg-framework (ref. 'TEWG-FW') == Outdated reference: A later version (-01) exists of draft-ietf-mpls-diff-te-ext-00 -- Possible downref: Normative reference to a draft: ref. 'DIFF-TE-EXT' -- Unexpected draft version: The latest known version of draft-lefaucheur-diff-te-ospf is -00, but you're referring to -01. -- Possible downref: Normative reference to a draft: ref. 'DIFF-TE-OSPF' -- Unexpected draft version: The latest known version of draft-lefaucheur-diff-te-isis is -00, but you're referring to -01. -- Possible downref: Normative reference to a draft: ref. 'DIFF-TE-ISIS' == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-03 == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-02 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'ISIS-TE') == Outdated reference: A later version (-09) exists of draft-ietf-mpls-rsvp-lsp-tunnel-07 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-diff-ext-07 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-cr-ldp-04 == Outdated reference: A later version (-14) exists of draft-ietf-mpls-te-mib-04 == Outdated reference: A later version (-14) exists of draft-ietf-mpls-lsr-mib-06 Summary: 10 errors (**), 0 flaws (~~), 15 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Francois Le Faucheur 2 Thomas D. Nadeau 3 Cisco Systems, Inc. 5 Angela Chiu 6 AT&T 8 William Townsend 9 Tenor Networks 11 Darek Skalecki 12 Nortel Networks 14 Martin Tatham 15 BT 17 IETF Internet Draft 18 Expires: May, 2001 19 Document: draft-ietf-mpls-diff-te-reqts-00.txt November, 2000 21 Requirements for support of 22 Diff-Serv-aware MPLS Traffic Engineering 24 Status of this Memo 26 This document is an Internet-Draft and is in full conformance with 27 all provisions of Section 10 of RFC2026. Internet-Drafts are 28 Working documents of the Internet Engineering Task Force (IETF), its 29 areas, and its working groups. Note that other groups may also 30 distribute working documents as Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other documents 34 at any time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 Abstract 44 This document defines the requirements for support of Diff-Serv- 45 aware MPLS Traffic Engineering on a per-Class-Type basis, as 46 discussed in the Traffic Engineering Working Group Framework 47 document [TEWG-FW]. 49 Le Faucheur, et. al 1 51 Requirements for Diff-Serv Traffic Engineering July 2000 53 Companion documents [DIFF-TE-EXT] [DIFF-TE-OSPF] [DIFF-TE-ISIS] 54 respectively propose actual extensions to RSVP and CR-LDP, to OSPF 55 and to ISIS, in order to meet those requirements. 57 1. Introduction 59 As Diff-Serv becomes prominent in providing scalable multi-class of 60 services in IP networks, performing traffic engineering at a per- 61 class level instead of an aggregated level is needed to further 62 enhance networks in performance and efficiency. By mapping a traffic 63 trunk in a given class on a separate LSP, it allows the traffic 64 trunk to utilize resources available on both shortest path(s) and 65 non-shortest paths and follow paths that meet constraints which are 66 specific to the given class. It also allows each class to select the 67 proper protection/restoration mechanism(s) that satisfy its 68 survivability requirements in a cost effective manner. 70 Besides the set of parameters defined for the general aggregate TE 71 [TE-REQ], a new set of per-class parameters needs to be provided at 72 each LSR interface and propagated via extensions to the IGP 73 (ISIS/OSPF) [TEWG-FW]. Furthermore, the per-class parameters can be 74 aggregated into per-Class-Type parameters. The main motivation for 75 grouping a set of classes into a Class-Type is to improve the 76 scalability of the IGP link state advertisements by propagating 77 information on a per-Class-Type basis instead of on a per-class 78 basis. This approach also has the benefit of allowing better 79 bandwidth sharing between classes in the same Class-Type. 81 A Class-Type [TEWG-FW] is defined as a set of classes that satisfy 82 the following two conditions: 84 1) Classes in the same Class-Type possess common aggregate maximum 85 and minimum bandwidth requirements to guarantee the required 86 performance level. 88 2) There is no maximum or minimum bandwidth requirement to be 89 enforced at the level of an individual class within the Class- 90 Type. One can still implement some "priority" policies for 91 classes within the same Class-Type in terms of accessing the 92 Class-Type bandwidth (e.g. via the use of preemption 93 priorities). 95 An example of Class-Type comprising multiple Diff-Serv classes is a 96 low-loss Class-Type that includes both AF1-based and AF2-based 97 Ordering Aggregates. 99 Note that with per Class-Type TE, Constraint-Based Routing is 100 performed with bandwidth constraints on a per Class-Type basis but 101 LSPs may carry a single Diff-Serv class (Ordered Aggregate) with 102 Diff-Serv scheduling (i.e. PHB) performed separately for each class. 104 Le Faucheur et. al 2 106 Requirements for Diff-Serv Traffic Engineering July 2000 108 In this document, we will only discuss "per Class-Type TE" because 109 "per Class TE" can be viewed as a special case of per Class-Type TE 110 (where each Class-Type is degenerated into a single Diff-Serv 111 class). 113 This document focuses on intra-domain operations. Inter-domain 114 operations is for further study. 116 The following sections detail the requirements on OSPF/ISIS, RSVP/ 117 CR-LDP, Constraint Based Routing, MPLS MIBs, Diff-Serv Scheduling 118 and Traffic Mapping for support of MPLS Traffic Engineering on a 119 per-Class-Type basis. 121 2. Requirements for ISIS/OSPF Extensions 123 [OSPF-TE] and [ISIS-TE] define extensions to OSPF and ISIS for 124 support of (aggregate) MPLS Traffic Engineering. In this section we 125 define the requirements on OSPF and ISIS for support of Diff-Serv 126 Traffic Engineering on a per-Class-Type basis. These requirements 127 are expected to require further extensions to OSPF and ISIS. Such 128 extensions are proposed in [DIFF-TE-OSPF] and [DIFFF-TE-ISIS]. 130 Given that there are hard limits imposed by ISIS/OSPF TLVs, the TLV 131 space must be used frugally. An additional concern is that the 132 amount of information advertised by the IGP directly affects the 133 scalability of the solution. These considerations strongly influence 134 the requirements defined in this section. 136 As pointed out in [TEWG-FW], the IGP needs to advertise separate "TE 137 information" for each Class-Type. We focus now on detailing what 138 this "TE information" should be. 140 For Constraint Based Routing to be able to compute paths which 141 satisfy different bandwidth constraints for each Class-Type, the IGP 142 needs to advertise different "Unreserved Bandwidth" information for 143 each Class-Type. 145 Moreover, we propose that the preemption attribute defined in [TE- 146 REQ] be retained for all Class-Types. We also propose that the 147 preemption attributes of setup priority and holding priority retain 148 existing semantics, and in particular the preemption should work 149 across class-types (i.e. independently of class-types), rather than 150 having preemption levels operating only within each class-type. 151 Thus, the IGP needs to advertise "Unreserved Bandwidth" at each 152 preemption level for each Class-Type. However, we observe that 153 within a Class-Type, the "Unreserved Bandwidth" value is often 154 identical for multiple preemption levels. Firstly, many practical 155 MPLS Traffic Engineering deployments will use less than the maximum 156 8 possible levels of preemption. In such cases, the Unreserved 157 Bandwidth corresponding to a preemption level which is not used will 159 Le Faucheur et. al 3 161 Requirements for Diff-Serv Traffic Engineering July 2000 163 always be equal to the Unreserved Bandwidth for the preemption level 164 immediately above (numerically lower). For example, if only 165 preemption levels 0,1 and 4 are used in a network, then the 166 "Unreserved Bandwidth" for preemption levels 2 and 3 are identical 167 to the "Unreserved Bandwidth" for preemption 1, and the "Unreserved 168 Bandwidth" for preemption levels 5, 6 and 7 are identical to the 169 "Unreserved Bandwidth" for preemption 4. Secondly, even when all 8 170 preemption levels are used in the network, whenever there is no TE 171 Tunnels actually setup for a given preemption level (for that Class- 172 Type) on a given link, the Unreserved Bandwidth corresponding to 173 that preemption level will again be equal to the Unreserved 174 Bandwidth for the preemption level immediately above (numerically 175 lower). 177 Thus we propose that the IGP extension encoding includes a 178 compression scheme which can efficiently reduce the length of the 179 "Unreserved Bandwidth" advertisement (for each Class-Type) whenever 180 there are duplicate values across multiple preemption levels. 182 For the bandwidth constraints to be effectively different for each 183 Class-Type, LSRs need to allow configuration for every link of a 184 "Maximum Reservable Bandwidth" for each Class-Type. Clearly, the 185 "Unreserved Bandwidth" advertised for each Class-Type takes into 186 account the "Maximum Reservable Bandwidth" configured for the 187 corresponding Class-Type. Consequently, Constraint Based Routing can 188 compute paths for the different Class-Types without receiving the 189 "Maximum Reservable Bandwidth" for each Class-Type from the IGP. 190 Thus we feel that the IGP need not advertise the Maximum Reservable 191 Bandwidth for each Class-Type. We note that the Maximum Reservable 192 Bandwidth for each Class-Type could have been used by Constraint 193 Based Routing to enhance route computation in some situations (e.g. 194 as a tie breaker), but we feel this does not justify the extra 195 overhead in IGP advertisement. 197 Current IGP extensions for (aggregate) TE [OSPF-TE][ISIS-TE] specify 198 advertisement of the Maximum Reservable Bandwidth for (aggregate) 199 TE. Note that this document does not propose that this be changed. 201 Other TE attributes already advertised by the IGP (i.e. 202 administrative group/color, IPv4 interface and neighbor addresses, 203 Maximum Link Bandwidth, TE Metric) need not be advertised per Class- 204 Type as those will be applicable to all Class-Types. We note that a 205 separate TE Metric per Class-Type could be defined in the future if 206 required, for instance to allow Constraint Based Routing to take 207 account of link propagation delay for LSPs from a Class-Type with 208 strict delay requirements. 210 We propose to begin by allowing a total of 4 Class-Types (i.e., 3 211 beyond the existing one aka. Class-Type 0). This is expected to be 212 sufficient for practical deployments in the foreseeable future. As 213 an example, a total of three Class-Types already allow support of 214 separate bandwidth control for Real-Time, Low-Loss and Best Effort, 216 Le Faucheur et. al 4 218 Requirements for Diff-Serv Traffic Engineering July 2000 220 while allowing multiple classes within each Class-Type (e.g. AF1 and 221 AF2 flavors of "Low-Loss"). More Class-Types could be defined in the 222 future if required. 224 Where a Class-Type is not effectively used in a network, it is 225 recommended that the corresponding sub-TLV is not included in the IS 226 reachability TLV. Therefore, the Class-Types for which "Unreserved 227 Bandwidth" is to be advertised in the IGP should be configurable and 228 the IGP must allow advertisement of "Unreserved Bandwidth" for any 229 subset of the Class-Types. 231 Implementations of Diff-Serv Traffic Engineering in compliance with 232 this specification MUST support at least a total of 2 Class-Types 233 and MAY support a total of 3 or 4 Class-Types. 235 2.1. Bandwidth Reservation Scheme 237 This section discusses the algorithm for computing the "Unreserved 238 Bandwidth" for each Class-Type as a function of: 239 - the configurable parameters controlling how link bandwidth 240 can be reserved by each Class-Type (in particular in situations 241 where Class-Types compete for bandwidth reservation) such as "Max 242 Reservable Bandwidth for the Class Type", 243 - the already established LSPs of all Class-Types. 244 This "Unreserved Bandwidth" for each Class-Type is computed for 245 advertisement in the IGP (and therefore used as the per Class-Type 246 bandwidth constraint for Constraint Based Routing). The same 247 algorithm for computation of "Unreserved Bandwidth" must also be 248 used for admission control of Diff-Serv-aware Traffic Engineering 249 LSPs at establishment time through RSVP or CR-LDP signalling; 250 otherwise persistent deadlock situations could occur whereby 251 Constraint Based Routing believes that a given LSP for a given 252 Class-Type can be routed through a link but local admission control 253 rejects it. 255 It is desirable to be able to avoid under-utilizing aggregate 256 resource. To achieve this, it is necessary to allow the sum of the 257 configurable Maximum Reservable Bandwidth of all Class-Types to be 258 larger than a configurable Maximum Reservable Aggregate Bandwidth 259 (i.e. aggregate across all Class-Types). At the same time, it is 260 desirable to be able to avoid over-utilizing the aggregate resource. 261 To achieve this, it is necessary to be able to enforce this Maximum 262 Reservable Aggregate Bandwidth; in other words it is necessary to 263 ensure that the sum of all LSPs across all Class-Types never exceeds 264 the Maximum Reservable Aggregate Bandwidth. 266 For example, a 10Gb/s link may be configured to allow: 268 - Class-Type 0 (eg: BE) to reserve up to 9 Gb/s 269 - Class-Type 1 (eg: real time including EF) to reserve up to 5 270 Gb/s 272 Le Faucheur et. al 5 274 Requirements for Diff-Serv Traffic Engineering July 2000 276 - Class-Type 2 (eg: low loss including AF1 and AF2) to reserve up 277 to 8 Gb/s 279 and at the same may be configured to allow: 281 - on an aggregate basis, the sum of all Class-Types to reserve up 282 to 10 Gb/s. 284 Therefore, a path computed by the Constraint Based Routing for an 285 LSP of Class-Type N must ensure that this LSP fits within the 286 remaining Class-Type N bandwidth AND that this LSP fits within the 287 remaining Aggregate bandwidth. 289 One way to achieve this, would be: 290 - for each Class-Type, that IGP uses the "Unreserved Bandwidth for 291 Class-Type N" to advertise the Class-Type N bandwidth currently 292 unreserved (i.e. the difference between the Maximum Reservable 293 Bandwidth for Class-Type N and the bandwidth reserved by 294 existing Class-Type N LSPs), 295 - in addition, that IGP separately advertises the "Unreserved 296 Aggregate Bandwidth" (i.e. the difference between the Maximum 297 Reservable Aggregate Bandwidth and the bandwidth reserved by 298 existing LSPs of all Class-Types) 299 - have Constraint Based Routing ensure that a new Class-Type N LSP 300 fits both in the received "Unreserved Bandwidth for Class-Type 301 N" and in the "Unreserved Aggregate Bandwidth". 302 Such an approach has the drawbacks that it would require that N+1 303 "unreserved bandwidth" information be advertised by the IGP when N 304 Class-Types are supported, and that it requires the node performing 305 Constraint Based Routing to meet a double bandwidth constraints. 307 Instead we propose that: 308 - for each Class-Type, that IGP uses the "Unreserved Bandwidth for 309 Class-Type N" to directly advertise the amount of bandwidth that 310 is effectively useable by Class-Type N. This is computed as the 311 smaller of these two values: 312 o The Class-Type N bandwidth currently unreserved (i.e. the 313 difference between the Maximum Reservable Bandwidth for 314 Class-Type N and the bandwidth reserved by existing Class- 315 Type N LSPs). 316 o The aggregate bandwidth currently unreserved (i.e. the 317 difference between the Maximum Reservable Aggregate 318 Bandwidth and the bandwidth reserved by existing LSPs of 319 all Class-Types). 320 - have Constraint Based Routing ensure that a new Class-Type N LSP 321 simply fits in the received "Unreserved Bandwidth for Class-Type 322 N". 323 Such an approach only requires that N "unreserved bandwidth" 324 information be advertised by the IGP when N Class-Types are 325 supported, and only requires that the node performing Constraint 326 Based Routing meets a single bandwidth constraint. 328 Le Faucheur et. al 6 330 Requirements for Diff-Serv Traffic Engineering July 2000 332 It may be desirable to prevent a Class-Type from being starved by 333 others. In the example given above where we defined three Class- 334 Types, it may be useful to be able to always ensure that some amount 335 of Class-Type 0 LSPs can be routed over that link (i.e. to prevent 336 Class-Type 1 LSPs and Class-Type 2 LSPs from reserving up to 100% of 337 the maximum reservable aggregate bandwidth which would result in 338 Class-Type 0 LSPs not having any access to the capacity of that 339 link). Such capability might require the ability from the IGP to 340 advertise an optional "minimum reservable bandwidth" per Class-Type. 341 This is not seen as an immediate requirement but could be defined in 342 the future if required. 344 [Editor's Note: We are considering a potential enhancement to the 345 Bandwidth Reservation scheme presented above and therefore to the 346 calculation of advertised `unreserved bandwidth' per Class-Type. 348 This potential enhancement would take into account a Minimum 349 Reservable Bandwidth in addition to the Maximum Reservable Bandwidth 350 and the Maximum Aggregate Reservable bandwidth and could take 351 account of bandwidth `borrowing' between classes. Thus traffic 352 trunks of one Class-Type (say CT-2) might initially reserve all the 353 bandwidth of the link, and implicitly that Class-Type would have 354 borrowed unreserved capacity from other Class-Types (say CT-1, CT- 355 0). However, the LSR would continue to advertise `unreserved 356 bandwidth' for CT-1 and CT-0 based on the maximum bandwidth 357 entitlement of each Class-Type. A reservation may then be received 358 within CT-1 or CT-0, which would preempt an existing reservation in 359 CT-2. This form of preemption between Class-Types would only operate 360 within existing preemption priority levels, and existing rules for 361 preemption across priority levels would still be followed. The 362 potential goals of this enhancement would be : 363 - to allow enforcement of a Minimum Reservable Bandwidth per 364 Class-Type in addition to the Maximum Reservable Bandwidth while 365 still advertising a single "Unreserved Bandwidth" per Class-Type 366 (for each preemption levels), 367 - to match the bandwidth "sharing" properties (across Class- 368 Types) of common work-conserving Diff-Serv schedulers (e.g. Weighted 369 Fair Queuing). This could ensure that, even in the case of 370 statically configured Diff-Serv packet scheduler, there is always 371 consistency between : 372 * the bandwidth reserved by each Class-Type for Constraint 373 Based Routing purposes, and 374 * the bandwidth actually granted to the corresponding 375 Class-Type by the Diff-Serv Packet Scheduler 376 As discussed in section 6 below, the Bandwidth Allocation Scheme 377 currently proposed requires dynamic adjustement of the Diff-Serv 378 packet scheduler.] 380 3. Requirements for RSVP/CR-LDP Extensions 382 Le Faucheur et. al 7 384 Requirements for Diff-Serv Traffic Engineering July 2000 386 [RSVP-TE] and [CR-LDP] define extensions to RSVP and LDP for support 387 of (aggregate) MPLS Traffic Engineering. [DIFF-MPLS] defines the 388 extensions to RSVP and LDP for support of Diff-Serv over MPLS. In 389 this section we define the requirements on RSVP and CR-LDP for 390 support of Diff-Serv Traffic Engineering on a per-Class-Type basis. 391 These requirements are expected to require further extensions to 392 RSVP and CR-LDP. Such extensions are proposed in [DIFF-TE-EXT]. 394 In order for an LSR to perform resource availability checking for an 395 LSP that belongs to a certain Class-Type, the LSR needs to be made 396 aware through RSVP/CR-LDP signaling of the Class-Type associated 397 with the LSP. 399 To that end, we propose that RSVP/CR-LDP be extended to be able to 400 signal the Class-Type. 402 We identify the following backward compatibility requirements for 403 the RSVP/CR-LDP extensions: 404 - operations in heterogeneous environments need to be supported 405 for smooth migration, where some LSRs are Diff-Serv-TE-capable 406 (as defined in this specification) while some other LSRs are not 407 Diff-Serv-TE-capable (i.e. support (aggregate) TE only) 408 - in such heterogeneous environments, the solution needs to allow 409 establishment of Class-Type 0 LSPs across paths combining Diff- 410 Serv-TE-capable LSRs and non-Diff-Serv-TE-capable LSRs 411 - in heterogeneous environments, the solution needs to ensure that 412 a non-Diff-Serv-TE-capable LSR would reject establishment of a 413 Class-Type N (N=1,2,3) LSP. 415 More generally we identify the following backward compatibility 416 requirements for the RSVP/CR-LDP extensions: 417 - operations in heterogeneous environments need to be supported 418 for smooth migration, where some Diff-Serv-TE-capable LSRs (as 419 defined in this specification) support N Class-Types while other 420 Diff-Serv-TE-capable LSRs support M Class-Types with M>N. 421 - in such heterogeneous environments, the solution needs to allow 422 establishment of Class-Type 0,.., N-1 LSPs across paths 423 combining both types of LSRs 424 - in such heterogeneous environments, the solution needs to ensure 425 that a Diff-Serv-TE-capable LSR supporting only N Class-Types 426 would reject establishment of a Class-Type X LSP if N<=X<=M-1. 428 The admission control algorithm implemented for LSP establishment 429 must locally maintain different variables which keep track of the 430 currently unreserved bandwidth for each Class-Type. These unreserved 431 bandwidth variables must be updated in accordance with the Bandwidth 432 Reservation Scheme discussed in the previous section. 434 4. Requirements for Constraint Based Routing Extensions 436 Le Faucheur et. al 8 438 Requirements for Diff-Serv Traffic Engineering July 2000 440 In order for Constraint Based Routing to support Diff-Serv TE on a 441 per-Class-Type basis, the Constraint Based Routing algorithm need to 442 be capable of taking into account the "Unreserved Bandwidth for 443 Class-Type N" when computing a path for a Class-Type N LSP. 445 The Constraint Based Routing may also take into account different 446 metric for different Class-Types. As an example, when computing a 447 path for a non-real-time Class-Type, the Constraint Based Routing 448 may use a metric similar to the one currently used by IGP SPF 449 Routing for Best Effort traffic, while when computing a path for a 450 real-time Class-Type, the Constraint Based Routing may use a metric 451 reflecting the link propagation delay. 453 5. Requirements for MIB Extensions 455 In order for an LSR to support the configuration and monitoring of 456 Diff-Serv Traffic Engineering certain enhancements to some of the 457 existing MPLS Management Information Bases (MIBs) will be required. 458 [LSRMIB] defines the MPLS Label Switch Router MIB (LSR MIB) which 459 contains objects useful for the management and configuration of MPLS 460 LSPs. [TE MIB] defines the MPLS Traffic Engineering MIB (TE MIB) 461 which contains objects useful for the management and configuration 462 of MPLS Traffic Engineered Tunnels. 464 In particular, the MIB extensions need to: 465 - track for each MPLS interface, the Maximum Reservable Bandwidth 466 configured for each Class-Type. 467 - track for each MPLS interface, the Maximum Reservable Aggregate 468 Bandwidth configured. 469 - track for each LSP, the Class-Type associated with the LSP. On 470 the Head-End LSRs, the Class-Type is configured as part of the 471 tunnel configuration. On other LSRs, the Class-Type is 472 associated with the LSP at establishment time based on signaled 473 information. 475 Additional details of these changes will be provided in forthcoming 476 versions of this draft. It is the authors' intent to transfer these 477 MIB requirements to future versions of the MPLS TE and the MPLS LSR 478 MIBs. It is not the intent of this document to define the SMI 479 required for the MIB enhancements; rather, it is to flesh out and 480 define the details of these changes in the context of this document. 482 6. Diff-Serv Scheduling Requirements 484 Diff-Serv-aware Traffic Engineering is expected to be deployed in 485 conjunction with Diff-Serv buffer management and differential packet 486 scheduling. Per-class-type performance would be controlled on longer 487 timescales by Diff-Serv-aware Traffic Engineering; this would be 488 complemented by Diff-Serv buffer management and differential packet 490 Le Faucheur et. al 9 492 Requirements for Diff-Serv Traffic Engineering July 2000 494 scheduling mechanisms controlling the per-class performance on 495 packet scheduling timescales. 497 If the Diff-Serv packet scheduling mechanisms are configured 498 statically, it is possible, however, that the allocation of 499 resources by Diff-Serv-aware Traffic Engineering for reservation 500 purposes will not always correspond with the resources allocated in 501 the packet scheduler. As an example, consider the following 10Mbps 502 link: 504 Max. Res'ble Admitted Pkt Scheduler 505 Bandwidth Load Bandwidth share 506 Class-Type 0 10 Mbps 1 Mbps 3 Mbps 507 Class-type 1 3 Mbps 3 Mbps 3 Mbps 508 Class-type 2 10 Mbps 6 Mbps 4 Mbps 510 In the above example, the Maximum Reservable Bandwidth for Class- 511 Type 2 (e.g. AF) has been set above the corresponding scheduler 512 share of 4 Mbps to prevent under-utilisation of the link, in case 513 there was little traffic in Class-Types 0 (e.g. BE) and 1 (e.g. EF). 514 Under actual load, let's assume that 6 Mbps of Class-Type 2 traffic 515 was admitted on the link, possibly due to Class-type 2 LSPs being 516 given a high preemption priority. However, the packet scheduler had 517 been configured to give the classes comprising Class-type 2 an 518 overall share of 4Mbps, reflecting the expected load and taking 519 account of the performance targets of Class-type 2 traffic. Even 520 though, for most link schedulers, resources would be dynamically 521 redirected from Class-Type 0 to Class-Type 2, this would leave 522 Class-type 2 traffic at risk of seeing poor performance, under 523 conditions of link congestion. Assume for instance that : 524 - there is indeed 3 Mbps worth of actual traffic sent onto the 525 admitted Class-Type 1 LSPs, 526 - there is indeed 6 Mbps worth of actual traffic sent onto the 527 admitted Class-Type 2 LSPs, 528 - although only 1 Mbps worth of Class-Type 0 (eg. Best Effort 529 traffic) has been admitted by Diff-Serv-aware TE, 3 Mbps of 530 Class-Type 0 traffic is actually sent onto the Class-Type 0 531 LSPs. 532 In that case, the packet scheduler will : 533 - serve the 3 Mbps of Class-Type 0 traffic 534 - serve the 3 Mbps of Class-Type 1 traffic 535 - will only be able to provide 4 Mbps of service rate for the 6 536 Mbps of Class-Type 2 traffic. 537 This example reflects the fact that the Bandwidth allocation Scheme 538 described in section 2.1 above may not under all conditions align 539 with the resource allocation approach taken by a statically 540 configured local link packet scheduler. 542 In general, therefore, the requirements on Diff-Serv packet 543 scheduling are that: 544 1) An LSR should be capable of dynamically adjusting resource 545 allocation to Classes based on per-class LSP resource requests. 547 Le Faucheur et. al 10 549 Requirements for Diff-Serv Traffic Engineering July 2000 551 2) The dynamic adjustment should take account of the performance 552 requirements of the classes. This may be achieved using, for 553 example, per-Class maximum allocation multipliers or overbooking 554 factors to adjust scheduling weights. 556 7. Traffic Mapping Requirements 558 This section describes the requirement for an LSR which is the Head- 559 end of Diff-Serv-aware Traffic Engineering LSPs to map incoming 560 traffic onto these LSPs. 561 Each Diff-Serv-aware Traffic Engineering LSP has the following 562 attributes: 563 - it can transport one (or a set of) Diff-Serv class(es) 564 (Ordered Aggregate) in accordance with [DIFF-MPLS] 565 - it has been constraint based routed based on the Class-Type 566 which comprises this (or these) class(es), in accordance with 567 the previous sections of this document. 569 Mapping of incoming traffic onto Diff-Serv-aware Traffic Engineering 570 LSPs is to be performed in accordance with [DIFF-MPLS] so that only 571 packets that belong to the (set of) Behavior Aggregate(s) 572 transported over a given Diff-Serv-aware TE LSP should be mapped to 573 that LSP. In particular, where the Head-end LSR is also the MPLS 574 Edge LSR, determination of the Behavior Aggregate (and thus 575 determination of the egress Diff-Serv-aware TE LSP) is based on the 576 Diffserv Codepoint (DSCP) in the packet header. 578 8. Security Considerations 580 The solution developed to address the requirements defined in this 581 document must address security aspects. 583 9. Acknowledgments 585 This document has benefited from discussions with Carol Iturralde 586 and Rob Goguen. 588 References 590 [TE-REQ] Awduche et al, Requirements for Traffic Engineering over 591 MPLS, RFC2702, September 1999. 593 [TEWG-FW] Awduche et al, A Framework for Internet Traffic 594 Engineering, draft-ietf-tewg-framework-02.txt, July 2000. 596 Le Faucheur et. al 11 598 Requirements for Diff-Serv Traffic Engineering July 2000 600 [DIFF-TE-EXT] Le Faucheur et al, Extensions to RSVP and CR-LDP for 601 support of Diff-Serv-aware MPLS Traffic Engineering, draft-ietf- 602 mpls-diff-te-ext-00.txt, November 2000. 604 [DIFF-TE-OSPF] Le Faucheur et al, Extension to OSPF for support of 605 Diff-Serv-aware MPLS Traffic Engineering, draft-lefaucheur-diff-te- 606 ospf-01.txt, November 2000. 608 [DIFF-TE-ISIS] Le Faucheur et al, Extension to ISIS for support of 609 Diff-Serv-aware MPLS Traffic Engineering, draft-lefaucheur-diff-te- 610 isis-01.txt, November 2000. 612 [OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF, 613 draft-katz-yeung-ospf-traffic-03.txt, September 2000. 615 [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft- 616 ietf-isis-traffic-02.txt, September 2000. 618 [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 619 Tunnels", draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, August 2000. 621 [DIFF-MPLS] Le Faucheur et al, "MPLS Support of Diff-Serv", draft- 622 ietf-mpls-diff-ext-07.txt, August 2000 624 [LDP] Andersson et al., "LDP Specification", draft-ietf-mpls-ldp- 625 11.txt, August 2000 627 [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", 628 draft-ietf-mpls-cr-ldp-04.txt, July 2000 630 [TEMIB] Srinivansan, C., and A. Viswanathan, "MPLS Traffic 631 Engineering Management Information Base Using SMIv2", draft-ietf- 632 mpls-te-mib-04.txt, July 2000. 634 [LSRMIB] Srinivansan, C., Viswanathan, A., and T. Nadeau "MPLS 635 Label Switch Router Management Information Base Using SMIv2", draft- 636 ietf-mpls-lsr-mib-06.txt, July 2000. 638 Authors' Address: 640 Francois Le Faucheur 641 Cisco Systems, Inc. 642 Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - 643 France 644 Phone: +33 4 92 96 75 64 645 Email: flefauch@cisco.com 647 Angela Chiu 648 AT&T Labs 649 200 Laurel Ave. Rm A5-1F06 650 Middletown, NJ 07748, USA 652 Le Faucheur et. al 12 654 Requirements for Diff-Serv Traffic Engineering July 2000 656 Tel: 1-(732) 420-9057 657 Email: alchiu@att.com 659 William Townsend 660 Tenor Networks 661 100 Nagog Park 662 Acton, MA 01720 663 Phone: +1-978-264-4900 664 Email: btownsend@tenornetworks.com 666 Thomas D. Nadeau 667 Cisco Systems, Inc. 668 250 Apollo Drive 669 Chelmsford, MA 01824 670 Phone: +1-978-244-3051 671 Email: tnadeau@cisco.com 673 Darek Skalecki 674 Nortel Networks 675 3500 Carling Ave, 676 Nepean K2H 8E9 677 Phone: +1-613-765-2252 678 Email: dareks@nortelnetworks.com 680 Martin Tatham 681 BT 682 Adastral Park, 683 Martlesham Heath, 684 Ipswich IP5 3RE 685 UK 686 Phone: +44-1473-606349 687 Email: martin.tatham@bt.com 689 Le Faucheur et. al 13