idnits 2.17.1 draft-ietf-mpls-rsvpte-attributes-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 846. -- Found old boilerplate from RFC 3978, Section 5.5 on line 946. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 826. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 833. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 839. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 17 longer pages, the longest (page 1) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 1 character 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 (March 2004) is 7340 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 243 == Unused Reference: 'RFC2119' is defined on line 850, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 869, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 872, but no explicit reference was found in the text == Unused Reference: 'INTER-AS' is defined on line 884, but no explicit reference was found in the text == Unused Reference: 'OSPF-CAPS' is defined on line 892, but no explicit reference was found in the text == Unused Reference: 'REOPT' is defined on line 897, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 8 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 March 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-03.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 02 to 03 Version 67 - Allow LSP_ATTRIBUTES object on Resv message. 68 - Document inheritance rules. 69 - Add table of Contents. 70 - New IPR and Copyright boiler-plate. 72 0.2 Changes from 01 to 02 Version 74 - Minor typographical changes. 76 0.3 Changes from 00 to 01 Version 78 - Change Attributes Flags TLV to be variable length so that more bits 79 can easily be added in the future. 80 - Define default behaviors for bits absent from the TLV and for 81 absence of the TLV. 82 - Clarify the IANA requirements for tracking Attributes Flags bits. 83 - Introduce RRO Attributes Subobject and describe usage. 84 - Move Fast Reroute reference to informational. 85 - Update security considerations to handle new RRO subobject 86 - Remove section that explained the need for this document in 87 advance of any definitive bit definitions. 88 - Tighten rules for processing LSP_ATTRIBUTES object in cases where 89 TLVs are unknown or unsupported. 90 - Clarify that LSP Attributes apply to individual LSPs and not to 91 entire sessions. 93 Contents 95 1. Introduction and Problem Statement 3 96 1.1 Applicability to Generalized MPLS 4 97 1.2 A Rejected Alternate Solution 4 98 2. Terminology 5 99 3. Attributes TLVs 5 100 3.1 Attributes Flags TLV 5 101 4. LSP_ATTRIBUTES Object 6 102 4.1 Format 7 103 4.2 Generic Processing Rules for Path Messages 7 104 4.3 Generic Processing Rules for Resv Messages 7 105 5. LSP_REQUIRED_ATTRIBUTES Object 8 106 5.1 Format 8 107 5.2 Generic Processing Rules 8 108 6. Inheritance Rules 9 109 7. Recording Attributes Per-LSP 9 110 7.1 Requirements 9 111 7.2 RRO Attributes Subobject 10 112 7.3 Procedures 10 113 7.3.1 Subobject Presence Rules 10 114 7.3.2 Reporting Compliance with LSP Attributes 11 115 7.3.3 Reporting Per-Hop Attributes 11 116 7.3.4 Default Behavior 11 117 8. Summary of Attribute Bit Allocation 11 118 9. Message Formats 12 119 10. IANA Considerations 13 120 10.1 New RSVP C-Nums and C-Types 13 121 10.2 New TLV Space 13 122 10.3 Attributes Flags 14 123 10.4 SESSION_ATTRIBUTE Flags Field 14 124 10.5 New Error Codes 14 125 10.6 New Record Route Subobject Identifier 14 126 11. Security Considerations 15 127 12. Acknowledgements 15 128 13. Intellectual Property Consideration 15 129 13.1 IPR Disclosure Acknowledgement 16 130 14. Normative References 16 131 15. Informative References 16 132 16. Authors' Addresses 17 133 17. Full Copyright Statement 17 135 1. Introduction and Problem Statement 137 Traffic Engineered Multiprotocol Label Switching (MPLS) Label 138 Switched Paths (LSPs) [RFC3031] may be set up using the Path message 139 of the RSVP-TE signaling protocol [RFC3209]. The Path message 140 includes the SESSION_ATTRIBUTE object which carries a flags field 141 used to indicate desired options and attributes of the LSP. 143 The flags field in the SESSION_ATTRIBUTE object has eight bits. Just 144 three of those bits are assigned in [RFC3209]. A further two bits are 145 assigned in [FRR] for fast re-reroute functionality leaving only 146 three bits available. Several recent proposals and Internet Drafts 147 have demonstrated that there is a high demand for the use of the 148 other three bits. Some, if not all, of those proposals are likely to 149 go forward as RFCs resulting in depletion or near depletion of the 150 flags field and a consequent difficulty in signaling new options and 151 attributes that may be developed in the future. 153 This document defines a new object for RSVP-TE messages that allows 154 the signaling of further attributes bits. The new object is 155 constructed from TLVs, and a new TLV is defined to carry a variable 156 number of attributes bits. Because of the nature of the TLV 157 construction the object is flexible and allows the future definition 158 of: 159 - further bit flags if further, distinct uses are discovered 160 - arbitrary options and attributes parameters carried as individual 161 TLVs. 163 Note that the LSP Attributes defined in this document are 164 specifically scoped to an LSP. They may be set differently on 165 separate LSPs with the same Tunnel ID between the same source and 166 destination (that is, within the same Session). 168 It is noted that some options and attributes do not need to be 169 acted on by all Label Switched Routers (LSRs) along the path of the 170 LSP. In particular, these options and attributes may apply only to 171 key LSRs on the path such as the ingress and egress. Special transit 172 LSRs, such as Area or AS Border Routers (ABRs/ASBRs) may also fall 173 into this category. This means that the new options and attributes 174 should be signaled transparently, and only examined at those points 175 that need to act on them. 177 On the other hand, other options and attributes may require action 178 at all transit LSRs along the path of the LSP. Inability to support 179 the required attributes by one of those transit LSRs may require the 180 LSR to refuse the establishment of the LSP. 182 These considerations are particularly important in the context of 183 backwards compatibility. In general, it should be possible to provide 184 new MPLS services across a legacy network without upgrading those 185 LSRs that do not need to participate actively in the new services. 186 Moreover, some features just require action on specific intermediate 187 hops, and not on every visited LSR. 189 Note that options already specified for the SESSION_ATTRIBUTE object 190 in pre-existing RFCs are not migrated to the new mechanisms described 191 in this document. 193 RSVP includes a way for unrecognized objects to be transparently 194 forwarded by transit nodes without them refusing the incoming 195 protocol messages and without the objects being stripped from the 196 outgoing protocol message (see [RFC2205] Section 3.10). This 197 capability extends to RSVP-TE and provides a good way to ensure that 198 only those LSRs that understand a particular object examine it. 200 This document distinguishes between options and attributes that are 201 only required at key LSRs along the path of the LSP, and those that 202 must be acted on by every LSR along the LSP. Two LSP Attributes 203 objects are defined in this document: the first may be passed 204 transparently by LSRs that do not recognize it, the second must cause 205 LSP setup failure with the generation of a PathErr message with an 206 appropriate Error Code if an LSR does not recognize it. 208 1.1 Applicability to Generalized MPLS 210 The RSVP-TE signaling protocol also forms the basis of a signaling 211 protocol for Generalized MPLS (GMPLS) as described in [RFC3471] and 212 [RFC3473]. The extensions described in this document are intended to 213 be equally applicable to MPLS and GMPLS. 215 1.2 A Rejected Alternate Solution 217 A rejected alternate solution was to define a new C-Type for the 218 existing SESSION_ATTRIBUTE object. This new C-Type could allow a 219 larger Flags field and address the immediate problem. 221 This solution was rejected because: 222 - A new C-Type is not backward compatible with deployed 223 implementations that expect to see a C-Type of 1 or 7. It is 224 important that any solution be capable of carrying new attributes 225 transparently across legacy LSRs if those LSRs are not required to 226 act on the attributes. 228 - Support for arbitrary attributes parameters through TLVs would 229 have meant a significant change of substance to the existing 230 object. 232 2. Terminology 234 This document uses terminology from the MPLS architecture document 235 [RFC3031] and from the RSVP-TE protocol specification [RFC3209] which 236 inherits from the RSVP specification [RFC2205]. It also makes uses of 237 the Generalized MPLS RSVP-TE terminology introduced in [RFC3471] and 238 [RFC3473]. 240 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 241 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 242 document are to be interpreted as described in RFC2119 [6]. 244 3. Attributes TLVs 246 Attributes carried by the new objects defined in this document are 247 encoded within TLVs. One or more TLVs may be present in each object. 248 There are no ordering rules for TLVs and no interpretation should be 249 placed on the order in which TLVs are received. 251 Each TLV is encoded as follows. 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Type | Length | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | | 259 // Value // 260 | | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Type 265 The identifier of the TLV. 267 Length 269 The length of the value field in bytes. Thus if no value 270 field is present the length field contains the value zero. 271 Each value field must be zero padded at the end to take it 272 up to a four byte boundary - the padding is not included in 273 the length so that a one byte value would be encoded in an 274 eight byte TLV with length field set to one. 276 Value 278 The data for the TLV padded as described above. 280 3.1 Attributes Flags TLV 282 This document defines only one TLV type value. Type 1 indicates the 283 Attributes Flags TLV. Other TLV types may be defined in future with 284 type values assigned by IANA. 286 The Attributes Flags TLV may be present in an LSP_ATTRIBUTES object 287 and/or an LSP_REQUIRED_ATTRIBUTES object defined in Sections 4 and 5. 288 The bits in the TLV represent the same attributes regardless of which 289 object carries the TLV. Documents that define individual bits MUST 290 specify whether the bit may be set in one object or the other, or 291 both. It is not expected that a bit will be set in both objects on a 292 single Path message at the same time, but this is not ruled out by 293 this document. 295 The Attributes Flags TLV value field is a variable length array of 296 flags numbered from the MSB as bit zero. The length field for this 297 TLV is always a multiple of 4 bytes, regardless of the number bits 298 carried. 300 Unassigned bits are considered as reserved and MUST be set to zero 301 on transmission by the originator of the object. Bits not contained 302 in the TLV MUST be assumed to be set to zero. If the TLV is absent 303 either because it is not contained in the LSP_ATTRIBUTES or LSP_ 304 REQUIRED_ATTRIBUTES object, or because those objects are themselves 305 absent, all processing MUST be performed as though the bits were 306 present and set to zero. 308 No bits are defined in this document. The assignment of bits is 309 managed by IANA. 311 4. LSP_ATTRIBUTES Object 313 The LSP_ATTRIBUTES object is used to signal attributes required in 314 support of an LSP, or to indicate the nature or use of an LSP where 315 that information is not required to be acted on by all transit LSRs. 316 Specifically, if an LSR does not support the object, it forwards it 317 unexamined and unchanged. This facilitates the exchange of attributes 318 across legacy networks that do not support this new object. 320 This object effectively extends the flags field in the SESSION_ 321 ATTRIBUTE object and allows for the future inclusion of more complex 322 objects through TLVs. 324 Note that some function may require an LSR to inspect both the 325 SESSION_ATTRIBUTE object, and the LSP_ATTRIBUTES or 326 LSP_REQUIRED_ATTRIBUTES object. 328 The LSP_ATTRIBUTES object may also be used to report LSP operational 329 state on a Resv even when no LSP_ATTRIBUTES or LSP_REQUIRED_ 330 ATTRIBUTES object was carried on the corresponding Path message. The 331 object is added or updated by LSRs that support the object. LSRs that 332 do not understand the object or have nothing to report, do not add 333 the object and forward it unchanged on Resv messages that they 334 generate. 336 The LSP_ATTRIBUTES object class is TBD of the form 11bbbbbb. This 337 C-Num value (see Section 8) ensures that LSRs that do not recognize 338 the object pass it on transparently. 340 One C-Type is defined, C-Type = 1 for LSP 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, and. 344 on Resv messages to report operational state. 346 4.1 Format 348 LSP_ATTRIBUTES class = TBD, C-Type = 1 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | | 354 // Attributes TLVs // 355 | | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 The Attributes TLVs are encoded as described in Section 3. 360 4.2 Generic Processing Rules for Path Messages 362 An LSR that does not support this object will pass it on unaltered 363 because of the C-Num. 365 An LSR that does support this object, but does not recognize a TLV 366 type code carried in this object MUST pass the TLV on unaltered 367 in the LSP_ATTRIBUTES object that it places in the Path message 368 that it sends downstream. 370 An LSR that does support this object and recognizes a TLV but does 371 not support the attribute defined by the TLV MUST act as specified in 372 the document that defines the TLV. 374 An LSR that supports the Attributes Flags TLV, but does not 375 recognize a bit set in the Attributes Flags TLV MUST forward the 376 TLV unchanged. 378 An LSR that supports the Attributes Flags TLV and recognizes a bit 379 that is set but does not support the indicated attribute MUST act as 380 specified in the document that defines the bit. 382 4.3 Generic Processing Rules for Resv Messages 384 An LSR that wishes to report operational status of an LSP may include 385 this object in a Resv message, or update the object that is already 386 carried in a Resv message. 388 Note that this usage reports the state of the entire LSP and not the 389 state of the LSP at an individual LSR. This latter function is 390 achieved using the LSP Attributes subobject of the Record Route 391 object as described in Section 7. 393 The bits in the Attributes TLV may be used to report operational 394 status for the whole LSP. For example, an egress may report a 395 particular status by setting a bit. LSRs within the network that 396 determine that this status has not been achieved may clear the bit 397 as they forward the Resv message. 399 Observe that LSRs that do not support the object or do not support 400 the function characterized by a particular bit in the Attributes TLV 401 will not clear the bit when forwarding the Resv. Thus, care must be 402 taken in defining the usage of this object on a Resv. The usage of 403 an individual bit in the Attributes TLV of the LSP_ATTRIBUTES object 404 on a Resv must be fully defined in the document that defines the bit. 406 Additional TLVs may also be defined to be carried in this object on 407 a Resv. 409 An LSR that does not support this object will pass it on unaltered 410 because of the C-Num. 412 5. LSP_REQUIRED_ATTRIBUTES Object 414 The LSP_REQUIRED_ATTRIBUTES object is used to signal attributes 415 required in support of an LSP, or to indicate the nature or use of 416 an LSP where that information MUST be inspected at each transit LSR. 417 Specifically, each transit LSR MUST examine the attributes in the 418 LSP_REQUIRED_ATTRIBUTES object and MUST NOT forward the object 419 transparently. 421 This object effectively extends the flags field in the SESSION_ 422 ATTRIBUTE object and allows for the future inclusion of more complex 423 objects through TLVs. It complements the LSP_ATTRIBUTES object. 425 The LSP_REQUIRED_ATTRIBUTES object class is TBD of the form 0bbbbbbb. 426 This C-Num value ensures that LSRs that do not 427 recognize the object reject the LSP setup effectively saying that 428 they do not support the attributes requested. This means that this 429 object SHOULD only be used for attributes that require support at 430 some transit LSRs and so require examination at all transit LSRs. See 431 Section 4 for how end-to-end and selective attributes are signaled. 433 One C-Type is defined, C-Type = 1 for LSP Required Attributes. 435 This object is optional and may be placed on Path messages to convey 436 additional information about the desired attributes of the LSP. 438 5.1 Format 440 LSP_REQUIRED_ATTRIBUTES class = TBD, C-Type = 1 442 0 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | | 446 // Attributes TLVs // 447 | | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 The Attributes TLVs are encoded as described in Section 3. 452 5.2 Generic Processing Rules 454 An LSR that does not support this object will use a PathErr to reject 455 the Path message based on the C-Num using the error code "Unknown 456 Object Class". 458 An LSR that does not recognize a TLV type code carried in this object 459 MUST reject the Path message using a PathErr with Error Code 460 "Unknown Attributes TLV" and Error Value set to the value of the 461 unknown TLV type code. 463 An LSR that does not recognize a bit set in the Attributes Flags 464 TLV MUST reject the Path message using a PathErr with Error Code 465 "Unknown Attributes Bit" and Error Value set to the bit number of 466 the unknown bit in the Attributes Flags. 468 An LSR that recognizes an attribute, however encoded, but which does 469 not support that attribute MUST act according to the behavior 470 specified in the document that defines that specific attribute. 472 Note that this object is not used on a Resv. In order to report the 473 status of an LSP either the LSP_ATTRIBUTES object on a Resv or the 474 Attributes subobject in the Record Route object (see Section 7) must 475 be used. 477 6. Inheritance Rules 479 In certain circumstances, when reaching an LSP region boundary, a 480 FA-LSP (see [MPLS-HIER]) is initially setup to allow the establishment 481 of the LSP carrying the LSP ATTRIBUTES and/or LSP_REQUIRED_ATTRIBUTES 482 objects. In this case, when the boundary LSR supports LSP_ATTRIBUTES 483 and LSP_REQUIRED_ATTRIBUTES processing, the FA-LSP MAY upon local 484 policy inherit a subset of the Attributes TLVs, in particular when the 485 FA-LSP belongs to the same switching capability class than the 486 triggering LSP. 488 When these conditions are met, the LSP_ATTRIBUTES and/or 489 LSP_REQUIRED_ATTRIBUTES objects are simply copied with the inherited 490 Attributes TLVs in the Path message used to establish the FA-LSP. By 491 default (and in order to simplify deployment), none of the incoming 492 LSP Attributes TLV are considered as inheritable. Note that when the 493 FA-LSP establishment itself requires one or more Attributes TLVs, an 494 'OR' operation is performed with the inherited set of values. 496 Documents that define individual bits for the LSP Attributes Flags 497 TLV MUST specify whether these bits MAY be inherited or not (including 498 the condition to be met in order for this inheritance to occur). The 499 same applies for any other TLV that will be defined following the 500 rules specified in Section 3. 502 7. Recording Attributes Per-LSP 504 7.1 Requirements 506 In some circumstances it is useful to determine which of the 507 requested LSP attributes have been applied at which LSRs along the 508 path of the LSP. For example, an attribute may be requested in the 509 LSP_ATTRIBUTES object such that LSRs that do not support the object 510 are not required to support the attribute or provide the requested 511 function. In this case, it may be useful to the ingress LSR to know 512 which LSRs acted on the request and which ignored it. 514 Additionally, there may be other qualities that need to be reported 515 on a hop-by-hop basis. These are currently indicated in the Flags 516 field of RRO subobjects. Since there are only eight bits available 517 in this field, and since some are already assigned and there is also 518 likely to be an increase in allocations in new documents, there is a 519 need for some other method to report per-hop attributes. 521 7.2 RRO Attributes Subobject 523 The RRO Attributes Subobject may be carried in the RECORD_ROUTE 524 object if it is present. The subobject uses the standard format of 525 an RRO subobject. 527 The length is variable as for the Attributes Flags TLV. The content 528 is the same as the Attribute Flags TLV - that is, it is a series of 529 bit flags. 531 There is a one-to-one correspondence between bits in the Attributes 532 Flags TLV and the RRO Attributes Subobject. If a bit is only required 533 in one of the two places, it is reserved in the other place. See 534 the procedures sections, below, for more information. 536 0 1 2 3 537 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 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Type | Length | Reserved | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | | 542 // Attribute Flags // 543 | | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 Type 548 0x?? TBD RRO Attribute Subobject 550 Length 552 The Length contains the total length of the subobject in bytes, 553 including the Type and Length fields. This length must be a 554 multiple of 4 and must be at least 8. 556 Attribute Flags 558 The attribute flags recorded for the specific hop. 560 7.3 Procedures 562 7.3.1 Subobject Presence Rules 564 The Attributes subobject is pushed onto the RECORD_ROUTE object 565 immediately prior to pushing the node's IP address or link 566 identifier. Thus, if label recording is being used, the Attributes 567 subobject SHOULD be pushed onto the RECORD_ROUTE object after the 568 Record Label subobject(s). 570 A node MUST NOT push an Attributes subobject on to the RECORD_ROUTE 571 object without also pushing an IPv4, IPv6 or Unnumbered Interface ID 572 subobject. 574 This means that an Attributes subobject is bound to the LSR 575 identified by the subobject found in the RRO immediately before the 576 Attributes subobject. 578 If the new subobject causes the RRO to be too big to fit in a Path 579 (or Resv) message, the processing MUST be as described in [RFC3209]. 581 If more than one Attributes subobject is found between a pair of 582 subobjects that identify LSRs, only the first one found (that is, the 583 nearest to the stop of the stack) SHALL have any meaning within the 584 context of this document. All such subobjects MUST be forwarded 585 unmodified by transit LSRs. 587 7.3.2 Reporting Compliance with LSP Attributes 589 To report compliance with an attribute requested in the Attributes 590 Flags TLV, an LSR MAY set the corresponding bit (see Section 8) in 591 the Attributes subobject. To report non-compliance, an LSR MAY clear 592 the corresponding bit in the Attributes subobject. 594 The requirement to report compliance MUST be specified in the 595 document that defines the usage of any bit. This will reduce to a 596 statement of whether hop-by-hop acknowledgement is required. 598 7.3.3 Reporting Per-Hop Attributes 600 To report a per-hop attribute, an LSR sets the appropriate bit in the 601 Attributes subobject. 603 The requirement to report a per-hop attribute MUST be specified in 604 the document that defines the usage of the bit. 606 7.3.4 Default Behavior 608 By default all bits in an Attributes subobject SHOULD be set to zero. 610 If a received Attribute subobject is not long enough to include a 611 specific numbered bit, that bit MUST be treated as though present and 612 as if set to zero. 614 If the RRO subobject is not present for a hop in the LSP, all bits 615 MUST be assumed to be set to zero. 617 8. Summary of Attribute Bit Allocation 619 This document defines two uses of per-LSP attribute flag bit fields. 620 The bit numbering in the Attributes Flags TLV and the RRO Attributes 621 subobject is identical. That is, the same attribute is indicated by 622 the same bit in both places. This means that only a single registry 623 of bits is maintained. 625 The consequence is a degree of clarity in implementation and 626 registration. 628 Note, however, that it is not always the case that a bit will be used 629 in both the Attributes Flags TLV and the RRO Attributes subobject. 630 For example, an attribute may be requested using the Attributes Flags 631 TLV, but there is no requirement to report the handling of the 632 attribute on a hop-by-hop basis. Conversely, there may be a 633 requirement to report the attributes of an LSP on a hop-by-hop basis, 634 but there is no corresponding request attribute. 636 In these cases, a single bit number is still assigned for both the 637 Attributes Flags TLV and the RRO Attributes subobject even though the 638 bit may be irrelevant in either the Attributes Flags or the RRO 639 Attributes subobject. The document that defines the usage of the new 640 bit MUST state in which places it is used and MUST handle a default 641 setting of zero. 643 9. Message Formats 645 The LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES object MAY 646 be carried in a Path message. The LSP_ATTRIBUTES object MAY be 647 carried in a Resv message. 649 The order of objects in RSVP-TE messages is recommended, but 650 implementations must be capable of receiving the objects in any 651 meaningful order. 653 On a Path message, the LSP_ATTRIBUTES object and LSP_REQUIRED_ 654 ATTRIBUTES objects are RECOMMENDED to be placed immediately after the 655 SESSION_ATTRIBUTE object if it is present, or otherwise immediately 656 after the LABEL_REQUEST object. 658 If both the LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES 659 object are present, the LSP_REQUIRED_ATTRIBUTES object is RECOMMENDED 660 to be placed first. 662 LSRs SHOULD be prepared to receive these objects in any order in any 663 position within a Path message. Subsequent instances of these objects 664 within a Path message SHOULD be ignored and those objects MUST be 665 forwarded unchanged. 667 On a Resv message, the LSP_ATTRIBUTES object is placed in the flow 668 descriptor and is associated with the FILTER_SPEC object that 669 precedes it. It is RECOMMENDED that the LSP_ATTRIBUTES object be 670 placed immediately after the LABEL object. 672 LSRs SHOULD be prepared to receive this object in any order in any 673 position within a Resv message subject to the previous note. Only 674 one instance of the LSP_ATTRIBUTES object is meaningful within the 675 context of a FILTER_SPEC object. Subsequent instances of the object 676 SHOULD be ignored and MUST be forwarded unchanged. 678 10. IANA Considerations 680 10.1 New RSVP C-Nums and C-Types 682 Two new RSVP C-Nums are defined in this document and should be 683 assigned by IANA. 685 o LSP_ATTRIBUTES object 687 The C-Num should be of the form 11bbbbbb so that LSRs that do not 688 recognize the object will ignore the object but forward it, 689 unexamined and unmodified, in all messages resulting from this 690 message. 692 One C-Type is defined for this object and should be assigned by 693 IANA. 695 o LSP Attributes TLVs 697 Recommended C-Type value 1. 699 o LSP_REQUIRED_ATTRIBUTES object 701 The C-Num should be of the form 0bbbbbbb so that LSRs that do not 702 recognize the object will reject the message that carries it with 703 an "Unknown Object Class" error. 705 One C-Type is defined for this object and should be assigned by 706 IANA. 708 o LSP Required Attributes TLVs 710 Recommended C-Type value 1. 712 10.2 New TLV Space 714 The two new objects referenced above are constructed from TLVs. Each 715 TLV includes a 16-bit type identifier (the T-field). The same T-field 716 values are applicable to both objects. 718 IANA is requested to manage TLV type identifiers as follows: 720 - TLV Type (T-field value) 721 - TLV Name 722 - Whether allowed on LSP_ATTRIBUTES object 723 - Whether allowed on LSP_REQUIRED_ATTRIBUTES object. 725 This document defines one TLV type as follows: 726 - TLV Type = 1 727 - TLV Name = Attributes Flags TLV 728 - allowed on LSP_ATTRIBUTES object 729 - allowed on LSP_REQUIRED_ATTRIBUTES object. 731 10.3 Attributes Flags 733 This document provides new attributes bit flags for use in other 734 documents that specify new RSVP-TE attributes. These flags are 735 present in the Attributes Flags TLV referenced in the previous 736 section. 738 IANA is requested to manage the space of attributes bit flags 739 numbering them in the usual IETF notation starting at zero and 740 continuing through 2039. 742 Each bit should be tracked with the following qualities: 743 - Bit number 744 - Defining RFC 745 - Name of bit 746 - Whether there is meaning in the Attribute Flags TLV on a Path 747 - Whether there is meaning in the Attribute Flags TLV on a Resv 748 - Whether there is meaning in the RRO Attributes Subobject. 750 Note that this means that all bits in the Attribute Flags TLV and the 751 RRO Attributes Subobject use the same bit number regardless of 752 whether they are used in one or both places. Thus, only one list of 753 bits is required to be maintained. (It would be meaningless in the 754 context of this document for a bit to have no meaning in neither the 755 Attribute Flags TLV nor the RRO Attributes Subobject.) 757 10.4 SESSION_ATTRIBUTE Flags Field 759 This document does not make any alterations to the definition of the 760 existing SESSION_ATTRIBUTE object nor to the definition of meanings 761 assigned to the flags in the Flags field of that object. These flags 762 are assigned meanings in various other RFCs and Internet Drafts. 764 It is suggested that IANA manage the allocation of meaning to the 765 bits in the Flags field of the SESSION_ATTRIBUTE object to prevent 766 accidental double allocation of any one bit. 768 10.5 New Error Codes 770 This document defines the following new error codes and error values. 771 Numeric values should be assigned by IANA. 773 Error Code Error Value 774 "Unknown Attributes TLV" Identifies the unknown TLV type code. 775 "Unknown Attributes Bit" Identifies the unknown Attribute Bit. 777 10.6 New Record Route Subobject Identifier 779 A new subobject is defined for inclusion in the RECORD_ROUTE object. 781 The RRO Attributes subobject is identified by a Type value of TBD. 783 11. Security Considerations 785 This document adds two new objects to the RSVP Path message as used 786 in MPLS and GMPLS signaling, and a new subobject to the RECORD_ROUTE 787 object carried on may RSVP messages. It does not introduce any new 788 direct security issues and the reader is referred to the security 789 considerations expressed in [RFC2205], [RFC3209] and [RFC3473]. 791 It is of passing note that any signaling request that indicates the 792 functional preferences or attributes of an MPLS LSP may provide 793 anyone with unauthorized access to the contents of the message with 794 information about the LSP that an administrator may wish to keep 795 secret. Although this document adds new objects for signaling desired 796 LSP attributes, it does not contribute to this issue which can 797 only be satisfactorily handled by encrypting the content of the 798 signaling message. 800 Similarly, the addition of attribute recording information to the 801 RRO may reveal information about the status of the LSP and the 802 capabilities of individual LSRs that operators wish to keep secret. 803 The same strategy that applies to other RRO subobjects also applies 804 here. Note, however, that there is a tension between notifying the 805 head end of the LSP status at transit LSRs, and hiding the existence 806 or identity of the transit LSRs. 808 12. Acknowledgements 810 Credit to the OSPF Working Group for inspiration from their solution 811 to a similar problem. 813 Thanks to Rahul Aggarwal for his careful review and support of this 814 work. Thanks also to Raymond Zhang, Kireeti Kompella, Philip Matthews, 815 Jim Gibson and Alan Kullberg for their input. 817 13. Intellectual Property Consideration 819 The IETF takes no position regarding the validity or scope of any 820 Intellectual Property Rights or other rights that might be claimed 821 to pertain to the implementation or use of the technology 822 described in this document or the extent to which any license 823 under such rights might or might not be available; nor does it 824 represent that it has made any independent effort to identify any 825 such rights. Information on the procedures with respect to rights 826 in RFC documents can be found in BCP 78 and BCP 79. 828 Copies of IPR disclosures made to the IETF Secretariat and any 829 assurances of licenses to be made available, or the result of an 830 attempt made to obtain a general license or permission for the use 831 of such proprietary rights by implementers or users of this 832 specification can be obtained from the IETF on-line IPR repository 833 at http://www.ietf.org/ipr. 835 The IETF invites any interested party to bring to its attention 836 any copyrights, patents or patent applications, or other 837 proprietary rights that may cover technology that may be required 838 to implement this standard. Please address the information to the 839 IETF at ietf-ipr@ietf.org. 841 13.1 IPR Disclosure Acknowledgement 843 By submitting this Internet-Draft, I certify that any applicable 844 patent or other IPR claims of which I am aware have been disclosed, 845 and any of which I become aware will be disclosed, in accordance with 846 RFC 3668. 848 14. Normative References 850 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 851 Requirement Levels", BCP 14, RFC 2119, March 1997. 853 [RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. 854 and S. Jamin, "Resource ReserVation Protocol -- 855 Version 1 Functional Specification", RFC 2205, 856 September 1997. 858 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., 859 Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions 860 to RSVP for LSP Tunnels", RFC 3209, December 2001. 862 [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label 863 Switching (GMPLS) Signaling Functional Description", 864 RFC 3471, January 2003. 866 [RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling - 867 RSVP-TE Extensions", RFC 3473 January 2003. 869 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, 870 RFC 3667, February 2004. 872 [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF 873 Technology", BCP 79, RFC 3668, February 2004. 875 15. Informative References 877 [RFC2026] Bradner, S., "The Internet Standards Process 878 -- Revision 3", RFC 2026, October 1996. 880 [RFC3031] Rosen, E., Viswanathan, A., and Callon, R., 881 "Multiprotocol Label Switching 882 Architecture", RFC 3031, January 2001. 884 [INTER-AS] Vasseur, JP., Zhang, R., "Inter-AS MPLS Traffic 885 Engineering", , 886 Internet Draft, work in progress. 888 [FRR] Pan, P. (Ed.), "Fast Reroute Extensions to RSVP-TE for 889 LSP Tunnels", , Internet Draft, work in progress. 892 [OSPF-CAPS] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., 893 Vasseur, JP., "Extensions to OSPF for Advertising 894 Optional Router Capabilities", , Internet Draft, work in progress. 897 [REOPT] Vasseur, JP., Ikejiri, Y., "Reoptimization of MPLS 898 Traffic Engineering loosely routed explicit LSP path", 899 , Internet 900 Draft, work in progress. 902 [MPLS-HIER] Kompella, K. and Y. Rekhter, "LSP Hierarchy with 903 MPLS TE", Work in Progress. 905 16. Authors' Addresses 907 Adrian Farrel 908 Old Dog Consulting 909 Phone: +44 (0) 1978 860944 910 EMail: adrian@olddog.co.uk 912 Dimitri Papadimitriou (Alcatel) 913 Fr. Wellesplein 1, 914 B-2018 Antwerpen, Belgium 915 Phone: +32 3 240-8491 916 EMail: dimitri.papadimitriou@alcatel.be 918 Jean Philippe Vasseur 919 Cisco Systems, Inc. 920 300 Beaver Brook Road 921 Boxborough , MA - 01719 922 USA 923 EMail: jpv@cisco.com 925 Arthi Ayyangar 926 Juniper Networks, Inc. 927 1194 N.Mathilda Ave 928 Sunnyvale, CA 94089 929 USA 930 EMail: arthi@juniper.net 932 17. Full Copyright Statement 934 Copyright (C) The Internet Society (2004). This document is 935 subject to the rights, licenses and restrictions contained in BCP 936 78, and except as set forth therein, the authors retain all their 937 rights. 939 This document and the information contained herein are provided 940 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 941 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 942 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 943 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 944 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 945 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 946 PARTICULAR PURPOSE.