Coordinated Multicast Trees (CMT) for Transparent Interconnection of Lots of Links (TRILL)
updates
- rfc-6325 — Routing Bridges (RBridges): Base Protocol Specification
Extracted elements (24)
All RBridges outside the edge group assume that multi-destination packets with Ingress Nickname set to RBv might use any distribution tree advertised by any member of the edge group. This conservative assumption avoids black-holing while permitting flexible tree use across the active-active group.
CMT requires only a software upgrade (no hardware/silicon changes), making it deployable as a control-plane enhancement. Backward compatibility via tunneling would require silicon changes, whereas CMT itself does not.
The active-active load-sharing model is implemented by representing the edge group with a single virtual RBridge nickname. Without this, existing RPF check algorithms (which strictly depend on link cost and parent RBridge priority) may leave a given edge RBridge with no valid distribution tree on which to forward traffic on behalf of the virtual RBridge.
When an RBridge advertises an Affinity sub-TLV designating one of its own nicknames as a child in a specific distribution tree, the effect is that nickname is ignored in all other distribution trees, enforcing RPF so that only that RBridge can use the nickname as ingress/egress on the designated tree. This has no effect on unicast SPF calculations.
If any RBridges in the campus do not support the Affinity sub-TLV, distribution trees fall back to the RFC 6325 / RFC 7780 SPF-based algorithm. CMT requires all campus RBridges to support the Affinity sub-TLV for full operation; the fallback is intended as a temporary measure during upgrade.
The Affinity sub-TLV is applicable specifically where a virtual RBridge represents multiple RBridges connected to an edge CE device via an LAALP (e.g., MC-LAG) where the RBridges cannot see each other's Hellos. The document does not cover other required active-active operational elements such as MC-LAG methods.
An AFFINITY RECORD asking for an RBridge to be its own child in a tree rooted at that RBridge, or asking for a non-adjacent non-self nickname as a child, MUST be ignored as it conflicts with TRILL distribution tree root determination or campus topology.
Each virtual RBridge MUST have a nickname unique within its TRILL campus to enable active-active load-sharing representation of the edge network.
For ingress multi-destination forwarding, an edge RBridge RBk encapsulates frames with a TRILL Header setting the Ingress Nickname field to RBv (the virtual RBridge nickname) and forwards on a distribution tree where RBv is associated with RBk.
If no tree exists on which RBv can claim affinity via RBk (e.g., n < k), then RBk MUST fall back to either disabling its CE-facing ports or tunneling multi-destination frames to an RBridge that has an assigned tree.
Implementations MUST support backward compatibility modes to interoperate with pre-Affinity sub-TLV RBridges, which MAY include tunneling and/or active-standby modes of operation.
In the absence of an Affinity sub-TLV, or if any RBridges in the campus do not support the Affinity sub-TLV, distribution trees MUST be calculated as specified in Section 4.5.1 of RFC 6325 (as updated by RFC 7780).
It is RECOMMENDED that timer T_j (used by existing member RBridges when a rejoining RBridge appears) be less than T_i (used by the rejoining RBridge itself), with a reasonable default of T_j = 1/2 of T_i, to reduce packet duplication which is more serious than dropped packets.
Multi-destination frames arriving at RBk on a tree where RBk has announced affinity of RBv MUST be forwarded to CE members of RBv in the frame's VLAN; frames arriving on a tree where RBk has NOT announced affinity of RBv MUST NOT be forwarded to CE members of RBv.
Remote RBridges MUST honor the Affinity sub-TLV from the RBridge with the highest priority to be a tree root (using System ID as tiebreaker) and MUST ignore conflicting Affinity sub-TLV entries from lower-priority RBridges.
When an Affinity sub-TLV is present, the association specified by the Affinity sub-TLV MUST be used when constructing the multi-destination distribution tree, except in the case of a conflicting Affinity sub-TLV (resolved per Section 5.3).
When conflicting Affinity sub-TLVs advertise the same virtual RBridge as child in the same tree, the RBridge with the highest priority to be a tree root retains the affinity association; lower-priority RBridges MUST stop advertising conflicting Affinity sub-TLVs, recalculate, and if appropriate advertise new non-conflicting ones.
A virtual RBridge is a purely conceptual RBridge representing an active-active edge group, assigned a unique nickname within the TRILL campus. Each edge RBridge (RB1 to RBk) advertises the virtual RBridge nickname (RBv) using the Nickname sub-TLV (6) along with its own regular nicknames. Virtual RBridges are ignored when determining distribution tree roots.
RBridges that announce the TRILL Version sub-TLV and set the Affinity capability bit (bit 0 in the TRILL-VER Sub-TLV Capability Flags registry) support the Affinity sub-TLV, CMT distribution tree calculation, and RPF checks as specified in this document.
The Affinity sub-TLV is a new IS-IS sub-TLV that allows an RBridge to specify its desired path of association to a given TRILL multi-destination distribution tree. It appears in Router Capability TLVs or MT Capability TLVs within Link State PDUs (LSPs). The code point and data structure are specified in RFC 7176.
This document registers 'Affinity sub-TLV support' as bit 0 in the 'TRILL-VER Sub-TLV Capability Flags' registry. The AFFINITY sub-TLV (value 17) in the 'Sub-TLVs for TLV 144' registry remains referenced to RFC 7176.
RBridges in a campus are generally trusted routers, and the authenticity of LSPs and link-local PDUs carrying Affinity sub-TLVs can be enforced using IS-IS security mechanisms (including RFC 5310 cryptographic authentication). Application-specific security considerations for Affinity sub-TLV use cases will be covered in application-specific documents.
Distribution tree assignment assigns trees to edge RBridges sorted by IS-IS System ID in ascending order. If n >= k, each RBridge RBi is assigned trees where tree_number % k + 1 == i. If n < k, only RB1 through RBn participate in active-active forwarding; RBn+1 through RBk do not.
Upon detecting member RBridge failure (via IS-IS LSP absence), surviving edge group members start recovery timer T_rec. If the failed RBridge has not recovered after T_rec, members recalculate tree assignment and re-advertise Affinity sub-TLVs. On RBi restart, T_i and T_j timers coordinate rejoining; T_j SHOULD be less than T_i (recommended default: T_j = T_i / 2) to minimize packet duplication.