idnits 2.17.1 draft-ietf-tewg-diff-te-proto-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1783 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119], [DSTE-REQ]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If a path message contains multiple CLASSTYPE objects, only the first one is meaningful; subsequent CLASSTYPE object(s) MUST be ignored and MUST not be forwarded. -- 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) -- Looks like a reference, but probably isn't: '0' on line 586 -- Looks like a reference, but probably isn't: '1' on line 452 -- Looks like a reference, but probably isn't: '2' on line 453 -- Looks like a reference, but probably isn't: '3' on line 454 -- Looks like a reference, but probably isn't: '7' on line 587 == Missing Reference: 'N' is mentioned on line 905, but not defined == Missing Reference: 'IANA' is mentioned on line 1110, but not defined == Unused Reference: 'DSTE-MAR' is defined on line 1158, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3564 (ref. 'DSTE-REQ') ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. 'DIFF-ARCH') ** Downref: Normative reference to an Informational RFC: RFC 2702 (ref. 'TE-REQ') ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'ISIS-TE') == Outdated reference: A later version (-07) exists of draft-ietf-tewg-diff-te-russian-04 == Outdated reference: A later version (-04) exists of draft-ietf-tewg-diff-te-mam-01 == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-gmpls-routing-05 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-bundle-04 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-rsvp-lsp-fastreroute-03 Summary: 9 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Francois Le Faucheur, Editor 3 Cisco Systems, Inc. 5 IETF Internet Draft 6 Expires: March, 2004 7 Document: draft-ietf-tewg-diff-te-proto-05.txt September, 2003 9 Protocol extensions for support of 10 Diff-Serv-aware MPLS Traffic Engineering 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. Internet-Drafts are 16 Working documents of the Internet Engineering Task Force (IETF), its 17 areas, and its working groups. Note that other groups may also 18 distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document specifies the IGP and RSVP-TE signaling extensions 33 (beyond those already specified for existing MPLS Traffic 34 Engineering) for support of Diff-Serv-aware MPLS Traffic Engineering 35 (DS-TE). These extensions address the Requirements for DS-TE spelt 36 out in [DSTE-REQ]. 38 Summary for Sub-IP related Internet Drafts 40 RELATED DOCUMENTS: 41 draft-ietf-tewg-diff-te-reqts-07.txt 43 WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK 44 This ID is a Working Group document of the TE Working Group. 46 WHY IS IT TARGETED AT THIS WG(s) 48 Le Faucheur, et. al 1 50 Protocols for Diff-Serv-aware TE September 2003 52 TEWG is responsible for specifying protocol extensions for support of 53 Diff-Serv-aware MPLS Traffic Engineering. 55 JUSTIFICATION 56 The TEWG charter states that "This will entail verification and 57 review of the Diffserv requirements in the WG Framework document and 58 initial specification of how these requirements can be met through 59 use and potentially expansion of existing protocols." 60 In line with this, the TEWG is progressing this Working Group 61 document specifying protocol extensions for Diff-Serv-aware MPLS 62 Traffic Engineering. 64 Specification of Requirements 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in [RFC2119]. 70 1. Introduction 72 [DSTE-REQ] presents the Service Providers requirements for support of 73 Diff-Serv-aware MPLS Traffic Engineering (DS-TE). This includes the 74 fundamental requirement to be able to enforce different bandwidth 75 constraints for different classes of traffic. 77 This document specifies the IGP and RSVP-TE signaling extensions 78 (beyond those already specified for existing MPLS Traffic Engineering 79 [OSPF-TE][ISIS-TE][RSVP-TE]) for support of the DS-TE requirements 80 spelt out in [DSTE-REQ] including environments relying on distributed 81 Constraint Based Routing (e.g. path computation involving Head-end 82 LSRs). 84 [DSTE-REQ] provides a definition and examples of Bandwidth Constraint 85 Models. The present document does not specify nor assume a particular 86 Bandwidth Constraints model. Specific Bandwidth Constraints model are 87 outside the scope of this document. While the extensions for DS-TE 88 specified in this document may not be sufficient to support all the 89 conceivable Bandwidth Constraints models, they do support the 90 "Russian Dolls" Model specified in [DSTE-RDM] and the "Maximum 91 Allocation" Model specified in [DSTE-MAM]. 93 2. Contributing Authors 95 This document was the collective work of several. The text and 96 content of this document was contributed by the editor and the co- 97 authors listed below. (The contact information for the editor appears 98 in Section 17, and is not repeated below.) 100 Le Faucheur et. al 2 102 Protocols for Diff-Serv-aware TE September 2003 104 Jim Boyle Kireeti Kompella 105 Protocol Driven Networks, Inc. Juniper Networks, Inc. 106 1381 Kildaire Farm Road #288 1194 N. Mathilda Ave. 107 Cary, NC 27511, USA Sunnyvale, CA 94099 108 Phone: (919) 852-5160 Email: kireeti@juniper.net 109 Email: jboyle@pdnets.com 111 William Townsend Thomas D. Nadeau 112 Tenor Networks Cisco Systems, Inc. 113 100 Nagog Park 250 Apollo Drive 114 Acton, MA 01720 Chelmsford, MA 01824 115 Phone: +1-978-264-4900 Phone: +1-978-244-3051 116 Email: Email: tnadeau@cisco.com 117 btownsend@tenornetworks.com 119 Darek Skalecki 120 Nortel Networks 121 3500 Carling Ave, 122 Nepean K2H 8E9 123 Phone: +1-613-765-2252 124 Email: dareks@nortelnetworks.com 126 3. Definitions 128 For readability a number of definitions from [DSTE-REQ] are repeated 129 here: 131 Traffic Trunk: an aggregation of traffic flows of the same class 132 [i.e. which are to be treated equivalently from the DS-TE 133 perspective] which are placed inside a Label Switched Path. 135 Class-Type (CT): the set of Traffic Trunks crossing a link that is 136 governed by a specific set of Bandwidth constraints. CT is used for 137 the purposes of link bandwidth allocation, constraint based routing 138 and admission control. A given Traffic Trunk belongs to the same CT 139 on all links. 141 TE-Class: A pair of: 142 i. a Class-Type 143 ii. a preemption priority allowed for that Class-Type. This 144 means that an LSP transporting a Traffic Trunk from 145 that Class-Type can use that preemption priority as the 146 set-up priority, as the holding priority or both. 148 Definitions for a number of MPLS terms are not repeated here. Those 149 can be found in [MPLS-ARCH]. 151 4. Configurable Parameters 153 Le Faucheur et. al 3 155 Protocols for Diff-Serv-aware TE September 2003 157 This section only discusses the differences with the configurable 158 parameters supported for MPLS Traffic Engineering as per [TE-REQ], 159 [ISIS-TE], [OSPF-TE], and [RSVP-TE]. All other parameters are 160 unchanged. 162 4.1. Link Parameters 164 4.1.1. Bandwidth Constraints (BCs) 166 [DSTE-REQ] states that "Regardless of the Bandwidth Constraint Model, 167 the DS-TE solution MUST allow support for up to 8 BCs." 169 For DS-TE, the existing "Maximum Reservable link bandwidth" parameter 170 is retained but its semantic is generalized and interpreted as the 171 aggregate bandwidth constraints across all Class-Types, so that, 172 independently of the Bandwidth Constraint Model in use: 173 SUM (Reserved (CTc)) <= Max Reservable Bandwidth, 174 where the SUM is across all values of "c" in the range 0 <= c <= 7. 176 Additionally, on every link, a DS-TE implementation MUST provide for 177 configuration of up to 8 additional link parameters which are the 178 eight potential Bandwidth Constraints i.e. BC0, BC1 , ... BC7. The 179 LSR MUST interpret these Bandwidth Constraints in accordance with the 180 supported Bandwidth Constraint Model (i.e. what bandwidth constraint 181 applies to what Class-Type and how). 183 Where the Bandwidth Constraint Model imposes some relationship among 184 the values to be configured for these Bandwidth Constraints, the LSR 185 MUST enforce those at configuration time. For example, when the 186 "Russian Doll" Bandwidth Constraints Model ([DSTE-RDM]) is used, the 187 LSR must ensure that BCi is configured smaller or equal to BCj, where 188 i is greater than j, and ensure that BC0 is equal to the Maximum 189 Reservable Bandwidth. As another example, when the Maximum Allocation 190 Model ([DSTE-MAM]) is used, the LSR must ensure that all BCi are 191 configured smaller or equal to the Maximum Reservable Bandwidth. 193 4.1.2. Overbooking 195 DS-TE enables a network administrator to apply different overbooking 196 (or underbooking) ratios for different CTs. 198 The principal methods to achieve this are the same as historically 199 used in existing TE deployment, which are : 200 (i) To take into account the overbooking/underbooking ratio 201 appropriate for the OA/CT associated with the considered LSP 202 at the time of establishing the bandwidth size of a given 203 LSP. We refer to this method as the "LSP Size Overbooking 204 method". AND/OR 205 (ii) To take into account the overbooking/underbooking ratio at 206 the time of configuring the Maximum Reservable 207 Bandwidth/Bandwidth Constraints and use values which are 208 larger(overbooking) or smaller(underbooking) than actually 210 Le Faucheur et. al 4 212 Protocols for Diff-Serv-aware TE September 2003 214 supported by the link. We refer to this method as the "Link 215 Size Overbooking method". 217 The "LSP Size Overbooking" method and the "Link size overbooking" 218 method are expected to be sufficient in many DS-TE environments and 219 require no additional configurable parameters. Other overbooking 220 methods may involve such additional configurable parameters but are 221 beyond the scope of this document. 223 4.2. LSR Parameters 225 4.2.1. TE-Class Mapping 227 In line with [DSTE-REQ], the preemption attributes defined in [TE- 228 REQ] are retained with DS-TE and applicable within, and across, all 229 Class Types. The preemption attributes of setup priority and holding 230 priority retain existing semantics, and in particular these semantics 231 are not affected by the LSP Class Type. This means that if LSP1 232 contends with LSP2 for resources, LSP1 may preempt LSP2 if LSP1 has a 233 higher set-up preemption priority (i.e. lower numerical priority 234 value) than LSP2 holding preemption priority regardless of LSP1 CT 235 and LSP2 CT. 237 DS-TE LSRs MUST allow configuration of a TE-Class mapping whereby the 238 Class-Type and preemption level are configured for each of (up to) 8 239 TE-Classes. 241 This mapping is referred to as : 243 TE-Class[i] <--> < CTc , preemption p > 245 Where 0 <= i <= 7, 0 <= c <= 7, 0 <= p <= 7 247 Two TE-Classes must not be identical (i.e. have both the same Class- 248 Type and the same preemption priority). 250 There are no other restrictions on how any of the 8 Class-Types can 251 be paired up with any of the 8 preemption priorities to form a TE- 252 class. In particular, one given preemption priority can be paired up 253 with two (or more) different Class-Types to form two (or more) TE- 254 classes. Similarly, one Class-Type can be paired up with two (or 255 more) different preemption priorities to form two (or more) TE- 256 Classes. Also, there is no mandatory ordering relationship between 257 the TE-Class index (i.e. "i" above) and the Class-Type (i.e. "c" 258 above) or the preemption priority (i.e. "p" above) of the TE-Class. 260 Where the network administrator uses less than 8 TE-Classes, the DS- 261 TE LSR MUST allow remaining ones to be configured as "Unused". Note 262 that "Configuring all the 8 TE-Classes as "Unused" effectively 263 results in disabling TE/DS-TE since no TE/DS-TE LSP can be 264 established (nor even configured, since as described in section 4.3.3 266 Le Faucheur et. al 5 268 Protocols for Diff-Serv-aware TE September 2003 270 below, the CT and preemption priorities configured for an LSP must 271 form one of the configured TE-Classes)". 273 To ensure coherent DS-TE operation, the network administrator MUST 274 configure exactly the same TE-Class Mapping on all LSRs of the DS-TE 275 domain. 277 When the TE-class mapping needs to be modified in the DS-TE domain, 278 care must be exercised during the transient period of reconfiguration 279 during which some DS-TE LSRs may be configured with the new TE-class 280 mapping while others are still configured with the old TE-class 281 mapping. It is recommended that active tunnels do not use any of the 282 TE-classes which are being modified during such a transient 283 reconfiguration period. 285 4.3. LSP Parameters 287 4.3.1. Class-Type 289 With DS-TE, LSRs MUST support, for every LSP, an additional 290 configurable parameter which indicates the Class-Type of the Traffic 291 Trunk transported by the LSP. 293 There is one and only one Class-Type configured per LSP. 295 The configured Class-Type indicates, in accordance with the supported 296 Bandwidth Constraint Model, what are the Bandwidth Constraints that 297 MUST be enforced for that LSP. 299 4.3.2. Setup and Holding Preemption Priorities 301 As per existing TE, DS-TE LSRs MUST allow every DS-TE LSP to be 302 configured with a setup and holding priority, each with a value 303 between 0 and 7. 305 4.3.3. Class-Type/Preemption Relationship 307 With DS-TE, the preemption priority configured for the setup priority 308 of a given LSP and the Class-Type configured for that LSP must be 309 such that, together, they form one of the (up to) 8 TE-Classes 310 configured in the TE-Class Mapping specified is section 4.2.1 above. 312 The preemption priority configured for the holding priority of a 313 given LSP and the Class-Type configured for that LSP must also be 314 such that, together, they form one of the (up to) 8 TE-Classes 315 configured in the TE-Class Mapping specified is section 4.2.1 above. 317 The LSR MUST enforce these two rules at configuration time. 319 4.4. Examples of Parameters Configuration 321 Le Faucheur et. al 6 323 Protocols for Diff-Serv-aware TE September 2003 325 For illustrative purposes, we now present a few examples of how these 326 configurable parameters may be used. All these examples assume that 327 different bandwidth constraints need to be enforced for different 328 sets of Traffic Trunks (e.g. for Voice and for Data) so that two, or 329 more, Class-Types need to be used. 331 4.4.1. Example 1 333 The Network Administrator of a first network using two Class Types 334 (CT1 for Voice and CT0 for Data), may elect to configure the 335 following TE-Class Mapping to ensure that Voice LSPs are never driven 336 away from their shortest path because of Data LSPs: 338 TE-Class[0] <--> < CT1 , preemption 0 > 339 TE-Class[1] <--> < CT0 , preemption 1 > 340 TE-Class[i] <--> unused, for 2 <= i <= 7 342 Voice LSPs would then be configured with: 343 - CT=CT1, set-up priority =0, holding priority=0 345 Data LSPs would then be configured with: 346 - CT=CT0, set-up priority =1, holding priority=1 348 A new Voice LSP would then be able to preempt an existing Data LSP in 349 case they contend for resources. A Data LSP would never preempt a 350 Voice LSP. A Voice LSP would never preempt another Voice LSP. A Data 351 LSP would never preempt another Data LSP. 353 4.4.2. Example 2 355 The Network Administrator of another network may elect to configure 356 the following TE-Class Mapping in order to optimize global network 357 resource utilization by favoring placement of large LSPs closer to 358 their shortest path: 360 TE-Class[0] <--> < CT1 , preemption 0 > 361 TE-Class[1] <--> < CT0 , preemption 1 > 362 TE-Class[2] <--> < CT1 , preemption 2 > 363 TE-Class[3] <--> < CT0 , preemption 3 > 364 TE-Class[i] <--> unused, for 4 <= i <= 7 366 Large size Voice LSPs could be configured with: 367 - CT=CT1, set-up priority =0, holding priority=0 369 Large size Data LSPs could be configured with: 370 - CT=CT0, set-up priority = 1, holding priority=1 372 Small size Voice LSPs could be configured with: 373 - CT=CT1, set-up priority = 2, holding priority=2 375 Small size Data LSPs could be configured with: 376 - CT=CT0, set-up priority = 3, holding priority=3. 378 Le Faucheur et. al 7 380 Protocols for Diff-Serv-aware TE September 2003 382 A new large size Voice LSP would then be able to preempt a small size 383 Voice LSP or any Data LSP in case they contend for resources. 384 A new large size Data LSP would then be able to preempt a small size 385 Data LSP or a small size Voice LSP in case they contend for 386 resources, but it would not be able to preempt a large size Voice 387 LSP. 389 4.4.3. Example 3 391 The Network Administrator of another network may elect to configure 392 the following TE-Class Mapping in order to ensure that Voice LSPs are 393 never driven away from their shortest path because of Data LSPs while 394 also achieving some optimization of global network resource 395 utilization by favoring placement of large LSPs closer to their 396 shortest path: 398 TE-Class[0] <--> < CT1 , preemption 0 > 399 TE-Class[1] <--> < CT1 , preemption 1 > 400 TE-Class[2] <--> < CT0 , preemption 2 > 401 TE-Class[3] <--> < CT0 , preemption 3 > 402 TE-Class[i] <--> unused, for 4 <= i <= 7 404 Large size Voice LSPs could be configured with: 405 - CT=CT1, set-up priority = 0, holding priority=0. 407 Small size Voice LSPs could be configured with: 408 - CT=CT1, set-up priority = 1, holding priority=1. 410 Large size Data LSPs could be configured with: 411 - CT=CT0, set-up priority = 2, holding priority=2. 413 Small size Data LSPs could be configured with: 414 - CT=CT0, set-up priority = 3, holding priority=3. 416 A Voice LSP could preempt a Data LSP if they contend for resources. A 417 Data LSP would never preempt a Voice LSP. A Large size Voice LSP 418 could preempt a small size Voice LSP if they contend for resources. A 419 Large size Data LSP could preempt a small size Data LSP if they 420 contend for resources. 422 4.4.4. Example 4 424 The Network Administrator of another network may elect to configure 425 the following TE-Class Mapping in order to ensure that no preemption 426 occurs in the DS-TE domain: 428 TE-Class[0] <--> < CT1 , preemption 0 > 429 TE-Class[1] <--> < CT0 , preemption 0 > 430 TE-Class[i] <--> unused, for 2 <= i <= 7 432 Voice LSPs would then be configured with: 434 Le Faucheur et. al 8 436 Protocols for Diff-Serv-aware TE September 2003 438 - CT=CT1, set-up priority =0, holding priority=0 440 Data LSPs would then be configured with: 441 - CT=CT0, set-up priority =0, holding priority=0 443 No LSP would then be able to preempt any other LSP. 445 4.4.5. Example 5 447 The Network Administrator of another network may elect to configure 448 the following TE-Class Mapping in view of increased network stability 449 through a more limited use of preemption: 451 TE-Class[0] <--> < CT1 , preemption 0 > 452 TE-Class[1] <--> < CT1 , preemption 1 > 453 TE-Class[2] <--> < CT0 , preemption 1 > 454 TE-Class[3] <--> < CT0 , preemption 2 > 455 TE-Class[i] <--> unused, for 4 <= i <= 7 457 Large size Voice LSPs could be configured with: 458 - CT=CT1, set-up priority = 0, holding priority=0. 460 Small size Voice LSPs could be configured with: 461 - CT=CT1, set-up priority = 1, holding priority=0. 463 Large size Data LSPs could be configured with: 464 - CT=CT0, set-up priority = 2, holding priority=1. 466 Small size Data LSPs could be configured with: 467 - CT=CT0, set-up priority = 2, holding priority=2. 469 A new large size Voice LSP would be able to preempt a Data LSP in 470 case they contend for resources, but it would not be able to preempt 471 any Voice LSP even a small size Voice LSP. 473 A new small size Voice LSP would be able to preempt a small size Data 474 LSP in case they contend for resources, but it would not be able to 475 preempt a large size Data LSP or any Voice LSP. 477 A Data LSP would not be able to preempt any other LSP. 479 5. IGP Extensions for DS-TE 481 This section only discusses the differences with the IGP 482 advertisement supported for (aggregate) MPLS Traffic Engineering as 483 per [OSPF-TE] and [ISIS-TE]. The rest of the IGP advertisement is 484 unchanged. 486 5.1. Bandwidth Constraints 488 Le Faucheur et. al 9 490 Protocols for Diff-Serv-aware TE September 2003 492 As detailed above in section 4.1.1, up to 8 Bandwidth Constraints 493 ( BCb, 0 <= b <= 7) are configurable on any given link. 495 With DS-TE, the existing "Maximum Reservable Bw" sub-TLV is retained 496 with a generalized semantic so that it MUST now be interpreted as the 497 aggregate bandwidth constraint across all Class-Types [ i.e. 498 SUM (Reserved (CTc)) <= Max Reservable Bandwidth], independently of 499 the Bandwidth Constraints Model. 501 This document also defines the following new optional sub-TLV to 502 advertise the eight potential Bandwidth Constraints (BC0 to BC7): 504 "Bandwidth Constraints" sub-TLV: 505 - Bandwidth Constraint Model Id (1 octet) 506 - Bandwidth Constraints (Nx4 octets) 508 Where: 510 - With OSPF, the sub-TLV is a sub-TLV of the "Link TLV" and its 511 sub-TLV type is TBD. See IANA Considerations section below. 513 - With ISIS, the sub-TLV is a sub-TLV of the "extended IS 514 reachability TLV" and its sub-TLV type is TBD. See IANA 515 Considerations section below. 517 - Bandwidth Constraint Model Id: 1 octet identifier for the 518 Bandwidth Constraints Model currently in use by the LSR 519 initiating the IGP advertisement. 520 - Value 0 identifies the Russian Dolls Model specified in 521 [DSTE-RDM]. 522 - Value 1 identifies the Maximum Allocation Model 523 specified in [DSTE-MAM]. 525 - Bandwidth Constraints: contains BC0, BC1,... BC(N-1). 526 Each Bandwidth Constraint is encoded on 32 bits in IEEE 527 floating point format. The units are bytes (not bits!) per 528 second. Where the configured TE-class mapping and the 529 Bandwidth Constraints model in use are such that BCh+1, 530 BCh+2, ...and BC7 are not relevant to any of the Class-Types 531 associated with a configured TE-class, it is recommended that 532 only the Bandwidth Constraints from BC0 to BCh be advertised, 533 in order to minimize the impact on IGP scalability. 535 A DS-TE LSR MAY optionally advertise Bandwidth Constraints. 537 A DS-TE LSR which does advertise Bandwidth Constraints MUST use the 538 new "Bandwidth Constraints" sub-TLV (in addition to the existing 539 Maximum Reservable Bandwidth sub-TLV) to do so. For example, 540 considering the case where a Service Provider deploys DS-TE with 541 TE-classes associated with CT0 and CT1 only, and where the Bandwidth 542 Constraints model is such that only BC0 and BC1 are relevant to CT0 543 and CT1: a DS-TE LSR which does advertise Bandwidth Constraints would 545 Le Faucheur et. al 10 547 Protocols for Diff-Serv-aware TE September 2003 549 include in the IGP advertisement the Maximum Reservable Bandwidth 550 sub-TLV as well as the "Bandwidth Constraints" sub-TLV, where the 551 former should contain the aggregate bandwidth constraint across all 552 CTs and the latter would contain BC0 and BC1. 554 A DS-TE LSR receiving the "Bandwidth Constraints" sub-TLV with a 555 Bandwidth Constraint Model Id which does not match the Bandwidth 556 Constraint Model it currently uses, MAY generate a warning to the 557 operator reporting the inconsistency between Bandwidth Constraint 558 Models used on different links. Also, in that case, if the DS-TE LSR 559 does not support the Bandwidth Constraint Model designated by the 560 Bandwidth Constraint Model Id, or if the DS-TE LSR does not support 561 operations with multiple simultaneous Bandwidth Constraint Models, 562 the DS-TE LSR MAY discard the corresponding TLV. If the DS-TE LSR 563 does support the Bandwidth Constraint Model designated by the 564 Bandwidth Constraint Model Id and if the DS-TE LSR does support 565 operations with multiple simultaneous Bandwidth Constraint Models, 566 the DS-TE LSR MAY accept the corresponding TLV and allow operations 567 with different Bandwidth Constraints Models used in different parts 568 of the DS-TE domain. 570 5.2. Unreserved Bandwidth 572 With DS-TE, the existing "Unreserved Bandwidth" sub-TLV is retained 573 as the only vehicle to advertise dynamic bandwidth information 574 necessary for Constraint Based Routing on Head-ends, except that it 575 is used with a generalized semantic. The Unreserved Bandwidth sub-TLV 576 still carries eight bandwidth values but they now correspond to the 577 unreserved bandwidth for each of the TE-Class (instead of for each 578 preemption priority as per existing TE). 580 More precisely, a DS-TE LSR MUST support the Unreserved Bandwidth 581 sub-TLV with a definition which is generalized into the following: 583 The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth 584 not yet reserved for each of the eight TE-classes, in IEEE floating 585 point format arranged in increasing order of TE-Class index, with 586 unreserved bandwidth for TE-Class [0] occurring at the start of the 587 sub-TLV, and unreserved bandwidth for TE-Class [7] at the end of the 588 sub-TLV. The unreserved bandwidth value for TE-Class [i] ( 0 <= i <= 589 7) is referred to as "Unreserved TE-Class [i]". It indicates the 590 bandwidth that is available, for reservation, to an LSP which : 591 - transports a Traffic Trunk from the Class-Type of TE- 592 Class[i], and 593 - has a setup priority corresponding to the preemption priority 594 of TE-Class[i]. 596 The units are bytes per second. 598 Since the bandwidth values are now ordered by TE-class index and thus 599 can relate to different CTs with different bandwidth constraints and 601 Le Faucheur et. al 11 603 Protocols for Diff-Serv-aware TE September 2003 605 can relate to any arbitrary preemption priority, a DS-TE LSR MUST NOT 606 assume any ordered relationship among these bandwidth values. 608 With existing TE, since all preemption priorities reflect the same 609 (and only) bandwidth constraints and since bandwidth values are 610 advertised in preemption priority order, the following relationship 611 is always true, and is often assumed by TE implementations: 613 If i < j , then "Unreserved Bw [i]" >= "Unreserved Bw [j]" 615 With DS-TE, no relationship is to be assumed so that: 616 If i < j , then any of the following relationship may be true 617 "Unreserved TE-Class [i]" = "Unreserved TE-Class [j]" 618 OR 619 "Unreserved TE-Class [i]" > "Unreserved TE-Class [j]" 620 OR 621 "Unreserved TE-Class [i]" < "Unreserved TE-Class [j]". 623 Rules for computing "Unreserved TE-Class [i]" are specified in 624 section 11. 626 If TE-Class[i] is unused, the value advertised by the IGP in 627 "Unreserved TE-Class [i]" MUST be set to zero by the LSR generating 628 the IGP advertisement, and MUST be ignored by the LSR receiving the 629 IGP advertisement. 631 6. RSVP-TE Extensions for DS-TE 633 In this section we describe extensions to RSVP-TE for support of 634 Diff-Serv-aware MPLS Traffic Engineering. These extensions are in 635 addition to the extensions to RSVP defined in [RSVP-TE] for support 636 of (aggregate) MPLS Traffic Engineering and to the extensions to RSVP 637 defined in [DIFF-MPLS] for support of Diff-Serv over MPLS. 639 6.1. DS-TE related RSVP Messages Format 641 One new RSVP Object is defined in this document: the CLASSTYPE 642 Object. Detailed description of this Object is provided below. This 643 new Object is applicable to Path messages. This specification only 644 defines the use of the CLASSTYPE Object in Path messages used to 645 establish LSP Tunnels in accordance with [RSVP-TE] and thus 646 containing a Session Object with a C-Type equal to LSP_TUNNEL_IPv4 647 and containing a LABEL_REQUEST object. 649 Restrictions defined in [RSVP-TE] for support of establishment of LSP 650 Tunnels via RSVP-TE are also applicable to the establishment of LSP 651 Tunnels supporting DS-TE. For instance, only unicast LSPs are 652 supported and Multicast LSPs are for further study. 654 Le Faucheur et. al 12 656 Protocols for Diff-Serv-aware TE September 2003 658 This new CLASSTYPE object is optional with respect to RSVP so that 659 general RSVP implementations not concerned with MPLS LSP set up do 660 not have to support this object. 662 An LSR supporting DS-TE MUST support the CLASSTYPE Object. 664 6.1.1. Path Message Format 666 The format of the Path message is as follows: 668 ::= [ ] 669 670 671 [ ] 672 673 [ ] 674 [ ] 675 [ ] 676 [ ... ] 677 [ ] 679 ::= [ ] 680 [ ] 681 [ ] 683 6.2. CLASSTYPE Object 685 The CLASSTYPE object format is shown below. 687 6.2.1. CLASSTYPE object 689 class = TBD, C_Type = 1 (need to get an official class num from the 690 IANA with the form 0bbbbbbb). See IANA Considerations section below. 692 0 1 2 3 693 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Reserved | CT | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 Reserved : 29 bits 699 This field is reserved. It must be set to zero on transmission 700 and must be ignored on receipt. 702 CT : 3 bits 703 Indicates the Class-Type. Values currently allowed are 704 1, 2, ... , 7. 706 6.3. Handling CLASSTYPE Object 708 Le Faucheur et. al 13 710 Protocols for Diff-Serv-aware TE September 2003 712 To establish an LSP tunnel with RSVP, the sender LSR creates a Path 713 message with a session type of LSP_Tunnel_IPv4 and with a 714 LABEL_REQUEST object as per [RSVP-TE]. The sender LSR may also 715 include the DIFFSERV object as per [DIFF-MPLS]. 717 If the LSP is associated with Class-Type 0, the sender LSR MUST NOT 718 include the CLASSTYPE object in the Path message. 720 If the LSP is associated with Class-Type N (1 <= N <=7), the sender 721 LSR MUST include the CLASSTYPE object in the Path message with the 722 Class-Type (CT) field set to N. 724 If a path message contains multiple CLASSTYPE objects, only the first 725 one is meaningful; subsequent CLASSTYPE object(s) MUST be ignored and 726 MUST not be forwarded. 728 Each LSR along the path MUST record the CLASSTYPE object, when 729 present, in its path state block. 731 If the CLASSTYPE object is not present in the Path message, the LSR 732 MUST associate the Class-Type 0 to the LSP. 734 The destination LSR responding to the Path message by sending a Resv 735 message MUST NOT include a CLASSTYPE object in the Resv message 736 (whether the Path message contained a CLASSTYPE object or not). 738 During establishment of an LSP corresponding to the Class-Type N, the 739 LSR MUST perform admission control over the bandwidth available for 740 that particular Class-Type. 742 An LSR that recognizes the CLASSTYPE object and that receives a path 743 message which contains the CLASSTYPE object but which does not 744 contain a LABEL_REQUEST object or which does not have a session type 745 of LSP_Tunnel_IPv4, MUST send a PathErr towards the sender with the 746 error code 'Diff-Serv-aware TE Error' and an error value of 747 'Unexpected CLASSTYPE object'. Those are defined below in section 748 6.5. 750 An LSR receiving a Path message with the CLASSTYPE object, which 751 recognizes the CLASSTYPE object but does not support the particular 752 Class-Type, MUST send a PathErr towards the sender with the error 753 code 'Diff-Serv-aware TE Error' and an error value of 'Unsupported 754 Class-Type'. Those are defined below in section 6.5. 756 An LSR receiving a Path message with the CLASSTYPE object, which 757 recognizes the CLASSTYPE object but determines that the Class-Type 758 value is not valid (i.e. Class-Type value 0), MUST send a PathErr 759 towards the sender with the error code 'Diff-Serv-aware TE Error' and 760 an error value of 'Invalid Class-Type value'. Those are defined below 761 in section 6.5. 763 An LSR receiving a Path message with the CLASSTYPE object, which: 765 Le Faucheur et. al 14 767 Protocols for Diff-Serv-aware TE September 2003 769 - recognizes the CLASSTYPE object, 770 - supports the particular Class-Type, but 771 - determines that the tuple formed by (i) this Class-Type and 772 (ii) the set-up priority signaled in the same Path message, 773 is not one of the eight TE-classes configured in the TE-class 774 mapping, 775 MUST send a PathErr towards the sender with the error code 'Diff- 776 Serv-aware TE Error' and an error value of 'CT and setup priority do 777 not form a configured TE-Class'. Those are defined below in section 778 6.5. 780 An LSR receiving a Path message with the CLASSTYPE object, which: 781 - recognizes the CLASSTYPE object, 782 - supports the particular Class-Type, but 783 - determines that the tuple formed by (i) this Class-Type and 784 (ii) the holding priority signaled in the same Path message, 785 is not one of the eight TE-classes configured in the TE-class 786 mapping, 787 MUST send a PathErr towards the sender with the error code 'Diff- 788 Serv-aware TE Error' and an error value of 'CT and holding priority 789 do not form a configured TE-Class'. Those are defined below in 790 section 6.5. 792 An LSR receiving a Path message with the CLASSTYPE object and with 793 the DIFFSERV object for an L-LSP, which: 794 - recognizes the CLASSTYPE object, 795 - has local knowledge of the relationship between Class-Types 796 and PSC (e.g. via configuration) 797 - based on this local knowledge, determines that the PSC 798 signaled in the DIFFSERV object is inconsistent with the 799 Class-Type signaled in the CLASSTYPE object, 800 MUST send a PathErr towards the sender with the error code 'Diff- 801 Serv-aware TE Error' and an error value of 'Inconsistency between 802 signaled PSC and signaled CT'. Those are defined below in section 803 6.5. 805 An LSR receiving a Path message with the CLASSTYPE object and with 806 the DIFFSERV object for an E-LSP, which: 807 - recognizes the CLASSTYPE object, 808 - has local knowledge of the relationship between Class-Types 809 and PHBs (e.g. via configuration) 810 - based on this local knowledge, determines that the PHBs 811 signaled in the MAP entries of the DIFFSERV object are 812 inconsistent with the Class-Type signaled in the CLASSTYPE 813 object, 814 MUST send a PathErr towards the sender with the error code 'Diff- 815 Serv-aware TE Error' and an error value of 'Inconsistency between 816 signaled PHBs and signaled CT'. Those are defined below in section 817 6.5. 819 An LSR MUST handle the situations where the LSP can not be accepted 820 for other reasons than those already discussed in this section, in 822 Le Faucheur et. al 15 824 Protocols for Diff-Serv-aware TE September 2003 826 accordance with [RSVP-TE] and [DIFF-MPLS] (e.g. a reservation is 827 rejected by admission control, a label can not be associated). 829 6.4. Non-support of the CLASSTYPE Object 831 An LSR that does not recognize the CLASSTYPE object Class-Num MUST 832 behave in accordance with the procedures specified in [RSVP] for an 833 unknown Class-Num whose format is 0bbbbbbb (i.e. it must send a 834 PathErr with the error code 'Unknown object class' toward the 835 sender). 837 An LSR that recognizes the CLASSTYPE object Class-Num but does not 838 recognize the CLASSTYPE object C-Type, MUST behave in accordance with 839 the procedures specified in [RSVP] for an unknown C-type (i.e. it 840 must send a PathErr with the error code 'Unknown object C-Type' 841 toward the sender). 843 In both situations, this causes the path set-up to fail. The sender 844 SHOULD notify management that a LSP cannot be established and 845 possibly might take action to retry reservation establishment without 846 the CLASSTYPE object. 848 6.5. Error Codes For Diff-Serv-aware TE 850 In the procedures described above, certain errors must be reported as 851 a 'Diff-Serv-aware TE Error'. The value of the 'Diff-Serv-aware TE 852 Error' error code is (TBD). See IANA Considerations section below. 854 The following defines error values for the Diff-Serv-aware TE Error: 856 Value Error 858 1 Unexpected CLASSTYPE object 859 2 Unsupported Class-Type 860 3 Invalid Class-Type value 861 4 CT and setup priority do not form a configured TE-Class 862 5 CT and holding priority do not form a configured 863 TE-Class 864 6 Inconsistency between signaled PSC and signaled CT 865 7 Inconsistency between signaled PHBs and signaled CT 867 7. DS-TE support with MPLS extensions. 869 There are a number of extensions to the initial base specification 870 for signaling [RSVP-TE] and IGP support for TE [OSPF-TE][ISIS-TE]. 871 Those include enhancements for generalization [GMPLS-SIG] 872 [GMPLS-ROUTE], as well as for additional functionality such as LSP 873 hierarchy [HIERARCHY], link bundling [BUNDLE] and fast restoration 874 [REROUTE]. These specifications may reference how to encode 875 information associated with certain preemption priorities, how to 876 treat LSPs at different preemption priorities, or otherwise specify 878 Le Faucheur et. al 16 880 Protocols for Diff-Serv-aware TE September 2003 882 encodings or behavior that have a different meaning for an DS-TE 883 router. 885 In order for an implementation to support both this specification for 886 Diff-Serv-aware TE and a given MPLS enhancement such as those listed 887 above (but not limited to those), it MUST treat references to 888 "preemption priority" and to "Maximum Reservable Bandwidth" in a 889 generalized manner, such as it is used in this specification. 891 Additionally, current and future MPLS enhancements may include more 892 precise specification for how they interact with Diff-Serv-aware TE. 894 7.1. DS-TE support and references to preemption priority 896 When a router supports both Diff-Serv-aware TE and one of the MPLS 897 protocol extensions such as those mentioned above, encoding of values 898 of preemption priority in signaling or encoding of information 899 associated with preemption priorities in IGP defined for the MPLS 900 extension, MUST be considered to be an encoding of the same 901 information for the corresponding TE-Class. For instance, if an MPLS 902 enhancement specifies advertisement in IGP of a parameter for routing 903 information at preemption priority N, in a DS-TE environment it MUST 904 actually be interpreted as specifying advertisement of the same 905 routing information but for TE-Class [N]. On receipt, DS-TE routers 906 MUST interpret it as such as well. 908 When there is discussion on how to comparatively treat LSPs of 909 different preemption priority, a DS-TE LSR MUST treat the preemption 910 priorities in this context as the preemption priorities associated 911 with the TE-Classes of the LSPs in question. 913 7.2. DS-TE support and references to Maximum Reservable Bandwidth 915 When a router supports both Diff-Serv-aware TE and MPLS protocol 916 extensions such as those mentioned above, advertisements of Maximum 917 Reservable Bandwidth MUST be done with the generalized interpretation 918 defined above in section 4.1.1 as the aggregate bandwidth constraint 919 across all Class-Types and MAY also allow the optional advertisement 920 of all Bandwidth Constraints. 922 8. Constraint Based Routing 924 Let us consider the case where a path needs to be computed for an LSP 925 whose Class-Type is configured to CTc and whose set-up preemption 926 priority is configured to p. 928 Then the pair of CTc and p will map to one of the TE-Classes defined 929 in the TE-Class mapping. Let us refer to this TE-Class as TE- 930 Class[i]. 932 Le Faucheur et. al 17 934 Protocols for Diff-Serv-aware TE September 2003 936 The Constraint Based Routing algorithm of a DS-TE LSR is still only 937 required to perform path computation satisfying a single bandwidth 938 constraint which is to fit in "Unreserved TE-Class [i]" as advertised 939 by the IGP for every link. Thus, no changes are required to the 940 existing TE Constraint Based Routing algorithm itself. 942 The Constraint Based Routing algorithm MAY also optionally take into 943 account, when used, the optional additional information advertised in 944 IGP such as the Bandwidth Constraints and the Maximum Reservable 945 Bandwidth. As an example, the Bandwidth Constraints MIGHT be used as 946 a tie-breaker criteria in situations where multiple paths, otherwise 947 equally attractive, are possible. 949 9. Diff-Serv scheduling 951 The Class-Type signaled at LSP establishment MAY optionally be used 952 by DS-TE LSRs to dynamically adjust the resources allocated to the 953 Class-Type by the Diff-Serv scheduler. In addition, the Diff-Serv 954 information (i.e. the PSC) signaled by the TE-LSP signaling protocols 955 as specified in [DIFF-MPLS], if used, MAY optionally be used by DS-TE 956 LSRs to dynamically adjust the resources allocated to a PSC/OA within 957 a Class Type by the Diff-Serv scheduler. 959 10. Existing TE as a Particular Case of DS-TE 961 We observe that existing TE can be viewed as a particular case of 962 DS-TE where: 964 (i) a single Class-Type is used, 965 (ii) all 8 preemption priorities are allowed for that Class- 966 Type, and 967 (iii) the following TE-Class Mapping is used: 968 TE-Class[i] <--> < CT0 , preemption i > 969 Where 0 <= i <= 7. 971 In that case, DS-TE behaves as existing TE. 973 As with existing TE, the IGP advertises: 974 - Unreserved Bandwidth for each of the 8 preemption priorities 976 As with existing TE, the IGP may advertise: 977 - Maximum Reservable Bandwidth containing an a bandwidth 978 constraint applying across all LSPs 980 Since all LSPs transport traffic from CT0, RSVP-TE signaling is done 981 without explicit signaling of the Class-Type (which is only used for 982 other Class-Types than CT0 as explained in section 6) as with 983 existing TE. 985 Le Faucheur et. al 18 987 Protocols for Diff-Serv-aware TE September 2003 989 11. Computing "Unreserved TE-Class [i]" and Admission Control Rules 991 11.1. Computing "Unreserved TE-Class [i]" 993 We first observe that, for existing TE, details on admission control 994 algorithms for TE LSPs, and consequently details on formulas for 995 computing the unreserved bandwidth, are outside the scope of the 996 current IETF work. This is left for vendor differentiation. Note that 997 this does not compromise interoperability across various 998 implementations since the TE schemes rely on LSRs to advertise their 999 local view of the world in terms of Unreserved Bw to other LSRs. This 1000 way, regardless of the actual local admission control algorithm used 1001 on one given LSR, Constraint Based Routing on other LSRs can rely on 1002 advertised information to determine whether an additional LSP will be 1003 accepted or rejected by the given LSR. The only requirement is that 1004 an LSR advertises unreserved bandwidth values which are consistent 1005 with its specific local admission control algorithm and take into 1006 account the holding preemption priority of established LSPs. 1008 In the context of DS-TE, again, details on admission control 1009 algorithms are left for vendor differentiation and formulas for 1010 computing the unreserved bandwidth for TE-Class[i] are outside the 1011 scope of this specification. However, DS-TE places the additional 1012 requirement on the LSR that the unreserved bandwidth values 1013 advertised MUST reflect all of the Bandwidth Constraints relevant to 1014 the CT associated with TE-Class[i] in accordance with the Bandwidth 1015 Constraints Model. Thus, formulas for computing "Unreserved TE-Class 1016 [i]" depend on the Bandwidth Constraints model in use and MUST 1017 reflect how bandwidth constraints apply to CTs. Example formulas for 1018 computing "Unreserved TE-Class [i]" Model are provided for the 1019 Russian Dolls Model and Maximum Allocation Model respectively in 1020 [DSTE-RDM] and [DSTE-MAM]. 1022 As with existing TE, DS-TE LSRs MUST consider the holding preemption 1023 priority of established LSPs (as opposed to their set-up preemption 1024 priority) for the purpose of computing the unreserved bandwidth for 1025 TE-Class [i]. 1027 11.2. Admission Control Rules 1029 A DS-TE LSR MUST support the following admission control rule: 1031 Regardless of how the admission control algorithm actually computes 1032 the unreserved bandwidth for TE-Class[i] for one of its local link, 1033 an LSP of bandwidth B, of set-up preemption priority p and of Class- 1034 Type CTc is admissible on that link iff: 1036 B <= Unreserved Bandwidth for TE-Class[i] 1038 Where 1040 Le Faucheur et. al 19 1042 Protocols for Diff-Serv-aware TE September 2003 1044 - TE-Class [i] maps to < CTc , p > in the LSR's configured TE- 1045 Class mapping 1047 12. Security Considerations 1049 This document does not introduce additional security threats beyond 1050 those inherent to Diff-Serv and MPLS Traffic Engineering and the same 1051 security mechanisms proposed for these technologies are applicable 1052 and may be used. For example, the approach for defense against theft- 1053 and denial-of-service attacks discussed in [DIFF-ARCH], which 1054 consists of the combination of traffic conditioning at DS boundary 1055 nodes along with security and integrity of the network infrastructure 1056 within a Diff-Serv domain, may be followed when DS-TE is in use. 1057 Also, as stated in [TE-REQ], it is specifically important that 1058 manipulation of administratively configurable parameters (such as 1059 those related to DS-TE LSPs) be executed in a secure manner by 1060 authorized entities. 1062 13. Acknowledgments 1064 We thank Martin Tatham, Angela Chiu and Pete Hicks for their earlier 1065 contribution in this work. We also thank Sanjaya Choudhury for his 1066 thorough review and suggestions. 1068 14. IANA Considerations 1070 This document defines a number of objects with implications for IANA. 1072 This document defines in section 5.1 a new sub-TLV, the "Bandwidth 1073 Constraints" sub-TLV, for the OSPF "Link" TLV [OSPF-TE]. A sub-TLV 1074 Type in the range 10 to 32767 needs to be assigned by Expert Review. 1075 This sub-TLV Type also needs to be registered by IANA. 1077 This document defines in section 5.1 a new sub-TLV, the "Bandwidth 1078 Constraints" sub-TLV, for the ISIS "Extended IS Reachability" TLV 1079 [ISIS-TE]. A sub-TLV Type needs to be assigned by Expert Review. This 1080 sub-TLV Type also needs to be registered by IANA. 1082 This document defines in section 5.3 a "Bandwidth Constraint Model 1083 Id" field within the "Bandwidth Constraints" sub-TLV. This document 1084 also defines in section 5.3 two values for this field (0 and 1). 1085 Future allocations of values in this space and in the range 2 to 127 1086 should be handled by IANA using the First Come First Served policy 1087 defined in [IANA]. Values in the range 128 to 255 are reserved for 1088 experimental use. 1090 This document defines in section 6.2.1 a new RSVP object, the 1091 CLASSTYPE object. This object requires a number from the space 1092 defined in [RSVP] for those objects which, if not understood, cause 1094 Le Faucheur et. al 20 1096 Protocols for Diff-Serv-aware TE September 2003 1098 the entire RSVP message to be rejected with an error code of "Unknown 1099 Object Class". Such objects are identified by a zero in the most 1100 significant bit of the class number. Within that space, this object 1101 requires a number to be allocated by IANA from the "IETF Consensus" 1102 space. 1104 This document defines in section 6.5 a new RSVP error code, the 1105 "Diff-Serv-aware TE Error". This new Error code needs to be allocated 1106 by IANA. This document defines values 1 through 7 of the value field 1107 to be used within the ERROR_SPEC object for the "Diff-Serv-aware TE 1108 error" code. Future allocations of values in this space should be 1109 handled by IANA using the First Come First Served policy defined in 1110 [IANA]. 1112 15. Normative References 1114 [DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv- 1115 aware MPLS Traffic Engineering, RFC3564, . 1117 [MPLS-ARCH] Rosen et al., "Multiprotocol Label Switching 1118 Architecture", RFC3031. 1120 [DIFF-ARCH] Blake et al., "An Architecture for Differentiated 1121 Services", RFC2475. 1123 [TE-REQ] Awduche et al., "Requirements for Traffic Engineering Over 1124 MPLS", RFC2702. 1126 [OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF, draft- 1127 katz-yeung-ospf-traffic-10.txt, June 2003. 1129 [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft- 1130 ietf-isis-traffic-05.txt, August 2003. 1132 [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 1133 Tunnels", RFC 3209, December 2001. 1135 [RSVP] Braden et al, "Resource ReSerVation Protocol (RSVP) - Version 1136 1 Functional Specification", RFC 2205, September 1997. 1138 [DIFF-MPLS] Le Faucheur et al, "MPLS Support of Diff-Serv", RFC3270, 1139 May 2002. 1141 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 1142 Requirement Levels, RFC2119, March 1997. 1144 16. Informative References 1146 Le Faucheur et. al 21 1148 Protocols for Diff-Serv-aware TE September 2003 1150 [DSTE-RDM] Le Faucheur et al., "Russian Dolls Bandwidth Constraints 1151 Model for DS-TE", draft-ietf-tewg-diff-te-russian-04.txt, September 1152 2003 1154 [DSTE-MAM] Le Faucheur, Lai, "Maximum Allocation Bandwidth 1155 Constraints Model for DS-TE", draft-ietf-tewg-diff-te-mam-01.txt, 1156 September 2003. 1158 [DSTE-MAR] Ash, "Max Allocation with Reservation Bandwidth Constraint 1159 Model for MPLS/DiffServ TE & Performance Comparisons", March 2003. 1161 [GMPLS-SIG] Berger et. al., "Generalized Multi-Protocol Label 1162 Switching (GMPLS) Signaling Functional Description", RFC3471 1164 [GMPLS-ROUTE] Kompella et. al., "Routing Extensions in Support of 1165 Generalized MPLS", draft-ietf-ccamp-gmpls-routing-05.txt, work in 1166 progress. 1168 [BUNDLE] Kompella, Rekhter, Berger, "Link Bundling in MPLS Traffic 1169 Engineering", draft-ietf-mpls-bundle-04.txt, work in progress. 1171 [HIERARCHY] Kompella, Rekhter, "LSP Hierarchy with Generalized MPLS 1172 TE", draft-ietf-mpls-lsp-hierarchy-08.txt, work in progress. 1174 [REROUTE] Pan et. al., "Fast Reroute Extensions to RSVP-TE for LSP 1175 Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt, work in 1176 progress. 1178 17. Editor's Address: 1180 Francois Le Faucheur 1181 Cisco Systems, Inc. 1182 Village d'Entreprise Green Side - Batiment T3 1183 400, Avenue de Roumanille 1184 06410 Biot-Sophia Antipolis 1185 France 1186 Phone: +33 4 97 23 26 19 1187 Email: flefauch@cisco.com 1189 Appendix A - Prediction for Multiple Path Computation 1191 There are situations where a Head-End needs to compute paths for 1192 multiple LSPs over a short period of time. There are potential 1193 advantages for the Head-end in trying to predict the impact of the n- 1194 th LSP on the unreserved bandwidth when computing the path for the 1195 (n+1)-th LSP, before receiving updated IGP information. One example 1196 would be to perform better load-distribution of the multiple LSPs 1197 across multiple paths. Another example would be to avoid CAC 1198 rejection when the (n+1)-th LSP would no longer fit on a link after 1199 establishment of the n-th LSP. While there are also a number of 1201 Le Faucheur et. al 22 1203 Protocols for Diff-Serv-aware TE September 2003 1205 conceivable scenarios where doing such predictions might result in a 1206 worse situation, it is more likely to improve the situation. As a 1207 matter of fact, a number of network administrators have elected to 1208 use such predictions when deploying existing TE. 1210 Such predictions are local matters, are optional and are outside the 1211 scope of this specification. 1213 Where such predictions are not used, the optional Bandwidth 1214 Constraint sub-TLV and the optional Maximum Reservable Bandwidth sub- 1215 TLV need not be advertised in IGP for the purpose of path computation 1216 since the information contained in the Unreserved Bw sub-TLV is all 1217 that is required by Head-Ends to perform Constraint Based Routing. 1219 Where such predictions are used on Head-Ends, the optional Bandwidth 1220 Constraint sub-TLV and the optional Maximum Reservable Bandwidth sub- 1221 TLV MAY be advertised in IGP. This is in order for the Head-ends to 1222 predict as accurately as possible how an LSP affects unreserved 1223 bandwidth values for subsequent LSPs. 1225 Remembering that actual admission control algorithms are left for 1226 vendor differentiation, we observe that predictions can only be 1227 performed effectively when the Head-end LSR predictions are based on 1228 the same (or a very close) admission control algorithm as used by 1229 other LSRs. 1231 Appendix B - Solution Evaluation 1233 1. Satisfying Detailed Requirements 1235 This DS-TE Solution addresses all the scenarios presented in [DSTE- 1236 REQ]. 1238 It also satisfies all the detailed requirements presented in [DSTE- 1239 REQ]. 1241 The objective set out in the last paragraph of section "4.7 1242 overbooking" of [DSTE-REQ] is only partially addressed by this DS-TE 1243 solution. Through support of the "LSP Size Overbooking" and "Link 1244 Size Overbooking" methods, this DS-TE solution effectively allows CTs 1245 to have different overbooking ratios and simultaneously allows 1246 overbooking to be tweaked differently (collectively across all CTs) 1247 on different links. But, in a general sense, it does not allow the 1248 effective overbooking ratio of every CT to be tweaked differently in 1249 different parts of the network independently of other CTs, while 1250 maintaining accurate bandwidth accounting of how different CTs 1251 mutually affect each other through shared Bandwidth Constraints (such 1252 as the Maximum Reservable Bandwidth). 1254 2. Flexibility 1256 Le Faucheur et. al 23 1258 Protocols for Diff-Serv-aware TE September 2003 1260 This DS-TE solution supports 8 CTs. It is entirely flexible as to how 1261 Traffic Trunks are grouped together into a CT. 1263 3. Extendibility 1265 A maximum of 8 CTs is considered by the authors of this document as 1266 more than comfortable. However, this solution could be extended to 1267 support more CTs if deemed necessary in the future. However, this 1268 would necessitate additional IGP extensions beyond those specified in 1269 this document. 1271 Although the prime objective of this solution is support of Diff- 1272 Serv-aware Traffic Engineering, its mechanisms are not tightly 1273 coupled with Diff-Serv. This makes the solution amenable, or more 1274 easily extendable, for support of potential other future Traffic 1275 Engineering applications. 1277 4. Scalability 1279 This DS-TE solution is expected to have a very small scalability 1280 impact compared to existing TE. 1282 From an IGP viewpoint, the amount of mandatory information to be 1283 advertised is identical to existing TE. One additional sub-TLV has 1284 been specified, but its use is optional and it only contains a 1285 limited amount of static information (at most 8 Bandwidth 1286 Constraints). 1288 We expect no noticeable impact on LSP Path computation since, as with 1289 existing TE, this solution only requires CSPF to consider a single 1290 unreserved bandwidth value for any given LSP. 1292 From a signaling viewpoint we expect no significant impact due to 1293 this solution since it only requires processing of one additional 1294 information (the Class-Type) and does not significantly increase the 1295 likelihood of CAC rejection. Note that DS-TE has some inherent impact 1296 on LSP signaling in the sense that it assumes that different classes 1297 of traffic are split over different LSPs so that more LSPs need to be 1298 signaled; but this is due to the DS-TE concept itself and not to the 1299 actual DS-TE solution discussed here. 1301 5. Backward Compatibility/Migration 1303 This solution is expected to allow smooth migration from existing TE 1304 to DS-TE. This is because existing TE can be supported as a 1305 particular configuration of DS-TE. This means that an "upgraded" LSR 1306 with a DS-TE implementation can directly interwork with an "old" LSR 1307 supporting existing TE only. 1309 This solution is expected to allow smooth migration when increasing 1310 the number of CTs actually deployed since it only requires 1312 Le Faucheur et. al 24 1314 Protocols for Diff-Serv-aware TE September 2003 1316 configuration changes. however, these changes must be performed in a 1317 coordinated manner across the DS-TE domain. 1319 Appendix C - Interoperability with non DS-TE capable LSRs 1321 This DSTE solution allows operations in a hybrid network where some 1322 LSRs are DS-TE capable while some LSRs and not DS-TE capable, which 1323 may occur during migration phases. This Appendix discusses the 1324 constraints and operations in such hybrid networks. 1326 We refer to the set of DS-TE capable LSRs as the DS-TE domain. We 1327 refer to the set of non DS-TE capable (but TE capable) LSRs as the 1328 TE-domain. 1330 Hybrid operations requires that the TE-class mapping in the DS-TE 1331 domain is configured so that: 1332 - a TE-class exist for CT0 for every preemption priority 1333 actually used in the TE domain 1334 - the index in the TE-class mapping for each of these TE- 1335 classes is equal to the preemption priority. 1337 For example, imagine the TE domain uses preemption 2 and 3. Then, DS- 1338 TE can be deployed in the same network by including the following TE- 1339 classes in the TE-class mapping: 1340 i <---> CT preemption 1341 ==================================== 1342 2 CT0 2 1343 3 CT0 3 1345 Another way to look at this is to say that, the whole TE-class 1346 mapping does not have to be consistent with the TE domain, but the 1347 subset of this TE-Class mapping applicable to CT0 must effectively be 1348 consistent with the TE domain. 1350 Hybrid operations also requires that: 1351 - non DS-TE capable LSRs be configured to advertise the Maximum 1352 Reservable Bandwidth 1353 - DS-TE capable LSRs be configured to advertise Bandwidth 1354 Constraints (using the Max Reservable Bandwidth sub-TLV as 1355 well as the Bandwidth Constraints sub-TLV, as specified in 1356 section 5.1 above). 1357 This allows DS-TE capable LSRs to unambiguously identify non DS-TE 1358 capable LSRs. 1360 Finally hybrid operations require that non DS-TE capable LSRs be able 1361 to accept Unreserved Bw sub-TLVs containing non decreasing bandwidth 1362 values (ie with Unreserved [p] < Unreserved [q] with p CT preemption 1392 ==================================== 1393 0 CT1 0 1394 1 CT1 1 1395 2 CT0 2 1396 3 CT0 3 1397 rest unused 1399 LSR0 is configured with a Max Reservable bandwidth=m01 for Link01. 1400 LSR1 is configured with a BC0=x0 a BC1=x1(possibly=0), and a Max 1401 Reservable Bandwidth=m10(possibly=m01) for Link01. 1403 LSR0 will advertise in IGP for Link01: 1404 - Max Reservable Bw sub-TLV = 1405 - Unreserved Bw sub-TLV = 1406 1408 On receipt of such advertisement, LSR1 will: 1409 - understand that LSR0 is not DS-TE capable because it 1410 advertised a Max Reservable Bw sub-TLV and no Bandwidth 1411 Constraint sub-TLV 1412 - conclude that only CT0 LSPs can transit via LSR0 and that 1413 only the values CT0/2 and CT0/3 are meaningful in the 1414 Unreserved Bw sub-TLV. LSR1 may effectively behave as if the 1415 six other values contained in the Unreserved Bw sub-TLV were 1416 set to zero. 1418 LSR1 will advertise in IGP for Link01: 1419 - Max Reservable Bw sub-TLV = 1420 - Bandwidth Constraint sub-TLV = 1421 - Unreserved Bw sub-TLV = 1423 Le Faucheur et. al 26 1425 Protocols for Diff-Serv-aware TE September 2003 1427 On receipt of such advertisement, LSR0 will: 1428 - Ignore the Bandwidth Constraint sub-TLV (unrecognized) 1429 - Correctly process CT0/2 and CT0/3 in the Unreserved Bw sub- 1430 TLV and use these values for CTO LSP establishment 1431 - Incorrectly believe that the other values contained in the 1432 Unreserved Bw sub-TLV relates to other preemption priorities 1433 for CT0, but will actually never use those since we assume 1434 that only preemption 2 and 3 are used in the TE domain. 1436 Le Faucheur et. al 27