idnits 2.17.1 draft-lefaucheur-diff-te-ext-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([TEWG-FW], [DIFF-TE-REQTS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 299: '...th this specification MUST support the...' RFC 2119 keyword, line 300: '...STYPE Object. It MUST support Class-Ty...' RFC 2119 keyword, line 422: '... An LSR MUST handle the situations w...' RFC 2119 keyword, line 493: '...is specification MUST support the Clas...' RFC 2119 keyword, line 494: '... Type TLV. It MUST support Class-Typ...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RSVP' is mentioned on line 437, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2702 (ref. 'TE-REQ') == Outdated reference: A later version (-05) exists of draft-ietf-tewg-framework-01 ** Downref: Normative reference to an Informational draft: draft-ietf-tewg-framework (ref. 'TEWG-FW') -- Possible downref: Normative reference to a draft: ref. 'DIFF-TE-REQTS' == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-01 == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-01 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'ISIS-TE') == Outdated reference: A later version (-09) exists of draft-ietf-mpls-rsvp-lsp-tunnel-05 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-diff-ext-05 == Outdated reference: A later version (-11) exists of draft-ietf-mpls-ldp-06 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-cr-ldp-03 Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Francois Le Faucheur 2 Thomas D. Nadeau 3 Cisco Systems, Inc. 5 Angela Chiu 6 AT&T 8 William Townsend 9 Tenor Networks 11 Darek Skalecki 12 Nortel Networks 14 IETF Internet Draft 15 Expires: January, 2001 16 Document: draft-lefaucheur-diff-te-ext-00.txt July, 2000 18 Extensions to IS-IS, OSPF, RSVP and CR-LDP 19 for support of Diff-Serv-aware MPLS Traffic Engineering 21 Status of this Memo 23 This document is an Internet-Draft and is in full conformance with 24 all provisions of Section 10 of RFC2026. Internet-Drafts are 25 Working documents of the Internet Engineering Task Force (IETF), its 26 areas, and its working groups. Note that other groups may also 27 distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 A companion document [DIFF-TE-REQTS] defines the requirements for 42 support of Diff-Serv-aware MPLS Traffic Engineering on a per-Class- 43 Type basis, as discussed in the Traffic Engineering Working Group 44 Framework document [TEWG-FW]. 46 This document proposes corresponding extensions to OSPF, ISIS, RSVP 47 and CR-LDP for support of Traffic Engineering on a per-Class-Type 48 basis. 50 Le Faucheur, et. al 1 51 1. Introduction 53 As Diffserv becomes prominent in providing scalable multi-class of 54 services in IP networks, performing traffic engineering at a per- 55 class level instead of an aggregated level is needed to further 56 enhance networks in performance and efficiency. By mapping a traffic 57 trunk in a given class on a separate LSP, it allows the traffic 58 trunk to utilize resources available on both shortest path(s) and 59 non-shortest paths and follow paths that meet constraints which are 60 specific to the given class. It also allows each class to select the 61 proper protection/restoration mechanism(s) that satisfy its 62 survivability requirements in a cost effective manner. 64 Besides the set of parameters defined for the general aggregate TE 65 [TE-REQ], a new set of per-class parameters needs to be provided at 66 each LSR interface and propagated via extensions to the IGP 67 (ISIS/OSPF) [TEWG-FW]. Furthermore, the per-class parameters can be 68 aggregated into per-Class-Type parameters. The main motivation for 69 grouping a set of classes into a Class-Type is to improve the 70 scalability of the IGP link state advertisements by propagating 71 information on a per-Class-Type basis instead of on a per-class 72 basis. This approach also has the benefit of allowing better 73 bandwidth sharing between classes in the same Class-Type. 75 A Class-Type [TEWG-FW] is defined as a set of classes that satisfy 76 the following two conditions: 78 1) Classes in the same Class-Type possess common aggregate maximum 79 and minimum bandwidth requirements to guarantee the required 80 performance level. 82 2) There is no maximum or minimum bandwidth requirement to be 83 enforced at the level of an individual class within the Class- 84 Type. One can still implement some "priority" policies for 85 classes within the same Class-Type in terms of accessing the 86 Class-Type bandwidth (e.g. via the use of preemption 87 priorities). 89 An example of Class-Type comprising multiple Diff-Serv classes is a 90 low-loss Class-Type that includes both AF1-based and AF2-based 91 Ordering Aggregates. 93 Note that with per Class-Type TE, Constraint-Based Routing is 94 performed with bandwidth constraints on a per Class-Type basis but 95 LSPs may carry a single Diff-Serv class (Ordered Aggregate) with 96 Diff-Serv scheduling (i.e. PHB) performed separately for each class. 97 Diff-Serv scheduling parameters for a given class within a Class- 98 Type may be automatically adjusted by the LSRs based on the 99 bandwidth of all LSPs currently established for each class within 100 the Class-Type. 102 Le Faucheur et. al 2 103 In this document, we will only discuss "per Class-Type TE" because 104 "per Class TE" can be viewed as a special case of per Class-Type TE 105 (where each Class-Type is degenerated into a single Diff-Serv 106 class). 108 This document focuses on intra-domain operations. Inter-domain 109 operations is for further study. 111 A companion document [DIFF-TE-REQTS] defines the requirements for 112 support of MPLS Traffic Engineering on a per-Class-Type basis. The 113 following sections propose detailed extensions to OSPF, ISIS, RSVP 114 and CR-LDP that meet those requirements. 116 2. OSPF Extensions 118 In this section we propose extensions to OSPF for support of Diff- 119 Serv Traffic Engineering on a per-Class-Type basis which meet the 120 requirements defined in [DIFF-TE-REQTS]. These extensions are in 121 addition to the extensions already defined for support of 122 (aggregate) MPLS Traffic Engineering [OSPF-TE]. 124 2.1. Existing TE Sub-TLVs 126 [OSPF-TE] defines a new LSA for support of (aggregate) Traffic 127 Engineering, which is referred to as the Traffic Engineering LSA. 128 This LSA contains a Link TLV (Type 2) comprising a number of sub- 129 TLVs. 131 In this document we refer to the sub-TLV 7 (maximum reservable 132 bandwidth) of the Link TLV (as defined in [OSPF-TE]) as the "Maximum 133 Reservable Aggregate Bandwidth". 135 We also refer to the sub-TLV 8 (unreserved bandwidth) of the Link 136 TLV (as defined in [OSPF-TE]) as the "Unreserved Bandwidth for 137 Class-Type 0". 139 2.2. New Sub-TLVs 141 The following additional sub-TLVs are defined for the Link TLV of 142 the Traffic Engineering LSA (sub-TLV numbers to be allocated) 144 TBD - Unreserved Bandwidth for Class-Type 1 (32 octets) 145 TBD+1 - Unreserved Bandwidth for Class-Type 2 (32 octets) 146 TBD+2 - Unreserved Bandwidth for Class-Type 3 (32 octets) 148 Each sub-TLV may occur only once. Unrecognized types are ignored. 150 Unlike the sub-TLVs defined for the Link TLV in [OSPF-TE], the 151 additional sub-TLVs defined above are optional. 153 Le Faucheur et. al 3 154 The Link TLV may include the sub-TLVs for any subset of the three 155 additional Class-Types. In other words, the Link TLV may contain 156 none of the three sub-TLVs defined above, any one of those, any two 157 of those, or the three sub-TLVs. Where a Class-Type is not 158 effectively used in a network, it is recommended that the 159 corresponding sub-TLV is not included in the Link TLV. For instance, 160 a Network Administrator may elect to use Diff-Serv Traffic 161 Engineering in order to compute separate routes for data traffic and 162 voice traffic (and apply different bandwidth constraints to the 163 route computation for those). In that case, the IGP would only 164 advertise the sub-TLV for one additional Class-Type (i.e. the Link 165 TLV would contain sub-TLV 7 for the Maximum Reservable Aggregate 166 Bandwidth, sub-TLV 8 for the Unreserved Bandwidth for Class-Type 0 167 and sub-TLV TBD for Unreserved Bandwidth for Class-Type 1). 169 An LSR which supports Class-Type N and receiving a Link TLV without 170 the sub-TLV corresponding to Class-Type N, interprets this as 171 meaning that the corresponding link does not support Class-Type N. 172 For Constraint Based Routing purposes, the LSR may consider this 173 equivalent to the case where the Link TLV contains an Unreserved 174 Bandwidth for Class-Type N sub-TLV set to zero. 176 2.3. Sub-TLV Details 178 The Unreserved Bandwidth for Class-Type N (N= 1,2,3) sub-TLV 179 specifies the amount of bandwidth not yet reserved at each of the 180 eight preemption priority levels for Class-Type N, in IEEE floating 181 point format. Each value will be less than or equal to the Maximum 182 Reservable Bandwidth for Class-Type N. The units are bytes per 183 second. The values correspond to the bandwidth that can be reserved 184 with a holding priority of 0 through 7, arranged in increasing order 185 with priority 0 occurring at the start of the sub-TLV, and priority 186 7 at the end of the sub-TLV. 188 The Unreserved Bandwidth for Class-Type N sub-TLV is TLV type 189 (TBD-1+N) , and is 32 octets in length. 191 3. ISIS Extensions 193 In this section we describe extensions to IS-IS for support of Diff- 194 Serv Traffic Engineering on a per-Class-Type basis which meet the 195 requirements defined in [DIFF-TE-REQTS]. These extensions are in 196 addition to the extensions required to support (aggregate) MPLS 197 Traffic Engineering [ISIS-TE]. 199 3.1. Existing TE sub-TLVs 201 [ISIS-TE] defines new extended TLVs for support of (aggregate) 202 Traffic Engineering. One of these extended TLV is referred to as the 203 extended IS reachability TLV (TLV type 22). This TLV contains a 204 number of new sub-TLVs. 206 Le Faucheur et. al 4 207 In this document we refer to the sub-TLV 10 (maximum reservable 208 bandwidth) of the extended IS reachability TLV (as defined in [ISIS- 209 TE]) as the "Maximum Reservable Aggregate Bandwidth". 211 We also refer to the sub-TLV 11 (unreserved bandwidth) of the 212 extended IS reachability TLV (as defined in [ISIS-TE]) as the 213 "Unreserved Bandwidth for Class-Type 0". 215 3.2. New Sub-TLVs 217 The following additional sub-TLVs are defined for the extended IS 218 reachability TLV (sub-TLV numbers to be allocated): 220 TBD - Unreserved bandwidth for Class-Type 1 (32 octets) 221 TBD+1 - Unreserved bandwidth for Class-Type 2 (32 octets) 222 TBD+2 - Unreserved bandwidth for Class-Type 3 (32 octets) 224 Each sub-TLV may occur only once. Unrecognized types are ignored. 226 The additional sub-TLVs defined above are optional so that they may 227 or may not be included in the extended IS reachability TLV. 229 The extended IS reachability TLV may include the sub-TLVs for any 230 subset of the three additional Class-Types. In other words, the IS 231 reachability TLV may contain none of the three sub-TLVs defined 232 above, any one of those, any two of those, or the three sub-TLVs. 233 Where a Class-Type is not effectively used in a network, it is 234 recommended that the corresponding sub-TLV is not included in the IS 235 reachability TLV. For instance, a Network Administrator may elect to 236 use Diff-Serv Traffic Engineering in order to compute separate 237 routes for data traffic and voice traffic (and apply different 238 bandwidth constraints to the route computation for those). In that 239 case, the IGP would only advertise the sub-TLV for one additional 240 Class-Type (i.e. the extended IS reachability TLV would contain sub- 241 TLV 10 for the Maximum Reservable Aggregate Bandwidth, sub-TLV 11 242 for the Unreserved Bandwidth for Class-Type 0 and sub-TLV TBD for 243 Unreserved Bandwidth for Class-Type 1). 245 An LSR which supports Class-Type N and receiving an extended IS 246 reachability TLV without the sub-TLV corresponding to Class-Type N, 247 interprets this as meaning that the corresponding link does not 248 support Class-Type N. For Constraint Based Routing purposes, the LSR 249 may consider this equivalent to the case where the extended IS 250 reachability TLV contains an Unreserved Bandwidth Class-Type N sub- 251 TLV set to zero. 253 3.3. Sub-TLV Details 255 The Unreserved Bandwidth for Class-Type N (N= 1,2,3) sub-TLVs 256 specifies the amount of bandwidth not yet reserved at each of the 257 eight preemption priority levels for Class-Type N, in IEEE floating 259 Le Faucheur et. al 5 260 point format. Each value will be less than or equal to the Maximum 261 Reservable Bandwidth for Class-Type N. The units are bytes per 262 second. The values correspond to the bandwidth that can be reserved 263 with a holding priority of 0 through 7, arranged in increasing order 264 with priority 0 occurring at the start of the sub-TLV, and priority 265 7 at the end of the sub-TLV. 267 The Unreserved Bandwidth for Class-Type N sub-TLV is TLV type 268 (TBD-1+N), and is 32 octets in length. 270 4. RSVP Extensions 272 In this section we describe extensions to RSVP for support of 273 Diff-Serv Traffic Engineering on a per-Class-Type basis which meet 274 the requirements defined in [DIFF-TE-REQTS]. These extensions are in 275 addition to the extensions to RSVP defined in [RSVP-TE] for support 276 of (aggregate) MPLS Traffic Engineering and to the extensions to 277 RSVP defined in [DIFF-MPLS] for support of Diff-Serv over MPLS. 279 4.1. Diff-Serv related RSVP Messages Format 281 One new RSVP Object is defined in this document: the CLASSTYPE 282 Object. Detailed description of this Object is provided below. This 283 new Object is applicable to Path messages. This specification only 284 defines the use of the CLASSTYPE Object in Path messages used to 285 establish LSP Tunnels in accordance with [RSVP-TE] and thus 286 containing a Session Object with a C-Type equal to LSP_TUNNEL_IPv4 287 and containing a LABEL_REQUEST object. 289 Restrictions defined in [RSVP-TE] for support of establishment of 290 LSP Tunnels via RSVP are also applicable to the establishment of LSP 291 Tunnels supporting Diff-Serv Traffic Engineering. For instance, only 292 unicast LSPs are supported and Multicast LSPs are for further study. 294 This new CLASSTYPE object is optional with respect to RSVP so that 295 general RSVP implementations not concerned with MPLS LSP set up do 296 not have to support this object. 298 An LSR supporting Diff-Serv Traffic Engineering on a per-Class-Type 299 basis in compliance with this specification MUST support the 300 CLASSTYPE Object. It MUST support Class-Type value 1, and MAY 301 support other Class-Type values. 303 4.1.1. Path Message Format 305 The format of the Path message is as follows: 307 ::= [ ] 308 309 310 [ ] 312 Le Faucheur et. al 6 313 314 [ ] 315 [ ] 316 [ ] 317 [ ... ] 318 [ ] 320 ::= [ ] 321 [ ] 322 [ ] 324 4.2. CLASSTYPE Object 326 The CLASSTYPE object format is shown below. 328 4.2.1. CLASSTYPE object 330 class = TBD, C_Type = 1 (need to get an official class num from the 331 IANA with the form 0bbbbbbb) 333 0 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Reserved |CT | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 Reserved : 30 bits 340 This field is reserved. It must be set to zero on transmission 341 and must be ignored on receipt. 343 CT : 2 bits 344 Indicates the Class-Type. Values currently allowed are 1, 2 and 345 3. 347 4.3. Handling CLASSTYPE Object 349 To establish an LSP tunnel with RSVP, the sender LSR creates a Path 350 message with a session type of LSP_Tunnel_IPv4 and with a 351 LABEL_REQUEST object as per [RSVP-TE]. The sender LSR may also 352 include the DIFFSERV object as per [DIFF-MPLS]. 354 If the LSP is associated with Class-Type 0, the sender LSR must not 355 include the CLASSTYPE object in the Path message. 357 If the LSP is associated with Class-Type N (N=1,2,3), the sender LSR 358 must include the CLASSTYPE object in the Path message with the 359 Class-Type (CT) field set to N. 361 [Editor's Note: additional options whereby the Class-Type could be 362 determined by the LSR without explicit Class-Type signaling are 364 Le Faucheur et. al 7 365 investigated. For example, the Class-Type could be determined from 366 Diff-Serv information already signaled such as the PSC for an L-LSP 367 and using a PSC<-->Class-Type mapping locally configured ] 369 If a path message contains multiple CLASSTYPE objects, only the 370 first one is meaningful; subsequent CLASSTYPE object(s) must be 371 ignored and not forwarded. 373 Each LSR along the path records the CLASSTYPE object, when present, 374 in its path state block. 376 If the CLASSTYPE object is not present in the Path message, the LSR 377 must associate the Class-Type 0 to the LSP. 379 The destination LSR responds to the Path message by sending a Resv 380 message without a CLASSTYPE object (whether the Path message 381 contained a CLASSTYPE object or not). 383 During establishment of an LSP corresponding to the Class-Type N, 384 the LSR performs admission control over the bandwidth available for 385 that particular Class-Type, which is computed using the smallest of: 386 - the Class-Type N bandwidth currently unreserved (i.e. the 387 difference between the Maximum Reservable Bandwidth for Class- 388 Type N and the bandwidth reserved by existing Class-Type N 389 LSPs). 390 - the aggregate bandwidth currently unreserved (i.e. the 391 difference between the Maximum Reservable Aggregate Bandwidth 392 and the bandwidth reserved by existing LSPs of all Class-Types). 394 In order to accurately apportion the resources associated with a 395 Class-Type among the classes comprised in this Class-Type, the LSR 396 may automatically adjust Diff-Serv scheduling parameters associated 397 with a class within a Class-Type based on the bandwidth currently 398 reserved by LSPs currently established in that class. 400 An LSR that recognizes the CLASSTYPE object and receives a path 401 message which contains the CLASSTYPE object but which does not 402 contain a LABEL_REQUEST object or which does not have a session type 403 of LSP_Tunnel_IPv4, must send a PathErr towards the sender with the 404 error code `Diff-Serv TE Error' and an error value of `Unexpected 405 CLASSTYPE object'. Those are defined below in section 4.5. 407 An LSR receiving a Path message with the CLASSTYPE object, which 408 recognizes the CLASSTYPE object but does not support the particular 409 Class-Type, must send a PathErr towards the sender with the error 410 code `Diff-Serv TE Error' and an error value of `Unsupported Class- 411 Type'. Those are defined below in section 4.5. 413 An LSR receiving a Path message with the CLASSTYPE object, which 414 recognizes the CLASSTYPE object but determines that the Class-Type 415 value is not valid (i.e. Class-Type value 0), must send a PathErr 416 towards the sender with the error code `Diff-Serv TE Error' and an 418 Le Faucheur et. al 8 419 error value of `Invalid Class-Type value'. Those are defined below 420 in section 4.5. 422 An LSR MUST handle the situations where the LSP can not be accepted 423 for other reasons than those already discussed in this section, in 424 accordance with [RSVP-TE] and [DIFF-MPLS] (e.g. a reservation is 425 rejected by admission control, a label can not be associated). 427 4.4. Non-support of the CLASSTYPE Object 429 An LSR that does not recognize the CLASSTYPE object Class-Num must 430 behave in accordance with the procedures specified in [RSVP] for an 431 unknown Class-Num whose format is 0bbbbbbb (i.e. it must send a 432 PathErr with the error code `Unknown object class' toward the 433 sender). 435 An LSR that recognizes the CLASSTYPE object Class-Num but does not 436 recognize the CLASSTYPE object C-Type, must behave in accordance 437 with the procedures specified in [RSVP] for an unknown C-type (i.e. 438 it must send a PathErr with the error code `Unknown object C-Type' 439 toward the sender). 441 In both situations, this causes the path set-up to fail. The sender 442 should notify management that a LSP cannot be established and 443 possibly might take action to retry reservation establishment 444 without the CLASSTYPE object. 446 4.5. Error Codes For Diff-Serv TE 448 In the procedures described above, certain errors must be reported 449 as a `Diff-Serv TE Error'. The value of the `Diff-Serv TE Error' 450 error code is (TBD). 452 The following defines error values for the Diff-Serv TE Error: 454 Value Error 456 1 Unexpected CLASSTYPE object 457 2 Unsupported Class-Type 458 3 Invalid Class-Type value 460 5. CR-LDP Extensions 462 CR-LDP, defined in [CR-LDP], is an extension to LDP, defined in 463 [LDP], for support of (aggregate) MPLS Traffic Engineering. In this 464 section we describe extensions to CR-LDP for support of Diff-Serv 465 Traffic Engineering on a per-Class-Type basis which meet the 466 requirements defined in [DIFF-TE-REQTS]. These extensions are in 467 addition to the extensions to LDP defined in [DIFF-MPLS] for support 468 of Diff-Serv over MPLS. They closely resemble the extensions to RSVP 469 defined in the previous section. 471 Le Faucheur et. al 9 472 Note that extensions of this section for support of Diff-Serv 473 Traffic Engineering are not applicable to LDP due to the fact that 474 LDP does not support MPLS Traffic Engineering and bandwidth 475 reservation in particular. 477 5.1. Diff-Serv related CR-LDP Messages Encoding 479 One new CR-LDP TLV is defined in this document: the Class Type TLV. 480 Detailed description of this TLV is provided below. This new TLV is 481 applicable to Label Request messages. 483 Restrictions defined in [CR-LDP] for support of establishment of 484 LSPs via CR-LDP are also applicable to the establishment of LSPs 485 supporting Diff-Serv Traffic Engineering: for instance, only unicast 486 LSPs are supported and multicast LSPs are for further study. 488 This new Class Type TLV is optional with respect to CR-LDP so that 489 general CR-LDP implementations not concerned with per-Class-Type 490 Diff-Serv Traffic Engineering do not have to support this TLV. 492 An LSR supporting Diff-Serv Traffic Engineering on a per-Class-Type 493 basis in compliance with this specification MUST support the Class 494 Type TLV. It MUST support Class-Type value 1, and MAY support other 495 Class-Type values. 497 5.1.1. Label Request Message Encoding 499 The encoding for the CR-LDP Label Request message is extended as 500 follows, to optionally include the Class Type TLV: 501 0 1 2 3 502 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 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 |0| Label Request (0x0401) | Message Length | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Message ID | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | FEC TLV | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Diff-Serv TLV (LDP, optional) | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Class Type TLV (CR-LDP optional) | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Other CR-LDP TLVs | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 The extension is based on a related LDP extension, defined in [DIFF- 518 MPLS], for support of Diff-Serv TLV but further extended for CR-LDP 519 with CR-LDP TLVs. 521 5.2. Class Type TLV 523 Le Faucheur et. al 10 524 The Class Type TLV has the following form: 525 0 1 2 3 526 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 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 |0|0| Class Type TLV | Length | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Reserved |CT | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 Reserved : 30 bits 534 This field is reserved. It must be set to zero on transmission 535 and must be ignored on receipt. 537 CT : 2 bits 538 Indicates the Class-Type. Values currently allowed are 1, 2 and 539 3. 541 5.3. Handling Class Type TLV 543 To establish an LSP using CR-LDP, an ingress LSR generates a Label 544 Request message as per [CR-LDP]. This Label Request may optionally 545 include the Diff-Serv TLV as defined in [DIFF-MPLS] for LDP but 546 extended to CR-LDP. 548 If the LSP is associated with Class-Type 0, the ingress LSR must not 549 include the Class Type TLV in the Label Request message. 551 If the LSP is associated with Class-Type N (N=1,2,3), the ingress 552 LSR must include the Class Type TLV in the Label Request message 553 with the Class-Type (CT) field set to N. 555 [Editor's Note: additional options whereby the Class-Type could be 556 determined by the LSR without explicit Class-Type signaling are 557 investigated. For example, the Class-Type could be determined from 558 Diff-Serv information already signaled such as the PSC for an L-LSP 559 and using a PSC<-->Class-Type mapping locally configured ] 561 If a Label Request message contains multiple Class Type TLVs, only 562 the first one is meaningful; subsequent Class Type TLV(s) must be 563 ignored and not forwarded. 565 If the Class Type TLV is not present in the Label Request message, 566 an LSR must associate the Class-Type 0 to the LSP. 568 A downstream LSR sending a Label Mapping message in response to a 569 Label Request message must not include the Class-Type TLV (whether 570 the Class-Type TLV was included in the Label Request message or 571 not). 573 Le Faucheur et. al 11 574 During establishment of an LSP corresponding to the Class-Type N, an 575 LSR performs admission control over the bandwidth available for that 576 particular Class-Type, which is computed using the smallest of: 577 - the Class-Type N bandwidth currently unreserved (i.e. the 578 difference between the Maximum Reservable Bandwidth for Class- 579 Type N and the bandwidth reserved by existing Class-Type N 580 LSPs). 581 - the aggregate bandwidth currently unreserved (i.e. the 582 difference between the Maximum Reservable Aggregate Bandwidth 583 and the bandwidth reserved by existing LSPs of all Class-Types). 585 In order to accurately apportion the resources associated with a 586 Class-Type among the classes comprised in this Class-Type, an LSR 587 may automatically adjust Diff-Serv scheduling parameters associated 588 with a class within a Class-Type based on the bandwidth currently 589 reserved by LSPs currently established in that class. 591 An LSR that recognizes the Class Type TLV and receives a Label 592 Request message which contains the Class Type TLV but which does not 593 contain any of the CR-LDP TLVs, must reject the label request by 594 sending upstream a Notification message which includes the Status 595 TLV with a Status Code of 'Unexpected Class-Type TLV'. This is 596 defined below in section 5.4. This error can only occur when an LDP 597 LSP as opposed to CR-LDP LSP is being established. As was already 598 mentioned, Class Type TLV extension for Diff-Serv Traffic 599 Engineering is not applicable to LDP. 601 An LSR receiving a Label Request message with the Class Type TLV, 602 which recognizes the Class Type TLV but does not support the 603 particular Class-Type, must reject the label request by sending 604 upstream a Notification message which includes the Status TLV with a 605 Status Code of 'Unsupported Class-Type'. This is defined below in 606 section 5.4. 608 An LSR receiving a Label Request message with the Class Type TLV, 609 which recognizes the Class Type TLV but determines that the Class- 610 Type value is not valid (i.e. Class-Type value 0), must reject the 611 label request by sending upstream a Notification message which 612 includes the Status TLV with a Status Code of 'Invalid Class-Type 613 value'. This is defined below in section 5.4. 615 An LSR MUST handle the situations where the LSP can not be accepted 616 for other reasons than those already discussed in this section, in 617 accordance with [CR-LDP], [LDP] and [DIFF-MPLS] (e.g. reservation 618 rejected by admission control, a label can not be associated). 620 5.4. Status Code Values for Diff-Serv TE 622 In the procedures described above, certain errors must be reported. 623 The following values are defined for the Status Code field of the 624 Status TLV: 626 Le Faucheur et. al 12 627 Status Code E Status Data 629 Unexpected Class Type TLV 0 TBD 630 Unsupported Class-Type 0 TBD 631 Invalid Class-Type value 0 TBD 633 6. Security Considerations 635 This document raises no new security issues for IS-IS, OSPF, RSVP or 636 CR-LDP. The security mechanisms already proposed for these 637 technologies may be used. 639 7. Acknowledgments 641 This document has benefited from discussions with Carol Iturralde 642 and Rob Goguen. 644 References 646 [TE-REQ] Awduche et al, Requirements for Traffic Engineering over 647 MPLS, RFC2702, September 1999. 649 [TEWG-FW] Awduche et al, A Framework for Internet Traffic 650 Engineering, draft-ietf-tewg-framework-01.txt, May 2000. 652 [DIFF-TE-REQTS] Le Faucheur et al, Requirements for support of 653 Diff-Serv-aware MPLS Traffic Engineering, draft-lefaucheur-diff-te- 654 reqts-00.txt, July 2000. 656 [OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF, 657 draft-katz-yeung-ospf-traffic-01.txt, April 2000. 659 [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft- 660 ietf-isis-traffic-01.txt, May 1999. 662 [RSVP-TE] Awduche et al, "Extensions to RSVP for LSP Tunnels", 663 draft-ietf-mpls-rsvp-lsp-tunnel-05.txt, February 2000. 665 [DIFF-MPLS] Le Faucheur et al, "MPLS Support of Diff-Serv", draft- 666 ietf-mpls-diff-ext-05.txt, June 2000 668 [LDP] Andersson et al., "LDP Specification", draft-ietf-mpls-ldp- 669 06.txt, October 1999 671 [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", 672 draft-ietf-mpls-cr-ldp-03.txt, October 1999 674 Authors' Address: 676 Le Faucheur et. al 13 677 Francois Le Faucheur 678 Cisco Systems, Inc. 679 Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - 680 France 681 Phone: +33 4 92 96 75 64 682 Email: flefauch@cisco.com 684 Angela Chiu 685 AT&T Labs 686 Rm 4-204,100 Schulz Dr., Red Bank, NJ 07701 687 USA 688 Phone: +1 (732) 345-3441 689 Email: alchiu@att.com 691 William Townsend 692 Tenor Networks 693 100 Nagog Park 694 Acton, MA 01720 695 Phone: +1-978-264-4900 696 Email: btownsend@tenornetworks.com 698 Thomas D. Nadeau 699 Cisco Systems, Inc. 700 250 Apollo Drive 701 Chelmsford, MA 01824 702 Phone: +1-978-244-3051 703 Email: tnadeau@cisco.com 705 Darek Skalecki 706 Nortel Networks 707 3500 Carling Ave, 708 Nepean K2H 8E9 709 Phone: +1-613-765-2252 710 Email: dareks@nortelnetworks.com 712 Le Faucheur et. al 14