Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)
Extracted elements (23)
The 250-byte limit on Hop Attributes TLV size is imposed by the ERO subobject size constraints. The document notes that known forthcoming TLVs (WSON_SIGNALING, Objective Function, Metric) are not expected to exceed this limit, justifying the choice not to define a fragmentation mechanism.
The ERO Hop Attributes subobject provides a generic per-hop attribute mechanism to support current and future ERO constraint extensions (e.g., WSON signaling, objective functions, metrics) without defining new ERO subobjects for each use case. It reuses the TLV structure already defined in RFC 5420 for whole-LSP attributes.
An ingress node not supporting the RRO Hop Attributes subobject will drop the information per RFC 3209 Section 4.4.5. A node may use the RRO Hop Attributes subobject to report an LSP attribute from LSP_ATTRIBUTES/LSP_REQUIRED_ATTRIBUTES only if both the attribute flag is allowed on both objects and the reporting in RRO Hop Attributes is specified in the defining document.
For LSP attributes signaled in LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES objects, a node SHOULD use the RRO Attributes subobject (not the RRO Hop Attributes subobject) to report processing. For attributes signaled only in the ERO Hop Attributes subobject, a node SHOULD use the RRO Hop Attributes subobject and SHOULD NOT use the RRO Attributes subobject.
A processing node MUST NOT originate a Hop Attributes TLV longer than the ERO Hop Attributes subobject. A node receiving a Hop Attributes TLV longer than the enclosing ERO subobject SHOULD return a PathErr with Error Code 'Routing Error' and Error Value 'Bad EXPLICIT_ROUTE object'.
If a node does not support the ERO Hop Attributes subobject, it MUST behave as described in RFC 3209 for unrecognized ERO subobjects: return a PathErr with Error Code 'Routing Error' and Error Value 'Bad EXPLICIT_ROUTE object', with the EXPLICIT_ROUTE object truncated to the offending subobject.
One or more ERO Hop Attributes subobjects MAY be inserted directly after any identifying subobject in the ERO list (defined in RFCs 3209, 3477, 4873, 4874, 5520, 5553), and also after any Label subobjects if present for that hop.
The L bit in the ERO Hop Attributes subobject MUST be set to 0.
The requirement for an LSR to report compliance with ERO hop attributes via the RRO Hop Attributes subobject MUST be specified in the document that defines the usage of that hop attribute.
The Reserved field MUST be set to 0 when the ERO Hop Attributes subobject is inserted, MUST NOT be changed when a node processes the ERO, and MUST be ignored on the node addressed by the preceding ERO subobjects.
The RRO Hop Attributes subobject MUST be pushed after the RRO Attributes subobject (if present) as defined in RFC 5420, and unless local policy applies, all such subobjects SHOULD be forwarded unmodified by transit LSRs.
TLVs within an ERO Hop Attributes subobject have no mandatory ordering, and interpretation SHOULD NOT be placed on the order in which TLVs are received.
Unknown Attribute Flags TLV flags in an ERO Hop Attributes subobject SHOULD trigger generation of a PathErr with Error Code 'Unknown Attributes Bit' as defined in RFC 5420 Section 5.2; invalid flags SHALL be silently ignored.
When the R bit is set, a node MUST examine Hop Attributes TLVs per RFC 5420 Section 5.2 (required attributes rules); when not set, MUST examine them per RFC 5420 Section 4.2 (optional attributes rules).
The ERO Hop Attributes subobject is an OPTIONAL subobject carried in the ERO or SERO, using the standard ERO subobject format. It carries a list of Hop Attributes TLVs and enables per-hop attribute specification, building on the LSP_ATTRIBUTE semantics of RFC 5420.
The R bit mirrors the LSP_REQUIRED_ATTRIBUTE/LSP_ATTRIBUTE semantic from RFC 5420. When set, it indicates hop attributes that the addressed node must process; when cleared, attributes are optional as per RFC 5420 Section 4.2.
IANA added a 'HOP_A' column to the 'Attributes TLV Space' registry in the RSVP-TE Parameters registry, indicating whether each TLV is allowed on the LSP Hop Attributes ERO subobject. Attribute Flags TLV (T=1) is marked Yes; Service ID TLV (T=2) and OAM Configuration TLV (T=3) are marked No.
IANA added an 'ERO' column to the 'Attribute Flags' registry in the RSVP-TE Parameters registry, indicating which flags are permitted in an Attribute Flags TLV carried in the ERO Hop Attributes subobject. All existing flags (bits 0–12) are marked 'No' for ERO use; new allocations SHALL indicate the ERO column value.
IANA allocated subobject type 35 ('Hop Attributes') in the ROUTE_RECORD Sub-object type 21 (Type 1 Route Record) registry of the 'Resource Reservation Protocol (RSVP) Parameters' registry.
RRO Hop Attributes can reveal confidential node details to outside observers. Domain boundary policies SHOULD take the releasing of RRO hop attributes into consideration, applying the same confidentiality strategies used for other RRO subobjects, including pruning or modifying the RRO at domain edges.
The ERO Hop Attributes mechanism allows more fine-grained control of LSP attributes at individual nodes, which can reveal information about LSP requests and node status to unauthorized parties. A node SHOULD validate hop attributes against its policies and admission procedures and MAY reject requests using 'Policy Control Failure' or 'Admission Control Failure' error codes. Full resolution requires encrypting entire RSVP signaling messages.
The ERO Hop Attributes subobject has a 4-byte header with L (1 bit), Type (7 bits, value 35), Length (8 bits), Reserved (15 bits, must be zero), and R (1 bit), followed by variable-length Hop Attributes TLVs. The maximum TLV payload size is 250 bytes due to ERO subobject size limits.
The RRO Hop Attributes subobject has a 4-byte header with Type (8 bits, value 35), Length (8 bits), and Reserved (16 bits, must be zero), followed by variable-length Hop Attributes TLVs encoded as in Section 2.2.