TRILL Working Group Radia Perlman INTERNET-DRAFT Sun Microsystems Intended status: Proposed Standard Donald Eastlake 3rd Expires: March 25, 2009 Eastlake Enterprises Dinesh G. Dutt Cisco Systems Silvano Gai Nuova Systems Anoop Ghanwani Brocade September 26, 2008 Rbridges: Base Protocol Specification Status of This Document By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Distribution of this document is unlimited. Comments should be sent to the TRILL working group mailing list . Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. R. Perlman, et al [Page 1] INTERNET-DRAFT RBridge Protocol Abstract RBridges provide optimal pair-wise forwarding with zero 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 optimization of the distribution of multi-destination frames based on VLAN and IP derived multicast groups. It also allows forwarding tables to be based on RBridge destinations (rather than end node destinations), which allows internal forwarding tables to be substantially smaller than in conventional bridge systems. Acknowledgements Many people have contributed to this design, including, in alphabetic order, Alia Atlas, Ayan Banerjee, Suresh Boddapati, Caitlin Bestler, Stewart Bryant, James Carlson, Dino Farinacci, Don Fedyk, Bill Fenner, Eric Gray, Joel Halpern, Andrew Lange, David Melman, Erik Nordmark, Sanjay Sane, Pekka Savola, Matthew Thomas, Joe Touch, and Mark Townsley. We invite you to join the mailing list at http://www.postel.org/rbridge. R. Perlman, et al [Page 2] INTERNET-DRAFT RBridge Protocol Table of Contents Status of This Document....................................1 Abstract...................................................2 Acknowledgements...........................................2 1. Introduction............................................7 1.1 Algorhyme V2, by Ray Perlner...........................8 1.2 Normative Content and Precedence.......................8 1.3 Terminology and Notation in this document..............8 1.4 Acronyms...............................................9 2. RBridges...............................................12 2.1 End Station Addresses.................................13 2.2 RBridge Encapsulation Architecture....................13 2.2.1 Known-Unicast.......................................16 2.2.2 Multi-destination...................................16 2.3 RBridges and VLANs....................................17 2.3.1 Link VLAN Assumptions...............................17 2.4 RBridges and IEEE 802.1 Bridges.......................18 3. Details of the TRILL Header............................19 3.1 TRILL Header Format...................................19 3.2 Version (V)...........................................19 3.3 Reserved (R)..........................................20 3.4 Multi-destination (M).................................20 3.5 TRILL Header Options..................................20 3.6 Hop Count.............................................21 3.7 RBridge Nicknames.....................................22 3.7.1 Egress RBridge Nickname.............................22 3.7.2 Ingress RBridge Nickname............................23 3.7.3 RBridge Nickname Allocation.........................23 4. Other RBridge Design Details...........................25 4.1 Ethernet Data Encapsulation...........................25 4.1.1 VLAN Tag Information................................27 4.1.2 Inner VLAN Tag......................................28 4.1.3 Outer VLAN Tag......................................28 4.1.4 Frame Check Sequence (FCS)..........................29 4.2 Link State Protocol (IS-IS)...........................29 4.2.1 IS-IS RBridge Identity..............................29 4.2.2 IS-IS Instances.....................................30 4.2.3 Core TRILL IS-IS....................................30 4.2.3.1 Core IS-IS Link Protocol..........................30 4.2.3.2 Designated RBridge................................34 4.2.3.3 Appointed VLAN-x Forwarder........................35 4.2.3.4 Core TRILL IS-IS LSP Information..................36 4.2.4 End Station Address Distribution Instance (ESADI)...38 4.2.4.1 ESADI Protocol....................................38 4.2.4.2 ESADI Information.................................38 R. Perlman, et al [Page 3] INTERNET-DRAFT RBridge Protocol Table of Contents Continued 4.3 Distribution Trees....................................39 4.3.1 Distribution Tree Calculation and Checks............40 4.3.2 Pruning the Distribution Tree.......................41 4.3.3 Tree Distribution Optimization......................41 4.3.4 Forwarding Using a Distribution Tree................42 4.4 Frame Processing Behavior.............................43 4.4.1 Receipt of a Native Frame...........................44 4.4.1.1 Native Unicast Case...............................44 4.4.1.2 Native Multicast and Broadcast Frames.............45 4.4.2 Receipt of a TRILL Frame............................46 4.4.2.1 TRILL IS-IS Frames................................46 4.4.2.2 TRILL Data Frames.................................47 4.4.3 Receipt of a Control Frame..........................48 4.5 IGMP, MLD, and MRD Learning...........................48 4.6 End Station Address Details...........................49 4.6.1 Learning End Station Addresses......................50 4.6.2 Forgetting End Station Addresses....................51 4.6.3 Shared VLAN Learning................................52 4.7 RBridge Port Structure................................53 4.7.1 BPDU Handling.......................................56 4.7.1.1 Receipt of BPDUs..................................56 4.7.1.2 Root Bridge Changes...............................56 4.7.1.3 Transmission of BPDUs.............................57 4.7.2 Dynamic VLAN Registration...........................57 5. RBridge Addresses, Parameters, and Constants...........59 6. Security Considerations................................61 7. Assignment Considerations..............................63 7.1 IANA Considerations...................................63 7.2 IEEE 802 Assignment Considerations....................63 8. Normative References...................................64 9. Informative References.................................65 Appendix A: Incremental Deployment Considerations.........66 A.1 Link Cost Determination...............................66 A.2 Appointed Forwarders and Bridged LANs.................66 A.3 Wiring Closet Topology................................68 A.3.1 The RBridge Solution................................69 A.3.2 The VLAN Solution...................................69 A.3.3 The Spanning Tree Solution..........................69 A.3.4 Comparison of Solutions.............................70 Appendix B: Trunk and Access Port Configuration...........71 R. Perlman, et al [Page 4] INTERNET-DRAFT RBridge Protocol Table of Contents Continued Appendix C: Multipathing..................................72 Appendix D: Determination of VLAN and Priority............74 Appendix Z: Revision History..............................75 Changes from -03 to -04...................................75 Changes from -04 to -05...................................76 Changes from -05 to -06...................................77 Changes from -06 to -07...................................77 Changes from -07 to -08...................................78 Changes from -08 to -09...................................80 Disclaimer................................................82 Additional IPR Provisions.................................82 Authors' Addresses........................................83 Expiration and File Name..................................84 R. Perlman, et al [Page 5] INTERNET-DRAFT RBridge Protocol Table of Figures Figure 2.1: Interconnected RBridges.......................14 Figure 2.2: An Ethernet Encapsulated TRILL Frame..........14 Figure 2.3: A PPP Encapsulated TRILL Frame................15 Figure 3.1: TRILL Header..................................19 Figure 3.2: Options Area Initial Flags Byte...............21 Figure 4.1: TRILL Data Encapsulation over Ethernet........26 Figure 4.2: VLAN Tag Information..........................27 Figure 4.3: RBridge Port Model............................55 Figure A.1: Link Cost of a Bridged Link...................66 Figure A.2: Wiring Closet Topology........................68 Figure C.1: Multi-Destination Multipath...................72 Figure C.2: Known Unicast Multipath.......................73 R. Perlman, et al [Page 6] INTERNET-DRAFT RBridge Protocol 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 significant 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 blocks ports, limiting the number of forwarding links, and therefore creates bottlenecks by concentrating traffic onto selected links. o The Ethernet header does not contain a hop count (or 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, perhaps unexpectedly, when spanning tree reconfigures due to a node failure or topology change. o Forwarding is not pair-wise shortest path, but is instead whatever path remains after the spanning tree eliminates redundant paths. This document presents the design for RBridges (Routing Bridges [RBridges]) which implement the TRILL protocol and are poetically summarized below. Rbridges combine the advantages of bridges and routers and in most cases they can incrementally replace IEEE [802.1Q] customer bridges. While they can be applied to a variety of link protocols, this specification focuses on IEEE [802.3] links. For further discussion of the problem domain addressed by RBridges see [PAS]. R. Perlman, et al [Page 7] INTERNET-DRAFT RBridge Protocol 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 2, 3, and 4 as follows: Section 2: general RBridge description Section 3: the TRILL header Section 4: other TRILL protocol details In case of conflict, the order of precedence of these section is as follows, with those appearing earlier in this list having precedence over those which appear later: 4 > 3 > 2 1.3 Terminology and Notation in this document "TRILL" normally refers to the protocol specified herein while "RBridge" refers to the devices that implement that protocol. The second letter in Rbridge is case insensitive. Both Rbridge and RBridge are correct. This document uses Hexadecimal Notation for MAC addresses. Each octet (that is, 8-bit byte) is represented by two hexadecimal digits giving the value of the octet as an unsigned integer and successive octets are separated by a hyphen. This document consistently uses R. Perlman, et al [Page 8] INTERNET-DRAFT RBridge Protocol 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. In this document, Layer 2 frames are divided into three categories, TRILL frames, control frames, and native frames, as follows:: o "TRILL" frames are those with the TRILL Ethertype. There are two sub-categories of TRILL frames as follows: - "TRILL IS-IS" frames have the All-IS-IS-RBridges multicast address as the encapsulated destination address. - "TRILL data" frames are all other TRILL frames. o "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. There are two sub-categories of control frames as follows: - "high level control" frames are those with a destination address of 01-80-C2-00-00-00 (BPDU) or 01-80-C2-00-00-21 (VRP). - "low level control" frames are all other control frames. o "native" frames are all frames other than TRILL and control frames. (Although, according to the definitions above, a frame could be both a TRILL frame and a control frame, such a frame would be invalid regardless of which view was taken and would be silently discarded.) 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]. 1.4 Acronyms AllL1ISs - All Level 1 Intermediate Systems AllL2ISs - All Level 2 Intermediate Systems CHbH - Critical Hop-by-Hop CItE - Critical Ingress-to-Egress CSNP - Complete Sequence Number PDU DA - Destination Address EAP - Extensible Authentication Protocol R. Perlman, et al [Page 9] INTERNET-DRAFT RBridge Protocol ECMP - Equal Cost Multi-Path EISS - Extended Internal Sublayer Service ESADI - End Station Address Distribution Instance DRB - Designated RBridge FCS - Frame Check Sequence GARP - Generic Attribute Registration Protocol GVRP - GARP VLAN Registration Protocol IEEE - Institute of Electrical and Electronic 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 MVRP - Multiple VLAN Registration Protocol NSAP - Network Service Access Point PDU - Protocol Data Unit PPP - Point-to-Point Protocol RBridge - Routing Bridge RPF - Reverse Path Forwarding SA - Source Address SNP - Sequence Number PDU R. Perlman, et al [Page 10] INTERNET-DRAFT RBridge 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 R. Perlman, et al [Page 11] INTERNET-DRAFT RBridge Protocol 2. RBridges This section provides a high level overview of RBridges, which implement the TRILL protocol. Sections 3 and 4 below provide the main specification. 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 unknown MAC destinations 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.3.1). 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. RB1 is known as the "ingress RBridge" and RB2 is known as the "egress RBridge". To save room in the TRILL header, a dynamic nickname acquisition protocol is run among the RBridges to select a 2-octet nickname for each RBridge, unique within the campus, which is an abbreviation for the 6-octet IS-IS system 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 tree roots and ECMP (Equal Cost MultiPath) of unicast frames are supported (see Appendix C). Multipathing may introduce frame reordering as can differing frame priorities or changes in network topology. RBridges run the IS-IS [ISO10589] election protocol to elect a "Designated RBridge" (DRB) on each bridged LAN ("link"). 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 specifies which VLAN will be the Designated VLAN used for communication between RBridges on that link. 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". (Section 2.3 discusses VLANs further.) R. Perlman, et al [Page 12] INTERNET-DRAFT RBridge Protocol Rbridges SHOULD support SNMPv3 [RFC3411]. The Rbridge MIB will be specified in a separate document. This management can be used, within a campus, even by an RBridge that lacks an IP or other Layer 3 transport stack or which has zero configuration and thus no Layer 3 address, by transporting SNMP with Ethernet [RFC4789]. 2.1 End Station Addresses An RBridge, RB1, which 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 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]), or through a Layer 2 explicit registration protocol. RB1 learns the 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 address of the inner frame of TRILL data frames that it decapsulates. Additionally, an end station address distribution instance (ESADI) of IS-IS MAY be used by an RBridge that is the appointed VLAN-x forwarder on one or more links to announce some or all of the attached VLAN-x end nodes on those links. The intention is that such an announcement would be used to announce end nodes that have been explicitly enrolled, and so such information would be more authoritative than simply learning from data frames being decapsulated onto the link. Also, it can be more secure because not only might the enrollment be authenticated (for example by cryptographically based EAP methods via [802.1X]), but IS-IS also supports cryptographic authentication of its messages [RFC3567]. But even if an ESADI is used to announce attached end nodes, RBridges MUST still learn from decapsulating data frames unless configured not to do so. Advertising end nodes using an ESADI of IS-IS is optional, as is learning from these announcements. (See Section 4.6 for further end station address details.) 2.2 RBridge Encapsulation Architecture The Layer 2 technology used to connect Rbridges may be either IEEE [802.3] or some other technology such as PPP [RFC1661]. This is possible since the RBridge relay functionality is layered on top of the Layer 2 technologies. However, this document specifies only an R. Perlman, et al [Page 13] INTERNET-DRAFT RBridge Protocol IEEE 802.3 encapsulation. Figure 2.1 shows two RBridges RB1 and RB2 interconnected through an Ethernet cloud. The Ethernet cloud may include point-to-point or shared media, hubs and IEEE 802.1 bridges. The Ethernet cloud may support VLAN tagging or not. ------------ / \ +-----+ / Ethernet \ +-----+ | RB1 |----< >---| RB2 | +-----+ \ Cloud / +-----+ \ / ------------ Figure 2.1: Interconnected RBridges Figure 2.2 shows the format of a TRILL frame traveling through the Ethernet cloud from RB1 to RB2. +--------------------------------+ | Outer Ethernet Header | +--------------------------------+ | TRILL Header | +--------------------------------+ | Inner Ethernet Header | +--------------------------------+ | Ethernet Payload | +--------------------------------+ | Ethernet FCS | +--------------------------------+ Figure 2.2: An Ethernet Encapsulated TRILL Frame In the case of media different from Ethernet, the outer Ethernet header is replaced by the header specific to that media. For example, Figure 2.3 shows a TRILL encapsulation over PPP. R. Perlman, et al [Page 14] INTERNET-DRAFT RBridge Protocol +--------------------------------+ | PPP Header | +--------------------------------+ | TRILL Header | +--------------------------------+ | Inner Ethernet Header | +--------------------------------+ | Ethernet Payload | +--------------------------------+ | Ethernet FCS | +--------------------------------+ Figure 2.3: A PPP Encapsulated TRILL Frame The outer header is link-specific and, although this document specifies only Ethernet 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 for several reasons: 1. to mitigate loop issues a hop count field is included; 2. to prevent original source MAC learning in the core from frames in transit; 3. to direct frames towards the egress RBridge (this enables forwarding tables of RBridges to be sized with the number of RBridges rather than the total number of end nodes); and, 4. to provide a separate VLAN tag for forwarding traffic between RBridges, independent of the original VLAN of the frame. When forwarding unicast frames between RBridges across a shared- media, the outer header has the MAC destination address of the next hop Rbridge, to avoid frame duplication. Having the outer header specify the transmitting RBridge as source address ensures that any bridges inside the shared-media link will not get confused, as they might given multipathing, if they were to see the original source or ingress RBridge in the outer header. There are several types of transit frames between RBridges that are forwarded differently. They are here classified into two main categories: known-unicast and multi-destination. R. Perlman, et al [Page 15] INTERNET-DRAFT RBridge Protocol 2.2.1 Known-Unicast These frames have a unicast inner MAC destination Address (Inner.MacDA) and are those for which the egress RBridge for that destination MAC address is known to the ingress RBridge. Such frames are forwarded Rbridge hop by Rbridge hop to their egress Rbridge. 2.2.2 Multi-destination These are frames that must be delivered to multiple destinations. The main cases of multi-destination frames are as follows: 1. frames for unknown unicast destinations: the Inner.MacDA is unicast, but the ingress RBridge does not know its location; 2. frames for Layer 2 multicast addresses derived from IP multicast addresses: 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. frames for Layer 2 multicast addresses not derived from IP multicast addresses: the Inner.MacDA is multicast, and not from the set of Layer 2 multicast addresses derived from IPv4 or IPv6 multicast addresses. 4. frames for the Layer 2 broadcast address: the Inner.MacDA is broadcast. RBridges build distribution trees (see Section 4.3) and use these trees for forwarding multi-destination frames. These distribution trees are pruned in different ways for different cases to avoid unnecessary propagation of the frame. R. Perlman, et al [Page 16] INTERNET-DRAFT RBridge Protocol 2.3 RBridges and VLANs A VLAN is a way to partition end nodes in a campus into different Layer 2 communities [802.1Q]. Use of VLANs requires configuration. The default method of determining the community of a frame sent by an end station is based on the port on which it is initially received. End stations can also explicitly insert this information in a frame. IEEE 802.1Q bridges can be configured to support multiple VLANs over a single link by inserting/removing a VLAN tag in the frame. Some end nodes have the same capability. VLAN tags used by TRILL are structured according to IEEE 802.1Q. As shown in Figure 2.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.3.1 for further discussion of TRILL IS-IS operation on a link beyond that in the subsections below.) 2.3.1 Link VLAN Assumptions In a network with a mix of bridges and RBridges, certain configurations of bridges or ports may prevent some nodes in some VLANs from communicating with each other. TRILL requires that on each link in the campus there is at least one VLAN that gives full connectivity to all the RBridges on that link and that the RBridges are configured to know which VLAN that is if it is not the default VLAN 1. Since there will be only one appointed forwarder for any VLAN, say VLAN A, on a link, if bridges are configured to cause VLAN A to be partitioned on a link, some 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 A frame turns into a VLAN B frame). TRILL detects this case through IS-IS Hellos, by inserting the initial VLAN tag into the Hello. If VLAN mapping is discovered, TRILL takes steps which assure that there is at most a single appointed forwarder on the link, to avoid possible frame duplication or loops. R. Perlman, et al [Page 17] INTERNET-DRAFT RBridge Protocol TRILL behaves as conservatively as possible, avoiding loops rather than avoiding partial connectivity. If lack of connectivity or other problems occur due to bridge or port configuration, reconfiguring the bridges or ports, or replacing bridges with RBridges, will solve the problem. 2.4 RBridges and IEEE 802.1 Bridges Because RBridges are generally compatible with current IEEE [802.1Q] customer bridges, a 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 un- managed, zero configuration bridges, then their RBridge replacements will not require configuration. The RBridge campus will work best if all IEEE 802.1 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. R. Perlman, et al [Page 18] INTERNET-DRAFT RBridge Protocol 3. Details of the TRILL Header The 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 3.1 and is independent of the data link layer used. When that layer is IEEE [802.3], it is prefixed with the 16-bit TRILL Ethertype, making it 64 bit aligned. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V | R |M|Op-Length| Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress RBridge Nickname | Ingress RBridge Nickname | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3.1: TRILL Header The header contains the following fields which are described in the sections referenced: o V (Version): 2-bit unsigned integer. See Section 3.2. o R (Reserved): 2 bits. See Section 3.3. o M (Multi-destination): 1 bit. See Section 3.4. o Op-Length (Options Length): 5-bit unsigned integer. See Section 3.5. o Hop Count: 6-bit unsigned integer. See Section 3.6. o Egress RBridge Nickname: 16-bit identifier. See Section 3.7.1. o Ingress RBridge Nickname: 16-bit identifier. See Section 3.7.2. 3.2 Version (V) A single Ethertype is granted to a protocol and, under IEEE guidelines, it is the protocol's responsibility to structure itself to support future revisions. Adhering to this guideline, there is a two bit Version field in the TRILL header. Version zero of TRILL is specified in this document. An RBridge that sees a message with a Version value it does not understand MUST silently discard the message because it may not be able to parse it. R. Perlman, et al [Page 19] INTERNET-DRAFT RBridge Protocol 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 zero on transmission and are ignored on receipt. 3.4 Multi-destination (M) The Multi-destination bit (see Section 2.2.2) indicates that the frame is to be delivered to a class of destination end stations via a distribution tree and that the egress RBridge nickname field specifies the root RBridge for this tree. In particular: o M = 0 (FALSE) - The egress RBridge nickname contains the nickname of the egress Rbridge for a known unicast TRILL data frame or is zero for a core instance TRILL IS-IS frame; o M = 1 (TRUE) - The egress RBridge nickname field contains the nickname of the RBridge that is the root of a distribution tree. This tree is selected by the ingress RBridge for a TRILL data frame or by the source RBridge for an end station address distribution TRILL IS-IS frame. 3.5 TRILL Header Options The TRILL Protocol includes an option capability in the TRILL Header. The Op-Length header field gives the length of the 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. All Rbridges MUST be able to skip the number of 4-octet chunks indicated by the Op-Length field in order to find the inner frame, since RBridges must be able to find the destination MAC address and VLAN tag in the inner frame. (Transit RBridges need such information to filter VLANs, IP multicast, and the like. Egress Rbridges need to find the inner frame to correctly decapsulate and dispose of the inner frame.) To ensure backward compatible safe operation, when Op-Length is non- zero indicating that options are present, the top two bits of the first byte of the options area are specified as follows: R. Perlman, et al [Page 20] INTERNET-DRAFT RBridge Protocol +------+------+----+----+----+----+----+----+ | CHbH | CItE | Reserved | +------+------+----+----+----+----+----+----+ Figure 3.2: Options Area Initial Flags Byte If the CHbH (Critical Hop by Hop) bit is one, one or more critical hop-by-hop options are present so transit RBridges that support no options MUST drop the frame. If the CHbH bit is zero, the frame is safe, from the point of view of options, for a transit RBridge. A transit RBridge that supports no options and forwards a frame MUST transparently forward the options area. If the CItE (Critical Ingress to Egress) bit is a one, one or more critical ingress-to-egress options are present. If it is zero, no such options are present. If either CHbH or CItE is non-zero, egress RBridges that support no options MUST drop the frame. If both CHbH and CItE are zero, the frame is safe, from the point of view of options, for any egress RBridge to process. Options will be further specified in other documents and are expected to include provisions for hop-by-hop and ingress-to-egress options as well as critical and non-critical options. A critical option is one which must be understood to safely process a frame. A non-critical option can be safely ignored. Warning: Most RBridges implementations are expected to be optimized for the simplest and most common cases of frame forwarding and processing. The inclusion of any options may, and the inclusion of complex or lengthy options almost certainly will, cause frame processing using a "slow path" with markedly inferior performance to "fast path" processing. Limited slow path throughput may cause such frames to be lost. 3.6 Hop Count The Hop Count field is a 6-bit unsigned integer. Each RBridge that is about to forward a frame to another RBridge MUST check this field and discard the frame if this field is zero. If this field is greater than or equal to 1, it MUST be decremented in the forwarded frame. For known unicast frames, the ingress RBridge MUST set the Hop Count to at least the number of RBridge hops it expects to the egress RBridge and SHOULD set it in excess of that number to allow for alternate routing later in the path. For multi-destination frames, the Hop Count MUST be set by the ingress RBridge (or source RBridge for an end station address R. Perlman, et al [Page 21] INTERNET-DRAFT RBridge Protocol distribution TRILL IS-IS frame) to at least the expected number of hops to the most distant RBridge and SHOULD NOT be set in excess of that amount. To accomplish this, RBridge RBn calculates, for each branch from RBn of the distribution tree rooted at RBi, the maximum number of hops in that branch. When forwarding a multi-destination frame onto a branch, transit RBridge RBm MAY decrease the hop count by more than 1 so as to set the hop count to be no more than necessary to reach all destinations in that branch of the tree rooted at RBi. This minimal Hop Count on multi-destination frames is to reduce potential problems with temporary loops when forwarding. Although the RBridge MAY decrease the hop count 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. 3.7 RBridge Nicknames Nicknames are 16-bit dynamically assigned abbreviations for each RBridge's 48-bit IS-IS System ID to achieve a more compact encoding. This assignment allows specifying up to 2**16 RBridges; however, 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 a nickname unique within the campus. 3.7.1 Egress RBridge Nickname There are three cases for the contents of the egress RBridge nickname field, depending on the M-bit (see Section 3.4) and the Inner.MacDA (see Section 4.1). It is filled in by the ingress RBridge for TRILL data frames and by the source RBridge for TRILL IS-IS frames. Once the egress nickname field is set, it MUST NOT be changed by any subsequent transit RBridge. o For known unicast TRILL data frames, M == 0, the Inner.MacDA is not All-IS-IS-RBridges, and the egress RBridge nickname field specifies the egress RBridge i.e. it specifies the RBridge that needs to remove the TRILL encapsulation from the native frame. o For core instance TRILL IS-IS frames, M == 0, the Inner.MacDA is All-IS-IS-Rbridge, and the egress RBridge nickname field is not used. Such frames may be sent before nicknames have been established and are only sent one hop. The Egress RBridge Nickname R. Perlman, et al [Page 22] INTERNET-DRAFT RBridge Protocol MUST be set to zero by the source RBridge for such frames and is ignored by other RBridges. o For multi-destination TRILL data frames and for ESADI (end station address distribution instance) TRILL IS-IS frames, M == 1. The egress RBridge nickname field contains the nickname of the root RBridge of the distribution tree selected to be used to forward the frame. This root MUST NOT be changed by transit RBridges. 3.7.2 Ingress RBridge Nickname The ingress RBridge nickname is set to the nickname of the ingress RBridge for all TRILL data frames and to the nickname of the source RBridge for all ESADI (end station address distribution instance) TRILL IS-IS frames. For core TRILL IS-IS frames, which may be sent before nicknames have been established, the ingress nickname MUST be set to zero by the source RBridge and is ignored by receiving RBridges. Once the ingress nickname field is set, it MUST NOT be changed by any subsequent transit RBridge. 3.7.3 RBridge Nickname Allocation The nickname allocation protocol is piggybacked on the core TRILL IS- IS instance as follows: o The nickname being used by an RBridge is carried in an IS-IS TLV (type-length-value data element) along with a priority of use value. Each RBridge chooses its own nickname. o The nickname value MAY be configured. An RBridge that has been configured with a nickname value will have priority for that nickname value over all Rbridges with non-configured nicknames. o The nickname values 0x0000 and 0xFFC0 through 0xFFFF are reserved and MUST NOT be selected or configured. In some cases the value 0x0000 is used to indicate that the nickname is not known. o 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 value 0x40, but MAY be configured to be some other value. Additionally, an RBridge MAY increase its priority after holding the nickname for some amount of time. However, the most R. Perlman, et al [Page 23] INTERNET-DRAFT RBridge Protocol significant bit of the priority MUST NOT be set unless the nickname value was configured. o Once an RBridge has successfully acquired a nickname it SHOULD attempt to reuse it in the case of a reboot. o Each RBridge is responsible for ensuring that its nickname is unique. If RB1 chooses nickname x, and RB1 discovers, through receipt of RB2's LSP, that RB2 has also chosen x, then the RBridge with the numerically higher priority 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 choose a new nickname. This can require an RBridge with a configured nickname to select a different nickname. o 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 choose new nicknames that do not, to the best of their knowledge, collide with any existing nicknames. Some RBridges may need to change their nickname more than once before the situation is resolved. To minimize the probability of nickname collisions, each RBridge, when choosing its nickname, does so by randomly hashing some of its parameters, e.g., interface MAC addresses, time and date, and other entropy sources such as those given in [RFC4086]. There is no reason for all Rbridges to use the same algorithm for choosing nicknames. To minimize the probability of a new RBridge usurping a nickname already in use, an RBridge whose nickname is not configured SHOULD wait to acquire the link state database from a neighbor before it announces its own nickname. An RBridge that will not act as an ingress, egress, or tree root need not have a nickname. R. Perlman, et al [Page 24] INTERNET-DRAFT RBridge Protocol 4. Other RBridge Design Details Section 3 above specifies the TRILL header, while this Section specifies other RBridge design details. 4.1 Ethernet Data Encapsulation TRILL frames in transit on Ethernet links are encapsulated with an outer Ethernet header (see Figure 2.2). This outer header looks, to a bridge on the path between two RBridges, like the header of a regular Ethernet frame and therefore bridges forward the frame without requiring any modification. To enable RBridges to distinguish TRILL frames, a new TRILL Ethertype (see Section 7.2) is used in the outer header. Figure 4.1 details a TRILL data frame with an outer VLAN tag traveling on an Ethernet link as shown at the top of the Figure, that is, between transit RBridges RB3 and RB4 where the native frame originated at end station ESa, was encapsulated by ingress RBridge RB1 and will ultimately be decapsulated by egress RBridge RB2 and delivered to destination end stations ESb. The encapsulation show in Figure 4.1 has the advantage, in the absence of TRILL options, of aligning the original Ethernet frame at a 64-bit boundary. When a TRILL data frame is carried over an Ethernet cloud it has three pairs of addresses: o Outer Ethernet Header: Outer Destination MAC Address (Outer.MacDA) and Outer Source MAC Address (Outer.MacSA): These addresses are used to specify the next hop RBridge and the transmitting RBridge, respectively. o TRILL Header: Egress Nickname and Ingress Nickname. These specify the nickname values of the egress and ingress RBridges, respectively, for TRILL data frames unless they are multi- destination in which case the Egress Nickname specified the root of the distribution tree on which the frame is being sent. o Inner Ethernet Header: Inner Destination MAC Address (Inner.MacDA) and Inner Source MAC Address (Inner.MacSA): These addresses are as transmitted by the original end station, specifying, respectively, the destination and source of the inner frame. A TRILL data frame also potentially has two VLAN tags that can carry two different VLAN Identifiers and specify priority. R. Perlman, et al [Page 25] INTERNET-DRAFT RBridge Protocol 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] | 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] | Inner.VLAN Tag Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethertype of Original Payload | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Original Ethernet Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Frame Check Sequence: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | New FCS (Frame Check Sequence) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4.1: TRILL Data Encapsulation over Ethernet R. Perlman, et al [Page 26] INTERNET-DRAFT RBridge Protocol 4.1.1 VLAN Tag Information A "VLAN Tag", also known as a "C-tag" (formerly Q-tag) for customer tag, includes a VLAN ID and a priority field as shown in Figure 4.2. The "VLAN ID" may be zero, indicating the no VLAN is specified, just a priority, although such a tag is properly called a "priority tag" rather than a "VLAN Tag" [802.1Q]. (Use of 802.1Q S-tags (service tag) is beyond the scope of this document.) +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | Priority | C | VLAN ID | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Figure 4.2: VLAN Tag Information As recommended in [802.1Q], Rbridges SHOULD be implemented so as to allow use of the full range of VLAN IDs from 0x001 through 0xFFE. VLAN ID zero is the null VLAN identifier and indicates that no VLAN is specified while VLAN ID 0xFFF is reserved. Rbridges MAY support a smaller number of simultaneously active VLAN IDs than the total number of different VLAN IDs they allow. The VLAN ID 0xFFF is reserved and MUST NOT be used. Rbridges MUST discard any frame they receive with an Outer.VLAN ID of 0xFFF. Rbridges MUST discard any frame for which they examine the Inner.VLAN ID and find it to be 0xFFF; such examination is required at all egress Rbridges which decapsulate a frame. The "C" bit shown in Figure 4.2 is not used in TRILL. It MUST be set to zero and is ignored by receivers. As specified in [802.1Q], the priority field contains an unsigned value from 0 through 7 where 1 indicates the lowest priority, 7 the highest priority, and the default priority zero is considered to be higher than priority 1 but lower than priority 2. The [802.1ad] amendment to [802.1Q] permits mapping some adjacent pairs of priority levels into a single priority level with and without drop eligibility. RBridges MAY also implement such configuration options. RBridges are not required to implement any particular number of distinct priority levels but may treat one or more adjacent priority levels in the same fashion. Frames with the same source address, destination address, VLAN, and priority that are received on the same port and transmitted on the same port MUST be transmitted in the order received. (Such frames might not be sent out the same port if multipath is implemented. See Appendix C.) Differing priorities can cause frame re-ordering. R. Perlman, et al [Page 27] INTERNET-DRAFT RBridge Protocol The C-Tag Ethertype is 0x8100. 4.1.2 Inner VLAN Tag The "Inner VLAN Tag Information" (Inner.VLAN) field contains the VLAN tag information associated with the native frame when it was ingressed or the VLAN tag information associated with an ESADI (end station address distribution instance) TRILL IS-IS message when that message is created. When a TRILL frame passes through a transit RBridge, the Inner.VLAN MUST NOT be changed. When a native frame arrives at an RBridge, the associated VLAN ID and priority are determined as specified in [802.1Q] (see Appendix D and [802.1Q] Section 6.7). If the RBridge is an appointed forwarder for that VLAN and the delivery of the frame requires transmission to one or more other RBridges, this ingress RBridge forms a TRILL data frame with the associated VLAN ID and priority placed in the Inner.VLAN Information. Thus, in TRILL data frames, the Inner.VLAN tag always specifies a VLAN ID. The VLAN ID is required at the ingress Rbridge as one element in determining the appropriate egress Rbridge for a known unicast frame and is needed at the ingress and every transit Rbridge for multi- destination frames to correctly prune the distribution tree. 4.1.3 Outer VLAN Tag TRILL frames sent by an RBridge, except for some TRILL IS-IS Hellos, use an Outer.VLAN ID specified by the Designated RBridge (DRB) for the link onto which they are being sent, referred to as the Designated VLAN. Transit RBridges forward TRILL frames with the priority present in the Inner.VLAN of the frame as received. TRILL data frames are sent with the priority associated with the corresponding native frame when it is ingressed (see Appendix D). TRILL IS-IS frames are sent with priority 7. Whether an Outer.VLAN tag actually appears on the wire when a TRILL frame is sent depends on the configuration of the RBridge port through which it is sent in the same way as the appearance of a VLAN tag on a frame sent by an [802.1Q] frame depends on the configuration of the bridge port (see Section 4.7). R. Perlman, et al [Page 28] INTERNET-DRAFT RBridge Protocol 4.1.4 Frame Check Sequence (FCS) Each Ethernet frame has a single Frame Check Sequence (FCS) that is computed to cover the entire frame, for detecting errors due to communications failures. It is typically calculated shortly before transmission and checked on receipt. Any frame for which the FCS check fails MUST be discarded. The FCS normally changes on encapsulation, decapsulation, and every TRILL hop due to changes in the outer destination and source addresses, the decrementing of the hop count, etc. Although, as stated above, the FCS is normally calculated just before transmission, it is desirable, when practical, for an FCS to accompany a frame within an RBridge after receipt. That FCS could then be dynamically updated to account for changes to the frame during Rbridge processing and used for transmission or checked against the FCS calculated for frame transmission. This optional, more continuous use of an FCS would be helpful in detecting a class of internal RBridge failures such as memory errors. 4.2 Link State Protocol (IS-IS) TRILL uses IS-IS [ISO10589] as the routing protocol since it has the following advantages: o it runs directly over Layer 2, so therefore may be run with zero configuration (no IP addresses need to be assigned); o it is easy to extend by defining new TLV (type-length-value) data elements and sub-elements for carrying TRILL information; 4.2.1 IS-IS RBridge Identity Each RBridge has a unique unsigned 48-bit (6-octet) IS-IS System ID. This ID may be derived from any of the RBridge's unique MAC addresses. A pseudonode is assigned a 7-byte ID by the DRB that created it, usually by taking a 6-byte ID owned by the DRB, and appending another byte. The only constraint is that the 7-byte ID be unique within the campus, and that the 7th byte be nonzero. An RBridge has a 7 byte ID consisting of its 6-byte system ID concatenated with a byte of 0. In this document we use the term "IS-IS ID" to refer to the 7 byte quantity, that can either be the ID of an RBridge or a pseudonode. R. Perlman, et al [Page 29] INTERNET-DRAFT RBridge Protocol 4.2.2 IS-IS Instances TRILL implements separate IS-IS instances from any used by Layer 3, that is, 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 a campus and are TRILL encapsulated. Layer 3 IS-IS native frames have a special multicast destination address, either AllL1ISs or AllL2ISs. When they are TRILL encapsulated, these multicast addresses appear as the Inner.MacDA. TRILL IS-IS messages are always encapsulated and always have a different Inner.MacDA, namely All-IS-IS-Rbridges. Within TRILL, there is a mandatory core IS-IS instance across all Rbridges in the campus as described in Section 4.2.3. In addition, there can be optional end station address distribution instances (ESADIs) between the RBridges on each supported VLAN as described in Section 4.2.4. They are distinguished by the presence of an inner VLAN tag in the ESADI TRILL IS-IS frames and the absence of such a tag in the core instances frames. 4.2.3 Core TRILL IS-IS All Rbridges must participate in the core TRILL IS-IS instance. Core instance frames are never forwarded by an RBridge but are decapsulated and locally processed. (Such processing may cause the RBridge to send additional core IS-IS instance frames.) 4.2.3.1 Core IS-IS Link Protocol RBridges send core TRILL IS-IS Hellos on a link in order to discover RBridge neighbors. As with Layer 3 IS-IS, one RBridge is elected DRB (Designated RBridge), based on configured priority (most significant field), and system ID. The DRB, as described in Section 4.2.3.2, designates the VLAN to be used on the link for inter-RBridge communication and appoints itself or other RBridges on the link as appointed forwarder (see Section 4.2.3.3) for VLANs on the link. 4.2.3.1.1 Core Hello VLAN Tagging By default, RBridges tag TRILL IS-IS Hellos with VLAN 1. Because a link may be a bridged LAN with different connectivity for different VLANs, and since an RBridge may be configured so that it cannot use VLAN 1 on a port, Hellos may need to be sent out a port with additional and/or other VLANs for connectivity and safety. R. Perlman, et al [Page 30] INTERNET-DRAFT RBridge Protocol An RBridge RBn maintains for each port the same VLAN information as a customer IEEE [802.1Q] bridge, including the set of VLANs enabled for output through that port (see Section 4.7). In addition, RBn maintains the following TRILL specific VLAN parameters per port: a) Desired Designated VLAN: the VLAN that RBn, if it is DRB, will specify in its Hellos to be used by all RBridges on the link to communicate all TRILL frames, except some 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 zero configuration RBridge. b) Designated VLAN: the VLAN being used on the link for all TRILL frames except some Hellos. This is set from RBn's Desired Designated VLAN if RBn believes it is DRB or from the Designated VLAN in the DRB's Hellos if RBn is not DRB. c) Announcing VLANs set. This defaults to the enabled VLANs set on the port but may be configured to be a subset of the enabled VLANs. d) Forwarding VLANs set: the set of VLANs for which an RBridge port is appointed VLAN forwarder on the port. This, by definition, may only contain enabled VLANs for the port, possibly all enabled VLANs. On each of its ports an RBridge sends Hellos Outer.VLAN tagged with each VLAN in a set of VLANs. For each port, this set depends on the RBridge's DRB status and the above VLAN parameters. All RBridges send Hellos Outer.VLAN tagged with the Designated VLAN, unless that VLAN is not enabled. In addition, the DRB sends Hellos Outer.VLAN tagged with each enabled VLAN in its Announcing VLANs set. All non-DRB RBridges send 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, Hellos are sent as follows: If it is DRB intersection ( Enabled VLANs, union ( Designated VLAN, Announcing VLANs ) ) If it is not DRB intersection ( Enabled VLANs, union ( Designated VLAN, intersection ( Forwarding VLANs, Announcing VLANs ) ) ) Configuring the Announcing VLANs set to be null minimizes the number of Hellos. In that case, Hellos are only tagged with the Designated VLAN. The number of Hellos is maximized, within this specification, by R. Perlman, et al [Page 31] INTERNET-DRAFT RBridge Protocol configuring the Announcing VLANs set to be the set of all enabled VLAN IDs, which is the default. In that case, the DRB will send Hellos tagged with all its Enabled VLAN tags and any non-DRB RBridge RBn will send Hellos tagged with the Designated VLAN, if enabled, and tagged with all VLANs for which RBn is an appointed forwarder. (It is possible to send even more Hellos. In particular, non-DRB RBridges could send Hellos on enabled VLANs for which they are not an appointed forwarder and which are not the Designated VLAN. This would not cause harm, other than a further communications and processing burden.) When an RBridge port comes up, until it has heard a Hello from a higher priority RBridge, it considers itself to be DRB on that port and sends Hellos on that basis. Similarly, even if it has at some time recognized some other RBridge on the link as DRB, if on that port it receives no Hellos from an RBridge with higher priority as DRB for a long enough time, as specified by IS-IS, it will revert to believing itself DRB. Note that an RBridge RBn does not defer to the DRB listed in a Hello, even if that claimed DRB is higher priority, if the Hello was sent by an RBridge with lower priority than RBn. 4.2.3.1.2 Core Hello Contents A core TRILL IS-IS Hello includes the following information, in addition to the standard IS-IS Hello header information. The actual encoding of this information and the IS-IS Type or sub-Type values for the TLV or sub-TLV data elements are specified in a separate document. 1. The VLAN ID of the Designated VLAN for the link. 2. In connection with VLAN mapping (see Section 4.2.3.1.3): 2.a A copy of the Outer.VLAN ID with which the Hello was tagged. 2.b A flag which, if set, indicates that the sender has detected VLAN mapping on the link, within the past five Hello times. 3. The set of VLANs for which end station service is enabled on the port. If this is missing or null, it implies that the port is configured as a trunk port (see Section 4.7). This MAY be omitted if the sender is DRB. 4. A flag which, if set, indicates that the sender believes it is appointed forwarder for the VLAN and port on which the Hello was sent. 5. A flag which, if set, indicates that the sender's port was configured as an access port. The value of this flag for the DRB controls and when it is asserted by the DRB all ports on that link R. Perlman, et al [Page 32] INTERNET-DRAFT RBridge Protocol which recognize the DRB act as access ports. 6. If the sender is DRB, the Rbridges (including itself) that the sender appoints as forwarders for that link and the VLANs for which it appoints them. 7. TRILL connectivity over which TRILL data and non-Hello TRILL IS-IS frames will be sent is only established on the Designated VLAN. Establishing such connectivity requires exchange of Hellos containing the IS Neighbor TLV, so that TLV MUST be included in Hellos sent on the Designated VLAN. The Neighbor TLV MAY be send on other VLANs but neighbor status is only established and updated based on Hellos on the Designated VLAN. It is anticipated that many links between RBridges will be point-to- point in which case a pseudonode merely adds to the complexity. If the DRB specifies the pseudonode ID as all zeros, this indicates that the RBridges on the link are just to report their adjacencies as point-to-point. This has no effect on how LSPs are flooded on a link. It only affects what LSPs are generated. For example, if RB1 and RB2 are the only RBridges on the link and RB1 is DRB, then if RB1 creates a pseudonode there are 3 LSPs: for, say, RB1.25 (the pseudonode), RB1, and RB2, where RB1.25 reports connectivity to RB1 and RB2, and RB1 and RB2 each just say they are connected to RB1.25. Whereas if DRB R1 declares no pseudonode, then there will be only 2 LSPs: RB1 and RB2 each reporting connectivity to each other. A DRB SHOULD NOT create a pseudonode for its link unless it has seen at least two simultaneous adjacencies on the link at some point since it last re-booted or in certain cases for access ports (see Section 4.7). 4.2.3.1.3 VLAN Mapping IEEE [802.1Q] does not provide for bridges changing the C-tag VLAN ID for a tagged frame they receive, that is, mapping VLANs. Nevertheless, some bridge products provide this capability and, in any case, bridged LANs can be configured to display this behavior. For example, a bridge port can be configured to strip certain VLAN tags on output and send the resulting untagged frames onto a link leading to another bridge's port configured to tag these frames with a different VLAN. Although each port's configuration is legal under [802.1Q], in the aggregate they perform manipulations not permitted within a single customer 802.1Q bridge. Since RBridge ports have the same VLAN capabilities as customer 802.1Q bridges, this can occur even in the absence of bridges. RBridges include the Outer.VLAN ID inside a TLV within each Hello R. Perlman, et al [Page 33] INTERNET-DRAFT RBridge Protocol message. When a Hello is received, they 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 and the Outer.VLAN is Y, it can be assumed that VLAN ID X is being mapped into VLAN ID Y. When a VLAN mapping is detected, the RBridge detecting it sets a flag in all Hellos it sends on the link for the during the subsequent five Hellos times. This notifies the DRB if the detecting RBridge is not the DRB. The DRB then assures that only one RBridge (either the DRB itself or some RBridge it appoints) is appointed forwarder for any VLANs on the link. This avoids loops and duplication of frames with different VLAN tags. 4.2.3.2 Designated RBridge TRILL IS-IS elects one RBridge for each link to be the Designated RBridge (DRB), that is, to have special duties. The Designated RBridge: o Chooses, for the link, and announces in its Hellos, the Designated VLAN ID to be used for inter-RBridge communication. This VLAN is used for all TRILL data frames and all non-Hello TRILL IS-IS frames. TRILL IS-IS Hellos are sent on this VLAN but are usually also sent on others (see Section 4.2.3.1.1). o If the link is represented in the IS-IS topology as a pseudonode, chooses a pseudonode ID and announces that in its Hello and issues an LSP on behalf of the pseudonode. o Issues CSNPs. o 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). o Before appointing a VLAN-x forwarder (including appointing itself), wait at least 5 Hello intervals (to ensure it is DRB). o Continues sending IS-IS Hellos on all its enabled VLANs that have been configured in the Announcing VLANs set of the DRB, which defaults to all enabled VLANs. R. Perlman, et al [Page 34] INTERNET-DRAFT RBridge Protocol 4.2.3.3 Appointed VLAN-x Forwarder The appointed VLAN-x forwarder for a link is responsible for the following: o Unless inhibited (see below), receiving VLAN-x native traffic from the link and, as appropriate, forwarding it in native and/or encapsulated form. o Receiving VLAN-x traffic for the link and, if uninhibited, transmitting it in native form after decapsulating it as appropriate. o Learning the MAC address of local VLAN-x nodes by looking at the source address of VLAN-x frames from the link. o Optionally learning the port of local VLAN-x nodes based on any sort of Layer 2 registration protocols. o 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. o Optionally listening to the messages in the TRILL IS-IS end station address distribution instance (ESADI) for VLAN-x to learn { egress RBridge, VLAN-x, MAC address } triplets and the confidence level of such explicitly advertised end nodes. o Optionally advertising VLAN-x end nodes, on links for which it is appointed VLAN-x forwarder, in a TRILL IS-IS ESADI. o 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. o Loop avoidance: - Inhibiting itself for a configurable time from 30 to zero seconds, which defaults to 30 second, after it sees a root bridge change on the link (see Section 4.7.1.1). - Inhibiting itself if, within the past five Hello times, it has received a Hello on VLAN-x in which the sender asserts that it is appointed forwarder for VLAN-x. - Optionally, not decapsulating a frame from ingress RBridge RBm unless 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 R. Perlman, et al [Page 35] INTERNET-DRAFT RBridge Protocol bridges for VLAN-x. This is known as the "decapsulation check" or "root bridge collision check". o Including a "port number" in its Hellos, and if it sees its own Hello on port p, where the port number in the received Hello is "q", then if q>p, not forwarding traffic to/from port p, as already provided in IS-IS. 4.2.3.4 Core TRILL IS-IS LSP Information The information in the TRILL IS-IS LSP for the mandatory core instance is listed below. The actual encoding of this information and the IS-IS Type or sub-Type values for any new IS-IS TLV or sub- TLV data elements are specified in a separate document. 1. 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 except for neighbors reached through certain access ports (see Section 4.7). 2. If an RBn is to be able to act as an ingress, egress, or tree root, the nickname of RBridge RBn (2 octets) and the unsigned 8-bit priority for RBn to have that nickname (see Section 3.7.3). 3. The TRILL Header Versions supported by RBridge RBn (4 bits). 4. The priority of RBn for becoming a distribution tree root and the number of additional distribution trees it wants computed for the campus (each 16 bits, see Section 4.3). 5. The list of RBridge nicknames that RBn might select for a distribution tree root when RBn injects a multi-destination frame into the campus. These tree roots MUST be from the set of roots for the distribution trees which all RBridges in the campus are computing (see Section 4.3). Using this field RBridges can efficiently build receipt filters to avoid multicast loops (see Section 4.3.1). If the list is empty or not provided, RBn can only select the highest priority distribution tree root for the campus. 6. 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.6.3 or in other documents.) In addition, the LSP contains the following information on a per-VLAN basis: R. Perlman, et al [Page 36] INTERNET-DRAFT RBridge Protocol 6.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 which does not do IP multicast control snooping MUST set both of these bits (see Section 4.3.3). 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. 6.2 Per VLAN Other Multicast flag. This is a flag bit that indicates that the RBridge wishes to receive non-IP derived multicast for that VLAN. It defaults to true (one). Within each VLAN, all non-IP derived multicast traffic MUST be sent to an RBridge that asserts this flag. 6.3 Per VLAN mandatory announcement of the set of IDs of Root bridges for any of RBn's links on which RBn is 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.3.3.) 6.4 Optionally, per VLAN Layer 2 multicast addresses derived from IPv4 IGMP or IPv6 MLD notification messages received from attached end nodes on that VLAN, indicating the location of listeners for these multicast addresses (see Section 4.3.4). 6.5 Per VLAN end station address distribution instance (ESADI) TRILL IS-IS participation flag, priority, and holding time. If this flag is one, it indicates that the RBridge wishes to receive such ESADI frames (see Section 4.2.4.1). 6.6 Per VLAN appointed forwarder status lost counter (see Section 4.6.2). 7. Optionally, a list of VLAN groups where address learning is shared across that VLAN group (see Section 4.6.3). Each VLAN group is a list of VLAN IDs, with 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. R. Perlman, et al [Page 37] INTERNET-DRAFT RBridge Protocol 4.2.4 End Station Address Distribution Instance (ESADI) IS-IS RBridges that are the appointed VLAN-x forwarder for a link MAY participate in the TRILL end station address distribution instance (ESADI) of IS-IS for that VLAN. But all transit RBridges MUST properly forward ESADI TRILL IS-IS frames as if they were multicast TRILL data frames. Because of this forwarding, it appears to an IS-IS ESADI at an RBridge that it is directly connected by a shared virtual link to all other RBridges in the campus running that instance. RBridges that do not implement that ESADI or are not appointed forwarder for that VLAN do not decapsulate or locally process any ESADI IS-IS frames they receive for that VLAN. In other words, these frames are transparently tunneled through transit RBridges. Such transit RBridges treat them exactly as multicast TRILL data frames and no IS-IS processing is invoked due to such forwarding. 4.2.4.1 ESADI Protocol An RBridge participating in an end station address distribution instance (ESADI) does not send any additional Hellos. The information available in the core TRILL IS-IS link state database is sufficient to determine the DRB on the virtual link for each VLAN's ESADI. In particular, the core link state database information for each RBridge includes the VLANs, if any, for which that RBridge is participating in an ESADI, its priority for being selected as DRB for each of those instances, its holding time, and its IS-IS system ID for breaking ties in priority. The DRB, for an ESADI, sends TRILL IS-IS CSNP messages on the ESADI virtual link. A participating RBridge that determines that some other RBridge should be DRB on such a virtual link and has not received or sent a CSNP in at least the DRB holding time MAY also send a CSNP on the virtual link. A participating RBridge that determines that no other RBridges are participating in an ESADI for a particular VLAN SHOULD NOT send ESADI LSPs or CSNPs on the virtual link. 4.2.4.2 ESADI Information The information in the LSP for a optional TRILL IS-IS ESADI is the list of local end station MAC addresses known to the originating RBridge and for each such address a one octet unsigned "confidence" rating in the range 0-254 (see Section 4.6). In order to make it practical to optionally provide for customer VLAN ID translation, as specified in a separate document, ESADI LSPs MUST NOT contain the R. Perlman, et al [Page 38] INTERNET-DRAFT RBridge Protocol VLAN ID in the body of the frame after the Inner.VLAN tag. 4.3 Distribution Trees RBridges use distribution trees to forward multi-destination frames (see Section 2.2.2). Distribution Trees are bidirectional. Although a single tree is logically sufficient for the entire campus, the computation of additional distribution trees is warranted for the following reasons: it enables multipathing of multi-destination frames and enables the choice of a tree root closer to or, in the limit, identical with the ingress RBridge. Such a closer tree root reduces out-of-order delivery when a unicast address transitions between unknown and known and improves the efficiency of the delivery of multi-destination frames that are being delivered to a subset of the links in the campus. Each RBridge RBn may advertise in the core instance link state database its priority to be chosen as a tree root and the number of additional distribution trees it specifies that every RBridge in the campus must compute if RBn is the highest priority tree root. The priority is a 16-bit unsigned integer that defaults, for a zero configuration RBridge to 0x8000. The number of distribution trees to be computed is a 16-bit unsigned integer giving the number of trees to be computed in addition to the one rooted at the highest priority root. The number of additional trees defaults, for a zero configuration RBridge, to one. The RBridge with highest priority to be tree root is determined by the numerically lowest priority field or, if priority fields are equal, by the numerically lowest system ID. A tree is always calculated rooted at this highest priority RBridge and that RBridge specifies to all RBridges in the campus the total number of additional distribution trees to be calculated. If it indicates that K-1 additional trees are to be calculated, then they are rooted at the 2nd through the Kth highest priority RBridges. Thus every RBridge calculates the same set of K distribution trees. Every RBridge RBn defaults, in the zero configuration case, to using a single distribution tree for multi-destination frames. For this purpose, it orders the trees being computed for the campus in order of increasing cost from RBn to the root RBridge of that tree and, if cost is equal, by decreasing priority to be a tree root and selects the first tree in that ordering. If RBn is to multi-path multi-destination frames, it can be configured with the number of different trees it would like to use, say J. RBn selects the first trees in its priority-of-use ordering, up to the minimum of J and K number of trees. However, RBn MUST R. Perlman, et al [Page 39] INTERNET-DRAFT RBridge Protocol announce, in its LSP, an intention to use any particular trees by listing the tree root, unless it is content to only use the highest priority tree root in the campus. 4.3.1 Distribution Tree Calculation and Checks RBridges do not use the spanning tree protocol to calculate distribution trees. Instead, distribution trees are calculated based on the link state information, selecting a particular RBridge as the root. Each RBridge RBn independently calculates a tree rooted at RBi by performing the SPF (Shortest Path First) calculation with RBi as the root without requiring any additional exchange of information. When a node RBn has two or more minimal equal cost paths toward the Root RBi, a deterministic tiebreaker is needed to guarantee that all Rbridges calculate the same distribution tree. This is obtained by selecting the path that goes to the parent that has the lower 7-byte IS-IS ID. 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. 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. To further avoid temporary multicast loops during topology changes, RBridges MUST do a sanity check that a multi-destination frame arrives on the expected link. This is called the Reverse Path Forwarding Check and is done as follows. When RBn calculates the RBi tree, for each adjacency in the RBi tree, RBn lists the possible ingress RBridge nicknames on that adjacency. The only ingress RBridges that appear on any of the adjacencies are RBridges that have explicitly stated, in their LSP, that they may select RBi as a distribution tree root or ingress RBridges that list no roots on adjacencies for the distribution tree with the highest priority root. If a multi-destination frame is received on a particular adjacency, marked as the RBi-tree, then RBn MUST NOT forward it if the ingress RBridge is not listed in the allowed list of ingress RBridges for that adjacency for that tree. When a topology change occurs (including apparent changes during start up), an RBridge MUST adjust its input distribution tree filters no later than it adjusts its output forwarding. R. Perlman, et al [Page 40] INTERNET-DRAFT RBridge Protocol 4.3.2 Pruning the Distribution Tree Each distribution tree SHOULD be pruned per-VLAN eliminating 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 several cases: (1) IGMP [RFC3376], MLD [RFC2710], and MRD [RFC4286] messages, where these are to be delivered only to links with IP Multicast routers; (2) other multicast frames derived from an IP multicast address that should be delivered only to links that have registered listeners, plus links which have IP Multicast routers, except for IP multicast addresses which must be broadcast; and (3) other multicast traffic not derived from an IP address that is only delivered to links for which the appointed forwarder has the Other Multicast requested flag set. All of these cases are scoped per-VLAN. Let's assume that RBridge RBn knows that adjacencies (a, c, and f) are in the RBi-distribution tree. RBn marks pruning information for each of the adjacencies in the RBi-tree. For each adjacency and for each tree, RBn marks: o the set of VLANs reachable downstream, o for each one of those VLANs, flags indicating whether there are IPv4 or IPv6 multicast routers downstream, and whether there are one or more RBridges downstream with the Other Multicast flag set, and o the set of Layer 2 multicast addresses derived from IP multicast groups for which there are receivers downstream. 4.3.3 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. They 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 frames that should have been VLAN pruned earlier in the tree distribution. They silently discard such frames. A campus may contain some Rbridges that prune on VLAN and some that do not. 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.5 below. And they SHOULD prune the distribution of IP derived multicast R. Perlman, et al [Page 41] INTERNET-DRAFT RBridge Protocol frames based on such learning and 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], and 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 as any multicast traffic such reports would be requesting will be sent to such end stations under these circumstances.) A campus may contain a mixture 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.3.4 Forwarding Using a Distribution Tree With full optimization, forwarding a multi-destination data frame is done as follows: o The RBridge RBn receives a multi-destination TRILL data frame with inner VLAN-x and a TRILL header indicating that the selected tree is the RBi-tree; o if the adjacency from which the frame was received is not one of the adjacencies in the RBi-tree for the specified ingress RBridge, the frame is dropped (see Section 4.3.1); o else, if the frame is an IGMP or MLD announcement message or an MRD query message, then the frame is forwarded onto adjacencies in the RBi-tree that indicate there are downstream VLAN-x IPv4 or IPv6 multicast routers as appropriate; R. Perlman, et al [Page 42] INTERNET-DRAFT RBridge Protocol o else, if the frame is for a Layer 2 multicast address derived from an IP multicast group, but its IP address is not the range of IP multicast addresses which must be treated as broadcast, the frame is forwarded onto adjacencies in the RBi-tree that indicate there are downstream VLAN-x IP multicast routers of the corresponding type (IPv4 or IPv6), as well as adjacencies that indicate there are downstream VLAN-x receivers for that group address; o else, if the frame is for a Layer 2 multicast address not derived from an IP multicast group, then the frame is forwarded onto adjacencies in the RBi-tree that indicate there are downstream RBridges in VLAN-x with the Other Multicast flag set; o else (the inner frame is for an unknown destination or broadcast or an IP multicast address which is required to be treated as broadcast) the frame is forwarded onto an adjacency if and only if that adjacency is in the RBi-tree, and marked as reaching VLAN-x links. 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, or process the frame. ESADI (end station address distribution instance) TRILL IS-IS frames will be delivered only to RBridges that are appointed forwarders for their VLAN. Such frames look, to transit RBridges, like any multicast data frame tagged with an inner VLAN tag. Such frames will be multicast throughout the campus, like other non-IP-derived multicast data frames, on the distribution tree chosen by the RBridge which created the ESADI message, and pruned according to the inner VLAN tag. Thus all the RBridges that are appointed forwarders for a link in that VLAN receive them unless the RBridge has cleared its Other Multicast bit for that VLAN and has no appointed forwarders downstream in the tree with the Other Multicast bit set. 4.4 Frame Processing Behavior This section describes RBridge behavior for all varieties of received frames, including how they are forwarded when appropriate. Section 4.4.1 covers native frames, Section 4.4.2 covers TRILL frames, and section 4.4.3 covers control frames. Frames with a bad FCS are discarded on receipt. Source address information ( { VLAN, Outer.MacSA, port } ) is learned from any non- control frame with a unicast sources address (see Section 4.6). R. Perlman, et al [Page 43] INTERNET-DRAFT RBridge Protocol 4.4.1 Receipt of a Native Frame If end station service is disabled on the port, the frame is discarded. The ingress Rbridge RB1 determines the VLAN ID for a native frame according to the same rules as IEEE 802.1Q bridges do (see Appendix D and Section 4.7). Once the VLAN is determined, if RB1 is not the appointed forwarder for that VLAN on the port where the frame was received, the frame is discarded. If it is appointed forwarder for that VLAN and is not inhibited (see Section 4.2.3.3), then the native frame is forwarded according to 4.4.1.1 if it is unicast and according to 4.4.1.2 if it is multicast or broadcast. 4.4.1.1 Native Unicast Case If the destination MAC address of the native frame is a unicast address, the following steps are performed. The Layer 2 destination address and VLAN are looked up in the ingress RBridge's Encapsulation Database to find the egress RBridge RBm or local egress port or discover that the destination is unknown. If the destination address is known, one of the following three cases will apply: 1. If the destination is known to be on the same link from which the native frame was received, the RBridge silently discards the frame, since the destination should already have received it. 2. If the destination is known to be on a different local link for which the RBridge is also appointed forwarder for the frame's VLAN, the RBridge forwards the frame in native form to that link unless inhibited for this different local link (see Section 4.2.3.3). 3. If the destination is known to be on a link for which a different RBridge is appointed forwarder for the frame's VLAN, say RBridge RBm, then RB1 converts the native frame to a TRILL data frame with an Outer.MacSA of RB1 and an Outer.MacDA of the next hop RBridge towards RBm, a TRILL header with M = 0, the ingress nickname for RB1, and the egress nickname for RBm. If a unicast destination address is unknown, RB1 handles the frame as described in Section 4.4.1.2 for a broadcast frame except that the Inner.MacDA is the original native frame's unicast destination address. R. Perlman, et al [Page 44] INTERNET-DRAFT RBridge Protocol 4.4.1.2 Native Multicast and Broadcast Frames If the destination address of a native frame is the broadcast address or a multicast address other than All-Rbridges or All-IS-IS-Rbridges, the frame is processed as described below. A native (non-TRILL) frame sent to the All-Rbridges or All-IS-IS-Rbridges address is erroneous and is silently discarded. If the frame is a native IGMP [RFC3376], MLD [RFC2710], or MRD [RFC4286] frame, then RB1 SHOULD analyze it, learn any group membership or IP multicast router presence indicated, and announce that information for the appropriate VLAN in its LSP (see Section 4.5). For all multi-destination native frames, RB1 forwards the frame in native form to its links where it is appointed forwarder for the frame's VLAN subject to further pruning and inhibition. In addition, it converts the native frame to a TRILL data frame with Outer.MacSA of RB1 and 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 root of the distribution tree it decides to use. It then forwards the frame on the pruned distribution tree (see Section 4.3). The default is for RB1 to write into the egress nickname field the nickname for the distribution tree, from the set of distribution trees being computed by each RBridge in the campus, whose root is least cost from RB1. However, RB1 MAY choose a different distribution tree if RB1 has been configured to path-split multicast. In that case RB1 MUST select a tree by specifying an RBridge that is a distribution tree root (see Section 4.3). Also, RB1 MUST select a tree that RB1 has announced (in RB1's own LSP) to be one of those that RB1 may choose as a distribution tree or the tree with the highest priority root if none is announced. Although the Outer.MacDA is normally the All-Rbridges multicast address if, for any particular frame sent out a particular port, there is only one next hop RBridge of interest, the frame MAY be sent with the unicast Outer.MacDA of the target RBridge; however, TRILL IS-IS Hellos MUST use All-Rbridges as their Outer.MacDA. (Using a unicast Outer.MacDA is of no benefit on a point-to-point link but may result in substantial savings if the link is actually a bridged LAN with many bridged branches and end stations, to all of which the frame may get flooded if a multicast destination is used.) R. Perlman, et al [Page 45] INTERNET-DRAFT RBridge Protocol 4.4.2 Receipt of a TRILL Frame A TRILL outer Ethertype indicates a TRILL frame. Such frames will be received with an Outer.MacDA that is unicast or that is the All- RBridges multicast address. TRILL frames with any other Outer.MacDA are erroneous and are discarded except that a TRILL frame with the broadcast Outer.MacDA MAY be treated as if the Outer.MacDA was the All-Rbridges multicast address. TRILL frames received by an RBridge on a port are never blocked because of that RBridge's appointed forwarder or appointed forwarder inhibition or Designated RBridge status for that port. If the Outer.MacDA is a unicast address, the frame is discarded unless that address is the address of the receiving Rbridge. (Such discarded frames are most likely addressed to another RBridge on a multi-access link and that other Rbridge will handle them.) After the above checks, further processing of TRILL frames is independent of the Outer.MacDA. If the Version field in the TRILL Header is greater than 0, the frame is discarded. The Inner.MacDA is then tested. If it is the All-IS-IS- Rbridges multicast address, processing proceeds as in Section 4.4.2.1 below. If it is any other address, processing proceeds as in Section 4.4.2.2. 4.4.2.1 TRILL IS-IS Frames If there is no Inner VLAN tag, the frame is a core instance TRILL IS- IS frame. In that case, if M == 1, the frame is silently discarded. Otherwise, it is processed by the core IS-IS instance on RBn and is not forwarded. Note that, in this instance, nicknames may not yet have been established and the ingress and egress nickname fields are ignored. If there is an Inner VLAN tag, the frame is an ESADI (end station address distribution instance) TRILL IS-IS frame. If M == 0, the frame is silently discarded. The egress nickname designates the distribution tree. In this case, the frame is forwarded as described in Section 4.4.2.2.2. In addition, if the forwarding Rbridge is an appointed forwarder for a link in the specified VLAN and implements an ESADI of TRILL IS-IS for that VLAN and that instance is enabled, the inner frame is decapsulated and provided to that local IS-IS instance. R. Perlman, et al [Page 46] INTERNET-DRAFT RBridge Protocol 4.4.2.2 TRILL Data Frames The port on which the frame was received is first checked and the frame discarded if there is no TRILL core IS-IS adjacency on that port. The M flag is then checked. If it is zero, processing continues as described in Section 4.4.2.2.1, if it is one, processing continues as described in Section 4.4.2.2.2. 4.4.2.2.1 Known Unicast TRILL Data Frames If the egress RBridge indicated is the RBridge performing the processing (RBn), the frame being forwarded is decapsulated to native form. The Inner.MacDA is checked: if it is not unicast, the frame is silently discarded; if it is unicast, the frame is then either (1) sent onto the link containing the destination if the RBridge is appointed forwarder for that link for the frame's VLAN and is not inhibited, (2) locally processed if the RBridge itself is the destination, or (3) silently discarded. A known unicast TRILL data frame can arrive at the egress Rbridge only to find that the Inner.MacDA is not actually known by that RBridge. One way this can happen is that the Inner.MacDA may have timed out in the egress RBridge cache. In this case, the egress RBridge decapsulates the frame to native form and sends it out on all links that are in the frame's VLAN for which the RBridge is appointed forwarder and has not been inhibited, except that it MAY refrain from sending the frame on links where it knows there cannot be an end station with the destination MAC address, for example the link is known to be a point-to-point link to another RBridge. If RBn is a transit RBridge and the hop count is zero, the frame is silently discarded. Otherwise the hop count is decremented by one and the frame forwarded to the next hop RBridge towards the egress RBridge, using the Forwarding Database. The Inner.VLAN is not examined by a transit RBridge forwarding a know unicast TRILL data frame. If the egress RBridge is not known to the transit RBridge, the frame is silently discarded. 4.4.2.2.2 Multi-Destination TRILL Data Frames The Outer.MacSA is checked and the frame discarded if it is not a tree adjacency for the tree indicated by the egress RBridge nickname or the reverse path forwarding check fails (see Section 4.3.1). If the RBridge is an appointed forwarder for the VLAN of the frame, a copy of the frame is decapsulated, sent in native form on those links in its VLAN for which the RBridge is appointed forwarder subject to additional pruning and inhibition as described in Section 4.2.3.3, R. Perlman, et al [Page 47] INTERNET-DRAFT RBridge Protocol and/or locally processed as appropriate. If the hop count in the frame is zero, it is then silently discarded. If non-zero, it is decreased (see Section 3.6) and the frame forwarded down the tree specified by the egress RBridge nickname pruned as described in Section 4.3. In the forwarded frame, the Outer.MacSA is set to that of the port on which the frame is being transmitted and the Outer.MacDA is normally the All-Rbridges multicast address; however, if for any particular frame transmitted on a particular port there is only one next hop RBridge of interest, the frame MAY be sent with a unicast Outer.MacDA of that next hop RBridge; however, TRILL IS-IS Hellos MUST use All- Rbridges as their Outer.MacDA. (Using a unicast Outer.MacDA is of no benefit on a point-to-point link but may result in substantial savings if the link is actually a bridged LAN with many bridged branches and end stations, to all of which the frame may get flooded if a multicast destination is used.) 4.4.3 Receipt of a Control Frame Low level control frames received by an RBridge are handled within the port where they are received as described in Section 4.7. There are two types of high level control frames, distinguished by their destination address, which are handled as described in the sections referenced below. Name Section Destination Address BPDU 4.7.1 01-80-C2-00-00-00 VRP 4.7.2 01-80-C2-00-00-21 4.5 IGMP, MLD, and MRD Learning Ingress RBridges SHOULD learn, based on seeing native IGMP [RFC3376], MLD [RFC2710], and MRD [RFC4286] frames, which IP derived multicast messages should be forwarded onto which links. Such frames are also, in general, encapsulated as TRILL data frames and distributed as described below and in Section 4.3. An IGMP or MLD membership report received in native form from a link indicates 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 indicates the presence of an IP multicast router on that link. R. Perlman, et al [Page 48] INTERNET-DRAFT RBridge Protocol IP multicast group membership reports have to be sent throughout the campus and delivered to all IP multicast routers, distinguishing IPv4 and IPv6. 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 is either an IP multicast router for that IP type (IPv4 or IPv6) or an IP multicast group listener for that IP multicast derived MAC address, unless the IP multicast address is in the range required to be treated as broadcast. RBridges do not need to announce themselves as listeners to the All- Snoopers multicast group (the group used for MRD reports [RFC4541]), because the IP multicast address for that group is in the range where all frames sent to that IP multicast addresses must be broadcast. See also "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches" [RFC4541]. 4.6 End Station Address Details RBridges have to learn the MAC addresses and VLANs of their locally attached end stations for link/VLAN pairs for which they are the appointed forwarder so they can o forward the native form of incoming known unicast TRILL data frames onto the correct link and o 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 need do nothing, or - known to be destined for another end station on another local link where the RBridge is also appointed forwarder so it can be directly forwarded in native form or - neither of the above, so the frame 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 for which they and the remote RBridge are an appointed forwarder, so they can efficiently direct native frames they receive which are unicast to those addresses and VLANs. R. Perlman, et al [Page 49] INTERNET-DRAFT RBridge Protocol 4.6.1 Learning End Station Addresses There are five independent ways an RBridge can learn end station addresses as follows: 1. From the observation of VLAN-x frames received on ports where it is appointed VLAN-x forwarder, learning the { source MAC, VLAN, port } triplet of received frames. 2. The { source MAC, VLAN, ingress RBridge nickname } triplet of any native frames that it decapsulates. 3. By Layer 2 registration protocols learning the { source MAC, VLAN, port } of end stations registering at a local port. 4. By running one or more ESADIs (end stations address distribution instances) of IS-IS which receives remote information and transmits local information. 5. By management configuration. RBridges MUST implement capabilities 1 and 2 above. RBridges use these capabilities unless configured, for one or more particular VLANs and/or ports, to not learn from either received frames or from decapsulating native frames to be transmitted or both. RBridges MAY implement capabilities 3 and 4 above. If capability 4 is implemented, such ESADIs are run only 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 addresses and associated information also have a one octet unsigned confidence level associated with each entry. Such information learned from the observation of data has a confidence of 0x20 unless configured to have a different confidence. This confidence level can be configured on a per RBridge basis separately for information learned from local native frames and that learned from remotely originated encapsulated frames. Such information received via an IS-IS ESADI is accompanied by a confidence level in the range 0 to 254. Such information configured by management defaults to a confidence level of 255 but may be configured to have 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 stated databases, and (3) additional information to implement timeout of learned addresses, R. Perlman, et al [Page 50] INTERNET-DRAFT RBridge Protocol statically configured addresses, and the like. When a new learned address and related information are to be entered into the local database there are three possibilities: A. If this is a new { address, VLAN } pair, the information is entered accompanied by the confidence level. B. If there is 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 level with which it is being learned. In addition, if the information is being learned with the same or a higher confidence level than its existing confidence level, timer information is reset. C. If there is already an entry for this { address, VLAN } pair with different information, the learned information replaces the older information only if it is being learned with higher or equal confidence than that in the database entry. If it replaces older information, timer information is also reset. 4.6.2 Forgetting End Station Addresses While RBridges need to learn end station addresses as described above, it is equally important that they be able to forget such information. Otherwise, frames for end stations that have moved to a different part of the campus could be indefinitely black holed by RBridges with stale information as to the link to which the end station is attached. For end station address information locally learned from frames received, the time out from the last time a native frame was received or decapsulated with the information conforms to the recommendations of [802.1Q]. It is referred to as the "Aging Time" and is configurable per RBridge with a range of from 10 seconds to 1,000,000 seconds and a default value of 300 seconds. The situation is different for end station address information acquired via an IS-IS ESADI. It is up to the originating RBridge to decide when to remove such information from the ESADI LSP (or up to IS-IS timeouts if the originating RBridge becomes inaccessible). When an RBridge ceases to be appointed forwarder for VLAN-x on a port, it forgets all end station address information learned from the observation of VLAN-x native frames received on that port. It also increments a per VLAN counter of the number of times it lost appointed forwarder status for that VLAN. R. Perlman, et al [Page 51] INTERNET-DRAFT RBridge Protocol When, for all of its ports, RBridge RBn is no longer appointed forwarder for VLAN-x, it forgets all end station address information learned from decapsulating VLAN-x native frames. Also, if RBn is participating in an IS-IS ESADI for VLAN-x, it ceases to so participate after sending a final LSP nulling out the end station address information for that VLAN which it had been originating. In addition, all other RBridges that are VLAN-x forwarder on at least one of their ports notice that the link state data for RBn has changed to show that it no longer has a link on VLAN-x. In response, they forget all end station address information they have learned from decapsulating VLAN-x frames which show RBn as the ingress RBridge. When the appointed forwarder lost counter for RBridge RBn for VLAN-x is observed to increase via the core 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 as follows: The time remaining for each entry is adjusted to be no larger than a per RBridge configuration parameter called (to correspond to [802.1Q]) "Forward Delay". This parameter is in the range of 4 to 30 seconds with a default value of 15 seconds. 4.6.3 Shared VLAN Learning RBridges can map VLAN IDs into a smaller number of identifiers for purposes of address learning, as [802.1Q] bridges can. Then, when a lookup is done in learned address information, this identifier is used for matching in place of the VLAN ID. If the ID of the VLAN on which the address was learned is not retained, then there are the following consequences: o The RBridge no longer has the information needed to participate in an IS-IS ESADI for the VLANs whose ID is not being retained. o In cases where 4.6.2 above requires the discarding of learned address information based on a particular VLAN, when the VLAN ID is not available for entries under a shared VLAN identifier, instead the time remaining for each entry under that shared VLAN identifier is adjusted to be no longer than the RBridge's "Forward Delay". Although outside the scope of this specification, there are some Layer 2 features in which a set of VLANs has shared learning, where one of the VLANs is the "primary" and the other VLANs in the group are "secondaries". An example of this is where traffic from different communities are separated using VLAN tags, and yet some resource R. Perlman, et al [Page 52] INTERNET-DRAFT RBridge Protocol (such as an IP router or DHCP server) is to be shared by all the communities. A method of implementing this feature 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, aware of this grouping, 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 specification 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.7 RBridge Port Structure An RBridge port can be modeled as having a structure similar to that of an [802.1Q] bridge port as shown in Figure 4.3. In this figure, the double lines represent the general flow of the frames and information while single lines represent information flow only. The dashed lines in connection with VRP (GVRP/MVRP) are to show that VRP support is optional. An actual RBridge port implementation may be structured in any way that provides the correct behavior. There are three per port configuration bits as follows: o Disable port bit. When this bit is set, all frames received are discarded and no frames are sent, with the possible exception of some low level control frames. o 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.) A port with end station service disabled reports, in the Hellos it sends out that port, that it has no VLANs for which it is provides end station support. As a result, such a port will not be appointed forwarder for any VLAN. Thus a port with end station service disabled cannot contribute to the VLANs which the RBridge reports in its LSP as being "connected" to that RBridge. Unless there is at least one port on an RBridge for which VLAN-x is appointed forwarder, that RBridge does not normally advertise itself in the link state as connected to VLAN-x. As a consequence, it will not normally receive any traffic for VLAN-x except as TRILL data frames to forward as a transit RBridge. R. Perlman, et al [Page 53] INTERNET-DRAFT RBridge Protocol o TRILL traffic disable (access port) bit. If this bit is set, the idea is to avoid sending TRILL data fames on the port since it is intended for end station traffic (see Appendix B). This bit is reported in Hellos sent out the port and the bit for the DRB controls the link. If the DRB asserts the access port bit in its Hello, then the link is an RBridge access link all RBridge ports which acknowledge that DRB act as access ports. If there are no TRILL IS-IS adjacencies on the access port, no special action need be taken. If there are adjacencies, and the RBridge is DRB, it normally does not create a pseudo-node for the link. In that case, no adjacencies over the access link are reported in their LSPs by any of the RBridges connected to the link. In this case no TRILL data or TRILL IS-IS frames, except Hellos, are sent out the access ports. Alternatively, the DRB MAY choose to creates a pseudo-node for the access link. If it does create a pseudo-node, it sets the IS-IS overflow bit in the pseudo-node. This will cause IS-IS routing to avoid sending transit data on the link if any other path is available but it will still be available as a path of last resort; however, core TRILL IS-IS frames will be sent over the link. In addition, if a pseudo-node is created by the DRB for an access link, all the RBridges on the access link report connectivity to the pseudo-node as usual and the DRB reports connectivity in the LSP it creates for the pseudo-node. R. Perlman, et al [Page 54] INTERNET-DRAFT RBridge Protocol +-------------------------+ +--------------------------+ | | | RBridge | +------+-----+ +- - - - - - + | | | | | | | Forwarding Engine, | | Port BPDU | | Port VRP +- - + IS-IS, Etc. | | Processing | | Processing | +--+--++------------------+ | | | | | || +-----++-----+ + - - ++ - - + | || || | +----+ || || | | || || | | +----++------+ <- EISS || | | | | || | | | Port VLAN | || | | | Processing | || | | | | || | | +----++------+ || | | || +-----++--------------++--------+-------++-----+ <-- ISS | | | Lower Level Port/Link Control Logic | | | +-------------++-------------------------------+ || || +------------+ || | | || | PHY | |+---+ (Physical +------- Link +----+ Interface) +------- | | +------------+ Figure 4.3: RBridge Port Model Low level control frames are handled in the lower level port/link control logic in the same way as in an 802.1Q bridge. This can optionally include a variety of 802.1 or link specific protocols such as link layer discovery, link aggregation, MAC security [802.1AE], or port based access control [802.1X]. While handled at a low level, these frames may affect higher level processing. For example, a Layer 2 registration protocol may affect the confidence in learned addresses. The upper interface to this lower level port control logic corresponds to the Internal Sublayer Service (ISS) in 802.1Q. Non-control frames are subject to Port VLAN and priority processing which is the same as for an 802.1Q bridge. The upper interface to the port VLAN processing corresponds to the Extended Internal Sublayer Service (EISS) in 802.1Q. High level control frames (BPDUs and, if supported, VRP frames) are R. Perlman, et al [Page 55] INTERNET-DRAFT RBridge Protocol not VLAN tagged. Although they extend through the ISS interface, they are not subject to port VLAN processing. Behavior on receipt of a VLAN tagged BPDU or VLAN tagged VRP frame, is unspecified. If a VRP is not implemented, then all VRP frames are discarded. Handling of BPDUs is described in Section 4.7.1. Handling of VRP frames is described in Section 4.7.2. 4.7.1 BPDU Handling If RBridge campus topology were static, RBridges would be simply end stations, thus terminating but not otherwise interacting with spanning tree. However, there are reasons for RBridges to listen to and sometimes to transmit BPDUs as described below. Even when RBridges listen to and transmit BPDUs, these are a local RBridge port activity. The ports of a particular RBridge never interact so as to make the RBridge as a whole a spanning tree node. 4.7.1.1 Receipt of BPDUs Rbridges MUST listen to spanning tree 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 information is reported per VLAN by the RBridge in its LSP. In addition, the receipt of spanning tree BPDUs is used as an indication that a link is a bridged LAN, which can affect the RBridge transmission of BPDUs. An RBridge MUST NOT encapsulate or forward any BPDU frame it receives. RBridges discard any topology change BPDUs they receive but note Section 4.7.1.3. 4.7.1.2 Root Bridge Changes A change in the root bridge seen out a port may indicate a change in bridged LAN topology including the possibility of the merger of two bridged LANs or the like. During topology transients, bridges may go into pre-forwarding states that block TRILL IS-IS Hellos. For these reasons, when an RBridge sees a root bridge change on a port for which it is appointed forwarder for one or more VLANs, it is inhibited (discards all native frames received from or which it would otherwise have sent to the link) for a period of time between 30 and zero seconds. This time period is configurable per RBridge and R. Perlman, et al [Page 56] INTERNET-DRAFT RBridge Protocol defaults to 30 seconds. For example, consider two bridged LANs carrying multiple VLANs, each with various appointed forwarders. Should they become merged, due to a repeater coming up or the like, those RBridges attached to the original bridged LAN with the lower priority root will see a root bridge change while those attached to the other original bridged LAN will not. Thus all appointed forwarders in the first set will be inhibited for the time period while things are sorted out by BPDUs within the merged bridged LAN and TRILL IS-IS Hellos between all the RBridges involved. 4.7.1.3 Transmission of BPDUs When an RBridge ceases to be appointed forwarder for one or more VLANs out a particular port it SHOULD, as long as it continues to receive spanning tree BPDUs on that port, send topology change BPDUs until it sees the topology change acknowledged in a spanning tree BPDU. RBridges MAY support a capability for sending spanning tree BPDUs for the purpose of attempting to force a bridged LAN to partition as discussed in Section A.3.3. Except for this optional capability, RBridges MUST NOT send spanning tree BPDUs. 4.7.2 Dynamic VLAN Registration Dynamic VLAN registration provides a means for bridges (and less commonly end stations) to request that VLANs be enabled or disabled on ports leading to the requestor. This is done by VLAN registration protocol (VRP) frames: GVRP or MVRP. RBridges MAY implement GVRP and/or MVRP as described below. VRP frames are never encapsulated as TRILL frames between RBridges or forwarded in native form by an RBridge. If an RBridge does not implement a VRP, it discards any VRP frames received and sends none. RBridge ports may have VLANs whose enablement is dynamic. If an RBridge supports a VRP, the actual enablement of dynamic VLANs is determined by GVRP/MVRP frames received at the port as it would be for an [802.1Q] / [802.1ak] bridge. An RBridge that supports a VRP sends GVRP/MVRP frames as an [802.1Q] / [802.1ak] bridge would send on each port that is not configured as an RBridge trunk port. For this purpose, it sends VRP frames to request traffic in the VLANs for which it is appointed forwarder and R. Perlman, et al [Page 57] INTERNET-DRAFT RBridge Protocol traffic in the Designated VLAN, unless the Designated VLAN is disabled on the port, and to not request traffic in any other VLAN. R. Perlman, et al [Page 58] INTERNET-DRAFT RBridge Protocol 5. RBridge Addresses, Parameters, and Constants IS-IS requires each RBridge to have a unique 48-bit (6-octet) System ID. This is easily obtainable, for example, as any one of the MAC-48 addresses owned by that RBridge. A new Ethertype must be assigned to indicate a TRILL encapsulated frame. Two Layer 2 multicast addresses must be assigned. o All-RBridges for use as Outer.MacDA in multi-destination frames. o All-IS-IS-RBridges as the Inner.MacDA for TRILL IS-IS frames. The following per RBridge parameters may be configured: o A nickname and nickname selection priority. o Priority to be a distribution tree root and desired number of additional distribution trees for the campus, as discussed in Section 4.3. o The per RBridge parameters Aging Timer and Forward Delay, as described in Section 4.6. RBridges may be configured to have ESADIs (end station address distribution instances) of TRILL IS-IS and to send and/or learn end station address information via such instances. Static end address information and priority of such end station information statically configured and learned in various ways can also be configured. The per RBridge per VLAN Other Multicast bit, which defaults to true, to request the receipt of non-IP derived multicast traffic. The following RBridge per port parameters: o Essentially the same parameters as for an 802.1Q port in terms of VLAN C-tags and frame priority code points. o Three per-port configuration bits: disable port, disable end station service (trunk), and access port (see Section 4.7). o Configuration for the optional send-BPDUs solution to the wiring closet topology problem (see Section A.3.3) consists of System ID of the RBridge with lowest System ID. If RB1 and RB2 are part of a wiring closet topology, both need to be configured to know about this, and that RB1 is the ID that should be used in the spanning tree protocol on the specified R. Perlman, et al [Page 59] INTERNET-DRAFT RBridge Protocol port. R. Perlman, et al [Page 60] INTERNET-DRAFT RBridge Protocol 6. Security Considerations Layer 2 bridging in not inherently secure. It is, for example, subject to forgery 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 such as to configure the TRILL IS-IS instances to use IS-IS security [RFC3567] and ignore unauthenticated TRILL IS-IS messages received on a port. Since such authentication requires configuration, RBridges using it are no longer zero 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 within a port and are outside the scope of TRILL proper (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 IS-IS ESADIs (see Section 4.6). TRILL encapsulates native frames inside the TRILL Ethertype while they are in transit between that frame's ingress RBridge and egress RBridge(s). Thus, TRILL ignorant devices with firewall features and which cannot be detected by RBridges as end stations will generally not be able to examine the interior of such frames for security checking purposes. This may render them ineffective. Routers and hosts appear to RBridges to be end stations and such frames will be decapsulated before being sent to such devices. Thus they will not see the TRILL Ethertype. Firewall devices which 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. 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 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, this will no longer work with TRILL; 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. RBridges do not prevent nodes from impersonating other nodes, for instance, by issuing bogus ARP/ND replies. However, RBridges do not R. Perlman, et al [Page 61] INTERNET-DRAFT RBridge Protocol interfere with any schemes that would secure neighbor discovery. R. Perlman, et al [Page 62] INTERNET-DRAFT RBridge Protocol 7. Assignment Considerations This section discuses IANA and IEEE 802 assignment considerations. See [RFC5226]. 7.1 IANA Considerations A new IANA registry is created for TRILL Versions, Nicknames, and Version 0 Header Reserved bits. The initial contents of the TRILL version registry is as follows: Version Status 0 As specified in RFCthisdocument 1-3 Available for allocation by IETF Standards Action The initial contents of the Version 0 Header Reserved Bits registry is as follows: Bit Status 0x2 Available for allocation by IETF Standards Action 0x1 Available for allocation by IETF Standards Action The initial contents of the TRILL nicknames registry is as follows: 0x0000 Reserved to indicate no nickname specified 0x0001-0xFFBF Dynamically allocated within each TRILL campus 0xFFC0-0xFFFE Available for allocation by IETF Standards Action 0xFFFF Permanently reserved 7.2 IEEE 802 Assignment Considerations The Ethertype is assigned by IEEE 802 to indicate a TRILL encapsulated frame. The Layer 2 multicast addresses and are assigned by IEEE 802 for "All-Rbridges" and "All-IS-IS-Rbridges" respectively. R. Perlman, et al [Page 63] INTERNET-DRAFT RBridge Protocol 8. Normative References [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] "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-2005, 9 December 2005 [ISO10589] ISO/IEC 10589:2002, "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, Stanford University, August 1989. [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. [RFC4286] Haberman, B., Martin, J., "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. R. Perlman, et al [Page 64] INTERNET-DRAFT RBridge Protocol 9. Informative References [802.1AB] "IEEE Standard for Local and metropolitan area networks / Station and Media Access Control Connectivity Discovery", 802.1AB-2005, 6 May 2005. [802.1AE] "IEEE Standard for Local and metropolitan area networks / Media Access Control (MAC) Security", 802.1AE-2006, 18 August 2006 [802.1X] "IEEE Standard for Local and metropolitan area networks / Port Based Network Access Control", 802.1X-2004, 13 December 2004. [Arch] Gray, E., "The Architecture of an RBridge Solution to TRILL", draft-ietf-trill-rbridge-arch-05.txt, February 2008, work in progress. [PAS] Touch, J., & R. Perlman, "Transparent Interconnection of Lots of Links (TRILL) / Problem and Applicability Statement", draft- ietf-trill-prob-04.txt, June 2008, work in progress. [RBridges] Perlman, R., "RBridges: Transparent Routing", Proc. Infocom 2005, March 2004. [RFC1661] Simpson, W., "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. [RFC3567] Li, T. and R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, July 2003. [RFC4086] Eastlake, D., 3rd, 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. [RP1999] Perlman, R., "Interconnection: Bridges, Routers, Switches, and Internetworking Protocols", Addison Wesley Chapter 3, 1999. R. Perlman, et al [Page 65] INTERNET-DRAFT RBridge Protocol Appendix A: Incremental Deployment Considerations Some aspects of partial RBridge deployment are described below for link cost determination (Section A.1) and possible congestion due to appointed forwarder bottlenecks (Section A.2). A particular example of a problem related to the TRILL use of a single appointed forwarder per link per VLAN (the "wiring closet topology") is explored in detail in Section A.3. A.1 Link Cost Determination With an RBridged campus having no bridges or repeaters on the links between RBridges, the RBridges can accurately determine the number of physical hops involved in a path and the line speed of each hop, assuming this is reported by their port logic. With intervening devices, this is no longer possible. For example, as shown in Figure A.1, the two bridges B1 and B2 can completely hide a slow link so that both Rbridges RB1 and RB2 incorrectly believe the link is faster. +-----+ +----+ +----+ +-----+ | | Fast | | Slow | | Fast | | | RB1 +--------+ B1 +--------+ B2 +--------+ RB2 | | | Link | | Link | | Link | | +-----+ +----+ +----+ +-----+ Figure A.1: Link Cost of a Bridged Link Even in the case of a single intervening bridge, two RBridges may know they are connected but each see the link as a different speed from how it is seen by the other. However, this problem is not unique to RBridges. For example, routers can encounter similar situations due to links hidden by bridges, repeaters or Rbridges. A.2 Appointed Forwarders and Bridged LANs With partial RBridge deployment, the RBridges may partition a bridged LAN into a relatively small number of relatively large remnant bridged LANs or possibly not partition it at all, so a single bridged LAN remains. Then two potential problems can occur as follows: 1. The requirement that end station frames enter and leave a link via the appointed forwarder for the link and VLAN of the frame can cause congestion or suboptimal routing. (Similar problems can R. Perlman, et al [Page 66] INTERNET-DRAFT RBridge Protocol occur within a bridged LAN due to the spanning tree algorithm.) The extent to which such a problem will occur is highly dependent on the network topology. For example, if a bridged LAN had a star- like structure with core bridges that connected only to other bridges and peripheral bridges that connected to end stations and are singly connected to a core bridge, the replacement of all of the core bridges by RBridges without replacing the peripheral bridges would generally improve performance without inducing any appointed forwarder congestion. Solutions to this problem are discussed below and a particular example explored in Section A.3. 2. TRILL traffic sent to the All-Rbridges multicast address will typically be flooded throughout a bridged LAN link, which may create a greater burden than necessary. In cases where there is actually only one RBridge next hop recipient of interest, this problem can be eliminated by using the option of sending the TRILL traffic as a unicast frame to that recipient rather than multicasting it. (Since one purpose of TRILL IS-IS Hello frames is to find previously unknown Rbridges, they must always be multicast.) Inserting RBridges so that all the bridged portions of the LAN stay connected to each other and have multiple RBridge connections is generally the least efficient arrangement. There are four techniques that may help if problem 1 above occurs and which can, to some extent, be used in combination: 1. Replace more IEEE 802.1 bridges with RBridges so as to minimize the size of the remnant bridged LANs between RBridges. This requires no configuration of the RBridges unless the bridges they replace required configuration. 2. Re-arrange network topology to minimize the problem. If the bridges and RBridges involved are configured, this may require changes in their configuration. 3. Configure the RBridges and bridges so that end stations on a remnant bridged LAN are separated into different VLANs that have different appointed forwarders. If the end stations were already assigned to different VLANs, this is straightforward (see Section 4.2.3.2). If the end stations were on the same VLAN and have to be split into different VLANs, this technique may lead to connectivity problems between end stations. 4. Configure the RBridges such that their ports which are connected to the bridged LAN send BPDUs (see Section A.3.3) in such a way as to force the partition of the bridged LAN. (Note: A spanning tree is never formed through an RBridge but always terminates at RBridge ports.) To use this technique, the RBridges must support R. Perlman, et al [Page 67] INTERNET-DRAFT RBridge Protocol this optional feature, and would need to be configured to make use of it, but the bridges involved would rarely have to be configured. Warning: This technique makes the bridged LAN unavailable for TRILL through traffic because the bridged LAN partitions. Conversely to item 3 above, there may be bridged LANs which use VLANs, or use more VLANs than would otherwise be necessary, to support the Multiple Spanning Tree Protocol or otherwise evade the congestion that can be caused by a single spanning tree. Replacing the IEEE 802.1 bridges in such LANs with RBridges may enable a reduction in or elimination of VLANs and configuration complexity. A.3 Wiring Closet Topology If 802.1 bridges are present and RBridges are not properly configured, the bridge spanning tree or the DRB may make inappropriate decisions. Below is a specific example of the more general problem that can occur when a bridged LAN is connected to multiple RBridges. In cases where there are two (or more) groups of end nodes, each attached to a bridge (say B1 and B2 respectively), and each bridge is attached to an RBridge (say RB1 and RB2 respectively), with an additional link connecting B1 and B2 (see Figure A.2), it may be desirable to have the B1-B2 link only as a backup in case one of RB1 or RB2 or one of the links B1-RB1 or B2-RB2 fail. +-------------------------------+ | | | | | Data +-----+ +-----+ | | Center -| RB1 |----| RB2 |- | | +-----+ +-----+ | | | | | +-------------------------------+ | | | | +-------------------------------+ | | | | | +----+ +----+ | | Wiring | B1 |-----| B2 | | | Closet +----+ +----+ | | Bridged | | LAN | +-------------------------------+ Figure A.2: Wiring Closet Topology R. Perlman, et al [Page 68] INTERNET-DRAFT RBridge Protocol For example, B1 and B2 may be in a wiring closet and it may be easy to provide a short, high bandwidth, low cost link between them while RB1 and RB2 are at a distant data center such that the RB1-B1 and RB2-B2 links are slower and more expensive. Default behavior might be that one of RB1 or RB2 (say RB1) would become DRB for the bridged LAN including B1 and B2 and appoint itself forwarder for the VLANs on that bridged LAN. As a result, RB1 would forward all traffic to/from the link, so end nodes attached to B2 would be connected to the campus via the path B2-B1-RB1, rather than the desired B2-RB2. This wastes the bandwidth of the B2-RB2 path and cuts available bandwidth between the end stations and the data center in half. The desired behavior would be to make use of both the RB1-B1 and RB2-B2 links. 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 will happen with zero configuration (other than VLAN support), but this may not be immediately practical if bridges are being incrementally replaced by RBridges. A.3.2 The VLAN Solution If the end stations attached to B1 and B2 are already divided among a number of VLANs, RB1 and RB2 could be configured so that which ever becomes DRB for this link will appoint itself forwarder for some of these VLANs and the other RBridge for the remaining VLANs. Should either of the RBridges fail or become disconnected, the other will have only itself to appoint as forwarder for all the VLANs. If the end stations are all on a single VLAN, then it would be necessary to arbitrarily assign them between at least two VLANs to use this solution. This may lead to connectivity problems that might require further measures to rectify. A.3.3 The Spanning Tree Solution Another solution is to configure RB1 and RB2 to be part of a "wiring closet group", with a configured System ID RBx (which may be RB1 or RB2's System ID). Both RB1 and RB2 emit BPDUs on their configured ports as highest priority root RBx. This causes the spanning tree to R. Perlman, et al [Page 69] INTERNET-DRAFT RBridge Protocol logically partition the bridged LAN as desired by blocking the B1-B2 link at one end or the other (unless one of the bridges is configured to also have highest priority and has a lower ID, which we consider to be a misconfiguration). With the B1-B2 link blocked, RB1 and RB2 cannot see each other's Hellos via that link and each acts as Designated RBridge and appointed forwarder for its respective partition. Of course, with this partition, no TRILL through traffic can flow over the RB1-B1-B2-RB2 path. In the spanning tree BPDU, the Root is "RBx" with highest priority, cost to Root is 0, Designated Bridge ID is "RB1" when RB1 transmits and "RB2" when RB2 transmits, and port ID is a value chosen independently by each of RB1 and RB2 to distinguish each of its own ports. (If RB1 and RB2 were actually bridges on the same shared medium with no bridges between them, the result would be that the one with the larger ID sees "better" BPDUs (because of the tiebreaker on the third field: the ID of the transmitting RBridge), and would turn off its port.) Should either RB1 or the RB1-B1 link or RB2 or the RB2-B2 link fail, the spanning tree algorithm will stop seeing one of the RBx roots and will unblock the B1-B2 link maintaining connectivity of all the end stations with the data center. If the link RB1-B1-B2-RB2 is on the cut set of the campus and RB2 and RB1 have been configured to believe they are part of a wiring closet group, the campus becomes partitioned as the link is blocked. A.3.4 Comparison of Solutions Replacing all 802.1 bridges with RBridges is usually the best solution with the least amount of configuration required, possibly none. The VLAN solution works well with a relatively small amount of configuration if the end stations are already divided among a number of VLANs. If they are not, it becomes more complex and problematic. The spanning tree solution does quite 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 BPDUs as described in Section 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, instead of exactly two bridges, there is no guarantee that it would partition into roughly equal pieces. In such a case, you might end up with a highly unbalanced load on the RB1 link and the RB2 link. R. Perlman, et al [Page 70] INTERNET-DRAFT RBridge Protocol Appendix B: Trunk and Access Port Configuration Many modern bridged LANs are organized into a core and access model, The core bridges have only point-to-point links to other bridges while the access bridges connect to end stations, core bridges, and possibly other access bridges. It seems likely that some RBridge campuses will be organized in a similar fashion. An RBridge port can be configured as a trunk port, that is, a point- to-point link to another RBridge (or RBridges), by configuring it to disable end station support. There is no reason for such a port to have more than one VLAN enabled and in its Announcing Set on the port. Of course, the RBridge (or RBridges) to which it is connected must have the same VLAN enabled. There is no reason for this VLAN to be other than the default VLAN 1 unless, perhaps, the link is actually over carrier Ethernet facilities that provide some other specific VLAN or the like. Such configuration minimizes wasted Hellos and eliminates useless decapsulation and transmission of multi- destination traffic in native form onto the link. (see Sections 4.2.3.1 and 4.7) An RBridge access port would be expected to lead to a link with end stations and possibly one or more bridges. Such a link might also have more than one RBridge connected to it to provide more reliable service to the end stations. It would be a goal to minimize or eliminate transit traffic on such as link as it is intended for end station traffic. This can be accomplished by turning on the access port configuration bit for the RBridge port or ports connected to the link as further detailed in Section 4.7. When designing RBridge configuration user interfaces, consideration should be given to making it convenient to configure trunk and access ports. R. Perlman, et al [Page 71] INTERNET-DRAFT RBridge Protocol Appendix C: Multipathing Rbridges support multipathing of both known unicast and multi- destination traffic. Implementation of multipathing is optional. Multi-destination traffic can be multipathed by using different distribution tree roots for different frames. For example, assume that in Figure C.1 end stations attached to RBy are the source of various multicast streams each of which has multiple listeners attached to various of RB1 through RB9. Assuming equal bandwidth links, the distribution tree rooted at RBy will predominantly use the vertical links among RB1 through RB9 while that rooted at RBz will predominantly use the horizontal. If RBy chooses itself as the distribution tree root for half of this traffic and RBz the root for the other half, it may be able to substantially increase the aggregate bandwidth by making use of both the vertical and horizontal links among RB1 through RB9. Since the distribution trees an RBridge must 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 which use different roots for different multi-destination frames and some of which use a single root for all such frames. +---+ |RBy|---------------+ +---+ | / | \ | / | \ | / | \ | +---+ +---+ +---+ | |RB1|---|RB2|---|RB3| | +---+ +---+ +---+\ | | | | \ | +---+ +---+ +---+ \+---+ |RB4|---|RB5|---|RB6|-----|RBz| +---+ +---+ +---+ /+---+ | | | / +---+ +---+ +---+/ |RB7|---|RB8|---|RB9| +---+ +---+ +---+ Figure C.1: Multi-Destination Multipath Known unicast equal cost multipathing (ECMP) can occur if, instead of using a tie-breaker criterion when building an SPF path between ingress and egress RBridges, information about equal cost paths is retained. Different unicast frames can then be sent via different equal cost paths. For example, in Figure C.2, there are three equal R. Perlman, et al [Page 72] INTERNET-DRAFT RBridge Protocol cost paths between RB1 and RB2 and two equal cost paths between RB2 and RB5. A transit RBridge receiving a known unicast frame forwards it towards the egress RBridge and is not concerned with whether it believes itself to be on any particular path from the ingress RBridge or a previous transit RBridge. Thus a campus will operate correctly with a mix of RBridges some of which implement ECMP and some of which do not. As an alternative to multipathing, it might be possible to combine the three paths between RB1 and RB2 into one logical link through the "channel aggregation" feature of 802.3 (see Clause 43 of [802.3]). Rbridges MAY implement channel aggregation. However, channel aggregation requires multiple single hop equal bandwidth links (no intervening bridges). Equal cost multipathing is somewhat more general in that there can be multiple hops with intervening bridges and RBridges and links of different costs as long as the path cost is the same. (Generally, the default estimate of the cost of a link is proportional to the reciprocal of its line speed.) +---+ double line = 10 Gbps ----- ===|RB3|--- single line = 1 Gbps / \ // +---+ \ +---+ +---+ +---+ ===|RB1|-----|RB2| |RB5|=== +---+ +---+ +---+ \ / \ +---+ // ----- ----|RB4|=== +---+ Figure C.2: Known Unicast Multipath When multipathing is used, frames that follow different paths will be subject to different delays and may be re-ordered. While some traffic may be order/delay insensitive, typically most traffic consists of flows of frames such the re-ordering within a flow is damaging. How to determine flows or what granularity flows should have is beyond the scope of this document but, as an example, under many circumstances it would be safe to consider all the frames flowing between a particular pair of end station ports to be a flow. R. Perlman, et al [Page 73] INTERNET-DRAFT RBridge Protocol Appendix D: Determination of VLAN and Priority A high level informative summary of how VLAN ID and priority are determined for incoming native frames, omitting some details, is given in the bulleted items below: o When an untagged native frame arrives, a zero configuration RBridge associates the default priority zero and the VLAN ID 1 with it. It actually 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 may 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. Determination of the VLAN ID associated with an incoming untagged non-control frame may also be made dependent 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. o When a priority tagged native frame arrives, a zero configuration RBridge associates with it 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 immediately 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, what actual priority code point will be associated with the frame by the RBridge. o When a C-tagged (formerly called Q-tagged) native frame arrives, a zero configuration RBridge associates with it 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 referred to as priority "regeneration". R. Perlman, et al [Page 74] INTERNET-DRAFT RBridge Protocol Appendix Z: Revision History RFC Editor: Please delete this Appendix Z before publication. Changes from -03 to -04 1. Divide IANA Considerations section into IANA and IEEE parts. Add IANA considerations for TRILL Header variations and reserved bit and normative references to RFCs 2434 and 4020. 2. Add note on the terms Rbridge and TRILL to section 1.2. 3. Remove IS-IS marketing text. 4. Split Section 3 into Sections 3 and 4. Add a new top level section "5. Pseudo Code", renumbering following sections. Move pseudo code that was in old Section 3 into Section 5 and make section 3 more textural. This idea is that Section 3 and 4 have more readable text descriptions with some corner cases left out for simplicity while section 5 has more structured and complete coverage. 5. Revised and extended Security Considerations section. 6. Move multicast router attachment bit and IGMP membership report information from the per-VLAN IS-IS instance to the core IS-IS instance so the information can be used by core RBridges to prune distribution trees. 7. Remove ARP/ND optimization. 8. Change TRILL Header to add option feature. Add option section. 9. Change TRILL Header to expand Version field to the Variation field. Add TRILL message variations (8 bits) supported to the per RBridge link state information. 10. Distinguish TRILL data and IS-IS messages by using Variation = 0 and 1. 11. Consistently state that VLAN pruning and IP derived multicast pruning of distribution trees are SHOULD. 12. Add text and pseudo code to discard TRILL Ethertype data frames received on a port that does not have an IS-IS adjacency on it. 13. Add end station address learning section. Specify end station address learning from decapsulated native frames. R. Perlman, et al [Page 75] INTERNET-DRAFT RBridge Protocol 14. Add nickname allocation priority and optional nickname configuration. Reserve nickname values zero and 0xFFFF. 15. Explain about multiple Designated RBridges because of multiple VLANS. 16. Add Incremental Deployment Considerations Section incorporating expanded Wiring Closet Topology Section. 17. Add more detail on VLAN tag information and material on frame priority. 18. Miscellaneous minor editing and terminology updates. Changes from -04 to -05 NOTE: Section 5 was NOT updated as indicated below but the remainder of the draft was so updated. 1. Mention optional VLAN and multicast optimization in Abstract. 2. Change to distinguish TRILL IS-IS from TRILL data frames based on the Inner.MacDA instead of a TRILL Header bit. 3. Split IP multicast router attached bit in two so you can separately indicate attachment of IPv4 and IPv6 routers. Provide that these bits must be set if an RBridge does not actually do multicast control snooping on ingressed traffic. 4. Add the term "port VLAN ID" (PVID). 5. Drop references to PIM. Improve discussions of IGMP, MLD, and MRD messages. 6. Move M bit over one and create two bit pruning field at the bottom of the "V" combined field. 7. Add pruning control values of V and discussion of same. 8. Permit optional unicast transmission of multi-destination frames when there is only one received out a port. 9. Miscellaneous minor editing and terminology updates. R. Perlman, et al [Page 76] INTERNET-DRAFT RBridge Protocol Changes from -05 to -06 1. Revise Section 2 discussion of DRB determination in the presence of VLANs and move it to Section 2.2. Adjust VLAN handling description. 2. Change "V" field to be a 2-bit version fields followed by 2 reserved bits. Make corresponding changes to eliminate the inclusion in the header of frame analysis indicating type of multi-destination pruning which is proper for frame. Thus all non-ingress RBridges that wish to perform such pruning are forced to do full frame analysis. Make further corresponding changes in IANA Considerations. 3. The Inner.MacDA for TRILL IS-IS frames is changed to a second multicast address: All-IS-IS-RBridges. IEEE Allocation Considerations, etc., are correspondingly changed. 4. Note in Section 6 that bridges can hide slow links and generally make it harder from RBridges to determine the cost of an RBridge to RBridge hop that is a bridged LAN. 5. Add material noting that replacement of bridges by RBridges can cause connectivity between previously isolated islands of the same VLAN. 6. Expand Security Considerations by mentioning RFC 3567 and indicating that TRILL enveloping may reduce the effectively of TRILL-ignorant firewall functionality. 7. Extensive updates to psuedo code. 8. Change to one DRB per physical link which dictates the inter- RBridge VLAN for the link, appoints forwarders per-VLAN, can be configured to send Hellos on multiple VLANs, etc. 9. Add a minimal management by SNMP statement to Section 2. 10. Delete explicit requirement to process TRILL frames arriving on a port even if the port implements spanning tree and is in spanning tree blocked state. 11. Miscellaneous minor editing and terminology updates. Changes from -06 to -07 [WARNING: Section 5 of draft -07 was not fully updated to incorporate the changes below.] R. Perlman, et al [Page 77] INTERNET-DRAFT RBridge Protocol 1. Drop recommendation to set "bridge" flags in some 802.1AB frame fields. 2. Add Section 2.5 giving an informative description of zero configuration behavior for 802.1D and 802.1Q bridges and RBridges. 3. Add Section 4.7 (renumbering the former 4.7 to be 4.9) on the receipt, handing, and transmission of MVRP and other MRP frames by RBridges. Add references to 802.1ak. 4. Add Section 4.8 on Multipathing. 5. Partial changes to Section 5 to correspond with changes elsewhere in the draft. 6. Addition of frame category definitions in Section 1.2. 7. Addition of Section 10, Acronyms. 8. Add note in Section 6.2 that difficult in link cost determination due to intervening devices is not confined to RBridges. 9. Re-ordered some sections in Section 6. 10. Added a paragraph about taking care if trying to use VLANs for security to Security Considerations Section and re-ordered paragraphs in that section. 11. Added mention of being able to configure a port so that native frames are not send and are dropped on receipt. Probably need to say more about this. 12. Remove material about pseudo node suppression. 13. Fix a few cases where hop count was off by one. 14. Add option critical bits when option area length non-zero. 16. Miscellaneous minor editing and terminology updates. Changed Figure numbers to be relative to major section. Added Table captions. Changes from -07 to -08 1. Add "low" and "high" level control frame definitions to Section 1.2 and note concerning frames which would qualify as both R. Perlman, et al [Page 78] INTERNET-DRAFT RBridge Protocol "TRILL" and "control" frames. Utilize these defined frame types more consistently through the document. 2. Move substantial areas of tutorial, motivational, and informational text to Appendices, or a separate document, including Sections numbered 2.5, 4.8, 6.3, and 6.4 in version -07. Remove pseudo-code (Section 5 in version -07). 3. Move link Hellos / VLAN specification and discussion to a new subsection of Section 4. 4. Replace distribution tree root flag per RBridge with new logic which orders all RBridges in a campus as to their priority to be a distribution tree root and provides for the highest priority distribution tree root to dictate the numbers of trees in the campus. RBridges use the tree with least cost from themselves to the tree root for multi-destination frame distribution, or the n such trees if they multi-path multi-destination traffic. 5. Add "Access" port configuration bit and Appendix on Trunk and Access Links. 6. Add statement that use of S-tags in TRILL is outside the scope of this document. 7. Add new section on RBridge port structure (Section 4.7) which includes discussion of RBridge interactions with BPDUs and revised interactions with VRP frames. Make provisions for dynamic VLAN registration a "MAY" implement and agnostic between GVRP and MVRP. Remove references to 802.1ak. Simplify text related to VRP. Remove related configuration option. 8. Add requirement to adjust input filters no later than output forwarding. 9. Add requirement for configurable (default 30 second) prohibition on RBridge decapsulation out a port if a root bridge change has just been observed on that port. 10. Add provisions for propagating topology change to attached bridged LAN when an RBridge is de-appointed forwarder. Also other end station addressing forgetting details including per VLAN forwarding status dropped counter. 11. Delete requirement that appointed forwarder wait until it has received all the LSPs listed in the first CSNP (if any) it has received from its neighbors before forwarding frames off a link. 12. Add explicit criterion for when an RBridge port defers to the DRB indicated in a Hello it receives even if that Hello is not from R. Perlman, et al [Page 79] INTERNET-DRAFT RBridge Protocol the DRB or even from an RBridge in direct communication with the DRB. 13. Add provisions for pseudonode minimization. 14. Update reference to RFC 2434 to be to RFC 5226. 15. Miscellaneous minor editing and terminology updates. Add Figures index after Table of Contents. Changes from -08 to -09 1. Specify SHOULD as the implementation requirement for SNMPv3 management. 2. Change default confidence level to 0x20 for addresses learned from observing locally received native frames and from decapsulating TRILL data frames. This provides more space for lower confidence levels. 3. Add security consideration for observation of traffic no longer constrained to links in its Inner.VLAN due to TRILL encapsulation. 4. Updated bridge configuration assumptions in Section 2.3.1. 5. Use "inhibited" to describe the status of an appointed forwarder when it is temporarily discarding all received native frames and not sending any native frames. 6. In Section 4.3, there was an implication that the priority to be a tree root and the number of trees to be computed had not only default values for a zero configuration RBridge but could also be individually present or absent in the LSP for the RBridge. This tends to lead to a variable-length sub-TLV or multiple sub-TLVs in the LSP which leads to additional code paths to test. So various "if advertised" conditional clauses have been removed. 7. Reserve nicknames 0xFFC0 through 0xFFFE as well as 0x0000 and 0xFFFF and provide IANA Considerations for their allocation. 8. Improve Figure 4.1, "TRILL Data Encapsulation over Ethernet" by generalizing it and adding an RBridge diagram. 9. Add "access port" bit to Hello. Extend and clarify behavior for access ports and for the occurrence of the IS Neighbor TLV in TRILL Hellos. R. Perlman, et al [Page 80] INTERNET-DRAFT RBridge Protocol 10. Miscellaneous minor editing. R. Perlman, et al [Page 81] INTERNET-DRAFT RBridge Protocol Disclaimer This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Additional IPR Provisions The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. R. Perlman, et al [Page 82] INTERNET-DRAFT RBridge Protocol Authors' Addresses Radia Perlman Sun Microsystems 16 Network Circle Menlo Park, CA 94025 Phone: +1-650-960-1300 Email: Radia.Perlman@sun.com Donald E. Eastlake, 3rd Eastlake Enterprises 155 Beaver Street Milford, MA 01757 USA Phone: +1-508-634-2066 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 Nuova Systems 2600 San Tomas Expressway Santa Clara, CA 95051 USA Phone: +1-408-387-6123 Email: sgai@nuovasystems.com Anoop Ghanwani Brocade 1745 Technology Drive San Jose, CA 95110 USA Phone: +1-408-333-7149 Email: anoop@brocade.com R. Perlman, et al [Page 83] INTERNET-DRAFT RBridge Protocol Expiration and File Name This draft expires in March 25, 2009. Its file name is draft-ietf-trill-rbridge-09.txt. R. Perlman, et al [Page 84]