rfc-6325

Routing Bridges (RBridges): Base Protocol Specification

R. Perlman, D. Eastlake 3rd, D. Dutt, S. Gai, A. Ghanwani
date2011-07 streamIETF areartg wgtrill statusPROPOSED STANDARD pages99 canonicalhttps://www.rfc-editor.org/rfc/rfc6325 doi10.17487/RFC6325 errataview
Routing Bridges (RBridges) provide optimal pair-wise forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. They achieve these goals using IS-IS routing and encapsulation of traffic with a header that includes a hop count. RBridges are compatible with previous IEEE 802.1 customer bridges as well as IPv4 and IPv6 routers and end nodes. They are as invisible to current IP routers as bridges are and, like routers, they terminate the bridge spanning tree protocol. The design supports VLANs and the optimization of the distribution of multi-destination frames based on VLAN ID and based on IP-derived multicast groups. It also allows unicast forwarding tables at transit RBridges to be sized according to the number of RBridges (rather than the number of end nodes), which allows their forwarding tables to be substantially smaller than in conventional customer bridges. [STANDARDS-TRACK]

updated by

Extracted elements (29)

design-rationale §3.6

An RBridge drops a frame when it arrives with hop count zero rather than after decrementing to zero (the IPv4/IPv6 behavior). This non-obvious choice is made to support a future traceroute-like facility that needs to elicit a hop-count-exceeded error from the egress RBridge itself.

routing

design-rationale §4.2

IS-IS was chosen as the TRILL routing protocol because it runs directly over Layer 2 without requiring IP address configuration, and because it is easily extended by defining new TLV/sub-TLV data elements to carry TRILL-specific information such as nicknames, appointed forwarders, and distribution tree roots.

routing

interoperability-note §2.6

RBridge ports are layered on top of IEEE 802.1Q-2005 port facilities and are compatible with 802.1D/802.1Q customer bridges, allowing incremental deployment. RBridges do not use the spanning tree protocol and do not block ports, but they terminate the spanning tree at their ports and handle BPDUs locally.

routing

normative-requirement §4.2.3 MUST

All RBridges MUST participate in the TRILL IS-IS instance, which constitutes a single Level 1 IS-IS area using the fixed area address zero. TRILL IS-IS frames are never forwarded by an RBridge but are locally processed on receipt.

routing

normative-requirement §3.6 MUST

An RBridge drops any TRILL frame received with a hop count of zero; otherwise it MUST decrement the hop count by at least 1. For multi-destination frames, transit RBridges MAY decrease the hop count by more than 1 to protect against temporary loops, but MUST NOT reduce it below what is needed to reach all destinations in that branch.

routing, security

normative-requirement §3.2 MUST

An RBridge MUST check the V (Version) field in a received TRILL-encapsulated frame. If the value is not recognized, the RBridge MUST silently discard the frame. New TRILL Version numbers require an IETF Standards Action.

routing, security

normative-requirement §2.2 MUST

Even when ESADI is used to announce end nodes, RBridges MUST still learn end-station MAC addresses from received native frames and from the ingress nickname, Inner.VLAN, and Inner.MacSA of decapsulated TRILL Data frames, unless explicitly configured not to do so.

routing

normative-requirement §4.1.1 MUST

Frames with the same source address, destination address, VLAN, and priority received on the same port MUST be transmitted in the order received, unless the RBridge classifies them into more fine-grained flows, in which case the ordering requirement applies per flow.

routing, qos

normative-requirement §1.4 MUST NOT

Layer 2 control frames with multicast destination addresses in the range 01-80-C2-00-00-00 to 01-80-C2-00-00-0F or equal to 01-80-C2-00-00-21 MUST NOT be encapsulated and forwarded by RBridges. RBridges conformant to this specification MUST discard TRILL other frames (those using the 16 reserved TRILL multicast addresses other than All-RBridges and All-IS-IS-RBridges).

routing, security

normative-requirement §4.2.4.1 MUST

RBridge P2P ports MUST use the IS-IS three-way handshake (RFC 5303) so that extended circuit IDs are associated with the link for tie-breaking during distribution tree computation. P2P ports MUST NOT provide any end-station (native frame) service.

routing

normative-requirement §4.2.4.4 MUST

RBridges MUST use the Extended IS Reachability TLV (#22, wide metric) for advertising neighbor costs and MUST NOT use the IS Reachability TLV (#2, narrow metric). By default, link cost SHOULD be set to the integer part of 20,000,000,000,000 divided by the port's bit rate, not to exceed 2**24-2.

routing

normative-requirement §4.1.2 MUST NOT

The Inner.VLAN tag MUST NOT be changed by any transit RBridge as a TRILL frame passes through, except when VLAN mapping is intentionally performed within that RBridge. The Inner.VLAN carries the VLAN ID and priority of the original native frame.

routing

normative-requirement §3.3 MUST

The two R (Reserved) bits in the TRILL header MUST be set to zero by an ingress RBridge, MUST be transparently copied but otherwise ignored by transit RBridges, and are ignored by egress RBridges. Allocation of reserved TRILL header bits requires an IETF Standards Action.

routing

normative-requirement §4.1.1 MUST NOT

VLAN ID 0xFFF MUST NOT be used. RBridges MUST discard any frame received with an Outer.VLAN ID of 0xFFF and MUST discard any frame for which examination of the Inner.VLAN ID reveals 0xFFF; this examination is required at all egress RBridges.

routing, security

normative-requirement §3.8 MUST

When the CHbH (Critical Hop-by-Hop) bit in the TRILL options area is set, transit RBridges that do not support all critical hop-by-hop options present MUST drop the frame. When CItE (Critical Ingress-to-Egress) or CHbH is set, egress RBridges that do not support all critical options present MUST drop the frame.

routing

normative-requirement §3.7.3 MUST

When two RBridges claim the same nickname, the RBridge with the numerically higher IS-IS ID (or, on a tie in priority, higher IS-IS System ID) retains the nickname, and the other MUST select a new nickname. Reserved values 0x0000 and 0xFFC0–0xFFFF MUST NOT be selected or configured.

routing

protocol-element §4.5

Distribution trees are computed by all RBridges using SPF and span the entire campus. Multi-destination frames are forwarded along a specific tree selected by the ingress RBridge, subject to VLAN and IP multicast pruning and a Reverse Path Forwarding Check to suppress loops.

routing, multicast

protocol-element §3.7

RBridge Nicknames are 16-bit dynamically acquired identifiers that abbreviate IS-IS IDs for use in the TRILL header. Value 0x0000 indicates an unspecified nickname, values 0xFFC0 through 0xFFFF are reserved, and each nickname in use also designates a distribution tree rooted at the corresponding RBridge.

routing

protocol-element §4.2.4.2

The Designated RBridge (DRB) is elected per LAN link via TRILL-Hello priority and source MAC address. The DRB designates a VLAN for all inter-RBridge communication on the link, assigns pseudonode IDs, issues CSNPs, and appoints an RBridge as the single VLAN-x forwarder for each VLAN appearing on the link.

routing

protocol-element §4.2.5

The ESADI (End-Station Address Distribution Information) protocol is a per-VLAN IS-IS instance carried in TRILL Data frames (Inner.MacDA All-ESADI-RBridges, L2-IS-IS Ethertype). It allows appointed VLAN-x forwarders to optionally distribute authenticated MAC address information to other RBridges, providing more authoritative learning than data-plane snooping.

routing, security

protocol-element §3.4

The M (Multi-destination) bit distinguishes frame delivery modes: M=0 indicates known unicast where the egress nickname field specifies the decapsulating RBridge; M=1 indicates multi-destination delivery where the egress nickname field specifies a distribution tree root nickname selected by the ingress RBridge.

routing, multicast

registry §7.1

IANA assignments required by this document include new Ethertype values for TRILL and L2-IS-IS (coordinated with IEEE Registration Authority per Section 7.2), allocation of TRILL Version number space (new versions require an IETF Standards Action), and allocation of the TRILL header reserved bit space (requires an IETF Standards Action).

registry, routing

registry §7.2

IEEE Registration Authority assignments requested by this document include the TRILL Ethertype, the L2-IS-IS Ethertype, and multicast MAC addresses for All-RBridges, All-IS-IS-RBridges, and All-ESADI-RBridges, plus 16 multicast MAC addresses reserved for TRILL use.

registry, routing

security-consideration §6.2

TRILL Hello and BPDU flooding can be exploited as denial-of-service vectors. An attacker on a link can send spoofed Hellos to disrupt DRB election or appointed-forwarder assignments, or flood BPDUs to trigger repeated inhibition of appointed forwarders. The specification notes these threats without mandating specific mitigations beyond the inhibition mechanism.

security, routing

security-consideration §6.1

VLAN security in a TRILL campus depends on correct appointed-forwarder operation; misconfiguration can allow frames to cross VLAN boundaries. The ESADI protocol supports cryptographic authentication of MAC address advertisements via IS-IS authentication (RFC 5304, RFC 5310), and end-node enrollment can be secured via 802.1X EAP methods.

security, routing

state-machine §4.2.4.3

An appointed VLAN-x forwarder transitions to an inhibited state (dropping native frames it receives or decapsulates) after observing a root bridge change on its link (inhibited for 0–30 seconds, default 30) or upon receiving a Hello from another RBridge claiming the same appointment. It resumes normal operation after the inhibit timer expires or the conflict resolves.

routing, security

wire-format §4.1

A TRILL Data frame on an Ethernet link is structured as: Outer Ethernet Header (with TRILL Ethertype), TRILL Header, Inner Ethernet Header (original frame's MAC addresses and VLAN tag), Ethernet Payload, and a new FCS. The outer header carries the next-hop RBridge and transmitting RBridge MAC addresses.

routing

wire-format §3.1

The TRILL header is a 6-octet base structure containing: V (2-bit version), R (2-bit reserved), M (1-bit multi-destination), Op-Length (5-bit options length in 4-octet units), Hop Count (6-bit), Egress RBridge Nickname (16-bit), and Ingress RBridge Nickname (16-bit), followed by optional variable-length options.

routing, security

wire-format §4.2.3

The TRILL IS-IS frame on 802.3 uses an Outer Ethernet Header with the All-IS-IS-RBridges multicast destination, source RBridge MAC, optional Outer.VLAN tag, L2-IS-IS Ethertype, IS-IS payload, and FCS. It carries no TRILL header.

routing