Transparent Interconnection of Lots of Links (TRILL): Header Extension
updated by
- rfc-7780 — Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates
updates
- rfc-6325 — Routing Bridges (RBridges): Base Protocol Specification
Extracted elements (23)
Extensions are 32-bit aligned and the extension area has a hard length limit (Op-Length field caps it at 124 octets) specifically to assist efficient hardware processing of frames with a TRILL Header extensions area. Despite this, including extensions may still force processing onto a 'slow path' with reduced throughput.
The critical summary bits (CHbHS, CItES, CRSVS) were designed to enable simple and efficient hardware processing: an RBridge that supports no critical extensions need only check Op-Length and the top one, two, or three bits of the extensions area to decide whether to discard or forward/process a frame, without parsing all extension flags.
The non-critical Channel Alert flag (bit 8) was defined separately from the critical flag (bit 7) to support use cases such as a 'record route' function in RBridge Channel messages where it is acceptable for transit RBridges that do not support the function to skip recording, without requiring them to discard the frame.
RBridges advertise the extended header flags they support in IS-IS PDUs [RFC7176]. An RBridge that has not advertised support for a critical extended header flag will not normally receive frames with that flag set, providing a 'no critical surprises' guarantee. An RBridge is not required to support any extensions.
To indicate support of hop-by-hop extended header flags 3-13, bits 3-13 of the PORT-TRILL-VER Sub-TLV Capability Flags are assigned; to indicate support of extended header flags 14-31, bits 14-31 of the TRILL-VER Sub-TLV Capability Flags are assigned. These registries are defined in RFC7176.
A transit RBridge MUST adjust the length of the extensions area (including changing Op-Length in the TRILL Header) if it adds or removes the extended header flags word, and MUST correctly set the critical summary bits if it adds the word or changes any critical flags.
A transit RBridge MUST NOT remove the extended header flags word unless it is all zero (either on arrival or after permitted modifications), and MUST NOT set or clear ingress-to-egress or reserved extended header flags except as specifically permitted in the specification of such flags.
All RBridges MUST check whether any critical flags applicable to their processing of the frame are set. If an RBridge does not implement all critical flags in a TRILL Data frame, it MUST treat the frame as having an unimplemented critical extension and discard it accordingly.
An RBridge SHOULD NOT set a critical extended flag in a frame unless it has determined that the RBridges that will receive and process the frame (next-hop for hop-by-hop, egress for ingress-to-egress, or the applicable class for reserved) support that flag.
Any egress RBridge receiving a frame with a critical ingress-to-egress extension it does not implement MUST drop the frame if it is a unicast frame (M bit = 0). For a multi-destination frame (M=1), the RBridge MUST NOT egress the frame but still forwards it on the distribution tree.
Any extended flag indicating a significant change in the structure or interpretation of later frame parts that, if ignored, could cause a failure of service or security policy violation MUST be a critical extension. If such a flag affects fields that transit RBridges examine, it MUST be a hop-by-hop critical extended flag.
Any RBridge receiving a frame with a critical hop-by-hop extension that it does not implement MUST discard the frame, because it is unsafe to process the frame without understanding such a critical extension.
Conflicting extended header flags SHOULD NOT be defined. If conflicting extensions appear in the same packet, results are unpredictable; if they are defined despite this guidance, careful thought must be given to specifying their handling.
For TRILL Data frames with extensions present, any transit RBridge that does not discard the frame MUST transparently copy the extended flags word, except for modifications permitted by an extension implemented by that RBridge.
When CHbHS is set to one, transit RBridges that do not support all critical hop-by-hop extensions present MUST drop the frame. When CItES is set, egress RBridges that do not support all critical extensions MUST drop the frame.
When CRSVS (Critical Reserved Summary) is set to one, RBridges in the reserved class (a future-defined subset of transit RBridges, e.g., multi-level IS-IS border RBridges) MUST drop frames with CRSVS set unless they implement all critical hop-by-hop and all critical reserved extensions present.
The TRILL Header Op-Length field (5 bits) specifies the length of the extensions area in units of 4 octets, allowing up to 124 octets of header extension. When Op-Length is non-zero, the extension area immediately follows the Ingress RBridge Nickname field, and its first 32 bits are always the extended header flags word.
Three critical summary bits (bits 0-2 of the extended header flags word) summarize the presence of critical extensions: CHbHS (bit 0) indicates critical hop-by-hop extensions, CItES (bit 1) indicates critical ingress-to-egress extensions, and CRSVS (bit 2) indicates critical reserved extensions. These bits enable efficient single-check processing by RBridges that need to decide whether to forward or discard a frame.
Two RBridge Channel Alert extended header flags are defined: the Critical Channel Alert flag (bit 7) and the Non-critical Channel Alert flag (bit 8). Their presence signals that the frame is an RBridge Channel message [RFC7178] requiring per-hop processing. If the Critical flag is set and the RBridge does not implement the RBridge Channel feature or the specific protocol, the frame is discarded.
IANA created a 'TRILL Extended Header Flags' subregistry within the TRILL Parameters registry, initially populated per Table 1 (bits 0-2 as critical summary bits, bit 7 as Critical Channel Alert, bit 8 as Non-critical Channel Alert, remaining bits available). New allocations require IETF Review [RFC5226].
It is critical that the critical summary bits be set correctly. If set when the corresponding critical extensions are absent, frames are unnecessarily discarded. If not set when critical extensions are present, frames may be mishandled or corrupted, and intended security policies may be violated.
The RBridge Channel Alert flags may be erroneously set. If either Channel Alert flag is found set in a frame that is not an RBridge Channel message, the flag MAY be cleared and should otherwise have no effect (except possibly delaying processing). If the flag is erroneously omitted, desired per-hop processing may not occur.
The first 32 bits of the TRILL Header extensions area form the extended header flags word, structured as: bits 0-2 (Crit., critical summary bits), bits 3-7 (CHbH, critical hop-by-hop flags), bits 8-13 (NCHbH, non-critical hop-by-hop flags), bits 14-16 (CRSV, critical reserved flags), bits 17-20 (NCRSV, non-critical reserved flags), bits 21-26 (CItE, critical ingress-to-egress flags), and bits 27-31 (NCItE, non-critical ingress-to-egress flags). This 32-bit aligned word is present whenever the TRILL Header Op-Length field is non-zero.