Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
obsoleted by
- rfc-5420 — Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)
updates
Extracted elements (22)
A single shared registry of attribute bit numbers is used for both the Attributes Flags TLV and the RRO Attributes Subobject, with the same bit number indicating the same attribute in both contexts. This avoids maintaining two separate registries and simplifies implementation, at the cost of reserving a bit in one place even when it has meaning only in the other.
The SESSION_ATTRIBUTE object's 8-bit Flags field was nearly exhausted (5 of 8 bits assigned), motivating a new extensible object rather than expanding the existing one. A new C-Type for SESSION_ATTRIBUTE was rejected because it would break backward compatibility with deployed implementations expecting C-Type 1 or 7, and because TLV support would have required significant changes to the existing object.
Two distinct objects are defined—LSP_ATTRIBUTES (C-Num 197, form 11bbbbbb) and LSP_REQUIRED_ATTRIBUTES (C-Num 67, form 0bbbbbbb)—to distinguish attributes that only key LSRs need to examine from those that all transit LSRs must act on. Legacy LSRs transparently forward LSP_ATTRIBUTES but reject Path messages containing LSP_REQUIRED_ATTRIBUTES they do not recognize.
Options already specified for the SESSION_ATTRIBUTE object in preexisting RFCs are not migrated to the new LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES objects. Implementations must continue to support the original SESSION_ATTRIBUTE flags and may need to inspect both the SESSION_ATTRIBUTE and the new objects.
A node MUST NOT push an Attributes subobject onto the RECORD_ROUTE object without also pushing an IPv4, IPv6, or Unnumbered Interface ID subobject. The Attributes subobject SHOULD be pushed after any Record Label subobjects so it is immediately prior to the node's address subobject.
An LSR that does not recognize a bit set in the Attributes Flags TLV within LSP_REQUIRED_ATTRIBUTES MUST reject the Path message using a PathErr with Error Code 'Unknown Attributes Bit' and Error Value set to the bit number of the unknown bit.
An LSR that supports LSP_ATTRIBUTES but does not recognize a TLV type code carried in it MUST pass the TLV on unaltered in the downstream LSP_ATTRIBUTES object. An LSR that supports the Attributes Flags TLV but does not recognize a set bit MUST forward the TLV unchanged.
By default, all bits in an Attributes subobject SHOULD be set to zero. If a received Attributes subobject is not long enough to include a specific numbered bit, that bit MUST be treated as present and set to zero. If no RRO subobject is present for a hop, all bits MUST be assumed zero.
Documents defining individual bits for the LSP Attributes Flags TLV MUST specify whether or not those bits MAY be inherited by FA-LSPs at LSP region boundaries, including the conditions under which inheritance occurs. By default, none of the incoming LSP Attributes TLVs are considered inheritable.
Each transit LSR MUST examine the attributes in LSP_REQUIRED_ATTRIBUTES and MUST NOT forward the object without acting on its contents. An LSR not recognizing a TLV type code in this object MUST reject the Path message with PathErr Error Code 'Unknown Attributes TLV' and Error Value set to the unknown TLV type code.
If more than one Attributes subobject appears between a pair of LSR-identifying subobjects in the RRO, only the first one (nearest the top of the stack) SHALL have meaning. All such subobjects MUST be forwarded unmodified by transit LSRs.
LSRs MUST be prepared to receive LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects in any order and at any position within a Path message. Subsequent instances of these objects within a Path message SHOULD be ignored and MUST be forwarded unchanged.
Unassigned bits in the Attributes Flags TLV MUST be set to zero on transmission. Bits not contained in the TLV MUST be assumed to be set to zero. If the TLV or its containing objects are absent, all processing MUST be performed as though the bits were present and set to zero.
The Attributes Flags TLV (Type=1) carries a variable-length array of 32-bit flag words, numbered from the most significant bit as bit zero. The Length field is always a multiple of 4 bytes. It may appear in both LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects.
The LSP_ATTRIBUTES object (class 197, C-Type 1) carries Attributes TLVs in RSVP-TE Path and Resv messages. Its C-Num value (form 11bbbbbb) ensures that LSRs not recognizing the object pass it on transparently without rejecting the message.
The LSP_REQUIRED_ATTRIBUTES object (class 67, C-Type 1) carries Attributes TLVs that each transit LSR MUST inspect and act on. Its C-Num (form 0bbbbbbb) causes LSRs that do not recognize it to reject the LSP setup with 'Unknown Object Class'. This object is not used on Resv messages.
The RRO Attributes Subobject (Type=0x05) is carried in the RECORD_ROUTE object to report per-hop attribute flags. Its format includes a 1-byte Type, 1-byte Length (minimum 8, multiple of 4), 2-byte Reserved field, and a variable-length Attribute Flags field using the same bit numbering as the Attributes Flags TLV.
IANA assigned two new RSVP C-Nums: LSP_ATTRIBUTES (class 197, C-Type 1) and LSP_REQUIRED_ATTRIBUTES (class 67, C-Type 1). A new TLV type registry was created for both objects, with Type=1 (Attributes Flags TLV) as the initial entry; new values require IETF Consensus.
IANA created a new Attributes Flags bit registry numbering bits from zero through at least 31. Each entry tracks: bit number, defining RFC, bit name, and whether the bit has meaning in the Attributes Flags TLV on Path, on Resv, and in the RRO Attributes Subobject. New bit allocations require IETF Consensus.
Two new RSVP PathErr Error Codes were assigned: Error Code 29 ('Unknown Attributes TLV', Error Value identifies the unknown TLV type code) and Error Code 30 ('Unknown Attributes Bit', Error Value identifies the unknown bit number). A new RRO subobject Type value of 5 was assigned for the RRO Attributes Subobject.
The new objects do not introduce new direct security vulnerabilities beyond those in RFC 2205, RFC 3209, and RFC 3473. However, LSP attribute signaling may expose information about LSP functional preferences to unauthorized observers; this can only be satisfactorily addressed by encrypting signaling message content. Similarly, RRO attribute recording may reveal LSR capabilities and LSP status that operators wish to keep confidential.
Each Attributes TLV has a 16-bit Type field, a 16-bit Length field (value length in bytes, excluding padding), and a variable-length Value field zero-padded to a 4-byte boundary. Padding is not counted in Length, so a 1-byte value produces an 8-byte TLV with Length=1.