idnits 2.17.1 draft-lefaucheur-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 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], [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 246: '...is specification MUST support at least...' RFC 2119 keyword, line 247: '... 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: 'TE MIB' is mentioned on line 329, but not defined == Unused Reference: 'LDP' is defined on line 386, but no explicit reference was found in the text == Unused Reference: 'TEMIB' is defined on line 392, 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-01 ** Downref: Normative reference to an Informational draft: draft-ietf-tewg-framework (ref. 'TEWG-FW') -- Possible downref: Normative reference to a draft: ref. 'DIFF-TE-EXT' == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-01 == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-01 ** 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-05 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-diff-ext-05 == Outdated reference: A later version (-11) exists of draft-ietf-mpls-ldp-06 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-cr-ldp-03 == Outdated reference: A later version (-14) exists of draft-ietf-mpls-te-mib-03 == Outdated reference: A later version (-14) exists of draft-ietf-mpls-lsr-mib-04 Summary: 10 errors (**), 0 flaws (~~), 13 warnings (==), 3 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 IETF Internet Draft 15 Expires: January, 2001 16 Document: draft-lefaucheur-diff-te-reqts-00.txt July, 2000 18 Requirements for support of 19 Diff-Serv-aware MPLS Traffic Engineering 21 Status of this Memo 23 This document is an Internet-Draft and is in full conformance with 24 all provisions of Section 10 of RFC2026. Internet-Drafts are 25 Working documents of the Internet Engineering Task Force (IETF), its 26 areas, and its working groups. Note that other groups may also 27 distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 This document defines the requirements for support of Diff-Serv- 42 aware MPLS Traffic Engineering on a per-Class-Type basis, as 43 discussed in the Traffic Engineering Working Group Framework 44 document [TEWG-FW]. 46 A companion document [DIFF-TE-EXT] proposes actual extensions to 47 OSPF, ISIS, RSVP and CR-LDP in order to meet those requirements. 49 Le Faucheur, et. al 1 50 1. Introduction 52 As Diff-Serv becomes prominent in providing scalable multi-class of 53 services in IP networks, performing traffic engineering at a per- 54 class level instead of an aggregated level is needed to further 55 enhance networks in performance and efficiency. By mapping a traffic 56 trunk in a given class on a separate LSP, it allows the traffic 57 trunk to utilize resources available on both shortest path(s) and 58 non-shortest paths and follow paths that meet constraints which are 59 specific to the given class. It also allows each class to select the 60 proper protection/restoration mechanism(s) that satisfy its 61 survivability requirements in a cost effective manner. 63 Besides the set of parameters defined for the general aggregate TE 64 [TE-REQ], a new set of per-class parameters needs to be provided at 65 each LSR interface and propagated via extensions to the IGP 66 (ISIS/OSPF) [TEWG-FW]. Furthermore, the per-class parameters can be 67 aggregated into per-Class-Type parameters. The main motivation for 68 grouping a set of classes into a Class-Type is to improve the 69 scalability of the IGP link state advertisements by propagating 70 information on a per-Class-Type basis instead of on a per-class 71 basis. This approach also has the benefit of allowing better 72 bandwidth sharing between classes in the same Class-Type. 74 A Class-Type [TEWG-FW] is defined as a set of classes that satisfy 75 the following two conditions: 77 1) Classes in the same Class-Type possess common aggregate maximum 78 and minimum bandwidth requirements to guarantee the required 79 performance level. 81 2) There is no maximum or minimum bandwidth requirement to be 82 enforced at the level of an individual class within the Class- 83 Type. One can still implement some "priority" policies for 84 classes within the same Class-Type in terms of accessing the 85 Class-Type bandwidth (e.g. via the use of preemption 86 priorities). 88 An example of Class-Type comprising multiple Diff-Serv classes is a 89 low-loss Class-Type that includes both AF1-based and AF2-based 90 Ordering Aggregates. 92 Note that with per Class-Type TE, Constraint-Based Routing is 93 performed with bandwidth constraints on a per Class-Type basis but 94 LSPs may carry a single Diff-Serv class (Ordered Aggregate) with 95 Diff-Serv scheduling (i.e. PHB) performed separately for each class. 96 Diff-Serv scheduling parameters for a given class within a Class- 97 Type may be automatically adjusted by the LSRs based on the 98 bandwidth of all LSPs currently established for each class within 99 the Class-Type. 101 Le Faucheur et. al 2 102 In this document, we will only discuss "per Class-Type TE" because 103 "per Class TE" can be viewed as a special case of per Class-Type TE 104 (where each Class-Type is degenerated into a single Diff-Serv 105 class). 107 This document focuses on intra-domain operations. Inter-domain 108 operations is for further study. 110 The following sections detail the requirements on OSPF/ISIS, RSVP/ 111 CR-LDP, Constraint Based Routing and MPLS MIBs for support of MPLS 112 Traffic Engineering on a per-Class-Type basis. 114 2. Requirements for ISIS/OSPF Extensions 116 [OSPF-TE] and [ISIS-TE] define extensions to OSPF and ISIS for 117 support of (aggregate) MPLS Traffic Engineering. In this section we 118 define the requirements on OSPF and ISIS for support of Diff-Serv 119 Traffic Engineering on a per-Class-Type basis. These requirements 120 are expected to require further extensions to OSPF and ISIS. Such 121 extensions are proposed in [DIFF-TE-EXT]. 123 Given that there are hard limits imposed by ISIS/OSPF TLVs, the TLV 124 space must be used frugally. An additional concern is that the 125 amount of information advertised by the IGP directly affects the 126 scalability of the solution. These considerations strongly influence 127 the requirements defined in this section. 129 As pointed out in [TEWG-FW], the IGP needs to advertise separate "TE 130 information" for each Class-Type. We focus now on detailing what 131 this "TE information" should be. 133 For Constraint Based Routing to be able to compute paths which 134 satisfy different bandwidth constraints for each Class-Type, the IGP 135 needs to advertise different "Unreserved Bandwidth" information for 136 each Class-Type. Moreover, we propose that the preemption attribute 137 defined in [TE-REQ] be retained for all Class-Types. Thus, the IGP 138 needs to advertise "Unreserved Bandwidth" at each preemption level 139 for each Class-Type. 141 For the bandwidth constraints to be effectively different for each 142 Class-Type, LSRs need to allow configuration for every link of a 143 "Maximum Reservable Bandwidth" for each Class-Type. Clearly, the 144 "Unreserved Bandwidth" advertised for each Class-Type takes into 145 account the "Maximum Reservable Bandwidth" configured for the 146 corresponding Class-Type. Consequently, Constraint Based Routing can 147 compute paths for the different Class-Types without receiving the 148 "Maximum Reservable Bandwidth" for each Class-Type from the IGP. 149 Thus we feel that the IGP need not advertise the Maximum Reservable 150 Bandwidth for each Class-Type. We note that the Maximum Reservable 151 Bandwidth for each Class-Type could have been used by Constraint 152 Based Routing to enhance route computation in some situations (e.g. 154 Le Faucheur et. al 3 155 as a tie breaker), but we feel this does not justify the extra 156 overhead in IGP advertisement. 158 Current IGP extensions for (aggregate) TE [OSPF-TE][ISIS-TE] specify 159 advertisement of the Maximum Reservable Bandwidth for (aggregate) 160 TE. Note that this document does not propose that this be changed. 162 Other TE attributes already advertised by the IGP (i.e. 163 resource/color) need not be advertised per Class-Type as those will 164 be applicable to all Class-Types. 166 It is desirable to be able to avoid under-utilizing aggregate 167 resource. To achieve this, it is necessary to allow the sum of the 168 configurable Maximum Reservable Bandwidth of all Class-Types be 169 larger than a configurable Maximum Reservable Aggregate Bandwidth 170 (i.e. aggregate across all Class-Types). At the same time, it is 171 desirable to be able to avoid over-utilizing the aggregate resource. 172 To achieve this, it is necessary to be able to enforce this Maximum 173 Reservable Aggregate Bandwidth; in other words it is necessary to 174 ensure that the sum of all LSPs across all Class-Types never exceeds 175 the Maximum Reservable Aggregate Bandwidth. 177 For example, a 10Gb/s link may be configured to allow: 179 - Class-Type 0 (BE) to reserve up to 9 Gb/s 180 - Class-Type 1 (e.g. real time including EF) to reserve up to 5 181 Gb/s 182 - Class-Type 2 (eg low loss including AF1 and AF2) to reserve up 183 to 8 Gb/s 185 and at the same may be configured to allow: 187 - on an aggregate basis, the sum of all Class-Types to reserve up 188 to 10 Gb/s. 190 Therefore, a path computed by the Constraint Based Routing for an 191 LSP of Class-Type N must ensure that this LSP fits within the 192 remaining Class-Type N bandwidth AND that this LSP fits within the 193 remaining Aggregate bandwidth. 195 One way to achieve this, would be: 196 - for each Class-Type, that IGP uses the "Unreserved Bandwidth for 197 Class-Type N" to advertise the Class-Type N bandwidth currently 198 unreserved (i.e. the difference between the Maximum Reservable 199 Bandwidth for Class-Type N and the bandwidth reserved by 200 existing Class-Type N LSPs), 201 - in addition, that IGP separately advertises the "Unreserved 202 Aggregate Bandwidth" (i.e. the difference between the Maximum 203 Reservable Aggregate Bandwidth and the bandwidth reserved by 204 existing LSPs of all Class-Types) 206 Le Faucheur et. al 4 207 - have Constraint Based Routing ensure that a new Class-Type N LSP 208 fits both in the received "Unreserved Bandwidth for Class-Type 209 N" and in the "Unreserved Aggregate Bandwidth". 210 Such an approach has the drawbacks that it would require that N+1 211 "unreserved bandwidth" information be advertised by the IGP when N 212 Class-Types are supported, and that it requires the node performing 213 Constraint Based Routing to meet a double bandwidth constraints. 215 Instead we propose that: 216 - for each Class-Type, that IGP uses the "Unreserved Bandwidth for 217 Class-Type N" to directly advertise the amount of bandwidth that 218 is effectively useable by Class-Type N. This is computed as the 219 smaller of these two values: 220 o The Class-Type N bandwidth currently unreserved (i.e. the 221 difference between the Maximum Reservable Bandwidth for 222 Class-Type N and the bandwidth reserved by existing Class- 223 Type N LSPs). 224 o The aggregate bandwidth currently unreserved (i.e. the 225 difference between the Maximum Reservable Aggregate 226 Bandwidth and the bandwidth reserved by existing LSPs of 227 all Class-Types). 228 - have Constraint Based Routing ensure that a new Class-Type N LSP 229 simply fits in the received "Unreserved Bandwidth for Class-Type 230 N". 231 Such an approach only requires that N "unreserved bandwidth" 232 information be advertised by the IGP when N Class-Types are 233 supported, and only requires that the node performing Constraint 234 Based Routing meets a single bandwidth constraints. 236 We propose to begin by allowing a total of 4 Class-Types (i.e., 3 237 beyond the existing one aka. Class-Type 0). This is expected to be 238 sufficient for practical deployments in the foreseeable future. As 239 an example, a total of three Class-Types already allow support of 240 separate bandwidth control for Real-Time, Low-Loss and Best Effort, 241 while allowing multiple classes within each Class-Type (e.g. AF1 and 242 AF2 flavors of "Low-Loss"). More Class-Types could be defined in the 243 future if required. 245 Implementations of Diff-Serv Traffic Engineering in compliance with 246 this specification MUST support at least a total of 2 Class-Types 247 and MAY support a total of 3 or 4 Class-Types. 249 The IGP must be able to only advertise the Bandwidth Information for 250 the subset of Class-Types actually used in the network (i.e. not 251 always advertise the Unreserved Bandwidth information for all the 252 new Class-Types). 254 It may be desirable to prevent a Class-Type from being starved by 255 others. In the example given above where we defined three Class- 256 Types, it may be useful to be able to always ensure that some amount 257 of Class-Type 0 LSPs can be routed over that link (i.e. to prevent 259 Le Faucheur et. al 5 260 Class-Type 1 LSPs and Class-Type 2 LSPs from reserving up to 100% of 261 the maximum reservable aggregate bandwidth which would result in 262 Class-Type 0 LSPs not having any access to the capacity of that 263 link). Such capability would require the ability from the IGP to 264 advertise an optional "minimum reservable bandwidth" per Class-Type. 265 This is not seen as an immediate requirement but could be defined in 266 the future if required. 268 3. Requirements for RSVP/CR-LDP Extensions 270 [RSVP-TE] and [CR-LDP] define extensions to RSVP and LDP for support 271 of (aggregate) MPLS Traffic Engineering. [DIFF-MPLS] defines the 272 extensions to RSVP and LDP for support of Diff-Serv over MPLS. In 273 this section we define the requirements on RSVP and CR-LDP for 274 support of Diff-Serv Traffic Engineering on a per-Class-Type basis. 275 These requirements are expected to require further extensions to 276 RSVP and CR-LDP. Such extensions are proposed in [DIFF-TE-EXT]. 278 In order for an LSR to perform resource availability checking for an 279 LSP that belongs to a certain Class-Type, the LSR needs to be made 280 aware through RSVP/CR-LDP signaling of the Class-Type associated 281 with the LSP. 283 To that end, we propose that RSVP/CR-LDP be extended to be able to 284 signal the Class-Type. 286 We identify the following backward compatibility requirements for 287 the RSVP/CR-LDP extensions: 288 - operations in heterogeneous environments need to be supported 289 for smooth migration, where some LSRs are Diff-Serv-TE-capable 290 (as defined in this specification) while some other LSRs are not 291 Diff-Serv-TE-capable (i.e. support (aggregate) TE only) 292 - in heterogeneous environments, the solution needs to allow 293 establishment of Class-Type 0 LSPs across paths combining Diff- 294 Serv-TE-capable LSRs and non-Diff-Serv-TE-capable LSRs 295 - in heterogeneous environments, the solution needs to ensure that 296 a non-Diff-Serv-TE-capable LSR would reject establishment of a 297 Class-Type N (N=1,2,3) LSP. 299 The admission control algorithm implemented for LSP establishment 300 must locally maintain different variables which keep track of the 301 currently unreserved bandwidth for each Class-Type. These unreserved 302 bandwidth variables must be updated in accordance with the approach 303 discussed in the previous section for enforcement of the Maximum 304 Reservable Aggregate Bandwidth across all Class-Types, if so 305 configured on an LSR. In particular, when admitting a Class-Type N 306 LSP, the LSR must take into account this Class-Type N LSP to update 307 the variables tracking the unreserved bandwidth for Class-Type N, as 308 well as to potentially update the variables tracking the unreserved 309 bandwidth for the other Class-Types (since the new LSP eats-up 311 Le Faucheur et. al 6 312 Aggregate bandwidth which in turn may reduce the amount of LSP that 313 may be established in other Class-Types). 315 4. Requirements for Constraint Based Routing Extensions 317 In order for Constraint Based Routing to support Diff-Serv TE on a 318 per-Class-Type basis, the Constraint Based Routing algorithm need to 319 be capable of taking into account the "Unreserved Bandwidth for 320 Class-Type N" when computing a path for a Class-Type N LSP. 322 5. Requirements for MIB Extensions 324 In order for an LSR to support the configuration and monitoring of 325 Diff-Serv Traffic Engineering certain enhancements to some of the 326 existing MPLS Management Information Bases (MIBs) will be required. 327 [LSRMIB] defines the MPLS Label Switch Router MIB (LSR MIB) which 328 contains objects useful for the management and configuration of MPLS 329 LSPs. [TE MIB] defines the MPLS Traffic Engineering MIB (TE MIB) 330 which contains objects useful for the management and configuration 331 of MPLS Traffic Engineered Tunnels. 333 In particular, the MIB extensions need to: 334 - track for each MPLS interface, the Maximum Reservable Bandwidth 335 configured for each Class-Type. 336 - track for each MPLS interface, the Maximum Reservable Aggregate 337 Bandwidth configured. 338 - track for each LSP, the Class-Type associated with the LSP. On 339 the Head-End LSRs, the Class-Type is configured as part of the 340 tunnel configuration. On other LSRs, the Class-Type is 341 associated with the LSP at establishment time based on signaled 342 information. 344 Additional details of these changes will be provided in forthcoming 345 versions of this draft. It is the authors' intent to transfer these 346 MIB requirements to future versions of the MPLS TE and the MPLS LSR 347 MIBs. It is not the intent of this document to define the SMI 348 required for the MIB enhancements; rather, it is to flesh out and 349 define the details of these changes in the context of this document. 351 6. Security Considerations 353 The solution developed to address the requirements defined in this 354 document must address security aspects. 356 7. Acknowledgments 358 This document has benefited from discussions with Carol Iturralde 359 and Rob Goguen. 361 Le Faucheur et. al 7 362 References 364 [TE-REQ] Awduche et al, Requirements for Traffic Engineering over 365 MPLS, RFC2702, September 1999. 367 [TEWG-FW] Awduche et al, A Framework for Internet Traffic 368 Engineering, draft-ietf-tewg-framework-01.txt, May 2000. 370 [DIFF-TE-EXT] Le Faucheur et al, Extensions to IS-IS, OSPF, RSVP, 371 CR-LDP and MPLS MIBs for support of Diff-Serv-aware MPLS Traffic 372 Engineering, draft-lefaucheur-diff-te-ext-00.txt, July 2000. 374 [OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF, 375 draft-katz-yeung-ospf-traffic-01.txt, April 2000. 377 [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft- 378 ietf-isis-traffic-01.txt, May 1999. 380 [RSVP-TE] Awduche et al, "Extensions to RSVP for LSP Tunnels", 381 draft-ietf-mpls-rsvp-lsp-tunnel-05.txt, February 2000. 383 [DIFF-MPLS] Le Faucheur et al, "MPLS Support of Diff-Serv", draft- 384 ietf-mpls-diff-ext-05.txt, June 2000 386 [LDP] Andersson et al., "LDP Specification", draft-ietf-mpls-ldp- 387 06.txt, October 1999 389 [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", 390 draft-ietf-mpls-cr-ldp-03.txt, October 1999 392 [TEMIB] Srinivansan, C., and A. Viswanathan, "MPLS Traffic 393 Engineering Management Information Base Using SMIv2", draft-ietf- 394 mpls-te-mib-03.txt, March 10, 2000. 396 [LSRMIB] Srinivansan, C., Viswanathan, A., and T. Nadeau "MPLS 397 Label Switch Router Management Information Base Using SMIv2", draft- 398 ietf-mpls-lsr-mib-04.txt, April 26, 2000. 400 Authors' Address: 402 Francois Le Faucheur 403 Cisco Systems, Inc. 404 Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - 405 France 406 Phone: +33 4 92 96 75 64 407 Email: flefauch@cisco.com 409 Angela Chiu 410 AT&T Labs 412 Le Faucheur et. al 8 413 Rm 4-204,100 Schulz Dr., Red Bank, NJ 07701 414 USA 415 Phone: +1 (732) 345-3441 416 Email: alchiu@att.com 418 William Townsend 419 Tenor Networks 420 100 Nagog Park 421 Acton, MA 01720 422 Phone: +1-978-264-4900 423 Email: btownsend@tenornetworks.com 425 Thomas D. Nadeau 426 Cisco Systems, Inc. 427 250 Apollo Drive 428 Chelmsford, MA 01824 429 Phone: +1-978-244-3051 430 Email: tnadeau@cisco.com 432 Darek Skalecki 433 Nortel Networks 434 3500 Carling Ave, 435 Nepean K2H 8E9 436 Phone: +1-613-765-2252 437 Email: dareks@nortelnetworks.com 439 Le Faucheur et. al 9