RFC 6325
Routing Bridges (RBridges): Base Protocol Specification
Pages: 99
Proposed Standard
→ Errata
Updated by: 6327 6439 7172 7177 7357 7179 7180 7455 7780 7783 8139 8249 8361 8377
Proposed Standard
→ Errata
Updated by: 6327 6439 7172 7177 7357 7179 7180 7455 7780 7783 8139 8249 8361 8377
Part 1 of 4 – Pages 1 to 20
Internet Engineering Task Force (IETF) R. Perlman Request for Comments: 6325 Intel Labs Category: Standards Track D. Eastlake 3rd ISSN: 2070-1721 Huawei D. Dutt S. Gai Cisco Systems A. Ghanwani Brocade July 2011 Routing Bridges (RBridges): Base Protocol SpecificationAbstract
Routing Bridges (RBridges) provide optimal pair-wise forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. They achieve these goals using IS-IS routing and encapsulation of traffic with a header that includes a hop count. RBridges are compatible with previous IEEE 802.1 customer bridges as well as IPv4 and IPv6 routers and end nodes. They are as invisible to current IP routers as bridges are and, like routers, they terminate the bridge spanning tree protocol. The design supports VLANs and the optimization of the distribution of multi-destination frames based on VLAN ID and based on IP-derived multicast groups. It also allows unicast forwarding tables at transit RBridges to be sized according to the number of RBridges (rather than the number of end nodes), which allows their forwarding tables to be substantially smaller than in conventional customer bridges. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, 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, except to format it for publication as an RFC or to translate it into languages other than English.
Table of Contents
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 ......................................98
Table of Figures
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 ................................94
1. Introduction
In traditional IPv4 and IPv6 networks, each subnet has a unique prefix. Therefore, a node in multiple subnets has multiple IP addresses, typically one per interface. This also means that when an interface moves from one subnet to another, it changes its IP address. Administration of IP networks is complicated because IP routers require per-port subnet address configuration. Careful IP address management is required to avoid creating subnets that are sparsely populated, wasting addresses. IEEE 802.1 bridges avoid these problems by transparently gluing many physical links into what appears to IP to be a single LAN [802.1D]. However, 802.1 bridge forwarding using the spanning tree protocol has some disadvantages: o The spanning tree protocol works by blocking ports, limiting the number of forwarding links, and therefore creates bottlenecks by concentrating traffic onto selected links. o Forwarding is not pair-wise shortest path, but is instead whatever path remains after the spanning tree eliminates redundant paths. o The Ethernet header does not contain a hop count (or Time to Live (TTL)) field. This is dangerous when there are temporary loops such as when spanning tree messages are lost or components such as repeaters are added. o VLANs can partition when the spanning tree reconfigures. This document presents the design for RBridges (Routing Bridges [RBridges]) that implement the TRILL protocol and are poetically summarized below. Rbridges combine the advantages of bridges and routers and, as specified in this document, are the application of link state routing to the VLAN-aware customer bridging problem. With the exceptions discussed in this document, RBridges can incrementally replace IEEE [802.1Q-2005] or [802.1D] customer bridges. While RBridges can be applied to a variety of link protocols, this specification focuses on IEEE [802.3] links. Use with other link types is expected to be covered in other documents. The TRILL protocol, as specified herein, is designed to be a Local Area Network protocol and not designed with the goal of scaling beyond the size of existing bridged LANs. For further discussion of the problem domain addressed by RBridges, see [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
The bulk of the normative material in this specification appears in Sections 1 through 4. In case of conflict between provisions in these four sections, the provision in the higher numbered section prevails.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 herein while an "RBridge" is a device that implements that protocol. The second letter in Rbridge is case insensitive. Both Rbridge and RBridge are correct. In this document, the term "link", unless otherwise qualified, means "bridged LAN", that is to say, the combination 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 indicate a point-to-point or multi-access link with no included bridges or RBridges. 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 indicate the physical point of connection between an RBridge and a link.
A "campus" is to RBridges as a "bridged LAN" is to bridges. An RBridge campus consists of a network of RBridges, bridges, hubs, repeaters, simple links, and the like and it is 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 is, 8-bit byte), giving the value of the octet as an unsigned integer. A hyphen separates successive octets. This document consistently uses IETF bit ordering, although the physical order of bit transmission within an octet on an IEEE [802.3] link is from the lowest order bit to the highest order bit, the reverse of IETF ordering.1.4. Categories of Layer 2 Frames
In this document, Layer 2 frames are divided into five categories: o Layer 2 control frames (such as Bridge PDUs (BPDUs)) o native frames (non-TRILL-encapsulated data frames) o TRILL Data frames (TRILL-encapsulated data frames) o TRILL control frames o TRILL other frames The way these five types of frames are distinguished is as follows: o Layer 2 control frames are those with a multicast destination address in the range 01-80-C2-00-00-00 to 01-80-C2-00-00-0F or equal to 01-80-C2-00-00-21. RBridges MUST NOT encapsulate and forward such frames, though they MAY, unless otherwise specified in this document, perform the Layer 2 function (such as MAC-level security) of the control frame. Frames with a destination address of 01-80-C2-00-00-00 (BPDU) or 01-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". o Native frames are those that are not control frames and have an Ethertype other than "TRILL" or "L2-IS-IS" and have a destination MAC address that is not one of the 16 multicast addresses reserved for TRILL. o TRILL Data frames have the Ethertype "TRILL". In addition, TRILL data frames, if multicast, have the multicast destination MAC address "All-RBridges".
o TRILL control frames have the Ethertype "L2-IS-IS". In addition,
TRILL control frames, if multicast, have the multicast destination
MAC addresses of "All-IS-IS-RBridges". (Note that ESADI frames
look on the outside like TRILL data and are so handled but, when
decapsulated, have the L2-IS-IS Ethertype.)
o TRILL other frames are those with any of the 16 multicast
destination addresses reserved for TRILL other than All-RBridges
and All-IS-IS-RBridges. RBridges conformant to this specification
MUST discard TRILL other frames.
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 Protocol
2. RBridges
This section provides a high-level overview of RBridges, which implement the TRILL protocol, omitting some details. Sections 3 and 4 below provide more detailed specifications. TRILL, as described in this document and with the exceptions discussed herein, 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 the like. The extension of TRILL to provide such 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
RBridges run a link state protocol amongst themselves. This gives them enough information to compute pair-wise optimal paths for unicast, and calculate distribution trees for delivery of frames either to destinations whose location is unknown or to multicast/broadcast groups [RBridges] [RP1999]. To mitigate temporary loop issues, RBridges forward based on a header with a hop count. RBridges also specify the next hop RBridge as the frame destination when forwarding unicast frames across a shared- media link, which avoids spawning additional copies of frames during a temporary loop. A Reverse Path Forwarding Check and other checks are performed on multi-destination frames to further control potentially looping traffic (see Section 4.5.2). The first RBridge that a unicast frame encounters in a campus, RB1, encapsulates the received frame with a TRILL header that specifies the last RBridge, RB2, where the frame is decapsulated. RB1 is known as the "ingress RBridge" and RB2 is known as the "egress RBridge". To save room in the TRILL header and simplify forwarding lookups, a dynamic nickname acquisition protocol is run among the RBridges to select 2-octet nicknames for RBridges, unique within the campus, which are an abbreviation for the IS-IS ID of the RBridge. The 2-octet nicknames are used to specify the ingress and egress RBridges in the TRILL header. Multipathing of multi-destination frames through alternative distribution trees and ECMP (Equal Cost Multipath) of unicast frames are supported (see Appendix C).
Networks with a more mesh-like structure will benefit to a greater extent from the multipathing and optimal paths provided by TRILL than will more tree-like networks. RBridges run a protocol on a link to elect a "Designated RBridge" (DRB). The TRILL-IS-IS election protocol on a link is a little different from the Layer 3 IS-IS [ISO10589] election protocol, because in TRILL it is essential that only one RBridge be elected DRB, whereas in Layer 3 IS-IS it is possible for multiple routers to be elected Designated Router (also known as Designated Intermediate System). As with 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. Additionally, the DRB 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, delegates this responsibility, 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 will refer to the RBridge appointed to forward VLAN-x traffic on behalf of the link as the "appointed VLAN-x forwarder" (see Section 4.2.4.3). (Section 2.5 discusses VLANs further.) 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 be used, within a campus, even for an RBridge that lacks an IP or other Layer 3 transport stack or which does not have a Layer 3 address, by transporting SNMP with 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, both on the links for which it is VLAN-x forwarder and on other links in the campus. RB1 learns the port, VLAN, and Layer 2 (MAC) addresses of end nodes on links for which it is VLAN-x forwarder from the source address of frames received, as bridges do (for example, see Section 8.7 of [802.1Q-2005]), or through configuration or 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, and the corresponding RBridge to which they are
attached, 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 that 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. Such information might be more authoritative than that learned from data frames being decapsulated onto the link. Also, the addresses enrolled and distributed in this way can 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 is unplugged from one RBridge and plugged into another, then, depending on circumstances, frames addressed to that end station can be black-holed. That is, they can be sent just to the older RBridge that the end station used to be connected to until cached address information at some remote RBridge(s) times out, possibly for a number of minutes or longer. With the ESADI protocol, the link interruption from the unplugging can cause an immediate update to be sent. 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 configured not to do so. Advertising end nodes using ESADI is optional, as is learning from these 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]. This is possible since the RBridge relay function is layered on top of the Layer 2 technologies. However, this document specifies only 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 RBridges Figure 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 Frame In the case of media different from 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 Frame The outer header is link-specific and, although this document specifies only [802.3] links, other links are allowed.
In both cases, the inner Ethernet header and the Ethernet Payload
come from the original frame and are encapsulated with a TRILL header
as they travel between RBridges. Use of a TRILL header offers the
following benefits:
1. loop mitigation through use of a hop count field;
2. elimination of the need for end-station VLAN and MAC address
learning in transit RBridges;
3. direction of unicast frames towards the egress RBridge (this
enables unicast forwarding tables of transit RBridges to be sized
with the number of RBridges rather than the total number of end
nodes); and
4. 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, to avoid frame
duplication if the inter-RBridge link is multi-access. This also
enables multipathing of unicast, since the transmitting RBridge can
specify the next hop. Having the outer header specify the
transmitting RBridge as the source address ensures that any bridges
inside the Ethernet cloud will not get confused, as they might be if
multipathing is in use and they were to see the original source or
ingress RBridge in the outer header.
2.4. Forwarding Overview
RBridges are true routers in the sense that, in the forwarding of a
frame by a transit RBridge, the outer Layer 2 header is replaced at
each hop with an appropriate Layer 2 header for the next hop, and a
hop count is decreased. Despite these modifications of 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 may be classified into
two categories: known-unicast and multi-destination. Layer 2 control
frames and TRILL control and TRILL other frames are not transit
frames, are not forwarded by RBridges, and are not included in these
categories.
2.4.1. Known-Unicast
These frames have a unicast inner MAC destination address (Inner.MacDA) and are those for which the ingress RBridge knows the egress RBridge for the destination MAC address in the frame's VLAN. Such frames are forwarded Rbridge hop by Rbridge hop to their egress Rbridge.2.4.2. Multi-Destination
These are frames that must be delivered to multiple destinations. Multi-destination frames include the following: 1. unicast frames for which the location of the destination is unknown: the Inner.MacDA is unicast, but the ingress RBridge does not know its location in the frame's VLAN. 2. multicast frames for which the Layer 2 destination address is derived from an IP multicast address: the Inner.MacDA is multicast, from the set of Layer 2 multicast addresses derived from IPv4 [RFC1112] or IPv6 [RFC2464] multicast addresses. These frames are handled somewhat differently in different subcases: 2.1. IGMP [RFC3376] and MLD [RFC2710] multicast group membership reports 2.2. IGMP [RFC3376] and MLD [RFC2710] queries and MRD [RFC4286] announcement messages 2.3. other IP-derived Layer 2 multicast frames 3. multicast frames for which the Layer 2 destination address is not derived from an IP multicast address: the Inner.MacDA is multicast, and not from the set of Layer 2 multicast addresses derived from IPv4 or IPv6 multicast addresses. 4. broadcast frames: the Inner.MacDA is broadcast (FF-FF-FF-FF-FF-FF). RBridges build distribution trees (see Section 4.5) and use these trees for forwarding multi-destination frames. Each distribution tree reaches all RBridges in the campus, is shared across all VLANs, and may be used for the distribution of a native frame that is in any VLAN. However, the distribution of any particular frame on a distribution tree is pruned in different ways for different cases to avoid unnecessary propagation of the frame.
2.5. RBridges and VLANs
A VLAN is a way to partition end nodes in a campus into different Layer 2 communities [802.1Q-2005]. Use of VLANs requires configuration. By default, the port of receipt determines the VLAN of a frame sent by an end station. End stations can also explicitly insert this information in a frame. IEEE [802.1Q-2005] bridges can be configured to support multiple customer VLANs over a single simple link by inserting/removing a VLAN tag in the frame. VLAN tags used by TRILL have the same format as VLAN tags defined in IEEE [802.1Q-2005]. As shown in Figure 2, there are two places where such tags may be present in a TRILL-encapsulated frame sent over an IEEE [802.3] link: one in the outer header (Outer.VLAN) and one in the inner header (Inner.VLAN). Inner and outer VLANs are further discussed in Section 4.1. RBridges enforce delivery of a native frame originating in a particular VLAN only to other links in the same VLAN; however, there are a few differences in the handling of VLANs 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 configurations of bridges may cause partitions of a VLAN on a link. For such configurations, a frame sent by one RBridge to a neighbor on that link might not arrive, if tagged with a VLAN that is partitioned due to bridge configuration. 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 cause VLAN-x to be partitioned on a link, some VLAN-x end nodes on that link may be orphaned (unable to communicate with the rest of the campus). It is 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 detected, it takes
steps to ensure that there is at most a single appointed forwarder on the link, to avoid possible frame duplication or loops (see Section 4.4.5). TRILL behaves as conservatively as possible, avoiding loops rather than avoiding partial connectivity. As a result, lack of connectivity may result from bridge or port misconfiguration.2.6. RBridges and IEEE 802.1 Bridges
RBridge ports are, except as described below, layered on top of IEEE [802.1Q-2005] port facilities.2.6.1. RBridge Ports and 802.1 Layering
RBridge ports make use of [802.1Q-2005] port VLAN and priority processing. In addition, 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]. However, RBridges do not use spanning tree and do not block ports as 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 represent the flow of control information, double lines 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 Model The upper interface to the low-level port/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, a bridged LAN can be upgraded by incrementally replacing such bridges with RBridges. Bridges that have not yet been replaced are transparent to RBridge traffic. The physical links directly interconnected by such bridges, together with the bridges themselves, constitute bridged LANs. These bridged LANs appear to RBridges to be multi-access links. If the bridges replaced by RBridges were default configuration bridges, then their RBridge replacements will not require configuration. Because RBridges, as described in this document, only provide customer services, they cannot replace provider bridges or provider backbone bridges, just as a customer bridge can't replace a provider bridge. However, such provider devices can be part of the bridged LAN between RBridges. Extension of TRILL to support provider services is left for future work and will be separately documented. Of course, if the bridges replaced had any port level protocols enabled, such as port-based access control [802.1X] or MAC security [802.1AE], replacement RBridges would need the same port level protocols enabled and similarly configured. In addition, the replacement RBridges would have to support the same link type and link level protocols as the replaced bridges. 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. However, there may be intermediate states, where only some bridges have been replaced by RBridges, with inferior performance. See Appendix A for further discussion of incremental deployment.
(page 20 continued on part 2)