idnits 2.17.1 draft-ietf-tewg-diff-te-proto-04.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 1651 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: 'IANA' is mentioned on line 1055, but not defined == Unused Reference: 'DSTE-MAR' is defined on line 1103, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-tewg-diff-te-reqts (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') == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-09 == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-04 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'ISIS-TE') == Outdated reference: A later version (-07) exists of draft-ietf-tewg-diff-te-russian-03 -- Unexpected draft version: The latest known version of draft-lefaucheur-diff-te-mam is -00, but you're referring to -01. Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 8 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: December, 2003 7 Document: draft-ietf-tewg-diff-te-proto-04.txt June, 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 June 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 16, and is not repeated below.) 100 Le Faucheur et. al 2 102 Protocols for Diff-Serv-aware TE June 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 June 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 June 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 June 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 June 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 June 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 June 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 June 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 June 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 June 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 10. 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 June 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 June 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 June 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 June 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. Constraint Based Routing 869 Let us consider the case where a path needs to be computed for an LSP 870 whose Class-Type is configured to CTc and whose set-up preemption 871 priority is configured to p. 873 Then the pair of CTc and p will map to one of the TE-Classes defined 874 in the TE-Class mapping. Let us refer to this TE-Class as TE- 875 Class[i]. 877 Le Faucheur et. al 16 879 Protocols for Diff-Serv-aware TE June 2003 881 The Constraint Based Routing algorithm of a DS-TE LSR is still only 882 required to perform path computation satisfying a single bandwidth 883 constraint which is to fit in "Unreserved TE-Class [i]" as advertised 884 by the IGP for every link. Thus, no changes are required to the 885 existing TE Constraint Based Routing algorithm itself. 887 The Constraint Based Routing algorithm MAY also optionally take into 888 account, when used, the optional additional information advertised in 889 IGP such as the Bandwidth Constraints and the Maximum Reservable 890 Bandwidth. As an example, the Bandwidth Constraints MIGHT be used as 891 a tie-breaker criteria in situations where multiple paths, otherwise 892 equally attractive, are possible. 894 8. Diff-Serv scheduling 896 The Class-Type signaled at LSP establishment MAY optionally be used 897 by DS-TE LSRs to dynamically adjust the resources allocated to the 898 Class-Type by the Diff-Serv scheduler. In addition, the Diff-Serv 899 information (i.e. the PSC) signaled by the TE-LSP signaling protocols 900 as specified in [DIFF-MPLS], if used, MAY optionally be used by DS-TE 901 LSRs to dynamically adjust the resources allocated to a PSC/OA within 902 a Class Type by the Diff-Serv scheduler. 904 9. Existing TE as a Particular Case of DS-TE 906 We observe that existing TE can be viewed as a particular case of 907 DS-TE where: 909 (i) a single Class-Type is used, 910 (ii) all 8 preemption priorities are allowed for that Class- 911 Type, and 912 (iii) the following TE-Class Mapping is used: 913 TE-Class[i] <--> < CT0 , preemption i > 914 Where 0 <= i <= 7. 916 In that case, DS-TE behaves as existing TE. 918 As with existing TE, the IGP advertises: 919 - Unreserved Bandwidth for each of the 8 preemption priorities 921 As with existing TE, the IGP may advertise: 922 - Maximum Reservable Bandwidth containing an a bandwidth 923 constraint applying across all LSPs 925 Since all LSPs transport traffic from CT0, RSVP-TE signaling is done 926 without explicit signaling of the Class-Type (which is only used for 927 other Class-Types than CT0 as explained in section 6) as with 928 existing TE. 930 Le Faucheur et. al 17 932 Protocols for Diff-Serv-aware TE June 2003 934 10. Computing "Unreserved TE-Class [i]" and Admission Control Rules 936 10.1. Computing "Unreserved TE-Class [i]" 938 We first observe that, for existing TE, details on admission control 939 algorithms for TE LSPs, and consequently details on formulas for 940 computing the unreserved bandwidth, are outside the scope of the 941 current IETF work. This is left for vendor differentiation. Note that 942 this does not compromise interoperability across various 943 implementations since the TE schemes rely on LSRs to advertise their 944 local view of the world in terms of Unreserved Bw to other LSRs. This 945 way, regardless of the actual local admission control algorithm used 946 on one given LSR, Constraint Based Routing on other LSRs can rely on 947 advertised information to determine whether an additional LSP will be 948 accepted or rejected by the given LSR. The only requirement is that 949 an LSR advertises unreserved bandwidth values which are consistent 950 with its specific local admission control algorithm and take into 951 account the holding preemption priority of established LSPs. 953 In the context of DS-TE, again, details on admission control 954 algorithms are left for vendor differentiation and formulas for 955 computing the unreserved bandwidth for TE-Class[i] are outside the 956 scope of this specification. However, DS-TE places the additional 957 requirement on the LSR that the unreserved bandwidth values 958 advertised MUST reflect all of the Bandwidth Constraints relevant to 959 the CT associated with TE-Class[i] in accordance with the Bandwidth 960 Constraints Model. Thus, formulas for computing "Unreserved TE-Class 961 [i]" depend on the Bandwidth Constraints model in use and MUST 962 reflect how bandwidth constraints apply to CTs. Example formulas for 963 computing "Unreserved TE-Class [i]" Model are provided for the 964 Russian Dolls Model and Maximum Allocation Model respectively in 965 [DSTE-RDM] and [DSTE-MAM]. 967 As with existing TE, DS-TE LSRs MUST consider the holding preemption 968 priority of established LSPs (as opposed to their set-up preemption 969 priority) for the purpose of computing the unreserved bandwidth for 970 TE-Class [i]. 972 10.2. Admission Control Rules 974 A DS-TE LSR MUST support the following admission control rule: 976 Regardless of how the admission control algorithm actually computes 977 the unreserved bandwidth for TE-Class[i] for one of its local link, 978 an LSP of bandwidth B, of set-up preemption priority p and of Class- 979 Type CTc is admissible on that link iff: 981 B <= Unreserved Bandwidth for TE-Class[i] 983 Where 985 Le Faucheur et. al 18 987 Protocols for Diff-Serv-aware TE June 2003 989 - TE-Class [i] maps to < CTc , p > in the LSR's configured TE- 990 Class mapping 992 11. Security Considerations 994 This document does not introduce additional security threats beyond 995 those inherent to Diff-Serv and MPLS Traffic Engineering and the same 996 security mechanisms proposed for these technologies are applicable 997 and may be used. For example, the approach for defense against theft- 998 and denial-of-service attacks discussed in [DIFF-ARCH], which 999 consists of the combination of traffic conditioning at DS boundary 1000 nodes along with security and integrity of the network infrastructure 1001 within a Diff-Serv domain, may be followed when DS-TE is in use. 1002 Also, as stated in [TE-REQ], it is specifically important that 1003 manipulation of administratively configurable parameters (such as 1004 those related to DS-TE LSPs) be executed in a secure manner by 1005 authorized entities. 1007 12. Acknowledgments 1009 We thank Martin Tatham, Angela Chiu and Pete Hicks for their earlier 1010 contribution in this work. We also thank Sanjaya Choudhury for his 1011 thorough review and suggestions. 1013 13. IANA Considerations 1015 This document defines a number of objects with implications for IANA. 1017 This document defines in section 5.1 a new sub-TLV, the "Bandwidth 1018 Constraints" sub-TLV, for the OSPF "Link" TLV [OSPF-TE]. A sub-TLV 1019 Type in the range 10 to 32767 needs to be assigned by Expert Review. 1020 This sub-TLV Type also needs to be registered by IANA. 1022 This document defines in section 5.1 a new sub-TLV, the "Bandwidth 1023 Constraints" sub-TLV, for the ISIS "Extended IS Reachability" TLV 1024 [ISIS-TE]. A sub-TLV Type needs to be assigned by Expert Review. This 1025 sub-TLV Type also needs to be registered by IANA. 1027 This document defines in section 5.3 a "Bandwidth Constraint Model 1028 Id" field within the "Bandwidth Constraints" sub-TLV. This document 1029 also defines in section 5.3 two values for this field (0 and 1). 1030 Future allocations of values in this space and in the range 2 to 127 1031 should be handled by IANA using the First Come First Served policy 1032 defined in [IANA]. Values in the range 128 to 255 are reserved for 1033 experimental use. 1035 This document defines in section 6.2.1 a new RSVP object, the 1036 CLASSTYPE object. This object requires a number from the space 1037 defined in [RSVP] for those objects which, if not understood, cause 1039 Le Faucheur et. al 19 1041 Protocols for Diff-Serv-aware TE June 2003 1043 the entire RSVP message to be rejected with an error code of "Unknown 1044 Object Class". Such objects are identified by a zero in the most 1045 significant bit of the class number. Within that space, this object 1046 requires a number to be allocated by IANA from the "IETF Consensus" 1047 space. 1049 This document defines in section 6.5 a new RSVP error code, the 1050 "Diff-Serv-aware TE Error". This new Error code needs to be allocated 1051 by IANA. This document defines values 1 through 7 of the value field 1052 to be used within the ERROR_SPEC object for the "Diff-Serv-aware TE 1053 error" code. Future allocations of values in this space should be 1054 handled by IANA using the First Come First Served policy defined in 1055 [IANA]. 1057 14. Normative References 1059 [DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv- 1060 aware MPLS Traffic Engineering, work-in-progress, draft-ietf-tewg- 1061 diff-te-reqts-07.txt, February 2003. 1063 [MPLS-ARCH] Rosen et al., "Multiprotocol Label Switching 1064 Architecture", RFC3031. 1066 [DIFF-ARCH] Blake et al., "An Architecture for Differentiated 1067 Services", RFC2475. 1069 [TE-REQ] Awduche et al., "Requirements for Traffic Engineering Over 1070 MPLS", RFC2702. 1072 [OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF, draft- 1073 katz-yeung-ospf-traffic-09.txt, October 2002. 1075 [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft- 1076 ietf-isis-traffic-04.txt, December 2002. 1078 [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 1079 Tunnels", RFC 3209, December 2001. 1081 [RSVP] Braden et al, "Resource ReSerVation Protocol (RSVP) - Version 1082 1 Functional Specification", RFC 2205, September 1997. 1084 [DIFF-MPLS] Le Faucheur et al, "MPLS Support of Diff-Serv", RFC3270, 1085 May 2002. 1087 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 1088 Requirement Levels, RFC2119, March 1997. 1090 15. Informative References 1092 Le Faucheur et. al 20 1094 Protocols for Diff-Serv-aware TE June 2003 1096 [DSTE-RDM] Le Faucheur et al., "Russian Dolls Bandwidth Constraints 1097 Model for DS-TE", draft-ietf-tewg-diff-te-russian-03.txt, June 2003 1099 [DSTE-MAM] Le Faucheur et al., "Maximum Allocation Bandwidth 1100 Constraints Model for DS-TE", draft-lefaucheur-diff-te-mam-01.txt, 1101 June 2003. 1103 [DSTE-MAR] Ash, "Max Allocation with Reservation Bandwidth Constraint 1104 Model for MPLS/DiffServ TE & Performance Comparisons", March 2003. 1106 16. Editor's Address: 1108 Francois Le Faucheur 1109 Cisco Systems, Inc. 1110 Village d'Entreprise Green Side - Batiment T3 1111 400, Avenue de Roumanille 1112 06410 Biot-Sophia Antipolis 1113 France 1114 Phone: +33 4 97 23 26 19 1115 Email: flefauch@cisco.com 1117 Appendix A - Prediction for Multiple Path Computation 1119 There are situations where a Head-End needs to compute paths for 1120 multiple LSPs over a short period of time. There are potential 1121 advantages for the Head-end in trying to predict the impact of the n- 1122 th LSP on the unreserved bandwidth when computing the path for the 1123 (n+1)-th LSP, before receiving updated IGP information. One example 1124 would be to perform better load-distribution of the multiple LSPs 1125 across multiple paths. Another example would be to avoid CAC 1126 rejection when the (n+1)-th LSP would no longer fit on a link after 1127 establishment of the n-th LSP. While there are also a number of 1128 conceivable scenarios where doing such predictions might result in a 1129 worse situation, it is more likely to improve the situation. As a 1130 matter of fact, a number of network administrators have elected to 1131 use such predictions when deploying existing TE. 1133 Such predictions are local matters, are optional and are outside the 1134 scope of this specification. 1136 Where such predictions are not used, the optional Bandwidth 1137 Constraint sub-TLV and the optional Maximum Reservable Bandwidth sub- 1138 TLV need not be advertised in IGP for the purpose of path computation 1139 since the information contained in the Unreserved Bw sub-TLV is all 1140 that is required by Head-Ends to perform Constraint Based Routing. 1142 Where such predictions are used on Head-Ends, the optional Bandwidth 1143 Constraint sub-TLV and the optional Maximum Reservable Bandwidth sub- 1144 TLV MAY be advertised in IGP. This is in order for the Head-ends to 1146 Le Faucheur et. al 21 1148 Protocols for Diff-Serv-aware TE June 2003 1150 predict as accurately as possible how an LSP affects unreserved 1151 bandwidth values for subsequent LSPs. 1153 Remembering that actual admission control algorithms are left for 1154 vendor differentiation, we observe that predictions can only be 1155 performed effectively when the Head-end LSR predictions are based on 1156 the same (or a very close) admission control algorithm as used by 1157 other LSRs. 1159 Appendix B - Solution Evaluation 1161 1. Satisfying Detailed Requirements 1163 This DS-TE Solution addresses all the scenarios presented in [DSTE- 1164 REQ]. 1166 It also satisfies all the detailed requirements presented in [DSTE- 1167 REQ]. 1169 The objective set out in the last paragraph of section "4.7 1170 overbooking" of [DSTE-REQ] is only partially addressed by this DS-TE 1171 solution. Through support of the "LSP Size Overbooking" and "Link 1172 Size Overbooking" methods, this DS-TE solution effectively allows CTs 1173 to have different overbooking ratios and simultaneously allows 1174 overbooking to be tweaked differently (collectively across all CTs) 1175 on different links. But, in a general sense, it does not allow the 1176 effective overbooking ratio of every CT to be tweaked differently in 1177 different parts of the network independently of other CTs, while 1178 maintaining accurate bandwidth accounting of how different CTs 1179 mutually affect each other through shared Bandwidth Constraints (such 1180 as the Maximum Reservable Bandwidth). 1182 2. Flexibility 1184 This DS-TE solution supports 8 CTs. It is entirely flexible as to how 1185 Traffic Trunks are grouped together into a CT. 1187 3. Extendibility 1189 A maximum of 8 CTs is considered by the authors of this document as 1190 more than comfortable. However, this solution could be extended to 1191 support more CTs if deemed necessary in the future. However, this 1192 would necessitate additional IGP extensions beyond those specified in 1193 this document. 1195 Although the prime objective of this solution is support of Diff- 1196 Serv-aware Traffic Engineering, its mechanisms are not tightly 1197 coupled with Diff-Serv. This makes the solution amenable, or more 1198 easily extendable, for support of potential other future Traffic 1199 Engineering applications. 1201 Le Faucheur et. al 22 1203 Protocols for Diff-Serv-aware TE June 2003 1205 4. Scalability 1207 This DS-TE solution is expected to have a very small scalability 1208 impact compared to existing TE. 1210 From an IGP viewpoint, the amount of mandatory information to be 1211 advertised is identical to existing TE. One additional sub-TLV has 1212 been specified, but its use is optional and it only contains a 1213 limited amount of static information (at most 8 Bandwidth 1214 Constraints). 1216 We expect no noticeable impact on LSP Path computation since, as with 1217 existing TE, this solution only requires CSPF to consider a single 1218 unreserved bandwidth value for any given LSP. 1220 From a signaling viewpoint we expect no significant impact due to 1221 this solution since it only requires processing of one additional 1222 information (the Class-Type) and does not significantly increase the 1223 likelihood of CAC rejection. Note that DS-TE has some inherent impact 1224 on LSP signaling in the sense that it assumes that different classes 1225 of traffic are split over different LSPs so that more LSPs need to be 1226 signaled; but this is due to the DS-TE concept itself and not to the 1227 actual DS-TE solution discussed here. 1229 5. Backward Compatibility/Migration 1231 This solution is expected to allow smooth migration from existing TE 1232 to DS-TE. This is because existing TE can be supported as a 1233 particular configuration of DS-TE. This means that an "upgraded" LSR 1234 with a DS-TE implementation can directly interwork with an "old" LSR 1235 supporting existing TE only. 1237 This solution is expected to allow smooth migration when increasing 1238 the number of CTs actually deployed since it only requires 1239 configuration changes. however, these changes must be performed in a 1240 coordinated manner across the DS-TE domain. 1242 Appendix C - Interoperability with non DS-TE capable LSRs 1244 This DSTE solution allows operations in a hybrid network where some 1245 LSRs are DS-TE capable while some LSRs and not DS-TE capable, which 1246 may occur during migration phases. This Appendix discusses the 1247 constraints and operations in such hybrid networks. 1249 We refer to the set of DS-TE capable LSRs as the DS-TE domain. We 1250 refer to the set of non DS-TE capable (but TE capable) LSRs as the 1251 TE-domain. 1253 Hybrid operations requires that the TE-class mapping in the DS-TE 1254 domain is configured so that: 1256 Le Faucheur et. al 23 1258 Protocols for Diff-Serv-aware TE June 2003 1260 - a TE-class exist for CT0 for every preemption priority 1261 actually used in the TE domain 1262 - the index in the TE-class mapping for each of these TE- 1263 classes is equal to the preemption priority. 1265 For example, imagine the TE domain uses preemption 2 and 3. Then, DS- 1266 TE can be deployed in the same network by including the following TE- 1267 classes in the TE-class mapping: 1268 i <---> CT preemption 1269 ==================================== 1270 2 CT0 2 1271 3 CT0 3 1273 Another way to look at this is to say that, the whole TE-class 1274 mapping does not have to be consistent with the TE domain, but the 1275 subset of this TE-Class mapping applicable to CT0 must effectively be 1276 consistent with the TE domain. 1278 Hybrid operations also requires that: 1279 - non DS-TE capable LSRs be configured to advertise the Maximum 1280 Reservable Bandwidth 1281 - DS-TE capable LSRs be configured to advertise Bandwidth 1282 Constraints (using the Max Reservable Bandwidth sub-TLV as 1283 well as the Bandwidth Constraints sub-TLV, as specified in 1284 section 5.1 above). 1285 This allows DS-TE capable LSRs to unambiguously identify non DS-TE 1286 capable LSRs. 1288 Finally hybrid operations require that non DS-TE capable LSRs be able 1289 to accept Unreserved Bw sub-TLVs containing non decreasing bandwidth 1290 values (ie with Unreserved [p] < Unreserved [q] with p CT preemption 1319 ==================================== 1320 0 CT1 0 1321 1 CT1 1 1322 2 CT0 2 1323 3 CT0 3 1324 rest unused 1326 LSR0 is configured with a Max Reservable bandwidth=m01 for Link01. 1327 LSR1 is configured with a BC0=x0 a BC1=x1(possibly=0), and a Max 1328 Reservable Bandwidth=m10(possibly=m01) for Link01. 1330 LSR0 will advertise in IGP for Link01: 1331 - Max Reservable Bw sub-TLV = 1332 - Unreserved Bw sub-TLV = 1333 1335 On receipt of such advertisement, LSR1 will: 1336 - understand that LSR0 is not DS-TE capable because it 1337 advertised a Max Reservable Bw sub-TLV and no Bandwidth 1338 Constraint sub-TLV 1339 - conclude that only CT0 LSPs can transit via LSR0 and that 1340 only the values CT0/2 and CT0/3 are meaningful in the 1341 Unreserved Bw sub-TLV. LSR1 may effectively behave as if the 1342 six other values contained in the Unreserved Bw sub-TLV were 1343 set to zero. 1345 LSR1 will advertise in IGP for Link01: 1346 - Max Reservable Bw sub-TLV = 1347 - Bandwidth Constraint sub-TLV = 1348 - Unreserved Bw sub-TLV = 1350 On receipt of such advertisement, LSR0 will: 1351 - Ignore the Bandwidth Constraint sub-TLV (unrecognized) 1352 - Correctly process CT0/2 and CT0/3 in the Unreserved Bw sub- 1353 TLV and use these values for CTO LSP establishment 1354 - Incorrectly believe that the other values contained in the 1355 Unreserved Bw sub-TLV relates to other preemption priorities 1356 for CT0, but will actually never use those since we assume 1357 that only preemption 2 and 3 are used in the TE domain. 1359 Le Faucheur et. al 25