Summary

  • RFC 5420 created TLV-based attribute carriage because the eight-bit SESSION_ATTRIBUTE Flags field could not accommodate continuing extensions. The mechanism applies to MPLS and GMPLS packet and non-packet LSPs.
  • The Attribute Flags TLV can appear in either LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES. The TLV, and any bit within it, does not independently make an attribute required. The carrying object determines transparent forwarding versus path-wide required examination.
  • LSP_ATTRIBUTES uses class 197, a C-Num object. An unknown object, TLV or bit in this optional carriage context is forwarded unchanged. LSP_REQUIRED_ATTRIBUTES uses class 67: an unknown object, unknown TLV or set unknown bit causes setup rejection through the corresponding PathErr.

The requester chooses the enforcement boundary. It may request transparent carriage, selective interpretation or path-wide examination, but it cannot use the base object to invent a universal reaction for a recognized attribute that is unsupported. The defining RFC retains authority over that attribute’s semantics and failure behavior.

The counterfactuals are explicit. If an unknown TLV or bit is in LSP_ATTRIBUTES, it is forwarded unchanged; that proves carriage, not compliance. If an unknown object, TLV or set bit is in LSP_REQUIRED_ATTRIBUTES, setup is rejected. If an attribute is recognized but unsupported, its defining RFC decides what follows rather than a universal rule supplied by class 67. The transit LSR performs recognition and, where the required object demands it, has rejection authority. Downstream LSRs then receive and forward the object according to that same object class and the relevant defining semantics; successful forwarding is not proof that the requested behavior was applied.

The practical distinction is between egress-only, key-transit and all-LSR needs. An egress-only attribute may be carried toward the endpoint without requiring every transit node to understand it. A key-transit attribute may need interpretation at selected hops, but the base object cannot prescribe the defining RFC’s response to non-support. An attribute whose correctness depends on every transit LSR can use required examination, accepting that one unsupported hop may fail the LSP closed.

Do not confuse setup status with proof of application. LSP_REQUIRED_ATTRIBUTES is not used on Resv. Whole-LSP status can be reported in LSP_ATTRIBUTES on Resv, while hop-specific status uses the RRO Attributes subobject. That subobject is bound to the LSR identified by the immediately preceding address or interface subobject; a node must not push it without also pushing that identifier. Per-hop reporting can expose operational state to later readers and consumes RRO and message space. If the added subobject makes the RRO too large, RFC 5420 invokes RFC 3209’s oversized-RRO processing rules. A node may set or clear a compliance bit only where the defining RFC gives it meaning and specifies whether reporting is meaningful or required.

At an LSP-region boundary, a forwarding-adjacency LSP may inherit a subset of Attributes TLVs under local policy when the boundary supports the relevant objects. Otherwise, the attribute objects are copied with the inherited ERO. This is a boundary-policy decision, not an assumption that a local attribute survives every transition. RFC 5420 uses one IANA-managed bit-number space for the Attribute Flags TLV and the RRO Attributes subobject, while each defining RFC must state where a bit has meaning and handle its zero default.

RFC 7570 is a later generic extension of the RFC 5420 mechanism for hop-specific ERO and RRO attributes and registry guidance. It is not proof of universal deployment and is not specifically a protection-only mechanism.

Verification fixtures

  1. Send a Path through a legacy LSR with an unknown TLV in LSP_ATTRIBUTES. Verify unchanged forwarding, not rejection; this demonstrates carriage, not compliance.
  2. Send a Path with an unknown LSP_REQUIRED_ATTRIBUTES object. Verify PathErr setup failure.
  3. Send class 67 with an unknown TLV and then with an unknown set bit. Verify the corresponding Unknown Attributes TLV and Unknown Attributes Bit errors.
  4. Send a recognized required attribute whose defining RFC tolerates non-support, and another whose defining RFC says otherwise. Verify that the defining RFC determines the result.
  5. Inspect Resv for whole-LSP status, then inspect each RRO Attributes subobject and bind it to the immediately preceding LSR address or interface. Test identifier omission and oversized-RRO handling.
  6. Test egress-only, key-transit and all-LSR policies separately. At a forwarding-adjacency boundary, verify subset inheritance under local policy and the inherited-ERO fallback.
  7. Check the shared bit registry, zero-default behavior and RFC 7570 registration guidance before assigning a new bit.

The evidence boundary matters. The source set establishes protocol rules, but not which vendors or operators implement a particular attribute, reporting behavior or inheritance policy. It provides no deployment prevalence, setup-failure rate, setup latency or customer-impact measurement. Successful optional setup therefore does not establish that the attribute was applied or reported as intended. There are no allegations in this source set.

Operator decision path

First state the dependency: endpoint-only, selected key hops or every transit LSR. Next identify the defining RFC for each TLV and bit, including recognized-but-unsupported behavior and the zero default. Choose class 197 when reachability and transparent carriage are acceptable; choose class 67 only when examination is a condition of correctness. Define Resv and RRO evidence, including identifier binding, disclosure implications and message-size limits. Finally test legacy, partially capable and region-boundary paths before treating setup success as an operational conclusion.

Sources