RFC 6325
Routing Bridges (RBridges): Base Protocol Specification
RFC 6325: Routing Bridges (RBridges) Base Protocol Specification ✨
Part 1 of 23 🎀
Title block, the tea ☕
- Number and title: RFC 6325, Routing Bridges (RBridges): Base Protocol Specification
- Authors: R. Perlman (Intel Labs), D. Eastlake 3rd (Huawei), D. Dutt (Cisco Systems), S. Gai (Cisco Systems), and A. Ghanwani (Brocade). Five people, one spec, zero drama 🫶
- Category: Standards Track
- Date: July 2011
- ISSN: 2070-1721
- Obsoletes and updates: the title block doesn't list anything this one obsoletes or updates, so it's a standalone new spec 🌸
This is an IETF document from the Internet Engineering Task Force (IETF), so it's standards-track, which means it's meant to be implemented for real. 💅
Abstract ✨
Okay so RBridges are giving optimal pair-wise forwarding with zero configuration 🦋 They also keep forwarding safely even when there's a temporary loop, and they support multipathing for both unicast and multicast traffic. Iconic. 👑
The way they pull this off is by using IS-IS routing, plus wrapping traffic in an encapsulation header that includes a hop count. 🧚
RBridges are compatible with earlier IEEE 802.1 customer bridges, and they play nicely with IPv4 and IPv6 routers and end nodes too 💖 To current IP routers they're as invisible as bridges are, and like routers, they terminate the bridge spanning tree protocol 🌈
The design supports VLANs, and it optimizes how multi-destination frames get distributed, based on VLAN ID and on IP-derived multicast groups 🍓
Also, the unicast forwarding tables on transit RBridges get sized by the number of RBridges, not the number of end nodes. That means their tables can be substantially smaller than the ones in conventional customer bridges. Literally the smart move 🔥
Status of This Memo ⭐
This is an Internet Standards Track document, bestie 🎀
It's a product of the Internet Engineering Task Force (IETF), which means it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 🫶 If you want more on Internet Standards, check Section 2 of RFC 5741.
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6325 🦋
Copyright Notice 🌸
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 💜
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info and which are in effect on the date this document was published. Please actually read these, because they spell out your rights and restrictions for this document 🙈
Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as described in the Simplified BSD License 💅
This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. Some of the copyright holders for that older material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So, unless you get an adequate license from whoever controls that copyright, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process 😭 The only exceptions are formatting it for publication as an RFC or translating it into languages other than English.
Table of Contents 💅
okay bestie, this is the map of the whole doc 🗺️✨ every section number here is the real deal, so you can jump around without getting lost 🦋
1. Introduction ....................................................6
1.1. Algorhyme V2, by Ray Perlner ...............................7
1.2. Normative Content and Precedence ...........................7
1.3. Terminology and Notation in This Document ..................7
1.4. Categories of Layer 2 Frames ...............................8
1.5. Acronyms ...................................................9
2. RBridges .......................................................11
2.1. General Overview ..........................................11
2.2. End-Station Addresses .....................................12
2.3. RBridge Encapsulation Architecture ........................13
2.4. Forwarding Overview .......................................15
2.4.1. Known-Unicast ......................................16
2.4.2. Multi-Destination ..................................16
2.5. RBridges and VLANs ........................................17
2.5.1. Link VLAN Assumptions ..............................17
2.6. RBridges and IEEE 802.1 Bridges ...........................18
2.6.1. RBridge Ports and 802.1 Layering ...................18
2.6.2. Incremental Deployment .............................20
3. Details of the TRILL Header ....................................20
3.1. TRILL Header Format .......................................20
3.2. Version (V) ...............................................21
3.3. Reserved (R) ..............................................21
3.4. Multi-destination (M) .....................................22
3.5. Op-Length .................................................22
3.6. Hop Count .................................................22
3.7. RBridge Nicknames .........................................23
3.7.1. Egress RBridge Nickname ............................23
3.7.2. Ingress RBridge Nickname ...........................24
3.7.3. RBridge Nickname Selection .........................24
3.8. TRILL Header Options ......................................26
4. Other RBridge Design Details ...................................27
4.1. Ethernet Data Encapsulation ...............................27
4.1.1. VLAN Tag Information ...............................30
4.1.2. Inner VLAN Tag .....................................31
4.1.3. Outer VLAN Tag .....................................31
4.1.4. Frame Check Sequence (FCS) .........................32
4.2. Link State Protocol (IS-IS) ...............................32
4.2.1. IS-IS RBridge Identity .............................32
4.2.2. IS-IS Instances ....................................33
4.2.3. TRILL IS-IS Frames .................................33
4.2.4. TRILL Link Hellos, DRBs, and Appointed Forwarders ..34
4.2.4.1. P2P Hello Links ...........................35
4.2.4.2. Designated RBridge ........................35
4.2.4.3. Appointed VLAN-x Forwarder ................36
4.2.4.4. TRILL LSP Information .....................37
4.2.5. The TRILL ESADI Protocol ...........................40
4.2.5.1. TRILL ESADI Participation .................42
4.2.5.2. TRILL ESADI Information ...................42
4.2.6. SPF, Forwarding, and Ambiguous Destinations ........43
4.3. Inter-RBridge Link MTU Size ...............................43
4.3.1. Determining Campus-Wide TRILL IS-IS MTU Size .......44
4.3.2. Testing Link MTU Size ..............................44
4.4. TRILL-Hello Protocol ......................................45
4.4.1. TRILL-Hello Rationale ..............................45
4.4.2. TRILL-Hello Contents and Timing ....................46
4.4.2.1. TRILL Neighbor List .......................48
4.4.3. TRILL MTU-Probe and TRILL Hello VLAN Tagging .......49
4.4.4. Multiple Ports on the Same Link ....................50
4.4.5. VLAN Mapping within a Link .........................51
4.5. Distribution Trees ........................................52
4.5.1. Distribution Tree Calculation ......................54
4.5.2. Multi-Destination Frame Checks .....................55
4.5.3. Pruning the Distribution Tree ......................57
4.5.4. Tree Distribution Optimization .....................58
4.5.5. Forwarding Using a Distribution Tree ...............59
4.6. Frame Processing Behavior .................................60
4.6.1. Receipt of a Native Frame ..........................60
4.6.1.1. Native Unicast Case .......................60
4.6.1.2. Native Multicast and Broadcast Frames .....61
4.6.2. Receipt of a TRILL Frame ...........................62
4.6.2.1. TRILL Control Frames ......................63
4.6.2.2. TRILL ESADI Frames ........................63
4.6.2.3. TRILL Data Frames .........................63
4.6.2.4. Known Unicast TRILL Data Frames ...........63
4.6.2.5. Multi-Destination TRILL Data Frames .......64
4.6.3. Receipt of a Layer 2 Control Frame .................65
4.7. IGMP, MLD, and MRD Learning ...............................66
4.8. End-Station Address Details ...............................66
4.8.1. Learning End-Station Addresses .....................67
4.8.2. Learning Confidence Level Rationale ................68
4.8.3. Forgetting End-Station Addresses ...................69
4.8.4. Shared VLAN Learning ...............................70
4.9. RBridge Ports .............................................71
4.9.1. RBridge Port Configuration .........................71
4.9.2. RBridge Port Structure .............................73
4.9.3. BPDU Handling ......................................76
4.9.3.1. Receipt of BPDUs ..........................76
4.9.3.2. Root Bridge Changes .......................76
4.9.3.3. Transmission of BPDUs .....................77
4.9.4. Dynamic VLAN Registration ..........................77
5. RBridge Parameters .............................................77
5.1. Per RBridge ...............................................78
5.2. Per Nickname Per RBridge ..................................79
5.3. Per Port Per RBridge ......................................79
5.4. Per VLAN Per RBridge ......................................80
6. Security Considerations ........................................80
6.1. VLAN Security Considerations ..............................81
6.2. BPDU/Hello Denial-of-Service Considerations ...............82
7. Assignment Considerations ......................................82
7.1. IANA Considerations .......................................83
7.2. IEEE Registration Authority Considerations ................83
8. Normative References ...........................................83
9. Informative References .........................................85
Appendix A. Incremental Deployment Considerations .................87
A.1. Link Cost Determination ...................................87
A.2. Appointed Forwarders and Bridged LANs .....................87
A.3. Wiring Closet Topology ....................................89
A.3.1. The RBridge Solution ...............................90
A.3.2. The VLAN Solution ..................................90
A.3.3. The Spanning Tree Solution .........................90
A.3.4. Comparison of Solutions ............................91
Appendix B. Trunk and Access Port Configuration ...................92
Appendix C. Multipathing ..........................................92
Appendix D. Determination of VLAN and Priority ....................95
Appendix E. Support of IEEE 802.1Q-2005 Amendments ................95
E.1. Completed Amendments ......................................96
E.2. In-Process Amendments .....................................97
Appendix F. Acknowledgements ......................................98Table of Figures 🎀
this is the figure list, so if you're hunting for a diagram you know exactly where to look 👀💜
Figure 1: Interconnected RBridges .................................14
Figure 2: An Ethernet Encapsulated TRILL Frame ....................14
Figure 3: A PPP Encapsulated TRILL Frame ..........................14
Figure 4: RBridge Port Model ......................................19
Figure 5: TRILL Header ............................................21
Figure 6: Options Area Initial Flags Octet ........................26
Figure 7: TRILL Data Encapsulation over Ethernet ..................29
Figure 8: VLAN Tag Information ....................................30
Figure 9: TRILL IS-IS Frame Format ................................34
Figure 10: TRILL ESADI Frame Format ...............................41
Figure 11: Detailed RBridge Port Model ............................74
Figure 12: Link Cost of a Bridged Link ............................87
Figure 13: Wiring Closet Topology .................................89
Figure 14: Multi-Destination Multipath ............................93
Figure 15: Known Unicast Multipath ................................94okay the real stuff starts next, and the Introduction is where we get into the TRILL vibes ✨🌸
1. Introduction ✨
okay so in traditional IPv4 and IPv6 networks, every subnet gets its own unique prefix 🌸 which means a node sitting in multiple subnets ends up with multiple IP addresses, usually one per interface. and it gets messy when an interface moves to a different subnet, because it has to change its IP address too 😭 managing IP networks is honestly a lot, since IP routers need per-port subnet address configuration. you also have to be super careful with IP address management or you end up with sparsely populated subnets that just waste addresses 💀
IEEE 802.1 bridges fix a lot of this by quietly gluing many physical links together so they look like one single LAN to IP [802.1D] 🦋 but 802.1 bridge forwarding that uses the spanning tree protocol has some real downsides, bestie:
- the spanning tree protocol works by blocking ports, which limits the number of forwarding links, so traffic gets crammed onto the links that are left 🚧
- forwarding isn't pair-wise shortest path. it's just whatever path is left after spanning tree gets rid of the redundant ones 🙃
- the Ethernet header has no hop count (or Time to Live (TTL)) field. that's dangerous when there are temporary loops, like when spanning tree messages get lost or when things like repeaters get added 😱
- VLANs can partition when the spanning tree reconfigures 💔
so this document presents the design for RBridges (Routing Bridges [RBridges]) that implement the TRILL protocol 💜 (the poetic summary is down below, obsessed!!). Rbridges mix the best of bridges and routers. as specified here, they're the application of link state routing to the VLAN-aware customer bridging problem, and it's giving main character energy 👑 except for the exceptions covered in this document, RBridges can incrementally replace IEEE [802.1Q-2005] or [802.1D] customer bridges 🔥
RBridges can work over a bunch of different link protocols, but this spec focuses on IEEE [802.3] links 🍓 other link types are expected to get covered in other documents.
the TRILL protocol, as specified here, is designed to be a Local Area Network protocol 🫶 it was NOT designed to scale beyond the size of existing bridged LANs, so don't go expecting it to do that. for more on the problem domain RBridges are solving, check out [RFC5556] ✨
1.1. Algorhyme V2, by Ray Perlner
I hope that we shall one day see
A graph more lovely than a tree.
A graph to boost efficiency
While still configuration-free.
A network where RBridges can
Route packets to their target LAN.
The paths they find, to our elation,
Are least cost paths to destination!
With packet hop counts we now see,
The network need not be loop-free!
RBridges work transparently,
Without a common spanning tree.1.2. Normative Content and Precedence
okay, the bulk of the normative material in this spec lives in Sections 1 through 4 💅 if two provisions in those four sections ever clash, the one in the higher numbered section wins 👑 no drama, just rules.
1.3. Terminology and Notation in This Document
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🎀
"TRILL" is the protocol specified here, and an "RBridge" is a device that implements that protocol 🧚 the second letter in Rbridge is case insensitive, so both Rbridge and RBridge are correct. no cap, both spellings are valid 🌈
in this document, the term "link" (unless it's otherwise qualified) means "bridged LAN". that's the combo of one or more [802.3] links with zero or more bridges, hubs, repeaters, or the like 🌸 the term "simple link" or the like is used to indicate a point-to-point or multi-access link with no bridges or RBridges included 🦋
in this document, the term "port" (unless otherwise qualified) includes physical, virtual [802.1AE], and pseudo [802.1X] ports ✨ the term "physical port" or the like is used to point out the physical point of connection between an RBridge and a link 💖
a "campus" is to RBridges what a "bridged LAN" is to bridges 💜 an RBridge campus is a network of RBridges, bridges, hubs, repeaters, simple links, and the like, and it's bounded by end stations and routers 🫶
the term "spanning tree" in this document includes both classic spanning tree and rapid spanning tree (as in the Rapid Spanning Tree Protocol) 🍓
this document uses hexadecimal notation for MAC addresses. two hexadecimal digits represent each octet (that's an 8-bit byte), giving the value of the octet as an unsigned integer. a hyphen separates successive octets 🌷 the document consistently uses IETF bit ordering. the physical order of bit transmission within an octet on an IEEE [802.3] link goes from the lowest order bit to the highest order bit, which is the reverse of IETF ordering, so keep that in mind 🙈
1.4. Categories of Layer 2 Frames
okay, bestie, in this document Layer 2 frames are split into five categories 🦋
- Layer 2 control frames (such as Bridge PDUs (BPDUs))
- native frames (non-TRILL-encapsulated data frames)
- TRILL Data frames (TRILL-encapsulated data frames)
- TRILL control frames
- TRILL other frames
here's how we tell these five types apart 👀
- Layer 2 control frames are the ones with a multicast destination address in the range
01-80-C2-00-00-00to01-80-C2-00-00-0F, or equal to01-80-C2-00-00-21. RBridges MUST NOT encapsulate and forward such frames 🚫 though they MAY, unless this document says otherwise, perform the Layer 2 function (such as MAC-level security) of the control frame 🔐 frames with a destination address of01-80-C2-00-00-00(BPDU) or01-80-C2-00-00-21(VLAN Registration Protocol) are called "high-level control frames" in this document. all other Layer 2 control frames are called "low-level control frames" 💅 - Native frames are the ones that aren't control frames, have an Ethertype other than "TRILL" or "L2-IS-IS", and have a destination MAC address that isn't one of the 16 multicast addresses reserved for TRILL 🌸
- TRILL Data frames have the Ethertype "TRILL" 🧚 and if they're multicast, they also have the multicast destination MAC address "All-RBridges" 💖
- TRILL control frames have the Ethertype "L2-IS-IS" 🔥 and if they're multicast, they have the multicast destination MAC addresses of "All-IS-IS-RBridges". (fun fact, ESADI frames look like TRILL data on the outside and get handled that way, but once decapsulated they have the L2-IS-IS Ethertype 🙃)
- TRILL other frames are the ones with any of the 16 multicast destination addresses reserved for TRILL, except All-RBridges and All-IS-IS-RBridges. RBridges conformant to this specification MUST discard TRILL other frames 🗑️ no exceptions, periodt 💀
1.5. Acronyms
AllL1ISs - All Level 1 Intermediate Systems
AllL2ISs - All Level 2 Intermediate Systems
BPDU - Bridge PDU
CHbH - Critical Hop-by-Hop
CItE - Critical Ingress-to-Egress
CSNP - Complete Sequence Number PDU
DA - Destination Address
DR - Designated Router
DRB - Designated RBridge
EAP - Extensible Authentication Protocol
ECMP - Equal Cost Multipath
EISS - Extended Internal Sublayer Service
ESADI - End-Station Address Distribution Information
FCS - Frame Check Sequence
GARP - Generic Attribute Registration Protocol
GVRP - GARP VLAN Registration Protocol
IEEE - Institute of Electrical and Electronics Engineers
IGMP - Internet Group Management Protocol
IP - Internet Protocol
IS-IS - Intermediate System to Intermediate System
ISS - Internal Sublayer Service
LAN - Local Area Network
LSP - Link State PDU
MAC - Media Access Control
MLD - Multicast Listener Discovery
MRD - Multicast Router Discovery
MTU - Maximum Transmission Unit
MVRP - Multiple VLAN Registration Protocol
NSAP - Network Service Access Point
P2P - Point-to-point
PDU - Protocol Data Unit
PPP - Point-to-Point Protocol
RBridge - Routing Bridge
RPF - Reverse Path Forwarding
SA - Source Address
SNMP - Simple Network Management Protocol
SPF - Shortest Path First
TLV - Type, Length, Value
TRILL - TRansparent Interconnection of Lots of Links
VLAN - Virtual Local Area Network
VRP - VLAN Registration Protocol2. RBridges
this section gives a high-level overview of RBridges, which implement the TRILL protocol 🌈 it skips some details, so Sections 3 and 4 below have the more detailed specs 💜
TRILL, as described here and with the exceptions covered in this document, provides [802.1Q-2005] VLAN-aware customer bridging service 🎀 as described below, TRILL is layered above the ports of an RBridge ✨
the RBridges specified by this document do NOT supply provider [802.1ad] or provider backbone [802.1ah] bridging or anything like it 🙅♀️ extending TRILL to offer those provider services is left for future work that will be separately documented 🦋 however, provider or provider backbone bridges may be used to interconnect parts of an RBridge campus 💅
2.1. General Overview ✨
okay so RBridges run a link state protocol amongst themselves 🧚 that gives them enough info to compute pair-wise optimal paths for unicast, and to calculate distribution trees for delivering frames to destinations whose location is unknown or to multicast/broadcast groups [RBridges] [RP1999]. it's giving main character energy, ngl 💅
to mitigate temporary loop issues, RBridges forward based on a header with a hop count 🔁 they also name the next hop RBridge as the frame destination when forwarding unicast frames across a shared-media link. this avoids spawning extra copies of frames during a temporary loop, which is so smart 🫶 a Reverse Path Forwarding Check and other checks run on multi-destination frames too, to keep potentially looping traffic in line (see Section 4.5.2) 🌀
the first RBridge a unicast frame meets in a campus, RB1, wraps the received frame in a TRILL header that names the last RBridge, RB2, where the frame gets unwrapped. RB1 is the "ingress RBridge" and RB2 is the "egress RBridge" 🦋 to save room in the TRILL header and keep forwarding lookups simple, a dynamic nickname acquisition protocol runs among the RBridges to pick 2-octet nicknames 🌸 these nicknames are unique within the campus and are an abbreviation for the IS-IS ID of the RBridge. the 2-octet nicknames are what specify the ingress and egress RBridges in the TRILL header ✨
multipathing of multi-destination frames through alternative distribution trees, and ECMP (Equal Cost Multipath) for unicast frames, are supported (see Appendix C) 🎀
networks with a more mesh-like structure get more out of the multipathing and optimal paths TRILL provides than more tree-like networks do 🕸️💖
RBridges run a protocol on a link to elect a "Designated RBridge" (DRB) 👑 the TRILL-IS-IS election on a link is a little different from the Layer 3 IS-IS [ISO10589] election, because in TRILL it is essential that only one RBridge gets elected DRB. in Layer 3 IS-IS, it's possible for multiple routers to be elected Designated Router (also known as Designated Intermediate System) 😭 like an IS-IS router, the DRB may give a pseudonode name to the link, issue an LSP (Link State PDU) on behalf of the pseudonode, and issues CSNPs (Complete Sequence Number PDUs) on the link. the DRB also has some TRILL-specific duties, including specifying which VLAN will be the Designated VLAN used for communication between RBridges on that link (see Section 4.2.4.2) 🌈
the DRB either encapsulates/decapsulates all data traffic to/from the link, or, for load splitting, hands this job off, for one or more VLANs, to other RBridges on the link ⭐ there must at all times be at most one RBridge on the link that encapsulates/decapsulates traffic for a particular VLAN. we'll call the RBridge appointed to forward VLAN-x traffic on behalf of the link the "appointed VLAN-x forwarder" (see Section 4.2.4.3) 🫧 (Section 2.5 talks more about VLANs.)
Rbridges SHOULD support SNMPv3 [RFC3411] 📋 the Rbridge MIB will be specified in a separate document. if IP service is available to an RBridge, it SHOULD support SNMPv3 over UDP over IPv4 [RFC3417] and IPv6 [RFC3419] 🌐 however, management can still happen within a campus even for an RBridge that lacks an IP or other Layer 3 transport stack, or that doesn't have a Layer 3 address, by carrying SNMP over Ethernet [RFC4789] 💜
2.2. End-Station Addresses 📍
an RBridge, RB1, that is the VLAN-x forwarder on any of its links MUST learn the location of VLAN-x end nodes. this applies both on the links it forwards for and on other links in the campus 🗺️ RB1 learns the port, VLAN, and Layer 2 (MAC) addresses of end nodes on links it forwards for from the source address of received frames, just like bridges do (for example, see Section 8.7 of [802.1Q-2005]). it can also learn them through configuration, or through a Layer 2 explicit registration protocol such as IEEE 802.11 association and authentication 🔐 RB1 learns the VLAN and Layer 2 address of distant VLAN-x end nodes, plus the RBridge they're attached to, by looking at the ingress RBridge nickname in the TRILL header and the VLAN and source MAC address of the inner frame of TRILL Data frames it decapsulates 🦋
additionally, an RBridge that is the appointed VLAN-x forwarder on one or more links MAY use the End-Station Address Distribution Information (ESADI) protocol to announce some or all of the attached VLAN-x end nodes on those links 📣
the ESADI protocol could be used to announce end nodes that have been explicitly enrolled 🎟️ that info might be more authoritative than what's learned from data frames being decapsulated onto the link. the addresses enrolled and distributed this way can also be more secure, for two reasons: (1) the enrollment might be authenticated (for example, by cryptographically based EAP methods via [802.1X]), and (2) the ESADI protocol also supports cryptographic authentication of its messages [RFC5304] [RFC5310] for more secure transmission 🔒✨
if an end station gets unplugged from one RBridge and plugged into another, then, depending on circumstances, frames addressed to that end station can be black-holed 🕳️😱 that means they can get sent just to the older RBridge the end station used to connect to, until cached address info at some remote RBridge(s) times out, which can take a number of minutes or longer. with the ESADI protocol, the link interruption from the unplugging can trigger an immediate update instead 💨
even if the ESADI protocol is used to announce or learn attached end nodes, RBridges MUST still learn from received native frames and decapsulated TRILL Data frames, unless they're configured not to 🙅♀️ advertising end nodes using ESADI is optional, and so is learning from those announcements 💅
(See Section 4.8 for further end-station address details.)
2.3. RBridge Encapsulation Architecture 🎀
the Layer 2 technology used to connect Rbridges may be either IEEE [802.3] or some other link technology, such as PPP [RFC1661] 🔌 that's possible because the RBridge relay function is layered on top of the Layer 2 technologies. however, this document only specifies an IEEE 802.3 encapsulation 📜
Figure 1 shows two RBridges, RB1 and RB2, interconnected through an Ethernet cloud ☁️ the Ethernet cloud may include hubs, point-to-point or shared media, IEEE 802.1D bridges, or 802.1Q bridges.
------------
/ \
+-----+ / Ethernet \ +-----+
| RB1 |----< >---| RB2 |
+-----+ \ Cloud / +-----+
\ /
------------
Figure 1: Interconnected RBridgesFigure 2 shows the format of a TRILL data or ESADI frame traveling through the Ethernet cloud between RB1 and RB2 🧚
+--------------------------------+
| Outer Ethernet Header |
+--------------------------------+
| TRILL Header |
+--------------------------------+
| Inner Ethernet Header |
+--------------------------------+
| Ethernet Payload |
+--------------------------------+
| Ethernet FCS |
+--------------------------------+
Figure 2: An Ethernet Encapsulated TRILL Framewith media that isn't Ethernet, the header specific to that media replaces the outer Ethernet header 🔄 for example, Figure 3 shows a TRILL encapsulation over PPP.
+--------------------------------+
| PPP Header |
+--------------------------------+
| TRILL Header |
+--------------------------------+
| Inner Ethernet Header |
+--------------------------------+
| Ethernet Payload |
+--------------------------------+
| PPP FCS |
+--------------------------------+
Figure 3: A PPP Encapsulated TRILL Framethe outer header is link-specific. even though this document only specifies [802.3] links, other links are allowed 🌈
in both cases, the inner Ethernet header and the Ethernet Payload come from the original frame and get wrapped in a TRILL header as they travel between RBridges 🎁 using a TRILL header gives you these perks:
- loop mitigation through use of a hop count field;
- elimination of the need for end-station VLAN and MAC address learning in transit RBridges;
- direction of unicast frames towards the egress RBridge (this lets the unicast forwarding tables of transit RBridges be sized with the number of RBridges rather than the total number of end nodes); and
- provision of a separate VLAN tag for forwarding traffic between RBridges, independent of the VLAN of the native frame.
when forwarding unicast frames between RBridges, the outer header has the MAC destination address of the next hop Rbridge 🎯 this avoids frame duplication if the inter-RBridge link is multi-access. it also enables multipathing of unicast, since the transmitting RBridge can specify the next hop 🛣️ the outer header specifies the transmitting RBridge as the source address, which makes sure any bridges inside the Ethernet cloud won't get confused. they might, if multipathing is in use and they saw the original source or ingress RBridge in the outer header 🫶
2.4. Forwarding Overview 🦋
RBridges are true routers in the sense that, when a transit RBridge forwards a frame, the outer Layer 2 header gets replaced at each hop with an appropriate Layer 2 header for the next hop, and the hop count decreases ⬇️ despite these changes to the outer Layer 2 header and the hop count in the TRILL header, the original encapsulated frame is preserved, including the original frame's VLAN tag 💜 see Section 4.6 for more details.
from a forwarding standpoint, transit frames fall into two categories: known-unicast and multi-destination. Layer 2 control frames, TRILL control frames, and TRILL other frames are not transit frames, aren't forwarded by RBridges, and aren't included in these categories 🙅♀️
2.4.1. Known-Unicast 🎯
these frames have a unicast inner MAC destination address (Inner.MacDA), and they're the ones where the ingress RBridge knows the egress RBridge for the destination MAC address in the frame's VLAN 🧠
such frames get forwarded Rbridge hop by Rbridge hop to their egress Rbridge 🚀
2.4.2. Multi-Destination 📦
Okay so these are the frames that have to be delivered to multiple destinations 🫶 Multi-destination frames include:
- unicast frames where the ingress RBridge doesn't know where the destination lives:
Inner.MacDAis unicast, but the ingress RBridge does not know its location in the frame's VLAN 🙈 - multicast frames where the Layer 2 destination address is derived from an IP multicast address:
Inner.MacDAis multicast, from the set of Layer 2 multicast addresses derived from IPv4 [RFC1112] or IPv6 [RFC2464] multicast addresses. These frames get handled a bit differently in different subcases: - multicast frames where the Layer 2 destination address is not derived from an IP multicast address:
Inner.MacDAis multicast, and not from the set of Layer 2 multicast addresses derived from IPv4 or IPv6 multicast addresses. 💜 - broadcast frames:
Inner.MacDAis broadcast (FF-FF-FF-FF-FF-FF). 📢
RBridges build distribution trees (see Section 4.5) and use them to forward multi-destination frames, and this is where the magic happens ✨ Each distribution tree reaches all RBridges in the campus, is shared across all VLANs, and may be used to distribute a native frame that is in any VLAN. Still, the distribution of any particular frame on a distribution tree gets pruned in different ways for different cases, so the frame doesn't go places it doesn't need to go. Efficiency bestie 💅
2.5. RBridges and VLANs 🎀
A VLAN is a way to split up end nodes in a campus into different Layer 2 communities [802.1Q-2005]. Using VLANs takes configuration, no free lunch here 😭 By default, the port a frame arrives on decides which VLAN an end station's frame belongs to. End stations can also put this info right into the frame themselves.
IEEE [802.1Q-2005] bridges can be configured to support multiple customer VLANs over a single simple link by inserting and removing a VLAN tag in the frame. VLAN tags used by TRILL have the same format as the VLAN tags defined in IEEE [802.1Q-2005] (same vibes, different party 🦋). As shown in Figure 2, a TRILL-encapsulated frame sent over an IEEE [802.3] link can have a tag in two places: one in the outer header (Outer.VLAN) and one in the inner header (Inner.VLAN). Inner and outer VLANs get more attention in Section 4.1.
RBridges enforce delivery of a native frame that originates in a particular VLAN only to other links in that same VLAN. Still, the handling of VLANs is a little different between an RBridge campus and an 802.1 bridged LAN, as described below 👀
(See Section 4.2.4 for further discussion of TRILL IS-IS operation on a link.)
2.5.1. Link VLAN Assumptions 🧚
Certain bridge configurations can cause partitions of a VLAN on a link. With those configs, a frame one RBridge sends to a neighbor on that link might not arrive, if it's tagged with a VLAN that's been partitioned by the bridge configuration. Yikes 💀
TRILL requires at least one VLAN per link that gives full connectivity to all the RBridges on that link. The default VLAN is 1, though RBridges may be configured to use a different VLAN. The DRB dictates to the other RBridges which VLAN to use. 👑
Since there will be only one appointed forwarder for any VLAN, say VLAN-x, on a link, if bridges are configured to make VLAN-x partitioned on a link, some VLAN-x end nodes on that link may get orphaned (unable to talk to the rest of the campus). Main character tragedy 😭
It's also possible for bridge and port configuration to cause VLAN mapping on a link (where a VLAN-x frame turns into a VLAN-y frame). TRILL detects this by inserting a copy of the outer VLAN into TRILL-Hello messages and checking it on receipt. If it detects this, it takes steps to make sure there's at most a single appointed forwarder on the link, so frames don't get duplicated or loop (see Section 4.4.5). Iconic protection 🛡️
TRILL behaves as conservatively as possible, so it avoids loops rather than avoiding partial connectivity. As a result, a lack of connectivity may come from bridge or port misconfiguration. Not the protocol's fault, periodt 💅
2.6. RBridges and IEEE 802.1 Bridges 🌸
RBridge ports are layered on top of IEEE [802.1Q-2005] port facilities, except as described below.
2.6.1. RBridge Ports and 802.1 Layering 🍓
RBridge ports make use of [802.1Q-2005] port VLAN and priority processing. On top of that, they MAY implement other lower-level 802.1 protocols, as well as protocols for the link in use, such as PAUSE (Annex 31B of [802.3]), port-based access control [802.1X], MAC security [802.1AE], or link aggregation [802.1AX]. Options, options, options 🫶
However, RBridges do not use spanning tree and do not block ports the way spanning tree does. Figure 4 shows a high-level diagram of an RBridge with one port connected to an IEEE 802.3 link. Single lines show the flow of control information, and double lines show the flow of both frames and control information.
+-----------------------------------------
| RBridge
|
| Forwarding Engine, IS-IS, etc.
| Processing of native and TRILL frames
|
+----+---+--------++----------------------
| | || other ports...
+-------------+ | ||
| | ||
+------------+-------------+ | ||
| RBridge | | +----++-------+ <- EISS
| | | | |
| High-Level Control Frame | | | 802.1Q-2005 |
| Processing (BPDU, VRP) | | | Port VLAN |
| | | | & Priority |
+-----------++-------------+ | | Processing |
|| | | |
+---------++-----------------+---+-------------+ <-- ISS
| |
| 802.1/802.3 Low-Level Control Frame |
| Processing, Port/Link Control Logic |
| |
+-----------++---------------------------------+
||
|| +------------+
|| | 802.3 PHY |
|+--------+ (Physical +--------- 802.3
+---------+ Interface) +--------- Link
| |
+------------+
Figure 4: RBridge Port ModelThe upper interface to the low-level port and link control logic corresponds to the Internal Sublayer Service (ISS) in [802.1Q-2005]. In RBridges, high-level control frames are processed above the ISS interface. 🧠
The upper interface to the port VLAN and priority processing corresponds to the Extended Internal Sublayer Service (EISS) in [802.1Q-2005]. In RBridges, native and TRILL frames are processed above the EISS interface and are subject to port VLAN and priority processing. ✨
2.6.2. Incremental Deployment 🌈
Because RBridges are compatible with IEEE [802.1Q-2005] customer bridges, except as discussed in this document, you can upgrade a bridged LAN by swapping those bridges out for RBridges, one at a time 🔥 Bridges that haven't been replaced yet are transparent to RBridge traffic. The physical links directly interconnected by such bridges, together with the bridges themselves, make up bridged LANs. To RBridges, these bridged LANs look like multi-access links.
If the bridges being replaced were default configuration bridges, their RBridge replacements won't need any configuration. Easy mode 🎀
RBridges, as described in this document, only provide customer services. That means they can't replace provider bridges or provider backbone bridges, just like a customer bridge can't replace a provider bridge 🙅♀️ However, provider devices can still be part of the bridged LAN between RBridges. Extending TRILL to support provider services is left for future work and will be documented separately.
Of course, if the bridges being replaced had any port-level protocols enabled, such as port-based access control [802.1X] or MAC security [802.1AE], the replacement RBridges would need the same port-level protocols enabled and configured similarly. Also, the replacement RBridges would have to support the same link type and link-level protocols as the bridges they replace. Don't skip the details, bestie 🫶
An RBridge campus will work best if all IEEE [802.1D] and [802.1Q-2005] bridges are replaced with RBridges, assuming the RBridges have the same speed and capacity as the bridges. There may be intermediate states, though, where only some bridges have been replaced by RBridges, and performance is inferior during that time 😬
See Appendix A for further discussion of incremental deployment.
3. Details of the TRILL Header 💖
This section specifies the TRILL header. Section 4 below provides other RBridge design details. 🧚
3.1. TRILL Header Format 🦋
The TRILL header is shown in Figure 5 and is independent of the data link layer used. When that layer is IEEE [802.3], the header gets prefixed with the 16-bit TRILL Ethertype [RFC5342], which makes it 64-bit aligned. If Op-Length is a multiple of 64 bits, then 64-bit alignment is normally maintained for the content of an encapsulated frame. Alignment is everything 🙈
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | R |M|Op-Length| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress RBridge Nickname | Ingress RBridge Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 5: TRILL HeaderThe header contains the following fields, which are described in the sections referenced:
V (Version): 2-bit unsigned integer. See Section 3.2.R (Reserved): 2 bits. See Section 3.3.M (Multi-destination): 1 bit. See Section 3.4.Op-Length (Options Length): 5-bit unsigned integer. See Section 3.5.Hop Count: 6-bit unsigned integer. See Section 3.6.Egress RBridge Nickname: 16-bit identifier. See Section 3.7.1.Ingress RBridge Nickname: 16-bit identifier. See Section 3.7.2.Options: present if Op-Length is non-zero. See Section 3.8.
3.2. Version (V) 🔢
Version (V) is a 2-bit field. Version zero of TRILL is specified in this document. An RBridge RB1 MUST check the V field in a received TRILL-encapsulated frame. If the V field has a value that RB1 doesn't recognize, then RB1 MUST silently discard the frame. Allocating new TRILL Version numbers requires an IETF Standards Action. Rules are rules, bestie 📜
3.3. Reserved (R) 🌙
The two R bits are reserved for future use in extensions to this version zero of the TRILL protocol. They MUST be set to zero when the TRILL header is added by an ingress RBridge, transparently copied but otherwise ignored by transit RBridges, and ignored by egress RBridges. Allocating reserved TRILL header bits requires an IETF Standards Action. 🫶
3.4. Multi-destination (M) 🦋
okay so the Multi-destination bit (see Section 2.4.2) tells you the frame is headed to a whole class of destination end stations, delivered through a distribution tree, and the egress RBridge nickname field is the thing that names that tree 🌳 here's how it works:
M = 0 (FALSE)- the egress RBridge nickname holds the nickname of the egress Rbridge for a known unicast MAC address 💌M = 1 (TRUE)- the egress RBridge nickname field holds a nickname that specifies a distribution tree 🌈 the ingress RBridge picks this for a TRILL Data frame, or the source RBridge picks it for a TRILL ESADI frame ✨
3.5. Op-Length ✨
there are provisions for saying, right in the TRILL header, that a frame is using an optional capability, and for tucking info into the header that goes with that capability 🎀
The Op-Length header field gives the length of the TRILL header options in units of 4 octets, which allows up to 124 octets of options area 💅 If Op-Length is zero, there are no options present. If options are present, they follow immediately after the Ingress Rbridge Nickname field 🫶
See Section 3.8 for more information on TRILL header options.
3.6. Hop Count 🌈
The Hop Count field is a 6-bit unsigned integer. An Rbridge drops frames received with a hop count of zero, otherwise it decrements the hop count. (This is different from IPv4 and IPv6 on purpose, so a traceroute-like facility can be added later and get a hop count exceeded from an egress RBridge 🧚)
For known unicast frames, the ingress RBridge SHOULD set the Hop Count in excess of the number of RBridge hops it expects to the egress RBridge, so there's room for alternate routing later in the path 🛣️
For multi-destination frames, the Hop Count SHOULD be set by the ingress RBridge (or the source RBridge for a TRILL ESADI frame) to at least the expected number of hops to the most distant RBridge. To pull this off, RBridge RBn calculates, for each branch from RBn of the specified distribution tree rooted at RBi, the maximum number of hops in that branch 📐
Multi-destination frames are of particular danger 💀 because a loop involving one or more distribution tree forks could result in the rapid generation of multiple copies of the frame, even with the normal hop count mechanism. That's why multi-destination frames get a stringent Reverse Path Forwarding Check and other checks, as described in Section 4.5.2. As an optional extra traffic control measure, when forwarding a multi-destination frame onto a distribution tree branch, transit RBridge RBm MAY decrease the hop count by more than 1, unless decreasing it by more than 1 would leave a hop count too low to reach all destinations in that branch of the tree rooted at RBi. Keeping the hop count close to or equal to the minimum needed on multi-destination frames gives extra protection against problems with temporary loops when forwarding 🔥
Although the RBridge MAY decrease the hop count of multi-destination frames by more than 1, under the circumstances described above, the RBridge forwarding a frame MUST decrease the hop count by at least 1, and discards the frame if it cannot do so because the hop count is 0. The option to decrease by more than 1 under those circumstances applies only to multi-destination frames, not to known unicast frames. 🙈
3.7. RBridge Nicknames 💜
Nicknames are 16-bit dynamically assigned quantities that act as abbreviations for RBridges' IS-IS IDs, so the encoding stays compact 🦋 They can also be used to specify potentially different trees with the same root. This lets you address up to 2**16 RBridges, but the value 0x0000 is reserved to indicate that a nickname is not specified, the values 0xFFC0 through 0xFFFE are reserved for future specification, and the value 0xFFFF is permanently reserved. RBridges piggyback a nickname acquisition protocol on the link state protocol (see Section 3.7.3) to acquire one or more nicknames unique within the campus 🌸
3.7.1. Egress RBridge Nickname
There are two cases for the contents of the egress RBridge nickname field, depending on the M bit (see Section 3.4). The nickname is filled in by the ingress RBridge for TRILL Data frames and by the source RBridge for TRILL ESADI frames 💅
- For known unicast TRILL Data frames,
M == 0and the egress RBridge nickname field specifies the egress RBridge. That is, it names the RBridge that needs to remove the TRILL encapsulation and forward the native frame. Once the egress nickname field is set, it MUST NOT be changed by any subsequent transit RBridge 🔒 - For multi-destination TRILL Data frames and for TRILL ESADI frames,
M == 1. The egress RBridge nickname field contains a nickname specifying the distribution tree selected to forward the frame. This root nickname MUST NOT be changed by transit RBridges 🌳
3.7.2. Ingress RBridge Nickname
The ingress RBridge nickname is set to a nickname of the ingress RBridge for TRILL Data frames, and to a nickname of the source RBridge for TRILL ESADI frames. If the RBridge setting the ingress nickname has multiple nicknames, it SHOULD use the same nickname in the ingress field whenever it encapsulates a frame with any particular Inner.MacSA and Inner.VLAN value. This simplifies end node learning 🧠
Once the ingress nickname field is set, it MUST NOT be changed by any subsequent transit RBridge 🫶
3.7.3. RBridge Nickname Selection
The nickname selection protocol is piggybacked on TRILL IS-IS as follows 🎀
- The nickname or nicknames being used by an RBridge are carried in an IS-IS TLV (type-length-value data element) along with a priority of use value [RFC6326]. Each RBridge chooses its own nickname or nicknames 👑
- Nickname values MAY be configured. An RBridge that has been configured with one or more nickname values will have priority for those nickname values over all Rbridges with non-configured nicknames ⭐
- The nickname value
0x0000and the values from0xFFC0through0xFFFFare reserved and MUST NOT be selected by or configured for an RBridge. The value0x0000is used to indicate that a nickname is not known 🙅♀️ - The priority of use field reported with a nickname is an unsigned 8-bit value, where the most significant bit (
0x80) indicates that the nickname value was configured. The bottom 7 bits have the default value0x40, but MAY be configured to be some other value. Additionally, an RBridge MAY increase its priority after holding a nickname for some amount of time. However, the most significant bit of the priority MUST NOT be set unless the nickname value was configured 💖 - Once an RBridge has successfully acquired a nickname, it SHOULD attempt to reuse it in the case of a reboot 🔁
- Each RBridge is responsible for ensuring that its nickname or each of its nicknames is unique. If RB1 chooses nickname x, and RB1 discovers, through receipt of an LSP for RB2 at any later time, that RB2 has also chosen x, then the RBridge or pseudonode with the numerically higher IS-IS ID (LAN ID) keeps the nickname, or if there is a tie in priority, the RBridge with the numerically higher IS-IS System ID keeps the nickname, and the other RBridge MUST select a new nickname. This can require an RBridge with a configured nickname to select a replacement nickname 😭
- To minimize the probability of nickname collisions, an RBridge selects a nickname randomly from the apparently available nicknames, based on its copy of the link state. This random selection can be by the RBridge hashing some of its parameters, e.g., SystemID, time and date, and other entropy sources, such as those given in [RFC4086], each time, or by the RBridge using such hashing to create a seed and making any selections based on pseudo-random numbers generated from that seed [RFC4086]. The random numbers or seed and the algorithm used SHOULD make uniformly distributed selections over the available nicknames. Convergence to a nickname-collision-free campus is accelerated by selecting new nicknames only from those that appear to be available, and by having the highest priority nickname involved in a nickname conflict retain its value. There is no reason for all Rbridges to use the same algorithm for selecting nicknames 🎲
- If two RBridge campuses merge, then transient nickname collisions are possible. As soon as each RBridge receives the LSPs from the other RBridges, the RBridges that need to change nicknames select new nicknames that do not, to the best of their knowledge, collide with any existing nicknames. Some RBridges may need to change nicknames more than once before the situation is resolved 🌀
- To minimize the probability of a new RBridge usurping a nickname already in use, an RBridge SHOULD wait to acquire the link state database from a neighbor before it announces any nicknames that were not configured 🙈
- An RBridge by default has only a single nickname but MAY be configured to request multiple nicknames. Each such nickname would specify a shortest path tree with the RBridge as root but, since the tree number is used in tiebreaking when there are multiple equal cost paths (see Section 4.5.1), the trees for the different nicknames will likely utilize different links. Because of the potential tree computation load it imposes, this capability to request multiple nicknames for an RBridge should be used sparingly. For example, it should be used at a few RBridges that, because of campus topology, are particularly good places from which to calculate multiple different shortest path distribution trees. Such trees need separate nicknames so traffic can be multipathed across them 🛤️
- If it is desired for a pseudonode to be a tree root, the DRB MAY request one or more nicknames in the pseudonode LSP 🧚
Every nickname in use in a campus identifies an RBridge (or pseudonode), and every nickname designates a distribution tree rooted at the RBridge (or pseudonode) it identifies. However, only a limited number of these potential distribution trees are actually computed by all the RBridges in a campus, as discussed in Section 4.5 ✨
3.8. TRILL Header Options ✨
Okay so every RBridge MUST be able to skip over the number of 4-octet chunks that the Op-Length field tells it about (see Section 3.5) 🫶 Why? Because RBridges need to find the destination MAC address and VLAN tag inside the inner frame. Transit RBridges need that info to filter VLANs, IP multicast, and stuff like that. Egress RBridges need to find the inner header so they can decapsulate and handle the inner frame correctly 💅
Now, to keep things backward-compatible and safe, when Op-Length is non-zero (meaning options are actually there), the top two bits of the first octet of the options area are set up like this 👑
+------+------+----+----+----+----+----+----+
| CHbH | CItE | Reserved |
+------+------+----+----+----+----+----+----+
Figure 6: Options Area Initial Flags OctetIf the CHbH (Critical Hop-by-Hop) bit is one, that means one or more critical hop-by-hop options are present 🚨 Any transit RBridge that doesn't support all of those critical hop-by-hop options MUST drop the frame. Think of an RBridge that supports zero options, it's getting dropped no matter what 💀 If the CHbH bit is zero, then the frame is totally safe for a transit RBridge to forward from an options-processing point of view, no matter which options that RBridge does or doesn't support 🦋 And a transit RBridge that doesn't support any of the options present MUST transparently forward the options area whenever it forwards a frame. No messing with it!
Next up, the CItE (Critical Ingress-to-Egress) bit. If it's one, one or more critical ingress-to-egress options are present. If it's zero, there are none of those 🌸 Now, if either CHbH or CItE is non-zero, egress RBridges that don't support all the critical options present, like an RBridge that supports no options at all, MUST drop the frame. But if both CHbH and CItE are zero, the frame is safe for any egress RBridge to process from an options point of view, no matter what that RBridge does or doesn't support ✨
Options, including what the bits labeled Reserved in Figure 6 are for, will be specified further in other documents. They're expected to cover hop-by-hop and ingress-to-egress options, plus both critical and non-critical options 🧚
Note: Most RBridge implementations are expected to be optimized for the simplest and most common cases of frame forwarding and processing. The inclusion of options may, and the inclusion of complex or lengthy options likely will, cause frame processing using a "slow path" with inferior performance to "fast path" processing. Limited slow path throughput may cause such frames to be discarded. 🙈
4. Other RBridge Design Details 🌈
Section 3 above specifies the TRILL header. This section is where we get into the other RBridge design details 💜
4.1. Ethernet Data Encapsulation 🎀
TRILL data and ESADI frames sent over Ethernet links get wrapped in an outer Ethernet header (see Figure 7). This outer header looks, to a bridge sitting on the path between two RBridges, just like the header of a regular Ethernet frame. So bridges forward it the way they normally would! 🫠 To let RBridges tell these TRILL Data frames apart, a new TRILL Ethertype (see Section 7.2) gets used in the outer header ✨
Figure 7 shows a TRILL Data frame with an outer VLAN tag traveling over an Ethernet link, the part at the top of the figure, between transit RBridges RB3 and RB4. The native frame started at end station ESa, got encapsulated by ingress RBridge RB1, and will eventually be decapsulated by egress RBridge RB2 and delivered to destination end station ESb 🦋 The encapsulation has a nice perk: if TRILL options are absent, or if their length is a multiple of 64 bits, the original Ethernet frame ends up lined up on a 64-bit boundary. Very aligned, very iconic 👑
When a TRILL Data frame is carried over an Ethernet cloud, it has three pairs of addresses:
- Outer Ethernet Header: Outer Destination MAC Address (
Outer.MacDA) and Outer Source MAC Address (Outer.MacSA). These are used to specify the next hop RBridge and the transmitting RBridge, respectively. 🚚 - TRILL Header: Egress Nickname and Ingress Nickname. These specify the nicknames of the egress and ingress RBridges, respectively, unless the frame is multi-destination. In that case, the Egress Nickname specifies the distribution tree the frame is being sent on. 🌳
- Inner Ethernet Header: Inner Destination MAC Address (
Inner.MacDA) and Inner Source MAC Address (Inner.MacSA). These are exactly as the original end station transmitted them, showing the destination and source of the inner frame, respectively. 💌
A TRILL Data frame can also have up to two VLAN tags, which I'll get into in Sections 4.1.2 and 4.1.3 below. Those can carry two different VLAN Identifiers and specify priority 🎀
Here's the flow, bestie 👇
Flow:
+-----+ +-------+ +-------+ +-------+ +-------+ +----+
| ESa +--+ RB1 +---+ RB3 +-------+ RB4 +---+ RB2 +--+ESb |
+-----+ |ingress| |transit| ^ |transit| |egress | +----+
+-------+ +-------+ | +-------+ +-------+
|
Outer Ethernet Header: |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address (RB4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address | Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Source MAC Address (RB3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ethertype = C-Tag [802.1Q-2005]| Outer.VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TRILL Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = TRILL | V | R |M|Op-Length| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress (RB2) Nickname | Ingress (RB1) Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inner Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Destination MAC Address (ESb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Destination MAC Address | Inner Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Source MAC Address (ESa) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ethertype = C-Tag [802.1Q-2005]| Inner.VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Payload:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype of Original Payload | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Original Ethernet Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frame Check Sequence:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New FCS (Frame Check Sequence) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: TRILL Data Encapsulation over Ethernet4.1.1. VLAN Tag Information 🏷️
A "VLAN Tag" (formerly known as a Q-tag), also called a "C-tag" for customer tag, has a VLAN ID and a priority field, as shown in Figure 8 💖 The "VLAN ID" can be zero, which means no VLAN is specified, just a priority. Those frames are called "priority tagged" instead of "VLAN tagged" [802.1Q-2005] 🌸
Use of [802.1ad] S-tags, also known as service tags, and use of stacked tags, are beyond the scope of this document. Not today, stacked tags 🙅♀️
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Priority | C | VLAN ID |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 8: VLAN Tag InformationAs recommended in [802.1Q-2005], RBridges SHOULD be implemented so they can use the full range of VLAN IDs, from 0x001 through 0xFFE 🌈 RBridges MAY support a smaller number of simultaneously active VLAN IDs. VLAN ID zero is the null VLAN identifier and indicates that no VLAN is specified. VLAN ID 0xFFF is reserved 💅
Okay, this part is serious: the VLAN ID 0xFFF MUST NOT be used. RBridges MUST discard any frame they receive with an Outer.VLAN ID of 0xFFF. RBridges MUST also discard any frame where they examine the Inner.VLAN ID and find it to be 0xFFF. That examination is required at all egress RBridges that decapsulate a frame 🚫
The "C" bit shown in Figure 8 is not used in the Inner.VLAN in TRILL. It MUST be set to zero there by ingress RBridges, transparently forwarded by transit RBridges, and ignored by egress RBridges.
Now about priority. As specified in [802.1Q-2005], the priority field holds an unsigned value from 0 through 7. Here 1 is the lowest priority and 7 is the highest. The default priority zero is considered higher than priority 1 but lower than priority 2 🧁 The [802.1ad] amendment to [802.1Q-2005] lets some adjacent pairs of priority levels get mapped into a single priority level, with and without drop eligibility. Ongoing work in IEEE 802.1 (802.1az, Appendix E) suggests being able to configure "priority groups" that have a certain guaranteed bandwidth 🦋 RBridges ports MAY also implement such options. RBridges are not required to implement any particular number of distinct priority levels, but they may treat one or more adjacent priority levels the same way ✨
Last but not least, ordering, which is a big deal 👑 Frames with the same source address, destination address, VLAN, and priority that are received on the same port as each other, and transmitted on the same port, MUST be transmitted in the order received. The exception is if the RBridge classifies the frames into more fine-grained flows, in which case this ordering requirement applies to each such flow. Frames in the same VLAN with the same priority that are received on the same port may be sent out different ports if multipathing is in effect (see Appendix C) 🛣️
The C-Tag Ethertype [RFC5342] is 0x8100 🎀
4.1.2. Inner VLAN Tag
Okay so the "Inner VLAN Tag Information" (Inner.VLAN) field holds the VLAN tag info from the native frame when it was ingressed 🚪, or the VLAN tag info for a TRILL ESADI frame when that frame got created ✨. When a TRILL frame passes through a transit RBridge, the Inner.VLAN MUST NOT be changed, except when VLAN mapping is being intentionally performed within that RBridge 🙅♀️. Not even a little bit, bestie!
When a native frame shows up at an RBridge, its VLAN ID and priority get figured out as specified in [802.1Q-2005] (see Appendix D and [802.1Q-2005], Section 6.7) 🧠. If the RBridge is an appointed forwarder for that VLAN and the frame needs to go out to one or more other links, this ingress RBridge builds a TRILL Data frame with the associated VLAN ID and priority placed in the Inner.VLAN information 🎀.
The VLAN ID is required at the ingress Rbridge as one element in figuring out the right egress Rbridge for a known unicast frame 🎯. It's also needed at the ingress and every transit Rbridge for multi-destination frames, so they can prune the distribution tree correctly 🌳. Main character energy for that VLAN ID, honestly 👑.
4.1.3. Outer VLAN Tag
TRILL frames sent by an RBridge use an Outer.VLAN ID chosen by the Designated RBridge (DRB) for the link they're going out on 🦋. That's called the Designated VLAN. The one exception is some TRILL-Hello frames 🙈. For TRILL data and ESADI frames, the priority in the Outer.VLAN tag SHOULD be set to the priority in the Inner.VLAN tag 💜.
A transit RBridge forwarding a TRILL frame uses the priority that was in the Inner.VLAN of the frame as received 🌸. TRILL Data frames get sent with the priority that belonged to the matching native frame when it was received (see Appendix D) ✨. And TRILL IS-IS frames SHOULD be sent with priority 7 🔥.
Whether an Outer.VLAN tag actually shows up on the wire depends on how the RBridge port it's sent through is configured 🔧. It's the same deal as a VLAN tag on a frame sent by an [802.1Q-2005] bridge, which depends on how that bridge port is configured (see Section 4.9.2) 💅.
4.1.4. Frame Check Sequence (FCS)
Every Ethernet frame has one Frame Check Sequence (FCS) that covers the entire frame 🧚. It's there to catch corruption from bit errors on a link 💀. So when a frame gets encapsulated, the original FCS isn't included, it's just discarded 🗑️. Any received frame where the FCS check fails SHOULD be discarded (this might not be possible with cut through forwarding) 🙃. The FCS normally changes on encapsulation, decapsulation, and every TRILL hop, because the outer destination and source addresses change, the hop count gets decremented, and so on 🔄.
Now, the FCS is normally calculated right before transmission, but it's desirable, when practical, for an FCS to come along with a frame inside an RBridge after receipt 🫶. That FCS could then be dynamically updated to account for changes made during RBridge processing, and then used for transmission or checked against the FCS calculated for frame transmission 💖. This optional, more continuous use of an FCS would help detect some internal RBridge failures, like memory errors 🧠⚡.
4.2. Link State Protocol (IS-IS)
TRILL uses an extension of IS-IS [ISO10589] [RFC1195] as its routing protocol 🗺️. IS-IS has the following advantages:
- It runs directly over Layer 2, so it can run without configuration (no IP addresses need to be assigned) ✨.
- It's easy to extend by defining new TLV (type-length-value) data elements and sub-elements for carrying TRILL information 🧩.
This section describes TRILL use of IS-IS, except for the TRILL-Hello protocol, which is described in Section 4.4, and the MTU-probe and MTU-ack messages that are described in Section 4.3 🎀.
4.2.1. IS-IS RBridge Identity
Each RBridge has a unique 48-bit (6-octet) IS-IS System ID 🆔. This ID may be derived from any of the RBridge's unique MAC addresses 💜.
A pseudonode gets a 7-octet ID from the DRB that created it 🦋. The DRB takes a 6-octet ID that it owns and appends another octet 🧁. The 6-octet ID used to form a pseudonode ID SHOULD be the DRB's ID, unless the DRB has to create IDs for pseudonodes for more than 255 links 🔢. The only constraint for correct operation is that the 7-octet ID be unique within the campus, and that the 7th octet be nonzero 🌈. An RBridge has a 7-octet ID made of its 6-octet system ID concatenated with a zero octet 🌸.
In this document, we use the term "IS-IS ID" to refer to the 7-octet quantity that can be either the ID of an RBridge or a pseudonode 🫶.
4.2.2. IS-IS Instances
TRILL runs a separate IS-IS instance from any used by Layer 3, which means it's different from the one used by routers 🚫. Layer 3 IS-IS frames must be distinguished from TRILL IS-IS frames, even when those Layer 3 IS-IS frames are transiting an RBridge campus 👀.
Layer 3 IS-IS native frames have special multicast destination addresses set aside for that purpose, like AllL1ISs or AllL2ISs 📣. When they're TRILL encapsulated, those multicast addresses show up as the Inner.MacDA, and the Outer.MacDA will be the All-RBridges multicast address 🎭.
Within TRILL, there's an IS-IS instance across all Rbridges in the campus, as described in Section 4.2.3 🌐. This instance uses TRILL IS-IS frames, which are distinguished by having a different Ethertype "L2-IS-IS" 🏷️. For TRILL IS-IS frames that are multicast, there's a distinct multicast destination address called All-IS-IS-RBridges 📮. TRILL IS-IS frames do not have a TRILL header 🙅♀️.
ESADI is a separate protocol from the IS-IS instance that all the RBridges implement 💅. There's a separate ESADI instance for each VLAN, and ESADI frames are encapsulated just like TRILL Data frames 🎁. After the TRILL header, the ESADI frame has an inner Ethernet header with the Inner.MacDA of "All-ESADI-RBridges" and the "L2-IS-IS" Ethertype, followed by the ESADI frame itself 🧸.
4.2.3. TRILL IS-IS Frames
All Rbridges MUST participate in the TRILL IS-IS instance 🫡. That instance is a single Level 1 IS-IS area using the fixed area address zero 🗺️. TRILL IS-IS frames are never forwarded by an RBridge, they're locally processed on receipt 🛑. (That processing might make the RBridge send additional TRILL IS-IS frames 📤.)
A TRILL IS-IS frame on an 802.3 link is structured as shown below 🧩. All such frames are Ethertype encoded 🏷️. The RBridge port that such a frame goes out of will strip the outer VLAN tag if it's configured to do so ✂️.
Outer Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All-IS-IS-RBridges Multicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All-IS-IS-RBridges continued | Source RBridge MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source RBridge MAC Address continued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ethertype = C-Tag [802.1Q-2005]| Outer.VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2-IS-IS Ethertype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IS-IS Payload:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs |
Frame Check Sequence:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCS (Frame Check Sequence) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 9: TRILL IS-IS Frame Format 📸
The VLAN specified in the Outer.VLAN information will be the Designated VLAN for the link on which the frame is sent, except in the case of some TRILL Hellos 🦋.
4.2.4. TRILL Link Hellos, DRBs, and Appointed Forwarders
RBridges default to using TRILL Hellos, unless they're configured on a per-port basis to use P2P Hellos 👋. TRILL-Hello frames are specified in Section 4.4 📖.
RBridges are normally configured to use P2P Hellos only when there are exactly two of them on a link 👯. Still, it can happen that RBridges are misconfigured as to which type of hello to use 😬. That's safe, but it may cause a lack of RBridge-to-RBridge connectivity 🥲. An RBridge port configured to use P2P Hellos ignores TRILL Hellos, and an RBridge port configured to use TRILL Hellos ignores P2P Hellos 🙉.
If any of the RBridge ports on a link is configured to use TRILL Hellos, one of those ports is elected DRB (Designated RBridge) for the link 👑. The election is based on configured priority (the most significant field) and source MAC address, as communicated by TRILL-Hello frames 🗳️. The DRB, as described in Section 4.2.4.2, designates the VLAN to be used on the link for inter-RBridge communication by the non-P2P RBridge ports 📍. It also appoints itself or other RBridges on the link as appointed forwarder (see Section 4.2.4.3) for VLANs on the link 🎀.
4.2.4.1. P2P Hello Links
RBridge ports can be configured to use IS-IS P2P Hellos 🔗. This implies that the port is a point-to-point link to another RBridge 💞. An RBridge MUST NOT provide any end-station (native frame) service on a port configured to use P2P Hellos 🚫.
As with Layer 3 IS-IS, these P2P ports don't take part in a DRB election 🙅♀️. They send all frames VLAN tagged as being in the Desired Designated VLAN configured for the port, although that tag may be stripped if the port is set up that way 🏷️. Since all traffic through the port should be TRILL frames or Layer 2 control frames, such a port cannot be an appointed forwarder 🧃. RBridge P2P ports MUST use the IS-IS three-way handshake [RFC5303] so that extended circuit IDs get associated with the link for tie breaking purposes (see Section 4.5.2) 🤝.
Even if all simple links in a network are physically point-to-point, if some of the nodes are bridges, the bridged LANs that include those bridges look like multi-access links to the attached RBridges 🌀. This would make it necessary to use TRILL Hellos for proper operation in many cases 😭.
While it's safe to erroneously configure ports as P2P, it may result in a lack of connectivity 🥀.
4.2.4.2. Designated RBridge
TRILL IS-IS elects one RBridge for each LAN link to be the Designated RBridge (DRB), meaning it gets special duties 👑✨. The Designated RBridge:
- Chooses, for the link, and announces in its TRILL Hellos, the Designated VLAN ID to be used for inter-RBridge communication 📢. This VLAN is used for all TRILL-encapsulated data and ESADI frames and TRILL IS-IS frames, except some TRILL-Hello frames 🦋.
- If the link is represented in the IS-IS topology as a pseudonode, chooses a pseudonode ID and announces that in its TRILL Hellos, and issues an LSP on behalf of the pseudonode 🧩.
- Issues CSNPs 📨.
- For each VLAN-x appearing on the link, chooses an RBridge on the link to be the appointed VLAN-x forwarder (the DRB MAY choose itself to be the appointed VLAN-x forwarder for all or some of the VLANs) 🎀.
- Before appointing a VLAN-x forwarder (including appointing itself), waits at least its Holding Time (to make sure it is the DRB) ⏳.
- If configured to send TRILL-Hello frames, continues to send them on all its enabled VLANs that have been configured in the Announcing VLANs set of the DRB, which defaults to all enabled VLANs 💌.
4.2.4.3. Appointed VLAN-x Forwarder ✨
okay bestie, the appointed VLAN-x forwarder for a link has a whole list of jobs 💅 when a port's appointed forwarder is "inhibited" 🙈, it drops any native frames it receives and doesn't transmit them. Instead, it drops any native frames it decapsulates, in the VLAN it's appointed for.
- Loop avoidance 🔁:
- Inhibiting itself for a time, configurable per port from zero to 30 seconds, which defaults to 30 seconds, after it sees a root bridge change on the link (see Section 4.9.3.2).
- Inhibiting itself for VLAN-x, if it has received a Hello in which the sender asserts that it is appointed forwarder and that is either
- received on VLAN-x (has VLAN-x as its
Outer.VLAN) or - was originally sent on VLAN-x as indicated inside the body of the Hello.
- received on VLAN-x (has VLAN-x as its
- Optionally, not decapsulating a frame from ingress RBridge
RBmunless it has RBm's LSP, and the root bridge on the link it is about to forward onto is not listed in RBm's list of root bridges for VLAN-x. This is known as the "decapsulation check" or "root bridge collision check".
- Unless inhibited (see above), receiving VLAN-x native traffic from the link and forwarding it as appropriate.
- Receiving VLAN-x traffic for the link and, unless inhibited, transmitting it in native form after decapsulating it as appropriate.
- Learning the MAC address of local VLAN-x nodes by looking at the source address of VLAN-x frames from the link.
- Optionally learning the port of local VLAN-x nodes based on any sort of Layer 2 registration protocols, such as IEEE 802.11 association and authentication.
- Keeping track of the
{ egress RBridge, VLAN, MAC address }of distant VLAN-x end nodes, learned by looking at the fields{ ingress RBridge, Inner.VLAN ID, Inner.MacSA }from VLAN-x frames being received for decapsulation onto the link. - Optionally observe native IGMP [RFC3376], MLD [RFC2710], and MRD [RFC4286] frames to learn the presence of local multicast listeners and multicast routers.
- Optionally listening to TRILL ESADI messages for VLAN-x to learn
{ egress RBridge, VLAN-x, MAC address }triplets and the confidence level of such explicitly advertised end nodes. - Optionally advertising VLAN-x end nodes, on links for which it is appointed VLAN-x forwarder, in ESADI messages.
- Sending TRILL-Hello frames on VLAN-x unless the Announcing VLANs set for the port has been configured to disable them.
- Listening to BPDUs on the common spanning tree to learn the root bridge, if any, for that link and to report in its LSP the complete set of root bridges seen on any of its links for which it is appointed forwarder for VLAN-x.
When an appointed forwarder observes that the DRB on a link has changed, it no longer considers itself appointed for that link until appointed by the new DRB. 🫶
4.2.4.4. TRILL LSP Information 🧚
the TRILL IS-IS LSP has a bunch of info items that get mentioned all over this document, and they're all listed right here 🌸 unless an item is stated to be optional, it MUST be included. Other items MAY be included unless their inclusion is prohibited elsewhere in this document. The actual encoding of this info, plus the IS-IS Type or sub-Type values for any new IS-IS TLV or sub-TLV data elements, is specified in separate documents [RFC6165] [RFC6326].
- The IS-IS IDs of neighbors (pseudonodes as well as RBridges) of RBridge RBn, and the cost of the link to each of those neighbors. RBridges MUST use the Extended IS Reachability TLV (
#22, also known as "wide metric" [RFC5305]) and MUST NOT use the IS Reachability TLV (#2, also known as "narrow metric"). To facilitate efficient operation without configuration, and consistent with [802.1D], RBridges SHOULD, by default, set the cost of a link to the integer part of twenty trillion (20,000,000,000,000) divided by the RBridge port's bit rate, but not more than2**24-2(16,777,214). For example, the cost for a link accessed by a 1Gbps port would default to20,000. (Note that2**24-1has a special meaning in IS-IS and would exclude the link from SPF routes.) However, the link cost MAY, by default, be decreased for aggregated links and/or increased to not more than2**24-2if the link appears to be a bridged LAN. The tested MTU for the link (see Section 4.3) MAY be included via a sub-TLV. ⚡ - The following information in connection with the nickname or each of the nicknames of RBridge RBn:
- 2.1. The nickname value (2 octets).
- 2.2. The unsigned 8-bit priority for RBn to have that nickname (see Section 3.7.3).
- 2.3. The 16-bit unsigned priority of that nickname to becoming a distribution tree root.
- The maximum TRILL Header Version supported by RBridge RBn. 🎀
- The following information, in addition to the per-nickname tree root priority, in connection with distribution tree determination and announcement. (See Section 4.5 for further details on how this information is used.)
- 4.1. An unsigned 16-bit number that is the number of trees all RBridges in the campus calculate if RBn has the highest priority tree root.
- 4.2. A second unsigned 16-bit number that is the number of trees RBn would like to use.
- 4.3. A third unsigned 16-bit number that is the maximum number of distribution trees that RBn is able to calculate.
- 4.4. A first list of nicknames that are intended distribution trees for all RBridges in the campus to calculate.
- 4.5. A second list of nicknames that are distribution trees RBn would like to use when ingressing multi-destination frames.
- The list of VLAN IDs of VLANs directly connected to RBn for links on which RBn is the appointed forwarder for that VLAN. (Note: An RBridge may advertise that it is connected to additional VLANs in order to receive additional frames to support certain VLAN-based features beyond the scope of this specification, as mentioned in Section 4.8.4 and in a separate document concerning VLAN mapping inside RBridges.) RBridges may associate advertised connectivity to different groups of VLANs with specific nicknames they hold. In addition, the LSP contains the following information on a per-VLAN basis:
- 5.1. Per-VLAN Multicast Router attached flags: This is two bits of information that indicate whether there is an IPv4 and/or IPv6 multicast router attached to the Rbridge on that VLAN. An RBridge that does not do IP multicast control snooping MUST set both of these bits (see Section 4.5.4). This information is used because IGMP [RFC3376] and MLD [RFC2710] Membership Reports MUST be transmitted to all links with IP multicast routers, and SHOULD NOT be transmitted to links without such routers. Also, all frames for IP-derived multicast addresses MUST be transmitted to all links with IP multicast routers (within a VLAN), in addition to links from which an IP node has explicitly asked to join the group the frame is for, except for some IP multicast addresses that MUST be treated as broadcast. 🕸️
- 5.2. Per-VLAN mandatory announcement of the set of IDs of Root bridges for any of RBn's links on which RBn is appointed forwarder for that VLAN. Where MSTP (Multiple Spanning Tree Protocol) is running on a link, this is the root bridge of the CIST (Common and Internal Spanning Tree). This is to quickly detect cases where two Layer 2 clouds accidentally get merged, and where there might otherwise temporarily be two DRBs for the same VLAN on the same link. (See Section 4.2.4.3.)
- 5.3. Optionally, per-VLAN Layer 2 multicast addresses derived from IPv4 IGMP and IPv6 MLD notification messages received from attached end nodes on that VLAN, indicating the location of listeners for these multicast addresses (see Section 4.5.5).
- 5.4. Per-VLAN ESADI protocol participation flag, priority, and holding time. If this flag is one, it indicates that the RBridge wishes to receive such TRILL ESADI frames (see Section 4.2.5.1).
- 5.5. Per-VLAN appointed forwarder status lost counter (see Section 4.8.3).
- Optionally, the largest TRILL IS-IS frame that the RBridge can handle using the
originatingLSPBufferSizeTLV#14(see Section 4.3). - Optionally, a list of VLAN groups where address learning is shared across that VLAN group (see Section 4.8.4). Each VLAN group is a list of VLAN IDs, where the first VLAN ID listed in a group, if present, is the "primary" and the others are "secondary". This is to detect misconfiguration of features outside the scope of this document. RBridges that do not support features such as "shared VLAN learning" ignore this field.
- Optionally, the Authentication TLV
#10(see Section 6).
4.2.5. The TRILL ESADI Protocol 🦋
okay so RBridges that are the appointed VLAN-x forwarder for a link MAY participate in the TRILL ESADI protocol for that VLAN 💅 But all transit RBridges MUST properly forward TRILL ESADI frames as if they were multicast TRILL Data frames 🫶 ESADI frames are structured like IS-IS frames, but on the wire they're always TRILL encapsulated, like they're TRILL Data frames in disguise 🎀
Because of this forwarding, the ESADI protocol at an RBridge thinks it's directly connected by a shared virtual link to every other RBridge in the campus running ESADI for that VLAN 🧚 RBridges that don't implement ESADI, or aren't the appointed forwarder for that VLAN, do not decapsulate or locally process any TRILL ESADI frames they get for that VLAN 🙈 So these frames are transparently tunneled through transit RBridges, which treat them exactly like multicast TRILL Data frames. No special processing gets triggered by the forwarding ✨
TRILL ESADI frames sent on an IEEE 802.3 link are structured as shown below. The outer VLAN tag won't be there if the port it was sent out of stripped it 💖
Outer Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Destination Address | Sending RBridge MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending RBridge Port MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ethertype = C-Tag [802.1Q-2005]| Outer.VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TRILL Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = TRILL | V | R |M|Op-Length| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress (Dist. Tree) Nickname | Ingress (Origin) Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inner Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All-ESADI-RBridges Multicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All-ESADI-RBridges continued | Origin RBridge MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin RBridge MAC Address continued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ethertype = C-Tag [802.1Q-2005]| Inner.VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = L2-IS-IS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ESADI Payload (formatted as IS-IS):
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs |
Frame Check Sequence:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCS (Frame Check Sequence) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: TRILL ESADI Frame FormatThe Next Hop Destination Address, or Outer.MacDA, is the All-RBridges multicast address. The VLAN in the Outer.VLAN information will always be the Designated VLAN for the link the frame goes out on. The V and R fields will be zero, and the M field will be one 🌸 The VLAN in the Inner.VLAN information is the VLAN the ESADI frame applies to. The Origin RBridge MAC Address, aka Inner.MacSA, MUST be a globally unique MAC address owned by the RBridge that originates the ESADI frame (for example, any of its port MAC addresses), and each RBridge MUST use the same Inner.MacSA for all of the ESADI frames it originates 🔥
4.2.5.1. TRILL ESADI Participation 👑
An RBridge does not send any Hellos just because it's participating in ESADI 🙌 The info already in the TRILL IS-IS link state database is enough to figure out the ESADI DRB on the virtual link for each VLAN. Specifically, each RBridge's link state database info includes the VLANs (if any) it's participating in ESADI for, its priority for being picked as DRB for ESADI for each of those VLANs, its holding time, and its IS-IS system ID for breaking priority ties 💜
An RBridge doesn't need to do any routing calculation because of ESADI participation. Since everyone participating in ESADI for a given VLAN looks like they're connected to the same single virtual link, there are no routing decisions to make. A participating RBridge just transmits the ESADI frames it originates on that virtual link 🦋
The ESADI DRB sends TRILL-ESADI-CSNP frames on the ESADI virtual link. For robustness, a participating RBridge that decides some other RBridge should be the ESADI DRB on such a virtual link, but hasn't received or sent a TRILL-ESADI-CSNP in at least the ESADI DRB holding time, MAY also send a TRILL-ESADI-CSNP on the virtual link 🛟 A participating RBridge that figures out no other RBridges are participating in ESADI for a particular VLAN SHOULD NOT send ESADI information or TRILL-ESADI-CSNPs on the virtual link for that VLAN 🙅♀️
4.2.5.2. TRILL ESADI Information 🍓
The info distributed with ESADI is the list of local end-station MAC addresses known to the originating RBridge. For each address, there's also a one-octet unsigned "confidence" rating in the range 0-254 (see Section 4.8) 💅
This is meant to optionally support VLAN ID translation within RBridges, as specified in [VLAN-MAPPING]. That includes translating TRILL ESADI frames too. If TRILL ESADI frames could carry VLAN IDs in arbitrary internal spots, that translation would be impractical 😭 So TRILL ESADI frames MUST NOT contain the VLAN ID of the VLAN they apply to in the body of the frame after the Inner.VLAN tag ✨
4.2.6. SPF, Forwarding, and Ambiguous Destinations 🧠
This section describes the logical result we want. Alternative implementation methods can be used as long as they produce the same forwarding behavior 🎀
When building a forwarding table, an RBridge RB1 calculates shortest paths from itself as described in Appendix C.1 of [RFC1195]. Nicknames get added into the shortest path calculation as a final step, just like with an end node. If multiple RBridges (say, RBa and RBb) claim the same nickname, that's a temporary situation: one of RBa or RBb will defer and pick a new nickname. Meanwhile, RB1 just adds that nickname as if it were attached to both RBa and RBb, and uses its normal shortest path calculation to choose the next hop 🦋
An ingress RBridge RB2 maps a native frame's known unicast destination MAC address and VLAN into an egress RBridge nickname. If RB2 only learns addresses by observing received and decapsulated frames, those MAC addresses can't be duplicated within a VLAN in RB2's tables. That's because newer learned info overwrites older info if its confidence is higher or equal, and gets ignored if its confidence is lower 💅 However, duplicates of the same MAC within a VLAN can show up in ESADI data, and between ESADI data and addresses learned from observed received and decapsulated frames, entered by manual configuration, or learned through Layer 2 registration protocols. If duplicate MAC addresses happen within a VLAN, RB2 sends frames to the MAC with the highest confidence. If the confidences are also tied between the duplicates, it is suggested that RB2 direct all such frames (or all such frames in the same ECMP flow) toward the same egress RBridge, just for consistency. Using other policies won't cause a network problem, though, since transit RBridges don't examine the Inner.MacDA for known unicast frames 🙌
4.3. Inter-RBridge Link MTU Size 📏
There are two reasons it matters to know what size of frame each inter-RBridge link in the campus can support 👀
- RBridge RB1 must know the size of link state information messages it can generate that will be guaranteed to be forwardable across all inter-RBridge links in the campus.
- If traffic engineering tools know which links support larger than minimally acceptable data packet sizes, paths can be computed that can support large data packets.
4.3.1. Determining Campus-Wide TRILL IS-IS MTU Size 🌈
In a stable campus, all RBridges have to ultimately agree on the value of "Sz", the minimum acceptable inter-RBridge link size for the campus, for TRILL IS-IS to work properly 🫶 All RBridges MUST format their link state information messages into chunks no larger than what they believe Sz to be. Also, every RBridge RB1 SHOULD test each of its RBridge adjacencies (say, to RB2) to make sure the RB1-RB2 link can forward packets of at least size Sz 🔍
Sz has no direct effect on end stations and isn't directly related to any end-station-to-end-station "path MTU" 💁♀️ Using Sz, or any link MTU info TRILL IS-IS gathers, in traffic engineering of routes or in figuring out any path MTU is beyond the scope of this document. Native frames that, after TRILL encapsulation, exceed the MTU of a link they're sent on will generally get discarded 💀
Sz is determined by each RBridge (optionally) advertising, in its LSP, what it assumes the campus-wide Sz is. In IS-IS, this LSP element is known as the originatingLSPBufferSize, TLV #14. The default and minimum value for Sz is 1470 octets, and that's also the implicitly advertised value of Sz if the TLV is absent. This length (which is also the maximum size of a TRILL-Hello) was picked to make it extremely unlikely that a TRILL control frame, even with reasonable additional headers, tags, and/or encapsulation, would run into MTU problems on an inter-RBridge link 🎀
The campus-wide value of Sz is the smallest value of Sz advertised by any RBridge 👑
4.3.2. Testing Link MTU Size ✨
okay so TRILL has two brand-new IS-IS message types for RBridge neighbors to check how big a packet their link can handle in both directions 🦋 they're called:
-- MTU-probe
-- MTU-ackBoth the MTU-probe and the MTU-ack get padded out to the size being tested 📏
Sending MTU-probes is optional 💅 BUT if an RBridge RB2 gets an MTU-probe from RB1, it MUST reply with an MTU-ack padded to the same size as that probe. no excuses 😤 The MTU-probe MAY be multicast to All-RBridges, or unicast to one specific RBridge. The MTU-ack is normally unicast back to whoever sent the probe, but it MAY be multicast to All-RBridges too 🫶
Now the retry drama 💀 If RB1 sends a probe of size X to RB2 and never gets an MTU-ack back after k tries (k is a configurable parameter, default 3), RB1 decides the RB1-RB2 link can't handle size X. ngl that's a harsh breakup 😭 If X is not greater than Sz, RB1 sets the "failed minimum MTU test" flag for RB2 in its Hello. But if size X does succeed and X > Sz, then RB1 advertises the largest tested X for each adjacency in the TRILL Hellos it sends on that link 🎀 And RB1 MAY also advertise X as an attribute of the link to RB2 in its LSP. slay 👑
4.4. TRILL-Hello Protocol 🧚
okay the TRILL-Hello protocol is a little different from the Layer 3 IS-IS LAN Hello protocol 🌸 It uses a brand-new IS-IS message type called a TRILL-Hello. main character energy 💖
4.4.1. TRILL-Hello Rationale 🦋
so why make a whole new thing? 🙈 In Layer 3 IS-IS, the LAN Hello protocol can end up electing multiple Designated Routers (DRs), because when a router picks a DR it ignores any other router it doesn't have 2-way connectivity with. Also, Layer 3 IS-IS LAN Hellos get padded, so neighbors that can't handle the maximum-sized packet with each other don't form adjacencies at all 😭 That means two neighbors that can talk to each other, but over a link whose MTU is smaller than what they think of as max-sized packets, won't even see each other's Hellos. The result? Routers form cliques and the link turns into multiple pseudonodes. messy 💀
Honestly that's fine for Layer 3 🌈 but NOT fine for Layer 2, where loops can form if there are multiple DRBs 🚨 So yeah, TRILL-Hello is its own thing.
Another issue is making sure subsets of the info can show up in any single message and still be processable, kind of like IS-IS LSPs and CSNPs 🎀 TRILL-Hello frames aren't padded, but they can get really big 🍓 An example is when some backbone tech connects hundreds of TRILL sites over what looks to TRILL like one giant Ethernet. The RBridges connected to that cloud would see the backbone as a single link with hundreds of neighbors 🫠
Here's the iconic part ✨ In TRILL (unlike Layer 3 IS-IS), the DRB gets picked based only on priority and MAC address. So if RB2 gets a TRILL-Hello from RB1 with a higher (priority, MAC), RB2 defers to RB1 as DRB, even if RB1 doesn't list RB2 in its TRILL-Hello 💅
The neighbor list doesn't affect the DRB election, but it does decide what gets announced in LSPs 🔥 RB1 only reports links to RBridges it has two-way connectivity with. So if RB1 is the DRB on a link, and for whatever reason (an MTU mismatch, or one-way connectivity) RB1 and RB2 don't have two-way connectivity, then RB2 doesn't report a link to RB1 (or the pseudonode), and RB1 (or RB1 on behalf of the pseudonode) doesn't report a link to RB2 either. not me being dramatic about two-way connectivity 😤
4.4.2. TRILL-Hello Contents and Timing 💜
The TRILL-Hello has a new IS-IS message type. It starts with the same fixed header as an IS-IS LAN Hello, which includes the 7-bit priority for the issuing RBridge to be DRB on that link. TRILL-Hellos get sent on the same timing as IS-IS LAN Hellos ⭐
TRILL-Hello messages, including their Outer.MacDA and Outer.MacSA (but NOT any Outer.VLAN or other tags), MUST NOT exceed 1470 octets in length and SHOULD NOT be padded 🙅♀️ The following info MUST appear in every TRILL-Hello. Heads up: references to "TLV" may actually be a "sub-TLV" as specified in separate documents [RFC6165] [RFC6326] 🫶
- The VLAN ID of the Designated VLAN for the link.
- A copy of the
Outer.VLANID the Hello was tagged with when sent. - A 16-bit port ID assigned by the sending RBridge to the port the TRILL-Hello goes out on, such that no two ports of that RBridge have the same port ID. 🦋
- A nickname of the sending RBridge.
- Two flags as follows:
- 5.a. A flag that, if set, indicates that the sender has detected VLAN mapping on the link, within the past 2 of its Holding Times. 👀
- 5.b. A flag that, if set, indicates that the sender believes it is appointed forwarder for the VLAN and port on which the TRILL-Hello was sent. 💖
The following info MAY appear 🌸
- The set of VLANs for which end-station service is enabled on the port.
- Several flags as follows:
- 2.a. A flag that, if set, indicates that the sender's port was configured as an access port.
- 2.b. A flag that, if set, indicates that the sender's port was configured as a trunk port.
- 2.c. A bypass pseudonode flag, as described below in this section. ✨
- If the sender is the DRB, the Rbridges (excluding itself) that it appoints as forwarders for that link, and the VLANs it appoints them for. As described below, this TLV is designed so that not all the appointment info needs to be in each Hello. Its absence means appointed forwarders should continue as previously assigned 🧚
- The TRILL neighbor list. This is a new TLV, NOT the same as the IS-IS Neighbor TLV, so it can handle fragmentation and report the MTU on the link (see Section 4.4.2.1) 🎀
The Appointed Forwarders TLV specifies a range of VLANs and, within that range, specifies which Rbridge (other than the DRB, if any) is appointed forwarder for the VLANs in that range [RFC6326]. Appointing an RBridge as forwarder on a port for a VLAN that isn't enabled on that port has no effect 🙈
It's expected that lots of links between RBridges will be point-to-point. In that case a pseudonode just adds complexity 😩 If the DRB specifies the bypass pseudonode bit in its TRILL-Hellos, the RBridges on the link just report their adjacencies as point-to-point. This has no effect on how LSPs are flooded on a link. It ONLY affects what LSPs get generated 🦋
For example 💅 if RB1 and RB2 are the only RBridges on the link and RB1 is the DRB, then if RB1 creates a pseudonode that gets used, there are 3 LSPs: one for, say, RB1.25 (the pseudonode), one for RB1, and one for RB2. RB1.25 reports connectivity to RB1 and RB2, and RB1 and RB2 each just say they're connected to RB1.25. Whereas if DRB RB1 sets the bypass pseudonode bit in its Hellos, there are only 2 LSPs: RB1 and RB2 each reporting connectivity to each other. so much cleaner 🫶
A DRB SHOULD set the bypass pseudonode bit for its links UNLESS, for a particular link, it has seen at least two simultaneous adjacencies on the link at some point since it last rebooted 🔥
4.4.2.1. TRILL Neighbor List 🌈
The new TRILL Neighbor TLV includes the following info for each neighbor it lists:
- The neighbor's MAC address.
- MTU size to this neighbor as a 2-octet unsigned integer in units of 4-octet chunks. The value zero indicates that the MTU is untested. 📏
- A flag for "failed minimum MTU test".
To allow partial reporting of neighbors, the neighbor IDs MUST be sorted by ID 🍓 If a set of neighbors { X1, X2, X3, ... Xn } is reported in RB1's Hello, then X1 < X2 < X3, ... < Xn. If RBridge RB2's ID falls between X1 and Xn and doesn't appear in RB1's Hello, then RB2 knows RB1 hasn't heard RB2's Hello. ouch 💀
There are also two overall TRILL Neighbor List TLV flags: "the smallest ID I reported in this Hello is the smallest ID of any neighbor", and "the largest ID I reported in this Hello is the largest ID of any neighbor". If all the neighbors fit in RB1's TRILL-Hello, both flags get set 💖
If RB1 reports { X1, ... Xn } in its Hello with the "smallest" flag set, and RB2's ID is smaller than X1, then RB2 knows RB1 hasn't heard RB2's Hello. Same deal the other way: if RB2's ID is larger than Xn and the "largest" flag is set, RB2 knows RB1 hasn't heard its Hello either 🙅♀️
To make sure any RBridge RB2 can definitively figure out whether RB1 can hear it, RB1's neighbor list MUST eventually cover every possible range of IDs 🎀 That's within a period that depends on RB1's policy, NOT necessarily within any specific period like the holding time. In other words, if X1 is the smallest ID reported in one of RB1's neighbor lists, and the "smallest" flag is NOT set, then X1 MUST also appear as the largest ID reported in a different TRILL-Hello neighbor list. Or, fragments can overlap, as long as there's no gap, so that some range (say, between Xi and Xj) never shows up in any fragment 🧚
4.4.3. TRILL MTU-Probe and TRILL Hello VLAN Tagging
okay so the MTU-probe thing is how RBridges figure out the MTU for their transmissions to each other 📏✨ and the probes and their acknowledgements only ever go out on the Designated VLAN 🦋
An RBridge RBn keeps the same VLAN info that a customer IEEE [802.1Q-2005] bridge does, including the set of VLANs enabled for output through that port (see Section 4.9.2). On top of that, RBn tracks these TRILL-specific VLAN parameters for each port 💅
- a) Desired Designated VLAN: the VLAN that RBn will put in its TRILL-Hellos, if RBn is the DRB, as the VLAN every RBridge on the link uses to talk TRILL frames, except some TRILL-Hellos. This MUST be a VLAN enabled on RBn's port. It defaults to the numerically lowest enabled VLAN ID, which is VLAN 1 for a default configuration RBridge 🎀
- b) Designated VLAN: the VLAN actually being used on the link for all TRILL frames except some TRILL Hellos. It's RBn's Desired Designated VLAN if RBn believes it's the DRB, or the Designated VLAN from the DRB's Hellos if RBn isn't the DRB 🌸
- c) Announcing VLANs set: defaults to the enabled VLANs set on the port, but it can be configured to be a subset of those enabled VLANs 📣
- d) Forwarding VLANs set: the set of VLANs for which an RBridge port is appointed VLAN forwarder on that port. This MUST contain only enabled VLANs for the port, possibly all of them 👑
On each of its ports that isn't configured to use P2P Hellos, an RBridge sends TRILL-Hellos Outer.VLAN tagged with each VLAN in a set of VLANs. That set depends on the RBridge's DRB status and the VLAN parameters above. RBridges send TRILL Hellos Outer.VLAN tagged with the Designated VLAN, unless that VLAN isn't enabled on the port. The DRB also sends TRILL Hellos Outer.VLAN tagged with each enabled VLAN in its Announcing VLANs set. All non-DRB RBridges send TRILL-Hellos Outer.VLAN tagged with all enabled VLANs that are in the intersection of their Forwarding VLANs set and their Announcing VLANs set. More symbolically, TRILL-Hello frames, when sent, go out like this 🧮
If sender is DRB
intersection ( Enabled VLANs,
union ( Designated VLAN, Announcing VLANs ) )
If sender is not DRB
intersection ( Enabled VLANs,
union ( Designated VLAN,
intersection ( Forwarding VLANs, Announcing VLANs ) ) )Setting the Announcing VLANs set to null minimizes the number of TRILL-Hellos. In that case, TRILL-Hellos are only tagged with the Designated VLAN. Great care should be taken in configuring an RBridge to not send TRILL Hellos on any VLAN where that RBridge is appointed forwarder, because under some circumstances, failing to send those Hellos can lead to loops. 🚨
The number of TRILL-Hellos is maximized, within this specification, by setting the Announcing VLANs set to the set of all enabled VLAN IDs, which is the default. In that case, the DRB sends TRILL-Hello frames tagged with all of its Enabled VLAN tags. Any non-DRB RBridge RBn sends TRILL-Hello frames tagged with the Designated VLAN, if it's enabled, and tagged with all the VLANs for which RBn is an appointed forwarder. (It's possible to send even more TRILL-Hellos. In particular, non-DRB RBridges could send TRILL-Hellos on enabled VLANs for which they aren't an appointed forwarder and which aren't the Designated VLAN. That would cause no harm beyond extra communications and processing burden 🙈)
When an RBridge port comes up, until it has heard a TRILL-Hello from a higher priority RBridge, it considers itself the DRB on that port and sends TRILL-Hellos on that basis. Similarly, even if it has at some point recognized some other RBridge on the link as the DRB, if it receives no TRILL-Hellos on that port from a higher priority RBridge acting as DRB for a long enough time, as specified by IS-IS, it reverts to believing itself to be the DRB. 🔄
4.4.4. Multiple Ports on the Same Link
It's possible for an RBridge RB1 to have multiple ports to the same link. It's important for RB1 to recognize which of its ports are on the same link. For instance, if RB1 is appointed forwarder for VLAN A, RB1 knows that only one of its ports acts as appointed forwarder for VLAN A on that link 🫶
RB1 detects this condition by receiving TRILL-Hello messages with the same IS-IS pseudonode ID on multiple ports. RB1 might have one set of ports, say { p1, p2, p3 }, on one link, another set of ports { p4, p5 } on a second link, and yet other ports, say p6, p7, p8, that are each on distinct links. Let's call a set of ports on the same link a "port group" 🍓
If RB1 detects that a set of ports, say { p1, p2, p3 }, is a port group on a link, then RB1 MUST ensure that it doesn't cause loops when it encapsulates and decapsulates traffic from and to that link. If RB1 is appointed forwarder for VLAN A on that Ethernet link, RB1 MUST encapsulate and decapsulate VLAN A on only one of the ports. However, if RB1 is appointed forwarder for more than one VLAN, RB1 MAY choose to load split among its ports, using one port for some set of VLANs and another port for a disjoint set of VLANs. 🔀
If RB1 detects VLAN mapping occurring (see Section 4.4.5), then RB1 MUST NOT load split as appointed forwarder. Instead, RB1 MUST act as appointed VLAN forwarder on that link on only one of its ports in the port group. 🚫
When forwarding TRILL-encapsulated multi-destination frames to and from a link on which RB1 has a port group, RB1 MAY choose to load split among its ports, provided that it doesn't duplicate frames and provided that it keeps frames for the same flow on the same port. If RB1's neighbor on that link, RB2, accepts multi-destination frames on that tree on that link from RB1, then RB2 MUST accept the frame from any of RB2's adjacencies to RB1 on that link. 🌈
If an RBridge has more than one port connected to a link and those ports have the same MAC address, they can be told apart by the port ID contained in TRILL-Hellos. 🪪
4.4.5. VLAN Mapping within a Link
IEEE [802.1Q-2005] doesn't provide for bridges changing the C-tag VLAN ID of a tagged frame they receive, which is what we call mapping VLANs. Still, some bridge products do offer this capability, and bridged LANs can be configured to act this way anyway 😭 For example, a bridge port can be configured to strip VLAN tags on output and send the resulting untagged frames onto a link leading to another bridge's port, which is configured to tag those frames with a different VLAN. Each port's configuration is legal under [802.1Q-2005], but taken together they do manipulations that aren't permitted on a single customer [802.1Q-2005] bridge. Since RBridge ports have the same VLAN capabilities as customer [802.1Q-2005] bridges, this can happen even without any bridges in the picture. (VLAN mapping is referred to in IEEE 802.1 as "VLAN ID translation".) 🧚
RBridges include the Outer.VLAN ID inside every TRILL-Hello message. When a TRILL-Hello is received, RBridges compare this saved copy with the Outer.VLAN ID information associated with the received frame. If these differ, and the VLAN ID inside the Hello is X while the Outer.VLAN is Y, it can be assumed that VLAN ID X is being mapped into VLAN ID Y. 🔍
When non-DRB RB2 detects VLAN mapping, based on receiving a TRILL-Hello where the VLAN tag in the body of the Hello differs from the one in the outer header, it sets a flag in all of its TRILL-Hellos for a period of two of its Holding Times since the last time RB2 detected VLAN mapping. When DRB RB1 is informed of VLAN mapping, either by receiving a TRILL-Hello that has been VLAN-mapped or by seeing the "VLAN mapping detected" flag in a neighbor's TRILL-Hello on the link, RB1 re-assigns VLAN forwarders so there's only a single forwarder on the link for all VLANs. 👑💖
4.5. Distribution Trees ✨
okay bestie, let's talk about distribution trees 🌳💖 RBridges use these to forward multi-destination frames (see Section 2.4.2). The trees are bidirectional 🦋. One tree would technically be enough for the whole campus, but computing extra trees is worth it for two reasons. It enables multipathing of multi-destination frames 💅, and it lets you pick a tree root that's closer to the ingress RBridge, or even the ingress RBridge itself. A closer root makes delivery more efficient when frames only need to reach some of the links in the campus, and it cuts down on out-of-order delivery when a unicast address goes from unknown to known. 🙈 If your apps really can't handle the occasional out-of-order unicast frame from those transitions, the campus should be engineered so those are super rare. You can do that with the ESADI protocol, by configuring addresses so there are no unknown destination unicast frames, or by using keep alive frames. 🫶
Next, an RBridge can acquire multiple nicknames, which means it can have multiple trees rooted at the same RBridge. The tree number is used as a tiebreaker for equal cost paths, so even trees rooted at the same RBridge will likely use different equal cost paths. Iconic ✨
How an ingress RBridge picks the distribution tree or trees it uses for multi-destination frames is out of scope for this document 🙃. For the reasons above, though, a good default (absent other factors) is the tree whose root is least cost from the ingress RBridge. That's also the default for an ingress RBridge that uses a single tree for multi-destination frames 👑.
RBridges precompute every tree that might be used, and they keep state for Reverse Path Forwarding Check filters (see Section 4.5.2) 🧚. Since the tree number is a tiebreaker, it's really important that every RBridge knows:
- how many trees to compute
- which trees to compute
- what the tree number for each tree is
- which trees each ingress RBridge might choose (for building Reverse Path Forwarding Check filters)
Each RBridge advertises a "tree root" priority in its LSP for its nickname, or for each nickname if it's been configured to have more than one 💜. This is a 16-bit unsigned integer, and it defaults to 0x8000 for an unconfigured RBridge. Tree roots are ordered with the highest numerical priority winning. The tiebreaker is the system ID of the RBridge (numerically higher means higher priority). If that's also equal, the numerically higher nickname value wins, read as an unsigned integer 🌸.
Each RBridge also advertises in its LSP the maximum number of distribution trees it can compute, and the number of trees it wants every RBridge in the campus to compute 📣. The number of trees, k, computed for the campus is the number wanted by RB1, which is the RBridge with the nickname that has the highest "tree root" priority. But k can't go above the number of trees supported by the campus RBridge that supports the fewest trees 😭. If RB1 doesn't specify the specific distribution tree roots (described below), then the k highest priority trees are the ones every RBridge computes. Some of those k trees might share a root if that RBridge has multiple nicknames 🍓.
If an RBridge specifies the number of trees it can compute, or the number it wants computed for the campus, as 0, that gets treated as 1. So k defaults to 1 💅.
Also, RB1 (the RBridge holding the highest root priority nickname) might explicitly advertise a set of s trees by listing s nicknames. In that case, the first k of those s trees get computed. If s is less than k, or if any of the s nicknames RB1 advertises don't exist in the LSP database, RBridges still compute k trees. The remaining trees they pick are the highest priority trees, so that k trees get computed in total ✨.
There are two exceptions to all of this that can lead to fewer distribution trees being computed 🙈:
- A nickname whose tree root priority is zero isn't selected as a tree root based on priority. It can still get selected if the RBridge holding the highest priority tree root nickname lists it. The one exception: if every nickname has priority zero, the highest priority among them (decided by the tiebreakers) is used as a tree root, so there's always at least one distribution tree 🛟.
- As a transient condition, two or more identical nicknames can show up in the list of roots for trees to be computed. In that case, it's pointless to compute a tree for the nickname(s) that the RBridges holding them are about to lose. So a distribution tree is only computed for the instance of the nickname where the priority to hold it is highest, which cuts down the total number of trees 💀. (Going further down the priority-ordered list of possible tree root nicknames to keep the tree count up also wouldn't help, since those extra roots would only be valid during a very brief nickname transition period.)
The k trees calculated for a campus are ordered and numbered from 1 to k 🔢. RB1 might also advertise a set of s trees by listing s nicknames, as described above. How the numbering works depends on how s compares to k 👑:
- If
s == k, the trees are numbered in the order RB1 advertises them. - If
s == 0, the trees are numbered in order of decreasing priority. For example, if RB1 advertises only thatk=2, then the highest priority tree is number 1, and the second highest priority tree is number 2. - If
s < k, the trees RB1 advertised are numbered from 1 in the order they were advertised. Then the rest are chosen by priority order from the remaining possible trees, and the numbering keeps going. For example, say RB1 advertisesk=4and advertises{ Tx, Ty }as the nicknames of the roots of the trees, and the campus-wide priority ordering of trees in decreasing order isTy > Ta > Tc > Tb > Tx. Then the numbering goes like this:Txis 1 andTyis 2, because that's the order RB1 advertised them in. After that,Tais 3 andTcis 4, since they're the highest priority trees that haven't been numbered yet 🧁.
4.5.1. Distribution Tree Calculation
RBridges don't use spanning tree to calculate distribution trees 🙅♀️. Instead, distribution trees are calculated from the link state information, with a particular RBridge nickname selected as the root. Each RBridge RBn works out a tree rooted at RBi on its own, by running the SPF (Shortest Path First) calculation with RBi as the root. It doesn't need any extra exchange of information for this 🦋.
When building a distribution tree, it's really important that every RBridge picks the same links for that tree 🫶. So when there are equal cost paths for a particular tree, every RBridge needs to use the same tiebreakers. It's also good to be able to split traffic across as many links as possible 💜. That's why a simple tiebreaker like "always choose the parent with lower ID" wouldn't be desirable. Instead, TRILL uses the tree number as a parameter in the tiebreaking algorithm ✨.
When building tree number j, remember all the possible equal cost parents for node N. After calculating the entire "tree" (really a directed graph), then for each node N with p parents, order those parents in ascending order by their 7-octet IS-IS ID, read as an unsigned integer, and number them starting at zero. For tree j, N's parent is choice j mod p 🔢.
Heads up: there might be multiple equal cost links between N and a potential parent P that don't have pseudonodes. That happens when they're point-to-point links or pseudonode-suppressed links. These get treated as a single link when building the tree, because they all share the same parent P, whose IS-IS ID is P.0 🌈.
In other words, the set of potential parents for N, for the tree rooted at R, is made up of the parents that give equally minimal cost paths from N to R and that have distinct IS-IS IDs, based on what's reported in the LSPs 🎀.
4.5.2. Multi-Destination Frame Checks ✨
okay bestie, so when a multi-destination TRILL-encapsulated frame lands on an RBridge, it has to pass four checks 🔍 and any one of them can bin it 🗑️ 💅
- Tree Adjacency Check 🌳: Each RBridge RBn keeps a set of adjacencies (
{ port, neighbor }pairs) for each distribution tree it is calculating. One of these adjacencies is toward the tree root RBi, and the others are toward the leaves. Once the adjacencies are chosen, it is irrelevant which ones are towards the root RBi and which are away from RBi. RBridges MUST drop a multi-destination frame that arrives at a port from an RBridge that is not an adjacency for the tree on which the frame is being distributed. Let's suppose that RBn has calculated that adjacencies a, c, and f are in the RBi tree. A multi-destination frame for the distribution tree RBi is received only from one of the adjacencies a, c, or f (otherwise it is discarded) and forwarded to the other two adjacencies. Should RBn have multiple ports on a link, a multi-destination frame it sends on one of these ports will be received by the others but will be discarded as an RBridge is not adjacent to itself. 🙈- RPF Check 🪞: Another technique RBridges use for avoiding temporary multicast loops during topology changes is the Reverse Path Forwarding Check. It involves checking that a multi-destination frame, based on the tree and the ingress RBridge, arrives from the expected link. RBridges MUST drop multi-destination frames that fail the RPF check. 🚫
To keep the amount of state needed for the RPF check small, each RBridge RB2 MUST announce which trees RB2 may choose when RB2 ingresses a multi-destination packet. When any RBridge, say, RB3, is computing the tree from nickname X, RB3 computes, for each RBridge RB2 that might act as ingress for tree X, the link on which RB3 should receive a packet from ingress RB2 on tree X, and notes for that link that RB2 is a legal ingress RBridge for tree X.
The info about which trees RB2 might choose lives in RB2's LSP. Just like the highest priority RBridge RB1 specifies the k trees that get computed by all RBridges, RB2 specifies a number j, which is the total number of different trees RB2 might specify. The specific trees RB2 might specify are a combo of specified trees and trees picked from the highest priority trees. If RB2 specifies any trees that are not in the k trees RB1 specified, they are ignored. 🙃
The j potential ingress trees for RB2 are the ones with nicknames that RB2 has explicitly specified in "specified ingress tree nicknames" (and that are included in the k campus-wide trees selected by highest priority RBridge RB1), with the remainder (up to the maximum of {j,k}) being the highest priority of the k campus-wide trees.
The default value for j is 1. The value 0 for j is special and means that RB2 can pick any of the k trees being computed for the campus. 👑
- Parallel Links Check 🔗: If the tree-building and tiebreaking for a particular multi-destination frame distribution tree selects a non-pseudonode link between RB1 and RB2, that "RB1-RB2 link" might actually be made up of multiple links. These parallel links would be visible to RB1 and RB2, but not to the rest of the campus (because the links are not represented by pseudonodes). If this bundle of parallel links is included in a tree, it's important for RB1 and RB2 to decide which link to use, but it's irrelevant to other RBridges. So the tiebreaking algorithm doesn't need to be visible to any RBridges other than RB1 and RB2. In this case, RB1-RB2 adjacencies are ordered as follows, with the one "most preferred" adjacency being the one on which RB1 and RB2 transmit to and receive multi-destination frames from each other. 🧩
a) Most preferred are those established by P2P Hellos. Tiebreaking among those is based on preferring the one with the numerically highest Extended Circuit ID as associated with the adjacency by the RBridge with the highest System ID. 🥇
b) Next considered are those established through TRILL-Hello frames, with suppressed pseudonodes. Note that the pseudonode is suppressed in LSPs, but still appears in the TRILL-Hello, and therefore is available for this tiebreaking. Among these links, the one with the numerically largest pseudonode ID is preferred. 🥈
- Port Group Check 👯: If an RBridge has multiple ports attached to the same link, a multi-destination frame it is receiving will arrive on all of them. All but one received copy of such a frame MUST be discarded to avoid duplication. All such frames that are part of the same flow must be accepted on the same port to avoid re-ordering. 🚦
When a topology change happens (including apparent changes during start up), an RBridge MUST adjust its input distribution tree filters no later than it adjusts its output forwarding. ⏱️✨
4.5.3. Pruning the Distribution Tree 🌿
Each distribution tree SHOULD be pruned per VLAN, cutting off branches that have no potential receivers downstream. Multi-destination TRILL Data frames SHOULD only be forwarded on branches that are not pruned. 🌸
Further pruning SHOULD be done in two cases: (1) IGMP [RFC3376], MLD [RFC2710], and MRD [RFC4286] messages, where these are to be delivered only to links with IP multicast routers; and (2) other multicast frames derived from an IP multicast address that should be delivered only to links that have registered listeners, plus links that have IP multicast routers, except for IP multicast addresses that must be broadcast. Each of these cases is scoped per VLAN. 🎀
Let's assume RBridge RBn knows that adjacencies (a, c, and f) are in the nickname1 distribution tree. RBn marks pruning info for each of the adjacencies in the nickname1-tree. For each adjacency and for each tree, RBn marks:
- the set of VLANs reachable downstream,
- for each one of those VLANs, flags indicating whether there are IPv4 or IPv6 multicast routers downstream, and
- the set of Layer 2 multicast addresses derived from IP multicast groups for which there are receivers downstream.
4.5.4. Tree Distribution Optimization 🧠
RBridges MUST determine the VLAN associated with all native frames they ingress, and properly enforce VLAN rules on the emission of native frames at egress RBridge ports according to how those ports are configured and designated as appointed forwarders. RBridges SHOULD also prune the distribution tree of multi-destination frames according to VLAN. But, since they are not required to do such pruning, they may receive TRILL data or ESADI frames that should have been VLAN pruned earlier in the tree distribution. They silently discard such frames. A campus may have some Rbridges that prune distribution trees on VLAN and some that don't. 🫶
The situation is more complex for multicast. RBridges SHOULD analyze IP-derived native multicast frames, and learn and announce listeners and IP multicast routers for such frames as discussed in Section 4.7 below. And they SHOULD prune the distribution of IP-derived multicast frames based on that learning and those announcements. But they are not required to prune based on IP multicast listener and router attachment state. And, unlike VLANs, where VLAN attachment state of ports MUST be maintained and honored, RBridges are not required to maintain IP multicast listener and router attachment state. 😤💜
An RBridge that does not examine native IGMP [RFC3376], MLD [RFC2710], or MRD [RFC4286] frames that it ingresses MUST advertise that it has IPv4 and IPv6 IP multicast routers attached for all the VLANs for which it is an appointed forwarder. It need not advertise any IP-derived multicast listeners. This will cause all IP-derived multicast traffic to be sent to this RBridge for those VLANs. It then egresses that traffic onto the links for which it is appointed forwarder, where the VLAN of the traffic matches the VLAN for which it is appointed forwarder on that link. (This may cause the suppression of certain IGMP membership report messages from end stations, but that is not significant because any multicast traffic that such reports would be requesting will be sent to such end stations under these circumstances.) 🙌
A campus may have a mix of Rbridges with different levels of IP-derived multicast optimization. An RBridge may receive IP-derived multicast frames that should have been pruned earlier in the tree distribution. It silently discards such frames. 🫠
See also "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches" [RFC4541]. 📚
4.5.5. Forwarding Using a Distribution Tree 🚀
With full optimization, forwarding a multi-destination data frame goes like this. References to adjacencies below do not include the adjacency on which a frame was received. 💫
- The RBridge RBn receives a multi-destination TRILL Data frame with inner
VLAN-xand a TRILL header indicating that the selected tree is thenickname1tree; - if the source from which the frame was received is not one of the adjacencies in the
nickname1tree for the specified ingress RBridge, the frame is dropped (see Section 4.5.1); - else, if the frame is an IGMP or MLD announcement message or an MRD query message, then the encapsulated frame is forwarded onto adjacencies in the
nickname1tree that indicate there are downstreamVLAN-xIPv4 or IPv6 multicast routers as appropriate; - else, if the frame is for a Layer 2 multicast address derived from an IP multicast group, but its IP address is not in the range of IP multicast addresses that must be treated as broadcast, the frame is forwarded onto adjacencies in the
nickname1tree that indicate there are downstreamVLAN-xIP multicast routers of the corresponding type (IPv4 or IPv6), as well as adjacencies that indicate there are downstreamVLAN-xreceivers for that group address; - else (the inner frame is for a Layer 2 multicast address not derived from an IP multicast group, or an unknown destination, or broadcast, or an IP multicast address that is required to be treated as broadcast), the frame is forwarded onto an adjacency if and only if that adjacency is in the
nickname1tree and marked as reachingVLAN-xlinks. 🎯
For each link for which RBn is appointed forwarder, RBn additionally checks to see if it should decapsulate the frame and send it to the link in native form, or process the frame locally. 🍓
TRILL ESADI frames will be delivered only to RBridges that are appointed forwarders for their VLAN. Such frames will be multicast throughout the campus, like other non-IP-derived multicast data frames, on the distribution tree chosen by the RBridge that created the TRILL ESADI frame, and pruned according to the Inner.VLAN ID. Thus, all the RBridges that are appointed forwarders for a link in that VLAN receive them. 🦋
4.6. Frame Processing Behavior ✨
Okay bestie, this is where the RBridge decides what to do with every frame that shows up 💅. It covers all the different kinds of received frames and how they get forwarded when that's the right move. Section 4.6.1 is for native frames, Section 4.6.2 is for TRILL frames, and Section 4.6.3 is for Layer 2 control frames. The processing can be organized or sequenced differently than I'm describing here, as long as the result is the same 🫶. For the frame type definitions, check Section 1.4 🌸.
Corrupt frames get tossed as soon as they hit an RBridge port 🗑️. That means frames that aren't a multiple of 8 bits, frames that are too short or too long for the link protocol or hardware in use, and frames with a bad FCS. An IEEE 802.1 bridge port does the same thing, so it's giving consistency 🙅♀️.
Source address info ( { VLAN, Outer.MacSA, port } ) is learned by default from any frame with a unicast source address (see Section 4.8) 🧠✨.
4.6.1. Receipt of a Native Frame 💌
If the port is configured as disabled, or if end-station service is disabled on the port (by configuring it as a trunk port or by configuring it to use P2P Hellos), the frame is discarded. Bye 👋.
The ingress Rbridge RB1 works out the VLAN ID for a native frame using the same rules that IEEE [802.1Q-2005] bridges use (see Appendix D and Section 4.9.2) 🧩. Once the VLAN is set, if RB1 isn't the appointed forwarder for that VLAN on the port where the frame came in, or if it's inhibited, the frame gets discarded. If RB1 is the appointed forwarder for that VLAN and isn't inhibited (see Section 4.2.4.3), then the native frame gets forwarded according to Section 4.6.1.1 if it's unicast, or according to Section 4.6.1.2 if it's multicast or broadcast. Main character energy 🎀.
4.6.1.1. Native Unicast Case 🦋
If the destination MAC address of the native frame is a unicast address, these steps happen.
The Layer 2 destination address and VLAN get looked up in the ingress RBridge's database of MAC addresses and VLANs. This finds either the egress RBridge RBm, the local egress port, or tells us that the destination is the receiving RBridge or is unknown. One of these four cases will apply:
- If the destination is the receiving RBridge, the frame is processed locally.
- If the destination is known to be on the same link the native frame came in on, but it isn't the receiving RBridge, the RBridge silently discards the frame, since the destination should already have received it 🙄.
- If the destination is known to be on a different local link for which RBm is the appointed forwarder, then RB1 converts the native frame to a TRILL Data frame. The frame gets an
Outer.MacDAof the next hop RBridge towards RBm, a TRILL header withM = 0, an ingress nickname for RB1, and the egress nickname for RBm. If ingress RB1 has multiple nicknames, it SHOULD use the same nickname in the ingress nickname field every time it encapsulates a native frame from any particular source MAC address and VLAN. This makes end node learning simpler 🧸. If RBm is RB1, processing then carries on as in Section 4.6.2.4. Otherwise, theOuter.MacSAis set to the MAC address of the RB1 port on the path to the next hop RBridge towards RBm, and the frame is queued for transmission out of that port 🚀. - If a unicast destination MAC is unknown in the frame's VLAN, RB1 handles the frame as described in Section 4.6.1.2 for a broadcast frame. The only difference is that the
Inner.MacDAis the original native frame's unicast destination address 🕵️♀️.
4.6.1.2. Native Multicast and Broadcast Frames 📣
If the RBridge has multiple ports attached to the same link, all but one received copy of a native multicast or broadcast frame gets discarded to avoid duplication 🙅♀️. All the frames that belong to the same flow must be accepted on the same port to avoid re-ordering 🔁.
If the frame is a native IGMP [RFC3376], MLD [RFC2710], or MRD [RFC4286] frame, then RB1 SHOULD analyze it. It should learn any group membership or IP multicast router presence that's indicated, and announce that info for the appropriate VLAN in its LSP (see Section 4.7) 👀.
For all multi-destination native frames, RB1 forwards the frame in native form out to its links where it's the appointed forwarder for the frame's VLAN. This is still subject to further pruning and inhibition ✂️. RB1 also converts the native frame into a TRILL Data frame. That frame has the All-RBridges multicast address as Outer.MacDA, a TRILL header with the multi-destination bit M = 1, the ingress nickname for RB1, and the egress nickname for the distribution tree RB1 decides to use. Then it forwards the frame on the pruned distribution tree (see Section 4.5), setting the Outer.MacSA of each copy it sends to the MAC address of the RB1 port it goes out on 🌈.
By default, RB1 writes the egress nickname field with the nickname for a distribution tree. That tree comes from the set RB1 has announced it might use, and its root is the least cost from RB1 💫. RB1 MAY choose different distribution trees for different frames if RB1 has been configured to path-split multicast. In that case, RB1 MUST select a tree by specifying a nickname that is a distribution tree root (see Section 4.5). Also, RB1 MUST select a nickname that RB1 has announced (in RB1's own LSP) as one it might use. The strategy RB1 uses to pick distribution trees when multipathing multi-destination frames is beyond the scope of this document 🤷♀️.
4.6.2. Receipt of a TRILL Frame 🎀
A TRILL frame either has the TRILL or L2-IS-IS Ethertype, or it has a multicast Outer.MacDA allocated to TRILL (see Section 7.2) 🧁. The tests below run one at a time, in order, and the first one that matches decides what happens to the frame:
- If the
Outer.MacDAis All-IS-IS-RBridges and the Ethertype is L2-IS-IS, the frame is handled as described in Section 4.6.2.1. - If the
Outer.MacDAis a multicast address allocated to TRILL other than All-RBridges, the frame is discarded. - If the
Outer.MacDAis a unicast address other than the receiving Rbridge port MAC address, the frame is discarded. (Such discarded frames are most likely addressed to another RBridge on a multi-access link, and that other Rbridge will handle them 🤝.) - If the Ethertype is not TRILL, the frame is discarded.
- If the
Versionfield in the TRILL header is greater than 0, the frame is discarded. - If the hop count is 0, the frame is discarded.
- If the
Outer.MacDAis multicast and theMbit is zero, or if theOuter.MacDAis unicast and theMbit is one, the frame is discarded. - By default, an RBridge MUST NOT forward TRILL-encapsulated frames from a neighbor it doesn't have a TRILL IS-IS adjacency with 🚫. RBridges MAY be configured per port to accept these frames for forwarding, in cases where it's known that a non-peering device (such as an end station) is set up to originate TRILL-encapsulated frames that can be safely forwarded 🔐.
- The
Inner.MacDAis then tested. If it's the All-ESADI-RBridges multicast address and RBn implements the ESADI protocol, processing proceeds as in Section 4.6.2.2 below. If it's any other address, or RBn doesn't implement ESADI, processing proceeds as in Section 4.6.2.3 🌟.
4.6.2.1. TRILL Control Frames 🛠️
The frame is processed by the TRILL IS-IS instance on RBn and is not forwarded. Control frames stay home 🏠.
4.6.2.2. TRILL ESADI Frames 📬
If M == 0, the frame is silently discarded 🤫.
The egress nickname designates the distribution tree, and the frame is forwarded as described in Section 4.6.2.5. On top of that, if the forwarding Rbridge is an appointed forwarder for a link in the specified VLAN, implements the TRILL ESADI protocol, and has ESADI enabled for that VLAN, the inner frame gets decapsulated and handed to that local ESADI protocol 🎁.
4.6.2.3. TRILL Data Frames 📦
The M flag gets checked next. If it's zero, processing continues as described in Section 4.6.2.4. If it's one, processing continues as described in Section 4.6.2.5 🔀.
4.6.2.4. Known Unicast TRILL Data Frames 💖
The egress nickname in the TRILL header gets examined. If it's unknown or reserved, the frame is discarded 🙃.
If RBn is a transit RBridge, the hop count drops by one and the frame is forwarded to the next hop RBridge towards the egress RBridge 🛤️. (The provision that lets RBridges decrease the hop count by more than one in some circumstances (see Section 3.6) applies only to multi-destination frames, not to the known unicast frames we're looking at in this subsection.) A transit RBridge doesn't look at Inner.VLAN when it forwards a known unicast TRILL Data frame. For the forwarded frame, the Outer.MacSA is the MAC address of the transmitting port, the Outer.MacDA is the unicast address of the next hop RBridge, and the VLAN is the Designated VLAN on the link the frame is going out onto 🧭.
If RBn is not a transit RBridge, meaning the egress RBridge indicated is the RBridge doing the processing, then the Inner.MacSA and Inner.VLAN ID get learned by default as associated with the ingress nickname. That only happens if the nickname is unknown or reserved, or if the Inner.MacSA is not unicast, in which case they don't get learned. Then the frame gets decapsulated to native form, and these checks run:
- The
Inner.MacDAis checked. If it's not unicast, the frame is discarded. - If the
Inner.MacDAcorresponds to the RBridge doing the processing, the frame is delivered locally 🥳. - The
Inner.VLAN IDis checked. If it's0x0or0xFFF, the frame is discarded. - The
Inner.MacDAandInner.VLAN IDare looked up in RBn's local address cache. Then the frame is either sent onto the link that holds the destination, if the RBridge is the appointed forwarder for that link for the frame's VLAN and isn't inhibited (or it's discarded if it is inhibited), or it's processed as in one of the following two paragraphs 🧐.
A known unicast TRILL Data frame can reach the egress Rbridge only to find that the combination of Inner.MacDA and Inner.VLAN isn't actually known by that RBridge 😬. One way this can happen is if the address info timed out in the egress RBridge's MAC address cache. In that case, the egress RBridge sends the native frame out on all links in the frame's VLAN where the RBridge is the appointed forwarder and hasn't been inhibited. There's one exception: it MAY skip links where it knows there can't be an end station with the destination MAC address. For example, that happens when the link port is configured as a trunk (see Section 4.9.1) 🚧.
If, due to manual configuration or learning from Layer 2 registration, the destination MAC and VLAN show up in RBn's local address cache for two or more links where RBn is an uninhibited appointed forwarder for the frame's VLAN, RBn sends the native frame out on all of those links 📤✨.
4.6.2.5. Multi-Destination TRILL Data Frames
Okay so for multi-destination TRILL Data frames 🦋, the first thing you check is the egress and ingress nicknames in the TRILL header. If either one is unknown or reserved, the frame is discarded 💀.
Next, the Outer.MacSA gets checked. If it's not a tree adjacency for the tree that the egress RBridge nickname points to, on the port where the frame came in, the frame is discarded 🙅♀️. Then the Reverse Path Forwarding Check runs on the ingress and egress nicknames, and if that fails, the frame is discarded too. If there are multiple TRILL-Hello pseudonode suppressed parallel links to the previous hop RBridge, the frame is discarded if it arrived on the wrong one. And if the RBridge has multiple ports on that link, the frame is discarded unless it came in on the right one 🔍. For more on all these checks, see Section 4.5.2.
If the Inner.VLAN ID of the frame is 0x0 or 0xFFF, it's discarded. No vibes there 🚫.
If the RBridge is an appointed forwarder for the frame's Inner.VLAN ID, the Inner.MacSA and Inner.VLAN ID are learned by default as associated with the ingress nickname. The only exceptions are when that nickname is unknown or reserved, or when the Inner.MacSA is not unicast. After that, a copy of the frame is decapsulated and sent in native form on those links in its VLAN where the RBridge is the appointed forwarder 🎀. This is subject to extra pruning and inhibition as described in Section 4.2.4.3, and/or it gets processed locally, as appropriate.
The hop count goes down (possibly by more than one; see Section 3.6), and the frame is forwarded down the tree specified by the egress RBridge nickname, pruned as described in Section 4.5 🌳.
For the forwarded frame, the Outer.MacSA is set to the MAC of the port it's being sent out on, the Outer.MacDA is the All-RBridges multicast address, and the VLAN is the Designated VLAN of the link it's being transmitted on ✨.
4.6.3. Receipt of a Layer 2 Control Frame
Low-level control frames that an RBridge receives get handled right on the port where they came in, as described in Section 4.9 🧚.
There are two types of high-level control frames. They're told apart by their destination address, and each one gets handled as described in the section listed below 💜.
Name Section Destination Address
BPDU 4.9.3 01-80-C2-00-00-00
VRP 4.9.4 01-80-C2-00-00-214.7. IGMP, MLD, and MRD Learning
Ingress RBridges SHOULD learn, from native IGMP [RFC3376], MLD [RFC2710], and MRD [RFC4286] frames they receive in VLANs where they're an uninhibited appointed forwarder, which IP-derived multicast messages should be forwarded onto which links 👀. These frames also usually get encapsulated as TRILL Data frames and distributed as described below and in Section 4.5 📦.
An IGMP or MLD membership report received in native form from a link tells you there's a multicast group listener for that group on that link 🎧. An IGMP or MLD query, or an MRD advertisement, received in native form from a link means there's an IP multicast router on that link 📡.
IP multicast group membership reports have to be sent throughout the campus and delivered to all IP multicast routers, with IPv4 and IPv6 kept separate 🗺️. All IP-derived multicast traffic must also be sent to all IP multicast routers for the same version of IP.
IP multicast data SHOULD only be sent on links where there's either an IP multicast router for that IP type (IPv4 or IPv6) or an IP multicast group listener for that IP-derived multicast MAC address. The exception is when the IP multicast address is in the range that has to be treated as broadcast 📢.
RBridges don't need to announce themselves as listeners to the IPv4 All-Snoopers multicast group (the group used for MRD reports [RFC4286]). That's because the IPv4 multicast address for that group is in the range where every frame sent to that address must be broadcast (see [RFC4541], Section 2.1.2) 🙌. However, RBridges that are doing IPv6-derived multicast optimization MUST announce themselves as listeners to the IPv6 All-Snoopers multicast group 🔥.
See also "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches" [RFC4541] 📚.
4.8. End-Station Address Details
RBridges have to learn the MAC addresses and VLANs of their locally attached end stations, for link/VLAN pairs where they're the appointed forwarder 🏠. Learning this lets them do the following:
- Forward the native form of incoming known unicast TRILL Data frames onto the correct link 🎯.
- Decide, for an incoming native unicast frame from a link where the RBridge is the appointed forwarder for the frame's VLAN, whether the frame is:
- known to have been destined for another end station on the same link, so the RBridge needs to do nothing 😌, or
- has to be converted to a TRILL Data frame and forwarded 🚀.
RBridges need to learn the MAC addresses, VLANs, and remote RBridges of remotely attached end stations, for VLANs where they and the remote RBridge are both appointed forwarders. That way they can send native unicast frames to those addresses and VLANs efficiently 💨.
4.8.1. Learning End-Station Addresses
There are five independent ways an RBridge can learn end-station addresses 🧠:
- From observing VLAN-x frames received on ports where it's the appointed VLAN-x forwarder, learning the
{ source MAC, VLAN, port }triplet of received frames. - The
{ source MAC, VLAN, ingress RBridge nickname }triplet of any native frames it decapsulates. - Through Layer 2 registration protocols, learning the
{ source MAC, VLAN, port }of end stations registering at a local port. - By running the TRILL ESADI protocol for one or more VLANs, and thereby receiving remote address information and/or transmitting local address information.
- Through management configuration.
RBridges MUST implement capabilities 1 and 2 above. RBridges use these capabilities unless they're configured, for one or more particular VLANs and/or ports, not to learn from received frames, from decapsulating native frames to be transmitted, or from both 🙅♀️.
RBridges MAY implement capabilities 3 and 4 above. If capability 4 is implemented, the ESADI protocol only runs when the RBridge is configured to do so on a per-VLAN basis 🧩.
RBridges SHOULD implement capability 5 💖.
Entries in the table of learned MAC and VLAN addresses, and their associated info, also each have a one-octet unsigned confidence level. The reasoning behind it is explained below 🍓. Info learned from observing data gets a confidence of 0x20, unless it's configured to have a different one. This confidence level can be set per RBridge, separately for info learned from local native frames and info learned from remotely originated encapsulated frames. Info received through the TRILL ESADI protocol comes with a confidence level in the range 0 to 254. Info configured by management defaults to a confidence level of 255, but it can be configured to another value 🌸.
The table of learned MAC addresses includes (1) { confidence, VLAN, MAC address, local port } for addresses learned from local native frames and local registration protocols, (2) { confidence, VLAN, MAC address, egress RBridge nickname } for addresses learned from remote encapsulated frames and ESADI link state databases, and (3) extra info to handle timing out of learned addresses, statically configured addresses, and the like ⏰.
When new address info learned from observing data frames is going into the local database, there are three possibilities 🤔:
A. If this is a new { address, VLAN } pair, the info goes in along with its confidence level.
B. If there's already an entry for this { address, VLAN } pair with the same accompanying delivery information, the confidence level in the local database is set to the maximum of its existing confidence level and the confidence it's being learned with. Also, if the info is being learned with the same or a higher confidence than the existing one, the timer info gets reset ⏱️.
C. If there's already an entry for this { address, VLAN } pair with different information, the new info only replaces the older info if it's being learned with higher or equal confidence than the database entry. If it does replace the older info, the timer info gets reset too 🔄.
4.8.2. Learning Confidence Level Rationale
The confidence level mechanism lets an RBridge campus manager make certain address learning sources win out over others 👑. In a default configuration, without the optional ESADI protocol, addresses are only learned from observing local native frames and from decapsulating received TRILL Data frames. Both of these sources default to confidence level 0x20. Since learning at an equal or higher confidence overrides previous learning, the learning in this default case copies default 802.1 bridge learning 🥰.
RBridge campus management policies are beyond the scope of this document 🙈, but here are some example types of policies you can build with the confidence mechanism, plus the reasoning for each:
- Locally received native frames might be seen as more reliable than decapsulated frames from remote parts of the campus. To stop MAC addresses learned from those local frames from getting usurped by forged frames arriving remotely, the confidence in locally learned addresses could be raised, or the confidence in addresses learned from remotely sourced decapsulated frames could be lowered 🛡️.
- MAC address info learned through a cryptographically authenticated Layer 2 registration protocol, such as 802.1X with a cryptographically based EAP method, might be seen as more reliable than info learned just by observing data frames 🔐. When that authenticated address info is sent via the ESADI protocol, the authentication in the TRILL ESADI LSP frames can make tampering with it in transit very difficult. So it might make sense to announce that authenticated info via ESADI with a high confidence, so it overrides any other learning from data observation 💪.
Manually configured address info is generally treated as static, so it defaults to a confidence of 0xFF. No other source of this info can be configured to a confidence any higher than 0xFE 🫶. But for other cases, like when the manual configuration is just a starting point that the RBridge campus manager wants to be dynamically overridable, the confidence of that manually configured info may be set to a lower value ✨.
4.8.3. Forgetting End-Station Addresses ✨
okay so RBridges need to learn end-station addresses (we just covered that 💅), but being able to forget them is just as important, bestie 🫶 Otherwise, frames for end stations that have moved to a different part of the campus could get black-holed forever by RBridges still holding stale info about which link that end station is attached to 😭
For end-station address info learned locally from received frames, the timeout counts from the last time a native frame was received or decapsulated with that info, and it follows the recommendations of [802.1D] 🎀. It's called the "Ageing Time." It's configurable per RBridge from 10 seconds to 1,000,000 seconds, and the default is 300 seconds ⏰.
ESADI-acquired info is a different story 🦋 The originating RBridge decides when to remove it from its ESADI LSPs (or the ESADI protocol timeouts take over if the originating RBridge becomes inaccessible).
When an RBridge stops being appointed forwarder for VLAN-x on a port, it forgets all the end-station address info it learned from observing VLAN-x native frames received on that port. It also bumps a per-VLAN counter that tracks how many times it lost appointed forwarder status on one of its ports for that VLAN 📈.
When, for all of its ports, RBridge RBn is no longer appointed forwarder for VLAN-x, it forgets all end-station address info learned from decapsulating VLAN-x native frames. If RBn is participating in the TRILL ESADI protocol for VLAN-x, it stops participating after sending a final LSP that nulls out the end-station address info for that VLAN. Also, all other RBridges that are VLAN-x forwarder on at least one of their ports notice that RBn's link state data has changed to show it no longer has a link on VLAN-x. In response, they forget all end-station address info they've learned from decapsulating VLAN-x frames that show RBn as the ingress RBridge 🧚
When the appointed forwarder lost counter for RBridge RBn for VLAN-x is observed to increase via the TRILL IS-IS link state database, but RBn continues to be an appointed forwarder for VLAN-x on at least one of its ports, every other RBridge that is an appointed forwarder for VLAN-x modifies the aging of all the addresses it has learned by decapsulating native frames in VLAN-x from ingress RBridge RBn. The time remaining for each entry is adjusted to be no larger than a per-RBridge configuration parameter called (to correspond to [802.1D]) "Forward Delay." It ranges from 4 to 30 seconds, with a default of 15 seconds 🌸
4.8.4. Shared VLAN Learning
RBridges can map VLAN IDs into a smaller number of identifiers for learning purposes, just like [802.1Q-2005] bridges can 🍓 Then, when they look up learned address info, they match on this identifier instead of the VLAN ID. If the ID of the VLAN the address was learned on isn't retained, here's what happens:
- The RBridge no longer has the info it needs to participate in the TRILL ESADI protocol for the VLANs whose ID isn't being retained.
- In cases where Section 4.8.3 above requires discarding learned address info based on a particular VLAN, but the VLAN ID isn't available for entries under a shared VLAN identifier, the time remaining for each entry under that shared VLAN identifier is adjusted to be no longer than the RBridge's "Forward Delay" instead.
Although this is outside the scope of this specification, some Layer 2 features have a set of VLANs sharing learning, where one VLAN is the "primary" and the others in the group are "secondaries" 👑 An example is when traffic from different communities is separated using VLAN tags, yet some resource (such as an IP router or DHCP server) is shared by all the communities. One way to do this is to give a VLAN tag, say, Z, to a link containing the shared resource, and have the other VLANs, say, A, C, and D, be part of the group { primary = Z, secondaries = A, C, D }. An RBridge that knows about this grouping and is attached to one of the secondary VLANs in the group also claims to be attached to the primary VLAN. So an RBridge attached to A would claim to also be attached to Z. An RBridge attached to the primary would claim to be attached to all the VLANs in the group 🌈
This document does not specify how VLAN groups might be used. Only RBridges that participate in a VLAN group will be configured to know about the VLAN group. However, to detect misconfiguration, an RBridge configured to know about a VLAN group SHOULD report the VLAN group in its LSP 🔥
4.9. RBridge Ports
Section 4.9.1 below describes the several RBridge port configuration bits, Section 4.9.2 gives a logical port structure in terms of frame processing, and Sections 4.9.3 and 4.9.4 describe the handling of high-level control frames 💜
4.9.1. RBridge Port Configuration
There are four per-port configuration bits, bestie 🦋
- Disable port bit. When this bit is set, all frames received or to be transmitted are discarded, with the possible exception of some Layer 2 control frames (see Section 1.4) that may be generated and transmitted or received and processed within the port. By default, ports are enabled.
- End-station service disable (trunk port) bit. When this bit is set, all native frames received on the port and all native frames that would have been sent on the port are discarded. (See Appendix B.) (Note that, for this document, "native frames" does not include Layer 2 control frames.) By default, ports are not restricted to being trunk ports.
If a port with end-station service disabled reports, in a TRILL-Hello frame it sends out that port, which VLANs it provides end-station support for, it reports that there are none. 🙈
- TRILL traffic disable (access port) bit. If this bit is set, the goal is to avoid sending any TRILL frames, except TRILL-Hello frames, on the port, since it's intended only for native end-station traffic. By default, ports are not restricted to being access ports. This bit is reported in TRILL-Hello frames. If RB1 is the DRB and has this bit set in its TRILL-Hello, the DRB still appoints VLAN forwarders. However, usually no pseudonode is reported, and none of the inter-RBridge links associated with that link are reported in LSPs.
If the DRB RB1 does not have this bit set, but neighbor RB2 on the link does have the bit set, then RB1 does not appoint RB2 as appointed forwarder for any VLAN, and none of the RBridges (including the pseudonode) report RB2 as a neighbor in LSPs.
In some cases, even though the DRB has the "access port" flag set, the DRB MAY choose to create a pseudonode for the access port. In this case, the other RBridges report connectivity to the pseudonode in their LSP, but the DRB sets the "overload" flag in the pseudonode LSP. 💀
- Use P2P Hellos bit. If this bit is set, Hellos sent on this port are IS-IS P2P Hellos. By default, TRILL-Hellos are used. See Section 4.2.4.1 for more information on P2P links. 🍓
The dominance relationship of these four configuration bits is as follows, where configuration bits to the left dominate those to the right. That is to say, when any pair of bits is asserted, inconsistencies in behavior they mandate are resolved in favor of behavior mandated by the bit to the left of the other bit in this list. periodt 💅
Disable > P2P > Access > Trunk4.9.2. RBridge Port Structure 🎀
okay so an RBridge port can be modeled as having a lower-level structure that's basically like an [802.1Q-2005] bridge port, see Figure 11 🧚 in the diagram, double lines show the general flow of frames and info, and single lines show info flow only. the dashed lines around VRP (GVRP/MVRP) are there to show that VRP support is optional 💅 and an actual RBridge port can be built in any way that gives the correct behavior ✨
+----------------------------------------------
| RBridge
|
| Interport Forwarding, IS-IS. Management, ...
|
+----++----------------------+-------------++--
|| | ||
TRILL || Data | ||
|| +--+---------+ ||
+-------------++-----+ | TRILL | ||
| Encapsulation | +------+ IS-IS Hello| ||
| Decapsulation | | | Processing | ||
| Processing | | +-----++-----+ ||
+--------------------+ | || ||
| RBridge Appointed +------+ || ||
+---+ Forwarder and | || ||
| | Inhibition Logic +==============\\ || //====++
| +---------+--------+-+ Native \\ ++ //
| | | Frames \++/
| | | ||
+----+-----+ +- - + - - + | ||
| RBridge | | RBridge | | || All TRILL and
| BPDU | | VRP | | || Native Frames
|Processing| |Processing| | ||
+-----++---+ + - - -+- -+ | +--------++--+ <- EISS
|| | | | 802.1Q |
|| | | | Port VLAN |
|| | | |and Priority|
|| | | | Processing |
+---++------------++------+------------+------------+ <-- ISS
| 802.1/802.3 Low-Level Control Frame |
| Processing, Port/Link Control Logic |
+------------++-------------------------------------+
||
|| +------------+
|| | 802.3 PHY |
++========+ (Physical +======== 802.3
| Interface) | Link
+------------+Figure 11: Detailed RBridge Port Model
low-level control frames get handled in the lower-level port/link control logic, same way as in an [802.1Q-2005] bridge port 🌸 this can optionally cover a bunch of 802.1 or link-specific stuff like PAUSE (Annex 31B of [802.3]), link layer discovery [802.1AB], link aggregation [802.1AX], MAC security [802.1AE], or port-based access control [802.1X] 🔥 even though they're handled at a low level, these frames can still mess with higher-level processing. like, a Layer 2 registration protocol can affect how confident the RBridge is in learned addresses 👀 and the upper interface to this low-level port control logic is the Internal Sublayer Service (ISS) in [802.1Q-2005] 🦋
high-level control frames (BPDUs and, if supported, VRP frames) are not VLAN tagged 🫶 they do go through the ISS interface, but they're not subject to port VLAN processing. behavior on receipt of a VLAN tagged BPDU or a VLAN tagged VRP frame is unspecified, so that's a no-go zone 🙈 and if VRP isn't implemented, then all VRP frames get discarded. BPDU handling is in Section 4.9.3 and VRP frame handling is in Section 4.9.4 💜
frames other than Layer 2 control frames (so all TRILL and native frames) go through port VLAN and priority processing, which is the same as for an [802.1Q-2005] bridge. the upper interface to that processing is the Extended Internal Sublayer Service (EISS) in [802.1Q-2005] ✨
in this model, RBridge port processing below the EISS layer is identical to an [802.1Q-2005] bridge with just two exceptions: (1) the handling of high-level control frames, and (2) discarding frames that have exceeded the Maximum Transit Delay is not mandatory but MAY be done 🌈
so the vibe for native frames is: incoming native frames are only accepted if the RBridge is an uninhibited appointed forwarder for the frame's VLAN, and then they're usually encapsulated and forwarded 🍓 outgoing native frames are usually obtained by decapsulation, and they only get output if the RBridge is an uninhibited appointed forwarder for the frame's VLAN 💅
TRILL-Hellos, MTU-probes, and MTU-acks are handled per port 🧚 and just like all TRILL IS-IS frames, they're never forwarded. they can affect the appointed forwarder and inhibition logic, and they can also affect the RBridge's LSP 💖
except for TRILL-Hellos, MTU-probes, and MTU-acks, all TRILL control frames, TRILL data frames, and ESADI frames get passed up to higher-level RBridge processing on receipt and passed down for transmission on creation or forwarding 🦋 these are never blocked because of the appointed forwarder and inhibition logic, since that logic only affects native frames 😭 but some of them do have extra filters, like the Reverse Path Forwarding Check 🔥
4.9.3. BPDU Handling 🌸
if the RBridge campus topology were static, RBridges would just be end stations from a bridging perspective, terminating but not otherwise interacting with spanning tree 💅 however, there are reasons for RBridges to listen to BPDUs and sometimes to transmit them, as described below ✨ even when RBridges do listen to and transmit BPDUs, that's a local RBridge port activity. the ports of a particular RBridge never interact in a way that makes the RBridge as a whole a spanning tree node, so it's giving "every port for itself" 👑
4.9.3.1. Receipt of BPDUs 🎀
Rbridges MUST listen to spanning tree configuration BPDUs received on a port and keep track of the root bridge, if any, on that link 🫶 if MSTP is running on the link, this is the CIST root. this info gets reported per VLAN by the RBridge in its LSP, and it may be used as described in Section 4.2.4.3 💜 also, receiving spanning tree configuration BPDUs is used as an indication that a link is a bridged LAN, and that can affect how the RBridge transmits BPDUs 🧚
An RBridge MUST NOT encapsulate or forward any BPDU frame it receives. never, ever, not once 🙅♀️
RBridges discard any topology change BPDUs they receive, but peep Section 4.9.3.3 🦋
4.9.3.2. Root Bridge Changes 🌈
okay this one is a lot. a change in the root bridge seen in spanning tree BPDUs received at an RBridge port may mean the bridged LAN topology has changed, including the possibility of two bridged LANs merging or something like that 😳 and it can happen with no physical indication at the port at all. during topology transients, bridges may go into pre-forwarding states that block TRILL-Hello frames 🌸 so for these reasons, when an RBridge sees a root bridge change on a port where it's appointed forwarder for one or more VLANs, it gets inhibited for a period of time between zero and 30 seconds 💀 (an inhibited appointed forwarder discards all native frames received from the link, or that it would otherwise have sent to the link.) this time period is configurable per port and defaults to 30 seconds ⭐
for example, picture two bridged LANs carrying multiple VLANs, each with various RBridge appointed forwarders 🍓 if they get merged, say because a cable got plugged in or whatever, the RBridges attached to the original bridged LAN with the lower priority root will see a root bridge change, while the ones attached to the other original bridged LAN won't. so all the appointed forwarders in the lower priority set get inhibited for a while, until BPDUs inside the merged bridged LAN and TRILL-Hello frames between the involved RBridges sort things out 🫶
4.9.3.3. Transmission of BPDUs 💅
when an RBridge stops being appointed forwarder for one or more VLANs out a particular port, it SHOULD, as long as it keeps receiving spanning tree BPDUs on that port, send topology change BPDUs until it sees the topology change acknowledged in a spanning tree configuration BPDU ✨
RBridges MAY support a capability for sending spanning tree BPDUs to try to force a bridged LAN to partition, as discussed in Appendix A.3.3 🧚 (that's a fun one, iykyk 😏)
4.9.4. Dynamic VLAN Registration 🦋
dynamic VLAN registration is how bridges (and less commonly end stations) can ask for VLANs to be enabled or disabled on ports leading to the requestor 💖 this happens through VLAN registration protocol (VRP) frames, which are GVRP or MVRP. RBridges MAY implement GVRP and/or MVRP as described below 🌈
VRP frames are never encapsulated as TRILL frames between RBridges, and they're never forwarded in native form by an RBridge 🙈 if an RBridge doesn't implement a VRP, it discards any VRP frames it receives and sends none 🔥
RBridge ports may have dynamically enabled VLANs 🌸 if an RBridge supports a VRP, the actual enablement of dynamic VLANs is determined by the GVRP/MVRP frames received at the port, the same way it would be for an [802.1Q-2005] / [802.1ak] bridge 💅
an RBridge that supports a VRP sends GVRP/MVRP frames the way an [802.1Q-2005] / [802.1ak] bridge would, on each port that isn't configured as an RBridge trunk port or P2P port ✨ for this purpose, it sends VRP frames to request traffic in the VLANs it's appointed forwarder for and in the Designated VLAN (unless the Designated VLAN is disabled on the port), and it doesn't request traffic in any other VLAN 👑
5. RBridge Parameters 💜
this section lists parameters for RBridges 🧚 it's expected that the TRILL MIB will include many of the items listed here, plus extra RBridge status and data, including traffic and error counts 📊
the default value and range are given for parameters added by TRILL 🍓 where a parameter is defined as a 16-bit unsigned integer and no explicit maximum is given, that maximum is 2**16-1 🌈 for parameters imported from [802.1Q-2005], [802.1D], or IS-IS [ISO10589] [RFC1195], see those standards for default and range if they aren't given here 🫶
5.1. Per RBridge ✨
okay so these are the settings that live on the whole RBridge, not on any one port 💅 here's the lineup:
- Number of nicknames, which defaults to
1and may be configured in the range of1to256. - The desired number of distribution trees to be calculated by every RBridge in the campus and a desired number of distribution trees for the advertising RBridge to use, both of which are unsigned 16-bit integers that default to
1(see Section 4.5). 🌸 - The maximum number of distribution trees the RBridge can compute. This is a 16-bit unsigned integer that is implementation and environment dependent and not subject to management configuration.
- Two lists of nicknames, one designating the distribution trees to be computed and one designating distribution trees to be used as discussed in Section 4.5. By default, these lists are empty.
- The parameters Ageing Timer and Forward Delay with the default and range specified in [802.1Q-2005].
- Two unsigned octets that are, respectively, the confidence in
{ MAC, VLAN, local port }triples learned from locally received native frames and the confidence in{ MAC, VLAN, remote RBridge }triples learned from decapsulating frames. These each default to0x20and may each be configured to values from0x00to0xFE. 🦋 - The desired minimum acceptable inter-RBridge link MTU for the campus, that is,
originatingLSPBufferSize. This is a 16-bit unsigned integer number of octets that defaults to1470bytes, which is the minimum valid value. Any lower value being advertised by an RBridge is ignored. 🎀 - The number of failed MTU-probes before the RBridge concludes that a particular MTU is not supported, which defaults to
3and may be configured between1and255.
Static end-station address information and confidence in such end station information statically configured can also be configured with a default confidence of 0xFF and range of 0x00 to 0xFF. By default, there is no such static address information. The quantity of such information that can be configured is implementation dependent. 🧚
5.2. Per Nickname Per RBridge
the following is the config info per nickname at each RBridge 🍓
- Priority to hold the nickname, which defaults to
0x40if no specific value has been configured or0xC0if it is configured (see Section 3.7.3). - Nickname priority to be selected as a distribution tree root, a 16-bit unsigned integer that defaults to
0x8000. - Nickname value, an unsigned 16-bit quantity that defaults to the configured value if configured, else to the last value held if the RBridge coming up after a reboot and that value is remembered, else to a random value; however, in all cases the reserved values
0x0000and0xFFC0through0xFFFFare excluded (see Section 3.7.3). 💜
5.3. Per Port Per RBridge
an RBridge has the following per-port config parameters, and this list is a lot 😭
- The same parameters as an [802.1Q-2005] port in terms of C-VLAN IDs. In addition, there is an Announcing VLANs set that defaults to the enabled VLANs on the port (see Section 4.4.3) and ranges from the null set to the set of all legal VLAN IDs.
- The same parameters as an [802.1Q-2005] port in terms of frame priority code point mapping (see [802.1Q-2005]).
- The inhibition time for the port when it observed a change in the root bridge of an attached bridged LAN. This is in units of seconds, defaults to
30, and can be configured to any value from0to30. - The Desired Designated VLAN that the RBridge will advertise in its TRILL Hellos if it is the DRB for the link via that port. This defaults to the lowest VLAN ID enabled on the port and may be configured to any valid VLAN ID that is enabled on the port (
0x001through0xFFE). 🌈 - Four per-port configuration bits: disable port (default
0== enabled), disable end-station service (trunk, default0== enabled), access port (default0== not restricted to being an access port), and use P2P Hellos (default0== use TRILL Hellos). (See Section 4.9.1.) - One bit per port such that, if the bit is set, it disables learning
{ MAC address, VLAN, port }triples from locally received native frames on the port. Default value is0== learning enabled. - The priority of the RBridge to be DRB and its Holding Time via that port with defaults and range as specified in IS-IS [ISO10589] [RFC1195].
- A bit that, when set, enables the receipt of TRILL-encapsulated frames from an
Outer.MacSAwith which the RBridges does not have an IS-IS adjacency. Default value is0== disabled. 🫶 - Configuration for the optional send-BPDUs solution to the wiring closet topology problem as described in Appendix A.3.3. Default Bridge Address is the System ID of the RBridge with the lowest System ID. If
RB1andRB2are part of a wiring closet topology, both need to be configured to know about this, and know the ID that should be used in the spanning tree protocol on the specified port. ✨
5.4. Per VLAN Per RBridge
an RBridge also has these per-VLAN config parameters 👑
- Per-VLAN ESADI protocol participation flag, 7-bit priority, and Holding Time. Default participation flag is
0== not participating. Default and range of priority and Holding Time as specified in IS-IS [ISO10589] [RFC1195]. - One bit per VLAN that, if set, disables learning
{ MAC address, VLAN, remote RBridge }triples from frames decapsulated in the VLAN. Defaults to0== learning enabled.
6. Security Considerations ✨
okay this section is serious, so read it properly 🙈
Layer 2 bridging is not inherently secure. It is, for example, subject to spoofing of source addresses and bridging control messages. A goal for TRILL is that RBridges do not add new issues beyond those existing in current bridging technology.
countermeasures are available, like configuring the TRILL IS-IS and ESADI protocols to use IS-IS security [RFC5304] [RFC5310] and ignoring unauthenticated TRILL control and ESADI frames that get received. RBridges using IS-IS security will need configuration. 🔥
IEEE 802.1 port admission and link security mechanisms, such as [802.1X] and [802.1AE], can also be used. These are best thought of as being implemented below TRILL (see Section 4.9.2) and are outside the scope of TRILL (just as they are generally out of scope for bridging standards [802.1D] and 802.1Q); however, TRILL can make use of secure registration through the confidence level communicated in the optional TRILL ESADI protocol (see Section 4.8). 🦋
TRILL encapsulates native frames inside the RBridge campus while they are in transit between ingress RBridge and egress RBridge(s) as described in Sections 2.3 and 4.1. Thus, TRILL ignorant devices with firewall features that cannot be detected by RBridges as end stations will generally not be able to inspect the content of such frames for security checking purposes. This may render them ineffective. Layer 3 routers and hosts appear to RBridges to be end stations, and native frames will be decapsulated before being sent to such devices. Thus, they will not see the TRILL Ethertype. Firewall devices that do not appear to an RBridge to be an end station, for example, bridges with co-located firewalls, should be modified to understand TRILL encapsulation. 💀
RBridges do not prevent nodes from impersonating other nodes, for instance, by issuing bogus ARP/ND replies. However, RBridges do not interfere with any schemes that would secure neighbor discovery. 🧚
6.1. VLAN Security Considerations
TRILL supports VLANs. These provide logical separation of traffic, but care should be taken in using VLANs for security purposes. To have reasonable assurance of such separation, all the RBridges and links (including bridged LANs) in a campus must be secured and configured so as to prohibit end stations from using dynamic VLAN registration frames or otherwise gaining access to any VLAN carrying traffic for which they are not authorized to read and/or inject. 🌸
Furthermore, if VLANs were used to keep some information off links where it might be observed in a bridged LAN, this will no longer work, in general, when bridges are replaced with RBridges; with encapsulation and a different outer VLAN tag, the data will travel the least cost transit path regardless of VLAN. Appropriate counter measures are to use end-to-end encryption or an appropriate TRILL security option should one be specified. 🔐
6.2. BPDU/Hello Denial-of-Service Considerations
the TRILL protocol requires that an appointed forwarder at an RBridge port be temporarily inhibited if it sees a TRILL-Hello from another RBridge claiming to be the appointed forwarder for the same VLAN or sees a root bridge change out that port. Thus, it would seem that forged BPDUs showing repeated root bridge changes and forged TRILL-Hello frames with the Appointed Forwarder flag set could represent a significant denial-of-service attack. However, the situation is not as bad as it seems. 😱
the best defense against forged TRILL-Hello frames or other IS-IS messages is the use of IS-IS security [RFC5304] [RFC5310]. Rogue end stations would not normally have access to the required IS-IS keying material needed to forge authenticatible messages. 🔑
authentication similar to IS-IS security is usually unavailable for BPDUs. However, it is also the case that in typical modern wired LANs, all the links are point-to-point. If you have an all-RBridged point-to-point campus, then the worst that an end-station can do by forging BPDUs or TRILL-Hello frames is to deny itself service. This could be either through falsely inhibiting the forwarding of native frames by the RBridge to which it is connected or by falsely activating the optional decapsulation check (see Section 4.2.4.3). 🙃
however, when an RBridge campus contains bridged LANs, those bridged LANs appear to any connected RBridges to be multi-access links. The forging of BPDUs by an end-station attached to such a bridged LAN could affect service to other end-stations attached to the same bridged LAN. Note that bridges never forward BPDUs but process them, although this processing may result in the issuance of further BPDUs. Thus, for an end-station to forge BPDUs to cause continuing changes in the root bridge as seen by an RBridge through intervening bridges would typically require it to cause root bridge thrashing throughout the bridged LAN that would be disruptive even in the absence of RBridges. 🚨
some bridges can be configured to not send BPDUs and/or to ignore BPDUs on particular ports, and RBridges can be configured not to inhibit appointed forwarding on a port due to root bridge changes; however, such configuration should be used with caution as it can be unsafe. ⚠️
7. Assignment Considerations
this section discusses IANA and IEEE 802 assignment considerations. See [RFC5226]. 🎀
7.1. IANA Considerations ✨
okay bestie so IANA gets a brand new registry called TRILL Parameters 🎀, and it has two subregistries inside it 🧚. Here's how the first one starts out:
The TRILL Nicknames subregistry starts out like this 💅:
0x0000 Reserved to indicate no nickname specified
0x0001-0xFFBF Dynamically allocated by the RBridges within each
RBridge campus
0xFFC0-0xFFFE Available for allocation by RFC Required (single
value) or IETF Review (single or multiple values)
0xFFFF Permanently reservedAnd the TRILL Multicast Address subregistry starts like this 🦋:
01-80-C2-00-00-40 Assigned as All-RBridges
01-80-C2-00-00-41 Assigned as All-IS-IS-RBridges
01-80-C2-00-00-42 Assigned as All-ESADI-RBridges
01-80-C2-00-00-43 to 01-80-C2-00-00-4F Available for allocation
by IETF Review7.2. IEEE Registration Authority Considerations 🫶
so the IEEE Registration Authority is the one doing the assigning here 👑. Ethertype 0x22F3 goes to the TRILL Protocol 💜, and Ethertype 0x22F4 goes to L2-IS-IS 🌈. On top of that, the IEEE Registration Authority assigns the block of 16 multicast MAC addresses from <01-80-C2-00-00-40> to <01-80-C2-00-00-4F> for IETF TRILL protocol use 🔥.
8. Normative References 📚
these are the must-read sources that the spec leans on, so here they all are, complete and unedited 🍓:
[802.1ak] "IEEE Standard for Local and metropolitan area networks /
Virtual Bridged Local Area Networks / Multiple
Registration Protocol", IEEE Standard 802.1ak-2007, 22
June 2007.
[802.1D] "IEEE Standard for Local and metropolitan area networks /
Media Access Control (MAC) Bridges", 802.1D-2004, 9 June
2004.
[802.1Q-2005]
"IEEE Standard for Local and metropolitan area networks /
Virtual Bridged Local Area Networks", 802.1Q-2005, 19 May
2006.
[802.3] "IEEE Standard for Information technology /
Telecommunications and information exchange between
systems / Local and metropolitan area networks / Specific
requirements Part 3: Carrier sense multiple access with
collision detection (CSMA/CD) access method and physical
layer specifications", 802.3-2008, 26 December 2008.
[ISO10589] ISO/IEC, "Intermediate system to Intermediate system
routeing information exchange protocol for use in
conjunction with the Protocol for providing the
Connectionless-mode Network Service (ISO 8473)", ISO/IEC
10589:2002.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October
1999.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3417] Presuhn, R., Ed., "Transport Mappings for the Simple
Network Management Protocol (SNMP)", STD 62, RFC 3417,
December 2002.
[RFC3419] Daniele, M. and J. Schoenwaelder, "Textual Conventions for
Transport Addresses", RFC 3419, December 2002.
[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery",
RFC 4286, December 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5303] Katz, D., Saluja, R., and D. Eastlake 3rd, "Three-Way
Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303,
October 2008.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, October 2008.
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2
Systems", RFC 6165, April 2011.
[RFC6326] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A.
Ghanwani, "Transparent Interconnection of Lots of Links
(TRILL) Use of IS-IS", RFC 6326, July 2011.9. Informative References 🔥
these ones are the extra-helpful background reads, not strictly required but so good to know 🧠:
[802.1AB] "IEEE Standard for Local and Metropolitan Networks /
Station and Media Access Control Connectivity Discovery",
802.1AB-2009, 17 September 2009.
[802.1ad] "IEEE Standard for and metropolitan area networks /
Virtual Bridged Local Area Networks / Provider Bridges",
802.1ad-2005, 26 May 2005.
[802.1ah] "IEEE Standard for Local and Metropolitan Area Networks /
Virtual Bridged Local Area Networks / Provider Backbone
Bridges", 802.1ah-2008, 1 January 2008.
[802.1aj] Virtual Bridged Local Area Networks / Two-Port Media
Access Control (MAC) Relay, 802.1aj Draft 4.2, 24
September 2009.
[802.1AE] "IEEE Standard for Local and metropolitan area networks /
Media Access Control (MAC) Security", 802.1AE-2006, 18
August 2006.
[802.1AX] "IEEE Standard for Local and metropolitan area networks /
Link Aggregation", 802.1AX-2008, 1 January 2008.
[802.1X] "IEEE Standard for Local and metropolitan area networks /
Port Based Network Access Control", 802.1X-REV Draft 2.9,
3 September 2008.
[RBridges] Perlman, R., "RBridges: Transparent Routing", Proc.
Infocom 2005, March 2004.
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
June 2005.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, May 2006.
[RFC4789] Schoenwaelder, J. and T. Jeffree, "Simple Network
Management Protocol (SNMP) over IEEE 802 Networks", RFC
4789, November 2006.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, October 2008.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, February 2009.
[RFC5342] Eastlake 3rd, D., "IANA Considerations and IETF Protocol
Usage for IEEE 802 Parameters", BCP 141, RFC 5342,
September 2008.
[RFC5556] Touch, J. and R. Perlman, "Transparent Interconnection of
Lots of Links (TRILL): Problem and Applicability
Statement", RFC 5556, May 2009.
[RP1999] Perlman, R., "Interconnection: Bridges, Routers, Switches,
and Internetworking Protocols, 2nd Edition", Addison
Wesley Longman, Chapter 3, 1999.
[VLAN-MAPPING]
Perlman, R., Dutt, D., Banerjee, A., Rijhsinghani, A., and
D. Eastlake 3rd, "RBridges: Campus VLAN and Priority
Regions", Work in Progress, April 2011.Appendix A. Incremental Deployment Considerations 🌸
okay so this appendix is all about what happens when you only partly roll out RBridges 🧚. It covers link cost determination (that's Appendix A.1 👇), plus possible congestion from appointed forwarder bottlenecks (that's Appendix A.2 💅). There's also a specific problem with the TRILL habit of using one appointed forwarder per link per VLAN, called the "wiring closet topology", and that one gets its own deep dive in Appendix A.3 🫶.
A.1. Link Cost Determination 💖
so if your RBridged campus has no bridges or repeaters sitting on the links between RBridges, the RBridges can accurately work out how many physical hops a path has and the line speed of each hop 🔥. That only works if the port logic reports the speed, though. Once there are intervening devices in the way, that stops being possible 🙈. Take Figure 12 🦋: bridges B1 and B2 can completely hide a slow link, so both RB1 and RB2 wrongly think the link is fast 😭.
+-----+ +----+ +----+ +-----+
| | Fast | | Slow | | Fast | |
| RB1 +--------+ B1 +--------+ B2 +--------+ RB2 |
| | Link | | Link | | Link | |
+-----+ +----+ +----+ +-----+
Figure 12: Link Cost of a Bridged Linkeven with just one bridge in between, two RBridges can know they're connected but each one sees the link as a different speed than the other does 💀.
this isn't just an RBridge problem though 🌈. Bridges can run into the same kind of thing because of links hidden by repeaters, and routers can run into it too because of links hidden by bridges, repeaters, or Rbridges ✨.
A.2. Appointed Forwarders and Bridged LANs ✨
okay so, with partial RBridge deployment, the RBridges might chop a bridged LAN into a smaller number of pretty big leftover bridged LANs, or maybe they don't split it at all and one bridged LAN stays whole 🧩. This setup can cause a problem, bestie:
The rule that native frames have to enter and leave a link through that link's appointed forwarder for the frame's VLAN can cause congestion or suboptimal routing 😬. (Similar problems can happen inside a bridged LAN because of the spanning tree algorithm.) How bad it gets depends a LOT on the topology 🌸. For example, say a bridged LAN has a star-like shape, with core bridges that only connect to other bridges and peripheral bridges that connect to end stations and to core bridges. If you swap out all the core bridges for RBridges but leave the peripheral bridges alone, performance would generally get better and you wouldn't get appointed forwarder congestion 💅.
Solutions to this are discussed below, and there's a specific example worked out in Appendix A.3.
Putting RBridges in so that all the bridged parts of the LAN stay connected to each other and each has multiple RBridge connections is generally the least efficient setup 🙈.
There are four techniques that can help if the problem above shows up, and you can kind of mix them together to some extent 🫶:
- Replace more IEEE 802.1 customer bridges with RBridges so the leftover remnant bridged LANs between RBridges are as small as possible. This doesn't need any RBridge configuration unless the bridges they replaced needed configuration.
- Rearrange the network topology to minimize the problem. If the bridges and RBridges involved are configured, this might mean changing their configuration.
- Configure the RBridges and bridges so that end stations on a remnant bridged LAN are split into different VLANs that have different appointed forwarders. If the end stations were already in different VLANs, this is easy-peasy (see Section 4.2.4.2). If the end stations were all on the same VLAN and have to be split up, this technique may cause connectivity problems between end stations 😭.
- Configure the RBridges so that their ports connected to the bridged LAN send spanning tree configuration BPDUs (see Section A.3.3) in a way that forces the bridged LAN to partition. (Note: A spanning tree is never formed through an RBridge, but it always terminates at RBridge ports.) To use this technique, the RBridges have to support this optional feature and would need to be configured to use it, but the bridges involved would rarely need any configuration 🧚. Heads up though: this technique makes the bridged LAN unavailable for TRILL through traffic, because the bridged LAN partitions 🚫.
Now, going the opposite way from item 3 above, there may be bridged LANs that use VLANs, or more VLANs than would otherwise be necessary, to support the Multiple Spanning Tree Protocol or to otherwise reduce the congestion a single spanning tree can cause. Swapping the IEEE 802.1 bridges in those LANs for RBridges may make it possible to cut back on VLANs and configuration complexity 🦋.
A.3. Wiring Closet Topology 🎀
ok so if 802.1 bridges are around and the RBridges aren't configured properly, the bridge spanning tree or the DRB might make inappropriate decisions 💀. Here's a specific example of the bigger problem that can happen when a bridged LAN connects to multiple RBridges.
Picture two (or more) groups of end nodes, each attached to a bridge (say, B1 and B2). Each bridge is attached to an RBridge (say, RB1 and RB2, respectively), and there's an extra link connecting B1 and B2 (see Figure 13). In that case, it might be smart to have the B1-B2 link act only as a backup, in case RB1 or RB2 fails, or one of the links B1-RB1 or B2-RB2 fails 🔥.
+-------------------------------+
| | | |
| Data +-----+ +-----+ |
| Center -| RB1 |----| RB2 |- |
| +-----+ +-----+ |
| | | |
+-------------------------------+
| |
| |
+-------------------------------+
| | | |
| +----+ +----+ |
| Wiring | B1 |-----| B2 | |
| Closet +----+ +----+ |
| Bridged |
| LAN |
+-------------------------------+
Figure 13: Wiring Closet TopologyFor example, B1 and B2 might be in a wiring closet, and it could be easy to set up a short, high-bandwidth, low-cost link between them, while RB1 and RB2 sit at a distant data center where the RB1-B1 and RB2-B2 links are slower and more expensive 💸.
The default behavior might be that one of RB1 or RB2 (say, RB1) becomes DRB for the bridged LAN including B1 and B2, and appoints itself forwarder for the VLANs on that bridged LAN 😵. Then RB1 would forward all the traffic to and from the link, so end nodes attached to B2 would connect to the campus via the path B2-B1-RB1, instead of the desired B2-RB2. That wastes the bandwidth of the B2-RB2 path and cuts the available bandwidth between the end stations and the data center in half 📉. What we really want is for both the RB1-B1 and RB2-B2 links to get used 🙌.
Three solutions to this problem are described below.
A.3.1. The RBridge Solution
Of course, if B1 and B2 are replaced with RBridges, the right thing happens without any configuration (other than VLAN support) 👑. But that might not be immediately practical if bridges are being swapped out for RBridges little by little 🧸.
A.3.2. The VLAN Solution
If the end stations attached to B1 and B2 are already split up among a number of VLANs, RB1 and RB2 can be configured so that whichever one becomes DRB for this link appoints itself forwarder for some of those VLANs and appoints the other RBridge for the remaining VLANs 🌈. If either RBridge fails or gets disconnected, the other one will have only itself to appoint as forwarder for all the VLANs 💜.
If all the end stations are on a single VLAN, you'd need to split them across at least two VLANs to use this solution. That might cause connectivity problems that need extra measures to fix 😬.
A.3.3. The Spanning Tree Solution
Another option is to configure the relevant ports on RB1 and RB2 to be part of a "wiring closet group", with a configured per-RBridge port "Bridge Address" Bx (which may be RB1 or RB2's System ID). Both RB1 and RB2 emit spanning tree BPDUs on their configured ports as highest priority root Bx 🔮. This makes the spanning tree logically partition the bridged LAN the way we want, by blocking the B1-B2 link at one end or the other (unless one of the bridges is also configured to have highest priority and has a lower ID, which we consider to be a misconfiguration ⚠️). With the B1-B2 link blocked, RB1 and RB2 can't see each other's TRILL-Hellos through that link, so each one acts as Designated RBridge and appointed forwarder for its own partition. Of course, with this partition, no TRILL through traffic can flow through the RB1-B1-B2-RB2 path 🚧.
In the spanning tree configuration BPDU, the Root is "Bx" with highest priority, the cost to Root is 0, and the Designated Bridge ID is "RB1" when RB1 transmits and "RB2" when RB2 transmits. The port ID is a value chosen independently by each of RB1 and RB2 to tell apart each of its own ports 🎯. The topology change flag is zero. The topology change acknowledgement flag is set if and only if a topology change BPDU has been received on the port since the last configuration BPDU was transmitted on the port 🧐. (If RB1 and RB2 were actually bridges on the same shared medium with no bridges between them, the one with the larger ID would see "better" BPDUs, because of the tiebreaker on the third field (the ID of the transmitting bridge), and would turn off its port 🙃.)
If RB1, the RB1-B1 link, RB2, or the RB2-B2 link fails, the spanning tree algorithm stops seeing one of the RBx roots and unblocks the B1-B2 link, which keeps all the end stations connected to the data center 🥹.
But if the link RB1-B1-B2-RB2 is on the cut set of the campus, and RB2 and RB1 have been configured to think they're part of a wiring closet group, the campus gets partitioned when the link is blocked 💔.
A.3.4. Comparison of Solutions
Replacing all 802.1 customer bridges with RBridges is usually the best solution, and it needs the least configuration, possibly none 🏆.
The VLAN solution works well with a fairly small amount of configuration if the end stations are already split up among a number of VLANs. If they aren't, it gets more complex and problematic 🤷♀️.
The spanning tree solution does pretty well in this particular case. But it depends on both RB1 and RB2 having implemented the optional feature of being able to configure a port to emit spanning tree BPDUs, as described in Appendix A.3.3 above 🔧. It also makes the bridged LAN whose partition is being forced unavailable for through traffic 🚫. Finally, while in this specific example it neatly breaks the link between the two bridges B1 and B2, if there were a more complex bridged LAN, with more than exactly two bridges, there's no guarantee it would partition into roughly equal pieces 🧩. In that case, you might end up with a very unbalanced load on the RB1-B1 link and the RB2-B2 link, although that's still better than using only one of those links exclusively 💖.
Appendix B. Trunk and Access Port Configuration ✨
okay so bridged LANs are lowkey organized like a core and access model 🏠. The core bridges only have point-to-point links to other bridges, and the access bridges hook up to end stations, core bridges, and maybe other access bridges too. It seems likely that some RBridge campuses will be set up the same way 🫶.
An RBridge port can be set up as a trunk port, meaning a link to another RBridge or RBridges. You do this by turning off end-station support on that port 💅. There's no reason for a trunk port to have more than one VLAN enabled and in its Announcing Set on the port. Of course, the RBridge (or RBridges) on the other end must have that same VLAN enabled 🎀. There's also no reason for this VLAN to be anything other than the default VLAN 1, unless the link is actually over carrier Ethernet or other facilities that only provide some other specific VLAN or something similar 🦋. This setup cuts down on wasted TRILL-Hellos and stops useless decapsulation and transmission of multi-destination traffic in native form onto the link (see Sections 4.2.4 and 4.9.1). It's giving efficiency, bestie 😭.
An RBridge access port is expected to lead to a link with end stations and possibly one or more bridges. That link might also have more than one RBridge connected to it, which gives the end stations more reliable service 🌸. The goal is to minimize or eliminate transit traffic on a link like this, since it's meant for end-station native traffic 💜. You can do that by turning on the access port configuration bit for the RBridge port or ports connected to the link, as explained further in Section 4.9.1 ✨.
When you're designing RBridge configuration user interfaces, you should think about making it convenient to configure ports as trunk and access ports 🍓.
Appendix C. Multipathing
okay this one is so cool 🌈. RBridges support multipathing of both known unicast and multi-destination traffic. Implementing multipathing is optional 🧚.
Multi-destination traffic can be multipathed by using different distribution tree roots for different frames 💖. For example, say that in Figure 14, end stations attached to RBy are the source of various multicast streams, and each stream has multiple listeners attached to various RBridges from RB1 through RB9 👑. Assuming the links all have equal bandwidth, a distribution tree rooted at RBy will mostly use the vertical links among RB1 through RB9, while one rooted at RBz will mostly use the horizontal ones 🦋. If RBy picks its nickname as the distribution tree root for half of this traffic and the RBz nickname as the root for the other half, it may be able to substantially increase the aggregate bandwidth by using both the vertical and horizontal links among RB1 through RB9 🔥.
Since the distribution trees an RBridge has to calculate are the same for all RBridges, and transit RBridges MUST respect the tree root specified by the ingress RBridge, a campus will operate correctly with a mix of RBridges. Some of them use different roots for different multi-destination frames they ingress, and some use a single root for all such frames 🫶.
+---+
|RBy|---------------+
+---+ |
/ | \ |
/ | \ |
/ | \ |
+---+ +---+ +---+ |
|RB1|---|RB2|---|RB3| |
+---+ +---+ +---+\ |
| | | \ |
+---+ +---+ +---+ \+---+
|RB4|---|RB5|---|RB6|-----|RBz|
+---+ +---+ +---+ /+---+
| | | /
+---+ +---+ +---+/
|RB7|---|RB8|---|RB9|
+---+ +---+ +---+
Figure 14: Multi-Destination MultipathKnown unicast Equal Cost Multipathing (ECMP) can happen at an RBridge if, instead of using a tiebreaker criterion when building SPF paths, it keeps information about the ports through which equal cost paths are available 🎀. Different unicast frames can then be sent out through those different ports, and they'll be forwarded along equal cost paths. For example, in Figure 15, which shows only RBridges and leaves out any bridges that are present, there are three equal cost paths between RB1 and RB2 and two equal cost paths between RB2 and RB5. So for traffic moving through this part of the campus from left to right, RB1 may be able to do three-way ECMP, and RB2 may be able to do two-way ECMP 💅.
A transit RBridge that receives a known unicast frame forwards it toward the egress RBridge, and it doesn't care whether it thinks it's on any particular path from the ingress RBridge or a previous transit RBridge 🌸. That means a campus will operate correctly with a mix of RBridges, where some implement ECMP and some don't 🧚.
There are actually three possibilities for the parallel paths between RB1 and RB2, and they go like this:
- If two or three of these paths have pseudonodes, then all three will be distinctly visible in the campus-wide link state, and ECMP as described above applies 👑.
- If the paths use P2P Hellos or otherwise don't have pseudonodes, these three paths appear as a single adjacency in the link state. In this case, multipathing across them is an entirely local matter for RB1 and RB2. It can be freely done for known unicast frames, but not for multi-destination frames, as described in Section 4.5.2 🙈.
- If and only if the three paths between RB1 and RB2 are single hop equal bandwidth links with no intervening bridges, then it would be permissible to combine them into one logical link through the [802.1AX] "link aggregation" feature. RBridges MAY implement link aggregation, since that feature operates below TRILL (see Section 4.9.2) 💜.
+---+ double line = 10 Gbps
----- ===|RB3|--- single line = 1 Gbps
/ \ // +---+ \
+---+ +---+ +---+
===|RB1|-----|RB2| |RB5|===
+---+ +---+ +---+
\ / \ +---+ //
----- ----|RB4|===
+---+
Figure 15: Known Unicast MultipathWhen multipathing is used, frames that follow different paths will be subject to different delays and may be re-ordered 😭. Some traffic may be insensitive to order and delay, but most traffic is made up of flows of frames where re-ordering within a flow is damaging 💀. How to determine flows, or what granularity flows should have, is beyond the scope of this document. (This issue is discussed in [802.1AX].) ✨
Appendix D. Determination of VLAN and Priority
this appendix is a high-level, informative summary of how the VLAN ID and priority get decided for incoming native frames 🦋. It leaves out some details. For the full story, see [802.1Q-2005] 🌈.
- When an untagged native frame arrives, an unconfigured RBridge associates the default priority zero and the VLAN ID 1 with it. Actually, it sets the VLAN for the untagged frame to be the "port VLAN ID" associated with that port. The port VLAN ID defaults to VLAN ID 1, but it can be configured to be any other VLAN ID 💖. An Rbridge may also be configured on a per-port basis to discard such frames or to associate a different priority code point with them. Determining the VLAN ID associated with an incoming untagged non-control frame may also depend on the Ethertype or NSAP (referred to in 802.1 as the Protocol) of the arriving frame, the source MAC address, or other local rules 🙈.
- When a priority tagged native frame arrives, an unconfigured RBridge associates it with both the port VLAN ID, which defaults to 1, and the priority code point provided in the priority tag in the frame. An Rbridge may be configured on a per-port basis to discard such frames, or to associate them with a different VLAN ID as described in the point right above. It may also be configured to map the priority code point provided in the frame by specifying, for each of the eight possible values that might be in the frame, which actual priority code point will be associated with the frame by the RBridge 💅.
- When a C-tagged (formerly called Q-tagged) native frame arrives, an unconfigured RBridge associates it with the VLAN ID and priority in the C-tag. An RBridge may be configured on a per-port per-VLAN basis to discard such frames. It may also be configured on a per-port basis to map the priority value as specified above for priority tagged frames 🫶.
In 802.1, the process of associating a priority code point with a frame, including mapping a priority provided in the frame to another priority, is called priority "regeneration" 🌸.
Appendix E. Support of IEEE 802.1Q-2005 Amendments
this informational appendix briefly comments on RBridge support for completed and in-process amendments to IEEE [802.1Q-2005] 🧚. There's no assurance that existing RBridge protocol specifications or existing bridges will support future [802.1Q-2005] amendments that haven't been specified yet, just as there's no assurance that existing bridge protocol specifications or existing RBridges will support future TRILL amendments that haven't been specified yet 😬.
The information below is frozen as of 25 October 2009. For the latest status, see the IEEE 802.1 working group at http://grouper.ieee.org/groups/802/1/ 👑.
E.1. Completed Amendments
okay so this is the bit where we get the list of IEEE amendments that are already done 🎀 (and the ones still cooking 🍳 come next). Each one gets a quick vibe check on how it plays with TRILL, bestie 🫶
802.1ad-2005 Provider Bridges is sometimes called "Q-in-Q" 🌸, because VLAN tags used to be called "Q-tags". It has Provider Bridges tunnel customer bridge traffic inside service VLAN tags (S-tags) ✨. If the customer LAN is an RBridge campus, that traffic gets bridged by Provider Bridges, and customer bridge features that care about Provider Bridge awareness (like configuring a customer bridge port to add an S-tag before sending a frame to a Provider Bridge) live below the EISS layer 💅. So they can run on RBridge ports with no changes to the TRILL protocol, periodt 💖
802.1ag-2007 Connectivity Fault Management (CFM) 😭 is at least partly dependent on the symmetric path and other stuff spanning tree does. The IEEE 802.1 working group told the IETF TRILL working group that "TRILL weakens the applicability of CFM" 💀. Not the vibe, honestly.
802.1ak-2007 Multiple Registration Protocol is supported to the extent described in Section 4.9.4 🦋.
802.1ah-2008 Provider Backbone Bridges is sometimes called "MAC-in-MAC" 🧚. It has Provider Backbone Bridges tunnel customer bridge traffic under different outer MAC addresses, and uses a tag (the "I-tag") to keep the original MAC addresses and signal other info 🍓. If the customer LAN is an RBridge campus, that traffic gets bridged by Provider Backbone Bridges. Same deal as 802.1ad: the customer bridge features about Provider Backbone Bridge awareness (like adding an I-tag to a frame before sending it to a Provider Backbone Bridge) are below the EISS layer, so RBridge ports can support them without modifying TRILL 👑
802.1Qaw-2009 Management of Data-Driven and Data-Dependent Connectivity Fault is an amendment that builds on 802.1ag. See the 802.1ag-2007 comments above, bestie 🙈
802.1Qay-2009 Provider Backbone Bridge Traffic Engineering is an amendment that builds on 802.1ah to configure traffic engineered routing 🌈. See the 802.1ah-2008 comments above ✨
E.2. In-Process Amendments
the following are amendments to IEEE [802.1Q-2005] that are still in process 🍳. Since they're still drafts, the comments below are based on those drafts, so they might be wrong for later versions or the final amendment, so don't take them as gospel 🙈
802.1aj Two-port MAC Relay [802.1aj] specifies a MAC relay that will be transparent to RBridges 🦋. RBridges are compatible with IEEE 802.1aj devices as currently specified, in the same sense that IEEE 802.1Q-2005 bridges are compatible with such devices 🫶
802.1aq Shortest Path Bridging provides improved routing in bridged LANs 🔥
802.1Qat Stream Reservation Protocol modifies 802.1Q to support the 802.1 Timing and Synchronization 💜. This protocol reserves resources for streams at supporting bridges 🌸
802.1Qau Congestion Notification: it currently appears that modifications to RBridge behavior above the EISS level would be needed to support this amendment 😬. Such modifications are beyond the scope of this document, so that's a different party's problem 💅
802.1Qav Forwarding and Queuing Enhancements for Time-Sensitive Streams modifies 802.1Q to support the 802.1 Timing and Synchronization protocol 🧚. This amendment specifies methods to support the resource reservations made through the 802.1Qat protocol (see above) ✨
802.1Qaz Enhanced Transmission Selection: it appears that this amendment will be below the EISS layer and can be supported in RBridge ports without modification to the TRILL protocol 👑
802.1Qbb Priority-based Flow Control, commonly called "per-priority pause" 🍓: it appears that this amendment will be below the EISS layer and can be supported in RBridge ports without modification to the TRILL protocol 🌈
802.1bc Remote Customer Service Interfaces is an extension to 802.1Q provider bridging. See 802.1ad-2005 above 🎀
802.1Qbe Multiple Backbone Service Instance Identifier (I-SID) Registration Protocol (MIRP) is an extension to 802.1Q provider backbone bridging. See 802.1ah-2008 above 🦋
802.1Qbf Provider Backbone Bridge Traffic Engineering (PBB-TE) Infrastructure Segment Protection extends 802.1Q to support certain types of failover between provider backbone bridges. See 802.1ah-2008 above 💖
Appendix F. Acknowledgements ✨
Many people have contributed to this design 🫶, including the following, in alphabetic order 🌸:
Bernard Aboba, Alia Atlas, Ayan Banerjee, Caitlin Bestler, Suresh Boddapati, David Michael Bond, Stewart Bryant, Ross Callon, James Carlson, Pasi Eronen, Dino Farinacci, Adrian Farrell, Don Fedyk, Bill Fenner, Eric Gray, Sujay Gupta, Joel Halpern, Andrew Lange, Acee Lindem, Vishwas Manral, Peter McCann, Israel Meilik, David Melman, Nandakumar Natarajan, Erik Nordmark, Jeff Pickering, Tim Polk, Dan Romascanu, Sanjay Sane, Pekka Savola, Matthew R. Thomas, Joe Touch, Mark Townsley, Kate Zebrose 💅👑
Authors' Addresses 🎀
Radia Perlman Intel Labs 2200 Mission College Blvd. Santa Clara, CA 95054-1549 USA
Phone: +1-408-765-8080 EMail: Radia@alum.mit.edu
Donald E. Eastlake, 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA
Phone: +1-508-333-2270 EMail: d3e3e3@gmail.com
Dinesh G. Dutt Cisco Systems 170 Tasman Drive San Jose, CA 95134-1706 USA
Phone: +1-408-527-0955 EMail: ddutt@cisco.com
Silvano Gai Cisco Systems 170 Tasman Drive San Jose, CA 95134-1706 USA
EMail: silvano@ip6.com
Anoop Ghanwani Brocade 130 Holger Way San Jose, CA 95134 USA
Phone: +1-408-333-7149 EMail: anoop@alumni.duke.edu
📦 where this page comes from
- ietf: rfc6325 2011-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms