idnits 2.17.1 draft-ietf-tewg-diff-te-proto-06.txt: -(92): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(171): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(188): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(218): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(258): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(259): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(262): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(509): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(512): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(518): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(600): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(640): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(642): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(644): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(650): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(730): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(801): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(825): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(837): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(898): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(903): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(997): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1048): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1156): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1180): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1192): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1203): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1207): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1214): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1485): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1486): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1549): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1550): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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. == There are 112 instances of lines with non-ascii characters in the document. == 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 1753 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** There are 24 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([ISIS-TE]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 614 -- Looks like a reference, but probably isn't: '1' on line 449 -- Looks like a reference, but probably isn't: '2' on line 450 -- Looks like a reference, but probably isn't: '3' on line 451 -- Looks like a reference, but probably isn't: '7' on line 615 == Missing Reference: 'N' is mentioned on line 964, but not defined ** Downref: Normative reference to an Informational RFC: RFC 3564 (ref. 'DSTE-REQ') ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. 'DIFF-ARCH') ** Downref: Normative reference to an Informational RFC: RFC 2702 (ref. 'TE-REQ') ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'ISIS-TE') ** Obsolete normative reference: RFC 2434 (ref. 'IANA-CONS') (Obsoleted by RFC 5226) == Outdated reference: A later version (-07) exists of draft-ietf-tewg-diff-te-russian-04 == Outdated reference: A later version (-04) exists of draft-ietf-tewg-diff-te-mam-02 == Outdated reference: A later version (-06) exists of draft-ietf-tewg-diff-te-mar-03 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-bundle-04 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-rsvp-lsp-fastreroute-03 Summary: 11 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Francois Le Faucheur, Editor 3 Cisco Systems, Inc. 5 IETF Internet Draft 6 Expires: March, 2004 7 Document: draft-ietf-tewg-diff-te-proto-06.txt January, 2004 9 Protocol extensions for support of 10 Differentiated-Service-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 Copyright Notice 32 Copyright (C) The Internet Society (2004). All Rights Reserved. 34 Abstract 36 This document specifies the protocol extensions for support of 37 Differentiated-Service-aware MPLS Traffic Engineering (DS-TE). This 38 includes generalization of the semantic of a number of IGP extensions 39 already defined for existing MPLS Traffic Engineering in RFC3630 and 40 RFC-TBD as well as additional IGP extensions beyond those. This also 41 includes extensions to RSVP-TE signaling beyond those already 42 specified in RFC3209 for existing MPLS Traffic Engineering. These 43 extensions address the Requirements for DS-TE spelt out in RFC3564. 45 To be removed by the RFC editor at the time of 46 publication: 47 Please replace �TBD� above by the actual RFC number when 48 an RFC number is allocated to [ISIS-TE] 50 Le Faucheur, et. al 1 52 Protocols for Diff-Serv-aware TE January 2004 54 56 Table of Contents 58 To be removed by the RFC editor at the time of 59 publication: 60 Could you please insert the Table of Content (or otherwise 61 remove this section)? 62 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 Differentiated-Service (Diff-Serv)-aware MPLS Traffic Engineering 74 (DS-TE). This includes the fundamental requirement to be able to 75 enforce different bandwidth constraints for different classes of 76 traffic. 78 This document specifies the IGP and RSVP-TE signaling extensions 79 (beyond those already specified for existing MPLS Traffic Engineering 80 [OSPF-TE][ISIS-TE][RSVP-TE]) for support of the DS-TE requirements 81 spelt out in [DSTE-REQ] including environments relying on distributed 82 Constraint Based Routing (e.g. path computation involving Head-end 83 LSRs). 85 [DSTE-REQ] provides a definition and examples of Bandwidth 86 Constraints Models. The present document does not specify nor assume 87 a particular Bandwidth Constraints model. Specific Bandwidth 88 Constraints model are outside the scope of this document. While the 89 extensions for DS-TE specified in this document may not be sufficient 90 to support all the conceivable Bandwidth Constraints models, they do 91 support the �Russian Dolls� Model specified in [DSTE-RDM], the 92 �Maximum Allocation� Model specified in [DSTE-MAM] and the �Maximum 93 Allocation with Reservation� Model specified in [DSTE-MAR]. 95 2. Contributing Authors 97 This document was the collective work of several. The text and 98 content of this document was contributed by the editor and the co- 99 authors listed below. (The contact information for the editor appears 100 in Section 18, and is not repeated below.) 102 Le Faucheur et. al 2 104 Protocols for Diff-Serv-aware TE January 2004 106 Jim Boyle Kireeti Kompella 107 Protocol Driven Networks, Inc. Juniper Networks, Inc. 108 1381 Kildaire Farm Road #288 1194 N. Mathilda Ave. 109 Cary, NC 27511, USA Sunnyvale, CA 94099 110 Phone: (919) 852-5160 Email: kireeti@juniper.net 111 Email: jboyle@pdnets.com 113 William Townsend Thomas D. Nadeau 114 Tenor Networks Cisco Systems, Inc. 115 100 Nagog Park 250 Apollo Drive 116 Acton, MA 01720 Chelmsford, MA 01824 117 Phone: +1-978-264-4900 Phone: +1-978-244-3051 118 Email: Email: tnadeau@cisco.com 119 btownsend@tenornetworks.com 121 Darek Skalecki 122 Nortel Networks 123 3500 Carling Ave, 124 Nepean K2H 8E9 125 Phone: +1-613-765-2252 126 Email: dareks@nortelnetworks.com 128 3. Definitions 130 For readability a number of definitions from [DSTE-REQ] are repeated 131 here: 133 Traffic Trunk: an aggregation of traffic flows of the same class 134 [i.e. which are to be treated equivalently from the DS-TE 135 perspective] which are placed inside a Label Switched Path. 137 Class-Type (CT): the set of Traffic Trunks crossing a link that is 138 governed by a specific set of Bandwidth constraints. CT is used for 139 the purposes of link bandwidth allocation, constraint based routing 140 and admission control. A given Traffic Trunk belongs to the same CT 141 on all links. 143 TE-Class: A pair of: 144 i. a Class-Type 145 ii. a preemption priority allowed for that Class-Type. This 146 means that an LSP transporting a Traffic Trunk from 147 that Class-Type can use that preemption priority as the 148 set-up priority, as the holding priority or both. 150 Definitions for a number of MPLS terms are not repeated here. Those 151 can be found in [MPLS-ARCH]. 153 4. Configurable Parameters 155 Le Faucheur et. al 3 157 Protocols for Diff-Serv-aware TE January 2004 159 This section only discusses the differences with the configurable 160 parameters supported for MPLS Traffic Engineering as per [TE-REQ], 161 [ISIS-TE], [OSPF-TE], and [RSVP-TE]. All other parameters are 162 unchanged. 164 4.1. Link Parameters 166 4.1.1. Bandwidth Constraints (BCs) 168 [DSTE-REQ] states that �Regardless of the Bandwidth Constraints 169 Model, the DS-TE solution MUST allow support for up to 8 BCs.� 171 For DS-TE, the existing �Maximum Reservable link bandwidth� parameter 172 is retained but its semantic is generalized and interpreted as the 173 aggregate bandwidth constraints across all Class-Types, so that, 174 independently of the Bandwidth Constraints Model in use: 175 SUM (Reserved (CTc)) <= Max Reservable Bandwidth, 176 where the SUM is across all values of "c" in the range 0 <= c <= 7. 178 Additionally, on every link, a DS-TE implementation MUST provide for 179 configuration of up to 8 additional link parameters which are the 180 eight potential Bandwidth Constraints i.e. BC0, BC1 , ... BC7. The 181 LSR MUST interpret these Bandwidth Constraints in accordance with the 182 supported Bandwidth Constraints Model (i.e. what bandwidth constraint 183 applies to what Class-Type and how). 185 Where the Bandwidth Constraints Model imposes some relationship among 186 the values to be configured for these Bandwidth Constraints, the LSR 187 MUST enforce those at configuration time. For example, when the 188 �Russian Doll� Bandwidth Constraints Model ([DSTE-RDM]) is used, the 189 LSR must ensure that BCi is configured smaller or equal to BCj, where 190 i is greater than j, and ensure that BC0 is equal to the Maximum 191 Reservable Bandwidth. As another example, when the Maximum Allocation 192 Model ([DSTE-MAM]) is used, the LSR must ensure that all BCi are 193 configured smaller or equal to the Maximum Reservable Bandwidth. 195 4.1.2. Overbooking 197 DS-TE enables a network administrator to apply different overbooking 198 (or underbooking) ratios for different CTs. 200 The principal methods to achieve this are the same as historically 201 used in existing TE deployment, which are : 202 (i) To take into account the overbooking/underbooking ratio 203 appropriate for the OA/CT associated with the considered LSP 204 at the time of establishing the bandwidth size of a given 205 LSP. We refer to this method as the �LSP Size Overbooking 206 method�. AND/OR 207 (ii) To take into account the overbooking/underbooking ratio at 208 the time of configuring the Maximum Reservable 209 Bandwidth/Bandwidth Constraints and use values which are 210 larger(overbooking) or smaller(underbooking) than actually 212 Le Faucheur et. al 4 213 Protocols for Diff-Serv-aware TE January 2004 215 supported by the link. We refer to this method as the �Link 216 Size Overbooking method�. 218 The �LSP Size Overbooking� method and the �Link Size Overbooking� 219 method are expected to be sufficient in many DS-TE environments and 220 require no additional configurable parameters. Other overbooking 221 methods may involve such additional configurable parameters but are 222 beyond the scope of this document. 224 4.2. LSR Parameters 226 4.2.1. TE-Class Mapping 228 In line with [DSTE-REQ], the preemption attributes defined in [TE- 229 REQ] are retained with DS-TE and applicable within, and across, all 230 Class Types. The preemption attributes of setup priority and holding 231 priority retain existing semantics, and in particular these semantics 232 are not affected by the LSP Class Type. This means that if LSP1 233 contends with LSP2 for resources, LSP1 may preempt LSP2 if LSP1 has a 234 higher set-up preemption priority (i.e. lower numerical priority 235 value) than LSP2 holding preemption priority regardless of LSP1 CT 236 and LSP2 CT. 238 DS-TE LSRs MUST allow configuration of a TE-Class mapping whereby the 239 Class-Type and preemption level are configured for each of (up to) 8 240 TE-Classes. 242 This mapping is referred to as : 244 TE-Class[i] <--> < CTc , preemption p > 246 Where 0 <= i <= 7, 0 <= c <= 7, 0 <= p <= 7 248 Two TE-Classes must not be identical (i.e. have both the same Class- 249 Type and the same preemption priority). 251 There are no other restrictions on how any of the 8 Class-Types can 252 be paired up with any of the 8 preemption priorities to form a TE- 253 class. In particular, one given preemption priority can be paired up 254 with two (or more) different Class-Types to form two (or more) TE- 255 classes. Similarly, one Class-Type can be paired up with two (or 256 more) different preemption priorities to form two (or more) TE- 257 Classes. Also, there is no mandatory ordering relationship between 258 the TE-Class index (i.e. �i� above) and the Class-Type (i.e. �c� 259 above) or the preemption priority (i.e. �p� above) of the TE-Class. 261 Where the network administrator uses less than 8 TE-Classes, the DS- 262 TE LSR MUST allow remaining ones to be configured as �Unused�. Note 263 that "Configuring all the 8 TE-Classes as "Unused" effectively 264 results in disabling TE/DS-TE since no TE/DS-TE LSP can be 265 established (nor even configured, since as described in section 4.3.3 267 Le Faucheur et. al 5 269 Protocols for Diff-Serv-aware TE January 2004 271 below, the CT and preemption priorities configured for an LSP must 272 form one of the configured TE-Classes)". 274 To ensure coherent DS-TE operation, the network administrator MUST 275 configure exactly the same TE-Class Mapping on all LSRs of the DS-TE 276 domain. 278 When the TE-class mapping needs to be modified in the DS-TE domain, 279 care must be exercised during the transient period of reconfiguration 280 during which some DS-TE LSRs may be configured with the new TE-class 281 mapping while others are still configured with the old TE-class 282 mapping. It is recommended that active tunnels do not use any of the 283 TE-classes which are being modified during such a transient 284 reconfiguration period. 286 4.3. LSP Parameters 288 4.3.1. Class-Type 290 With DS-TE, LSRs MUST support, for every LSP, an additional 291 configurable parameter which indicates the Class-Type of the Traffic 292 Trunk transported by the LSP. 294 There is one and only one Class-Type configured per LSP. 296 The configured Class-Type indicates, in accordance with the supported 297 Bandwidth Constraints Model, the Bandwidth Constraints that MUST be 298 enforced for that LSP. 300 4.3.2. Setup and Holding Preemption Priorities 302 As per existing TE, DS-TE LSRs MUST allow every DS-TE LSP to be 303 configured with a setup and holding priority, each with a value 304 between 0 and 7. 306 4.3.3. Class-Type/Preemption Relationship 308 With DS-TE, the preemption priority configured for the setup priority 309 of a given LSP and the Class-Type configured for that LSP must be 310 such that, together, they form one of the (up to) 8 TE-Classes 311 configured in the TE-Class Mapping specified in section 4.2.1 above. 313 The preemption priority configured for the holding priority of a 314 given LSP and the Class-Type configured for that LSP must also be 315 such that, together, they form one of the (up to) 8 TE-Classes 316 configured in the TE-Class Mapping specified in section 4.2.1 above. 318 The LSR MUST enforce these two rules at configuration time. 320 4.4. Examples of Parameters Configuration 322 Protocols for Diff-Serv-aware TE January 2004 324 For illustrative purposes, we now present a few examples of how these 325 configurable parameters may be used. All these examples assume that 326 different bandwidth constraints need to be enforced for different 327 sets of Traffic Trunks (e.g. for Voice and for Data) so that two, or 328 more, Class-Types need to be used. 330 4.4.1. Example 1 332 The Network Administrator of a first network using two Class Types 333 (CT1 for Voice and CT0 for Data), may elect to configure the 334 following TE-Class Mapping to ensure that Voice LSPs are never driven 335 away from their shortest path because of Data LSPs: 337 TE-Class[0] <--> < CT1 , preemption 0 > 338 TE-Class[1] <--> < CT0 , preemption 1 > 339 TE-Class[i] <--> unused, for 2 <= i <= 7 341 Voice LSPs would then be configured with: 342 - CT=CT1, set-up priority =0, holding priority=0 344 Data LSPs would then be configured with: 345 - CT=CT0, set-up priority =1, holding priority=1 347 A new Voice LSP would then be able to preempt an existing Data LSP in 348 case they contend for resources. A Data LSP would never preempt a 349 Voice LSP. A Voice LSP would never preempt another Voice LSP. A Data 350 LSP would never preempt another Data LSP. 352 4.4.2. Example 2 354 The Network Administrator of another network may elect to configure 355 the following TE-Class Mapping in order to optimize global network 356 resource utilization by favoring placement of large LSPs closer to 357 their shortest path: 359 TE-Class[0] <--> < CT1 , preemption 0 > 360 TE-Class[1] <--> < CT0 , preemption 1 > 361 TE-Class[2] <--> < CT1 , preemption 2 > 362 TE-Class[3] <--> < CT0 , preemption 3 > 363 TE-Class[i] <--> unused, for 4 <= i <= 7 365 Large size Voice LSPs could be configured with: 366 - CT=CT1, set-up priority =0, holding priority=0 368 Large size Data LSPs could be configured with: 369 - CT=CT0, set-up priority = 1, holding priority=1 371 Small size Voice LSPs could be configured with: 372 - CT=CT1, set-up priority = 2, holding priority=2 373 Small size Data LSPs could be configured with: 374 - CT=CT0, set-up priority = 3, holding priority=3. 376 Le Faucheur et. al 7 378 Protocols for Diff-Serv-aware TE January 2004 380 A new large size Voice LSP would then be able to preempt a small size 381 Voice LSP or any Data LSP in case they contend for resources. 382 A new large size Data LSP would then be able to preempt a small size 383 Data LSP or a small size Voice LSP in case they contend for 384 resources, but it would not be able to preempt a large size Voice 385 LSP. 387 4.4.3. Example 3 389 The Network Administrator of another network may elect to configure 390 the following TE-Class Mapping in order to ensure that Voice LSPs are 391 never driven away from their shortest path because of Data LSPs while 392 also achieving some optimization of global network resource 393 utilization by favoring placement of large LSPs closer to their 394 shortest path: 396 TE-Class[0] <--> < CT1 , preemption 0 > 397 TE-Class[1] <--> < CT1 , preemption 1 > 398 TE-Class[2] <--> < CT0 , preemption 2 > 399 TE-Class[3] <--> < CT0 , preemption 3 > 400 TE-Class[i] <--> unused, for 4 <= i <= 7 402 Large size Voice LSPs could be configured with: 403 - CT=CT1, set-up priority = 0, holding priority=0. 405 Small size Voice LSPs could be configured with: 406 - CT=CT1, set-up priority = 1, holding priority=1. 408 Large size Data LSPs could be configured with: 409 - CT=CT0, set-up priority = 2, holding priority=2. 411 Small size Data LSPs could be configured with: 412 - CT=CT0, set-up priority = 3, holding priority=3. 414 A Voice LSP could preempt a Data LSP if they contend for resources. A 415 Data LSP would never preempt a Voice LSP. A Large size Voice LSP 416 could preempt a small size Voice LSP if they contend for resources. A 417 Large size Data LSP could preempt a small size Data LSP if they 418 contend for resources. 420 4.4.4. Example 4 422 The Network Administrator of another network may elect to configure 423 the following TE-Class Mapping in order to ensure that no preemption 424 occurs in the DS-TE domain: 426 TE-Class[0] <--> < CT1 , preemption 0 > 427 TE-Class[1] <--> < CT0 , preemption 0 > 428 TE-Class[i] <--> unused, for 2 <= i <= 7 429 Voice LSPs would then be configured with: 431 Le Faucheur et. al 8 433 Protocols for Diff-Serv-aware TE January 2004 435 - CT=CT1, set-up priority =0, holding priority=0 437 Data LSPs would then be configured with: 438 - CT=CT0, set-up priority =0, holding priority=0 440 No LSP would then be able to preempt any other LSP. 442 4.4.5. Example 5 444 The Network Administrator of another network may elect to configure 445 the following TE-Class Mapping in view of increased network stability 446 through a more limited use of preemption: 448 TE-Class[0] <--> < CT1 , preemption 0 > 449 TE-Class[1] <--> < CT1 , preemption 1 > 450 TE-Class[2] <--> < CT0 , preemption 1 > 451 TE-Class[3] <--> < CT0 , preemption 2 > 452 TE-Class[i] <--> unused, for 4 <= i <= 7 454 Large size Voice LSPs could be configured with: 455 - CT=CT1, set-up priority = 0, holding priority=0. 457 Small size Voice LSPs could be configured with: 458 - CT=CT1, set-up priority = 1, holding priority=0. 460 Large size Data LSPs could be configured with: 461 - CT=CT0, set-up priority = 2, holding priority=1. 463 Small size Data LSPs could be configured with: 464 - CT=CT0, set-up priority = 2, holding priority=2. 466 A new large size Voice LSP would be able to preempt a Data LSP in 467 case they contend for resources, but it would not be able to preempt 468 any Voice LSP even a small size Voice LSP. 470 A new small size Voice LSP would be able to preempt a small size Data 471 LSP in case they contend for resources, but it would not be able to 472 preempt a large size Data LSP or any Voice LSP. 474 A Data LSP would not be able to preempt any other LSP. 476 5. IGP Extensions for DS-TE 478 This section only discusses the differences with the IGP 479 advertisement supported for (aggregate) MPLS Traffic Engineering as 480 per [OSPF-TE] and [ISIS-TE]. The rest of the IGP advertisement is 481 unchanged. 483 5.1. Bandwidth Constraints 485 Le Faucheur et. al 9 487 Protocols for Diff-Serv-aware TE January 2004 489 As detailed above in section 4.1.1, up to 8 Bandwidth Constraints 490 ( BCb, 0 <= b <= 7) are configurable on any given link. 492 With DS-TE, the existing �Maximum Reservable Bandwidth� sub-TLV 493 ([OSPF-TE], [ISIS-TE]) is retained with a generalized semantic so 494 that it MUST now be interpreted as the aggregate bandwidth constraint 495 across all Class-Types [ i.e. 496 SUM (Reserved (CTc)) <= Max Reservable Bandwidth], independently of 497 the Bandwidth Constraints Model. 499 This document also defines the following new optional sub-TLV to 500 advertise the eight potential Bandwidth Constraints (BC0 to BC7): 502 �Bandwidth Constraints� sub-TLV: 503 - Bandwidth Constraints Model Id (1 octet) 504 - Reserved (3 octets) 505 - Bandwidth Constraints (Nx4 octets) 507 Where: 509 - With OSPF, the sub-TLV is a sub-TLV of the �Link TLV� and its 510 sub-TLV type is TBD 512 - With ISIS, the sub-TLV is a sub-TLV of the �extended IS 513 reachability TLV� and its sub-TLV type is TBD (). 515 To be removed by the RFC editor at the time of 516 publication: 517 When the sub-TLV numbers are allocated by IANA for OSPF and 518 ISIS, replace �TBD� in the two bullet points above by the respective 519 assigned value. See IANA Considerations section for allocation 520 request. 521 523 - Bandwidth Constraints Model Id: 1 octet identifier for the 524 Bandwidth Constraints Model currently in use by the LSR 525 initiating the IGP advertisement. See the IANA Considerations 526 section below for assignment of values in this name space. 528 - Reserved: a 3-octet field. This field should be set to zero 529 by the LSR generating the sub-TLV and should be ignored by 530 the LSR receiving the sub-TLV. 532 - Bandwidth Constraints: contains BC0, BC1,... BC(N-1). 533 Each Bandwidth Constraint is encoded on 32 bits in IEEE 534 floating point format. The units are bytes (not bits!) per 535 second. Where the configured TE-class mapping and the 536 Bandwidth Constraints model in use are such that BCh+1, 537 BCh+2, ...and BC7 are not relevant to any of the Class-Types 538 associated with a configured TE-class, it is RECOMMENDED that 539 only the Bandwidth Constraints from BC0 to BCh be advertised, 541 Le Faucheur et. al 10 543 Protocols for Diff-Serv-aware TE January 2004 545 All relevant generic TLV encoding rules (including TLV format, 546 padding and alignment, as well as IEEE floating point format 547 encoding) defined in [OSPF-TE] and [ISIS-TE] are applicable to this 548 new sub-TLV. 550 The �Bandwidth Constraints� sub-TLV format is illustrated below: 552 0 1 2 3 553 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 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | BC Model Id | Reserved | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | BC0 value | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 // . . . // 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | BCh value | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 A DS-TE LSR MAY optionally advertise Bandwidth Constraints. 566 A DS-TE LSR which does advertise Bandwidth Constraints MUST use the 567 new �Bandwidth Constraints� sub-TLV (in addition to the existing 568 Maximum Reservable Bandwidth sub-TLV) to do so. For example, 569 considering the case where a Service Provider deploys DS-TE with 570 TE-classes associated with CT0 and CT1 only, and where the Bandwidth 571 Constraints Model is such that only BC0 and BC1 are relevant to CT0 572 and CT1: a DS-TE LSR which does advertise Bandwidth Constraints would 573 include in the IGP advertisement the Maximum Reservable Bandwidth 574 sub-TLV as well as the �Bandwidth Constraints� sub-TLV, where the 575 former should contain the aggregate bandwidth constraint across all 576 CTs and the latter would contain BC0 and BC1. 578 A DS-TE LSR receiving the �Bandwidth Constraints� sub-TLV with a 579 Bandwidth Constraints Model Id which does not match the Bandwidth 580 Constraints Model it currently uses, SHOULD generate a warning to the 581 operator/management-system reporting the inconsistency between 582 Bandwidth Constraints Models used on different links. Also, in that 583 case, if the DS-TE LSR does not support the Bandwidth Constraints 584 Model designated by the Bandwidth Constraints Model Id, or if the DS- 585 TE LSR does not support operations with multiple simultaneous 586 Bandwidth Constraints Models, the DS-TE LSR MAY discard the 587 corresponding TLV. If the DS-TE LSR does support the Bandwidth 588 Constraints Model designated by the Bandwidth Constraints Model Id 589 and if the DS-TE LSR does support operations with multiple 590 simultaneous Bandwidth Constraints Models, the DS-TE LSR MAY accept 591 the corresponding TLV and allow operations with different Bandwidth 592 Constraints Models used in different parts of the DS-TE domain. 594 5.2. Unreserved Bandwidth 596 Le Faucheur et. al 11 598 Protocols for Diff-Serv-aware TE January 2004 600 With DS-TE, the existing �Unreserved Bandwidth� sub-TLV is retained 601 as the only vehicle to advertise dynamic bandwidth information 602 necessary for Constraint Based Routing on Head-ends, except that it 603 is used with a generalized semantic. The Unreserved Bandwidth sub-TLV 604 still carries eight bandwidth values but they now correspond to the 605 unreserved bandwidth for each of the TE-Class (instead of for each 606 preemption priority as per existing TE). 608 More precisely, a DS-TE LSR MUST support the Unreserved Bandwidth 609 sub-TLV with a definition which is generalized into the following: 611 The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth 612 not yet reserved for each of the eight TE-classes, in IEEE floating 613 point format arranged in increasing order of TE-Class index, with 614 unreserved bandwidth for TE-Class [0] occurring at the start of the 615 sub-TLV, and unreserved bandwidth for TE-Class [7] at the end of the 616 sub-TLV. The unreserved bandwidth value for TE-Class [i] ( 0 <= i <= 617 7) is referred to as �Unreserved TE-Class [i]�. It indicates the 618 bandwidth that is available, for reservation, to an LSP which : 619 - transports a Traffic Trunk from the Class-Type of TE- 620 Class[i], and 621 - has a setup priority corresponding to the preemption priority 622 of TE-Class[i]. 624 The units are bytes per second. 626 Since the bandwidth values are now ordered by TE-class index and thus 627 can relate to different CTs with different bandwidth constraints and 628 can relate to any arbitrary preemption priority, a DS-TE LSR MUST NOT 629 assume any ordered relationship among these bandwidth values. 631 With existing TE, since all preemption priorities reflect the same 632 (and only) bandwidth constraints and since bandwidth values are 633 advertised in preemption priority order, the following relationship 634 is always true, and is often assumed by TE implementations: 636 If i < j , then �Unreserved Bw [i]� >= �Unreserved Bw [j]� 638 With DS-TE, no relationship is to be assumed so that: 639 If i < j , then any of the following relationship may be true 640 �Unreserved TE-Class [i]� = �Unreserved TE-Class [j]� 641 OR 642 �Unreserved TE-Class [i]� > �Unreserved TE-Class [j]� 643 OR 644 �Unreserved TE-Class [i]� < �Unreserved TE-Class [j]�. 646 Rules for computing �Unreserved TE-Class [i]� are specified in 647 section 11. 649 If TE-Class[i] is unused, the value advertised by the IGP in 650 �Unreserved TE-Class [i]� MUST be set to zero by the LSR generating 652 Le Faucheur et. al 12 653 Protocols for Diff-Serv-aware TE January 2004 655 the IGP advertisement, and MUST be ignored by the LSR receiving the 656 IGP advertisement. 658 6. RSVP-TE Extensions for DS-TE 660 In this section we describe extensions to RSVP-TE for support of 661 Diff-Serv-aware MPLS Traffic Engineering. These extensions are in 662 addition to the extensions to RSVP defined in [RSVP-TE] for support 663 of (aggregate) MPLS Traffic Engineering and to the extensions to RSVP 664 defined in [DIFF-MPLS] for support of Diff-Serv over MPLS. 666 6.1. DS-TE related RSVP Messages Format 668 One new RSVP Object is defined in this document: the CLASSTYPE 669 Object. Detailed description of this Object is provided below. This 670 new Object is applicable to Path messages. This specification only 671 defines the use of the CLASSTYPE Object in Path messages used to 672 establish LSP Tunnels in accordance with [RSVP-TE] and thus 673 containing a Session Object with a C-Type equal to LSP_TUNNEL_IPv4 674 and containing a LABEL_REQUEST object. 676 Restrictions defined in [RSVP-TE] for support of establishment of LSP 677 Tunnels via RSVP-TE are also applicable to the establishment of LSP 678 Tunnels supporting DS-TE. For instance, only unicast LSPs are 679 supported and Multicast LSPs are for further study. 681 This new CLASSTYPE object is optional with respect to RSVP so that 682 general RSVP implementations not concerned with MPLS LSP set up do 683 not have to support this object. 685 An LSR supporting DS-TE MUST support the CLASSTYPE Object. 687 6.1.1. Path Message Format 689 The format of the Path message is as follows: 691 ::= [ ] 692 693 694 [ ] 695 696 [ ] 697 [ ] 698 [ ] 699 [ ... ] 700 [ ] 702 ::= [ ] 703 [ ] 704 [ ] 706 Le Faucheur et. al 13 708 Protocols for Diff-Serv-aware TE January 2004 710 6.2. CLASSTYPE Object 712 The CLASSTYPE object Class Name is CLASSTYPE. Its Class Number is 713 TBD. Currently, there is only one defined C_Type which is C_Type 1. 714 The CLASSTYPE object format is shown below. 716 To be removed by the RFC editor at the time of 717 publication: 718 When the RSVP Class-Num is assigned by IANA replace �TBD� 719 above by the assigned value. See IANA Considerations section 720 for allocation request. 721 723 6.2.1. CLASSTYPE object 725 Class Number = TBD 726 Class Type = 1 728 To be removed by the RFC editor at the time of 729 publication: 730 When the RSVP Class Number is assigned by IANA replace �TBD� 731 above by the assigned value. See IANA Considerations section 732 for allocation request. 733 735 0 1 2 3 736 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 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Reserved | CT | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 Reserved : 29 bits 742 This field is reserved. It must be set to zero on transmission 743 and must be ignored on receipt. 745 CT : 3 bits 746 Indicates the Class-Type. Values currently allowed are 747 1, 2, ... , 7. Value of 0 is Reserved. 749 6.3. Handling CLASSTYPE Object 751 To establish an LSP tunnel with RSVP, the sender LSR creates a Path 752 message with a session type of LSP_Tunnel_IPv4 and with a 753 LABEL_REQUEST object as per [RSVP-TE]. The sender LSR may also 754 include the DIFFSERV object as per [DIFF-MPLS]. 756 If the LSP is associated with Class-Type 0, the sender LSR MUST NOT 757 include the CLASSTYPE object in the Path message. This allows 759 Le Faucheur et. al 14 761 Protocols for Diff-Serv-aware TE January 2004 763 backward compatibility with non-DSTE-configured or non-DSTE-capable 764 LSRs as discussed below in section 10 and Appendix C. 766 If the LSP is associated with Class-Type N (1 <= N <=7), the sender 767 LSR MUST include the CLASSTYPE object in the Path message with the 768 Class-Type (CT) field set to N. 770 If a path message contains multiple CLASSTYPE objects, only the first 771 one is meaningful; subsequent CLASSTYPE object(s) MUST be ignored and 772 MUST NOT be forwarded. 774 Each LSR along the path MUST record the CLASSTYPE object, when 775 present, in its path state block. 777 If the CLASSTYPE object is not present in the Path message, the LSR 778 MUST associate the Class-Type 0 to the LSP. 780 The destination LSR responding to the Path message by sending a Resv 781 message MUST NOT include a CLASSTYPE object in the Resv message 782 (whether the Path message contained a CLASSTYPE object or not). 784 During establishment of an LSP corresponding to the Class-Type N, the 785 LSR MUST perform admission control over the bandwidth available for 786 that particular Class-Type. 788 An LSR that recognizes the CLASSTYPE object and that receives a path 789 message which: 790 - contains the CLASSTYPE object, but 791 - which does not contain a LABEL_REQUEST object or which does 792 not have a session type of LSP_Tunnel_IPv4, 793 MUST send a PathErr towards the sender with the error code �Diff- 794 Serv-aware TE Error� and an error value of �Unexpected CLASSTYPE 795 object�. Those are defined below in section 6.5. 797 An LSR receiving a Path message with the CLASSTYPE object, which: 798 - recognizes the CLASSTYPE object, but 799 - does not support the particular Class-Type, 800 MUST send a PathErr towards the sender with the error code �Diff- 801 Serv-aware TE Error� and an error value of �Unsupported Class-Type�. 802 Those are defined below in section 6.5. 804 An LSR receiving a Path message with the CLASSTYPE object, which: 805 - recognizes the CLASSTYPE object, but 806 - determines that the Class-Type value is not valid (i.e. 807 Class-Type value 0), 808 MUST send a PathErr towards the sender with the error code �Diff- 809 Serv-aware TE Error� and an error value of �Invalid Class-Type 810 value�. Those are defined below in section 6.5. 812 An LSR receiving a Path message with the CLASSTYPE object, which: 813 - 814 - supports the particular Class-Type, but 816 Le Faucheur et. al 15 818 Protocols for Diff-Serv-aware TE January 2004 820 - determines that the tuple formed by (i) this Class-Type and 821 (ii) the set-up priority signaled in the same Path message, 822 is not one of the eight TE-classes configured in the TE-class 823 mapping, 824 MUST send a PathErr towards the sender with the error code �Diff- 825 Serv-aware TE Error� and an error value of �CT and setup priority do 826 not form a configured TE-Class�. Those are defined below in section 827 6.5. 829 An LSR receiving a Path message with the CLASSTYPE object, which: 830 - recognizes the CLASSTYPE object, 831 - supports the particular Class-Type, but 832 - determines that the tuple formed by (i) this Class-Type and 833 (ii) the holding priority signaled in the same Path message, 834 is not one of the eight TE-classes configured in the TE-class 835 mapping, 836 MUST send a PathErr towards the sender with the error code �Diff- 837 Serv-aware TE Error� and an error value of �CT and holding priority 838 do not form a configured TE-Class�. Those are defined below in 839 section 6.5. 841 An LSR receiving a Path message with the CLASSTYPE object and with 842 the DIFFSERV object for an L-LSP, which: 843 - recognizes the CLASSTYPE object, 844 - has local knowledge of the relationship between Class-Types 845 and PSC (e.g. via configuration) 846 - based on this local knowledge, determines that the PSC 847 signaled in the DIFFSERV object is inconsistent with the 848 Class-Type signaled in the CLASSTYPE object, 849 MUST send a PathErr towards the sender with the error code �Diff- 850 Serv-aware TE Error� and an error value of �Inconsistency between 851 signaled PSC and signaled CT�. Those are defined below in section 852 6.5. 854 An LSR receiving a Path message with the CLASSTYPE object and with 855 the DIFFSERV object for an E-LSP, which: 856 - recognizes the CLASSTYPE object, 857 - has local knowledge of the relationship between Class-Types 858 and PHBs (e.g. via configuration) 859 - based on this local knowledge, determines that the PHBs 860 signaled in the MAP entries of the DIFFSERV object are 861 inconsistent with the Class-Type signaled in the CLASSTYPE 862 object, 863 MUST send a PathErr towards the sender with the error code �Diff- 864 Serv-aware TE Error� and an error value of �Inconsistency between 865 signaled PHBs and signaled CT�. Those are defined below in section 867 An LSR MUST handle the situations where the LSP can not be accepted 868 for other reasons than those already discussed in this section, in 869 accordance with [RSVP-TE] and [DIFF-MPLS] (e.g. a reservation is 870 rejected by admission control, a label can not be associated). 872 Le Faucheur et. al 16 874 Protocols for Diff-Serv-aware TE January 2004 876 6.4. Non-support of the CLASSTYPE Object 878 An LSR that does not recognize the CLASSTYPE object Class-Num MUST 879 behave in accordance with the procedures specified in [RSVP] for an 880 unknown Class-Num whose format is 0bbbbbbb (i.e. it must send a 881 PathErr with the error code �Unknown object class� toward the 882 sender). 884 An LSR that recognizes the CLASSTYPE object Class-Num but does not 885 recognize the CLASSTYPE object C-Type, MUST behave in accordance with 886 the procedures specified in [RSVP] for an unknown C-type (i.e. it 887 must send a PathErr with the error code �Unknown object C-Type� 888 toward the sender). 890 In both situations, this causes the path set-up to fail. The sender 891 SHOULD notify the operator/management-system that an LSP cannot be 892 established and possibly might take action to retry reservation 893 establishment without the CLASSTYPE object. 895 6.5. Error Codes For Diff-Serv-aware TE 897 In the procedures described above, certain errors must be reported as 898 a �Diff-Serv-aware TE Error�. The value of the �Diff-Serv-aware TE 899 Error� error code is (TBD)(). 901 To be removed by the RFC editor at the time of 902 publication: 903 When the �Diff-Serv-aware TE Error� Error Code is assigned by 904 IANA, replace �TBD� above by the assigned value. 905 See IANA Considerations section for allocation request. 906 908 The following defines error values for the Diff-Serv-aware TE Error: 910 Value Error 912 1 Unexpected CLASSTYPE object 913 2 Unsupported Class-Type 914 3 Invalid Class-Type value 915 4 Class-Type and setup priority do not form a configured 916 TE-Class 917 5 Class-Type and holding priority do not form a 918 configured TE-Class 919 6 Inconsistency between signaled PSC and signaled 920 Class-Type 921 7 Inconsistency between signaled PHBs and signaled 922 Class-Type 924 See the IANA Considerations section for allocation of additional 925 Values. 927 Le Faucheur et. al 17 929 Protocols for Diff-Serv-aware TE January 2004 931 7. DS-TE support with MPLS extensions. 933 There are a number of extensions to the initial base specification 934 for signaling [RSVP-TE] and IGP support for TE [OSPF-TE][ISIS-TE]. 935 Those include enhancements for generalization [GMPLS-SIG] 936 [GMPLS-ROUTE], as well as for additional functionality such as LSP 937 hierarchy [HIERARCHY], link bundling [BUNDLE] and fast restoration 938 [REROUTE]. These specifications may reference how to encode 939 information associated with certain preemption priorities, how to 940 treat LSPs at different preemption priorities, or otherwise specify 941 encodings or behavior that have a different meaning for an DS-TE 942 router. 944 In order for an implementation to support both this specification for 945 Diff-Serv-aware TE and a given MPLS enhancement such as those listed 946 above (but not limited to those), it MUST treat references to 947 "preemption priority" and to �Maximum Reservable Bandwidth� in a 948 generalized manner, such as it is used in this specification. 950 Additionally, current and future MPLS enhancements may include more 951 precise specification for how they interact with Diff-Serv-aware TE. 953 7.1. DS-TE support and references to preemption priority 955 When a router supports both Diff-Serv-aware TE and one of the MPLS 956 protocol extensions such as those mentioned above, encoding of values 957 of preemption priority in signaling or encoding of information 958 associated with preemption priorities in IGP defined for the MPLS 959 extension, MUST be considered to be an encoding of the same 960 information for the corresponding TE-Class. For instance, if an MPLS 961 enhancement specifies advertisement in IGP of a parameter for routing 962 information at preemption priority N, in a DS-TE environment it MUST 963 actually be interpreted as specifying advertisement of the same 964 routing information but for TE-Class [N]. On receipt, DS-TE routers 965 MUST interpret it as such as well. 967 When there is discussion on how to comparatively treat LSPs of 968 different preemption priority, a DS-TE LSR MUST treat the preemption 969 priorities in this context as the preemption priorities associated 970 with the TE-Classes of the LSPs in question. 972 7.2. DS-TE support and references to Maximum Reservable Bandwidth 974 When a router supports both Diff-Serv-aware TE and MPLS protocol 975 extensions such as those mentioned above, advertisements of Maximum 976 Reservable Bandwidth MUST be done with the generalized interpretation 977 defined above in section 4.1.1 as the aggregate bandwidth constraint 978 across all Class-Types and MAY also allow the optional advertisement 979 of all Bandwidth Constraints. 981 Le Faucheur et. al 18 983 Protocols for Diff-Serv-aware TE January 2004 985 8. Constraint Based Routing 987 Let us consider the case where a path needs to be computed for an LSP 988 whose Class-Type is configured to CTc and whose set-up preemption 989 priority is configured to p. 991 Then the pair of CTc and p will map to one of the TE-Classes defined 992 in the TE-Class mapping. Let us refer to this TE-Class as TE- 993 Class[i]. 995 The Constraint Based Routing algorithm of a DS-TE LSR is still only 996 required to perform path computation satisfying a single bandwidth 997 constraint which is to fit in �Unreserved TE-Class [i]� as advertised 998 by the IGP for every link. Thus, no changes are required to the 999 existing TE Constraint Based Routing algorithm itself. 1001 The Constraint Based Routing algorithm MAY also take into account, 1002 when used, the optional additional information advertised in IGP such 1003 as the Bandwidth Constraints and the Maximum Reservable Bandwidth. As 1004 an example, the Bandwidth Constraints MIGHT be used as a tie-breaker 1005 criteria in situations where multiple paths, otherwise equally 1006 attractive, are possible. 1008 9. Diff-Serv scheduling 1010 The Class-Type signaled at LSP establishment MAY optionally be used 1011 by DS-TE LSRs to dynamically adjust the resources allocated to the 1012 Class-Type by the Diff-Serv scheduler. In addition, the Diff-Serv 1013 information (i.e. the PSC) signaled by the TE-LSP signaling protocols 1014 as specified in [DIFF-MPLS], if used, MAY optionally be used by DS-TE 1015 LSRs to dynamically adjust the resources allocated to a PSC/OA within 1016 a Class Type by the Diff-Serv scheduler. 1018 10. Existing TE as a Particular Case of DS-TE 1020 We observe that existing TE can be viewed as a particular case of 1021 DS-TE where: 1023 (i) a single Class-Type is used, 1024 (ii) all 8 preemption priorities are allowed for that Class- 1025 Type, and 1026 (iii) the following TE-Class Mapping is used: 1027 TE-Class[i] <--> < CT0 , preemption i > 1028 Where 0 <= i <= 7. 1030 In that case, DS-TE behaves as existing TE. 1032 As with existing TE, the IGP advertises: 1033 - Unreserved Bandwidth for each of the 8 preemption priorities 1035 Le Faucheur et. al 19 1037 Protocols for Diff-Serv-aware TE January 2004 1039 As with existing TE, the IGP may advertise: 1040 - Maximum Reservable Bandwidth containing a bandwidth 1041 constraint applying across all LSPs 1043 Since all LSPs transport traffic from CT0, RSVP-TE signaling is done 1044 without explicit signaling of the Class-Type (which is only used for 1045 other Class-Types than CT0 as explained in section 6) as with 1046 existing TE. 1048 11. Computing �Unreserved TE-Class [i]� and Admission Control Rules 1050 11.1. Computing �Unreserved TE-Class [i]� 1052 We first observe that, for existing TE, details on admission control 1053 algorithms for TE LSPs, and consequently details on formulas for 1054 computing the unreserved bandwidth, are outside the scope of the 1055 current IETF work. This is left for vendor differentiation. Note that 1056 this does not compromise interoperability across various 1057 implementations since the TE schemes rely on LSRs to advertise their 1058 local view of the world in terms of Unreserved Bw to other LSRs. This 1059 way, regardless of the actual local admission control algorithm used 1060 on one given LSR, Constraint Based Routing on other LSRs can rely on 1061 advertised information to determine whether an additional LSP will be 1062 accepted or rejected by the given LSR. The only requirement is that 1063 an LSR advertises unreserved bandwidth values which are consistent 1064 with its specific local admission control algorithm and take into 1065 account the holding preemption priority of established LSPs. 1067 In the context of DS-TE, again, details on admission control 1068 algorithms are left for vendor differentiation and formulas for 1069 computing the unreserved bandwidth for TE-Class[i] are outside the 1070 scope of this specification. However, DS-TE places the additional 1071 requirement on the LSR that the unreserved bandwidth values 1072 advertised MUST reflect all of the Bandwidth Constraints relevant to 1073 the CT associated with TE-Class[i] in accordance with the Bandwidth 1074 Constraints Model. Thus, formulas for computing �Unreserved TE-Class 1075 [i]� depend on the Bandwidth Constraints Model in use and MUST 1076 reflect how bandwidth constraints apply to CTs. Example formulas for 1077 computing �Unreserved TE-Class [i]� Model are provided for the 1078 Russian Dolls Model and Maximum Allocation Model respectively in 1079 [DSTE-RDM] and [DSTE-MAM]. 1081 As with existing TE, DS-TE LSRs MUST consider the holding preemption 1082 priority of established LSPs (as opposed to their set-up preemption 1083 priority) for the purpose of computing the unreserved bandwidth for 1084 TE-Class [i]. 1086 11.2. Admission Control Rules 1088 A DS-TE LSR MUST support the following admission control rule: 1090 Le Faucheur et. al 20 1092 Protocols for Diff-Serv-aware TE January 2004 1094 Regardless of how the admission control algorithm actually computes 1095 the unreserved bandwidth for TE-Class[i] for one of its local link, 1096 an LSP of bandwidth B, of set-up preemption priority p and of Class- 1097 Type CTc is admissible on that link if, and only if,: 1099 B <= Unreserved Bandwidth for TE-Class[i] 1101 Where 1103 - TE-Class [i] maps to < CTc , p > in the TE-Class mapping 1104 configured on the LSR. 1106 12. Security Considerations 1108 This document does not introduce additional security threats beyond 1109 those described for Diff-Serv ([DIFF-ARCH]) and MPLS Traffic 1110 Engineering ([TE-REQ], [RSVP-TE], [OSPF-TE], [ISIS-TE]) and the same 1111 security measures and procedures described in these documents apply 1112 here. For example, the approach for defense against theft- and 1113 denial-of-service attacks discussed in [DIFF-ARCH], which consists of 1114 the combination of traffic conditioning at DS boundary nodes along 1115 with security and integrity of the network infrastructure within a 1116 Diff-Serv domain, may be followed when DS-TE is in use. Also, as 1117 stated in [TE-REQ], it is specifically important that manipulation of 1118 administratively configurable parameters (such as those related to 1119 DS-TE LSPs) be executed in a secure manner by authorized entities. 1121 13. Acknowledgments 1123 We thank Martin Tatham, Angela Chiu and Pete Hicks for their earlier 1124 contribution in this work. We also thank Sanjaya Choudhury for his 1125 thorough review and suggestions. 1127 14. IANA Considerations 1129 This document creates two new name spaces which are to be managed by 1130 IANA. Also, a number of assignments from existing name spaces have 1131 been made by IANA in this document. Those are discussed below. 1133 14.1. A new name space for Bandwidth Constraints Model Identifiers 1135 This document defines in section 5.1 a "Bandwidth Constraints Model 1136 Id" field (name space) within the "Bandwidth Constraints" sub-TLV, 1137 both for OSPF and ISIS. IANA is requested to create and maintain this 1138 new name space. The field for this namespace is 1 octet, and IANA 1139 guidelines for assignments for this field are as follows: 1141 Le Faucheur et. al 21 1143 Protocols for Diff-Serv-aware TE January 2004 1145 o values in the range 0-127 are to be assigned according to 1146 the "Specification Required" policy defined in [IANA-CONS]. 1148 o values in the range 128-239 are not to be assigned at this 1149 time. Before any assignments can be made in this range, there MUST be 1150 a Standards Track RFC that specifies IANA Considerations that cover 1151 assignment within that range. 1153 o values in the range 240-255 are for experimental use; these 1154 will not be registered with IANA, and MUST NOT be mentioned by RFCs. 1156 14.2. A new name space for Error Values under the �Diff-Serv-aware TE 1157 Error� 1159 An Error Code is an 8-bit quantity defined in [RSVP] that appears in 1160 an ERROR_SPEC object to broadly define an error condition. With each 1161 Error Code there may be a 16-bit Error Value (which depends on the 1162 Error Code) that further specifies the cause of the error. 1164 This document defines in section 6.5 a new RSVP error code, the 1165 "Diff-Serv-aware TE Error" (see section 14.3.4). The Error Values for 1166 the "Diff-Serv-aware TE Error" constitute a new name space to be 1167 managed by IANA. 1169 This document defines, in section 6.5, values 1 through 7 in that 1170 name space (see section 14.3.5). 1172 Future allocations of values in this name space are to be assigned by 1173 IANA using the �Specification Required� policy defined in [IANA- 1174 CONS]. 1176 14.3. Assignments made in this Document 1178 14.3.1. Bandwidth Constraints sub-TLV for OSPF version 2 1180 [OSPF-TE] creates a name space for the sub-TLV types within the �Link 1181 TLV� of the Traffic Engineering LSA and rules for management of this 1182 name space by IANA. 1184 This document defines in section 5.1 a new sub-TLV, the "Bandwidth 1185 Constraints" sub-TLV, for the OSPF "Link" TLV. In accordance with the 1186 IANA considerations provided in [OSPF-TE], a sub-TLV type in the 1187 range 10 to 32767 was requested and the value TBD has been assigned 1188 by IANA for the "Bandwidth Constraints" sub-TLV. 1190 To be removed by the RFC editor at the time of 1191 publication: 1192 When the sub-TLV Type is assigned by IANA replace �TBD� above 1193 by the assigned value. 1194 1196 14.3.2. Bandwidth Constraints sub-TLV for ISIS 1198 Le Faucheur et. al 22 1200 Protocols for Diff-Serv-aware TE January 2004 1202 [ISIS-TE] creates a name space for the sub-TLV types within the ISIS 1203 �Extended IS Reachability� TLV and rules for management of this name 1204 space by IANA. 1206 This document defines in section 5.1 a new sub-TLV, the "Bandwidth 1207 Constraints" sub-TLV, for the ISIS �Extended IS Reachability" TLV. In 1208 accordance with the IANA considerations provided in [ISIS-TE], a sub- 1209 TLV type was requested and the value TBD has been assigned by IANA 1210 for the "Bandwidth Constraints" sub-TLV. 1212 To be removed by the RFC editor at the time of 1213 publication: 1214 When the sub-TLV Type is assigned by IANA replace �TBD� above 1215 by the assigned value. 1216 1218 14.3.3. CLASSTYPE object for RSVP 1220 [RSVP] defines the Class Number name space for RSVP object which is 1221 managed by IANA. Currently allocated Class Numbers are listed at 1222 �http://www.iana.org/assignments/rsvp-parameters" 1224 This document defines in section 6.2.1 a new RSVP object, the 1225 CLASSTYPE object. IANA was requested to assign a Class Number for 1226 this RSVP object from the range defined in section 3.10 of [RSVP] for 1227 those objects which, if not understood, cause the entire RSVP message 1228 to be rejected with an error code of "Unknown Object Class". Such 1229 objects are identified by a zero in the most significant bit of the 1230 class number (i.e. 1231 Class-Num = 0bbbbbbb). 1232 IANA assigned Class-Number TBD to the CLASSTYPE object. C_Type 1 is 1233 defined in this document for the CLASSTYPE object. 1235 To be removed by the RFC editor at the time of 1236 publication: 1237 When the RSVP Class-Num is assigned by IANA replace �TBD� 1238 above by the assigned value. 1239 1241 14.3.4. �Diff-Serv-aware TE Error� Error Code 1243 [RSVP] defines the Error Code name space and rules for management of 1244 this name space by IANA. Currently allocated Error Codes are listed 1245 at �http://www.iana.org/assignments/rsvp-parameters" 1247 This document defines in section 6.5 a new RSVP Error Code, the 1248 "Diff-Serv-aware TE Error". In accordance with the IANA 1249 considerations provided in [RSVP], Error Code TBD was assigned by 1250 IANA to the �Diff-Serv-aware TE Error�. 1252 Le Faucheur et. al 23 1254 Protocols for Diff-Serv-aware TE January 2004 1256 To be removed by the RFC editor at the time of 1257 publication: 1258 When the RSVP Class-Num is assigned by IANA replace �TBD� 1259 above by the assigned value. 1260 1262 14.3.5. Error Values for �Diff-Serv-aware TE Error� 1264 An Error Code is an 8-bit quantity defined in [RSVP] that appears in 1265 an ERROR_SPEC object to broadly define an error condition. With each 1266 Error Code there may be a 16-bit Error Value (which depends on the 1267 Error Code) that further specifies the cause of the error. 1269 This document defines in section 6.5 a new RSVP error code, the 1270 "Diff-Serv-aware TE Error" (see section 14.3.4). The Error Values for 1271 the "Diff-Serv-aware TE Error" constitute a new name space to be 1272 managed by IANA. 1274 This document defines, in section 6.5, the following Error Values for 1275 the �Diff-Serv-aware TE Error�: 1277 Value Error 1279 1 Unexpected CLASSTYPE object 1280 2 Unsupported Class-Type 1281 3 Invalid Class-Type value 1282 4 Class-Type and setup priority do not form a configured 1283 TE-Class 1284 5 Class-Type and holding priority do not form a 1285 configured TE-Class 1286 6 Inconsistency between signaled PSC and signaled 1287 Class-Type 1288 7 Inconsistency between signaled PHBs and signaled 1289 Class-Type 1291 See section 14.2 for allocation of other values in that name space. 1293 15. Intellectual Property Considerations 1295 The IETF takes no position regarding the validity or scope of any 1296 intellectual property or other rights that might be claimed to 1297 pertain to the implementation or use of the technology described in 1298 this document or the extent to which any license under such rights 1299 might or might not be available; neither does it represent that it 1300 has made any effort to identify any such rights. Information on the 1301 IETF's procedures with respect to rights in standards-track and 1302 standards-related documentation can be found in RFC 2028. Copies of 1303 claims of rights made available for publication and any assurances of 1304 licenses to be made available, or the result of an attempt made to 1305 obtain a general license or permission for the use of such 1307 Le Faucheur et. al 24 1308 Protocols for Diff-Serv-aware TE January 2004 1310 proprietary rights by implementors or users of this specification can 1311 be obtained from the IETF Secretariat. 1313 The IETF invites any interested party to bring to its attention any 1314 copyrights, patents or patent applications, or other proprietary 1315 rights which may cover technology that may be required to practice 1316 this standard. Please address the information to the IETF Executive 1317 Director. 1319 16. Normative References 1321 [DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv- 1322 aware MPLS Traffic Engineering, RFC3564, . 1324 [MPLS-ARCH] Rosen et al., �Multiprotocol Label Switching 1325 Architecture�, RFC3031. 1327 [DIFF-ARCH] Blake et al., �An Architecture for Differentiated 1328 Services�, RFC2475. 1330 [TE-REQ] Awduche et al., �Requirements for Traffic Engineering Over 1331 MPLS�, RFC2702. 1333 [OSPF-TE] Katz et al., �Traffic Engineering (TE) Extensions to OSPF 1334 Version 2�, RFC3630. 1336 [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft- 1337 ietf-isis-traffic-05.txt, work in progress. 1339 [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 1340 Tunnels", RFC 3209. 1342 [RSVP] Braden et al, "Resource ReSerVation Protocol (RSVP) - Version 1343 1 Functional Specification", RFC 2205. 1345 [DIFF-MPLS] Le Faucheur et al, "MPLS Support of Diff-Serv", RFC3270. 1347 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 1348 Requirement Levels, RFC2119. 1350 [IANA-CONS], T. Narten et al, �Guidelines for Writing an IANA 1351 Considerations Section in RFCs�, RFC2434. 1353 17. Informative References 1355 [DSTE-RDM] Le Faucheur et al., �Russian Dolls Bandwidth Constraints 1356 Model for DS-TE�, draft-ietf-tewg-diff-te-russian-04.txt, work in 1357 progress. 1359 Le Faucheur et. al 25 1361 Protocols for Diff-Serv-aware TE January 2004 1363 [DSTE-MAM] Le Faucheur, Lai, �Maximum Allocation Bandwidth 1364 Constraints Model for DS-TE�, draft-ietf-tewg-diff-te-mam-02.txt, 1365 work in progress . 1367 [DSTE-MAR] Ash, �Max Allocation with Reservation Bandwidth 1368 Constraints Model for MPLS/DiffServ TE & Performance Comparisons�, 1369 draft-ietf-tewg-diff-te-mar-03.txt, work in progress . 1371 [GMPLS-SIG] Berger et. al., "Generalized Multi-Protocol Label 1372 Switching (GMPLS) Signaling Functional Description", RFC3471 1374 [GMPLS-ROUTE] Kompella et. al., "Routing Extensions in Support of 1375 Generalized MPLS", draft-ietf-ccamp-gmpls-routing-09.txt, work in 1376 progress. 1378 [BUNDLE] Kompella, Rekhter, Berger, "Link Bundling in MPLS Traffic 1379 Engineering", draft-ietf-mpls-bundle-04.txt, work in progress. 1381 [HIERARCHY] Kompella, Rekhter, "LSP Hierarchy with Generalized MPLS 1382 TE", draft-ietf-mpls-lsp-hierarchy-08.txt, work in progress. 1384 [REROUTE] Pan et. al., "Fast Reroute Extensions to RSVP-TE for LSP 1385 Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt, work in 1386 progress. 1388 18. Editor�s Address: 1390 Francois Le Faucheur 1391 Cisco Systems, Inc. 1392 Village d'Entreprise Green Side - Batiment T3 1393 400, Avenue de Roumanille 1394 06410 Biot-Sophia Antipolis 1395 France 1396 Phone: +33 4 97 23 26 19 1397 Email: flefauch@cisco.com 1399 19. Full Copyright Statement 1401 Copyright (C) The Internet Society (2004). All Rights Reserved. 1403 This document and translations of it may be copied and furnished to 1404 others, and derivative works that comment on or otherwise explain it 1405 or assist in its implementation may be prepared, copied, published 1406 and distributed, in whole or in part, without restriction of any 1407 kind, provided that the above copyright notice and this paragraph are 1408 included on all such copies and derivative works. However, this 1409 document itself may not be modified in any way, such as by removing 1410 the copyright notice or references to the Internet Society or other 1411 Internet organizations, except as needed for the purpose of 1412 developing Internet standards in which case the procedures for 1414 Le Faucheur et. al 26 1416 Protocols for Diff-Serv-aware TE January 2004 1418 copyrights defined in the Internet Standards process must be 1419 followed, or as required to translate it into languages other than 1420 English. 1422 The limited permissions granted above are perpetual and will not be 1423 revoked by the Internet Society or its successors or assigns. 1425 This document and the information contained herein is provided on an 1426 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1427 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1428 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1429 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1430 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1432 Appendix A � Prediction for Multiple Path Computation 1434 There are situations where a Head-End needs to compute paths for 1435 multiple LSPs over a short period of time. There are potential 1436 advantages for the Head-end in trying to predict the impact of the n- 1437 th LSP on the unreserved bandwidth when computing the path for the 1438 (n+1)-th LSP, before receiving updated IGP information. One example 1439 would be to perform better load-distribution of the multiple LSPs 1440 across multiple paths. Another example would be to avoid CAC 1441 rejection when the (n+1)-th LSP would no longer fit on a link after 1442 establishment of the n-th LSP. While there are also a number of 1443 conceivable scenarios where doing such predictions might result in a 1444 worse situation, it is more likely to improve the situation. As a 1445 matter of fact, a number of network administrators have elected to 1446 use such predictions when deploying existing TE. 1448 Such predictions are local matters, are optional and are outside the 1449 scope of this specification. 1451 Where such predictions are not used, the optional Bandwidth 1452 Constraint sub-TLV and the optional Maximum Reservable Bandwidth sub- 1453 TLV need not be advertised in IGP for the purpose of path computation 1454 since the information contained in the Unreserved Bw sub-TLV is all 1455 that is required by Head-Ends to perform Constraint Based Routing. 1457 Where such predictions are used on Head-Ends, the optional Bandwidth 1458 Constraints sub-TLV and the optional Maximum Reservable Bandwidth 1459 sub-TLV MAY be advertised in IGP. This is in order for the Head-ends 1460 to predict as accurately as possible how an LSP affects unreserved 1461 bandwidth values for subsequent LSPs. 1463 Remembering that actual admission control algorithms are left for 1464 vendor differentiation, we observe that predictions can only be 1465 performed effectively when the Head-end LSR predictions are based on 1466 the same (or a very close) admission control algorithm as used by 1467 other LSRs. 1469 Le Faucheur et. al 27 1471 Protocols for Diff-Serv-aware TE January 2004 1473 Appendix B - Solution Evaluation 1475 1. Satisfying Detailed Requirements 1477 This DS-TE Solution addresses all the scenarios presented in [DSTE- 1478 REQ]. 1480 It also satisfies all the detailed requirements presented in [DSTE- 1481 REQ]. 1483 The objective set out in the last paragraph of section �4.7 1484 overbooking� of [DSTE-REQ] is only partially addressed by this DS-TE 1485 solution. Through support of the �LSP Size Overbooking� and �Link 1486 Size Overbooking� methods, this DS-TE solution effectively allows CTs 1487 to have different overbooking ratios and simultaneously allows 1488 overbooking to be tweaked differently (collectively across all CTs) 1489 on different links. But, in a general sense, it does not allow the 1490 effective overbooking ratio of every CT to be tweaked differently in 1491 different parts of the network independently of other CTs, while 1492 maintaining accurate bandwidth accounting of how different CTs 1493 mutually affect each other through shared Bandwidth Constraints (such 1494 as the Maximum Reservable Bandwidth). 1496 2. Flexibility 1498 This DS-TE solution supports 8 CTs. It is entirely flexible as to how 1499 Traffic Trunks are grouped together into a CT. 1501 3. Extendibility 1503 A maximum of 8 CTs is considered by the authors of this document as 1504 more than comfortable. A maximum of 8 TE-classes is considered by the 1505 authors of this document as sufficient. However, this solution could 1506 be extended to support more CTs or more TE-classes if deemed 1507 necessary in the future; This would necessitate additional IGP 1508 extensions beyond those specified in this document. 1510 Although the prime objective of this solution is support of Diff- 1511 Serv-aware Traffic Engineering, its mechanisms are not tightly 1512 coupled with Diff-Serv. This makes the solution amenable, or more 1513 easily extendable, for support of potential other future Traffic 1514 Engineering applications. 1516 4. Scalability 1518 This DS-TE solution is expected to have a very small scalability 1519 impact compared to existing TE. 1521 From an IGP viewpoint, the amount of mandatory information to be 1522 advertised is identical to existing TE. One additional sub-TLV has 1523 been specified, but its use is optional and it only contains a 1525 Le Faucheur et. al 28 1527 Protocols for Diff-Serv-aware TE January 2004 1529 limited amount of static information (at most 8 Bandwidth 1530 Constraints). 1532 We expect no noticeable impact on LSP Path computation since, as with 1533 existing TE, this solution only requires CSPF to consider a single 1534 unreserved bandwidth value for any given LSP. 1536 From a signaling viewpoint we expect no significant impact due to 1537 this solution since it only requires processing of one additional 1538 information (the Class-Type) and does not significantly increase the 1539 likelihood of CAC rejection. Note that DS-TE has some inherent impact 1540 on LSP signaling in the sense that it assumes that different classes 1541 of traffic are split over different LSPs so that more LSPs need to be 1542 signaled; but this is due to the DS-TE concept itself and not to the 1543 actual DS-TE solution discussed here. 1545 5. Backward Compatibility/Migration 1547 This solution is expected to allow smooth migration from existing TE 1548 to DS-TE. This is because existing TE can be supported as a 1549 particular configuration of DS-TE. This means that an �upgraded� LSR 1550 with a DS-TE implementation can directly interwork with an �old� LSR 1551 supporting existing TE only. 1553 This solution is expected to allow smooth migration when increasing 1554 the number of CTs actually deployed since it only requires 1555 configuration changes. however, these changes must be performed in a 1556 coordinated manner across the DS-TE domain. 1558 Appendix C � Interoperability with non DS-TE capable LSRs 1560 This DSTE solution allows operations in a hybrid network where some 1561 LSRs are DS-TE capable while some LSRs are not DS-TE capable, which 1562 may occur during migration phases. This Appendix discusses the 1563 constraints and operations in such hybrid networks. 1565 We refer to the set of DS-TE capable LSRs as the DS-TE domain. We 1566 refer to the set of non DS-TE capable (but TE capable) LSRs as the 1567 TE-domain. 1569 Hybrid operations requires that the TE-class mapping in the DS-TE 1570 domain is configured so that: 1571 - a TE-class exist for CT0 for every preemption priority 1572 actually used in the TE domain 1573 - the index in the TE-class mapping for each of these TE- 1574 classes is equal to the preemption priority. 1576 For example, imagine the TE domain uses preemption 2 and 3. Then, DS- 1577 TE can be deployed in the same network by including the following TE- 1578 classes in the TE-class mapping: 1579 i <---> CT preemption 1581 Le Faucheur et. al 29 1582 Protocols for Diff-Serv-aware TE January 2004 1584 ==================================== 1585 2 CT0 2 1586 3 CT0 3 1588 Another way to look at this is to say that, the whole TE-class 1589 mapping does not have to be consistent with the TE domain, but the 1590 subset of this TE-Class mapping applicable to CT0 must effectively be 1591 consistent with the TE domain. 1593 Hybrid operations also requires that: 1594 - non DS-TE capable LSRs be configured to advertise the Maximum 1595 Reservable Bandwidth 1596 - DS-TE capable LSRs be configured to advertise Bandwidth 1597 Constraints (using the Max Reservable Bandwidth sub-TLV as 1598 well as the Bandwidth Constraints sub-TLV, as specified in 1599 section 5.1 above). 1600 This allows DS-TE capable LSRs to unambiguously identify non DS-TE 1601 capable LSRs. 1603 Finally hybrid operations require that non DS-TE capable LSRs be able 1604 to accept Unreserved Bw sub-TLVs containing non decreasing bandwidth 1605 values (ie with Unreserved [p] < Unreserved [q] with p CT preemption 1630 ==================================== 1631 0 CT1 0 1632 1 CT1 1 1633 3 CT0 3 1635 Le Faucheur et. al 30 1637 Protocols for Diff-Serv-aware TE January 2004 1639 rest unused 1641 LSR0 is configured with a Max Reservable bandwidth=m01 for Link01. 1642 LSR1 is configured with a BC0=x0 a BC1=x1(possibly=0), and a Max 1643 Reservable Bandwidth=m10(possibly=m01) for Link01. 1645 LSR0 will advertise in IGP for Link01: 1646 - Max Reservable Bw sub-TLV = 1647 - Unreserved Bw sub-TLV = 1648 1650 On receipt of such advertisement, LSR1 will: 1651 - understand that LSR0 is not DS-TE capable because it 1652 advertised a Max Reservable Bw sub-TLV and no Bandwidth 1653 Constraints sub-TLV 1654 - conclude that only CT0 LSPs can transit via LSR0 and that 1655 only the values CT0/2 and CT0/3 are meaningful in the 1656 Unreserved Bw sub-TLV. LSR1 may effectively behave as if the 1657 six other values contained in the Unreserved Bw sub-TLV were 1658 set to zero. 1660 LSR1 will advertise in IGP for Link01: 1661 - Max Reservable Bw sub-TLV = 1662 - Bandwidth Constraints sub-TLV = 1663 - Unreserved Bw sub-TLV = 1665 On receipt of such advertisement, LSR0 will: 1666 - Ignore the Bandwidth Constraints sub-TLV (unrecognized) 1667 - Correctly process CT0/2 and CT0/3 in the Unreserved Bw sub- 1668 TLV and use these values for CTO LSP establishment 1669 - Incorrectly believe that the other values contained in the 1670 Unreserved Bw sub-TLV relates to other preemption priorities 1671 for CT0, but will actually never use those since we assume 1672 that only preemption 2 and 3 are used in the TE domain. 1674 Le Faucheur et. al 31