Transparent Interconnection of Lots of Links (TRILL) Smart Endnodes
Extracted elements (25)
Smart Endnodes use the nickname of the attached edge RBridge rather than consuming their own nicknames. This solves the endnode table size and freshness problem at edge RBridges by offloading encapsulation/decapsulation to capable endnodes without expanding the nickname space.
The multihoming bit (M) in the Smart-MAC APPsub-TLV was introduced to solve MAC flip-flopping when a Smart Endnode uses active-active load balancing across two edge RBridges with different nicknames. Remote RBridges retain both (MAC, label, RB1) and (MAC, label, RB2) entries simultaneously when M=1.
The Smart Endnode solution supports FGL-aware endnodes: because Smart Endnodes perform their own encapsulation, they can set the Inner.Label to a Fine-Grained Label (RFC 7172). When and how to choose FGL versus VLAN is explicitly left out of scope.
All TRILL Data packets sent to or from Smart Endnodes are sent in the Designated VLAN of the local link but do not necessarily need to be VLAN-tagged.
Smart Endnodes do not transmit or receive IS-IS LSPs or E-L1FS FS LSPs and do not perform routing calculations. Only the attached edge RBridge can distinguish a Smart Endnode from a normal endnode; the rest of the TRILL campus is unaware of the distinction.
A Smart Endnode SHOULD send a Smart-Hello immediately if RB1 crashes and restarts, or if the DRB changes and SE1 receives a Smart-Hello that does not mention SE1.
All Flags bits in the Smart-Parameters APPsub-TLV MUST be sent as zero and ignored on receipt. If no Smart-Parameters APPsub-TLV appears in a Smart-Hello, that Smart-Hello is ignored.
Avoiding hybrid endnode ports (mixing Smart Endnodes and normal endnodes on the same port) is RECOMMENDED because it requires dual-copy multicast transmission and adds edge RBridge complexity.
Both Smart Endnodes and edge RBridges supporting Smart Endnodes MUST send a Smart-Hello at least three times during their Holding Time. If no Smart-Hellos are received within the most recent Holding Time sent, the peer is assumed no longer available.
Edge RBridge RB1 SHOULD filter encapsulated frames from Smart Endnode ports based on the inner source MAC and Data Label expected for that Smart Endnode; frames with unexpected MAC or Data Label SHOULD be dropped to prevent rogue injection.
The edge RBridge RB1 MUST list a Smart Endnode in its Smart-Hellos as a Smart Endnode neighbor if RB1 is Appointed Forwarder for any VLAN that the Smart Endnode claims.
A Smart Endnode maintains an endnode table of (remote MAC address, Data Label, edge RBridge nickname) entries, populated by learning from decapsulated packets, directory queries, or static configuration — mirroring how an edge RBridge populates its own table.
On ports with hybrid endnodes (both Smart and non-Smart), RB1 sends two copies of multicast frames: one native (for normal endnodes) and one TRILL-encapsulated (for Smart Endnodes). Avoiding hybrid ports is RECOMMENDED to reduce complexity and bandwidth waste.
Smart-Hello messages are used by both Smart Endnodes and edge RBridges to announce capabilities and parameters. They are a type of TRILL ES-IS PDU as specified in RFC 8171, and carry TRILL IS-IS TLVs using non-extended (8-bit type/length) format.
The edge RBridge's Smart-Hello carries: its nickname (via nickname sub-TLV inside TLV 242), tree identifiers for multi-destination ingress, a Smart Endnode neighbor list (TRILL Neighbor TLV), and optionally an Authentication TLV.
The F bit in Smart-MAC APPsub-TLV indicates FGL support: if set, the 24-bit VLAN/FGL field carries a Fine-Grained Label; otherwise only the lower 12 bits are used as a VLAN ID and upper 12 bits are ignored.
The M bit in Smart-MAC APPsub-TLV indicates multihoming. When set, remote RBridges and Smart Endnodes retain multiple endnode entries for the same MAC address (one per attached RBridge nickname) to avoid MAC flip-flopping during active-active load balancing.
When RB1 receives a unicast TRILL Data packet destined for a Smart Endnode's MAC, it forwards the packet still encapsulated: the outer Ethernet destination is the Smart Endnode's MAC, and RB1 decrements the hop count by 1 to account for the RB1-to-Smart-Endnode hop.
IANA has assigned two APPsub-TLV type values in the 'TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1' registry: type 22 for Smart-Parameters and type 23 for Smart-MAC, both referencing RFC 8384.
Misbehaving Smart Endnodes can forge arbitrary ingress and egress nicknames in TRILL headers, causing remote RBridges to misdirect future traffic via data-plane learning. RBridge ports MUST NOT be configured for Smart Endnodes unless end stations are trusted or adequately authenticated.
Smart Endnodes can forge both outer and inner MAC addresses and can send data in any Data Label, bypassing Data Label-based security policies. End-to-end encryption and authentication between source and destination end stations is recommended as a countermeasure.
Smart Endnodes learn the MAC addresses of attached edge RBridges and egress RBridge nicknames, giving them significant visibility into TRILL domain topology. Compromised Smart Endnodes pose a topology information disclosure risk.
Smart-Hellos can be secured with Authentication TLVs based on RFC 5310. Without authentication, a rogue end station could falsely present itself as a valid Smart Endnode and gain encapsulation privileges on the TRILL campus.
The Smart-MAC APPsub-TLV (type 23) encodes a 1-bit FGL flag (F), 1-bit multihoming flag (M), 6-bit reserved field, a 24-bit VLAN/FGL Data Label, and N 48-bit MAC addresses. Total length is 4 + 6*N bytes.
The Smart-Parameters APPsub-TLV (type 22) is 4 bytes long and contains a 2-byte Holding Time (unsigned integer, seconds) and a 2-byte Flags field (all bits currently reserved, sent as zero). It MUST appear in every Smart-Hello inside a TRILL GENINFO TLV.