idnits 2.17.1 draft-ietf-mpls-rsvpte-attributes-02.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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 1) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. 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.) -- The document date (January 2004) is 7407 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) -- Looks like a reference, but probably isn't: '6' on line 190 == Unused Reference: 'RFC2119' is defined on line 705, but no explicit reference was found in the text == Unused Reference: 'INTER-AS' is defined on line 733, but no explicit reference was found in the text == Unused Reference: 'OSPF-CAPS' is defined on line 741, but no explicit reference was found in the text == Unused Reference: 'REOPT' is defined on line 746, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Adrian Farrel (Editor) 2 Internet Draft Old Dog Consulting 3 Category: Standards Track 4 Expires: July 2004 Dimitri Papadimitriou 5 Alcatel 7 Jean-Philippe Vasseur 8 Cisco Systems, Inc. 10 Arthi Ayyangar 11 Juniper Networks 13 January 2004 15 Encoding of Attributes for Multiprotocol Label Switching (MPLS) 16 Label Switched Path (LSP) Establishment Using RSVP-TE 18 draft-ietf-mpls-rsvpte-attributes-02.txt 20 Status of this Memo 22 This document is an Internet-Draft and is in full conformance 23 with all provisions of Section 10 of RFC 2026 [RFC2026]. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that other 27 groups may also distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 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. 37 The list of Internet-Draft Shadow Directories can be 38 accessed at http://www.ietf.org/shadow.html. 40 Abstract 42 Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may 43 be established using the Resource Reservation Protocol Traffic 44 Engineering extensions (RSVP-TE). This protocol includes an object 45 (the SESSION_ATTRIBUTE object) which carries a flags field used to 46 indicate options and attributes of the LSP. That flags field has 47 eight bits allowing for eight options to be set. Recent proposals in 48 many documents that extend RSVP-TE have suggested uses for each of 49 the previously unused bits. 51 This document defines a new object for RSVP-TE messages that allows 52 the signaling of further attribute bits and also the carriage of 53 arbitrary attribute parameters to make RSVP-TE easily extensible to 54 support new requirements. Additionally, this document defines a way 55 to record the attributes applied to the LSP on a hop-by-hop basis. 57 The object mechanisms defined in this document are equally applicable 58 to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to 59 GMPLS non-PSC LSPs. 61 0. Change History 63 This section to be removed before publication. 65 0.1 Changes from 01 to 02 Version 67 - Minor typographical changes. 69 0.2 Changes from 00 to 01 Version 71 - Change Attributes Flags TLV to be variable length so that more bits 72 can easily be added in the future. 73 - Define default behaviors for bits absent from the TLV and for 74 absence of the TLV. 75 - Clarify the IANA requirements for tracking Attributes Flags bits. 76 - Introduce RRO Attibutes Subobject and describe usage. 77 - Move Fast Reroute reference to informational. 78 - Update security considerations to handle new RRO subobject 79 - Remove section that explained the need for this document in 80 advance of any definitive bit definitions. 81 - Tighten rules for processing LSP_ATTRIBUTES object in cases where 82 TLVs are unknown or unsupported. 83 - Clarify that LSP Attributes apply to individual LSPs and not to 84 entire sessions. 86 1. Introduction and Problem Statement 88 Traffic Engineered Multiprotocol Label Switching (MPLS) Label 89 Switched Paths (LSPs) [RFC3031] may be set up using the Path message 90 of the RSVP-TE signaling protocol [RFC3209]. The Path message 91 includes the SESSION_ATTRIBUTE object which carries a flags field 92 used to indicate desired options and attributes of the LSP. 94 The flags field in the SESSION_ATTRIBUTE object has eight bits. Just 95 three of those bits are assigned in [RFC3209]. A further two bits are 96 assigned in [FRR] for fast re-reroute functionality leaving only 97 three bits available. Several recent proposals and Internet Drafts 98 have demonstrated that there is a high demand for the use of the 99 other three bits. Some, if not all, of those proposals are likely to 100 go forward as RFCs resulting in depletion or near depletion of the 101 flags field and a consequent difficulty in signaling new options and 102 attributes that may be developed in the future. 104 This document defines a new object for RSVP-TE messages that allows 105 the signaling of further attributes bits. The new object is 106 constructed from TLVs, and a new TLV is defined to carry a variable 107 number of attributes bits. Because of the nature of the TLV 108 construction the object is flexible and allows the future definition 109 of: 110 - further bit flags if further, distinct uses are discovered 111 - arbitrary options and attributes parameters carried as individual 112 TLVs. 114 Note that the LSP Attributes defined in this document are 115 specifically scoped to an LSP. They may be set differently on 116 separate LSPs with the same Tunnel ID between the same source and 117 destination (that is, within the same Session). 119 It is noted that that some options and attributes do not need to be 120 acted on by all Label Switched Routers (LSRs) along the path of the 121 LSP. In particular, these options and attributes may apply only to 122 key LSRs on the path such as the ingress and egress. Special transit 123 LSRs, such as area or AS Border Routers (ABR/ASBRs) may also fall 124 into this category. This means that the new options and attributes 125 should be signaled transparently, and only examined at those points 126 that need to act on them. 128 On the other hand, other options and attributes may require action 129 at all transit LSRs along the path of the LSP. Inability to support 130 the required attributes by one of those transit LSRs may require the 131 LSR to refuse the establishment of the LSP. 133 These considerations are particularly important in the context of 134 backwards compatibility. In general, it should be possible to provide 135 new MPLS services across a legacy network without upgrading those 136 LSRs that do not need to participate actively in the new services. 138 Note that options already specified for the SESSION_ATTRIBUTE object 139 in pre-existing RFCs are not migrated to the new mechanisms described 140 in this documnet. 142 RSVP includes a way for unrecognized objects to be transparently 143 forwarded by transit nodes without them refusing the incoming 144 protocol messages and with the objects being stripped from the 145 outgoing protocol message (see [RFC2205] section 3.10). This 146 capability extends to RSVP-TE and provides a good way to ensure that 147 only those LSRs that understand a particular object examine it. 149 This document distinguishes between options and attributes that are 150 only required at key LSRs along the path of the LSP, and those that 151 must be acted on by every LSR along the LSP. Two LSP Attributes 152 objects are defined in this document: the first may be passed 153 transparently by LSRs that do not recognize it, the second must cause 154 LSP setup failure with the generation of a PathErr message with an 155 appropriate Error Code if an LSR does not recognize it. 157 1.1 Applicability to Generalized MPLS 159 The RSVP-TE signaling protocol also forms the basis of a signaling 160 protocol for Generalized MPLS (GMPLS) as described in [RFC3471] and 161 [RFC3473]. The extensions described in this document are intended to 162 be equally applicable to MPLS and GMPLS. 164 1.2 A Rejected Alternate Solution 166 A rejected alternate solution was to define a new C-Type for the 167 existing SESSION_ATTRIBUTE object. This new C-Type could allow a 168 larger Flags field and address the immediate problem. 170 This solution was rejected because: 171 - A new C-Type is not backward compatible with deployed 172 implementations that expect to see a C-Type of 1 or 7. It is 173 important that any solution be capable of carrying new attributes 174 transparently across legacy LSRs if those LSRs are not required to 175 act on the attributes. 177 - Support for arbitrary attributes parameters through TLVs would 178 have meant a significant change of substance to the existing 179 object. 181 2. Terminology 183 This document uses terminology from the MPLS architecture document 184 [RFC3031] and from the RSVP-TE protocol specification [RFC3209] which 185 inherits from the RSVP specification [RFC2205]. 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 189 document are to be interpreted as described in RFC2119 [6]. 191 3. Attributes TLVs 193 Attributes carried by the new objects defined in this document are 194 encoded within TLVs. One or more TLVs may be present in each object. 195 There are no ordering rules for TLVs and no interpretation should be 196 placed on the order in which TLVs are received. 198 Each TLV is encoded as follows. 200 0 1 2 3 201 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 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Type | Length | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | | 206 // Value // 207 | | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 Type 212 The identifier of the TLV. 214 Length 216 The length of the value field in bytes. Thus if no value 217 field is present the length field contains the value zero. 218 Each value field must be zero padded at the end to take it 219 up to a four byte boundary - the padding is not included in 220 the length so that a one byte value would be encoded in an 221 eight byte TLV with length field set to one. 223 Value 225 The data for the TLV padded as described above. 227 3.1 Attributes Flags TLV 229 This document defines only one TLV type value. Type 1 indicates the 230 Attributes Flags TLV. Other TLV types may be defined in future with 231 type values assigned by IANA. 233 The Attributes Flags TLV may be present in an LSP_ATTRIBUTES object 234 and/or an LSP_REQUIRED_ATTRIBUTES object. The bits in the TLV 235 represent the same attributes regardless of which object carries the 236 TLV. Documents that define individual bits MUST specify whether the 237 bit may be set in one object or the other, or both. It is not 238 expected that a bit will be set in both objects on a single Path 239 message at the same time, but this is not ruled out by this document. 241 The Attributes Flags TLV value field is a variable length array of 242 flags numbered from the MSB as bit zero. The length field for this 243 TLV is always a multiple of 4 bytes, regardless of the number bits 244 carried. 246 Unassigned bits are considered as reserved and MUST be set to zero 247 on transmission by the originator of the object. Bits not contained in the 248 TLV MUST be assumed to be set to zero. If the TLV is absent either 249 because it is not contained in the LSP_ATTRIBUTES or LSP_REQUIRED_ 250 ATTRIBUTES object, or because those objects are themselves absent, 251 all processing MUST be performed as though the bits were present 252 and set to zero. 254 No bits are defined in this document. The assignment of bits is 255 managed by IANA. 257 4. LSP_ATTRIBUTES Object 259 The LSP_ATTRIBUTES object is used to signal attributes required in 260 support of an LSP, or to indicate the nature or use of an LSP where 261 that information is not required to be acted on by all transit LSRs. 262 Specifically, if an LSR does not support the object, it forwards it 263 unexamined and unchanged. This facilitates the exchange of attributes 264 across legacy networks that do not support this new object. 266 This object effectively extends the flags field in the SESSION_ 267 ATTRIBUTE object and allows for the future inclusion of more complex 268 objects through TLVs. 270 Note that some function may require an LSR to inspect both the 271 SESSION_ATTRIBUTE object, and the LSP_ATTRIBUTES or 272 LSP_REQUIRED_ATTIBUTES object. 274 The LSP_ATTRIBUTES object class is TBD of the form 11bbbbbb. This 275 C-Num value (see section 7) ensures that LSRs that do not recognize 276 the object pass it on transparently. 278 One C-Type is defined, C-Type = 1 for LSP Attributes. 280 This object is optional and may be placed on Path messages to convey 281 additional information about the desired attributes of the LSP. 283 4.1 Format 285 LSP_ATTRIBUTES class = TBD, C-Type = 1 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | | 291 // Attributes TLVs // 292 | | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 The Attributes TLVs are encoded as described in section 3. 297 4.2 Generic Processing Rules 299 An LSR that does not support this object will pass it on unaltered 300 because of the C-Num. 302 An LSR that does support this object, but does not recognize a TLV 303 type code carried in this object MUST pass the TLV on unaltered 304 in the LSP_ATTRIBUTES object that it places in the Path message 305 that it sends downstream. 307 An LSR that does support this object and recognizes a TLV but does 308 not support the attribute defined by the TLV MUST act as specified in 309 the document that defines the TLV. 311 An LSR that supports the Attributes Flags TLV, but does not 312 recognize a bit set in the Attributes Flags TLV MUST forward the 313 TLV unchanged. 315 An LSR that supports the Attributes Flags TLV and recognizes a bit 316 that is set but does not support the indicated attribute MUST act as 317 specified in the document that defines the bit. 319 5. LSP_REQUIRED_ATTRIBUTES Object 321 The LSP_REQUIRED_ATTRIBUTES object is used to signal attributes 322 required in support of an LSP, or to indicate the nature or use of 323 an LSP where that information MUST be inspected at each transit LSR. 324 Specifically, each transit LSR MUST examine the attributes in the 325 LSP_REQUIRED_ATTRIBUTES object and MUST NOT forward the object 326 transparently. 328 This object effectively extends the flags field in the SESSION_ 329 ATTRIBUTE object and allows for the future inclusion of more complex 330 objects through TLVs. It complements the LSP_ATTRIBUTES object. 332 The LSP_REQUIRED_ATTRIBUTES object class is TBD of the form 0bbbbbbb. 333 This C-Num value ensures that LSRs that do not 334 recognize the object reject the LSP setup effectively saying that 335 they do not support the attributes requested. This means that this 336 object SHOULD only be used for attributes that require support at 337 some transit LSRs and so require examination at all transit LSRs. See 338 section 4 for how end-to-end and selective attributes are signaled. 340 One C-Type is defined, C-Type = 1 for LSP Required Attributes. 342 This object is optional and may be placed on Path messages to convey 343 additional information about the desired attributes of the LSP. 345 5.1 Format 347 LSP_REQUIRED_ATTRIBUTES class = TBD, C-Type = 1 349 0 1 2 3 350 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 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | | 353 // Attributes TLVs // 354 | | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 The Attributes TLVs are encoded as described in section 3. 359 5.2 Generic Processing Rules 361 An LSR that does not support this object will use a PathErr to reject 362 the Path message based on the C-Num using the error code "Unknown 363 Object Class". 365 An LSR that does not recognize a TLV type code carried in this object 366 MUST reject the Path message using a PathErr with Error Code 367 "Unknown Attributes TLV" and Error Value set to the value of the 368 unknown TLV type code. 370 An LSR that does not recognize a bit set in the Attributes Flags 371 TLV MUST reject the Path message using a PathErr with Error Code 372 "Unknown Attributes Bit" and Error Value set to the bit number of 373 the unknown bit in the Attributes Flags. 375 An LSR that recognizes an attribute, however encoded, but which does 376 not support that attribute MUST act according to the behavior 377 specified in the document that defines that specific attribute. 379 6. Recording Attributes 381 6.1 Requirements 383 In some circumstances it is useful to determine which of the 384 requested LSP attributes have been applied at which LSRs along the 385 path of the LSP. For example, an attribute may be requested in the 386 LSP_ATTRIBUTES object such that LSRs that do not support the object 387 are not required to support the attribute or provide the requested 388 function. In this case, it may be useful to the ingress LSR to know 389 which LSRs acted on the request and which ignored it. 391 Additionally, there may be other qualities that need to be reported 392 on a hop-by-hop basis. These are currently indicated in the Flags 393 field of RRO subobjects. Since there are only eight bits available 394 in this field, and since some are already assigned and there is also 395 likely to be an increase in allocations in new documents, there is a 396 need for some other method to report per-hop attributes. 398 6.2 RRO Attributes Subobject 400 The RRO Attributes Subobject may be carried in the RECORD_ROUTE 401 object if it is present. The subobject uses the standard format of 402 an RRO subobject. 404 The length is variable as for the Attributes Flags TLV. The content 405 is the same as the Attribute Flags TLV - that is, it is a series of 406 bit flags. 408 There is a one-to-one correspondance between bits in the Attributes 409 Flags TLV and the RRO Attributes Subobject. If a bit is only required 410 in one of the two places, it is reserved in the other place. See 411 the procedures sections, below, for more information. 413 0 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Type | Length | Reserved | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | | 419 // Attribute Flags // 420 | | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 Type 425 0x?? TBD RRO Attribute Subobject 427 Length 429 The Length contains the total length of the subobject in bytes, 430 including the Type and Length fields. This length must be a 431 multiple of 4 and must be at least 8. 433 Attribute Flags 435 The attribute flags recorded for the specific hop. 437 6.3 Procedures 439 6.3.1 Subobject Presence Rules 441 The Attributes subobject is pushed onto the RECORD_ROUTE object 442 immediately prior to pushing the node's IP address or link 443 identifier. Thus, if label recording is being used, the Attributes 444 subobject SHOULD be pushed onto the RECORD_ROUTE object after the 445 Record Label subobject(s). 447 A node MUST NOT push an Attributes subobject on to the RECORD_ROUTE 448 object without also pushing an IPv4, IPv6 or Unnumbered Interface ID 449 subobject. 451 This means that an Attributes subobject is bound to the LSR 452 identified by the subobject found in the RRO immediately before the 453 Attributes subobject. 455 If the new subobject causes the RRO to be too big to fit in a Path 456 (or Resv) message, the processing MUST be as described in [RFC3209]. 458 If more than one Attributes subobject is found between a pair of 459 subobjects that identify LSRs, only the first one found (that is, the 460 nearest to the stop of the stack) SHALL have any meaning within the 461 context of this document. All such subobjects MUST be forwarded 462 unmodified by transit LSRs. 464 6.3.2 Reporting Compliance with LSP Attributes 466 To report compliance with an attribute requested in the Attributes 467 Flags TLV, an LSR MAY set the corresponding bit (see section 7) in 468 the Attributes subobject. To report non-compliance, an LSR MAY clear 469 the corresponding bit in the Attributes subobject. 471 The requirement to report compliance MUST be specified in the 472 document that defines the usage of any bit. This will reduce to a 473 statement of whether hop-by-hop acknowledgement is required. 475 6.3.3 Reporting Per-Hop Attributes 477 To report a per-hop attribute, an LSR sets the appropriate bit in the 478 Attributes subobject. 480 The requirement to report a per-hop attribute MUST be specified in 481 the document that defines the usage of the bit. 483 6.3.4 Default Behavior 485 By default all bits in an Attibutes subobject SHOULD be set to zero. 487 If a received Attribute subobject is not long enough to include a 488 specific numbered bit, that bit MUST be treated as though present and 489 as if set to zero. 491 If the RRO subobject is not present for a hop in the LSP, all bits 492 MUST be assumed to be set to zero. 494 7. Summary of Attribute Bit Allocation 496 This document defines two uses of per-LSP attribute flag bit fields. 497 The bit numbering in the Attributes Flags TLV and the RRO Attributes 498 subobject is identical. That is, the same attribute is indicated by 499 the same bit in both places. This means that only a single registry 500 of bits is maintained. 502 The consequence is a degree of clarity in implementation and 503 registration. 505 Note, however, that it is not always the case that a bit will be used 506 in both the Attributes Flags TLV and the RRO Attributes subobject. 507 For example, an attribute may be requested using the Attributes Flags 508 TLV, but there is no requirement to report the handling of the 509 attribute on a hop-by-hop basis. Conversely, there may be a 510 requirement to report the attributes of an LSP on a hop-by-hop basis, 511 but there is no corresponding request attribute. 513 In these cases, a single bit number is still assigned for both the 514 Attributes Flags TLV and the RRO Attributes subobject even though the 515 bit may be irrelevant in either the Attributes Flags or the RRO 516 Attributes subobject. The document that defines the usage of the new 517 bit MUST state in which places it is used and MUST handle a default 518 setting of zero. 520 8. Message Formats 522 The LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES object MAY 523 be carried in a Path message. 525 The order of objects in RSVP-TE messages is recommended, but 526 implementations must be capable of receiving the objects in any 527 meaningful order. The LSP_ATTRIBUTES object and LSP_REQUIRED_ 528 ATTRIBUTES objects are RECOMMENDED to be placed immediately after the 529 SESSION_ATTRIBUTE object if it is present, or otherwise immediately 530 after the LABEL_REQUEST object. 532 If both the LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES 533 object are present, the LSP_REQUIRED_ATTRIBUTES object is RECOMMENDED 534 to be placed first. 536 LSRs SHOULD be prepared to receive these objects in any order in any 537 position within a Path message. Subsequent instances of these objects 538 within a Path message SHOULD be ignored and those objects MUST be 539 forwarded unchanged transparently. 541 9. IANA Considerations 543 9.1 New RSVP C-Nums and C-Types 545 Two new RSVP C-Nums are defined in this document and should be 546 assigned by IANA. 548 o LSP_ATTRIBUTES object 550 The C-Num should be of the form 11bbbbbb so that LSRs that do not 551 recognize the object will ignore the object but forward it, 552 unexamined and unmodified, in all messages resulting from this 553 message. 555 One C-Type is defined for this object and should be assigned by 556 IANA. 558 o LSP Attributes TLVs 560 Recommended C-Type value 1. 562 o LSP_REQUIRED_ATTRIBUTES object 564 The C-Num should be of the form 0bbbbbbb so that LSRs that do not 565 recognize the object will reject the message that carries it with 566 an "Unknown Object Class" error. 568 One C-Type is defined for this object and should be assigned by 569 IANA. 571 o LSP Required Attributes TLVs 573 Recommended C-Type value 1. 575 9.2 New TLV Space 577 The two new objects referenced above are constructed from TLVs. Each 578 TLV includes a 16-bit type identifier (the T-field). The same T-field 579 values are applicable to both objects. 581 IANA is requested to manage TLV type identifiers as follows: 583 - TLV Type (T-field value) 584 - TLV Name 585 - Whether allowed on LSP_ATTRIBUTES object 586 - Whether allowed on LSP_REQUIRED_ATTRIBUTES object. 588 This document defines one TLV type as follows: 589 - TLV Type = 1 590 - TLV Name = Attributes Flags TLV 591 - allowed on LSP_ATTRIBUTES object 592 - allowed on LSP_REQUIRED_ATTRIBUTES object. 594 9.3 Attributes Flags 596 This document provides new attributes bit flags for use in other 597 documents that specify new RSVP-TE attributes. These flags are 598 present in the Attributes Flags TLV referenced in the previous 599 section. 601 IANA is requested to manage the space of attributes bit flags 602 numbering them in the usual IETF notation starting at zero and 603 continuing through 2039. 605 Each bit should be tracked with the following qualities: 606 - Bit number 607 - Defining RFC 608 - Name of bit 609 - Whether there is meaning in the Attibute Flags TLV (yes/no) 610 - Whether there is meaning in the RRO Attributes Subobject (yes/no). 612 Note that this means that all bits in the Attribute Flags TLV and the 613 RRO Attributes Subobject use the same bit number regardless of 614 whether they are used in one or both places. Thus, only one list of 615 bits is required to be maintained. (It would be meaningless in the 616 context of this document for a bit to have no meaning in neither the 617 Attribute Flags TLV nor the RRO Attributes Subobject.) 619 9.4 SESSION_ATTRIBUTE Flags Field 621 This document does not make any alterations to the definition of the 622 existing SESSION_ATTRIBUTE object nor to the definition of meanings 623 assigned to the flags in the Flags field of that object. These flags 624 are assigned meanings in various other RFCs and Internet Drafts. 626 It is suggested that IANA manage the allocation of meaning to the 627 bits in the Flags field of the SESSION_ATTRIBUTE object to prevent 628 accidental double allocation of any one bit. 630 9.5 New Error Codes 632 This document defines the following new error codes and error values. 633 Numeric values should be assigned by IANA. 635 Error Code Error Value 636 "Unknown Attributes TLV" Identifies the unknown TLV type code. 637 "Unknown Attributes Bit" Identifies the unknown Attribute Bit. 639 9.6 New Record Route Subobject Identifier 641 A new subobject is defined for inclusion in the RECORD_ROUTE object. 643 The RRO Attributes subobject is identified by a Type value of TBD. 645 10. Security Considerations 647 This document adds two new objects to the RSVP Path message as used 648 in MPLS and GMPLS signaling, and a new subobject to the RECORD_ROUTE 649 object carried on may RSVP messages. It does not introduce any new 650 direct security issues and the reader is referred to the security 651 considerations expressed in [RFC2205], [RFC3209] and [RFC3473]. 653 It is of passing note that any signaling request that indicates the 654 functional preferences or attributes of an MPLS LSP may provide 655 anyone with unauthorized access to the contents of the message with 656 information about the LSP that an administrator may wish to keep 657 secret. Although this document adds new objects for signaling desired 658 LSP attributes, it does not contribute to this issue which can 659 only be satisfactorily handled by encrypting the content of the 660 signaling message. 662 Similarly, the addition of attribute recording information to the 663 RRO may reveal information about the status of the LSP and the 664 capabilities of individual LSRs that operators wish to keep secret. 665 The same strategy that applies to other RRO subobjects also applies 666 here. Note, however, that there is a tension between notifying the 667 head end of the LSP status at transit LSRs, and hiding the existence 668 or identity of the transit LSRs. 670 11. Acknowledgements 672 Credit to the OSPF Working Group for inspiration from their solution 673 to a similar problem. 675 Thanks to Rahul Aggarwal for his careful review and support of this 676 work. Thanks also to Raymond Zhang, Kireeti Kompella, Philip Matthews 677 and Jim Gibson for their input. 679 12. Intellectual Property Consideration 681 The IETF takes no position regarding the validity or scope 682 of any intellectual property or other rights that might be 683 claimed to pertain to the implementation or use of the 684 technology described in this document or the extent to 685 which any license under such rights might or might not be 686 available; neither does it represent that it has made any 687 effort to identify any such rights. Information on the 688 IETF's procedures with respect to rights in standards-track 689 and standards-related documentation can be found in BCP-11. 690 Copies of claims of rights made available for publication 691 and any assurances of licenses to be made available, or the 692 result of an attempt made to obtain a general license or 693 permission for the use of such proprietary rights by 694 implementors or users of this specification can be obtained 695 from the IETF Secretariat. 697 The IETF invites any interested party to bring to its 698 attention any copyrights, patents or patent applications, or 699 other proprietary rights which may cover technology that may 700 be required to practice this standard. Please address the 701 information to the IETF Executive Director. 703 13. Normative References 705 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 706 Requirement Levels", BCP 14, RFC 2119, March 1997. 708 [RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. 709 and S. Jamin, "Resource ReserVation Protocol -- 710 Version 1 Functional Specification", RFC 2205, 711 September 1997. 713 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., 714 Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions 715 to RSVP for LSP Tunnels", RFC 3209, December 2001. 717 [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label 718 Switching (GMPLS) Signaling Functional Description", 719 RFC 3471, January 2003. 721 [RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling - 722 RSVP-TE Extensions", RFC 3473 January 2003. 724 14. Informative References 726 [RFC2026] Bradner, S., "The Internet Standards Process 727 -- Revision 3", RFC 2026, October 1996. 729 [RFC3031] Rosen, E., Viswanathan, A., and Callon, R., 730 "Multiprotocol Label Switching 731 Architecture", RFC 3031, January 2001. 733 [INTER-AS] Vasseur, JP., Zhang, R., "Inter-AS MPLS Traffic 734 Engineering", , 735 Internet Draft, work in progress. 737 [FRR] Pan, P. (Ed.), "Fast Reroute Extensions to RSVP-TE for 738 LSP Tunnels", , Internet Draft, work in progress. 741 [OSPF-CAPS] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., 742 Vasseur, JP., "Extensions to OSPF for Advertising 743 Optional Router Capabilities", , Internet Draft, work in progress. 746 [REOPT] Vasseur, JP., Ikejiri, Y., "Reoptimization of MPLS 747 Traffic Engineering loosely routed explicit LSP path", 748 , Internet 749 Draft, work in progress. 751 15. Authors' Addresses 753 Adrian Farrel 754 Old Dog Consulting 755 Phone: +44 (0) 1978 860944 756 EMail: adrian@olddog.co.uk 758 Dimitri Papadimitriou (Alcatel) 759 Fr. Wellesplein 1, 760 B-2018 Antwerpen, Belgium 761 Phone: +32 3 240-8491 762 EMail: dimitri.papadimitriou@alcatel.be 764 Jean Philippe Vasseur 765 Cisco Systems, Inc. 766 300 Beaver Brook Road 767 Boxborough , MA - 01719 768 USA 769 EMail: jpv@cisco.com 771 Arthi Ayyangar 772 Juniper Networks, Inc. 773 1194 N.Mathilda Ave 774 Sunnyvale, CA 94089 775 USA 776 EMail: arthi@juniper.net 778 16. Full Copyright Statement 780 Copyright (C) The Internet Society (2004). All Rights 781 Reserved. 783 This document and translations of it may be copied and 784 furnished to others, and derivative works that comment on 785 or otherwise explain it or assist in its implementation may 786 be prepared, copied, published and distributed, in whole or 787 in part, without restriction of any kind, provided that the 788 above copyright notice and this paragraph are included on 789 all such copies and derivative works. However, this 790 document itself may not be modified in any way, such as by 791 removing the copyright notice or references to the Internet 792 Society or other Internet organizations, except as needed 793 for the purpose of developing Internet standards in which 794 case the procedures for copyrights defined in the Internet 795 Standards process must be followed, or as required to 796 translate it into languages other than English. 798 The limited permissions granted above are perpetual and 799 will not be revoked by the Internet Society or its 800 successors or assigns. This document and the information 801 contained herein is provided on an "AS IS" basis and THE 802 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 803 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 804 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 805 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 806 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 807 PURPOSE.