idnits 2.17.1 draft-ietf-tewg-diff-te-proto-01.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 2443 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 125: '... DS-TE implementation MUST provide for...' RFC 2119 keyword, line 129: '... The LSR MUST interpret these Bandwid...' RFC 2119 keyword, line 135: '... MUST enforce those at configuration ...' RFC 2119 keyword, line 170: '... a DS-TE implementation MAY optionally...' RFC 2119 keyword, line 209: '... For DS-TE, LSRs MUST allow configurat...' (67 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 91 has weird spacing: '...rned by a spe...' == 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) == Missing Reference: 'TE-REQ' is mentioned on line 198, but not defined == Missing Reference: 'DSTE-REQTS' is mentioned on line 810, but not defined -- Looks like a reference, but probably isn't: '0' on line 1075 -- Looks like a reference, but probably isn't: '1' on line 1076 -- Looks like a reference, but probably isn't: '2' on line 420 -- Looks like a reference, but probably isn't: '3' on line 421 -- Looks like a reference, but probably isn't: '7' on line 544 == Missing Reference: 'RSVP' is mentioned on line 1381, but not defined == Missing Reference: 'LDP' is mentioned on line 1613, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-tewg-diff-te-reqts-05 ** Downref: Normative reference to an Informational draft: draft-ietf-tewg-diff-te-reqts (ref. 'DSTE-REQ') == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-06 == 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') -- Possible downref: Normative reference to a draft: ref. 'RUSSIAN' == Outdated reference: A later version (-06) exists of draft-wlai-tewg-bcmodel-00 ** Downref: Normative reference to an Informational draft: draft-wlai-tewg-bcmodel (ref. 'BCMODEL') Summary: 10 errors (**), 0 flaws (~~), 12 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Francois Le Faucheur, Editor 3 Thomas Nadeau 4 Cisco Systems, Inc. 6 Jim Boyle 7 PDNets 9 Kireeti Kompella 10 Juniper Networks 12 William Townsend 13 Tenor Networks 15 Darek Skalecki 16 Nortel Networks 18 IETF Internet Draft 19 Expires: December, 2002 20 Document: draft-ietf-tewg-diff-te-proto-01.txt June, 2002 22 Protocol extensions for support of 23 Diff-Serv-aware MPLS Traffic Engineering 25 Status of this Memo 27 This document is an Internet-Draft and is in full conformance with 28 all provisions of Section 10 of RFC2026. Internet-Drafts are 29 Working documents of the Internet Engineering Task Force (IETF), its 30 areas, and its working groups. Note that other groups may also 31 distribute working documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 Abstract 45 This document specifies the IGP and signaling extensions and 46 procedures (beyond those already specified for existing MPLS Traffic 47 Engineering) for support of Diff-Serv-aware MPLS Traffic Engineering. 49 Le Faucheur, et. al 1 51 Protocols for Diff-Serv-aware TE June 2002 53 A default Bandwidth Constraints model for Diff-Serv-aware Traffic 54 Engineering (the Russian Dolls model) is also specified. 56 1. Introduction 58 [DSTE-REQ] presents the Service Providers requirements for support of 59 Diff-Serv-aware MPLS Traffic Engineering (DS-TE). This includes the 60 fundamental requirement to be able to enforce different bandwidth 61 constraints for different classes of traffic. 63 This document specifies: 64 - the IGP and signaling extensions and procedures (beyond those 65 already specified for existing MPLS Traffic Engineering 66 [OSPF-TE][ISIS-TE][RSVP-TE][CR-LDP]) for support of the DS-TE 67 requirements [DSTE-REQ] in environments relying on 68 distributed Constraint Based Routing (i.e. path computation 69 involving Head-end LSRs). 70 - A default Bandwidth Constraint Model for DS-TE called the 71 Russian Dolls model. While DS-TE implementations may support 72 other Bandwidth Constraints model, they must all support the 73 Russian Dolls model to ensure interoperability across all 74 implementations. 76 2. Definitions 78 [DSTE-REQ] discusses how a Head-end LSR may split the set of Ordered 79 Aggregates from the traffic to a given Tail-end into multiple Traffic 80 Trunks. Each Traffic Trunk is transported over a separate LSP which 81 is Constraint Based Routed individually. 83 For readability a number of definitions from [DSTE-REQ] are repeated 84 here: 86 Traffic Trunk: an aggregation of traffic flows of the same class 87 [i.e. which are to be treated equivalently from the DS-TE 88 perspective] which are placed inside a Label Switched Path. 90 Class-Type (CT): the set of Traffic Trunks crossing a link that is 91 governed by a specific set of Bandwidth constraints. CT is used for 92 the purposes of link bandwidth allocation, constraint based routing 93 and admission control. A given Traffic Trunk belongs to the same CT 94 on all links. A given Traffic Trunk belongs to the same CT on all 95 links. 97 TE-Class: A pair of: 98 i. a Class-Type 99 ii. a preemption priority allowed for that Class-Type. This 100 means that an LSP transporting a Traffic Trunk from 101 that Class-Type can use that preemption priority as the 102 set-up priority, as the holding priority or both. 104 Le Faucheur et. al 2 106 Protocols for Diff-Serv-aware TE June 2002 108 3. Configurable Parameters 110 This section only discusses the differences with the configurable 111 parameters supported for MPLS Traffic Engineering as per [TE-REQ], 112 [ISIS-TE], [OSPF-TE], [RSVP-TE] and [CR-LDP]. All other parameters 113 are unchanged. 115 3.1. Link Parameters 117 3.1.1. Bandwidth Constraints (BCs) 119 [DSTE-REQTS] states that "Regardless of the Bandwidth Constraint 120 Model, the DS-TE solution must allow support for up to 8 BCs." 122 For DS-TE, the existing "Maximum Reservable link bandwidth" parameter 123 is retained but its semantic is generalized and interpreted as BC0. 125 Additionally, on every link, a DS-TE implementation MUST provide for 126 configuration of up to 7 additional link parameters which are the 127 seven other potential Bandwidth Constraints i.e. BC1, BC2 , ... BC7. 129 The LSR MUST interpret these Bandwidth Constraints in accordance with 130 the supported Bandwidth Constraint Model (i.e. what bandwidth 131 constraint applies to what Class-Type and how). 133 Where the Bandwidth Constraint Model imposes some relationship among 134 the values to be configured for these Bandwidth Constraints, the LSR 135 MUST enforce those at configuration time. For example, with the 136 "Russian Doll" Bandwidth Constraints Model defined below in section 137 9, the LSR must ensure that BCi is configured smaller or equal to 138 BCj, where i is greater than j. 140 3.1.2. per-CT Local Overbooking Multipliers (LOMs) 142 DS-TE enables a network administrator to apply different overbooking 143 (or underbooking) ratios for different CTs. 145 The principal method to achieve this is the same as historically used 146 in existing TE deployment, which is : 147 (i) to take into account the over-booking/underbooking ratio 148 appropriate for the OA/CT associated with the considered LSP 149 at the time of establishing the bandwidth size of a given 150 LSP, AND/OR 151 (ii) to take into account the overbooking/underbooking ratio at 152 the time of configuring the Maximum Reservable 153 Bandwidth/Bandwidth Constraints and/or the Maximum Link 154 Bandwidth (which effectively controls the maximum size of an 155 individual LSP) and use values which are larger(overbooking) 156 or smaller(underbooking) than the actual link. 157 We refer to this method as the "LSP/link size overbooking" method. 159 Le Faucheur et. al 3 161 Protocols for Diff-Serv-aware TE June 2002 163 The "LSP/link size overbooking" method is expected to be often 164 sufficient in many DS-TE environments and requires no additional 165 configurable parameters. 167 However, in the particular DS-TE environments where, for a given CT, 168 the overbooking ratio needs to be tweaked differently on different 169 links and where a very fine accounting of overbooking cross-effect 170 across Class-Types is required, a DS-TE implementation MAY optionally 171 support the "local overbooking" method as a complement to the 172 "LSP/link size overbooking" method. The "local overbooking" method 173 relies on optional "per-CT Local Overbooking Multipliers" (LOMs) 174 which are configurable, on every link, for every CT. The per-CT Local 175 Overbooking Multiplier effectively allows the network operator to 176 increase/decrease", on some links, the overbooking ratio already 177 enforced by the "LSP/link size overbooking" method. This is achieved 178 by factoring the per-CT LOM in all local bandwidth accounting for the 179 purposes of admission control and IGP advertisement of unreserved 180 bandwidths. Exact details on how the LOMs need to be factored in 181 depend on the Bandwidth Constraints model. This is discussed for the 182 Russian Dolls model in section 9. 184 Since the per-CT Local Overbooking Multipliers are factored in the 185 IGP advertisement of unreserved bandwidth by the local LSR, a remote 186 LSR computing a path for a DS-TE tunnel need not be aware that local 187 overbooking is used on the considered link. In fact, the remote LSR 188 does not even need to support the optional local overbooking method. 189 In any case, the remote LSR will compute a path that effectively 190 takes into account the LOMs on the considered link because it bases 191 its computation on advertised unreserved bandwidth which do factor in 192 the LOMs for that link. 194 3.2. LSR Parameters 196 3.2.1. TE-Class Mapping 198 In line with [DSTE-REQ], the preemption attributes defined in [TE- 199 REQ] are retained with DS-TE and applicable across all Class Types. 200 The preemption attributes of setup priority and holding priority 201 retain existing semantics, and in particular these semantics are not 202 affected by the Ordered Aggregate transported by the LSP or by the 203 LSP's Class Type. This means that if LSP1 contends with LSP2 for 204 resources, LSP1 may preempt LSP2 if LSP1 has a higher set-up 205 preemption priority (i.e. lower numerical priority value) than LSP2's 206 holding preemption priority regardless of LSP1's OA/CT and LSP2's 207 OA/CT. 209 For DS-TE, LSRs MUST allow configuration of a TE-Class mapping 210 whereby the Class-Type and preemption level are configured for each 211 of (up to) 8 TE-Classes. 213 This mapping is referred to as : 215 Le Faucheur et. al 4 217 Protocols for Diff-Serv-aware TE June 2002 219 TE-Class[i] <--> < CTc , preemption p > 221 Where 0 <= i <= 7, 0 <= c <= 7, 0 <= p <= 7 223 Two TE-Classes must not be identical (i.e. have both the same Class- 224 Type and the same preemption priority). 226 Where the network administrator uses less than 8 TE-Classes, the DS- 227 TE LSR MUST allow remaining ones to be configured as "Unused". 229 There are no other restrictions on how any of the 8 Class-Types can 230 be paired up with any of the 8 preemption priorities to form a TE- 231 class. In particular, one given preemption priority can be paired up 232 with two (or more) different Class-Types to form two (or more) TE- 233 classes. Similarly, one Class-Type can be paired up with two (or 234 more) different preemption priorities to form two (or more) TE- 235 Classes. Also, there is no mandatory ordering relationship between 236 the TE-Class index (i.e. "i" above) and the Class-Type (i.e. "c" 237 above) or the preemption priority (i.e. "p" above) of the TE-Class. 239 To ensure coherent DS-TE operation, the network administrator MUST 240 configure exactly the same TE-Class Mapping on all LSRs of the DS-TE 241 domain. 243 When the TE-class mapping needs to be modified in the DS-TE domain, 244 care must be exercised during the transient period of reconfiguration 245 during which some DS-TE LSRs may be configured with the new TE-class 246 mapping while others are still configured with the old TE-class 247 mapping. It is recommended that active tunnels do not use any of the 248 TE-classes which are being modified during such a transient 249 reconfiguration period. 251 3.3. LSP Parameters 253 3.3.1. Class-Type 255 With DS-TE, LSRs MUST support, for every LSP, an additional 256 configurable parameter which indicates the Class-Type of the Traffic 257 Trunk transported by the LSP. 259 There is one and only one Class-Type configured per LSP. 261 The configured Class-Type indicates, in accordance with the supported 262 Bandwidth Constraint Model, what are the Bandwidth Constraints 263 applicable to that LSP. 265 3.3.2. Setup and Holding Preemption Priorities 267 As per existing TE, DS-TE assumes that every DS-TE LSP is configured 268 with a setup and holding priority, each with a value between 0 and 7. 270 Le Faucheur et. al 5 272 Protocols for Diff-Serv-aware TE June 2002 274 3.3.3. Class-Type/Preemption Relationship 276 With DS-TE, the preemption priority configured for the setup priority 277 of a given LSP and the Class-Type configured for that LSP must be 278 such that, together, they form one of the (up to) 8 TE-Classes 279 configured in the TE-Class Mapping specified is section 3.2.1 above. 281 The LSR MUST enforce this rule at configuration time. 283 The preemption priority configured for the holding priority of a 284 given LSP and the Class-Type configured for that LSP must also be 285 such that, together, they form one of the (up to) 8 TE-Classes 286 configured in the TE-Class Mapping specified is section 3.2.1 above. 288 The LSR MUST enforce this rule at configuration time. 290 3.4. Examples of Parameters Configuration 292 For illustrative purposes, we now present a few examples of how these 293 configurable parameters may be used. All these examples assume that 294 different bandwidth constraints need to be enforced for different 295 sets of Traffic Trunks (e.g. for Voice and for Data) so that two, or 296 more, Class-Types must be used. 298 3.4.1. Example 1 300 The Network Administrator of a first network using two Class Types 301 (CT1 for Voice and CT0 for Data), may elect to configure the 302 following TE-Class Mapping to ensure that Voice LSPs are never driven 303 away from their shortest path because of Data LSPs: 305 TE-Class[0] <--> < CT1 , preemption 0 > 306 TE-Class[1] <--> < CT0 , preemption 1 > 307 TE-Class[i] <--> unused, for 2 <= i <= 7 309 Voice LSPs would then be configured with: 310 - CT=CT1, set-up priority =0, holding priority=0 312 Data LSPs would then be configured with: 313 - CT=CT0, set-up priority =1, holding priority=1 315 A new Voice LSP would then be able to preempt an existing Data LSP in 316 case they contend for resources. A Data LSP would never preempt a 317 Voice LSP. A Voice LSP would never preempt another Voice LSP. A Data 318 LSP would never preempt another Data LSP. 320 3.4.2. Example 2 322 The Network Administrator of another network may elect to configure 323 the following TE-Class Mapping in order to optimize global network 325 Le Faucheur et. al 6 327 Protocols for Diff-Serv-aware TE June 2002 329 resource utilization by favoring placement of large LSPs closer to 330 their shortest path: 332 TE-Class[0] <--> < CT1 , preemption 0 > 333 TE-Class[1] <--> < CT0 , preemption 1 > 334 TE-Class[2] <--> < CT1 , preemption 2 > 335 TE-Class[3] <--> < CT0 , preemption 3 > 336 TE-Class[i] <--> unused, for 4 <= i <= 7 338 Large size Voice LSPs could be configured with: 339 - CT=CT1, set-up priority =0, holding priority=0 341 Large size Data LSPs could be configured with: 342 - CT=CT0, set-up priority = 1, holding priority=1 344 Small size Voice LSPs could be configured with: 345 - CT=CT1, set-up priority = 2, holding priority=2 347 Small size Data LSPs could be configured with: 348 - CT=CT0, set-up priority = 3, holding priority=3. 350 A new large size Voice LSP would then be able to preempt a small size 351 Voice LSP or any Data LSP in case they contend for resources. 352 A new large size Data LSP would then be able to preempt a small size 353 Data LSP or a small size Voice LSP in case they contend for 354 resources, but it would not be able to preempt a large size Voice 355 LSP. 357 3.4.3. Example 3 359 The Network Administrator of another network may elect to configure 360 the following TE-Class Mapping in order to ensure that Voice LSPs are 361 never driven away from their shortest path because of Data LSPs while 362 also achieving some optimization of global network resource 363 utilization by favoring placement of large LSPs closer to their 364 shortest path: 366 TE-Class[0] <--> < CT1 , preemption 0 > 367 TE-Class[1] <--> < CT1 , preemption 1 > 368 TE-Class[2] <--> < CT0 , preemption 2 > 369 TE-Class[3] <--> < CT0 , preemption 3 > 370 TE-Class[i] <--> unused, for 4 <= i <= 7 372 Large size Voice LSPs could be configured with: 373 - CT=CT1, set-up priority = 0, holding priority=0. 375 Small size Voice LSPs could be configured with: 376 - CT=CT1, set-up priority = 1, holding priority=1. 378 Large size Data LSPs could be configured with: 379 - CT=CT0, set-up priority = 2, holding priority=2. 381 Le Faucheur et. al 7 383 Protocols for Diff-Serv-aware TE June 2002 385 Small size Data LSPs could be configured with: 386 - CT=CT0, set-up priority = 3, holding priority=3. 388 A Voice LSP could preempt a Data LSP if they contend for resources. A 389 Data LSP would never preempt a Voice LSP. A Large size Voice LSP 390 could preempt a small size Voice LSP if they contend for resources. A 391 Large size Data LSP could preempt a small size Data LSP if they 392 contend for resources. 394 3.4.4. Example 4 396 The Network Administrator of another network may elect to configure 397 the following TE-Class Mapping in order to ensure that no preemption 398 occurs in the DS-TE domain: 400 TE-Class[0] <--> < CT1 , preemption 0 > 401 TE-Class[1] <--> < CT0 , preemption 0 > 402 TE-Class[i] <--> unused, for 2 <= i <= 7 404 Voice LSPs would then be configured with: 405 - CT=CT1, set-up priority =0, holding priority=0 407 Data LSPs would then be configured with: 408 - CT=CT0, set-up priority =0, holding priority=0 410 No LSP would then be able to preempt any other LSP. 412 3.4.5. Example 5 414 The Network Administrator of another network may elect to configure 415 the following TE-Class Mapping in view of increased network stability 416 through a more limited use of preemption: 418 TE-Class[0] <--> < CT1 , preemption 0 > 419 TE-Class[1] <--> < CT1 , preemption 1 > 420 TE-Class[2] <--> < CT0 , preemption 1 > 421 TE-Class[3] <--> < CT0 , preemption 2 > 422 TE-Class[i] <--> unused, for 4 <= i <= 7 424 Large size Voice LSPs could be configured with: 425 - CT=CT1, set-up priority = 0, holding priority=0. 427 Small size Voice LSPs could be configured with: 428 - CT=CT1, set-up priority = 1, holding priority=0. 430 Large size Data LSPs could be configured with: 431 - CT=CT0, set-up priority = 2, holding priority=1. 433 Small size Data LSPs could be configured with: 434 - CT=CT0, set-up priority = 2, holding priority=2. 436 Le Faucheur et. al 8 438 Protocols for Diff-Serv-aware TE June 2002 440 A new large size Voice LSP would be able to preempt a Data LSP in 441 case they contend for resources, but it would not be able to preempt 442 any Voice LSP even a small size Voice LSP. 444 A new small size Voice LSP would be able to preempt a small size Data 445 LSP in case they contend for resources, but it would not be able to 446 preempt a large size Data LSP or any Voice LSP. 448 A Data LSP would not be able to preempt any other LSP. 450 4. IGP Advertisement 452 This section only discusses the differences with the IGP 453 advertisement supported for MPLS Traffic Engineering as per [OSPF-TE] 454 and [ISIS-TE]. The rest of the IGP advertisement is unchanged. 456 4.1. Bandwidth Constraints 458 As detailed above in section 3.1.1, up to 8 Bandwidth Constraints ( 459 BCb, 0 <= b <= 7) are configurable on any given link. 461 With DS-TE, the existing "Maximum Reservable Bw" sub-TLV is retained 462 with a generalized semantic so that it is now interpreted as 463 Bandwidth Constraint 0 (BC0). 465 DS-TE also defines the following optional sub-TLV to advertise the 466 eight potential Bandwidth Constraints (BC0 to BC7): 468 "Bandwidth Constraints" sub-TLV: 469 TBD - Bandwidth Constraint Model Id (1 octet) 470 - Bandwidth Constraints (Nx4 octets) 472 Where: 474 - Bandwidth Constraint Model Id: 1 octet identifier for the 475 Bandwidth Constraints Model currently in use by the LSR 476 initiating the IGP advertisement. 477 Values 0 to 127 are to be allocated by the TEWG to identify 478 Bandwidth Constraints Models defined in the TEWG. Value 0 479 identifies the Russian Doll Bandwidth Constraint Model 480 defined in section 9. 481 Values 128 to 255 are for experimental use. 483 - Bandwidth Constraints: contains BC0, BC1,... BCN-1. 484 Each Bandwidth Constraint is encoded in 32 bits in IEEE 485 floating point format. The units are bytes (not bits!) per 486 second. It is recommended that only the Bandwidth Constraints 487 corresponding to active CTs be advertised in order to 488 minimize the impact on IGP scalability. 490 A DS-TE LSR MAY optionally advertise Bandwidth Constraints. 492 Le Faucheur et. al 9 494 Protocols for Diff-Serv-aware TE June 2002 496 A DS-TE LSR which does advertise Bandwidth Constraints MUST use the 497 new "Bandwidth Constraints" sub-TLV to do so. For example, where a 498 Service Provider deploys DS-TE with two active CTs, only two 499 Bandwidth Constraints per link would be meaningful (assuming, for 500 instance, the Russian Doll Bandwidth Constraint Model defined in 501 section 9). A DS-TE LSR which does advertise Bandwidth Constraint 502 would include the "Bandwidth Constraints" sub-TLV in the IGP 503 advertisement and this should contain BC0 and BC1. 505 A DS-TE LSR which does advertise Bandwidth Constraints, MAY also 506 include the existing "Maximum Reservable Bw" sub-TLV. This may be 507 useful in migration situations where some LSRs in the network are not 508 DS-TE capable (see Appendix G) and thus do not understand the new 509 "Bandwidth Constraints" sub-TLV. IN that case, the DS-TE LSR MUST set 510 the value of the "Maximum Reservable Bw" sub-TLV to the same value as 511 the one for BC0 encoded in the "Bandwidth Constraints" sub-TLV. 513 A DS-TE LSR receiving both the old "Maximum Reservable Bw" sub-TLV 514 and the new "Bandwidth Constraints" sub-TLV for a given link MAY 515 ignore the "Maximum Reservable Bw" sub-TLV. 517 A DS-TE LSR receiving the "Bandwidth Constraints" sub-TLV with a 518 Bandwidth Constraint Model Id which does not match the Bandwidth 519 Constraint Model it currently uses, MAY generate a warning to the 520 operator reporting the inconsistency between Bandwidth Constraint 521 Models used on different links. If the DS-TE LSR does not support the 522 Bandwidth Constraint Model designated by the Bandwidth Constraint 523 Model Id, or if the DS-TE LSR does not support operations with 524 multiple simultaneous Bandwidth Constraint Models, the DS-TE LSR MAY 525 ignore the corresponding TLV. 527 4.2. Unreserved Bandwidth 529 With DS-TE, the existing "Unreserved Bandwidth" sub-TLV is retained 530 as the only vehicle to advertise dynamic bandwidth information 531 necessary for Constraint Based Routing on Head-ends, except that it 532 is used with a generalized semantic. The Unreserved Bandwidth sub-TLV 533 still carries eight bandwidth values but they now correspond to the 534 unreserved bandwidth for each of the TE-Class (instead of for each 535 preemption as per existing TE). 537 More precisely, a DS-TE LSR MUST support the Unreserved Bandwidth 538 sub-TLV with a definition which is generalized into the following: 540 The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth 541 not yet reserved for each of the eight TE-classes, in IEEE floating 542 point format arranged in increasing order of TE-Class index, with 543 unreserved bandwidth for TE-Class [0] occurring at the start of the 544 sub-TLV, and unreserved bandwidth for TE-Class [7] at the end of the 545 sub-TLV. The unreserved bandwidth value for TE-Class [i] ( 0 <= i <= 547 Le Faucheur et. al 10 549 Protocols for Diff-Serv-aware TE June 2002 551 7) is referred to as "Unreserved TE-Class [i]". It indicates the 552 bandwidth that is available, for reservation, to an LSP which : 553 - transports a Traffic Trunk from the Class-Type of TE- 554 Class[i], and 555 - has a setup priority corresponding to the preemption priority 556 of TE-Class[i]. 558 The units are bytes per second. 560 Since the bandwidth values are now ordered by TE-class index and thus 561 can relate to different CTs with different bandwidth constraints and 562 can relate to any arbitrary preemption priority, a DS-TE LSR MUST NOT 563 assume any ordered relationship among these bandwidth. 565 With existing TE, since all preemption priorities reflect the same 566 (and only) bandwidth constraints and since bandwidth values are 567 advertised in preemption priority order, the following relationship 568 is always true, and is often assumed by TE implementations: 570 If i < j , then "Unreserved Bw [i]" >= "Unreserved Bw [j]" 572 With DS-TE, no relationship is to be assumed so that: 573 If i < j , then 574 "Unreserved TE-Class [i]" = "Unreserved TE-Class [j]" 575 OR 576 "Unreserved TE-Class [i]" > "Unreserved TE-Class [j]" 577 OR 578 "Unreserved TE-Class [i]" < "Unreserved TE-Class [j]". 580 Since some Bandwidth Constraints Models are such that a given Class- 581 Type is constrained by multiple Bandwidth Constraints (as in the case 582 of the Russian Doll Bandwidth Constraint Model specified in section 583 9), the value to be advertised by the IGP in "Unreserved TE-Class 584 [i]" MUST reflect all of the Bandwidth Constraints relevant to the CT 585 associated with TE-Class [i]. 587 If TE-Class[i] is unused, the value advertised by the IGP in 588 "Unreserved TE-Class [i]" MUST be set to zero. 590 4.3. Local Overbooking Multiplier 592 The following additional optional sub-TLV is defined for DS-TE: 594 "Local Overbooking Multiplier" sub-TLV: 595 TBD - per-CT Local Overbooking Multipliers (N x 2 octets). 596 Each LOM is encoded as an integer in the range 597 [ 0 , (2^16 -1) ] that represents LOM expressed in 598 percentage. For example, a LOM of 1 (i.e. 100%) is encoded 599 as 100, and represents no overbooking/underbooking. A LOM 600 of 2 (i.e. 200%) is encoded as 200, and represents an 601 overbooking of 2. A LOM of 0.5 (i.e. 50%) is encoded as 50 602 and represents an underbooking of 2. 604 Le Faucheur et. al 11 606 Protocols for Diff-Serv-aware TE June 2002 608 where N is the number of per-CT Local Overbooking Multipliers 609 actually advertised. It is recommended that only the LOMs 610 corresponding to active CTs be included, in order to minimize the 611 impact on IGP scalability. 613 A DS-TE LSR supporting the optional local overbooking method MAY 614 optionally advertise LOMs. A DS-TE LSR which does advertise LOMs MUST 615 use the "Local Overbooking Multiplier" sub-TLV to do so. 617 For example, where a Service Provider only deploys DS-TE with two CTs 618 and makes use of the Local Overbooking method, the "Local Overbooking 619 Multiplier" sub-TLV may optionally be used and would then contain 620 only LOM[0] and LOM[1. 622 Note that the use of this sub-TLV is only optional even when the 623 optional Local Overbooking method is actually used (and thus when the 624 Local Overbooking Multipliers parameters are actually configured 625 locally on some or all links). Its use may assist in head-end 626 prediction of network response to LSP establishment. 628 5. LSP Signaling 630 This section only describes the signaling extensions beyond those 631 already specified for MPLS Traffic Engineering as per [RSVP-TE] and 632 [CR-LDP] and for Diff-Serv over MPLS as per [DIFF-MPLS]. 634 The Class-Type of the LSP is signaled in RSVP-TE and CR-LDP for DS-TE 635 in order for LSRs to enforce the appropriate bandwidth constraint(s) 636 for admission control and bandwidth accounting. 638 Protocol and procedure extensions for signaling of the Class-Type are 639 specified in details in Appendix A and B respectively for RSVP-TE and 640 CR-LDP. 642 A DS-TE implementation based on RSVP-TE MUST support the protocol and 643 procedure extensions specified in Appendix A. 645 A DS-TE implementation based on CR-LDP MUST support the protocol and 646 procedure extensions specified in Appendix B. 648 6. Constraint Based Routing 650 Let us consider the case where a path needs to be computed for an LSP 651 whose Class-Type is configured to CTc and whose set-up preemption 652 priority is configured to p. 654 Le Faucheur et. al 12 656 Protocols for Diff-Serv-aware TE June 2002 658 Then the pair of CTc and p will map to one of the TE-Classes defined 659 in the TE-Class mapping. Let us assume that this is the i-th TE-Class 660 i.e. TE-Class[i]. 662 The Constraint Based Routing algorithm of a DS-TE LSR is still only 663 required to perform path computation satisfying a single bandwidth 664 constraint which is to fit in "Unreserved TE-Class [i]" as advertised 665 by the IGP for every link. Thus, no changes are required to the 666 existing TE Constraint Based Routing algorithm itself. 668 The Constraint Based Routing algorithm MAY also optionally take into 669 account, when used, the optional information advertised in IGP which 670 are the Bandwidth Constraints and the Local Overbooking Multipliers. 671 As an example, the Bandwidth Constraints MIGHT be used as a tie- 672 breaker criteria in situations where multiple paths, otherwise 673 equally attractive, are possible. 675 7. Diff-Serv scheduling 677 The Class-Type signaled at LSP establishment MAY optionally be used 678 by DS-TE LSRs to dynamically adjust the resources allocated to the 679 Class-Type by the Diff-Serv scheduler. In addition, the Diff-Serv 680 information (i.e. the PSC) signaled by the TE-LSP signaling protocols 681 as specified in [DIFF-MPLS], if used, MAY optionally be used by DS-TE 682 LSRs to dynamically adjust the resources allocated to a PSC/OA within 683 a Class Type by the Diff-Serv scheduler. 685 8. Existing TE as a Particular Case of DS-TE 687 We observe that existing TE can be viewed as a particular case of DS- 688 TE where: 690 (i) a single Class-Type is used, all 8 preemption priorities 691 are allowed for that Class-Type and the following TE-Class 692 Mapping is used: 694 TE-Class[i] <--> < CT0 , preemption i > 695 Where 0 <= i <= 7. 697 (ii) optional per-CT Local Overbooking Multipliers are not 698 used. 700 In that case, DS-TE behaves as existing TE. 702 As with existing TE, the IGP advertises: 703 - Unreserved Bandwidth for each of the 8 preemption priorities 704 - Max Link Bandwidth 706 As with existing TE, the IGP may also optionally advertise BC0 = 707 Maximum Reservable Bandwidth. 709 Le Faucheur et. al 13 711 Protocols for Diff-Serv-aware TE June 2002 713 Note that, unlike with existing TE, the IGP will also advertise the 714 Bandwidth Constraint sub-TLV (which will contain BC0). 716 Since all LSPs transport traffic from CT0, LSP Signaling is done 717 without explicit signaling of the Class-Type (which is only used for 718 other Class-Types than CT0 as explained in Appendix A and B). 720 9. Russian Doll Bandwidth Constraints Model 722 9.1. Definition 724 [DSTE-REQ] introduces the concept of Bandwidth Constraints Models to 725 characterize the Bandwidth Constraints associated with CTs, but it 726 does not actually select one particular Model. 728 [DSTE-REQ] also requires that a default Bandwidth Constraints Model 729 be specified. The purpose of such a default Model is to ensure that 730 there is at least one common Bandwidth Constraints model supported 731 across all DS-TE implementations to allow for easier deployment of 732 DS-TE. 734 This section specifies a default Bandwidth Constraints Model which is 735 referred to as the "Russian Dolls" Bandwidth Constraints model. DS-TE 736 implementations MUST support the Russian Dolls models and MAY also 737 optionally support other Bandwidth Constraints Models. 739 The "Russian Dolls" model is defined in the following manner 740 (assuming that the optional per-CT Local Overbooking Multipliers are 741 not used - i.e. LOM[c]=1 , 0<=c<=7 ): 742 o Maximum Number of Bandwidth Constraints (MaxBC)= Maximum 743 Number of Class-Types (MaxCT) = 8 744 o All LSPs supporting Traffic Trunks from CTc (with 745 b<=c<=7) use no more than BCb i.e.: 746 - All LSPs from CT7 use no more than BC7 747 - All LSPs from CT6 and CT7 use no more than BC6 748 - All LSPs from CT5, CT6 and CT7 use no more than BC5 749 - etc. 750 - All LSPs from CT0, CT1,... CT7 use no more than BC0 752 Purely for illustration purposes, the diagram below represents the 753 Russian Doll Bandwidth Constraints model in a pictorial manner when 3 754 Class-Types are active: 756 I------------------------------------------------------I 757 I-------------------------------I I 758 I--------------I I I 759 I CT2 I CT2+CT1 I CT2+CT1+CT0 I 760 I--------------I I I 761 I-------------------------------I I 762 I------------------------------------------------------I 764 Le Faucheur et. al 14 766 Protocols for Diff-Serv-aware TE June 2002 768 I-----BC2------> 769 I----------------------BC1------> 770 I---------------------------------------------BC0------> 772 While simpler or, conversely, more flexible/sophisticated Bandwidth 773 Constraints models can be defined, the Russian Dolls model is an 774 attractive trade-off for the following reasons: 775 - Network administrators generally find it superior to the most 776 basic model of a single independent BC per CT (which, in 777 typical deployment scenarios, results in either capacity 778 wastage, low priority Traffic Trunk starvation and/or 779 degradation of QoS objectives) 780 - network administrators generally find it sufficient for the 781 real life deployments currently anticipated (e.g. it 782 addresses all the scenarios described in [DSTE-REQ]) 783 - it remains simple and only requires limited protocol 784 extensions, while more sophisticated Bandwidth Constraints 785 model may require more complex extensions. 787 More details on the properties of the Russian Dolls model can be 788 found in [RUSSIAN] and [BCMODEL]. 790 As an example usage of the "Russian Doll" Bandwidth Constraints 791 Model, a network administrator using one CT for Voice (CT1) and one 792 CT for data (CT0) might configure on a given link: 793 - BC0 = 2.5 Gb/s (i.e. Voice + Data is limited to 2.5 Gb/s) 794 - BC1= 1.5 Gb/s (i.e. Voice is limited to 1.5 Gb/s). 796 Another (or other) Bandwidth Constraints Model(s) may be specified in 797 another (or other) document(s) to address other potential 798 requirements which may emerge from Service Providers real life 799 deployment and which cannot be efficiently addressed by the Russian 800 Dolls model. This is outside the scope of the current specification. 802 The Russian Doll Bandwidth Constraints Model can be supported with 803 the extensions defined earlier in this document for DS-TE. Note that 804 a number of other Bandwidth Constraints could also be supported with 805 these same extensions. Note also that not all Bandwidth Constraints 806 models could be supported with these extensions and some may require 807 additional or different extensions. Both of these situations are 808 beyond the scope of this specification. 810 Note that as per [DSTE-REQTS], while deployment of DS-TE is expected 811 to be easier when a single Bandwidth Constraints Model is used on all 812 the DS-TE LSRs of a DS-TE domain, the DS-TE solution itself does not 813 prevent a network operator to activate different Bandwidth 814 Constraints models on different links in a network, if he/she wishes 815 to do so and if the particular DS-TE LSR implementations allow this. 817 9.2. Computing "Unreserved TE-Class [i]" 819 Le Faucheur et. al 15 821 Protocols for Diff-Serv-aware TE June 2002 823 We first observe that, for existing TE, details on admission control 824 algorithms for TE LSPs, and consequently details on formulas for 825 computing the unreserved bandwidth, are outside the scope of the 826 current IETF work. This is left for vendor differentiation. Note that 827 this does not compromise interoperability across various 828 implementations since the TE schemes rely on LSRs to advertise their 829 local view of the world in terms of Unreserved Bw to other LSRs. This 830 way, regardless of the actual local admission control algorithm used 831 on one given LSR, Constraint Based Routing on other LSRs can rely on 832 advertised information to determine whether an additional LSP will be 833 accepted or rejected by the given LSR. The only requirement is that 834 an LSR advertises unreserved bandwidth values which are consistent 835 with its specific local admission control algorithm and take into 836 account the holding preemption priority of established LSPs. 838 In the context of DS-TE, again, details on admission control 839 algorithms are left for vendor differentiation and formulas for 840 computing the unreserved bandwidth for TE-Class[i] are outside the 841 scope of this specification. However, DS-TE places the additional 842 requirement on the LSR that the unreserved bandwidth values 843 advertised MUST reflect all of the Bandwidth Constraints relevant to 844 the CT associated with TE-Class[i], as discussed in section 4.2. 846 As with existing TE, DS-TE assumes that the holding preemption 847 priority of established LSPs is the one considered (as opposed to 848 their set-up preemption priority) for the purpose of computing the 849 unreserved bandwidth for TE-Class [i]. 851 Example formulas for computing "Unreserved TE-Class [i]" are provided 852 in Appendix C. 854 9.3. Admission Control Rules 856 A DS-TE LSR MUST support the following admission control rule: 858 Regardless of how the admission control algorithm actually computes 859 the unreserved bandwidth for TE-Class[i] for one of its local link, 860 an LSP of bandwidth B, of set-up preemption priority p and of Class- 861 Type CTc is admissible on that link iff: 863 B <= unreserved bandwidth for TE-Class[i], AND 864 B <= Max Link Bandwidth 866 Where 868 - TE-Class [i] maps to < CTc , p > in the LSR's configured TE- 869 Class mapping 870 - Max Link Bandwidth is the maximum link bandwidth configured 871 on the link and advertised in IGP. 873 Le Faucheur et. al 16 875 Protocols for Diff-Serv-aware TE June 2002 877 Note that this admission control rule assumes that the optional per- 878 CT Local Overbooking Multipliers are not used (i.e. LOM[c]=1, 879 0<=c<= 7 ). 881 9.4. Support of Optional Local Overbooking Method 883 We remind the reader that, as discussed in section 3.1.2, the "LSP/link 884 size overbooking" method (which does not use the Local Overbooking 885 Multipliers) is expected to be sufficient in many DS-TE environments. 886 It is expected that the optional Local Overbooking method (and LOMs) 887 would only be used in specific environments, in particular where 888 different overbooking ratios need to be enforced on different links of 889 the DS-TE domain and cross-effect of overbooking across CTs needs to be 890 accounted for very accurately. 892 This section discusses the impact of the optional local overbooking 893 method on the Russian Dolls model and associated rules and formula. 894 This is only applicable in the cases where the optional local 895 overbooking method is indeed supported by the DS-TE LSRs and actually 896 deployed. 898 9.4.1. Russian Dolls Model Definition 900 Let us define "Reserved(CTc)" as the sum of the bandwidth reserved by 901 all established LSPs which belong to CTc. 903 Let us define "Normalised(CTc)" as "Reserved(CTc)/LOM(c)". 905 When the optional Local Overbooking method is supported, the "Russian 906 Doll" model definition MUST be extended in the following manner: 907 - Maximum Number of Bandwidth Constraints (MaxBC)= Maximum 908 Number of Class-Types (MaxCT) = 8 909 - SUM [ Normalised(CTc), for b<=c<=7 ] <= BCb i.e.: 910 o [ Normalised(CT7) ] <= BC7 911 o [ Normalised(CT6) + Normalised(CT7) ] <= BC6 912 o [ Normalised(CT5) + Normalised(CT6) + 913 Normalised(CT7) ] <= BC5 914 o etc. 915 o [ Normalised(CT0) + Normalised(CT1) + 916 ... 917 Normalised(CT6) + Normalised(CT7) ] <= BC0 919 Purely for illustration purposes, the diagram below represents the 920 Russian Doll Bandwidth Constraints model in a pictorial manner when 3 921 Class-Types are active and the local overbooking method is used: 923 I--------------------------------------------------------------I 924 I-----------------------------------------I Normalised(CT2) I 925 I--------------------I Normalised(CT2) I + I 926 I Normalised(CT2) I + I Normalised(CT1) I 927 I--------------------I Normalised(CT1) I + I 928 I-----------------------------------------I Normalised(CT0) I 930 Le Faucheur et. al 17 932 Protocols for Diff-Serv-aware TE June 2002 934 I--------------------------------------------------------------I 936 I--------BC2---------> 937 I-------------------------BC1-------------> 938 I-----------------------------------------------BC0------------> 940 9.4.2. Bandwidth Constraints 942 When the optional Local Overbooking method is supported, the 943 relationship among the Bandwidth Constraints values to be enforced by 944 the LSR is not modified. The LSR MUST still ensure that BCi is 945 configured smaller or equal to BCj, where i is greater than j. 947 When the Bandwidth Constraints are optionally advertised in the 948 Bandwidth Constraints sub-TLV, the values advertised are the BC 949 values as configured (i.e. LOMs do not affect the advertisement of 950 BCs). 952 9.4.3. Computing "Unreserved TE-Class [i]" 954 As discussed in section 9.2, details on formulas for computing the 955 unreserved bandwidth, are outside the scope of the current IETF work. 956 However, when the Local Overbooking method is supported, the 957 advertised unreserved bandwidth values MUST reflect the per-CT Local 958 Overbooking Multipliers. This MUST be consistent with how the LOMs 959 are taken into account in the specific local admission control 960 algorithm. 962 Note that this may result in the Unreserved Bandwidth values 963 advertised for a particular CT being larger than one or more of the 964 BCs relevant to this CT (since BCs are not affected by LOMs). 966 Example formulas for computing "Unreserved TE-Class [i]" when local 967 overbooking is supported are provided in section 2 of Appendix C. 969 9.4.4. Max Link Bandwidth 971 The Max Link bandwidth parameter effectively controls the maximum 972 size of a single LSP. The value advertised in the Max Link Bandwidth 973 sub-TLV is the value as configured locally (i.e. LOMs do not affect 974 the advertisement of the Max Link Bandwidth). 976 9.4.5. Admission Control Rules 978 When the optional Local Overbooking method is supported, the DS-TE 979 LSR MUST support the same admission control rules as without LOM: 981 Regardless of how the admission control algorithm actually computes 982 the unreserved bandwidth for TE-Class[i] for one of its local link, 984 Le Faucheur et. al 18 986 Protocols for Diff-Serv-aware TE June 2002 988 an LSP of bandwidth B, of set-up preemption priority p and of Class- 989 Type CTc is admissible on that link iff: 991 (i) B <= unreserved bandwidth for TE-Class[i], AND 992 (ii) B <= Max Link Bandwidth 994 Where 996 - TE-Class [i] maps to < CTc , p > in the LSR's configured TE- 997 Class mapping 998 - Max Link Bandwidth is the maximum link bandwidth configured 999 on the link and advertised in IGP. 1000 Condition (i) above applies to B [and not B/LOM(c) ] because the LOM 1001 is already factored in the unreserved bandwidth values. 1003 Condition (ii) above also applies to B [and not B/LOM(c) ]. Condition 1004 (ii) controls the maximum bandwidth that a single LSP can grab on its 1005 own, by limiting it to the Maximum Link Bandwidth. Since 1006 "overbooking" is usually only (fully) achievable when a sufficient 1007 number of LSPs share the Link Bandwidth, it is not appropriate to 1008 factor in the LOM when assessing the maximum bandwidth that a single 1009 LSP can grab on a link. 1011 9.4.6. Example Usage of LOM 1013 To illustrate usage of the local overbooking method, let's consider a 1014 DS-TE deployment where two CTs (CT0 for data and CT1 for voice) and a 1015 single preemption priority are used. 1017 The TE-Class mapping is the following: 1019 TE-Class <--> CT, preemption 1020 ============================== 1021 0 CT0, 0 1022 1 CT1, 0 1023 rest unused 1025 Let's assume that on a given link, BCs and LOMs are configured in the 1026 following way: 1027 BC0 = 200 1028 BC1 = 100 1029 LOM(0) = 4 (i.e. = 400%) 1030 LOM(1) = 2 (i.e. = 200%) 1032 Let's further assume that the DS-TE LSR uses the example formulas 1033 presented in section 2 of Appendix C for computing unreserved 1034 bandwidth values. 1036 If there is no established LSP on the considered link, the LSR will 1037 advertise for that link in IGP : 1038 Unreserved TE-Class [0] = 4 x (200 - 0/4 - 0/2 )= 800 1039 Unreserved TE-Class [1] = 2 x (100- 0/2) = 200 1041 Le Faucheur et. al 19 1043 Protocols for Diff-Serv-aware TE June 2002 1045 Note again that these values advertised for Unreserved Bandwidth are 1046 larger than BC1 and BC0. 1048 If there is only a single established LSP, with CT=CT0 and BW=100, 1049 the LSR will advertise: 1050 Unreserved TE-Class [0] = 4 x (200 - 100/4 - 0/2 )=700 1051 Unreserved TE-Class [1] = 2 x (100- 0/2) = 200 1053 If there is only a single established LSP, with CT=CT1 and BW=100, 1054 the LSR will advertise: 1055 Unreserved TE-Class [0] = 4 x (200 - 0/4 - 100/2 )= 600 1056 Unreserved TE-Class [1] = 2 x (100- 100/2) = 100 1057 Note that the impact of an LSP on the unreserved bandwidth of a CT 1058 does not depend only on the LOM for that CT: it also depends on the 1059 LOM for the CT of the LSP. This can be seen in our example. A BW=100 1060 tunnel affects Unreserved 1061 CT0 twice as much if it is a CT1 tunnel, than if it is a CT0 tunnel. 1062 It reduces Unreserved CTO by 200 (800->600) rather than by 100 1063 (800->700). This is because LOM(1) is half as big as LOM(0). This 1064 illustrates why the local overbooking method allows very fine 1065 accounting of cross-effect of overbooking across CTs, as compared 1066 with the LSP/link size overbooking method. 1068 If there are two established LSPs, one with CT=CT1 and BW=100 and one 1069 with CT=CT0 and BW=100, the LSR will advertise: 1070 Unreserved TE-Class [0] = 4 x (200 - 100/4 - 100/2) = 500 1071 Unreserved TE-Class [1] = 2 x (100 - 100/2) = 100 1073 If there are two LSPs established, one with CT=CT1 and BW=100, and 1074 one with CT=CT0 and BW=480, the LSR will advertise: 1075 Unreserved TE-Class [0] = 4 x (200 - 480/4 - 100/2) = 120 1076 Unreserved TE-Class [1] = 2 x MIN [ (200 - 480/4 - 100/2), 1077 (100 - 100/2) ] 1078 = 2 x MIN [ 30, 50 ] 1079 = 60 1081 10. Security Considerations 1083 The solution is not expected to add specific security requirements 1084 beyond those of Diff-Serv and existing TE. The security mechanisms 1085 currently used with Diff-Serv and existing TE can be used with this 1086 solution. 1088 11. Acknowledgments 1090 We thank Martin Tatham, Angela Chiu and Pete Hicks for their earlier 1091 contribution in this work. We also thank Sanjaya Choudhury for his 1092 thorough reviews and numerous suggestions. 1094 Le Faucheur et. al 20 1096 Protocols for Diff-Serv-aware TE June 2002 1098 References 1100 [DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv- 1101 aware MPLS Traffic Engineering, draft-ietf-tewg-diff-te-reqts-05.txt, 1102 June 2002. 1104 [OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF, draft- 1105 katz-yeung-ospf-traffic-06.txt, October 2001. 1107 [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft- 1108 ietf-isis-traffic-04.txt, August 2001. 1110 [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 1111 Tunnels", RFC 3209, December 2001. 1113 [CR-LDP] Jamoussi et al, "Constraint-Based LSP Setup using LDP", RFC 1114 3212, January 2002. 1116 [DIFF-MPLS] Le Faucheur et al, "MPLS Support of Diff-Serv", RFC3270, 1117 May 2002. 1119 [RUSSIAN] Le Faucheur, "Considerations on Bandwidth Constraints Model 1120 for DS-TE", draft-lefaucheur-tewg-russian-dolls-00.txt, June 2002. 1122 [BCMODEL] Lai, "Bandwidth Constraints Models for DS-TE", 1123 draft-wlai-tewg-bcmodel-00.txt, June 2002. 1125 Authors' Address: 1127 Francois Le Faucheur 1128 Cisco Systems, Inc. 1129 Village d'Entreprise Green Side - Batiment T3 1130 400, Avenue de Roumanille 1131 06410 Biot-Sophia Antipolis 1132 France 1133 Phone: +33 4 97 23 26 19 1134 Email: flefauch@cisco.com 1136 Jim Boyle 1137 Protocol Driven Networks 1138 1381 Kildaire Farm Road #288 1139 Cary, NC 27511 1140 Phone: +1 919 852-5160 1141 Email: jboyle@pdnets.com 1143 Kireeti Kompella 1144 Juniper Networks, Inc. 1145 1194 N. Mathilda Ave. 1146 Sunnyvale, CA 94099 1147 Email: kireeti@juniper.net 1149 Le Faucheur et. al 21 1151 Protocols for Diff-Serv-aware TE June 2002 1153 William Townsend 1154 Tenor Networks 1155 100 Nagog Park 1156 Acton, MA 01720 1157 Phone: +1-978-264-4900 1158 Email: btownsend@tenornetworks.com 1160 Thomas D. Nadeau 1161 Cisco Systems, Inc. 1162 250 Apollo Drive 1163 Chelmsford, MA 01824 1164 Phone: +1-978-244-3051 1165 Email: tnadeau@cisco.com 1167 Darek Skalecki 1168 Nortel Networks 1169 3500 Carling Ave, 1170 Nepean K2H 8E9 1171 Phone: +1-613-765-2252 1172 Email: dareks@nortelnetworks.com 1174 Appendix A - RSVP Extensions for Diff-Serv-aware TE 1176 In this section we describe extensions to RSVP for support of 1177 Diff-Serv-aware MPLS Traffic Engineering. These extensions are in 1178 addition to the extensions to RSVP defined in [RSVP-TE] for support 1179 of (aggregate) MPLS Traffic Engineering and to the extensions to RSVP 1180 defined in [DIFF-MPLS] for support of Diff-Serv over MPLS. 1182 1. Diff-Serv-aware TE related RSVP Messages Format 1184 One new RSVP Object is defined in this document: the CLASSTYPE 1185 Object. Detailed description of this Object is provided below. This 1186 new Object is applicable to Path messages. This specification only 1187 defines the use of the CLASSTYPE Object in Path messages used to 1188 establish LSP Tunnels in accordance with [RSVP-TE] and thus 1189 containing a Session Object with a C-Type equal to LSP_TUNNEL_IPv4 1190 and containing a LABEL_REQUEST object. 1192 Restrictions defined in [RSVP-TE] for support of establishment of LSP 1193 Tunnels via RSVP are also applicable to the establishment of LSP 1194 Tunnels supporting Diff-Serv-aware Traffic Engineering. For instance, 1195 only unicast LSPs are supported and Multicast LSPs are for further 1196 study. 1198 This new CLASSTYPE object is optional with respect to RSVP so that 1199 general RSVP implementations not concerned with MPLS LSP set up do 1200 not have to support this object. 1202 An LSR supporting Diff-Serv-aware Traffic Engineering in compliance 1203 with this specification MUST support the CLASSTYPE Object. 1205 Le Faucheur et. al 22 1207 Protocols for Diff-Serv-aware TE June 2002 1209 1.1. Path Message Format 1211 The format of the Path message is as follows: 1213 ::= [ ] 1214 1215 1216 [ ] 1217 1218 [ ] 1219 [ ] 1220 [ ] 1221 [ ... ] 1222 [ ] 1224 ::= [ ] 1225 [ ] 1226 [ ] 1228 2. CLASSTYPE Object 1230 The CLASSTYPE object format is shown below. 1232 2.1. CLASSTYPE object 1234 class = TBD, C_Type = 1 (need to get an official class num from the 1235 IANA with the form 0bbbbbbb) 1237 0 1 2 3 1238 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 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 | Reserved | CT | 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1243 Reserved : 29 bits 1244 This field is reserved. It must be set to zero on transmission 1245 and must be ignored on receipt. 1247 CT : 3 bits 1248 Indicates the Class-Type. Values currently allowed are 1, 2, ... 1249 , 7. 1251 3. Handling CLASSTYPE Object 1253 To establish an LSP tunnel with RSVP, the sender LSR creates a Path 1254 message with a session type of LSP_Tunnel_IPv4 and with a 1255 LABEL_REQUEST object as per [RSVP-TE]. The sender LSR may also 1256 include the DIFFSERV object as per [DIFF-MPLS]. 1258 Le Faucheur et. al 23 1260 Protocols for Diff-Serv-aware TE June 2002 1262 If the LSP is associated with Class-Type 0, the sender LSR MUST NOT 1263 include the CLASSTYPE object in the Path message. 1265 If the LSP is associated with Class-Type N (1 <= N <=7), the sender 1266 LSR MUST include the CLASSTYPE object in the Path message with the 1267 Class-Type (CT) field set to N. 1269 If a path message contains multiple CLASSTYPE objects, only the first 1270 one is meaningful; subsequent CLASSTYPE object(s) MUST be ignored and 1271 MUST not be forwarded. 1273 Each LSR along the path MUST record the CLASSTYPE object, when 1274 present, in its path state block. 1276 If the CLASSTYPE object is not present in the Path message, the LSR 1277 MUST associate the Class-Type 0 to the LSP. 1279 The destination LSR responding to the Path message by sending a Resv 1280 message MUST NOT include a CLASSTYPE object in the Resv message 1281 (whether the Path message contained a CLASSTYPE object or not). 1283 During establishment of an LSP corresponding to the Class-Type N, the 1284 LSR MUST perform admission control over the bandwidth available for 1285 that particular Class-Type. 1287 An LSR that recognizes the CLASSTYPE object and that receives a path 1288 message which contains the CLASSTYPE object but which does not 1289 contain a LABEL_REQUEST object or which does not have a session type 1290 of LSP_Tunnel_IPv4, MUST send a PathErr towards the sender with the 1291 error code 'Diff-Serv-aware TE Error' and an error value of 1292 'Unexpected CLASSTYPE object'. Those are defined below in section 5. 1294 An LSR receiving a Path message with the CLASSTYPE object, which 1295 recognizes the CLASSTYPE object but does not support the particular 1296 Class-Type, MUST send a PathErr towards the sender with the error 1297 code 'Diff-Serv-aware TE Error' and an error value of 'Unsupported 1298 Class-Type'. Those are defined below in section 5. 1300 An LSR receiving a Path message with the CLASSTYPE object, which 1301 recognizes the CLASSTYPE object but determines that the Class-Type 1302 value is not valid (i.e. Class-Type value 0), MUST send a PathErr 1303 towards the sender with the error code 'Diff-Serv-aware TE Error' and 1304 an error value of 'Invalid Class-Type value'. Those are defined below 1305 in section 5. 1307 An LSR receiving a Path message with the CLASSTYPE object, which: 1308 - recognizes the CLASSTYPE object, 1309 - supports the particular Class-Type, but 1310 - determines that the tuple formed by (i) this Class-Type and 1311 (ii) the set-up priority signaled in the same Path message, 1312 is not one of the eight TE-classes configured in the TE-class 1313 mapping, 1315 Le Faucheur et. al 24 1317 Protocols for Diff-Serv-aware TE June 2002 1319 MUST send a PathErr towards the sender with the error code 'Diff- 1320 Serv-aware TE Error' and an error value of 'CT and setup priority do 1321 not form a configured TE-Class'. Those are defined below in section 1322 5. 1324 An LSR receiving a Path message with the CLASSTYPE object, which: 1325 - recognizes the CLASSTYPE object, 1326 - supports the particular Class-Type, but 1327 - determines that the tuple formed by (i) this Class-Type and 1328 (ii) the holding priority signaled in the same Path message, 1329 is not one of the eight TE-classes configured in the TE-class 1330 mapping, 1331 MUST send a PathErr towards the sender with the error code 'Diff- 1332 Serv-aware TE Error' and an error value of 'CT and holding priority 1333 do not form a configured TE-Class'. Those are defined below in 1334 section 5. 1336 An LSR receiving a Path message with the CLASSTYPE object and with 1337 the DIFFSERV object for an L-LSP, which: 1338 - recognizes the CLASSTYPE object, 1339 - has local knowledge of the relationship between Class-Types 1340 and PSC (e.g. via configuration) 1341 - based on this local knowledge, determines that the PSC 1342 signaled in the DIFFSERV object is inconsistent with the 1343 Class-Type signaled in the CLASSTYPE object, 1344 MUST send a PathErr towards the sender with the error code 'Diff- 1345 Serv-aware TE Error' and an error value of 'Inconsistency between 1346 signaled PSC and signaled CT'. Those are defined below in section 5. 1348 An LSR receiving a Path message with the CLASSTYPE object and with 1349 the DIFFSERV object for an E-LSP, which: 1350 - recognizes the CLASSTYPE object, 1351 - has local knowledge of the relationship between Class-Types 1352 and PHBs (e.g. via configuration) 1353 - based on this local knowledge, determines that the PHBs 1354 signaled in the MAP entries of the DIFFSERV object are 1355 inconsistent with the Class-Type signaled in the CLASSTYPE 1356 object, 1357 MUST send a PathErr towards the sender with the error code 'Diff- 1358 Serv-aware TE Error' and an error value of 'Inconsistency between 1359 signaled PHBs and signaled CT'. Those are defined below in section 5. 1361 An LSR MUST handle the situations where the LSP can not be accepted 1362 for other reasons than those already discussed in this section, in 1363 accordance with [RSVP-TE] and [DIFF-MPLS] (e.g. a reservation is 1364 rejected by admission control, a label can not be associated). 1366 4. Non-support of the CLASSTYPE Object 1368 An LSR that does not recognize the CLASSTYPE object Class-Num MUST 1369 behave in accordance with the procedures specified in [RSVP] for an 1370 unknown Class-Num whose format is 0bbbbbbb (i.e. it must send a 1372 Le Faucheur et. al 25 1374 Protocols for Diff-Serv-aware TE June 2002 1376 PathErr with the error code 'Unknown object class' toward the 1377 sender). 1379 An LSR that recognizes the CLASSTYPE object Class-Num but does not 1380 recognize the CLASSTYPE object C-Type, MUST behave in accordance with 1381 the procedures specified in [RSVP] for an unknown C-type (i.e. it 1382 must send a PathErr with the error code 'Unknown object C-Type' 1383 toward the sender). 1385 In both situations, this causes the path set-up to fail. The sender 1386 SHOULD notify management that a LSP cannot be established and 1387 possibly might take action to retry reservation establishment without 1388 the CLASSTYPE object. 1390 5. Error Codes For Diff-Serv-aware TE 1392 In the procedures described above, certain errors must be reported as 1393 a 'Diff-Serv-aware TE Error'. The value of the 'Diff-Serv-aware TE 1394 Error' error code is (TBD). 1396 The following defines error values for the Diff-Serv-aware TE Error: 1398 Value Error 1400 1 Unexpected CLASSTYPE object 1401 2 Unsupported Class-Type 1402 3 Invalid Class-Type value 1403 4 CT and setup priority do not form a configured TE-Class 1404 5 CT and holding priority do not form a configured 1405 TE-Class 1406 6 Inconsistency between signaled PSC and signaled CT 1407 7 Inconsistency between signaled PHBs and signaled CT 1409 Appendix B - CR-LDP Extensions for Diff-Serv-aware TE 1411 CR-LDP, defined in [CR-LDP], is an extension to LDP, defined in 1412 [LDP], for support of (aggregate) MPLS Traffic Engineering. In this 1413 section we describe extensions to CR-LDP for support of Diff-Serv- 1414 aware MPLS Traffic Engineering. These extensions are in addition to 1415 the extensions to LDP defined in [DIFF-MPLS] for support of Diff-Serv 1416 over MPLS. They closely resemble the extensions to RSVP defined in 1417 the previous section. 1419 Note that extensions of this section for support of Diff-Serv-aware 1420 Traffic Engineering are not applicable to LDP due to the fact that 1421 LDP does not support MPLS Traffic Engineering and bandwidth 1422 reservation in particular. 1424 1. Diff-Serv-aware TE related CR-LDP Messages Encoding 1426 One new CR-LDP TLV is defined in this document: the Class Type TLV. 1428 Le Faucheur et. al 26 1430 Protocols for Diff-Serv-aware TE June 2002 1432 Detailed description of this TLV is provided below. This new TLV is 1433 applicable to Label Request messages. 1435 Restrictions defined in [CR-LDP] for support of establishment of LSPs 1436 via CR-LDP are also applicable to the establishment of LSPs 1437 supporting Diff-Serv-aware Traffic Engineering: for instance, only 1438 unicast LSPs are supported and multicast LSPs are for further study. 1440 This new Class Type TLV is optional with respect to CR-LDP so that 1441 general CR-LDP implementations not concerned with Diff-Serv-aware 1442 Traffic Engineering are not required to support this TLV. 1444 An LSR supporting Diff-Serv-aware Traffic Engineering in compliance 1445 with this specification MUST support the Class Type TLV. 1447 1.1. Label Request Message Encoding 1449 The encoding for the CR-LDP Label Request message is extended as 1450 follows, to optionally include the Class Type TLV: 1452 0 1 2 3 1453 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 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 |0| Label Request (0x0401) | Message Length | 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1457 | Message ID | 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 | FEC TLV | 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 | Diff-Serv TLV (LDP, optional) | 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 | Class Type TLV (CR-LDP optional) | 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 | Other CR-LDP TLVs | 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1468 The extension is based on a related LDP extension, defined in [DIFF- 1469 MPLS], for support of Diff-Serv TLV but further extended for CR-LDP 1470 with CR-LDP TLVs. 1472 2. Class Type TLV 1474 The Class Type TLV has the following form: 1475 0 1 2 3 1476 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 1477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1478 |0|0| Class Type TLV | Length | 1479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1480 | Reserved | CT | 1481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1483 Le Faucheur et. al 27 1485 Protocols for Diff-Serv-aware TE June 2002 1487 Reserved : 29 bits 1488 This field is reserved. It must be set to zero on transmission 1489 and must be ignored on receipt. 1491 CT : 3 bits 1492 Indicates the Class-Type. Values currently allowed are 1, 2, ... 1493 , 7. 1495 3. Handling Class Type TLV 1497 To establish an LSP using CR-LDP, an ingress LSR generates a Label 1498 Request message as per [CR-LDP]. This Label Request may optionally 1499 include the Diff-Serv TLV as defined in [DIFF-MPLS] for LDP but 1500 extended to CR-LDP. 1502 If the LSP is associated with Class-Type 0, the ingress LSR MUST NOT 1503 include the Class Type TLV in the Label Request message. 1505 If the LSP is associated with Class-Type N (1 <= N <= 7), the ingress 1506 LSR MUST include the Class Type TLV in the Label Request message with 1507 the Class-Type (CT) field set to N. 1509 If a Label Request message contains multiple Class Type TLVs, only 1510 the first one is meaningful; subsequent Class Type TLV(s) MUST be 1511 ignored and not forwarded. 1513 If the Class Type TLV is not present in the Label Request message, an 1514 LSR MUST associate the Class-Type 0 to the LSP. 1516 A downstream LSR sending a Label Mapping message in response to a 1517 Label Request message MUST NOT include the Class-Type TLV (whether 1518 the Class-Type TLV was included in the Label Request message or not). 1520 During establishment of an LSP corresponding to the Class-Type N, an 1521 LSR MUST perform admission control over the bandwidth available for 1522 that particular Class-Type. 1524 An LSR that recognizes the Class Type TLV and receives a Label 1525 Request message which contains the Class Type TLV but which does not 1526 contain any of the CR-LDP TLVs, MUST reject the label request by 1527 sending upstream a Notification message which includes the Status TLV 1528 with a Status Code of 'Unexpected Class-Type TLV'. This is defined 1529 below in section 4. This error can only occur when an LDP LSP as 1530 opposed to CR-LDP LSP is being established. As was already mentioned, 1531 Class Type TLV extension for Diff-Serv-aware Traffic Engineering is 1532 not applicable to LDP. 1534 An LSR receiving a Label Request message with the Class Type TLV, 1535 which recognizes the Class Type TLV but does not support the 1536 particular Class-Type, MUST reject the label request by sending 1537 upstream a Notification message which includes the Status TLV with a 1539 Le Faucheur et. al 28 1541 Protocols for Diff-Serv-aware TE June 2002 1543 Status Code of 'Unsupported Class-Type'. This is defined below in 1544 section 4. 1546 An LSR receiving a Label Request message with the Class Type TLV, 1547 which recognizes the Class Type TLV but determines that the Class- 1548 Type value is not valid (i.e. Class-Type value 0), MUST reject the 1549 label request by sending upstream a Notification message which 1550 includes the Status TLV with a Status Code of 'Invalid Class-Type 1551 value'. This is defined below in section 4. 1553 An LSR receiving a Label Request message with the Class Type TLV, 1554 which: 1555 - recognizes the Class Type TLV, 1556 - supports the particular Class-Type, but 1557 - determines that the tuple formed by (i) this Class-Type and 1558 (ii) the set-up priority signaled in the same Label Request 1559 message, is not one of the eight TE-classes configured in 1560 the TE-class mapping, 1561 MUST reject the label request by sending upstream a Notification 1562 message which includes the Status TLV with a Status Code of 'CT and 1563 setup priority do not form a configured TE-Class'. This is defined 1564 below in section 4. 1566 An LSR receiving a Label Request message with the Class Type TLV, 1567 which: 1568 - recognizes the Class Type TLV, 1569 - supports the particular Class-Type, but 1570 - determines that the tuple formed by (i) this Class-Type and 1571 (ii) the holding priority signaled in the same Label Request 1572 message, is not one of the eight TE-classes configured in 1573 the TE-class mapping, 1574 MUST reject the label request by sending upstream a Notification 1575 message which includes the Status TLV with a Status Code of 'CT and 1576 holding priority do not form a configured TE-Class'. This is defined 1577 below in section 4. 1579 An LSR receiving a Label Request message with the Class Type TLV and 1580 with the Diff-Serv TLV for an L-LSP, which: 1581 - recognizes the Class Type TLV, 1582 - has local knowledge of the relationship between Class-Types 1583 and PSC (e.g. via configuration) 1584 - based on this local knowledge, determines that the PSC 1585 signaled in the Diff-Serv TLV is inconsistent with the Class- 1586 Type signaled in the Class-Type TLV, 1587 MUST reject the label request by sending upstream a Notification 1588 message which includes the Status TLV with a Status Code of 1589 'Inconsistency between signaled PSC and signaled CT'. This is defined 1590 below in section 4. 1592 An LSR receiving a Label Request message with the Class Type TLV and 1593 with the Diff-Serv TLV for an E-LSP, which: 1594 - recognizes the Class Type TLV, 1596 Le Faucheur et. al 29 1598 Protocols for Diff-Serv-aware TE June 2002 1600 - has local knowledge of the relationship between Class-Types 1601 and PHBs (e.g. via configuration) 1602 - based on this local knowledge, determines that the PHBs 1603 signaled in the MAP entries of the Diff-Serv TLV are 1604 inconsistent with the Class-Type signaled in the Class-Type 1605 TLV, 1606 MUST reject the label request by sending upstream a Notification 1607 message which includes the Status TLV with a Status Code of 1608 'Inconsistency between signaled PHBs and signaled CT'. This is 1609 defined below in section 4. 1611 An LSR MUST handle the situations where the LSP can not be accepted 1612 for other reasons than those already discussed in this section, in 1613 accordance with [CR-LDP], [LDP] and [DIFF-MPLS] (e.g. reservation 1614 rejected by admission control, a label can not be associated). 1616 4. Status Code Values for Diff-Serv-aware TE 1618 In the procedures described above, certain errors must be reported. 1619 The following values are defined for the Status Code field of the 1620 Status TLV: 1622 Status Code E Status Data 1624 Unexpected Class Type TLV 0 TBD 1625 Unsupported Class-Type 0 TBD 1626 Invalid Class-Type value 0 TBD 1627 CT and setup priority do not 0 TBD 1628 form a configured TE-Class 1629 CT and holding priority do not 0 TBD 1630 form a configured TE-Class' 1631 Inconsistency between signaled 0 TBD 1632 PSC and signaled CT 1633 Inconsistency between signaled 0 TBD 1634 PHBs and signaled CT 1636 Appendix C - Example Formulas for Computing "Unreserved TE-Class [i]" 1638 1. Example Formulas Without Local Overbooking 1640 Keeping in mind that details of admission control algorithms as well 1641 as formulas for computing "Unreserved TE-Class [i]" are outside the 1642 scope of this specification, we provide in this section, for 1643 illustration purposes, an example of how values for the unreserved 1644 bandwidth for TE-Class[i] might be computed, assuming: 1645 - the Russian Doll Bandwidth Constraints Model is used 1646 - the basic admission control algorithm which simply deducts 1647 the exact bandwidth of any established LSP from all of the 1648 Bandwidth Constraints relevant to the CT associated with that 1649 LSP. 1651 Le Faucheur et. al 30 1653 Protocols for Diff-Serv-aware TE June 2002 1655 - the optional per-CT Local Overbooking Multipliers are not 1656 used (.i.e. LOM[c]=1, 0<= c <=7). 1658 We assume that: 1659 TE-Class [i] <--> < CTc , preemption p> 1660 in the configured TE-Class mapping. 1662 Let us define "Reserved(CTb,q)" as the sum of the bandwidth reserved 1663 by all established LSPs which belong to CTb and have a holding 1664 priority of q. Note that if q and CTb do not form one of the 8 1665 possible configured TE-Classes, then there can not be any established 1666 LSP which belong to CTb and have a holding priority of q, so in that 1667 case Reserved(CTb,q)=0. 1669 For readability, formulas are first shown assuming only 4 CTs are 1670 active. The formulas below can be extended trivially to cover the 1671 cases where more CTs are used. 1673 If CTc = CT0, then "Unreserved TE-Class [i]" = 1674 [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 3 1676 If CTc = CT1, then "Unreserved TE-Class [i]" = 1677 MIN [ 1678 [ BC1 - SUM ( Reserved(CTb,q) ) ] for q <= p and 1 <= b <= 3, 1679 [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 3 1680 ] 1682 If CTc = CT2, then "Unreserved TE-Class [i]" = 1683 MIN [ 1684 [ BC2 - SUM ( Reserved(CTb,q) ) ] for q <= p and 2 <= b <= 3, 1685 [ BC1 - SUM ( Reserved(CTb,q) ) ] for q <= p and 1 <= b <= 3, 1686 [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 3 1687 ] 1689 If CTc = CT3, then "Unreserved TE-Class [i]" = 1690 MIN [ 1691 [ BC3 - SUM ( Reserved(CTb,q) ) ] for q <= p and 3 <= b <= 3, 1692 [ BC2 - SUM ( Reserved(CTb,q) ) ] for q <= p and 2 <= b <= 3, 1693 [ BC1 - SUM ( Reserved(CTb,q) ) ] for q <= p and 1 <= b <= 3, 1694 [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 3 1695 ] 1697 The formula can be generalized to 8 active CTs and expressed in a 1698 more compact way in the following: 1700 "Unreserved TE-Class [i]" = 1701 MIN [ 1702 [ BCc - SUM ( Reserved(CTb,q) ) ] for q <= p and c <= b <= 7, 1704 Le Faucheur et. al 31 1706 Protocols for Diff-Serv-aware TE June 2002 1708 . . . 1709 [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 7, 1710 ] 1712 where: 1713 TE-Class [i] <--> < CTc , preemption p> 1714 in the configured TE-Class mapping. 1716 2. Example Formulas With Local Overbooking 1718 When the optional local overbooking method is supported, the above 1719 example generalized formula becomes: 1721 "Unreserved TE-Class [i]" = 1722 LOM(c) x MIN [ 1723 [ BCc - SUM ( Normalised(CTb,q) ) ] for q <= p and c <= b <= 7, 1724 . . . 1725 [ BC0 - SUM ( Normalised(CTb,q) ) ] for q <= p and 0 <= b <= 7, 1726 ] 1728 where: 1729 - TE-Class [i] <--> < CTc , preemption p> 1730 in the configured TE-Class mapping. 1731 - Normalised(CTb,q) = Reserved(CTb/q)/LOM(b) 1733 Appendix D - Prediction for Multiple Path Computation 1735 There are situations where a Head-End needs to compute paths for 1736 multiple LSPs. There are potential advantages for the Head-end in 1737 trying to predict the impact of the n-th LSP on the unreserved 1738 bandwidth when computing the path for the (n+1)-th LSP, before 1739 receiving updated IGP information. One example would be to perform 1740 better load-distribution of the multiple LSPs across multiple paths. 1741 Another example would be to avoid CAC rejection when the (n+1)-th LSP 1742 would no longer fit on a link after establishment of the n-th LSP. 1743 While there are also a number of conceivable scenarios where doing 1744 such predictions might result in a worse situation, it is more likely 1745 to improve the situation. As a matter of fact, a number of network 1746 administrators have elected to use such predictions when deploying 1747 existing TE. 1749 Such predictions are local matters, are optional and are outside the 1750 scope of this specification. 1752 Where such predictions are not used, the optional Bandwidth 1753 Constraint sub-TLV and the optional Local Overbooking Multiplier sub- 1754 TLV need not be advertised in IGP since the information contained in 1755 the Unreserved Bw sub-TLV is all that is required by Head-Ends to 1756 perform Constraint Based Routing. 1758 Le Faucheur et. al 32 1760 Protocols for Diff-Serv-aware TE June 2002 1762 Where such predictions are used on Head-Ends, the optional Bandwidth 1763 Constraint sub-TLV (and the optional Local Overbooking Multiplier 1764 sub-TLV if different overbooking ratios need to be supported on 1765 different links) MAY be advertised in IGP. This is in order for the 1766 Head-ends to predict as accurately as possible how an LSP affects 1767 unreserved bandwidth values for subsequent LSPs. 1769 Remembering that actual admission control algorithms are left for 1770 vendor differentiation, we observe that predictions can only be 1771 performed effectively when the Head-end LSR predictions are based on 1772 the same (or a very close) admission control algorithm as used by 1773 other LSRs. 1775 Appendix E - Addressing [DSTE-REQ] Scenarios 1777 This Appendix provides examples of how the DS-TE solution can be used 1778 to support each of the scenario described in [DSTE-REQ]. 1780 1. Scenario 1: Limiting Amount of Voice 1782 By configuring on every link: 1783 - Bandwidth Constraint 1 (for CT1=Voice) = "certain percentage" 1784 of link capacity 1785 - BC0= Max Reservable Link Bandwidth = link capacity 1787 By configuring: 1788 - every CT1/Voice TE-LSP with preemption =0 1789 - every CT0/Data TE-LSP with preemption =1 1791 The proposed solution will address all the requirements: 1792 - amount of Voice traffic limited to desired percentage on 1793 every link 1794 - data traffic capable of using all remaining link capacity 1795 - voice traffic capable of preempting other traffic 1797 2. Scenario 2: Maintain Relative Proportion of Traffic Classes 1799 By configuring on every link: 1800 - BC2 for CT2 = e.g. 45% 1801 - BC1 for CT1+CT2 = e.g. 80% 1802 - BC0 for CT0+CT1+CT2= e.g.100% 1804 The proposed DS-TE solution will ensure that the amount of traffic of 1805 each Class Type established on a link is within acceptable levels as 1806 compared to the resources allocated to the corresponding Diff-Serv 1807 PHBs regardless of which order the LSPs are routed in, regardless of 1808 which preemption priorities are used by which LSPs and regardless of 1809 failure situations. Optional automatic adjustment of Diff-Sev 1810 scheduling configuration could be used for maintaining very strict 1811 relationship between amount of established traffic of each Class Type 1812 and corresponding Diff-Serv resources. 1814 Le Faucheur et. al 33 1816 Protocols for Diff-Serv-aware TE June 2002 1818 3. Scenario 3: Guaranteed Bandwidth Services 1820 By configuring on every link: 1821 - BC1 for CT1 = "given" percentage of bandwidth (appropriate to 1822 achieve the Guaranteed Bandwidth service's QoS objectives) 1823 - BC0 for CT0+CT1 = 100% 1825 The proposed DS-TE solution will ensure that the amount of Guaranteed 1826 Bandwidth Trafic established on every link remains below the given 1827 percentage so that it will always meet its QoS objectives. AT the 1828 same time it will allow traffic engineering of the rest of the 1829 traffic such that links can be filled up. 1831 Appendix F - Solution Evaluation 1833 1. Satisfying Detailed Requirements 1835 This DS-TE Solution address all the scenarios presented in [DSTE-REQ] 1836 as explained in Appendix E. It also satisfy all the detailed 1837 requirements presented in [DSTE-REQ]. 1839 2. Flexibility 1841 This DS-TE solution supports 8 CTs. It is entirely flexible as to how 1842 Traffic Trunks are grouped together into a CT. 1844 3. Extendibility 1846 A maximum of 8 CTs is considered by the authors of this document as 1847 more than comfortable. However, this solution could be extended to 1848 support more CTs if deemed necessary in the future. However, this 1849 would necessitate additional IGP extensions beyond those specified in 1850 this document. 1852 4. Scalability 1854 This DS-TE solution is expected to have a very small scalability 1855 impact compared to existing TE. 1857 From an IGP viewpoint, the amount of mandatory information to be 1858 advertised is identical to existing TE. Two additional sub-TLVs have 1859 been specified, but their use is optional and those contained a 1860 limited amount of static information (at most 8 Bandwidth Constraints 1861 and 8 LOMs). 1863 We expect no noticeable impact on LSP Path computation since, as with 1864 existing TE, this solution only require CSPF to consider a single 1865 unreserved bandwidth value for any given LSP. 1867 Le Faucheur et. al 34 1869 Protocols for Diff-Serv-aware TE June 2002 1871 From a signaling viewpoint we expect no significant impact due to 1872 this solution since it only requires processing of one additional 1873 information (the Class-Type) and does not significantly increase the 1874 likelihood of CAC rejection. Note that DS-TE has some inherent impact 1875 on LSP signaling in the sense that it assumes that different classes 1876 of traffic are split over different LSPs so that more LSPs need to be 1877 signaled; but this is due to the DS-TE concept itself and not to the 1878 actual DS-TE solution discussed here. 1880 5. Backward Compatibility/Migration 1882 This solution is expected to allow smooth migration from existing TE 1883 to DS-TE. This is because existing TE can be supported exactly as 1884 today as a particular configuration of DS-TE. This means that an 1885 "upgraded" LSR with a DS-TE implementation can directly interwork 1886 with an "old" LSR supporting existing TE only. 1888 This solution is expected to allow smooth migration when increasing 1889 the number of CTs actually deployed since it only requires 1890 configuration changes. however, these changes must be performed in a 1891 coordinated manner across the DS-TE domain. 1893 Appendix G - Interoperability with non DS-TE capable LSRs 1895 This DSTE solution allows operations in a hybrid network where some 1896 LSRs are DS-TE capable while some LSRs and not DS-TE capable, which 1897 may occur during migration phases. This Appendix discusses the 1898 constraints and operations in such hybrid networks. 1900 We refer to the set of DS-TE capable LSRs as the DS-TE domain. We 1901 refer to the set of non DS-TE capable (but TE capable) LSRs as the 1902 TE-domain. 1904 Hybrid operations requires that the TE-class mapping in the DS-TE 1905 domain is configured so that: 1906 - a TE-class exist for CT0 for every preemption priority 1907 actually used in the TE domain 1908 - the index in the TE-class mapping for each of these TE- 1909 classes is equal to the preemption priority. 1911 For example, imagine the TE domain uses preemption 2 and 3. Then, DS- 1912 TE can be deployed in the same network by including the following TE- 1913 classes in the TE-class mapping: 1914 i <---> CT preemption 1915 ==================================== 1916 2 CT0 2 1917 3 CT0 3 1919 Another way to look at this is to say that, the whole TE-class 1920 mapping does not have to be consistent with the TE domain, but the 1922 Le Faucheur et. al 35 1924 Protocols for Diff-Serv-aware TE June 2002 1926 subset of this TE-Class mapping applicable to CT0 must effectively be 1927 consistent with the TE domain. 1929 In such hybrid networks : 1930 - CT0 LSPs can be established by both DS-TE capable LSRs and 1931 non-DSTE capable LSRs 1932 - CT0 LSPs can transit via (or terminate at) both DS-TE capable 1933 LSRs and non-DSTE capable LSRs 1934 - LSPs from other CTs can only be established by DS-TE capable 1935 LSRs 1936 - LSPs from other CTs can only transit via (or terminate at) 1937 DS-TE capable LSRs 1939 Note that, for such hybrid operation, non DS-TE capable LSRs need to 1940 be able to accept Unreserved Bw sub-TLVs containing non decreasing 1941 bandwidth values (ie with Unreserved [p] < Unreserved [q] with p CT preemption 1959 ==================================== 1960 0 CT1 0 1961 1 CT1 1 1962 2 CT0 2 1963 3 CT0 3 1964 rest unused 1966 LSR0 is configured with a Max Reservable bandwidth=m for Link01. 1967 LSR1 is configured with a BC0=x0 and a BC1=x1(possibly=0) for Link01. 1969 LSR0 will advertise in IGP for Link01: 1970 - Max Reservable Bw sub-TLV = 1971 - Unreserved Bw sub-TLV = 1972 1974 On receipt of such advertisement, LSR1 will: 1975 - understand that LSR0 is not DS-TE capable because it 1976 advertised a Max Reservable Bw sub-TLV and no Bandwidth 1977 Constraint sub-TLV 1979 Le Faucheur et. al 36 1981 Protocols for Diff-Serv-aware TE June 2002 1983 - conclude that only CT0 LSPs can transit via LSR0 and that 1984 only the values CT0/2 and CT0/3 are meaningful in the 1985 Unreserved Bw sub-TLV. LSR1 may effectively behave as if the 1986 six other values contained in the Unreserved Bw sub-TLV were 1987 set to zero. 1989 LSR1 will advertise in IGP for Link01: 1990 - Max Reservable Bw sub-TLV = 1991 - Bandwidth Constraint sub-TLV = 1992 - Unreserved Bw sub-TLV = 1994 On receipt of such advertisement, LSR0 will: 1995 - Ignore the Bandwidth Constraint sub-TLV (unrecognized) 1996 - Correctly process CT0/2 and CT0/3 in the Unreserved Bw sub- 1997 TLV and use these values for CTO LSP establishment 1998 - Incorrectly believe that the other values contained in the 1999 Unreserved Bw sub-TLV relates to other preemption priorities 2000 for CT0, but will actually never use those since we assume 2001 that only preemption 2 and 3 are used in the TE domain. 2003 Le Faucheur et. al 37