idnits 2.17.1 draft-ietf-mpls-diff-te-ext-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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 ([DIFF-TE-OSPF], [TEWG-FW], [DIFF-TE-ISIS], [DIFF-TE-REQTS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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.) -- The document date (February 2001) is 8443 days in the past. Is this intentional? 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 297, but not defined == Unused Reference: 'OSPF-TE' is defined on line 535, but no explicit reference was found in the text == Unused Reference: 'ISIS-TE' is defined on line 538, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2702 (ref. 'TE-REQ') == Outdated reference: A later version (-05) exists of draft-ietf-tewg-framework-02 ** Downref: Normative reference to an Informational draft: draft-ietf-tewg-framework (ref. 'TEWG-FW') == Outdated reference: A later version (-07) exists of draft-ietf-tewg-diff-te-reqts-00 ** Downref: Normative reference to an Informational draft: draft-ietf-tewg-diff-te-reqts (ref. 'DIFF-TE-REQTS') -- Possible downref: Normative reference to a draft: ref. 'DIFF-TE-OSPF' -- Possible downref: Normative reference to a draft: ref. 'DIFF-TE-ISIS' == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-03 == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-02 ** 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-07 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-diff-ext-08 -- No information found for draft-ietf-mpls-ldp-011 - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LDP' == Outdated reference: A later version (-06) exists of draft-ietf-mpls-cr-ldp-04 Summary: 10 errors (**), 0 flaws (~~), 11 warnings (==), 6 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 Celion Networks 8 William Townsend 9 Tenor Networks 11 Darek Skalecki 12 Nortel Networks 14 IETF Internet Draft 15 Expires: August, 2001 16 Document: draft-ietf-mpls-diff-te-ext-01.txt February 2001 18 Extensions to RSVP-TE 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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 40 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 41 "OPTIONAL" in this document are to be interpreted as described in 42 RFC 2119, reference [BCP14]. 44 Abstract 46 A companion document [DIFF-TE-REQTS] defines the requirements for 47 support of Diff-Serv-aware MPLS Traffic Engineering on a per-Class- 49 Le Faucheur, et. al 1 50 Extensions for Diff-Serv Traffic EngineeringFebruary 2001 52 Type basis, as discussed in the Traffic Engineering Working Group 53 Framework document [TEWG-FW]. 55 This document proposes corresponding extensions to RSVP-TE and CR- 56 LDP for support of Traffic Engineering on a per-Class-Type basis. 58 Two companion documents [DIFF-TE-OSPF] [DIFF-TE-ISIS] propose 59 corresponding extensions to OSPF and ISIS for support of Traffic 60 Engineering on a per-Class-Type basis. 62 1. Introduction 64 As Diff-Serv becomes prominent in providing scalable multi-class of 65 services in IP networks, performing traffic engineering at a per- 66 class level instead of an aggregated level is needed in networks 67 where fine optimisation of resources is sought in order to further 68 enhance performance and efficiency. By mapping a traffic trunk in a 69 given class on a separate LSP, it allows the traffic trunk to 70 utilize resources available on both shortest path(s) and non- 71 shortest path(s) and follow paths that meet constraints which are 72 specific to the given class. It also allows each class to select the 73 proper protection/restoration mechanism(s) that satisfy its 74 survivability requirements in a cost-effective manner. 76 Besides the set of parameters defined for the general aggregate TE 77 [TE-REQ], a new set of per-class parameters needs to be provided at 78 each LSR interface and propagated via extensions to the IGP 79 (ISIS/OSPF) [TEWG-FW]. Furthermore, the per-class parameters can be 80 aggregated into per-Class-Type parameters. The main motivation for 81 grouping a set of classes into a Class-Type is to improve the 82 scalability of the IGP link state advertisements by propagating 83 information on a per-Class-Type basis instead of on a per-class 84 basis. This approach also has the benefit of allowing better 85 bandwidth sharing between classes in the same Class-Type. 87 A Class-Type [TEWG-FW] is defined as a set of classes that satisfy 88 the following two conditions: 90 1) Classes in the same Class-Type possess common aggregate maximum 91 and minimum bandwidth requirements to guarantee the required 92 performance level. 94 2) There is no maximum or minimum bandwidth requirement to be 95 enforced at the level of an individual class within the Class- 96 Type. One can still implement some "priority" policies for 97 classes within the same Class-Type in terms of accessing the 98 Class-Type bandwidth (e.g. via the use of preemption 99 priorities). 101 Le Faucheur et. al 2 102 Extensions for Diff-Serv Traffic EngineeringFebruary 2001 104 An example of Class-Type comprising multiple Diff-Serv classes is a 105 low-loss Class-Type that includes both AF1-based and AF2-based 106 Ordering Aggregates. 108 Note that with per Class-Type TE, Constraint-Based Routing is 109 performed with bandwidth constraints on a per Class-Type basis but 110 LSPs may carry a single Diff-Serv class (Ordered Aggregate) with 111 Diff-Serv scheduling (i.e. PHB) performed separately for each class. 113 In this document, we will only discuss "per Class-Type TE" because 114 "per Class TE" can be viewed as a special case of per Class-Type TE 115 (where each Class-Type is degenerated into a single Diff-Serv 116 class). 118 This document focuses on intra-domain operations. Inter-domain 119 operations is for further study. 121 A companion document [DIFF-TE-REQTS] defines the requirements for 122 support of MPLS Traffic Engineering on a per-Class-Type basis. The 123 following sections propose detailed extensions to RSVP and CR-LDP 124 that meet those requirements. Two companion documents [DIFF-TE-OSPF] 125 and [DIFF-TE-ISIS] propose extensions to OSPF and ISIS that also 126 meet those requirements. 128 2. RSVP Extensions 130 In this section we describe extensions to RSVP for support of 131 Diff-Serv Traffic Engineering on a per-Class-Type basis which meet 132 the requirements defined in [DIFF-TE-REQTS]. These extensions are in 133 addition to the extensions to RSVP defined in [RSVP-TE] for support 134 of (aggregate) MPLS Traffic Engineering and to the extensions to 135 RSVP defined in [DIFF-MPLS] for support of Diff-Serv over MPLS. 137 2.1. Diff-Serv related RSVP Messages Format 139 One new RSVP Object is defined in this document: the CLASSTYPE 140 Object. Detailed description of this Object is provided below. This 141 new Object is applicable to Path messages. This specification only 142 defines the use of the CLASSTYPE Object in Path messages used to 143 establish LSP Tunnels in accordance with [RSVP-TE] and thus 144 containing a Session Object with a C-Type equal to LSP_TUNNEL_IPv4 145 and containing a LABEL_REQUEST object. 147 Restrictions defined in [RSVP-TE] for support of establishment of 148 LSP Tunnels via RSVP are also applicable to the establishment of LSP 149 Tunnels supporting Diff-Serv Traffic Engineering. For instance, only 150 unicast LSPs are supported and Multicast LSPs are for further study. 152 This new CLASSTYPE object is optional with respect to RSVP so that 153 general RSVP implementations not concerned with MPLS LSP set up do 154 not have to support this object. 156 Le Faucheur et. al 3 157 Extensions for Diff-Serv Traffic EngineeringFebruary 2001 159 An LSR supporting Diff-Serv Traffic Engineering on a per-Class-Type 160 basis in compliance with this specification MUST support the 161 CLASSTYPE Object. It MUST support Class-Type value 1, and MAY 162 support other Class-Type values. 164 2.1.1. Path Message Format 166 The format of the Path message is as follows: 168 ::= [ ] 169 170 171 [ ] 172 173 [ ] 174 [ ] 175 [ ] 176 [ ... ] 177 [ ] 179 ::= [ ] 180 [ ] 181 [ ] 183 2.2. CLASSTYPE Object 185 The CLASSTYPE object format is shown below. 187 2.2.1. CLASSTYPE object 189 class = TBD, C_Type = 1 (need to get an official class num from the 190 IANA with the form 0bbbbbbb) 192 0 1 2 3 193 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 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Reserved |CT | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 Reserved : 30 bits 199 This field is reserved. It must be set to zero on transmission 200 and must be ignored on receipt. 202 CT : 2 bits 203 Indicates the Class-Type. Values currently allowed are 1, 2 and 204 3. 206 2.3. Handling CLASSTYPE Object 208 Le Faucheur et. al 4 209 Extensions for Diff-Serv Traffic EngineeringFebruary 2001 211 To establish an LSP tunnel with RSVP, the sender LSR creates a Path 212 message with a session type of LSP_Tunnel_IPv4 and with a 213 LABEL_REQUEST object as per [RSVP-TE]. The sender LSR may also 214 include the DIFFSERV object as per [DIFF-MPLS]. 216 If the LSP is associated with Class-Type 0, the sender LSR must not 217 include the CLASSTYPE object in the Path message. 219 If the LSP is associated with Class-Type N (N=1,2,3), the sender LSR 220 must include the CLASSTYPE object in the Path message with the 221 Class-Type (CT) field set to N. 223 If a path message contains multiple CLASSTYPE objects, only the 224 first one is meaningful; subsequent CLASSTYPE object(s) must be 225 ignored and must not be forwarded. 227 Each LSR along the path records the CLASSTYPE object, when present, 228 in its path state block. 230 If the CLASSTYPE object is not present in the Path message, the LSR 231 must associate the Class-Type 0 to the LSP. 233 The destination LSR responds to the Path message by sending a Resv 234 message without a CLASSTYPE object (whether the Path message 235 contained a CLASSTYPE object or not). 237 During establishment of an LSP corresponding to the Class-Type N, 238 the LSR performs admission control over the bandwidth available for 239 that particular Class-Type, which is computed using the smallest of: 240 - the Class-Type N bandwidth currently unreserved (i.e. the 241 difference between the Maximum Reservable Bandwidth for Class- 242 Type N and the bandwidth reserved by existing Class-Type N 243 LSPs). 244 - the aggregate bandwidth currently unreserved (i.e. the 245 difference between the Maximum Reservable Aggregate Bandwidth 246 and the bandwidth reserved by existing LSPs of all Class-Types). 248 [Editor's Note: the admission control algorithm described in the 249 previous paragraph depends on the Bandwidth Reservation Scheme 250 discussed in section 2.1 of [DIFF-TE-REQTS] ] 252 In order to accurately apportion the resources associated with a 253 Class-Type among the classes comprised in this Class-Type, the LSR 254 may automatically adjust Diff-Serv scheduling parameters associated 255 with a class within a Class-Type based on the bandwidth currently 256 reserved by LSPs currently established in that class. 258 An LSR that recognizes the CLASSTYPE object and that receives a path 259 message which contains the CLASSTYPE object but which does not 260 contain a LABEL_REQUEST object or which does not have a session type 261 of LSP_Tunnel_IPv4, must send a PathErr towards the sender with the 263 Le Faucheur et. al 5 264 Extensions for Diff-Serv Traffic EngineeringFebruary 2001 266 error code `Diff-Serv TE Error' and an error value of `Unexpected 267 CLASSTYPE object'. Those are defined below in section 4.5. 269 An LSR receiving a Path message with the CLASSTYPE object, which 270 recognizes the CLASSTYPE object but does not support the particular 271 Class-Type, must send a PathErr towards the sender with the error 272 code `Diff-Serv TE Error' and an error value of `Unsupported Class- 273 Type'. Those are defined below in section 4.5. 275 An LSR receiving a Path message with the CLASSTYPE object, which 276 recognizes the CLASSTYPE object but determines that the Class-Type 277 value is not valid (i.e. Class-Type value 0), must send a PathErr 278 towards the sender with the error code `Diff-Serv TE Error' and an 279 error value of `Invalid Class-Type value'. Those are defined below 280 in section 4.5. 282 An LSR MUST handle the situations where the LSP can not be accepted 283 for other reasons than those already discussed in this section, in 284 accordance with [RSVP-TE] and [DIFF-MPLS] (e.g. a reservation is 285 rejected by admission control, a label can not be associated). 287 2.4. Non-support of the CLASSTYPE Object 289 An LSR that does not recognize the CLASSTYPE object Class-Num must 290 behave in accordance with the procedures specified in [RSVP] for an 291 unknown Class-Num whose format is 0bbbbbbb (i.e. it must send a 292 PathErr with the error code `Unknown object class' toward the 293 sender). 295 An LSR that recognizes the CLASSTYPE object Class-Num but does not 296 recognize the CLASSTYPE object C-Type, must behave in accordance 297 with the procedures specified in [RSVP] for an unknown C-type (i.e. 298 it must send a PathErr with the error code `Unknown object C-Type' 299 toward the sender). 301 In both situations, this causes the path set-up to fail. The sender 302 should notify management that a LSP cannot be established and 303 possibly might take action to retry reservation establishment 304 without the CLASSTYPE object. 306 2.5. Error Codes For Diff-Serv TE 308 In the procedures described above, certain errors must be reported 309 as a `Diff-Serv TE Error'. The value of the `Diff-Serv TE Error' 310 error code is (TBD). 312 The following defines error values for the Diff-Serv TE Error: 314 Value Error 316 1 Unexpected CLASSTYPE object 317 2 Unsupported Class-Type 319 Le Faucheur et. al 6 320 Extensions for Diff-Serv Traffic EngineeringFebruary 2001 322 3 Invalid Class-Type value 324 3. CR-LDP Extensions 326 CR-LDP, defined in [CR-LDP], is an extension to LDP, defined in 327 [LDP], for support of (aggregate) MPLS Traffic Engineering. In this 328 section we describe extensions to CR-LDP for support of Diff-Serv 329 Traffic Engineering on a per-Class-Type basis which meet the 330 requirements defined in [DIFF-TE-REQTS]. These extensions are in 331 addition to the extensions to LDP defined in [DIFF-MPLS] for support 332 of Diff-Serv over MPLS. They closely resemble the extensions to RSVP 333 defined in the previous section. 335 Note that extensions of this section for support of Diff-Serv 336 Traffic Engineering are not applicable to LDP due to the fact that 337 LDP does not support MPLS Traffic Engineering and bandwidth 338 reservation in particular. 340 3.1. Diff-Serv related CR-LDP Messages Encoding 342 One new CR-LDP TLV is defined in this document: the Class Type TLV. 343 Detailed description of this TLV is provided below. This new TLV is 344 applicable to Label Request messages. 346 Restrictions defined in [CR-LDP] for support of establishment of 347 LSPs via CR-LDP are also applicable to the establishment of LSPs 348 supporting Diff-Serv Traffic Engineering: for instance, only unicast 349 LSPs are supported and multicast LSPs are for further study. 351 This new Class Type TLV is optional with respect to CR-LDP so that 352 general CR-LDP implementations not concerned with per-Class-Type 353 Diff-Serv Traffic Engineering are not required to support this TLV. 355 An LSR supporting Diff-Serv Traffic Engineering on a per-Class-Type 356 basis in compliance with this specification MUST support the Class 357 Type TLV. It MUST support Class-Type value 1, and MAY support other 358 Class-Type values. 360 3.1.1. Label Request Message Encoding 362 The encoding for the CR-LDP Label Request message is extended as 363 follows, to optionally include the Class Type TLV: 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 |0| Label Request (0x0401) | Message Length | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Message ID | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | FEC TLV | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 Le Faucheur et. al 7 375 Extensions for Diff-Serv Traffic EngineeringFebruary 2001 377 | Diff-Serv TLV (LDP, optional) | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Class Type TLV (CR-LDP optional) | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Other CR-LDP TLVs | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 The extension is based on a related LDP extension, defined in [DIFF- 385 MPLS], for support of Diff-Serv TLV but further extended for CR-LDP 386 with CR-LDP TLVs. 388 3.2. Class Type TLV 390 The Class Type TLV has the following form: 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 |0|0| Class Type TLV | Length | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Reserved |CT | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 Reserved : 30 bits 400 This field is reserved. It must be set to zero on transmission 401 and must be ignored on receipt. 403 CT : 2 bits 404 Indicates the Class-Type. Values currently allowed are 1, 2 and 405 3. 407 3.3. Handling Class Type TLV 409 To establish an LSP using CR-LDP, an ingress LSR generates a Label 410 Request message as per [CR-LDP]. This Label Request may optionally 411 include the Diff-Serv TLV as defined in [DIFF-MPLS] for LDP but 412 extended to CR-LDP. 414 If the LSP is associated with Class-Type 0, the ingress LSR must not 415 include the Class Type TLV in the Label Request message. 417 If the LSP is associated with Class-Type N (N=1,2,3), the ingress 418 LSR must include the Class Type TLV in the Label Request message 419 with the Class-Type (CT) field set to N. 421 If a Label Request message contains multiple Class Type TLVs, only 422 the first one is meaningful; subsequent Class Type TLV(s) must be 423 ignored and not forwarded. 425 If the Class Type TLV is not present in the Label Request message, 426 an LSR must associate the Class-Type 0 to the LSP. 428 Le Faucheur et. al 8 429 Extensions for Diff-Serv Traffic EngineeringFebruary 2001 431 A downstream LSR sending a Label Mapping message in response to a 432 Label Request message must not include the Class-Type TLV (whether 433 the Class-Type TLV was included in the Label Request message or 434 not). 436 During establishment of an LSP corresponding to the Class-Type N, an 437 LSR performs admission control over the bandwidth available for that 438 particular Class-Type, which is computed using the smallest of: 439 - the Class-Type N bandwidth currently unreserved (i.e. the 440 difference between the Maximum Reservable Bandwidth for Class- 441 Type N and the bandwidth reserved by existing Class-Type N 442 LSPs). 443 - the aggregate bandwidth currently unreserved (i.e. the 444 difference between the Maximum Reservable Aggregate Bandwidth 445 and the bandwidth reserved by existing LSPs of all Class-Types). 447 [Editor's Note: the admission control algorithm described in the 448 previous paragraph depends on the Bandwidth Reservation Scheme 449 discussed in section 2.1 of [DIFF-TE-REQTS] ] 451 In order to accurately apportion the resources associated with a 452 Class-Type among the classes comprised in this Class-Type, an LSR 453 may automatically adjust Diff-Serv scheduling parameters associated 454 with a class within a Class-Type based on the bandwidth currently 455 reserved by LSPs currently established in that class. 457 An LSR that recognizes the Class Type TLV and receives a Label 458 Request message which contains the Class Type TLV but which does not 459 contain any of the CR-LDP TLVs, must reject the label request by 460 sending upstream a Notification message which includes the Status 461 TLV with a Status Code of 'Unexpected Class-Type TLV'. This is 462 defined below in section 5.4. This error can only occur when an LDP 463 LSP as opposed to CR-LDP LSP is being established. As was already 464 mentioned, Class Type TLV extension for Diff-Serv Traffic 465 Engineering is not applicable to LDP. 467 An LSR receiving a Label Request message with the Class Type TLV, 468 which recognizes the Class Type TLV but does not support the 469 particular Class-Type, must reject the label request by sending 470 upstream a Notification message which includes the Status TLV with a 471 Status Code of 'Unsupported Class-Type'. This is defined below in 472 section 5.4. 474 An LSR receiving a Label Request message with the Class Type TLV, 475 which recognizes the Class Type TLV but determines that the Class- 476 Type value is not valid (i.e. Class-Type value 0), must reject the 477 label request by sending upstream a Notification message which 478 includes the Status TLV with a Status Code of 'Invalid Class-Type 479 value'. This is defined below in section 5.4. 481 Le Faucheur et. al 9 482 Extensions for Diff-Serv Traffic EngineeringFebruary 2001 484 An LSR MUST handle the situations where the LSP can not be accepted 485 for other reasons than those already discussed in this section, in 486 accordance with [CR-LDP], [LDP] and [DIFF-MPLS] (e.g. reservation 487 rejected by admission control, a label can not be associated). 489 3.4. Status Code Values for Diff-Serv TE 491 In the procedures described above, certain errors must be reported. 492 The following values are defined for the Status Code field of the 493 Status TLV: 495 Status Code E Status Data 497 Unexpected Class Type TLV 0 TBD 498 Unsupported Class-Type 0 TBD 499 Invalid Class-Type value 0 TBD 501 4. Security Considerations 503 This document raises no new security issues for IS-IS, OSPF, RSVP or 504 CR-LDP. The security mechanisms already proposed for these 505 technologies may be used. 507 5. Acknowledgments 509 This document has benefited from discussions with Carol Iturralde 510 and Rob Goguen. 512 References 514 [TE-REQ] Awduche et al, Requirements for Traffic Engineering over 515 MPLS, RFC2702, September 1999. 517 [TEWG-FW] Awduche et al, A Framework for Internet Traffic 518 Engineering, draft-ietf-tewg-framework-02.txt, July 2000. 520 [DIFF-TE-REQTS] Le Faucheur et al, Requirements for support of 521 Diff-Serv-aware MPLS Traffic Engineering, draft-ietf-tewg-diff-te- 522 reqts-00.txt, February 2001. 524 [DIFF-TE-OSPF] Le Faucheur et al, Extension to OSPF for support of 525 Diff-Serv-aware MPLS Traffic Engineering, draft-ietf-ospf-diff-te- 526 00.txt, February 2001. 528 [DIFF-TE-ISIS] Le Faucheur et al, Extension to ISIS for support of 529 Diff-Serv-aware MPLS Traffic Engineering, draft-ietf-isis-diff-te- 530 00.txt, February 2001. 532 Le Faucheur et. al 10 533 Extensions for Diff-Serv Traffic EngineeringFebruary 2001 535 [OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF, 536 draft-katz-yeung-ospf-traffic-03.txt, September 2000. 538 [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft- 539 ietf-isis-traffic-02.txt, September 2000. 541 [RSVP-TE] Awduche et al, "Extensions to RSVP for LSP Tunnels", 542 draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, August 2000. 544 [DIFF-MPLS] Le Faucheur et al, "MPLS Support of Diff-Serv", draft- 545 ietf-mpls-diff-ext-08.txt, February 2001 547 [LDP] Andersson et al., "LDP Specification", draft-ietf-mpls-ldp- 548 011.txt, August 2000 550 [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", 551 draft-ietf-mpls-cr-ldp-04.txt, July 2000 553 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 554 Requirement Levels", BCP 14, RFC 2119, March 1997. 556 Authors' Address: 558 Francois Le Faucheur 559 Cisco Systems, Inc. 560 Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - 561 France 562 Phone: +33 4 92 96 75 64 563 Email: flefauch@cisco.com 565 Angela Chiu 566 Celion Networks 567 1 Sheila Drive, Suite 2 568 Tinton Falls, NJ 07724 569 Phone: +1-732 747 9987 570 Email: angela.chiu@celion.com 572 William Townsend 573 Tenor Networks 574 100 Nagog Park 575 Acton, MA 01720 576 Phone: +1-978-264-4900 577 Email: btownsend@tenornetworks.com 579 Thomas D. Nadeau 580 Cisco Systems, Inc. 581 250 Apollo Drive 582 Chelmsford, MA 01824 583 Phone: +1-978-244-3051 584 Email: tnadeau@cisco.com 586 Le Faucheur et. al 11 587 Extensions for Diff-Serv Traffic EngineeringFebruary 2001 589 Darek Skalecki 590 Nortel Networks 591 3500 Carling Ave, 592 Nepean K2H 8E9 593 Phone: +1-613-765-2252 594 Email: dareks@nortelnetworks.com 596 Le Faucheur et. al 12