idnits 2.17.1 draft-ietf-ccamp-rfc4420bis-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 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1013. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 984. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 991. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 997. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. == 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 IETF Trust 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 4420 (Obsoleted by RFC 5420) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Adrian Farrel (Editor) 2 Network Working Group Old Dog Consulting 3 Obsoletes: RFC4420 Dimitri Papadimitriou 4 Updates: RFC3209, RFC3473 Alcatel 5 Category: Standards Track Jean-Philippe Vasseur 6 Created: May 27, 2008 Cisco Systems, Inc. 7 Expires: November 27, 2008 Arthi Ayyangar 8 Juniper Networks 10 Encoding of Attributes for Multiprotocol Label Switching (MPLS) 11 Label Switched Path (LSP) Establishment Using RSVP-TE 13 draft-ietf-ccamp-rfc4420bis-03.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be 35 accessed at http://www.ietf.org/shadow.html. 37 Abstract 39 Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may 40 be established using the Resource Reservation Protocol Traffic 41 Engineering (RSVP-TE) extensions. This protocol includes an object 42 (the SESSION_ATTRIBUTE object) that carries a Flags field used to 43 indicate options and attributes of the LSP. That Flags field has 44 eight bits allowing for eight options to be set. Recent proposals in 45 many documents that extend RSVP-TE have suggested uses for each of 46 the previously unused bits. 48 This document defines a new object for RSVP-TE messages that allows 49 the signaling of further attribute bits and also the carriage of 50 arbitrary attribute parameters to make RSVP-TE easily extensible to 51 support new requirements. Additionally, this document defines a way 52 to record the attributes applied to the LSP on a hop-by-hop basis. 54 The object mechanisms defined in this document are equally applicable 55 to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to 56 GMPLS non-PSC LSPs. 58 This document replaces and obsoletes the previous version of this 59 work published as RFC 4420. The only change is in the encoding of the 60 Type-Length-Variable (TLV) data structures. 62 Contents 64 1. Introduction and Problem Statement ..............................3 65 1.1. Applicability to Generalized MPLS ..........................4 66 1.2. A Rejected Alternate Solution ..............................4 67 2. Terminology .....................................................5 68 3. Attributes TLVs .................................................5 69 3.1. Attributes Flags TLV .......................................6 70 4. LSP_ATTRIBUTES Object ...........................................6 71 4.1. Format .....................................................7 72 4.2. Generic Processing Rules for Path Messages .................7 73 4.3. Generic Processing Rules for Resv Messages .................8 74 5. LSP_REQUIRED_ATTRIBUTES Object ..................................9 75 5.1. Format .....................................................9 76 5.2. Generic Processing Rules ...................................9 77 6. Inheritance Rules ..............................................10 78 7. Recording Attributes Per LSP ...................................11 79 7.1. Requirements ..............................................11 80 7.2. RRO Attributes Subobject ..................................11 81 7.3. Procedures ................................................12 82 7.3.1. Subobject Presence Rules ...........................12 83 7.3.2. Reporting Compliance with LSP Attributes ...........12 84 7.3.3. Reporting Per-Hop Attributes .......................13 85 7.3.4. Default Behavior ...................................13 86 8. Summary of Attribute Bit Allocation ............................13 87 9. Message Formats ................................................14 88 10. Guidance for Key Application Scenarios ........................14 89 10.1. Communicating to Egress LSRs .............................15 90 10.2. Communicating to Key Transit LSRs ........................15 91 10.3. Communicating to All LSRs ................................16 92 11. IANA Considerations ...........................................16 93 11.1. New RSVP C-Nums and C-Types ..............................16 94 11.2. New TLV Space ............................................17 95 11.3. Attributes Flags .........................................17 96 11.4. New Error Codes ..........................................18 97 11.5. New Record Route Subobject Identifier ....................18 98 12. Security Considerations .......................................18 99 13. Acknowledgements ..............................................19 100 14. Changes from RFC 4420 to RFC XXXX .............................19 101 15. Normative References ..........................................19 102 16. Informative References ........................................20 103 17. Authors' Addresses ............................................20 105 1. Introduction and Problem Statement 107 This document replaces and obsoletes the previous version of this 108 work published as RFC 4420 [RFC4420]. The only change is in the 109 encoding of the Type-Length-Variable (TLV) data structures presented 110 in Section 3. See Section 14 for a summary of changes. 112 Traffic-Engineered Multiprotocol Label Switching (MPLS) Label 113 Switched Paths (LSPs) [RFC3031] may be set up using the Path message 114 of the RSVP-TE signaling protocol [RFC3209]. The Path message 115 includes the SESSION_ATTRIBUTE object, which carries a Flags field 116 used to indicate desired options and attributes of the LSP. 118 The Flags field in the SESSION_ATTRIBUTE object has eight bits. Just 119 three of those bits are assigned in [RFC3209]. A further two bits 120 are assigned in [RFC4090] for fast re-reroute functionality leaving 121 only three bits available. Several recent proposals and Internet 122 Drafts have demonstrated that there is a high demand for the use of 123 the other three bits. Some, if not all, of those proposals are 124 likely to go forward as RFCs resulting in depletion or near depletion 125 of the Flags field and a consequent difficulty in signaling new 126 options and attributes that may be developed in the future. 128 This document defines a new object for RSVP-TE messages that allows 129 the signaling of further attributes bits. The new object is 130 constructed from TLVs, and a new TLV is defined to carry a variable 131 number of attributes bits. 133 The new RSVP-TE message object is quite flexible, due to the use of 134 the TLV format and allows: 136 - future specification of bit flags 137 - additional options and attribute parameters carried in TLV 138 format. 140 Note that the LSP Attributes defined in this document are 141 specifically scoped to an LSP. They may be set differently on 142 separate LSPs with the same Tunnel ID between the same source and 143 destination (that is, within the same session). 145 It is noted that some options and attributes do not need to be acted 146 on by all Label Switched Routers (LSRs) along the path of the LSP. 147 In particular, these options and attributes may apply only to key 148 LSRs on the path such as the ingress LSR and egress LSR. Special 149 transit LSRs, such as Area or Autonomous System Border Routers (ABRs 150 or ASBRs), may also fall into this category. This means that the new 151 options and attributes should be signaled transparently, and only 152 examined at those points that need to act on them. 154 On the other hand, other options and attributes may require action at 155 all transit LSRs along the path of the LSP. Inability to support the 156 required attributes by one of those transit LSRs may require the LSR 157 to refuse the establishment of the LSP. 159 These considerations are particularly important in the context of 160 backward compatibility. In general, it should be possible to provide 161 new MPLS services across a legacy network without upgrading those 162 LSRs that do not need to participate actively in the new services. 163 Moreover, some features just require action on specific intermediate 164 hops, and not on every visited LSR. 166 Note that options already specified for the SESSION_ATTRIBUTE object 167 in preexisting RFCs are not migrated to the new mechanisms described 168 in this document. 170 RSVP includes a way for unrecognized objects to be transparently 171 forwarded by transit nodes without them refusing the incoming 172 protocol messages and without the objects being stripped from the 173 outgoing protocol message (see [RFC2205], Section 3.10). This 174 capability extends to RSVP-TE and provides a good way to ensure that 175 only those LSRs that understand a particular object examine it. 177 This document distinguishes between options and attributes that are 178 only required at key LSRs along the path of the LSP, and those that 179 must be acted on by every LSR along the LSP. Two LSP Attributes 180 objects are defined in this document: using the C-Num definition 181 rules inherited from [RFC2205], the first is passed transparently by 182 LSRs that do not recognize it, and the second causes LSP setup 183 failure with the generation of a PathErr message with an appropriate 184 Error Code if an LSR does not recognize it. 186 1.1. Applicability to Generalized MPLS 188 The RSVP-TE signaling protocol also forms the basis of a signaling 189 protocol for Generalized MPLS (GMPLS) as described in [RFC3471] and 190 [RFC3473]. The extensions described in this document are equally 191 applicable to MPLS and GMPLS. 193 1.2. A Rejected Alternate Solution 195 A rejected alternate solution was to define a new C-Type for the 196 existing SESSION_ATTRIBUTE object. This new C-Type could allow a 197 larger Flags field and address the immediate problem. 199 This solution was rejected because: 201 - A new C-Type is not backward compatible with deployed 202 implementations that expect to see a C-Type of 1 or 7. It is 203 important that any solution be capable of carrying new attributes 204 transparently across legacy LSRs if those LSRs are not required to 205 act on the attributes. 207 - Support for arbitrary attributes parameters through TLVs would have 208 meant a significant change of substance to the existing object. 210 2. Terminology 212 This document uses terminology from the MPLS architecture document 213 [RFC3031] and from the RSVP-TE protocol specification [RFC3209], 214 which inherits from the RSVP specification [RFC2205]. It also makes 215 use of the Generalized MPLS RSVP-TE terminology introduced in 216 [RFC3471] and [RFC3473]. 218 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 219 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 220 document are to be interpreted as described in [RFC2119]. 222 3. Attributes TLVs 224 Attributes carried by the new objects defined in this document are 225 encoded within TLVs. One or more TLVs may be present in each object. 226 There are no ordering rules for TLVs, and no interpretation should be 227 placed on the order in which TLVs are received. 229 Each TLV is encoded as follows. 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Type | Length | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | | 237 // Value // 238 | | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 Type 243 The identifier of the TLV. 245 Length 247 Indicates the total length of the TLV, i.e., 4 + the length of 248 the value field in octets. A value field whose length is not a 249 multiple of four MUST be zero-padded so that the TLV is four- 250 octet aligned. 252 Value 254 The data for the TLV padded as described above. 256 3.1. Attributes Flags TLV 258 This document defines only one TLV type value. Type 1 indicates the 259 Attributes Flags TLV. Other TLV types may be defined in the future 260 with type values assigned by IANA (see Section 11.2). 262 The Attributes Flags TLV may be present in an LSP_ATTRIBUTES object 263 and/or an LSP_REQUIRED_ATTRIBUTES object defined in Sections 4 and 5. 264 The bits in the TLV represent the same attributes regardless of which 265 object carries the TLV. Documents that define individual bits MUST 266 specify whether the bit may be set in one object or the other, or 267 both. It is not expected that a bit will be set in both objects on a 268 single Path message at the same time, but this is not ruled out by 269 this document. 271 The Attribute Flags TLV Value field is an array of units of 32 flags 272 numbered from the most significant bit as bit zero. The Length field 273 for this TLV is therefore always a multiple of 4 bytes, regardless of 274 the number of bits carried and no padding is required. 276 Unassigned bits are considered as reserved and MUST be set to zero on 277 transmission by the originator of the object. Bits not contained in 278 the TLV MUST be assumed to be set to zero. If the TLV is absent 279 either because it is not contained in the LSP_ATTRIBUTES or 280 LSP_REQUIRED_ATTRIBUTES object, or because those objects are 281 themselves absent, all processing MUST be performed as though the 282 bits were present and set to zero. That is to say, assigned bits 283 that are not present either because the TLV is deliberately 284 foreshortened or because the TLV is not included MUST be treated as 285 though they are present and are set to zero. 287 No bits are defined in this document. The assignment of bits is 288 managed by IANA (see Section 11.3). 290 4. LSP_ATTRIBUTES Object 292 The LSP_ATTRIBUTES object is used to signal attributes required in 293 support of an LSP, or to indicate the nature or use of an LSP where 294 that information is not required to be acted on by all transit LSRs. 295 Specifically, if an LSR does not support the object, it forwards it 296 unexamined and unchanged. This facilitates the exchange of 297 attributes across legacy networks that do not support this new 298 object. 300 This object effectively extends the Flags field in the 301 SESSION_ATTRIBUTE object and allows for the future inclusion of more 302 complex objects through TLVs. 304 Note that some function may require an LSR to inspect both the 305 SESSION_ATTRIBUTE object and the LSP_ATTRIBUTES or 306 LSP_REQUIRED_ATTRIBUTES object. 308 The LSP_ATTRIBUTES object may also be used to report LSP operational 309 state on a Resv message even when no LSP_ATTRIBUTES or 310 LSP_REQUIRED_ATTRIBUTES object was carried on the corresponding Path 311 message. The object is added or updated by LSRs that support the 312 object. LSRs that do not understand the object or have nothing to 313 report do not add the object and forward it unchanged on Resv 314 messages that they generate. 316 The LSP_ATTRIBUTES object class is 197 of the form 11bbbbbb. This 317 C-Num value (see [RFC2205], Section 3.10) ensures that LSRs that do 318 not recognize the object pass it on transparently. 320 One C-Type is defined, C-Type = 1 for LSP Attributes. 322 This object is optional and may be placed on Path messages to convey 323 additional information about the desired attributes of the LSP, and 324 on Resv messages to report operational state. 326 4.1. Format 328 LSP_ATTRIBUTES class = 197, C-Type = 1 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | | 334 // Attributes TLVs // 335 | | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 The Attributes TLVs are encoded as described in Section 3. 340 4.2. Generic Processing Rules for Path Messages 342 An LSR that does not support this object is required to pass it on 343 unaltered as indicated by the C-Num and the rules defined in 344 [RFC2205]. 346 An LSR that does support this object, but does not recognize a TLV 347 type code carried in this object, MUST pass the TLV on unaltered in 348 the LSP_ATTRIBUTES object that it places in the Path message that it 349 sends downstream. 351 An LSR that does support this object and recognizes a TLV, but does 352 not support the attribute defined by the TLV, MUST act as specified 353 in the document that defines the TLV. 355 An LSR that supports the Attributes Flags TLV, but does not recognize 356 a bit set in the Attributes Flags TLV, MUST forward the TLV 357 unchanged. 359 An LSR that supports the Attributes Flags TLV and recognizes a bit 360 that is set, but does not support the indicated attribute, MUST act 361 as specified in the document that defines the bit. 363 4.3. Generic Processing Rules for Resv Messages 365 An LSR that wishes to report operational status of an LSP may include 366 this object in a Resv message, or update the object that is already 367 carried in a Resv message. 369 Note that this usage reports the state of the entire LSP and not the 370 state of the LSP at an individual LSR. This latter function is 371 achieved using the LSP Attributes subobject of the Record Route 372 object (RRO) as described in Section 7. 374 The bits in the Attributes TLV may be used to report operational 375 status for the whole LSP. For example, an egress LSR may report a 376 particular status by setting a bit. LSRs within the network that 377 determine that this status has not been achieved may clear the bit as 378 they forward the Resv message. 380 Observe that LSRs that do not support the object or do not support 381 the function characterized by a particular bit in the Attributes TLV 382 will not clear the bit when forwarding the Resv. Thus, care must be 383 taken in defining the usage of this object on a Resv. The usage of 384 an individual bit in the Attributes TLV of the LSP_ATTRIBUTES object 385 on a Resv must be fully defined in the document that defines the bit. 387 Additional TLVs may also be defined to be carried in this object on a 388 Resv. 390 An LSR that does not support this object will pass it on unaltered 391 because of the C-Num. 393 5. LSP_REQUIRED_ATTRIBUTES Object 395 The LSP_REQUIRED_ATTRIBUTES object is used to signal attributes 396 required in support of an LSP, or to indicate the nature or use of an 397 LSP where that information MUST be inspected at each transit LSR. 398 Specifically, each transit LSR MUST examine the attributes in the 399 LSP_REQUIRED_ATTRIBUTES object and MUST NOT forward the object 400 without acting on its contents. 402 This object effectively extends the Flags field in the 403 SESSION_ATTRIBUTE object and allows for the future inclusion of more 404 complex objects through TLVs. It complements the LSP_ATTRIBUTES 405 object. 407 The LSP_REQUIRED_ATTRIBUTES object class is 67 of the form 0bbbbbbb. 408 This C-Num value ensures that LSRs that do not recognize the object 409 reject the LSP setup effectively saying that they do not support the 410 attributes requested. This means that this object SHOULD only be 411 used for attributes that require support at some transit LSRs and so 412 require examination at all transit LSRs. See Section 4 for how end- 413 to-end and selective attributes are signaled. 415 One C-Type is defined, C-Type = 1 for LSP Required Attributes. 417 This object is optional and may be placed on Path messages to convey 418 additional information about the desired attributes of the LSP. 420 5.1. Format 422 LSP_REQUIRED_ATTRIBUTES class = 67, C-Type = 1 424 0 1 2 3 425 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 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | | 428 // Attributes TLVs // 429 | | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 The Attributes TLVs are encoded as described in Section 3. 434 5.2. Generic Processing Rules 436 An LSR that does not support this object will use a PathErr to reject 437 the Path message based on the C-Num using the Error Code "Unknown 438 Object Class". 440 An LSR that does not recognize a TLV type code carried in this object 441 MUST reject the Path message using a PathErr with Error Code "Unknown 442 Attributes TLV" and Error Value set to the value of the unknown TLV 443 type code. 445 An LSR that does not recognize a bit set in the Attributes Flags TLV 446 MUST reject the Path message using a PathErr with Error Code "Unknown 447 Attributes Bit" and Error Value set to the bit number of the unknown 448 bit in the Attributes Flags. 450 An LSR that recognizes an attribute (however encoded), but that does 451 not support that attribute, MUST act according to the behavior 452 specified in the document that defines that specific attribute. 454 Note that this object is not used on a Resv. In order to report the 455 status of an LSP, either the LSP_ATTRIBUTES object on a Resv or the 456 Attributes subobject in the Record Route object (see Section 7) must 457 be used. 459 6. Inheritance Rules 461 In certain circumstances, when reaching an LSP region boundary, a 462 forwarding adjacency LSP (FA-LSP; see [RFC4206]) is initially set up 463 to allow the establishment of the LSP carrying the LSP_ATTRIBUTES 464 and/or LSP_REQUIRED_ATTRIBUTES objects. In this case, when the 465 boundary LSR supports LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES 466 processing, the FA-LSP MAY upon local policy inherit a subset of the 467 Attributes TLVs, in particular when the FA-LSP belongs to the same 468 switching capability class as the triggering LSP. 470 When these conditions are met, the LSP_ATTRIBUTES and/or 471 LSP_REQUIRED_ATTRIBUTES objects are simply copied with the inherited 472 Attributes TLVs in the Path message used to establish the FA-LSP. By 473 default (and in order to simplify deployment), none of the incoming 474 LSP Attributes TLVs are considered as inheritable. Note that when 475 the FA-LSP establishment itself requires one or more Attributes TLVs, 476 an 'OR' operation is performed with the inherited set of values. 478 Documents that define individual bits for the LSP Attributes Flags 479 TLV MUST specify whether or not these bits MAY be inherited 480 (including the condition to be met in order for this inheritance to 481 occur). The same applies for any other TLV that will be defined 482 following the rules specified in Section 3. 484 7. Recording Attributes Per LSP 486 7.1. Requirements 488 In some circumstances, it is useful to determine which of the 489 requested LSP attributes have been applied at which LSRs along the 490 path of the LSP. For example, an attribute may be requested in the 491 LSP_ATTRIBUTES object such that LSRs that do not support the object 492 are not required to support the attribute or provide the requested 493 function. In this case, it may be useful to the ingress LSR to know 494 which LSRs acted on the request and which ignored it. 496 Additionally, there may be other qualities that need to be reported 497 on a hop-by-hop basis. These are currently indicated in the Flags 498 field of RRO subobjects. Since there are only eight bits available 499 in this field, and since some are already assigned and there is also 500 likely to be an increase in allocations in new documents, there is a 501 need for some other method to report per-hop attributes. 503 7.2. RRO Attributes Subobject 505 The RRO Attributes Subobject may be carried in the RECORD_ROUTE 506 object if it is present. The subobject uses the standard format of 507 an RRO subobject. 509 The length is variable as for the Attributes Flags TLV. The content 510 is the same as the Attribute Flags TLV -- that is, it is a series of 511 bit flags. 513 There is a one-to-one correspondence between bits in the Attributes 514 Flags TLV and the RRO Attributes Subobject. If a bit is only 515 required in one of the two places, it is reserved in the other place. 516 See the procedures sections, below, for more information. 518 0 1 2 3 519 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 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Type | Length | Reserved | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | | 524 // Attribute Flags // 525 | | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 Type 530 0x05 532 Length 534 The Length contains the total length of the subobject in bytes, 535 including the Type and Length fields. This length must be a 536 multiple of 4 and must be at least 8. 538 Attribute Flags 540 The attribute flags recorded for the specific hop. 542 7.3. Procedures 544 7.3.1. Subobject Presence Rules 546 As will be clear from [RFC3209], the RECORD_ROUTE object is managed 547 as a "stack" with each LSR adding subobjects to the start of the 548 object. The Attributes subobject is pushed onto the RECORD_ROUTE 549 object immediately prior to pushing the node's IP address or link 550 identifier. Thus, if label recording is being used, the Attributes 551 subobject SHOULD be pushed onto the RECORD_ROUTE object after the 552 Record Label subobject(s). 554 A node MUST NOT push an Attributes subobject onto the RECORD_ROUTE 555 object without also pushing an IPv4, IPv6, or Unnumbered Interface ID 556 subobject. 558 This means that an Attributes subobject is bound to the LSR 559 identified by the subobject found in the RRO immediately before the 560 Attributes subobject. 562 If the new subobject causes the RRO to be too big to fit in a Path 563 (or Resv) message, the processing MUST be as described in Section 564 4.4.3 of [RFC3209]. 566 If more than one Attributes subobject is found between a pair of 567 subobjects that identify LSRs, only the first one found (that is, the 568 nearest to the top of the stack) SHALL have any meaning within the 569 context of this document. All such subobjects MUST be forwarded 570 unmodified by transit LSRs 572 7.3.2. Reporting Compliance with LSP Attributes 574 To report compliance with an attribute requested in the Attributes 575 Flags TLV, an LSR MAY set the corresponding bit (see Section 8) in 576 the Attributes subobject. To report non-compliance, an LSR MAY clear 577 the corresponding bit in the Attributes subobject. 579 The requirement to report compliance MUST be specified in the 580 document that defines the usage of any bit. This will reduce to a 581 statement of whether hop-by-hop acknowledgement is required. 583 7.3.3. Reporting Per-Hop Attributes 585 To report a per-hop attribute, an LSR sets the appropriate bit in the 586 Attributes subobject. 588 The requirement to report a per-hop attribute MUST be specified in 589 the document that defines the usage of the bit. 591 7.3.4. Default Behavior 593 By default, all bits in an Attributes subobject SHOULD be set to 594 zero. 596 If a received Attribute subobject is not long enough to include a 597 specific numbered bit, that bit MUST be treated as though present and 598 as if set to zero. 600 If the RRO subobject is not present for a hop in the LSP, all bits 601 MUST be assumed to be set to zero. 603 8. Summary of Attribute Bit Allocation 605 This document defines two uses of per-LSP attribute flag bit fields. 606 The bit numbering in the Attributes Flags TLV and the RRO Attributes 607 subobject is identical. That is, the same attribute is indicated by 608 the same bit in both places. This means that only a single registry 609 of bits is maintained. 611 The consequence is a degree of clarity in implementation and 612 registration. 614 Note, however, that it is not always the case that a bit will be used 615 in both the Attributes Flags TLV and the RRO Attributes subobject. 616 For example, an attribute may be requested using the Attributes Flags 617 TLV, but there is no requirement to report the handling of the 618 attribute on a hop-by-hop basis. Conversely, there may be a 619 requirement to report the attributes of an LSP on a hop-by-hop basis, 620 but there is no corresponding request attribute. 622 In these cases, a single bit number is still assigned for both the 623 Attributes Flags TLV and the RRO Attributes subobject even though the 624 bit may be irrelevant in either the Attributes Flags or the RRO 625 Attributes subobject. The document that defines the usage of the new 626 bit MUST state in which places it is used and MUST handle a default 627 setting of zero. 629 9. Message Formats 631 The LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES object MAY 632 be carried in a Path message. The LSP_ATTRIBUTES object MAY be 633 carried in a Resv message. 635 The order of objects in RSVP-TE messages is recommended, but 636 implementations must be capable of receiving the objects in any 637 meaningful order. 639 On a Path message, the LSP_ATTRIBUTES object and 640 LSP_REQUIRED_ATTRIBUTES objects are RECOMMENDED to be placed 641 immediately after the SESSION_ATTRIBUTE object if it is present, or 642 otherwise immediately after the LABEL_REQUEST object. 644 If both the LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES 645 object are present, the LSP_REQUIRED_ATTRIBUTES object is RECOMMENDED 646 to be placed first. 648 LSRs MUST be prepared to receive these objects in any order in any 649 position within a Path message. Subsequent instances of these 650 objects within a Path message SHOULD be ignored and those objects 651 MUST be forwarded unchanged. 653 On a Resv message, the LSP_ATTRIBUTES object is placed in the flow 654 descriptor and is associated with the FILTER_SPEC object that 655 precedes it. It is RECOMMENDED that the LSP_ATTRIBUTES object be 656 placed immediately after the LABEL object. 658 LSRs MUST be prepared to receive this object in any order in any 659 position within a Resv message subject to the previous note. Only 660 one instance of the LSP_ATTRIBUTES object is meaningful within the 661 context of a FILTER_SPEC object. Subsequent instances of the object 662 SHOULD be ignored and MUST be forwarded unchanged. 664 10. Guidance for Key Application Scenarios 666 As described in the Introduction section of this document, it may be 667 that requested LSP attributes need to be acted on by only the egress 668 LSR of the LSP, by certain key transit points (such as ABRs and 669 ASBRs), or by all LSRs along the LSP. This section briefly describes 670 how each of these scenarios is met. This section is informational 671 and does not define any new procedures. 673 10.1. Communicating to Egress LSRs 675 When communicating LSP attributes that must be acted on only by the 676 LSP egress LSR, the attributes should be communicated in the 677 LSP_ATTRIBUTES object. Because of its C-Num, this object may be 678 ignored (passed onwards, untouched) by transit LSRs that do not 679 understand it. This means that the Path message will not be rejected 680 by LSRs that do not understand the object. In this way, the 681 requested LSP attributes are guaranteed to reach the egress LSR. 683 Attributes are set within the LSP_ATTRIBUTES object according to 684 which LSP attributes are required. Each attribute is defined in some 685 RFC and is accompanied by a statement of what the expected behavior 686 is. This behavior will include whether the attribute must be acted 687 on by any LSR that recognizes it, or specifically by the egress LSR. 688 Thus, any attribute that must be acted on only by an egress LSR will 689 be defined in this way -- any transit LSR seeing this attribute 690 either will understand the semantics of the attribute and ignore it 691 (forwarding it, unchanged) or will not understand the attribute and 692 ignore it (forwarding it, unchanged) according to the rules of the 693 LSP_ATTRIBUTES object. 695 The remaining issue is how the ingress LSR can know whether the 696 egress LSR has acted correctly on the required LSP attribute. 697 Another part of the definition of the attribute (in the defining RFC) 698 is whether reporting is required. If reporting is required, the 699 egress LSR is required to use the RRO Attributes subobject to report 700 whether it has acted on the received attribute. 702 If an egress LSR understands a received attribute as mandatory for an 703 egress LSR, but does not wish to satisfy the request, it will reject 704 the Path message. If an egress LSR understands the attribute, but 705 believes it to be optional and does not wish to satisfy the request, 706 it will report its non-compliance in the RRO Attributes subobject. 707 If the egress LSR does not understand the received attribute, it may 708 report non-compliance in the RRO Attributes subobject explicitly, or 709 may omit the RRO Attributes subobject implying that it has not 710 satisfied the request. 712 10.2. Communicating to Key Transit LSRs 714 Processing for key transit LSRs (such as ABRs and ASBRs) follows 715 exactly as for egress LSR. The only difference is that the 716 definition of the LSP attribute in the defining RFC will state that 717 the attribute must be acted on by these transit LSRs. 719 10.3. Communicating to All LSRs 721 In order to force all LSRs to examine the LSP attributes, the 722 LSP_REQUIRED_ATTRIBUTES object is used. The C-Num of this object is 723 such that any LSR that does not recognize the object must reject a 724 received Path message containing the object. 726 An LSR that recognizes the LSP_REQUIRED_ATTRIBUTES object, but does 727 not recognize an attribute, will reject the Path message. 729 An LSR that recognizes an attribute, but does not wish to support the 730 attribute, reacts according to the definition of the attribute in the 731 defining RFC. This may allow the LSR to ignore the attribute and 732 forward it unchanged, or may require it to fail the LSP setup. The 733 LSR may additionally be required to report whether it supports the 734 attribute using the RRO Attributes subobject. 736 11. IANA Considerations 738 The IANA allocations made for RFC 4420 [RFC4420] now apply to this 739 document and are listed here for completeness. 741 This document makes no further requests for IANA action, but IANA 742 should update the registry entries created for RFC 4420 to reference 743 this document which is now the normative reference for those entries. 745 11.1. New RSVP C-Nums and C-Types 747 Two new RSVP C-Nums are defined in this document and have been 748 assigned by IANA. 750 o LSP_ATTRIBUTES object 752 The C-Num (value 197) is of the form 11bbbbbb so that LSRs that do 753 not recognize the object will ignore the object but forward it, 754 unexamined and unmodified, in all messages resulting from this 755 message. 757 One C-Type is defined for this object and has been assigned by 758 IANA. 760 o LSP Attributes TLVs 762 Recommended C-Type value 1. 764 o LSP_REQUIRED_ATTRIBUTES object 766 The C-Num (value 67) is of the form 0bbbbbbb so that LSRs that do 767 not recognize the object will reject the message that carries it 768 with an "Unknown Object Class" error. 770 One C-Type is defined for this object and has been assigned by 771 IANA. 773 o LSP Required Attributes TLVs 775 Recommended C-Type value 1. 777 11.2. New TLV Space 779 The two new objects referenced above are constructed from TLVs. Each 780 TLV includes a 16-bit type identifier (the T-field). The same 781 T-field values are applicable to both objects. 783 The IANA has created a new registry and will manage TLV type 784 identifiers as follows: 786 - TLV Type (T-field value) 787 - TLV Name 788 - Whether allowed on LSP_ATTRIBUTES object 789 - Whether allowed on LSP_REQUIRED_ATTRIBUTES object. 791 This document defines one TLV type as follows: 793 - TLV Type = 1 794 - TLV Name = Attributes Flags TLV 795 - allowed on LSP_ATTRIBUTES object 796 - allowed on LSP_REQUIRED_ATTRIBUTES object. 798 New TLV type values may be allocated only by an IETF Consensus 799 action. 801 11.3. Attributes Flags 803 This document provides new attributes bit flags for use in other 804 documents that specify new RSVP-TE attributes. These flags are 805 present in the Attributes Flags TLV referenced in the previous 806 section. 808 The IANA has created a new registry and will manage the space of 809 attributes bit flags numbering them in the usual IETF notation 810 starting at zero and continuing at least through 31. 812 New bit numbers may be allocated only by an IETF Consensus action. 814 Each bit should be tracked with the following qualities: 816 - Bit number 817 - Defining RFC 818 - Name of bit 819 - Whether there is meaning in the Attribute Flags TLV on a Path 820 - Whether there is meaning in the Attribute Flags TLV on a Resv 821 - Whether there is meaning in the RRO Attributes Subobject. 823 Note that this means that all bits in the Attribute Flags TLV and the 824 RRO Attributes Subobject use the same bit number regardless of 825 whether they are used in one or both places. Thus, only one list of 826 bits is required to be maintained. (It would be meaningless in the 827 context of this document for a bit to have no meaning in either the 828 Attribute Flags TLV or the RRO Attributes Subobject.) 830 11.4. New Error Codes 832 This document defines the following new Error Codes and Error Values. 833 Numeric values have been assigned by IANA. 835 Error Code Error Value 836 29 "Unknown Attributes TLV" Identifies the unknown TLV type code. 837 30 "Unknown Attributes Bit" Identifies the unknown Attribute Bit. 839 11.5. New Record Route Subobject Identifier 841 A new subobject is defined for inclusion in the RECORD_ROUTE object. 843 The RRO Attributes subobject is identified by a Type value of 5. 845 12. Security Considerations 847 This document adds two new objects to the RSVP Path message as used 848 in MPLS and GMPLS signaling, and a new subobject to the RECORD_ROUTE 849 object carried on many RSVP messages. It does not introduce any new 850 direct security issues, and the reader is referred to the security 851 considerations expressed in [RFC2205], [RFC3209], and [RFC3473]. 853 It is of passing note that any signaling request that indicates the 854 functional preferences or attributes of an MPLS LSP may provide 855 anyone with unauthorized access to the contents of the message with 856 information about the LSP that an administrator may wish to keep 857 secret. Although this document adds new objects for signaling 858 desired LSP attributes, it does not contribute to this issue, which 859 can only be satisfactorily handled by encrypting the content of the 860 signaling message. 862 Similarly, the addition of attribute recording information to the RRO 863 may reveal information about the status of the LSP and the 864 capabilities of individual LSRs that operators wish to keep secret. 866 The same strategy that applies to other RRO subobjects also applies 867 here. Note, however, that there is a tension between notifying the 868 head end of the LSP status at transit LSRs, and hiding the existence 869 or identity of the transit LSRs. 871 13. Acknowledgements 873 Credit to the OSPF Working Group for inspiration from their solution 874 to a similar problem. Thanks to Rahul Aggarwal for his careful 875 review and support of this work. Thanks also to Raymond Zhang, 876 Kireeti Kompella, Philip Matthews, Jim Gibson, and Alan Kullberg for 877 their input. As so often, thanks to John Drake for useful offline 878 discussions. Thanks to Mike Shand for providing the Routing 879 Directorate review and to Joel Halpern for the General Area review -- 880 both picked up on some unclarities. 882 Thanks to the OIF for noticing the discrepency in RFC 4420 that is 883 fixed in this document. Alfred Hoenes noted several typographical 884 errors. 886 14. Changes from RFC 4420 to RFC XXXX 888 [RFC Editor - Please replace "XXXX" with the RFC number assigned for 889 this work and remove this note.] 891 This document obsoletes RFC 4420 [RFC4420]. The only change is in 892 Section 3. Section 3 describes the semantic of the Length field of 893 the Attributes TLV. 895 Prior to the change, the Length field indicated the length of the 896 Value field only. After the change, as described in Section 3, the 897 Length field indicates the length of the whole TLV. This change means 898 that this document is consistent with the subobject format defined in 899 [RFC3209] and the TLV format defined in [RFC3471]. 901 15. Normative References 903 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 904 Requirement Levels", BCP 14, RFC 2119, March 1997. 906 [RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S., and 907 S. Jamin, "Resource ReSerVation Protocol (RSVP) -- 908 Version 1 Functional Specification", RFC 2205, September 909 1997. 911 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 912 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 913 Tunnels", RFC 3209, December 2001. 915 [RFC3471] Berger, L. (Ed.), "Generalized Multi-Protocol Label 916 Switching (GMPLS) Signaling Functional Description", RFC 917 3471, January 2003. 919 [RFC3473] Berger, L. (Ed.), "Generalized Multi-Protocol Label 920 Switching (GMPLS) Signaling Resource ReserVation 921 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 922 3473, January 2003. 924 16. Informative References 926 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 927 Label Switching Architecture", RFC 3031, January 2001. 929 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 930 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 931 2005. 933 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 934 Hierarchy with Generalized Multi-Protocol Label Switching 935 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 936 2005. 938 [RFC4420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and 939 A. Ayyangar, "Encoding of Attributes for Multiprotocol 940 Label Switching (MPLS) Label Switched Path (LSP) 941 Establishment Using Resource ReserVation Protocol-Traffic 942 Engineering (RSVP-TE)", RFC 4420, February 2006. 944 17. Authors' Addresses 946 Adrian Farrel 947 Old Dog Consulting 949 Phone: +44 (0) 1978 860944 950 EMail: adrian@olddog.co.uk 952 Dimitri Papadimitriou 953 Alcatel 954 Fr. Wellesplein 1, 955 B-2018 Antwerpen, Belgium 957 Phone: +32 3 240-8491 958 EMail: dimitri.papadimitriou@alcatel.be 959 Jean Philippe Vasseur 960 Cisco Systems, Inc. 961 1414 Massachusetts Avenue 962 Boxborough, MA - 01719 963 USA 965 EMail: jpv@cisco.com 967 Arthi Ayyangar 968 Juniper Networks, Inc. 969 1194 N.Mathilda Ave 970 Sunnyvale, CA 94089 971 USA 973 EMail: arthi@juniper.net 975 18. Intellectual Property Statement 977 The IETF takes no position regarding the validity or scope of any 978 Intellectual Property Rights or other rights that might be claimed to 979 pertain to the implementation or use of the technology described in 980 this document or the extent to which any license under such rights 981 might or might not be available; nor does it represent that it has 982 made any independent effort to identify any such rights. Information 983 on the procedures with respect to rights in RFC documents can be 984 found in BCP 78 and BCP 79. 986 Copies of IPR disclosures made to the IETF Secretariat and any 987 assurances of licenses to be made available, or the result of an 988 attempt made to obtain a general license or permission for the use of 989 such proprietary rights by implementers or users of this 990 specification can be obtained from the IETF on-line IPR repository at 991 http://www.ietf.org/ipr. 993 The IETF invites any interested party to bring to its attention any 994 copyrights, patents or patent applications, or other proprietary 995 rights that may cover technology that may be required to implement 996 this standard. Please address the information to the IETF at ietf- 997 ipr@ietf.org. 999 19. Full Copyright Statement 1001 Copyright (C) The IETF Trust (2008). 1003 This document is subject to the rights, licenses and restrictions 1004 contained in BCP 78, and except as set forth therein, the authors 1005 retain all their rights. 1007 This document and the information contained herein are provided on an 1008 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1009 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1010 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1011 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1012 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1013 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.