Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)
obsoletes
- rfc-4420 — Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
updated by
- rfc-6510 — Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects
updates
Extracted elements (28)
A rejected alternative was to define a new C-Type for the SESSION_ATTRIBUTE object with a larger Flags field. This was rejected because a new C-Type is not backward compatible with deployed implementations expecting C-Type 1 or 7, and because adding TLV-based arbitrary attribute parameters would have constituted a significant change to the existing object.
RFC 5420 changes the encoding of the TLV Length field from RFC 4420: the Length field now indicates the total length of the whole TLV (Type + Length + Value), not just the Value field. This makes the encoding consistent with the subobject format in RFC 3209 and the TLV format in RFC 3471.
The SESSION_ATTRIBUTE Flags field has only eight bits, of which five were already assigned (three by RFC 3209, two by RFC 4090), leaving only three bits available. Multiple in-progress proposals were competing for those remaining bits, motivating a new, extensible object rather than further packing the existing field.
The LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES object mechanisms are equally applicable to MPLS Packet Switch Capable (PSC) LSPs and to GMPLS non-PSC LSPs, since GMPLS signaling is built on RSVP-TE (RFC 3471, RFC 3473).
A node MUST NOT push an RRO 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 the Record Label subobject(s) and is bound to the immediately following LSR-identifying subobject.
An LSR that does not recognize a bit set in the Attribute Flags TLV carried in an LSP_REQUIRED_ATTRIBUTES object MUST reject the Path message with a PathErr using Error Code 30 ('Unknown Attributes Bit') and Error Value set to the bit number of the unknown bit.
An LSR that does not recognize a TLV type code in the LSP_REQUIRED_ATTRIBUTES object MUST reject the Path message with a PathErr using Error Code 29 ('Unknown Attributes TLV') and Error Value set to the unknown TLV type code.
An LSR that supports the LSP_ATTRIBUTES object but does not recognize a TLV type code carried in it MUST pass the TLV on unaltered in the downstream Path message. An LSR that does not recognize a set bit in the Attribute Flags TLV MUST forward the TLV unchanged.
Documents defining individual bits for the Attribute Flags TLV MUST specify whether those bits MAY be inherited by an FA-LSP and the conditions under which inheritance occurs. The same requirement applies to any other TLV type defined under the rules of Section 3.
Documents defining individual bits MUST state in which of the Attribute Flags TLV (on Path and/or Resv) and the RRO Attributes subobject the bit is used, and MUST handle a default setting of zero for the bit in places where it is not meaningful.
LSRs MUST be prepared to receive the LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects in any order at any position within a Path message. Subsequent instances of these objects within a Path message SHOULD be ignored and MUST be forwarded unchanged.
The LSP_REQUIRED_ATTRIBUTES object SHOULD only be used for attributes that require support at some transit LSRs and therefore must be examined at all transit LSRs. End-to-end or selective attributes that need only be inspected by key LSRs should instead use the LSP_ATTRIBUTES object.
Unassigned bits in the Attribute Flags TLV MUST be set to zero on transmission. Bits not contained in the TLV and bits in an absent TLV or absent object MUST be assumed to be set to zero, as if the bits were present and zero.
Inheritance rules apply when a Forwarding Adjacency LSP (FA-LSP) is established at an LSP region boundary. The boundary LSR MAY, upon local policy, copy a subset of Attributes TLVs into the FA-LSP's Path message when the FA-LSP belongs to the same switching capability class as the triggering LSP. By default, no TLVs are inheritable.
The Attribute Flags TLV (Type = 1) carries a variable-length array of 32-bit units of flag bits numbered from the most significant bit as bit zero. Its Length is always a multiple of four bytes and requires no padding. Unassigned bits MUST be set to zero; bits absent from a foreshortened or omitted TLV MUST be treated as present and zero.
The LSP_ATTRIBUTES object (class 197, C-Type 1) uses a C-Num of the form 11bbbbbb, so LSRs that do not recognize it pass it on transparently without examining or modifying it. It may appear on Path messages to signal optional LSP attributes and on Resv messages to report operational state.
The LSP_REQUIRED_ATTRIBUTES object (class 67, C-Type 1) uses a C-Num of the form 0bbbbbbb, causing LSRs that do not recognize it to reject the LSP setup with an 'Unknown Object Class' PathErr. Every transit LSR MUST examine its attributes and MUST NOT forward it without acting on its contents.
The RRO Attributes subobject (Type 0x05) may be included in the RECORD_ROUTE object to record per-hop LSP attribute compliance or per-hop attributes. It carries the same bit-flag array as the Attribute Flags TLV with a one-to-one bit correspondence, allowing a single registry to serve both uses.
A new RECORD_ROUTE object subobject identifier is registered: Type 5 for the RRO Attributes subobject, used to record per-hop LSP attribute compliance and per-hop attributes.
IANA maintains a registry of 16-bit TLV type identifiers shared by both the LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects, tracking TLV Type, TLV Name, and applicability to each object. New TLV types require IETF Consensus. Type 1 (Attribute Flags TLV) is the only initial entry.
IANA maintains a registry of Attribute Flags bit numbers (starting at zero), tracking the bit number, defining RFC, bit name, and whether the bit has meaning in the Attribute Flags TLV on Path, on Resv, and in the RRO Attributes subobject. New bit allocations require IETF Consensus. No bits are defined by this document.
RFC 5420 (updating allocations originally made for RFC 4420) registers two new RSVP object classes: LSP_ATTRIBUTES (class 197, C-Num 11bbbbbb, C-Type 1) and LSP_REQUIRED_ATTRIBUTES (class 67, C-Num 0bbbbbbb, C-Type 1). Both are recorded in the RSVP Parameters registry.
Two new RSVP error codes are registered: Error Code 29 ('Unknown Attributes TLV') with Error Value identifying the unknown TLV type code, and Error Code 30 ('Unknown Attributes Bit') with Error Value identifying the unknown bit number. Both are used in PathErr messages from LSP_REQUIRED_ATTRIBUTES processing.
Adding attribute-recording information to the RRO Attributes subobject may reveal the status of the LSP and the capabilities of individual transit LSRs. There is an inherent tension between notifying the ingress LSR of per-hop status and concealing the existence or identity of transit LSRs.
LSP attribute signaling in the new objects may expose functional preferences or administrative details about an LSP to anyone with unauthorized access to the signaling messages. This confidentiality concern is not introduced by this document and can only be satisfactorily addressed by encrypting signaling message content.
Each Attributes TLV is encoded with a 16-bit Type field, a 16-bit Length field (total TLV length in octets including Type and Length), and a variable-length Value field. The entire TLV MUST be padded with zero to three trailing zeros to achieve four-octet alignment; padding octets are not counted in the Length field.
The LSP_ATTRIBUTES object (class 197, C-Type 1) and the LSP_REQUIRED_ATTRIBUTES object (class 67, C-Type 1) both contain a variable-length sequence of Attributes TLVs encoded as described in Section 3; there are no other fixed fields.
The RRO Attributes subobject is encoded with a 1-octet Type (0x05), a 1-octet Length (total subobject length, minimum 8, multiple of 4), a 2-octet Reserved field, followed by a variable-length Attribute Flags array using the same bit numbering as the Attribute Flags TLV.