idnits 2.17.1 draft-ietf-mpls-rsvpte-attributes-05.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 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 974. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 887. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 894. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 900. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. 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 (May 2005) is 6920 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 215, but not defined == Unused Reference: 'RFC2119' is defined on line 904, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 925, but no explicit reference was found in the text Summary: 5 errors (**), 0 flaws (~~), 5 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 Updates: RFC3209 and RFC3473 Old Dog Consulting 3 Category: Standards Track Dimitri Papadimitriou 4 Expires: November 2005 Alcatel 5 Jean-Philippe Vasseur 6 Cisco Systems, Inc. 7 Arthi Ayyangar 8 Juniper Networks 10 May 2005 12 Encoding of Attributes for Multiprotocol Label Switching (MPLS) 13 Label Switched Path (LSP) Establishment Using RSVP-TE 15 draft-ietf-mpls-rsvpte-attributes-05.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Contents 62 1. Introduction and Problem Statement 3 63 1.1 Applicability to Generalized MPLS 4 64 1.2 A Rejected Alternate Solution 4 65 2. Terminology 5 66 3. Attributes TLVs 5 67 3.1 Attributes Flags TLV 6 68 4. LSP_ATTRIBUTES Object 6 69 4.1 Format 7 70 4.2 Generic Processing Rules for Path Messages 7 71 4.3 Generic Processing Rules for Resv Messages 8 72 5. LSP_REQUIRED_ATTRIBUTES Object 8 73 5.1 Format 9 74 5.2 Generic Processing Rules 9 75 6. Inheritance Rules 10 76 7. Recording Attributes Per-LSP 10 77 7.1 Requirements 10 78 7.2 RRO Attributes Subobject 10 79 7.3 Procedures 11 80 7.3.1 Subobject Presence Rules 11 81 7.3.2 Reporting Compliance with LSP Attributes 12 82 7.3.3 Reporting Per-Hop Attributes 12 83 7.3.4 Default Behavior 12 84 8. Summary of Attribute Bit Allocation 12 85 9. Message Formats 13 86 10. Guidance for Key Application Scenarios 14 87 10.1 Communicating to Egress LSRs 14 88 10.2 Communicating to Key Transit LSRs 15 89 10.3 Communicating to All LSRs 15 90 11. IANA Considerations 15 91 11.1 New RSVP C-Nums and C-Types 15 92 11.2 New TLV Space 16 93 11.3 Attributes Flags 16 94 11.4 SESSION_ATTRIBUTE Flags Field 17 95 11.5 New Error Codes 17 96 11.6 New Record Route Subobject Identifier 17 97 12. Security Considerations 17 98 13. Acknowledgements 18 99 14. Intellectual Property Consideration 18 100 15. Normative References 18 101 16. Informative References 19 102 17. Authors' Addresses 19 103 18. Disclaimer of Validity 20 104 19. Full Copyright Statement 20 106 1. Introduction and Problem Statement 108 Traffic Engineered Multiprotocol Label Switching (MPLS) Label 109 Switched Paths (LSPs) [RFC3031] may be set up using the Path message 110 of the RSVP-TE signaling protocol [RFC3209]. The Path message 111 includes the SESSION_ATTRIBUTE object which carries a flags field 112 used to indicate desired options and attributes of the LSP. 114 The flags field in the SESSION_ATTRIBUTE object has eight bits. Just 115 three of those bits are assigned in [RFC3209]. A further two bits are 116 assigned in [FRR] for fast re-reroute functionality leaving only 117 three bits available. Several recent proposals and Internet Drafts 118 have demonstrated that there is a high demand for the use of the 119 other three bits. Some, if not all, of those proposals are likely to 120 go forward as RFCs resulting in depletion or near depletion of the 121 flags field and a consequent difficulty in signaling new options and 122 attributes that may be developed in the future. 124 This document defines a new object for RSVP-TE messages that allows 125 the signaling of further attributes bits. The new object is 126 constructed from TLVs, and a new TLV is defined to carry a variable 127 number of attributes bits. 128 The new RSVP-TE message object is quite flexible, due to the use of 129 the TLV format and allows: 130 - future specification of bit flags 131 - additional options and atttribute paramerters carried in TLV 132 format. 134 Note that the LSP Attributes defined in this document are 135 specifically scoped to an LSP. They may be set differently on 136 separate LSPs with the same Tunnel ID between the same source and 137 destination (that is, within the same Session). 139 It is noted that some options and attributes do not need to be 140 acted on by all Label Switched Routers (LSRs) along the path of the 141 LSP. In particular, these options and attributes may apply only to 142 key LSRs on the path such as the ingress LSR and egress LSR. Special 143 transit LSRs, such as Area or AS Border Routers (ABRs/ASBRs) may also 144 fall into this category. This means that the new options and 145 attributes should be signaled transparently, and only examined at 146 those points that need to act on them. 148 On the other hand, other options and attributes may require action 149 at all transit LSRs along the path of the LSP. Inability to support 150 the required attributes by one of those transit LSRs may require the 151 LSR to refuse the establishment of the LSP. 153 These considerations are particularly important in the context of 154 backwards compatibility. In general, it should be possible to provide 155 new MPLS services across a legacy network without upgrading those 156 LSRs that do not need to participate actively in the new services. 158 Moreover, some features just require action on specific intermediate 159 hops, and not on every visited LSR. 161 Note that options already specified for the SESSION_ATTRIBUTE object 162 in pre-existing RFCs are not migrated to the new mechanisms described 163 in this document. 165 RSVP includes a way for unrecognized objects to be transparently 166 forwarded by transit nodes without them refusing the incoming 167 protocol messages and without the objects being stripped from the 168 outgoing protocol message (see [RFC2205] Section 3.10). This 169 capability extends to RSVP-TE and provides a good way to ensure that 170 only those LSRs that understand a particular object examine it. 172 This document distinguishes between options and attributes that are 173 only required at key LSRs along the path of the LSP, and those that 174 must be acted on by every LSR along the LSP. Two LSP Attributes 175 objects are defined in this document: using the C-Num definition 176 rules inherrited from [RFC2205], the first is passed transparently 177 by LSRs that do not recognize it, and the second causes LSP setup 178 failure with the generation of a PathErr message with an 179 appropriate Error Code if an LSR does not recognize it. 181 1.1 Applicability to Generalized MPLS 183 The RSVP-TE signaling protocol also forms the basis of a signaling 184 protocol for Generalized MPLS (GMPLS) as described in [RFC3471] and 185 [RFC3473]. The extensions described in this document are equally 186 applicable to MPLS and GMPLS. 188 1.2 A Rejected Alternate Solution 190 A rejected alternate solution was to define a new C-Type for the 191 existing SESSION_ATTRIBUTE object. This new C-Type could allow a 192 larger Flags field and address the immediate problem. 194 This solution was rejected because: 195 - A new C-Type is not backward compatible with deployed 196 implementations that expect to see a C-Type of 1 or 7. It is 197 important that any solution be capable of carrying new attributes 198 transparently across legacy LSRs if those LSRs are not required to 199 act on the attributes. 200 - Support for arbitrary attributes parameters through TLVs would 201 have meant a significant change of substance to the existing 202 object. 204 2. Terminology 206 This document uses terminology from the MPLS architecture document 207 [RFC3031] and from the RSVP-TE protocol specification [RFC3209] which 208 inherits from the RSVP specification [RFC2205]. It also makes uses of 209 the Generalized MPLS RSVP-TE terminology introduced in [RFC3471] and 210 [RFC3473]. 212 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 213 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 214 document are to be interpreted as described in [RFC2219]. 216 3. Attributes TLVs 218 Attributes carried by the new objects defined in this document are 219 encoded within TLVs. One or more TLVs may be present in each object. 220 There are no ordering rules for TLVs and no interpretation should be 221 placed on the order in which TLVs are received. 223 Each TLV is encoded as follows. 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Type | Length | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | | 231 // Value // 232 | | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Type 237 The identifier of the TLV. 239 Length 241 The length of the value field in bytes. Thus if no value 242 field is present the length field contains the value zero. 243 Each value field must be zero padded at the end to take it 244 up to a four byte boundary - the padding is not included in 245 the length so that a one byte value would be encoded in an 246 eight byte TLV with length field set to one. 248 Value 250 The data for the TLV padded as described above. 252 3.1 Attributes Flags TLV 254 This document defines only one TLV type value. Type 1 indicates the 255 Attributes Flags TLV. Other TLV types may be defined in future with 256 type values assigned by IANA (see section 11.2). 258 The Attributes Flags TLV may be present in an LSP_ATTRIBUTES object 259 and/or an LSP_REQUIRED_ATTRIBUTES object defined in Sections 4 and 5. 260 The bits in the TLV represent the same attributes regardless of which 261 object carries the TLV. Documents that define individual bits MUST 262 specify whether the bit may be set in one object or the other, or 263 both. It is not expected that a bit will be set in both objects on a 264 single Path message at the same time, but this is not ruled out by 265 this document. 267 The Attribute Flags TLV value field is an array of units of 32 flags 268 numbered from the MSB as bit zero. The length field for this TLV is 269 therefore always a multiple of 4 bytes, regardless of the number of 270 bits carried and no padding is required. 272 Unassigned bits are considered as reserved and MUST be set to zero 273 on transmission by the originator of the object. Bits not contained 274 in the TLV MUST be assumed to be set to zero. If the TLV is absent 275 either because it is not contained in the LSP_ATTRIBUTES or 276 LSP_REQUIRED_ATTRIBUTES object, or because those objects are 277 themselves absent, all processing MUST be performed as though the 278 bits were present and set to zero. That is to say, assigned bits that 279 are not present either because the TLV is deliberatley forshortened, 280 or because the TLV is not included MUST be treated as though they are 281 present and are set to zero. 283 No bits are defined in this document. The assignment of bits is 284 managed by IANA (see section 11.3). 286 4. LSP_ATTRIBUTES Object 288 The LSP_ATTRIBUTES object is used to signal attributes required in 289 support of an LSP, or to indicate the nature or use of an LSP where 290 that information is not required to be acted on by all transit LSRs. 291 Specifically, if an LSR does not support the object, it forwards it 292 unexamined and unchanged. This facilitates the exchange of attributes 293 across legacy networks that do not support this new object. 295 This object effectively extends the flags field in the SESSION_ 296 ATTRIBUTE object and allows for the future inclusion of more complex 297 objects through TLVs. 299 Note that some function may require an LSR to inspect both the 300 SESSION_ATTRIBUTE object, and the LSP_ATTRIBUTES or 301 LSP_REQUIRED_ATTRIBUTES object. 303 The LSP_ATTRIBUTES object may also be used to report LSP operational 304 state on a Resv even when no LSP_ATTRIBUTES or LSP_REQUIRED_ 305 ATTRIBUTES object was carried on the corresponding Path message. The 306 object is added or updated by LSRs that support the object. LSRs that 307 do not understand the object or have nothing to report, do not add 308 the object and forward it unchanged on Resv messages that they 309 generate. 311 The LSP_ATTRIBUTES object class is TBD of the form 11bbbbbb. This 312 C-Num value (see Section 8) ensures that LSRs that do not recognize 313 the object pass it on transparently. 315 One C-Type is defined, C-Type = 1 for LSP Attributes. 317 This object is optional and may be placed on Path messages to convey 318 additional information about the desired attributes of the LSP, and. 319 on Resv messages to report operational state. 321 4.1 Format 323 LSP_ATTRIBUTES class = TBD, C-Type = 1 325 0 1 2 3 326 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 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | | 329 // Attributes TLVs // 330 | | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 The Attributes TLVs are encoded as described in Section 3. 335 4.2 Generic Processing Rules for Path Messages 337 An LSR that does not support this object is required to pass it on 338 unaltered as indicated by the C-Num and the rules defined in 339 [RFC2205]. 341 An LSR that does support this object, but does not recognize a TLV 342 type code carried in this object MUST pass the TLV on unaltered 343 in the LSP_ATTRIBUTES object that it places in the Path message 344 that it sends downstream. 346 An LSR that does support this object and recognizes a TLV but does 347 not support the attribute defined by the TLV MUST act as specified in 348 the document that defines the TLV. 350 An LSR that supports the Attributes Flags TLV, but does not 351 recognize a bit set in the Attributes Flags TLV MUST forward the 352 TLV unchanged. 354 An LSR that supports the Attributes Flags TLV and recognizes a bit 355 that is set but does not support the indicated attribute MUST act as 356 specified in the document that defines the bit. 358 4.3 Generic Processing Rules for Resv Messages 360 An LSR that wishes to report operational status of an LSP may include 361 this object in a Resv message, or update the object that is already 362 carried in a Resv message. 364 Note that this usage reports the state of the entire LSP and not the 365 state of the LSP at an individual LSR. This latter function is 366 achieved using the LSP Attributes subobject of the Record Route 367 object as described in Section 7. 369 The bits in the Attributes TLV may be used to report operational 370 status for the whole LSP. For example, an egress LSR may report a 371 particular status by setting a bit. LSRs within the network that 372 determine that this status has not been achieved may clear the bit 373 as they forward the Resv message. 375 Observe that LSRs that do not support the object or do not support 376 the function characterized by a particular bit in the Attributes TLV 377 will not clear the bit when forwarding the Resv. Thus, care must be 378 taken in defining the usage of this object on a Resv. The usage of 379 an individual bit in the Attributes TLV of the LSP_ATTRIBUTES object 380 on a Resv must be fully defined in the document that defines the bit. 382 Additional TLVs may also be defined to be carried in this object on 383 a Resv. 385 An LSR that does not support this object will pass it on unaltered 386 because of the C-Num. 388 5. LSP_REQUIRED_ATTRIBUTES Object 390 The LSP_REQUIRED_ATTRIBUTES object is used to signal attributes 391 required in support of an LSP, or to indicate the nature or use of 392 an LSP where that information MUST be inspected at each transit LSR. 393 Specifically, each transit LSR MUST examine the attributes in the 394 LSP_REQUIRED_ATTRIBUTES object and MUST NOT forward the object 395 without acting on its contents. 397 This object effectively extends the flags field in the SESSION_ 398 ATTRIBUTE object and allows for the future inclusion of more complex 399 objects through TLVs. It complements the LSP_ATTRIBUTES object. 401 The LSP_REQUIRED_ATTRIBUTES object class is TBD of the form 0bbbbbbb. 402 This C-Num value ensures that LSRs that do not recognize the object 403 reject the LSP setup effectively saying that they do not support the 404 attributes requested. This means that this object SHOULD only be used 405 for attributes that require support at some transit LSRs and so 406 require examination at all transit LSRs. See Section 4 for how end- 407 to-end and selective attributes are signaled. 409 One C-Type is defined, C-Type = 1 for LSP Required Attributes. 411 This object is optional and may be placed on Path messages to convey 412 additional information about the desired attributes of the LSP. 414 5.1 Format 416 LSP_REQUIRED_ATTRIBUTES class = TBD, C-Type = 1 418 0 1 2 3 419 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 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | | 422 // Attributes TLVs // 423 | | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 The Attributes TLVs are encoded as described in Section 3. 428 5.2 Generic Processing Rules 430 An LSR that does not support this object will use a PathErr to reject 431 the Path message based on the C-Num using the error code "Unknown 432 Object Class". 434 An LSR that does not recognize a TLV type code carried in this object 435 MUST reject the Path message using a PathErr with Error Code 436 "Unknown Attributes TLV" and Error Value set to the value of the 437 unknown TLV type code. 439 An LSR that does not recognize a bit set in the Attributes Flags 440 TLV MUST reject the Path message using a PathErr with Error Code 441 "Unknown Attributes Bit" and Error Value set to the bit number of 442 the unknown bit in the Attributes Flags. 444 An LSR that recognizes an attribute, however encoded, but which does 445 not support that attribute MUST act according to the behavior 446 specified in the document that defines that specific attribute. 448 Note that this object is not used on a Resv. In order to report the 449 status of an LSP either the LSP_ATTRIBUTES object on a Resv or the 450 Attributes subobject in the Record Route object (see Section 7) must 451 be used. 453 6. Inheritance Rules 455 In certain circumstances, when reaching an LSP region boundary, a 456 FA-LSP (see [MPLS-HIER]) is initially setup to allow the 457 establishment of the LSP carrying the LSP ATTRIBUTES and/or 458 LSP_REQUIRED_ATTRIBUTES objects. In this case, when the boundary LSR 459 supports LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES processing, the 460 FA-LSP MAY upon local policy inherit a subset of the Attributes TLVs, 461 in particular when the FA-LSP belongs to the same switching 462 capability class as the triggering LSP. 464 When these conditions are met, the LSP_ATTRIBUTES and/or 465 LSP_REQUIRED_ATTRIBUTES objects are simply copied with the inherited 466 Attributes TLVs in the Path message used to establish the FA-LSP. By 467 default (and in order to simplify deployment), none of the incoming 468 LSP Attributes TLV are considered as inheritable. Note that when the 469 FA-LSP establishment itself requires one or more Attributes TLVs, an 470 'OR' operation is performed with the inherited set of values. 472 Documents that define individual bits for the LSP Attributes Flags 473 TLV MUST specify whether these bits MAY be inherited or not 474 (including the condition to be met in order for this inheritance to 475 occur). The same applies for any other TLV that will be defined 476 following the rules specified in Section 3. 478 7. Recording Attributes Per-LSP 480 7.1 Requirements 482 In some circumstances it is useful to determine which of the 483 requested LSP attributes have been applied at which LSRs along the 484 path of the LSP. For example, an attribute may be requested in the 485 LSP_ATTRIBUTES object such that LSRs that do not support the object 486 are not required to support the attribute or provide the requested 487 function. In this case, it may be useful to the ingress LSR to know 488 which LSRs acted on the request and which ignored it. 490 Additionally, there may be other qualities that need to be reported 491 on a hop-by-hop basis. These are currently indicated in the Flags 492 field of RRO subobjects. Since there are only eight bits available 493 in this field, and since some are already assigned and there is also 494 likely to be an increase in allocations in new documents, there is a 495 need for some other method to report per-hop attributes. 497 7.2 RRO Attributes Subobject 499 The RRO Attributes Subobject may be carried in the RECORD_ROUTE 500 object if it is present. The subobject uses the standard format of 501 an RRO subobject. 503 The length is variable as for the Attributes Flags TLV. The content 504 is the same as the Attribute Flags TLV - that is, it is a series of 505 bit flags. 507 There is a one-to-one correspondence between bits in the Attributes 508 Flags TLV and the RRO Attributes Subobject. If a bit is only required 509 in one of the two places, it is reserved in the other place. See 510 the procedures sections, below, for more information. 512 0 1 2 3 513 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 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | Type | Length | Reserved | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | | 518 // Attribute Flags // 519 | | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 Type 524 0x?? TBD by IANA RRO Attribute Subobject (see section 11.6). 526 Length 528 The Length contains the total length of the subobject in bytes, 529 including the Type and Length fields. This length must be a 530 multiple of 4 and must be at least 8. 532 Attribute Flags 534 The attribute flags recorded for the specific hop. 536 7.3 Procedures 538 7.3.1 Subobject Presence Rules 540 As will be clear from [RFC3209], the RECORD_ROUTE object is managed 541 as a "stack" with each LSR adding sub-objects to the start of the 542 object. The Attributes subobject is pushed onto the RECORD_ROUTE 543 object immediately prior to pushing the node's IP address or link 544 identifier. Thus, if label recording is being used, the Attributes 545 subobject SHOULD be pushed onto the RECORD_ROUTE object after the 546 Record Label subobject(s). 548 A node MUST NOT push an Attributes subobject on to the RECORD_ROUTE 549 object without also pushing an IPv4, IPv6 or Unnumbered Interface ID 550 subobject. 552 This means that an Attributes subobject is bound to the LSR 553 identified by the subobject found in the RRO immediately before the 554 Attributes subobject. 556 If the new subobject causes the RRO to be too big to fit in a Path 557 (or Resv) message, the processing MUST be as described in section 558 4.4.3 of [RFC3209]. 560 If more than one Attributes subobject is found between a pair of 561 subobjects that identify LSRs, only the first one found (that is, the 562 nearest to the top of the stack) SHALL have any meaning within the 563 context of this document. All such subobjects MUST be forwarded 564 unmodified by transit LSRs. 566 7.3.2 Reporting Compliance with LSP Attributes 568 To report compliance with an attribute requested in the Attributes 569 Flags TLV, an LSR MAY set the corresponding bit (see Section 8) in 570 the Attributes subobject. To report non-compliance, an LSR MAY clear 571 the corresponding bit in the Attributes subobject. 573 The requirement to report compliance MUST be specified in the 574 document that defines the usage of any bit. This will reduce to a 575 statement of whether hop-by-hop acknowledgement is required. 577 7.3.3 Reporting Per-Hop Attributes 579 To report a per-hop attribute, an LSR sets the appropriate bit in the 580 Attributes subobject. 582 The requirement to report a per-hop attribute MUST be specified in 583 the document that defines the usage of the bit. 585 7.3.4 Default Behavior 587 By default all bits in an Attributes subobject SHOULD be set to zero. 589 If a received Attribute subobject is not long enough to include a 590 specific numbered bit, that bit MUST be treated as though present and 591 as if set to zero. 593 If the RRO subobject is not present for a hop in the LSP, all bits 594 MUST be assumed to be set to zero. 596 8. Summary of Attribute Bit Allocation 598 This document defines two uses of per-LSP attribute flag bit fields. 599 The bit numbering in the Attributes Flags TLV and the RRO Attributes 600 subobject is identical. That is, the same attribute is indicated by 601 the same bit in both places. This means that only a single registry 602 of bits is maintained. 604 The consequence is a degree of clarity in implementation and 605 registration. 607 Note, however, that it is not always the case that a bit will be used 608 in both the Attributes Flags TLV and the RRO Attributes subobject. 609 For example, an attribute may be requested using the Attributes Flags 610 TLV, but there is no requirement to report the handling of the 611 attribute on a hop-by-hop basis. Conversely, there may be a 612 requirement to report the attributes of an LSP on a hop-by-hop basis, 613 but there is no corresponding request attribute. 615 In these cases, a single bit number is still assigned for both the 616 Attributes Flags TLV and the RRO Attributes subobject even though the 617 bit may be irrelevant in either the Attributes Flags or the RRO 618 Attributes subobject. The document that defines the usage of the new 619 bit MUST state in which places it is used and MUST handle a default 620 setting of zero. 622 9. Message Formats 624 The LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES object MAY 625 be carried in a Path message. The LSP_ATTRIBUTES object MAY be 626 carried in a Resv message. 628 The order of objects in RSVP-TE messages is recommended, but 629 implementations must be capable of receiving the objects in any 630 meaningful order. 632 On a Path message, the LSP_ATTRIBUTES object and LSP_REQUIRED_ 633 ATTRIBUTES objects are RECOMMENDED to be placed immediately after the 634 SESSION_ATTRIBUTE object if it is present, or otherwise immediately 635 after the LABEL_REQUEST object. 637 If both the LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES 638 object are present, the LSP_REQUIRED_ATTRIBUTES object is RECOMMENDED 639 to be placed first. 641 LSRs MUST be prepared to receive these objects in any order in any 642 position within a Path message. Subsequent instances of these objects 643 within a Path message SHOULD be ignored and those objects MUST be 644 forwarded unchanged. 646 On a Resv message, the LSP_ATTRIBUTES object is placed in the flow 647 descriptor and is associated with the FILTER_SPEC object that 648 precedes it. It is RECOMMENDED that the LSP_ATTRIBUTES object be 649 placed immediately after the LABEL object. 651 LSRs MUST be prepared to receive this object in any order in any 652 position within a Resv message subject to the previous note. Only 653 one instance of the LSP_ATTRIBUTES object is meaningful within the 654 context of a FILTER_SPEC object. Subsequent instances of the object 655 SHOULD be ignored and MUST be forwarded unchanged. 657 10. Guidance for Key Application Scenarios 659 As described in the Introduction section of this document, it may be 660 that requested LSP attributes need to be acted on by only the egress 661 LSR of the LSP, by certain key transit points (such as ABRs and 662 ASBRs) or by all LSRs along the LSP. This section briefly describes 663 how each of these scenarios is met. This section is informational and 664 does not define any new procedures. 666 10.1. Communicating to Egress LSRs 668 When communicating LSP attributes that must be acted on only by the 669 LSP egress LSR, the attributes should be communicated in the 670 LSP_ATTRIBUTES object. Because of its C-Num, this object may be 671 ignored (passed onwards, untouched) by transit LSRs that do not 672 understand it. This means that the Path message will not be rejected 673 by LSRs that do not understand the object. In this way, the requested 674 LSP attributes are guaranteed to reach the egress LSR. 676 Attributes are set within the LSP_ATTRIBUTES object according to 677 which LSP attributes are required. Each attribute is defined in some 678 RFC and is accompanied by a statement of what the expected behavior 679 is. This behavior will include whether the attribute must be acted on 680 by any LSR that recognises it, or specifically by the egress LSR. 681 Thus any attribute that must be acted on only by an egress LSR will 682 be defined in this way - any transit LSR seeing this attribute will 683 either understand the semantics of the attribute and ignore it 684 (forwarding it, unchanged), or will not understand the attribute and 685 will ignore it (forwarding it, unchanged) according to the rules of 686 the LSP_ATTRIBUTES object. 688 The remaining issue is how the ingress LSR can know whether the 689 egress LSR has acted correctly on the required LSP attribute. Another 690 part of the definition of the attribute (in the defining RFC) is 691 whether reporting is required. If reporting is required, the egress 692 LSR is required to use the RRO Attributes subobject to report whether 693 it has acted on the received attribute. 695 If an egress LSR understands a received attribute as mandatory for an 696 egress LSR, but does not wish to satisfy the request, it will reject 697 the Path message. If an egress LSR understands the attribute, but 698 believes it to be optional and does not wish to satisfy the request, 699 it will report its non-compliance in the RRO Attributes subobject. If 700 the egress LSR does not understand the received attribute, it may 701 report non-compliance in the RRO Attributes subobject explicitly, or 702 may omit the RRO Attributes subobject implying that it has not 703 satisfied the request. 705 10.2. Communicating to Key Transit LSRs 707 Processing for key transit LSRs (such as ABRs and ASBRs) follows 708 exactly as for egress LSR. The only difference is that the definition 709 of the LSP attribute in the defining RFC will state that the 710 attribute must be acted on by these transit LSRs. 712 10.3. Communicating to All LSRs 714 In order to force all LSRs to examine the LSP attributes, the 715 LSP_REQUIRED_ATTRIBUTES object is used. The C-Num of this object is 716 such that any LSR that does not recognise the object must reject a 717 received Path message containing the object. 719 An LSR that recognises the LSP_REQUIRED_ATTRIBUTES object, but that 720 does not recognize an attributes will reject the Path message. 722 An LSR that recognizes an attribute, but which does not wish to 723 support the attribute reacts according to the definition of the 724 attribute in the defining RFC. This may allow the LSR to ignore the 725 attribute and forward it unchanged, or may require it to fail the LSP 726 setup. The LSR may additionally be required to report whether it 727 supports the attribute using the RRO Attributes subobject. 729 11. IANA Considerations 731 11.1 New RSVP C-Nums and C-Types 733 Two new RSVP C-Nums are defined in this document and should be 734 assigned by IANA. 736 o LSP_ATTRIBUTES object 738 The C-Num should be of the form 11bbbbbb so that LSRs that do not 739 recognize the object will ignore the object but forward it, 740 unexamined and unmodified, in all messages resulting from this 741 message. 743 One C-Type is defined for this object and should be assigned by 744 IANA. 746 o LSP Attributes TLVs 748 Recommended C-Type value 1. 750 o LSP_REQUIRED_ATTRIBUTES object 752 The C-Num should be of the form 0bbbbbbb so that LSRs that do not 753 recognize the object will reject the message that carries it with 754 an "Unknown Object Class" error. 756 One C-Type is defined for this object and should be assigned by 757 IANA. 759 o LSP Required Attributes TLVs 761 Recommended C-Type value 1. 763 11.2 New TLV Space 765 The two new objects referenced above are constructed from TLVs. Each 766 TLV includes a 16-bit type identifier (the T-field). The same T-field 767 values are applicable to both objects. 769 IANA is requested to manage TLV type identifiers as follows: 771 - TLV Type (T-field value) 772 - TLV Name 773 - Whether allowed on LSP_ATTRIBUTES object 774 - Whether allowed on LSP_REQUIRED_ATTRIBUTES object. 776 This document defines one TLV type as follows: 777 - TLV Type = 1 778 - TLV Name = Attributes Flags TLV 779 - allowed on LSP_ATTRIBUTES object 780 - allowed on LSP_REQUIRED_ATTRIBUTES object. 782 New TLV type values may be allocated only by an IETF Consensus 783 action. 785 11.3 Attributes Flags 787 This document provides new attributes bit flags for use in other 788 documents that specify new RSVP-TE attributes. These flags are 789 present in the Attributes Flags TLV referenced in the previous 790 section. 792 IANA is requested to manage the space of attributes bit flags 793 numbering them in the usual IETF notation starting at zero and 794 continuing at least through 31. 796 New bit numbers may be allocated only by an IETF Consensus action. 798 Each bit should be tracked with the following qualities: 799 - Bit number 800 - Defining RFC 801 - Name of bit 802 - Whether there is meaning in the Attribute Flags TLV on a Path 803 - Whether there is meaning in the Attribute Flags TLV on a Resv 804 - Whether there is meaning in the RRO Attributes Subobject. 806 Note that this means that all bits in the Attribute Flags TLV and the 807 RRO Attributes Subobject use the same bit number regardless of 808 whether they are used in one or both places. Thus, only one list of 809 bits is required to be maintained. (It would be meaningless in the 810 context of this document for a bit to have no meaning in neither the 811 Attribute Flags TLV nor the RRO Attributes Subobject.) 813 11.4 SESSION_ATTRIBUTE Flags Field 815 This document does not make any alterations to the definition of the 816 existing SESSION_ATTRIBUTE object nor to the definition of meanings 817 assigned to the flags in the Flags field of that object. These flags 818 are assigned meanings in various other RFCs and Internet Drafts. 820 It is suggested that IANA manage the allocation of meaning to the 821 bits in the Flags field of the SESSION_ATTRIBUTE object to prevent 822 accidental double allocation of any one bit. 824 It is suggested that new SESSION_ATTRIBUTE Flags be allocated only by 825 an IETF Consensus action. 827 11.5 New Error Codes 829 This document defines the following new error codes and error values. 830 Numeric values should be assigned by IANA. 832 Error Code Error Value 833 "Unknown Attributes TLV" Identifies the unknown TLV type code. 834 "Unknown Attributes Bit" Identifies the unknown Attribute Bit. 836 11.6 New Record Route Subobject Identifier 838 A new subobject is defined for inclusion in the RECORD_ROUTE object. 840 The RRO Attributes subobject is identified by a Type value of TBD. 842 12. Security Considerations 844 This document adds two new objects to the RSVP Path message as used 845 in MPLS and GMPLS signaling, and a new subobject to the RECORD_ROUTE 846 object carried on may RSVP messages. It does not introduce any new 847 direct security issues and the reader is referred to the security 848 considerations expressed in [RFC2205], [RFC3209] and [RFC3473]. 850 It is of passing note that any signaling request that indicates the 851 functional preferences or attributes of an MPLS LSP may provide 852 anyone with unauthorized access to the contents of the message with 853 information about the LSP that an administrator may wish to keep 854 secret. Although this document adds new objects for signaling desired 855 LSP attributes, it does not contribute to this issue which can 856 only be satisfactorily handled by encrypting the content of the 857 signaling message. 859 Similarly, the addition of attribute recording information to the 860 RRO may reveal information about the status of the LSP and the 861 capabilities of individual LSRs that operators wish to keep secret. 862 The same strategy that applies to other RRO subobjects also applies 863 here. Note, however, that there is a tension between notifying the 864 head end of the LSP status at transit LSRs, and hiding the existence 865 or identity of the transit LSRs. 867 13. Acknowledgements 869 Credit to the OSPF Working Group for inspiration from their solution 870 to a similar problem. Thanks to Rahul Aggarwal for his careful review 871 and support of this work. Thanks also to Raymond Zhang, Kireeti 872 Kompella, Philip Matthews, Jim Gibson and Alan Kullberg for their 873 input. As so often, thanks to John Drake for useful offline 874 discussions. Thanks to Mike Shand for providing the Routing 875 Directorate review and to Joel Halpern for the General Area review - 876 both picked up on some unclarities. 878 14. Intellectual Property Consideration 880 The IETF takes no position regarding the validity or scope of any 881 Intellectual Property Rights or other rights that might be claimed to 882 pertain to the implementation or use of the technology described in 883 this document or the extent to which any license under such rights 884 might or might not be available; nor does it represent that it has 885 made any independent effort to identify any such rights. Information 886 on the procedures with respect to rights in RFC documents can be 887 found in BCP 78 and BCP 79. 889 Copies of IPR disclosures made to the IETF Secretariat and any 890 assurances of licenses to be made available, or the result of an 891 attempt made to obtain a general license or permission for the use of 892 such proprietary rights by implementers or users of this 893 specification can be obtained from the IETF on-line IPR repository at 894 http://www.ietf.org/ipr. 896 The IETF invites any interested party to bring to its attention any 897 copyrights, patents or patent applications, or other proprietary 898 rights that may cover technology that may be required to implement 899 this standard. Please address the information to the IETF at ietf- 900 ipr@ietf.org. 902 15. Normative References 904 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 905 Requirement Levels", BCP 14, RFC 2119, March 1997. 907 [RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. 908 and S. Jamin, "Resource ReserVation Protocol -- 909 Version 1 Functional Specification", RFC 2205, 910 September 1997. 912 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., 913 Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions 914 to RSVP for LSP Tunnels", RFC 3209, December 2001. 916 [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label 917 Switching (GMPLS) Signaling Functional Description", 918 RFC 3471, January 2003. 920 [RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling - 921 RSVP-TE Extensions", RFC 3473 January 2003. 923 16. Informative References 925 [RFC2026] Bradner, S., "The Internet Standards Process 926 -- Revision 3", RFC 2026, October 1996. 928 [RFC3031] Rosen, E., Viswanathan, A., and Callon, R., 929 "Multiprotocol Label Switching 930 Architecture", RFC 3031, January 2001. 932 [FRR] Pan, P. (Ed.), "Fast Reroute Extensions to RSVP-TE for 933 LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute, 934 work in progress. 936 [MPLS-HIER] Kompella, K. and Y. Rekhter, "LSP Hierarchy with 937 MPLS TE", draft-ietf-mpls-lsp-hierarchy, work in 938 progress. 940 17. Authors' Addresses 942 Adrian Farrel 943 Old Dog Consulting 944 Phone: +44 (0) 1978 860944 945 EMail: adrian@olddog.co.uk 947 Dimitri Papadimitriou (Alcatel) 948 Fr. Wellesplein 1, 949 B-2018 Antwerpen, Belgium 950 Phone: +32 3 240-8491 951 EMail: dimitri.papadimitriou@alcatel.be 952 Jean Philippe Vasseur 953 Cisco Systems, Inc. 954 300 Beaver Brook Road 955 Boxborough , MA - 01719 956 USA 957 EMail: jpv@cisco.com 959 Arthi Ayyangar 960 Juniper Networks, Inc. 961 1194 N.Mathilda Ave 962 Sunnyvale, CA 94089 963 USA 964 EMail: arthi@juniper.net 966 18. Disclaimer of Validity 968 This document and the information contained herein are provided on an 969 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 970 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 971 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 972 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 973 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 974 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 976 19. Full Copyright Statement 978 Copyright (C) The Internet Society (2005). This document is subject 979 to the rights, licenses and restrictions contained in BCP 78, and 980 except as set forth therein, the authors retain all their rights.