Transparent Interconnection of Lots of Links (TRILL): Multi-Topology
updates
Extracted elements (28)
A Number of Trees to Compute field value of zero in the Trees sub-TLV for a non-zero topology is honored and causes no distribution trees to be calculated for that topology. This differs from topology zero, where a zero value causes one tree to be computed, allowing topologies to exist with only unicast traffic.
Multi-topology creates different logical subsets from a single physical TRILL campus, constraining TRILL Data packets to specific switches and links. This differs from Data Labels (VLANs/FGLs), which create virtual end-station topologies but allow packets to traverse any physical path regardless of label.
There is no 'MT capability bit'; a TRILL switch signals MT capability simply by advertising any topology (even just topology zero explicitly) via the MT TLV in its LSP. This avoids a separate capability advertisement.
Unlike RFC 5120, which assumes packet topology is always determined implicitly, this document adds optional explicit topology labeling via the MT Label. This accommodates hardware that cannot reliably classify packets by port or content alone.
Unlike RFC 5120, which makes topology zero support optional for MT routers, this document requires all TRILL switches and links to support topology zero. This simplifies network management and avoids a class of configuration errors.
Areas of topology-ignorant TRILL switches can be connected to an MT TRILL campus but will only be able to ingress to, transit, or egress from topology zero TRILL Data packets, functioning as legacy stubs.
On links with a mix of MT, FGL, or VL TRILL switches, the Special VLANs and Flags, Enabled-VLANs, Appointed Forwarders, and VLANs Appointed sub-TLVs MUST occur only in MT Port Capability TLVs with a zero MT-ID, since VL and FGL TRILL switches do not understand topologies.
A non-zero topology TRILL Data packet MUST NOT be forwarded onto a link unless the link meets the topology support requirements of Section 2.2, even if there are MT TRILL switch ports on the link. This prevents topology boundary violations on multi-access links.
A TRILL switch advertises supported topologies via MT TLVs in its LSP. It MUST support topology zero. MT TLVs SHOULD be advertised in core LSP fragment zero for robust and rapid flooding.
All MT TRILL switches MUST support FGL in the sense of being FGL safe (RFC 7172), and thus MUST support all four data labeling area content formats. This requirement collapses FGL and MT support to reduce implementation variations and simplify testing.
All TRILL switches and links MUST support topology zero, the special default base topology. Topology zero is used for management messages, BFD, RBridge Channel messages, and similar traffic.
An MT TRILL switch MUST have logically separate routing tables per topology for the forwarding of multi-destination traffic.
Multi-topology TRILL switches advertise supported topologies in MT TLVs in every TRILL Hello sent out a port, except they MUST handle topology zero (which is optional to list). A link is usable for non-zero topology T only if all ports on the link advertise topology T support.
On receiving a TRILL Data packet whose explicit topology label differs from the port's own topology determination for that packet, the TRILL switch MUST discard the packet (applies to ports with Explicit Topology capability value 1).
To minimize transient inconsistencies, all Nickname sub-TLVs advertised by a TRILL switch for a particular nickname (whether in Router Capability or MT Router Capability TLVs) SHOULD appear in the same LSP PDU, or all LSP PDUs containing them SHOULD be flooded as an atomic action.
When a TRILL switch transmits a TRILL Data packet onto a link where any other TRILL switch requires explicit topology labeling, an explicit topology label MUST be included unless the packet is in topology zero (in which case it MAY be included).
Adjacency for topology zero is announced using the Extended Intermediate System Reachability TLV (#22) in core LSPs, maintaining compatibility with legacy topology-ignorant RBridges. Adjacency for non-zero topologies is announced using MT Reachable Intermediate Systems TLV (#222) as specified in RFC 5120.
Distribution trees for non-zero topology T are built using only links usable with topology T, and automatically span only internally connected islands of that topology. Only Nickname, Trees, Tree Identifiers, and Trees Used sub-TLVs occurring in MT Router Capabilities TLV (#144) specifying topology T are used for tree root determination.
Explicit topology labeling support is indicated by a 2-bit capability field (bits 14-15) in the Port TRILL Version Sub-TLV. Four values are defined: 0 (no support), 1 (can insert and tolerate but does not require), and 2 or 3 (requires explicit label in received packets except for topology zero).
In MT TRILL switches, end station MAC address learning is qualified by topology as well as by label (VLAN or FGL). ESADI (End Station Address Distribution Information) operates per label per topology, with separate link state databases per topology area.
RBridge Channel messages (including BFD over TRILL) appear to transit TRILL switches like normal multi-destination TRILL Data packets and therefore have a topology. They are generally sent in topology zero when used for network management to avoid topology constraints.
TRILL switch nicknames are common across all topologies. Nickname allocation uses only Nickname sub-TLVs in Router Capabilities TLVs (#242), ignoring those in MT Router Capability TLVs (#144) for allocation purposes. However, Nickname sub-TLVs in non-zero topology MT Router Capability TLVs do affect distribution tree root selection.
TRILL unicast routing in MT uses logically separate forwarding tables per topology T, each calculated based on least-cost routing within T using only links and nodes that support T. The next hop is determined by a lookup on {topology, egress nickname}.
IANA assigned bits 14-15 of the Port TRILL Version Sub-TLV Capability Flags for 'Topology labeling support' (Explicit Topology capability field). The IEEE Registration Authority allocated Ethertype 0x9A22 for the MT Label.
IANA created the informational 'TRILL Ethertypes' subregistry within the TRILL Parameters registry, documenting IEEE-assigned Ethertypes: 0x22F3 (TRILL data), 0x22F4 (L2-IS-IS), 0x893B (FGL), 0x8946 (TRILL RBridge Channel), and 0x9A22 (MT Multi-Topology).
Multiple topologies can be used for traffic isolation and security; for instance, sensitive traffic can be placed in a topology that excludes links prone to adversarial observation. Delivery of data originating in one topology outside that topology is a security policy violation. Using IS-IS security (RFC 5310) on all IS-IS PDUs and link-layer security on all links is recommended to prevent such violations.
The MT Label is a 32-bit field: a 16-bit MT Ethertype (0x9A22), a 2-bit version field V (version zero defined here), a 2-bit reserved field R (sent as zero, ignored on receipt), and a 12-bit MT-ID topology identifier using the MT TLV number space.
TRILL Data packet data labeling area supports four standardized content varieties: (1) C-VLAN (0x8100 + PRI/D/VLAN-ID), (2) FGL (two 0x893B words with high/low FGL parts), (3) MT C-VLAN (0x9A22 MT label followed by C-VLAN), and (4) MT FGL (0x9A22 MT label followed by two FGL words). Packets with any other data labeling are discarded.