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