idnits 2.17.1 draft-ietf-mpls-rsvpte-attributes-04.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 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 922. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 830. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 837. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 843. ** 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 3 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 contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [RFC2219], but that reference does not seem to mention RFC 2119 either. -- 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 (July 2004) is 7224 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: 'RFC2219' is mentioned on line 247, but not defined == Unused Reference: 'RFC2119' is defined on line 847, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 866, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 869, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 874, 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 (~~), 7 warnings (==), 7 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 Dimitri Papadimitriou 4 Expires: January 2005 Alcatel 5 Jean-Philippe Vasseur 6 Cisco Systems, Inc. 7 Arthi Ayyangar 8 Juniper Networks 10 July 2004 12 Encoding of Attributes for Multiprotocol Label Switching (MPLS) 13 Label Switched Path (LSP) Establishment Using RSVP-TE 15 draft-ietf-mpls-rsvpte-attributes-04.txt 17 Status of this Memo 19 By submitting this Internet-Draft, I certify that any applicable 20 patent or other IPR claims of which I am aware have been disclosed, 21 or will be disclosed, and any of which I become aware will be 22 disclosed, in accordance with RFC 3668. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that other 26 groups may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be 37 accessed at http://www.ietf.org/shadow.html. 39 Abstract 41 Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may 42 be established using the Resource Reservation Protocol Traffic 43 Engineering extensions (RSVP-TE). This protocol includes an object 44 (the SESSION_ATTRIBUTE object) which carries a flags field used to 45 indicate options and attributes of the LSP. That flags field has 46 eight bits allowing for eight options to be set. Recent proposals in 47 many documents that extend RSVP-TE have suggested uses for each of 48 the previously unused bits. 50 This document defines a new object for RSVP-TE messages that allows 51 the signaling of further attribute bits and also the carriage of 52 arbitrary attribute parameters to make RSVP-TE easily extensible to 53 support new requirements. Additionally, this document defines a way 54 to record the attributes applied to the LSP on a hop-by-hop basis. 56 The object mechanisms defined in this document are equally applicable 57 to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to 58 GMPLS non-PSC LSPs. 60 0. Change History 62 This section to be removed before publication as an RFC. 64 0.1 Changes from 03 to 04 Version 66 - New IPR and copyright text 67 - Update referneces 69 0.2 Changes from 02 to 03 Version 71 - Allow LSP_ATTRIBUTES object on Resv message. 72 - Document inheritance rules. 73 - Add table of Contents. 74 - New IPR and Copyright boiler-plate. 76 0.3 Changes from 01 to 02 Version 78 - Minor typographical changes. 80 0.4 Changes from 00 to 01 Version 82 - Change Attributes Flags TLV to be variable length so that more bits 83 can easily be added in the future. 84 - Define default behaviors for bits absent from the TLV and for 85 absence of the TLV. 86 - Clarify the IANA requirements for tracking Attributes Flags bits. 87 - Introduce RRO Attributes Subobject and describe usage. 88 - Move Fast Reroute reference to informational. 89 - Update security considerations to handle new RRO subobject 90 - Remove section that explained the need for this document in 91 advance of any definitive bit definitions. 92 - Tighten rules for processing LSP_ATTRIBUTES object in cases where 93 TLVs are unknown or unsupported. 94 - Clarify that LSP Attributes apply to individual LSPs and not to 95 entire sessions. 97 Contents 99 1. Introduction and Problem Statement 3 100 1.1 Applicability to Generalized MPLS 4 101 1.2 A Rejected Alternate Solution 4 102 2. Terminology 5 103 3. Attributes TLVs 5 104 3.1 Attributes Flags TLV 5 105 4. LSP_ATTRIBUTES Object 6 106 4.1 Format 7 107 4.2 Generic Processing Rules for Path Messages 7 108 4.3 Generic Processing Rules for Resv Messages 7 109 5. LSP_REQUIRED_ATTRIBUTES Object 8 110 5.1 Format 8 111 5.2 Generic Processing Rules 9 112 6. Inheritance Rules 9 113 7. Recording Attributes Per-LSP 9 114 7.1 Requirements 9 115 7.2 RRO Attributes Subobject 10 116 7.3 Procedures 10 117 7.3.1 Subobject Presence Rules 10 118 7.3.2 Reporting Compliance with LSP Attributes 11 119 7.3.3 Reporting Per-Hop Attributes 11 120 7.3.4 Default Behavior 11 121 8. Summary of Attribute Bit Allocation 11 122 9. Message Formats 12 123 10. IANA Considerations 13 124 10.1 New RSVP C-Nums and C-Types 13 125 10.2 New TLV Space 13 126 10.3 Attributes Flags 14 127 10.4 SESSION_ATTRIBUTE Flags Field 14 128 10.5 New Error Codes 14 129 10.6 New Record Route Subobject Identifier 14 130 11. Security Considerations 15 131 12. Acknowledgements 15 132 13. Intellectual Property Consideration 15 133 13.1 IPR Disclosure Acknowledgement 16 134 14. Normative References 16 135 15. Informative References 16 136 16. Authors' Addresses 16 137 17. Full Copyright Statement 17 139 1. Introduction and Problem Statement 141 Traffic Engineered Multiprotocol Label Switching (MPLS) Label 142 Switched Paths (LSPs) [RFC3031] may be set up using the Path message 143 of the RSVP-TE signaling protocol [RFC3209]. The Path message 144 includes the SESSION_ATTRIBUTE object which carries a flags field 145 used to indicate desired options and attributes of the LSP. 147 The flags field in the SESSION_ATTRIBUTE object has eight bits. Just 148 three of those bits are assigned in [RFC3209]. A further two bits are 149 assigned in [FRR] for fast re-reroute functionality leaving only 150 three bits available. Several recent proposals and Internet Drafts 151 have demonstrated that there is a high demand for the use of the 152 other three bits. Some, if not all, of those proposals are likely to 153 go forward as RFCs resulting in depletion or near depletion of the 154 flags field and a consequent difficulty in signaling new options and 155 attributes that may be developed in the future. 157 This document defines a new object for RSVP-TE messages that allows 158 the signaling of further attributes bits. The new object is 159 constructed from TLVs, and a new TLV is defined to carry a variable 160 number of attributes bits. Because of the nature of the TLV 161 construction the object is flexible and allows the future definition 162 of: 163 - further bit flags if further, distinct uses are discovered 164 - arbitrary options and attributes parameters carried as individual 165 TLVs. 167 Note that the LSP Attributes defined in this document are 168 specifically scoped to an LSP. They may be set differently on 169 separate LSPs with the same Tunnel ID between the same source and 170 destination (that is, within the same Session). 172 It is noted that some options and attributes do not need to be 173 acted on by all Label Switched Routers (LSRs) along the path of the 174 LSP. In particular, these options and attributes may apply only to 175 key LSRs on the path such as the ingress and egress. Special transit 176 LSRs, such as Area or AS Border Routers (ABRs/ASBRs) may also fall 177 into this category. This means that the new options and attributes 178 should be signaled transparently, and only examined at those points 179 that need to act on them. 181 On the other hand, other options and attributes may require action 182 at all transit LSRs along the path of the LSP. Inability to support 183 the required attributes by one of those transit LSRs may require the 184 LSR to refuse the establishment of the LSP. 186 These considerations are particularly important in the context of 187 backwards compatibility. In general, it should be possible to provide 188 new MPLS services across a legacy network without upgrading those 189 LSRs that do not need to participate actively in the new services. 190 Moreover, some features just require action on specific intermediate 191 hops, and not on every visited LSR. 193 Note that options already specified for the SESSION_ATTRIBUTE object 194 in pre-existing RFCs are not migrated to the new mechanisms described 195 in this document. 197 RSVP includes a way for unrecognized objects to be transparently 198 forwarded by transit nodes without them refusing the incoming 199 protocol messages and without the objects being stripped from the 200 outgoing protocol message (see [RFC2205] Section 3.10). This 201 capability extends to RSVP-TE and provides a good way to ensure that 202 only those LSRs that understand a particular object examine it. 204 This document distinguishes between options and attributes that are 205 only required at key LSRs along the path of the LSP, and those that 206 must be acted on by every LSR along the LSP. Two LSP Attributes 207 objects are defined in this document: the first may be passed 208 transparently by LSRs that do not recognize it, the second must cause 209 LSP setup failure with the generation of a PathErr message with an 210 appropriate Error Code if an LSR does not recognize it. 212 1.1 Applicability to Generalized MPLS 214 The RSVP-TE signaling protocol also forms the basis of a signaling 215 protocol for Generalized MPLS (GMPLS) as described in [RFC3471] and 216 [RFC3473]. The extensions described in this document are intended to 217 be equally applicable to MPLS and GMPLS. 219 1.2 A Rejected Alternate Solution 221 A rejected alternate solution was to define a new C-Type for the 222 existing SESSION_ATTRIBUTE object. This new C-Type could allow a 223 larger Flags field and address the immediate problem. 225 This solution was rejected because: 226 - A new C-Type is not backward compatible with deployed 227 implementations that expect to see a C-Type of 1 or 7. It is 228 important that any solution be capable of carrying new attributes 229 transparently across legacy LSRs if those LSRs are not required to 230 act on the attributes. 232 - Support for arbitrary attributes parameters through TLVs would 233 have meant a significant change of substance to the existing 234 object. 236 2. Terminology 238 This document uses terminology from the MPLS architecture document 239 [RFC3031] and from the RSVP-TE protocol specification [RFC3209] which 240 inherits from the RSVP specification [RFC2205]. It also makes uses of 241 the Generalized MPLS RSVP-TE terminology introduced in [RFC3471] and 242 [RFC3473]. 244 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 245 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 246 document are to be interpreted as described in [RFC2219]. 248 3. Attributes TLVs 250 Attributes carried by the new objects defined in this document are 251 encoded within TLVs. One or more TLVs may be present in each object. 252 There are no ordering rules for TLVs and no interpretation should be 253 placed on the order in which TLVs are received. 255 Each TLV is encoded as follows. 257 0 1 2 3 258 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Type | Length | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | | 263 // Value // 264 | | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 Type 269 The identifier of the TLV. 271 Length 273 The length of the value field in bytes. Thus if no value 274 field is present the length field contains the value zero. 275 Each value field must be zero padded at the end to take it 276 up to a four byte boundary - the padding is not included in 277 the length so that a one byte value would be encoded in an 278 eight byte TLV with length field set to one. 280 Value 282 The data for the TLV padded as described above. 284 3.1 Attributes Flags TLV 286 This document defines only one TLV type value. Type 1 indicates the 287 Attributes Flags TLV. Other TLV types may be defined in future with 288 type values assigned by IANA. 290 The Attributes Flags TLV may be present in an LSP_ATTRIBUTES object 291 and/or an LSP_REQUIRED_ATTRIBUTES object defined in Sections 4 and 5. 292 The bits in the TLV represent the same attributes regardless of which 293 object carries the TLV. Documents that define individual bits MUST 294 specify whether the bit may be set in one object or the other, or 295 both. It is not expected that a bit will be set in both objects on a 296 single Path message at the same time, but this is not ruled out by 297 this document. 299 The Attributes Flags TLV value field is a variable length array of 300 flags numbered from the MSB as bit zero. The length field for this 301 TLV is always a multiple of 4 bytes, regardless of the number bits 302 carried. 304 Unassigned bits are considered as reserved and MUST be set to zero 305 on transmission by the originator of the object. Bits not contained 306 in the TLV MUST be assumed to be set to zero. If the TLV is absent 307 either because it is not contained in the LSP_ATTRIBUTES or LSP_ 308 REQUIRED_ATTRIBUTES object, or because those objects are themselves 309 absent, all processing MUST be performed as though the bits were 310 present and set to zero. 312 No bits are defined in this document. The assignment of bits is 313 managed by IANA. 315 4. LSP_ATTRIBUTES Object 317 The LSP_ATTRIBUTES object is used to signal attributes required in 318 support of an LSP, or to indicate the nature or use of an LSP where 319 that information is not required to be acted on by all transit LSRs. 320 Specifically, if an LSR does not support the object, it forwards it 321 unexamined and unchanged. This facilitates the exchange of attributes 322 across legacy networks that do not support this new object. 324 This object effectively extends the flags field in the SESSION_ 325 ATTRIBUTE object and allows for the future inclusion of more complex 326 objects through TLVs. 328 Note that some function may require an LSR to inspect both the 329 SESSION_ATTRIBUTE object, and the LSP_ATTRIBUTES or 330 LSP_REQUIRED_ATTRIBUTES object. 332 The LSP_ATTRIBUTES object may also be used to report LSP operational 333 state on a Resv even when no LSP_ATTRIBUTES or LSP_REQUIRED_ 334 ATTRIBUTES object was carried on the corresponding Path message. The 335 object is added or updated by LSRs that support the object. LSRs that 336 do not understand the object or have nothing to report, do not add 337 the object and forward it unchanged on Resv messages that they 338 generate. 340 The LSP_ATTRIBUTES object class is TBD of the form 11bbbbbb. This 341 C-Num value (see Section 8) ensures that LSRs that do not recognize 342 the object pass it on transparently. 344 One C-Type is defined, C-Type = 1 for LSP Attributes. 346 This object is optional and may be placed on Path messages to convey 347 additional information about the desired attributes of the LSP, and. 348 on Resv messages to report operational state. 350 4.1 Format 352 LSP_ATTRIBUTES class = TBD, C-Type = 1 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | | 358 // Attributes TLVs // 359 | | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 The Attributes TLVs are encoded as described in Section 3. 364 4.2 Generic Processing Rules for Path Messages 366 An LSR that does not support this object will pass it on unaltered 367 because of the C-Num. 369 An LSR that does support this object, but does not recognize a TLV 370 type code carried in this object MUST pass the TLV on unaltered 371 in the LSP_ATTRIBUTES object that it places in the Path message 372 that it sends downstream. 374 An LSR that does support this object and recognizes a TLV but does 375 not support the attribute defined by the TLV MUST act as specified in 376 the document that defines the TLV. 378 An LSR that supports the Attributes Flags TLV, but does not 379 recognize a bit set in the Attributes Flags TLV MUST forward the 380 TLV unchanged. 382 An LSR that supports the Attributes Flags TLV and recognizes a bit 383 that is set but does not support the indicated attribute MUST act as 384 specified in the document that defines the bit. 386 4.3 Generic Processing Rules for Resv Messages 388 An LSR that wishes to report operational status of an LSP may include 389 this object in a Resv message, or update the object that is already 390 carried in a Resv message. 392 Note that this usage reports the state of the entire LSP and not the 393 state of the LSP at an individual LSR. This latter function is 394 achieved using the LSP Attributes subobject of the Record Route 395 object as described in Section 7. 397 The bits in the Attributes TLV may be used to report operational 398 status for the whole LSP. For example, an egress may report a 399 particular status by setting a bit. LSRs within the network that 400 determine that this status has not been achieved may clear the bit 401 as they forward the Resv message. 403 Observe that LSRs that do not support the object or do not support 404 the function characterized by a particular bit in the Attributes TLV 405 will not clear the bit when forwarding the Resv. Thus, care must be 406 taken in defining the usage of this object on a Resv. The usage of 407 an individual bit in the Attributes TLV of the LSP_ATTRIBUTES object 408 on a Resv must be fully defined in the document that defines the bit. 410 Additional TLVs may also be defined to be carried in this object on 411 a Resv. 413 An LSR that does not support this object will pass it on unaltered 414 because of the C-Num. 416 5. LSP_REQUIRED_ATTRIBUTES Object 418 The LSP_REQUIRED_ATTRIBUTES object is used to signal attributes 419 required in support of an LSP, or to indicate the nature or use of 420 an LSP where that information MUST be inspected at each transit LSR. 421 Specifically, each transit LSR MUST examine the attributes in the 422 LSP_REQUIRED_ATTRIBUTES object and MUST NOT forward the object 423 transparently. 425 This object effectively extends the flags field in the SESSION_ 426 ATTRIBUTE object and allows for the future inclusion of more complex 427 objects through TLVs. It complements the LSP_ATTRIBUTES object. 429 The LSP_REQUIRED_ATTRIBUTES object class is TBD of the form 0bbbbbbb. 430 This C-Num value ensures that LSRs that do not recognize the object 431 reject the LSP setup effectively saying that they do not support the 432 attributes requested. This means that this object SHOULD only be used 433 for attributes that require support at some transit LSRs and so 434 require examination at all transit LSRs. See Section 4 for how end- 435 to-end and selective attributes are signaled. 437 One C-Type is defined, C-Type = 1 for LSP Required Attributes. 439 This object is optional and may be placed on Path messages to convey 440 additional information about the desired attributes of the LSP. 442 5.1 Format 444 LSP_REQUIRED_ATTRIBUTES class = TBD, C-Type = 1 446 0 1 2 3 447 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 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | | 450 // Attributes TLVs // 451 | | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 The Attributes TLVs are encoded as described in Section 3. 456 5.2 Generic Processing Rules 458 An LSR that does not support this object will use a PathErr to reject 459 the Path message based on the C-Num using the error code "Unknown 460 Object Class". 462 An LSR that does not recognize a TLV type code carried in this object 463 MUST reject the Path message using a PathErr with Error Code 464 "Unknown Attributes TLV" and Error Value set to the value of the 465 unknown TLV type code. 467 An LSR that does not recognize a bit set in the Attributes Flags 468 TLV MUST reject the Path message using a PathErr with Error Code 469 "Unknown Attributes Bit" and Error Value set to the bit number of 470 the unknown bit in the Attributes Flags. 472 An LSR that recognizes an attribute, however encoded, but which does 473 not support that attribute MUST act according to the behavior 474 specified in the document that defines that specific attribute. 476 Note that this object is not used on a Resv. In order to report the 477 status of an LSP either the LSP_ATTRIBUTES object on a Resv or the 478 Attributes subobject in the Record Route object (see Section 7) must 479 be used. 481 6. Inheritance Rules 483 In certain circumstances, when reaching an LSP region boundary, a 484 FA-LSP (see [MPLS-HIER]) is initially setup to allow the establishment 485 of the LSP carrying the LSP ATTRIBUTES and/or LSP_REQUIRED_ATTRIBUTES 486 objects. In this case, when the boundary LSR supports LSP_ATTRIBUTES 487 and LSP_REQUIRED_ATTRIBUTES processing, the FA-LSP MAY upon local 488 policy inherit a subset of the Attributes TLVs, in particular when the 489 FA-LSP belongs to the same switching capability class than the 490 triggering LSP. 492 When these conditions are met, the LSP_ATTRIBUTES and/or 493 LSP_REQUIRED_ATTRIBUTES objects are simply copied with the inherited 494 Attributes TLVs in the Path message used to establish the FA-LSP. By 495 default (and in order to simplify deployment), none of the incoming 496 LSP Attributes TLV are considered as inheritable. Note that when the 497 FA-LSP establishment itself requires one or more Attributes TLVs, an 498 'OR' operation is performed with the inherited set of values. 500 Documents that define individual bits for the LSP Attributes Flags 501 TLV MUST specify whether these bits MAY be inherited or not (including 502 the condition to be met in order for this inheritance to occur). The 503 same applies for any other TLV that will be defined following the 504 rules specified in Section 3. 506 7. Recording Attributes Per-LSP 508 7.1 Requirements 510 In some circumstances it is useful to determine which of the 511 requested LSP attributes have been applied at which LSRs along the 512 path of the LSP. For example, an attribute may be requested in the 513 LSP_ATTRIBUTES object such that LSRs that do not support the object 514 are not required to support the attribute or provide the requested 515 function. In this case, it may be useful to the ingress LSR to know 516 which LSRs acted on the request and which ignored it. 518 Additionally, there may be other qualities that need to be reported 519 on a hop-by-hop basis. These are currently indicated in the Flags 520 field of RRO subobjects. Since there are only eight bits available 521 in this field, and since some are already assigned and there is also 522 likely to be an increase in allocations in new documents, there is a 523 need for some other method to report per-hop attributes. 525 7.2 RRO Attributes Subobject 527 The RRO Attributes Subobject may be carried in the RECORD_ROUTE 528 object if it is present. The subobject uses the standard format of 529 an RRO subobject. 531 The length is variable as for the Attributes Flags TLV. The content 532 is the same as the Attribute Flags TLV - that is, it is a series of 533 bit flags. 535 There is a one-to-one correspondence between bits in the Attributes 536 Flags TLV and the RRO Attributes Subobject. If a bit is only required 537 in one of the two places, it is reserved in the other place. See 538 the procedures sections, below, for more information. 540 0 1 2 3 541 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 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Type | Length | Reserved | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | | 546 // Attribute Flags // 547 | | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 Type 552 0x?? TBD RRO Attribute Subobject 554 Length 556 The Length contains the total length of the subobject in bytes, 557 including the Type and Length fields. This length must be a 558 multiple of 4 and must be at least 8. 560 Attribute Flags 562 The attribute flags recorded for the specific hop. 564 7.3 Procedures 566 7.3.1 Subobject Presence Rules 568 The Attributes subobject is pushed onto the RECORD_ROUTE object 569 immediately prior to pushing the node's IP address or link 570 identifier. Thus, if label recording is being used, the Attributes 571 subobject SHOULD be pushed onto the RECORD_ROUTE object after the 572 Record Label subobject(s). 574 A node MUST NOT push an Attributes subobject on to the RECORD_ROUTE 575 object without also pushing an IPv4, IPv6 or Unnumbered Interface ID 576 subobject. 578 This means that an Attributes subobject is bound to the LSR 579 identified by the subobject found in the RRO immediately before the 580 Attributes subobject. 582 If the new subobject causes the RRO to be too big to fit in a Path 583 (or Resv) message, the processing MUST be as described in [RFC3209]. 585 If more than one Attributes subobject is found between a pair of 586 subobjects that identify LSRs, only the first one found (that is, the 587 nearest to the stop of the stack) SHALL have any meaning within the 588 context of this document. All such subobjects MUST be forwarded 589 unmodified by transit LSRs. 591 7.3.2 Reporting Compliance with LSP Attributes 593 To report compliance with an attribute requested in the Attributes 594 Flags TLV, an LSR MAY set the corresponding bit (see Section 8) in 595 the Attributes subobject. To report non-compliance, an LSR MAY clear 596 the corresponding bit in the Attributes subobject. 598 The requirement to report compliance MUST be specified in the 599 document that defines the usage of any bit. This will reduce to a 600 statement of whether hop-by-hop acknowledgement is required. 602 7.3.3 Reporting Per-Hop Attributes 604 To report a per-hop attribute, an LSR sets the appropriate bit in the 605 Attributes subobject. 607 The requirement to report a per-hop attribute MUST be specified in 608 the document that defines the usage of the bit. 610 7.3.4 Default Behavior 612 By default all bits in an Attributes subobject SHOULD be set to zero. 614 If a received Attribute subobject is not long enough to include a 615 specific numbered bit, that bit MUST be treated as though present and 616 as if set to zero. 618 If the RRO subobject is not present for a hop in the LSP, all bits 619 MUST be assumed to be set to zero. 621 8. Summary of Attribute Bit Allocation 623 This document defines two uses of per-LSP attribute flag bit fields. 624 The bit numbering in the Attributes Flags TLV and the RRO Attributes 625 subobject is identical. That is, the same attribute is indicated by 626 the same bit in both places. This means that only a single registry 627 of bits is maintained. 629 The consequence is a degree of clarity in implementation and 630 registration. 632 Note, however, that it is not always the case that a bit will be used 633 in both the Attributes Flags TLV and the RRO Attributes subobject. 634 For example, an attribute may be requested using the Attributes Flags 635 TLV, but there is no requirement to report the handling of the 636 attribute on a hop-by-hop basis. Conversely, there may be a 637 requirement to report the attributes of an LSP on a hop-by-hop basis, 638 but there is no corresponding request attribute. 640 In these cases, a single bit number is still assigned for both the 641 Attributes Flags TLV and the RRO Attributes subobject even though the 642 bit may be irrelevant in either the Attributes Flags or the RRO 643 Attributes subobject. The document that defines the usage of the new 644 bit MUST state in which places it is used and MUST handle a default 645 setting of zero. 647 9. Message Formats 649 The LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES object MAY 650 be carried in a Path message. The LSP_ATTRIBUTES object MAY be 651 carried in a Resv message. 653 The order of objects in RSVP-TE messages is recommended, but 654 implementations must be capable of receiving the objects in any 655 meaningful order. 657 On a Path message, the LSP_ATTRIBUTES object and LSP_REQUIRED_ 658 ATTRIBUTES objects are RECOMMENDED to be placed immediately after the 659 SESSION_ATTRIBUTE object if it is present, or otherwise immediately 660 after the LABEL_REQUEST object. 662 If both the LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES 663 object are present, the LSP_REQUIRED_ATTRIBUTES object is RECOMMENDED 664 to be placed first. 666 LSRs SHOULD be prepared to receive these objects in any order in any 667 position within a Path message. Subsequent instances of these objects 668 within a Path message SHOULD be ignored and those objects MUST be 669 forwarded unchanged. 671 On a Resv message, the LSP_ATTRIBUTES object is placed in the flow 672 descriptor and is associated with the FILTER_SPEC object that 673 precedes it. It is RECOMMENDED that the LSP_ATTRIBUTES object be 674 placed immediately after the LABEL object. 676 LSRs SHOULD be prepared to receive this object in any order in any 677 position within a Resv message subject to the previous note. Only 678 one instance of the LSP_ATTRIBUTES object is meaningful within the 679 context of a FILTER_SPEC object. Subsequent instances of the object 680 SHOULD be ignored and MUST be forwarded unchanged. 682 10. IANA Considerations 684 10.1 New RSVP C-Nums and C-Types 686 Two new RSVP C-Nums are defined in this document and should be 687 assigned by IANA. 689 o LSP_ATTRIBUTES object 691 The C-Num should be of the form 11bbbbbb so that LSRs that do not 692 recognize the object will ignore the object but forward it, 693 unexamined and unmodified, in all messages resulting from this 694 message. 696 One C-Type is defined for this object and should be assigned by 697 IANA. 699 o LSP Attributes TLVs 701 Recommended C-Type value 1. 703 o LSP_REQUIRED_ATTRIBUTES object 705 The C-Num should be of the form 0bbbbbbb so that LSRs that do not 706 recognize the object will reject the message that carries it with 707 an "Unknown Object Class" error. 709 One C-Type is defined for this object and should be assigned by 710 IANA. 712 o LSP Required Attributes TLVs 714 Recommended C-Type value 1. 716 10.2 New TLV Space 718 The two new objects referenced above are constructed from TLVs. Each 719 TLV includes a 16-bit type identifier (the T-field). The same T-field 720 values are applicable to both objects. 722 IANA is requested to manage TLV type identifiers as follows: 724 - TLV Type (T-field value) 725 - TLV Name 726 - Whether allowed on LSP_ATTRIBUTES object 727 - Whether allowed on LSP_REQUIRED_ATTRIBUTES object. 729 This document defines one TLV type as follows: 730 - TLV Type = 1 731 - TLV Name = Attributes Flags TLV 732 - allowed on LSP_ATTRIBUTES object 733 - allowed on LSP_REQUIRED_ATTRIBUTES object. 735 10.3 Attributes Flags 737 This document provides new attributes bit flags for use in other 738 documents that specify new RSVP-TE attributes. These flags are 739 present in the Attributes Flags TLV referenced in the previous 740 section. 742 IANA is requested to manage the space of attributes bit flags 743 numbering them in the usual IETF notation starting at zero and 744 continuing through 2039. 746 Each bit should be tracked with the following qualities: 747 - Bit number 748 - Defining RFC 749 - Name of bit 750 - Whether there is meaning in the Attribute Flags TLV on a Path 751 - Whether there is meaning in the Attribute Flags TLV on a Resv 752 - Whether there is meaning in the RRO Attributes Subobject. 754 Note that this means that all bits in the Attribute Flags TLV and the 755 RRO Attributes Subobject use the same bit number regardless of 756 whether they are used in one or both places. Thus, only one list of 757 bits is required to be maintained. (It would be meaningless in the 758 context of this document for a bit to have no meaning in neither the 759 Attribute Flags TLV nor the RRO Attributes Subobject.) 761 10.4 SESSION_ATTRIBUTE Flags Field 763 This document does not make any alterations to the definition of the 764 existing SESSION_ATTRIBUTE object nor to the definition of meanings 765 assigned to the flags in the Flags field of that object. These flags 766 are assigned meanings in various other RFCs and Internet Drafts. 768 It is suggested that IANA manage the allocation of meaning to the 769 bits in the Flags field of the SESSION_ATTRIBUTE object to prevent 770 accidental double allocation of any one bit. 772 10.5 New Error Codes 774 This document defines the following new error codes and error values. 775 Numeric values should be assigned by IANA. 777 Error Code Error Value 778 "Unknown Attributes TLV" Identifies the unknown TLV type code. 779 "Unknown Attributes Bit" Identifies the unknown Attribute Bit. 781 10.6 New Record Route Subobject Identifier 783 A new subobject is defined for inclusion in the RECORD_ROUTE object. 785 The RRO Attributes subobject is identified by a Type value of TBD. 787 11. Security Considerations 789 This document adds two new objects to the RSVP Path message as used 790 in MPLS and GMPLS signaling, and a new subobject to the RECORD_ROUTE 791 object carried on may RSVP messages. It does not introduce any new 792 direct security issues and the reader is referred to the security 793 considerations expressed in [RFC2205], [RFC3209] and [RFC3473]. 795 It is of passing note that any signaling request that indicates the 796 functional preferences or attributes of an MPLS LSP may provide 797 anyone with unauthorized access to the contents of the message with 798 information about the LSP that an administrator may wish to keep 799 secret. Although this document adds new objects for signaling desired 800 LSP attributes, it does not contribute to this issue which can 801 only be satisfactorily handled by encrypting the content of the 802 signaling message. 804 Similarly, the addition of attribute recording information to the 805 RRO may reveal information about the status of the LSP and the 806 capabilities of individual LSRs that operators wish to keep secret. 807 The same strategy that applies to other RRO subobjects also applies 808 here. Note, however, that there is a tension between notifying the 809 head end of the LSP status at transit LSRs, and hiding the existence 810 or identity of the transit LSRs. 812 12. Acknowledgements 814 Credit to the OSPF Working Group for inspiration from their solution 815 to a similar problem. Thanks to Rahul Aggarwal for his careful review 816 and support of this work. Thanks also to Raymond Zhang, Kireeti 817 Kompella, Philip Matthews, Jim Gibson and Alan Kullberg for their 818 input. As so often, thanks to John Drake for useful offline 819 discussions. 821 13. Intellectual Property Consideration 823 The IETF takes no position regarding the validity or scope of any 824 Intellectual Property Rights or other rights that might be claimed to 825 pertain to the implementation or use of the technology described in 826 this document or the extent to which any license under such rights 827 might or might not be available; nor does it represent that it has 828 made any independent effort to identify any such rights. Information 829 on the procedures with respect to rights in RFC documents can be 830 found in BCP 78 and BCP 79. 832 Copies of IPR disclosures made to the IETF Secretariat and any 833 assurances of licenses to be made available, or the result of an 834 attempt made to obtain a general license or permission for the use of 835 such proprietary rights by implementers or users of this 836 specification can be obtained from the IETF on-line IPR repository at 837 http://www.ietf.org/ipr. 839 The IETF invites any interested party to bring to its attention any 840 copyrights, patents or patent applications, or other proprietary 841 rights that may cover technology that may be required to implement 842 this standard. Please address the information to the IETF at ietf- 843 ipr@ietf.org. 845 14. Normative References 847 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 848 Requirement Levels", BCP 14, RFC 2119, March 1997. 850 [RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. 851 and S. Jamin, "Resource ReserVation Protocol -- 852 Version 1 Functional Specification", RFC 2205, 853 September 1997. 855 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., 856 Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions 857 to RSVP for LSP Tunnels", RFC 3209, December 2001. 859 [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label 860 Switching (GMPLS) Signaling Functional Description", 861 RFC 3471, January 2003. 863 [RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling - 864 RSVP-TE Extensions", RFC 3473 January 2003. 866 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, 867 RFC 3667, February 2004. 869 [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF 870 Technology", BCP 79, RFC 3668, February 2004. 872 15. Informative References 874 [RFC2026] Bradner, S., "The Internet Standards Process 875 -- Revision 3", RFC 2026, October 1996. 877 [RFC3031] Rosen, E., Viswanathan, A., and Callon, R., 878 "Multiprotocol Label Switching 879 Architecture", RFC 3031, January 2001. 881 [FRR] Pan, P. (Ed.), "Fast Reroute Extensions to RSVP-TE for 882 LSP Tunnels", , Internet Draft, work in progress. 885 [MPLS-HIER] Kompella, K. and Y. Rekhter, "LSP Hierarchy with 886 MPLS TE", Work in Progress. 888 16. Authors' Addresses 890 Adrian Farrel 891 Old Dog Consulting 892 Phone: +44 (0) 1978 860944 893 EMail: adrian@olddog.co.uk 895 Dimitri Papadimitriou (Alcatel) 896 Fr. Wellesplein 1, 897 B-2018 Antwerpen, Belgium 898 Phone: +32 3 240-8491 899 EMail: dimitri.papadimitriou@alcatel.be 900 Jean Philippe Vasseur 901 Cisco Systems, Inc. 902 300 Beaver Brook Road 903 Boxborough , MA - 01719 904 USA 905 EMail: jpv@cisco.com 907 Arthi Ayyangar 908 Juniper Networks, Inc. 909 1194 N.Mathilda Ave 910 Sunnyvale, CA 94089 911 USA 912 EMail: arthi@juniper.net 914 17. Disclaimer of Validity 916 This document and the information contained herein are provided on an 917 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 918 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 919 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 920 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 921 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 922 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 924 18. Full Copyright Statement 926 Copyright (C) The Internet Society (2004). This document is subject 927 to the rights, licenses and restrictions contained in BCP 78, and 928 except as set forth therein, the authors retain all their rights.