[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-perlman-trill-rbridge-protocol) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 RFC 6325

TRILL Working Group                                        Radia Perlman
INTERNET-DRAFT                                          Sun Microsystems
Intended status: Proposed Standard                   Donald Eastlake 3rd
                                                   Motorola Laboratories
                                                             Silvano Gai
                                                           Nuova Systems
                                                          Dinesh G. Dutt
                                                           Cisco Systems
                                                          Anoop Gandwani
                                                                 Brocade
Expires: August 2008                                       February 2008


                 Rbridges: Base Protocol Specification

               <draft-ietf-trill-rbridge-protocol-07.txt>


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 <rbridge@postel.org>.

   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/1id-abstracts.html

   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 allow for optimal pair-wise forwarding with zero
   configuration, safe forwarding even during periods of temporary
   loops, and multipathing for 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 bridges as well as
   current 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, Caitlin Bestler, Stewart Bryant, James Carlson,
   Dino Farinacci, Don Fedyk, Eric Gray, Joel Halpern, Erik Nordmark,
   Sanjay Sane, 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


      Status of This Document....................................1

      Abstract...................................................2
      Acknowledgements...........................................2

      1. Introduction............................................6
      1.1 Algorhyme V2, by Ray Perlner...........................7
      1.2 Terminology Used In This document......................7

      2. RBridges................................................8
      2.1 End Station Addresses..................................9
      2.2 RBridge Architecture...................................9
      2.3 RBridges and VLANs....................................11
      2.4 Forwarding of Different Frame Types...................13
      2.4.1 Known-Unicast.......................................13
      2.4.2 Multi-destination...................................13
      2.5 Zero Configuration Comparison.........................14
      2.5.1 IEEE 802.1D Bridges.................................14
      2.5.2 IEEE 802.1Q Bridges.................................14
      2.5.3 RBridges............................................15

      3. Details of the TRILL Header............................17
      3.1 TRILL Header Format...................................17
      3.2 Version (V)...........................................17
      3.3 Reserved (R)..........................................18
      3.4 Multi-destination (M).................................18
      3.5 TRILL Header Options..................................18
      3.6 Hop Count.............................................19
      3.7 RBridge Nicknames.....................................20
      3.7.1 Egress RBridge Nickname.............................20
      3.7.2 Ingress RBridge Nickname............................21
      3.7.3 RBridge Nickname Allocation.........................21

      4. Other RBridge Design Details...........................23
      4.1 Ethernet Data Encapsulation...........................23
      4.1.1 VLAN Tag Information................................24
      4.1.2 Outer VLAN Info.....................................25
      4.1.3 Inner VLAN Info.....................................26
      4.1.4 Frame CheckSum (FCS)................................27
      4.2 Link State Protocol (IS-IS)...........................27
      4.2.1 IS-IS RBridge Identity..............................28
      4.2.2 IS-IS Instances.....................................28
      4.2.3 TRILL IS-IS Information.............................29
      4.2.3.1 Core IS-IS Information............................29
      4.2.3.2 Optional Per-VLAN IS-IS Instance Information......30
      4.2.4 Designated RBridge..................................31
      4.2.5 Appointed VLAN-x Forwarder..........................31
      4.3 Distribution Trees....................................32




R. Perlman, et al                                               [Page 3]


INTERNET-DRAFT                                          RBridge Protocol


Table of Contents Continued

      4.3.1 Distribution Tree Calculation and Checks............33
      4.3.2 Pruning the Distribution Tree.......................34
      4.3.3 Forwarding Using a Distribution Tree................35
      4.4 Forwarding Behavior...................................36
      4.4.1 Receipt of a Native Frame...........................36
      4.4.1.1 Native Unicast Case...............................36
      4.4.1.2 Native Multicast and Broadcast Frames.............37
      4.4.2 Receipt of a TRILL Frame............................37
      4.4.2.1 TRILL IS-IS Frames................................38
      4.4.2.2 TRILL Data Frames.................................38
      4.4.3 Tree Distribution Optimization......................40
      4.5 IGMP, MLD, and MRD Learning...........................40
      4.6 End Station Address Details...........................41
      4.6.1 Learning End Station Addresses......................42
      4.6.2 Forgetting End Station Addresses....................43
      4.7 IEEE 802.1 Registration Protocols.....................43
      4.7.1 Non-VLAN Registration Frames........................44
      4.7.2 VLAN Registration Frames............................44
      4.7.2.1 VLAN Registration Frame Receipt...................44
      4.7.2.2 VLAN Registration Frame Transmission..............45
      4.8 Multipathing..........................................45
      4.9 Shared VLAN Learning..................................47

      5. Pseudo Code............................................48
      5.1 802MUL Destination Frames.............................49
      5.1.1 All Bridges Frames..................................50
      5.1.2 Media Multicast Frames..............................51
      5.1.3 802.1X Frames.......................................51
      5.1.4 802.1AB Frames......................................51
      5.1.5 MRP, MMRP, and MVRP.................................51
      5.1.6 Other Bridge Multicast Frames.......................52
      5.2 Processing a Frame Received by an RBridge.............52
      5.2.1 Further Dispatch for IP Frames......................54
      5.2.2 Common Subroutines..................................54
      5.2.2.1 Learn Source MAC Address..........................54
      5.2.2.2 TRILL Frame Multi-destination Forwarding..........54
      5.2.2.3 TRILL Data Frame Tree Transmission................55
      5.2.2.4 TRILL Data Frame Transmission.....................55
      5.2.3 TRILL Ethertype Frames..............................56
      5.2.3.1 TRILL IS-IS Frames................................56
      5.2.3.2 TRILL Data Frames.................................57
      5.2.4 Native Frame Receipt................................58
      5.2.4.1 Native IPv4 Multicast Frame.......................60
      5.2.4.2 Native IPv6 Multicast Frame.......................61
      5.2.5 IGMP and MLD Frames.................................61
      5.2.6 MRD Frames..........................................61
      5.3 Frames Spontaneously Sourced..........................62
      5.3.1 Bridge/Media Frames Sourced.........................62


R. Perlman, et al                                               [Page 4]


INTERNET-DRAFT                                          RBridge Protocol


Table of Contents Continued

      5.3.2 IS-IS Frames Sourced................................62
      5.3.2.1 Core IS-IS Frames.................................63
      5.3.2.2 Per-VLAN IS-IS Frames.............................64
      5.3.3 Other Frames Sourced................................65

      6. Incremental Deployment Considerations..................66
      6.1 VLAN Connectivity Changes.............................66
      6.2 Link Cost Determination...............................66
      6.3 Appointed Forwarders and Bridged LANs.................67
      6.4 Wiring Closet Topology................................68
      6.4.1 The RBridge Solution................................69
      6.4.2 The VLAN Solution...................................69
      6.4.3 The Spanning Tree Solution..........................70
      6.4.4 Comparison of Solutions.............................71

      7. RBridge Addresses, Parameters, and Constants...........72

      8. Security Considerations................................73

      9. Assignment Considerations..............................74
      9.1 IANA Considerations...................................74
      9.2 IEEE 802 Assignment Considerations....................74

      10. Acronyms..............................................75

      11. Normative References..................................77
      12. Informative References................................78

      Appendix A: Revision History..............................79
      Changes from -03 to -04...................................79
      Changes from -04 to -05...................................80
      Changes from -05 to -06...................................81
      Changes from -06 to -07...................................81

      Disclaimer................................................83
      Additional IPR Provisions.................................83

      Authors' Addresses........................................84
      Expiration and File Name..................................84











R. Perlman, et al                                               [Page 5]


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 and 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.  While they can be applied to a variety of link protocols,
   this specification concentrates on IEEE 802.3 links [802.3].
















R. Perlman, et al                                               [Page 6]


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 count we now see,
      The network need not be loop-free!

      RBridges work transparently.
      Without a common spanning tree.



1.2 Terminology Used In This document

   "TRILL" normally refers to the protocol specified herein while
   "RBridge" refers to the devices which implement that protocol.  The
   second letter in Rbridge is case insensitive. Both Rbridge and
   RBridge are correct.

   In this document, Layer 2 frames are divided into the following three
   categories:

      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.

      o  "native" frames are all frames other than TRILL and control
         frames.

   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].





R. Perlman, et al                                               [Page 7]


INTERNET-DRAFT                                          RBridge Protocol


2. RBridges

   RBridges run a link state protocol amongst themselves. This give 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 (see Section
   4.3.1) and other checks are performed on multi-destination frames.

   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 but not fully specified in this document (see
   Section 4.8). Multipathing may introduce frame reordering as can
   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, issues
   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 to use 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 bridged LAN 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 further implications of VLANs.)

   Rbridges can be managed with SNMP [RFC3410].  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 is zero configuration and has no Layer 3


R. Perlman, et al                                               [Page 8]


INTERNET-DRAFT                                          RBridge Protocol


   address, by transporting SNMP with Ethernet [RFC4789].



2.1 End Station Addresses

   An RBridge, RB1, that is the VLAN-x forwarder on any of its links
   MUST learn the location of VLAN-x end nodes, both on the links for
   which it is VLAN-x forwarder, and on other links in the campus. RB1
   learns the location and Layer 2 addresses of end nodes on links for
   which it is VLAN-x forwarder from the source address of frames, as
   bridges do (for example, see section 8.7 of [802.1Q]). 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 source address in the inner
   frame header of TRILL data frames that it is decapsulating onto a
   link.

   Additionally, a VLAN-x instance of IS-IS MAY be used by the appointed
   VLAN-x forwarder on a link to announce some or all of the attached
   VLAN-x end nodes on that link. 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 packets 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.  But even if a
   per-VLAN instance is used to announce attached end nodes, RBridges
   MUST still learn from decapsulating data packets unless configured
   not to do so.

   Advertising end nodes using a per-VLAN instance of IS-IS is optional,
   as is learning from these announcements.

   (See Section 4.6 for further end station address details.)



2.2 RBridge 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 functionality of an RBridge relay entity is
   layered on top of the Layer 2 technologies.

   However, this document specifies only an IEEE 802.3 encapsulation
   [802.3].

   Figure 2.1 shows two RBridges RB1 and RB2 interconnected through an


R. Perlman, et al                                               [Page 9]


INTERNET-DRAFT                                          RBridge Protocol


   Ethernet cloud. There are no restrictions on what may compose the
   Ethernet cloud: 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.

                   +--------------------------------+
                   |           PPP Header           |
                   +--------------------------------+
                   |          TRILL Header          |
                   +--------------------------------+
                   |     Inner Ethernet Header      |
                   +--------------------------------+
                   |        Ethernet Payload        |
                   +--------------------------------+
                   |         Ethernet FCS           |
                   +--------------------------------+

                 Figure 2.3 A PPP Encapsulated TRILL Frame




R. Perlman, et al                                              [Page 10]


INTERNET-DRAFT                                          RBridge Protocol


   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 are
   derived from the original frame which is encapsulated with a TRILL
   Header as it travels 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.



2.3 RBridges and VLANs

   A VLAN is a way to partition end nodes in a campus into different
   Layer 2 communities [802.1Q]. The usual method of determining which
   community a frame belongs to is based on the port from which it is
   received although end stations can insert this information in a
   frame. Use of VLANs requires configuration.

   IEEE 802.1Q bridges have the capability of supporting multiple VLANs
   over a single link by inserting/removing a VLAN tag in the frame.
   Rbridges can be configured to provide similar VLAN support.  Some end
   nodes have the same capability.  The VLAN tag is 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 which is 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 inner VLAN only to other links in the same VLAN; however,
   there are a few differences in the handling of VLANs between RBridged


R. Perlman, et al                                              [Page 11]


INTERNET-DRAFT                                          RBridge Protocol


   LANs and 802.1 bridged LANs.

   802.1 bridges will only forward a data frame over a link if that link
   is configured to be part of the VLAN to which that frame belongs. (By
   default a link belongs only to VLAN 1.) The MVRP protocol (see
   [802.1ak]), and proprietary features of some 802.1Q bridges (i.e.,
   "trunk links"), are designed to support full connectivity between all
   end stations in a particular VLAN. However, 802.1Q bridges can be
   configured so as to partition one or more particular VLANs into
   unconnected islands.  RBridges, on the other hand, have a campus wide
   view through the IS-IS link state database and can use arbitrary
   outer VLAN labeling for connectivity and to send data for any VLAN
   over any link.  As a result, RBridges connect all campus end stations
   in a particular VLAN (unless those end stations are cut off by
   bridges or configuration from access to any RBridge). (See also
   Section 2.5)

   A link which is a bridged LAN might be partitioned with respect to
   some VLANs. If the bridged LAN were partitioned with respect to, say,
   VLAN-x, and two RBridges were to send IS-IS Hellos on that link
   tagged with VLAN-x, they might not see each other's Hellos, and as a
   result, both conclude they should be DRB (Designated RBridge) on that
   link, both performing the encapsulation/decapsulation of data packets
   to/from that link, and thereby forming a loop. Therefore, it is
   important for RBridges to tag IS-IS Hellos with a VLAN that is not
   partitioned on the link. If the link is misconfigured, and the VLAN
   on which they are sending Hellos is partitioned, TRILL provides an
   additional mechanism whereby the duplicate DRBs will be detected and
   loops will be prevented.

   By default, RBridges tag IS-IS Hellos with VLAN 1. However, an
   RBridge MAY be configured to transmit Hellos on a set of VLANs, and
   if elected DRB, to designate to the other RBridges on the link which
   VLAN to tag Hellos with. Once the DRB, say RB1, is elected, and
   specifies the designated VLAN, say VLAN-x, on which to send Hellos,
   (1) all RBridges on the link, except the DRB, transmit Hellos tagged
   only with VLAN-x, (2) all RBridge-RBridge communication (including
   Hellos, forwarded data packets, and LSPs) are tagged with VLAN-x, and
   (3) the DRB only lists, in its Hello, and in the pseudonode LSP, the
   set of RBridges from which the DRB hears VLAN-V tagged packets.

   To maximize the probability that even if VLAN-x is partitioned, other
   RBridges will know that RB1 is the DRB, RB1 will continue to transmit
   Hellos on the set of VLANs for which it is configured to send Hellos.
   Note that the set of VLANs RB1 is configured to send Hellos on need
   not be all the VLANs that RB1 can send and receive on.  An RBridge
   that is not DRB MAY ignore any TRILL IS-IS messages (including
   Hellos) sent on any VLANs other than the common VLAN. The DRB,
   however, MUST continue to send and receive IS-IS Hellos on all VLANs
   that the DRB has been configured to send Hellos on.


R. Perlman, et al                                              [Page 12]


INTERNET-DRAFT                                          RBridge Protocol


2.4 Forwarding of Different Frame Types

   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.



2.4.1 Known-Unicast

   These frames have an inner MAC destination Address (Inner.MacDA) that
   is unicast and the egress RBridge for that destination MAC address
   location is known to the ingress RBridge.

   Such frames are forwarded Rbridge hop by Rbridge hop to their egress
   Rbridge.



2.4.2 Multi-destination

   These are frames that must be delivered to multiple destinations.
   They 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


R. Perlman, et al                                              [Page 13]


INTERNET-DRAFT                                          RBridge Protocol


   trees for forwarding multi-destination frames.



2.5 Zero Configuration Comparison

   This informational section provides a general comparison of the
   behavior, for non-control frames, of a zero configuration device in a
   network of possibly configured devices, where the zero configuration
   device is an IEEE 802.1D bridge, an IEEE 802.1Q bridge, or an
   RBridge. The goal is to clarify the behavioral differences,
   particularly in regard to VLANs.  All three devices can learn end
   station addresses in essentially the same way, through the
   observation of traffic (although RBridges provide an additional
   facility, which can be configured to learn such information via TRILL
   IS-IS messages).



2.5.1 IEEE 802.1D Bridges

   802.1D bridges [802.1D] are ignorant of VLANs. They are unaware
   whether frames received have a VLAN tag. As a result, they learn end
   station address location based on simple 48-bit MAC addresses
   unqualified by VLAN.

   In a bridged LAN of 802.1D bridges, a single spanning tree is
   determined and frames flow along this tree.  As a result, any links
   not part of the spanning tree can not be used for through traffic.



2.5.2 IEEE 802.1Q Bridges

   802.1Q bridges [802.1Q] are aware of VLANs. Every frame internal to
   such a bridge has a VLAN associated with it.  If the frame arrived
   without a VLAN tag, the bridge port logic associates a VLAN with it
   (see Section 4.1.3). When a frame is transmitted by an 802.1Q bridge,
   it can be sent with a VLAN tag indicating its VLAN or not, depending
   on port configuration. Frames are only transmitted through a port if
   the VLAN of the frame is in the set of VLANs associated with that
   port.  For a zero configuration port, that set consists of only VLAN
   1.

   The learning of end station addresses in such a bridge is based on a
   combined 12-bit VLAN ID and 48-bit MAC address.

   A zero configuration 802.1Q bridge accepts frames that arrive tagged
   with any valid VLAN. (They reject frames tagged with the illegal VLAN
   0xFFF.) Frames without a VLAN tag are associates with VLAN 1.


R. Perlman, et al                                              [Page 14]


INTERNET-DRAFT                                          RBridge Protocol


   However, because the ports of a zero configuration bridge have only
   VLAN 1 in their set, accepted frames for any VLANs other than 1,
   unless they are addressed to the bridge itself, have no place they
   can go.  As a result, in an 802.1Q bridge network where there is
   bridged traffic in any VLAN other than the default VLAN 1, it is
   essential to configure ports to permit output for these other VLANs.
   This can be done through management at each bridge or with VLAN
   Registration Protocol messages such as MVRP [802.1ak] or a
   combination of these techniques.

   By default, 802.1Q bridges form a single spanning tree and frames
   flow along that tree. The bridge ports on spanning tree interbridge
   links must be configured to be in all the VLANs which require the
   link for connectivity.

   The recommended default for 802.1Q bridges is that ports permit
   dynamic VLAN registration except for VLAN 1 which is fixed
   registered.  As a result, VLAN Registration Protocol frames can flow
   along the spanning tree adding the needed VLANs to the ports where
   they are received so as to provide connectivity between all end
   stations in each VLAN.



2.5.3 RBridges

   RBridges are VLAN aware and, in terms of VLANs, the port behavior and
   configurability of an RBridge is similar to that of an 802.1Q bridge.
   RBridge learning of end station addresses is also based on a combined
   12-bit VLAN ID and 48-bit MAC address.

   An RBridge will only accept frames at a port associated with a VLAN
   for which output is enabled at that port. Those frames will not be
   forwarded in native form out of any local port unless the RBridge is
   the appointed forwarder for the port and VLAN which, in the zero
   configuration case, this could only occur for VLAN 1. However, once a
   native frame is encapsulated into a TRILL data frame, it is not
   restricted to ports where output to its inner VLAN is enabled.

   A zero configuration RBridge will often encapsulate and forward
   native frames to another RBridge or RBridges.  For example, a known
   unicast frame could be forwarded to the correct egress RBridge even
   if it is in a VLAN other than 1. An RBridge might flood a
   multidestination frame to all other RBridges or, if it prunes the
   distribution tree for efficiency, to a subset of RBridges. This is
   because an RBridge to RBridge link does not need its end ports to
   have the relevant end-to-end VLANs added to them; the encapsulation
   can tag the frame with whatever outer VLAN ID is convenient.

   As a result of this, there is no need for VLAN Registration Protocol


R. Perlman, et al                                              [Page 15]


INTERNET-DRAFT                                          RBridge Protocol


   frames to affect the receiving ports of transit or egress RBridges.
   It can, however, still be useful for such frames to add VLANs to the
   set for the ports of ingress RBridges where they are received. Also,
   it can be useful for RBridges to send such VLAN Registration Protocol
   frames to bridges (or possibly even end stations) that may be
   included in the campus. (See Section 4.7 for more details on RBridge
   handling of dynamic VLAN registration.)













































R. Perlman, et al                                              [Page 16]


INTERNET-DRAFT                                          RBridge Protocol


3. Details of the TRILL Header

   The section provides a textual and diagrammatic description of the
   TRILL header. Section 4 below provides other RBridge design details,
   and Section 5 gives pseudo-code.



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 and is 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-bits. 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-bits. See Section 3.5.

   o  Hop Count: 6-bit unsigned integer. See Section 3.6.

   o  Egress RBridge Nickname: 16-bit address. See Section 3.7.1.

   o  Ingress RBridge Nickname: 16-bit address. See Section 3.7.2.



3.2 Version (V)

   According to IEEE's Ethertype guidelines, a single Ethertype is
   granted to a protocol and it is the protocol's responsibility to
   structure the format of the protocol header so as to support future
   revisions to the protocol. 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


R. Perlman, et al                                              [Page 17]


INTERNET-DRAFT                                          RBridge Protocol


   message because it may not be able to parse it.



3.3 Reserved (R)

   The two R bits are reserved for future use in extensions to 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.4.2) indicates the frame is
   to be delivered to a class of destination end stations via a
   distribution tree. It specifies the meaning of the egress RBridge
   nickname field as follows:

   o  M = 0 (FALSE) - the frame is (a) known unicast data or (b) core
      TRILL IS-IS; the egress RBridge nickname contains the nickname of
      the egress Rbridge for a known unicast TRILL data frame or 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 the distribution tree.
      This tree is selected by the ingress RBridge for a TRILL data
      frame or by the source RBridge for a per-VLAN 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; else, the options 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 destination
   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 18]


INTERNET-DRAFT                                          RBridge Protocol


               +------+------+----+----+----+----+----+----+
               | CHbH | CItE |          Reserved           |
               +------+------+----+----+----+----+----+----+

                Figure 3.2 Options Area Initial Flags Byte

   If the CHbH bit is one, one or more critical hop-by-hop options are
   present so, for example, 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 present.

   If the CItE 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 later 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 are expected to be implemented to optimize 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, to minimize potential problems with
   temporary loops when forwarding, the Hop Count SHOULD be set by the


R. Perlman, et al                                              [Page 19]


INTERNET-DRAFT                                          RBridge Protocol


   ingress RBridge (or source RBridge for a per-VLAN TRILL IS-IS frame)
   to the expected number of hops on that path to the most distant
   RBridge. To accomplish this, RBridge RBn calculates, for each branch
   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 tree rooted at RBi.

   Although the RBridge MAY decrease the hop count by more than 1, the
   RBridge forwarding a frame MUST decrease the hop count by at least 1,
   and discards the packet if it can not 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
   (see Section 4.2.1). This assignment allows specifying up to 2**16
   RBridges; however, the value 0x0000 is reserved to indicate that a
   nickname is not specified and the value 0xFFFF is reserved for future
   specification.  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.

   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 header from the data frame.

   o  For multi-destination TRILL data frames, M == 1, and 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.

   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


R. Perlman, et al                                              [Page 20]


INTERNET-DRAFT                                          RBridge Protocol


      Nickname MUST be set to zero by the source RBridge for such frames
      and is ignored by other RBridges.



3.7.2 Ingress RBridge Nickname

   The ingress RBridge nickname contains the nickname of the ingress
   RBridge in two cases: (1) Data frames (those with Inner.MacDA other
   than All-IS=IS-Rbridges) and (2) Per-VLAN TRILL IS-IS frames (those
   with Inner.MacDA equal to All-IS-IS-Rbridges and an inner VLAN tag
   present).  (The per-VLAN-x TRILL IS-IS frame is used for the purpose
   of the ingress RBridge R1 optionally advertising attachment of a set
   of VLAN-x end nodes to R1.)

   For core TRILL IS-IS frames, that is those with Inner.MacDA equal to
   All-IS-IS-Rbridges and no inner VLAN tag present, this field is not
   used.  Such frames may be sent before nicknames have been established
   and are only sent one hop.  In that case this field MUST be set to
   zero by the source RBridge and is ignored by other RBridges.



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 0xFFFF are reserved and may 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 the priority (once) after
      holding the nickname for some amount of time, to prevent a newly
      arriving RBridge that has not yet seen all the LSPs, from usurping
      its nickname, unless the new RBridge has been configured with the
      nickname value and the RBridge using that nickname value was not
      manually configured with that nickname value. The most significant


R. Perlman, et al                                              [Page 21]


INTERNET-DRAFT                                          RBridge Protocol


      bit of the priority MUST NOT be set unless the nickname value was
      configured.

   o  Each RBridge is also 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 System ID keeps the nickname, and the other RBridge MUST
      choose a new nickname. This may 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 link state
      frames 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.

   To minimize the probability of nickname collisions, each RBridge,
   when choosing its nickname, does so by randomly hashing some of its
   parameters. For example, parameters listed in Section 7, interface
   MAC addresses, time and date, and other entropy sources such as those
   give in [RFC4086].  There is no reason for all Rbridges to use the
   same algorithm for choosing nicknames.

   Once an RBridge has successfully acquired a nickname it SHOULD
   attempt to reuse it in the case of a reboot.

   To minimize the probability of a new RBridge usurping a nickname
   already in use, an RBridge SHOULD wait to acquire the link state
   database from a neighbor before it announces its own nickname.

   In IS-IS [ISO10589] a shared link is modeled as a pseudonode.
   Pseudonodes never act as ingress or egress RBridges and are never
   treated as distribution tree roots. Thus they do not need and do not
   have nicknames.
















R. Perlman, et al                                              [Page 22]


INTERNET-DRAFT                                          RBridge Protocol


4. Other RBridge Design Details

   Section 3 above describes the TRILL Headers while this Section
   provides a textual and diagrammatic description of other RBridge
   design details. Section 5 below provides pseudo-code.



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 9.2) is used in the outer
   header.

   Figure 4.1 details a data frame with an outer VLAN tag traveling on
   the Ethernet cloud of Figure 2.1 from RB1 to RB2. This encapsulation
   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 and Outer
      Source MAC Address: These addresses are used to specify the next
      hop RBridge and the transmitting RBridge, respectively, over a
      shared Ethernet cloud.

   o  TRILL Header: Egress (RB2) Nickname and Ingress (RB1) Nickname.
      These specify the nickname values of the egress and ingress
      RBridges, respectively, for data frames.

   o  Inner Ethernet Header: Inner Destination MAC Address and Inner
      Source MAC Address: These addresses are as transmitted by the
      original end node, specifying, respectively, the destination and
      source of the inner frame.

   It also potentially has two VLAN tags that can carry two different
   VLAN Identifiers and also include priority.










R. Perlman, et al                                              [Page 23]


INTERNET-DRAFT                                          RBridge Protocol


   Outer Ethernet Header:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Outer Destination MAC Address  (RB2)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Outer Destination MAC Address | Outer Source MAC Address      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Outer Source MAC Address  (RB1)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 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                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Inner Destination MAC Address |  Inner Source MAC Address     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Inner Source MAC Address                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Ethertype = C-Tag [802.1Q]    |  Inner.VLAN Tag Information   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Payload:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Ethertype of Original Payload |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
      |                                  Original Ethernet Payload    |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Frame CheckSum:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  New FCS (Frame CheckSum)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 4.1 TRILL Data Encapsulation over Ethernet



4.1.1 VLAN Tag Information

   The information in a "VLAN Tag", also known as a "C-tag" (formerly Q-
   tag), is more than just a VLAN ID. It always includes a priority
   field as shown in Figure 4.2. In fact, the "VLAN ID" may be zero,
   indicating the no VLAN is specified, just priority, although such a
   tag is properly called a "priority tag" rather than a "VLAN Tag"
   [802.1Q].


R. Perlman, et al                                              [Page 24]


INTERNET-DRAFT                                          RBridge Protocol


     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     | 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 "C" bit shown in Figure 4.2 is the CFI or Canonical Format
   Indicator bit. In some uses, it refers to the bit ordering of the
   following octets or of the associated source and destination
   addresses. 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. RBridges (and
   bridges), are not required to implement 8 priority levels so frames
   with different priority levels may be treated as if they had the same
   priority. 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 send out the same port if multipath is
   implemented. See section 4.8.)  Differing priorities can cause frame
   re-ordering.

   The C-Tag (formerly Q-Tag) Ethertype is 0x8100.



4.1.2 Outer VLAN Info

   RBridges send IS-IS Hellos on a link in order to discover RBridge
   neighbors. The default is to send IS-IS Hellos only on VLAN 1.
   However, an RBridge MAY be configured to send Hellos on a set of,
   say, k different VLAN numbers, including one preferred value.  In
   that case, the RBridge will transmit k times as many Hellos, sending
   Hellos tagged with each of the k values in turn.

   As with traditional IS-IS, one RBridge is elected DRB (Designated
   RBridge), based on configured priority (most significant field), and
   system ID. The DRB continues to send k times as many Hellos, but
   specifies in all the Hellos, the designated VLAN ID for the link. All
   RBridges that are not DRB transmit Hellos only on the single


R. Perlman, et al                                              [Page 25]


INTERNET-DRAFT                                          RBridge Protocol


   designated VLAN number specified by the DRB.  This VLAN number is
   used in all RBridge-RBridge communication, including forwarded
   encapsulated data packets and IS-IS messages, except for the
   additional k-1 Hellos transmitted by the DRB on the VLANs other than
   the designated VLAN.

   On TRILL frames, the priority field in the Outer VLAN Info is set on
   an outgoing TRILL frame to a copy of the priority field in the Inner
   VLAN Info for data frames or to 7, the highest priority, for TRILL
   IS-IS frames.



4.1.3 Inner VLAN Info

   The "Inner VLAN Info" field contains the VLAN information associated
   with the original native frame when it was ingressed or the VLAN
   information associated with a per-VLAN TRILL IS-IS message when that
   message was created.  When a TRILL frame with Inner VLAN Info
   arrives, that Inner VLAN Info is not changed.

   When a native frame arrives, the priority and VLAN in the Inner VLAN
   Info are determined as specified in [802.1Q] (see [802.1Q] Section
   6.7). A high level, informative summary of how this VLAN Info is
   determined, 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 with
      them.  Determination of the configured port VLAN IDs may also be
      made dependent on the Ethertype or NSAP (referred to in 802.1 as
      the Protocol) of the arriving frame.

   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 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 provided in the frame by specifying, for each of the
      eight possible priorities that might be in the frame, what actual
      priority 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


R. Perlman, et al                                              [Page 26]


INTERNET-DRAFT                                          RBridge Protocol


      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 as specified above for
      priority tagged frames.

   In 802.1, the process of associating a priority with a frame
   including mapping a priority provided in the frame to another
   priority, is referred to as priority "regeneration".

   In TRILL, the Inner VLAN Tag always specifies a VLAN ID.  This Inner
   VLAN ID is required at the ingress Rbridge as one element in
   determining the appropriate egress Rbridge for a known unicast frame
   and is required at the ingress and every transit Rbridge for multi-
   destination frames to correctly prune the distribution tree.

   The VLAN ID 0xFFF is reserved and MUST NOT be used. Rbridges MUST
   discard any frame they receive with a VLAN 0xFFF tag.



4.1.4 Frame CheckSum (FCS)

   Each frame has a single Frame CheckSum (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 fails is 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 would be 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 more
   continuous use of an FCS would be helpful in detecting a class of
   internal RBridge failures such as intermittent memory failures.



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);




R. Perlman, et al                                              [Page 27]


INTERNET-DRAFT                                          RBridge Protocol


   o  it is easy to extend by defining new TLV (type-length-value) data
      elements for carrying TRILL information;



4.2.1 IS-IS RBridge Identity

   Each RBridge has a unique 6-octet IS-IS System ID, which may be
   derived from any of the RBridge's unique MAC addresses.



4.2.2 IS-IS Instances

   TRILL implements separate IS-IS instances from the one used by Layer
   3, that is, different from the one used by IP 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 always have a destination multicast
   address of AllL1ISs or AllL2ISs. When they are TRILL encapsulated,
   these appear as the inner destination address.  TRILL IS-IS messages
   are always encapsulated and always have a different inner multicast
   destination address, namely All-IS-IS-Rbridges.

   Within TRILL, there is a mandatory core IS-IS across all Rbridges in
   the campus and optional per-VLAN instances between the RBridges on
   each supported VLAN. They are distinguished by the presence of an
   inner VLAN tag in the per-VLAN instance frames and the absence of
   such a tag in the core instances frames.

   All Rbridges must participate in the core IS-IS instance.  Core IS-IS
   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.)

   RBridges that are the appointed VLAN-x forwarder for a link having an
   end station in a particular VLAN-x MAY participate in the per-VLAN
   IS-IS instance for that VLAN. But all transit RBridges MUST properly
   forward per-VLAN IS-IS instance frames. Because of this forwarding,
   it appears to a per-VLAN IS-IS instance at an RBridge that it is
   directly connected by a shared link to all other RBridges in the
   campus running that per-VLAN IS-IS instance.  RBridges that do not
   implement the per-VLAN IS-IS instance for a VLAN or do not have that
   VLAN configured do not decapsulate or locally process any per-VLAN
   IS-IS frames they receive for that VLAN.





R. Perlman, et al                                              [Page 28]


INTERNET-DRAFT                                          RBridge Protocol


4.2.3 TRILL IS-IS Information

   The information in the IS-IS link state for the mandatory core and
   optional per-VLAN TRILL IS-IS instances 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.



4.2.3.1 Core IS-IS Information

   The information contained in the link state of RBridge RBn for the
   mandatory core IS-IS instance is as follows:

   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.

   2. 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. A flag RequestTree indicating whether RBridges MUST calculate a
      tree rooted at RBn (default RequestTree = TRUE).

   5. The list of RBridge nicknames that RBn might select for a
      distribution tree when RBn injects a multi-destination frame into
      the campus.  With 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 itself (if
      RBn's Request Tree flag is true) or the RBridge with the lowest
      System ID (if RBn's Request Tree flag is false).

   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 discussed in
      Section 4.9.) In addition, the link state contains the following
      information on a per-VLAN basis:

      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.4.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


R. Perlman, et al                                              [Page 29]


INTERNET-DRAFT                                          RBridge Protocol


         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.

      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.4.)

      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.4.3).

   7. Optionally, a list of VLAN groups, where each VLAN group is a list
      of VLAN IDs, with the first VLAN ID listed in a group is the
      "primary" and the others are "secondary". This is solely 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 (see Section 4.9).

   Using this information each RBridge can compute the optimal pair-wise
   forwarding for known-unicast traffic (the Forwarding Database) and
   the distribution trees for multi-destination traffic.

   The distribution of multi-destination frames (see Sections 4.3 and
   4.4.3) SHOULD also be pruned according to the list of VLAN IDs for
   which each RBridge is an appointed forwarder and for IP based
   multicast optimization (see Section 4.3.2).  If RBn is forwarding a
   multi-destination frame tagged with VLAN-x, RBn SHOULD NOT forward it
   onto branches of the distribution tree that have no downstream VLAN-x
   links.



4.2.3.2 Optional Per-VLAN IS-IS Instance Information

   The information in the link state for the optional per-VLAN TRILL IS-
   IS instances is the list of local end station MAC addresses known to


R. Perlman, et al                                              [Page 30]


INTERNET-DRAFT                                          RBridge Protocol


   the originating RBridge and for each such address a one octet
   unsigned "confidence" rating in the range 0-254 (see Section 4.6).



4.2.4 Designated RBridge

   IS-IS elects one RBridge for each link to be the Designated RBridge
   (DRB), i.e. to have special duties. The Designated RBridge:

   o  chooses, for the link, the designated VLAN tag to be used for all
      inter-Bridge communication (forwarded data packets, TRILL IS-IS
      messages), and announces it in its Hello.

   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 to
      be the appointed VLAN-x forwarder for all or some of the VLANs).

   o  before forwarding traffic off the link, or appointing a VLAN-x
      forwarder, wait at least 5 Hello intervals (to ensure you are
      DRB).

   o  continues sending IS-IS Hellos on all the VLANs that the DRB has
      been configured to send Hellos on (whereas non-DRBs send Hellos
      only on the common VLAN as specified by the DRB).



4.2.5 Appointed VLAN-x Forwarder

   The appointed VLAN-x forwarder is responsible for

   o  forwarding VLAN-x data traffic to-from the link.

   o  learning the port of local VLAN-x end nodes based on looking at
      the source address of native VLAN-x packets on the link.

   o  optionally learning the port of local VLAN-x end nodes based on
      any sort of Layer 2 enrollment 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, VLAN in inner VLAN tag, source address in inner
      Ethernet header } from packets being decapsulated onto the link.


R. Perlman, et al                                              [Page 31]


INTERNET-DRAFT                                          RBridge Protocol


   o  optionally listening to the messages in the VLAN-x instance of IS-
      IS to learn { egress RBridge, VLAN, MAC address } triplets of
      explicitly advertised end nodes.

   o  optionally advertising VLAN-x end nodes, on links for which you
      are appointed VLAN-x forwarder, in a VLAN-x instance of IS-IS.

   o  listening to BPDUs on the common spanning tree to learn the root
      bridge, if any and reporting in its LSP, the complete set of root
      bridges seen on any its links for which this RBridge is appointed
      forwarder for any VLAN.

   o  loop avoidance: not decapsulating a packet from ingress RBridge
      RB3 unless it has RB3's LSP, and the root bridge on the link it is
      about to forward onto is not listed in RB3's list of root bridges
      for the same VLAN.

   o  duplicate avoidance: not forwarding packets off a link until
      waiting several Hello intervals on each of its links, and, for
      each link, receiving all the LSPs listed in the first CSNP (if
      any) it has received from the neighbor on that link.

   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, forwarding traffic to/from port p.



4.3 Distribution Trees

   RBridges use distribution trees to forward multi-destination frames
   (see Section 2.4.2). Distribution Trees are bidirectional. A single
   distribution tree is logically enough for the entire campus. The
   TRILL WG decided that the computation of additional distribution
   trees was warranted because:

   1. using a tree rooted at the ingress RBridge optimizes the
      distribution path and (almost always) the cost of delivery when
      the number of destination links is a subset of the total number of
      links, as is the case with VLANs and IP multicasts;

   2. for unknown unicast destinations, using a tree rooted at the
      ingress RBridge minimizes out-of-order delivery because, in the
      case where a flow starts before the location of the destination is
      known by the RBridges, the path to the destination is the same as
      the shortest path to the destination unless equal cost multipath
      is being used.

   A distribution tree rooted in the ingress RBridge is not always the
   best choice:


R. Perlman, et al                                              [Page 32]


INTERNET-DRAFT                                          RBridge Protocol


   1. In some cases, a different tradeoff might be wanted in terms of
      the expense of computing many trees vs. optimality of traffic
      distribution (so fewer trees would be desired).

   2. It might be desirable to allow choosing a different distribution
      tree than the one rooted at the ingress RBridge for some frames in
      order to allow multipathing of multi-destination traffic injected
      by a particular RBridge.

   RBridges MUST calculate at least one distribution tree, and by
   default SHOULD compute one distribution tree for every Rbridge.
   However, to scale in the presence of a large number of RBridges in a
   campus, some RBridges MAY be configured to not be the root of a
   distribution tree. Each RBridge RBi announces whether RBridges MUST
   compute a tree rooted at RBi via the RequestTree flag in its core IS-
   IS instance LSP. The default is RequestTree == TRUE, but management
   configuration MAY reduce the number of trees.

   If all Rbridges have their RequestTree == FALSE, then each RBridge
   MUST calculate a tree rooted at the RBridge with lowest System ID.

   If RBi is a tree root, then any RBridge RBn that needs to send multi-
   destination traffic MAY select the RBi-tree by specifying RBi as the
   egress Nickname in the TRILL header. However, RBn MUST announce, in
   its LSP, an intention to use RBi as a tree root if RBn ever chooses
   the RBi-tree.  All the other RBridges MUST comply with the tree root
   decision of the RBridge RBn.

   In IS-IS a shared link may be modeled as a pseudonode.  If so, the
   RBridge acting as designed RBridge for the shared link MUST set
   RequestTree false for the pseudonode.



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.

   Calculation of a tree rooted at RBi is done independently by each
   RBridge RBn 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 tie-breaker 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 IS-IS


R. Perlman, et al                                              [Page 33]


INTERNET-DRAFT                                          RBridge Protocol


   System ID.

   Each RBridge RBn keeps a set of adjacencies ( { port, neighbor}
   pairs) for each distribution tree. 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 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. 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.



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 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 ports with IP Multicast routers; (2) other
   multicast frames derived from an IP multicast address which should be
   delivered only to links that have registered listeners, plus links
   which have IP Multicast routers; and (3) other multicast traffic not
   derived from an IP address which 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,



R. Perlman, et al                                              [Page 34]


INTERNET-DRAFT                                          RBridge Protocol


   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 RBridge 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 Forwarding Using a Distribution Tree

   Forwarding a multi-destination data frame is done as follows:

   o  The RBridge RBn receives a multi-destination 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 respectively (for more information see
      Section 4.4);

   o  else, if the frame is for a Layer 2 multicast address derived from
      an IP multicast group, then 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 (see Section 4.4);

   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)
      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.

   The per-VLAN instance TRILL IS-IS frames will be delivered only to
   RBridges which are appointed forwarders for that VLAN. Per-VLAN TRILL


R. Perlman, et al                                              [Page 35]


INTERNET-DRAFT                                          RBridge Protocol


   IS-IS messages look, to transit RBridges, like any multicast data
   packet tagged with an inner VLAN tag. Such packets will be multicast
   throughout the campus, like other non-IP-derived multicast data
   packets, on the distribution tree chose by the RBridge which created
   the per-VLAN IS-IS message, and pruned according to the inner VLAN
   tag. Thus they are received by all the RBridges who are appointed
   forwarders for a link in that VLAN 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 Forwarding Behavior

   This section describes RBridge behavior for a variety of received
   frames, including how they are forwarded when appropriate.



4.4.1 Receipt of a Native Frame

   The ingress Rbridge RB1 determines the VLAN ID for a native frame
   according to the same rules as IEE 802.1Q bridges do (see Section
   4.1.3). Once the VLAN is determined, if RB1 is not the appointed
   forwarder for that VLAN for the link from which the frame was
   received, the frame is discarded. If it is appointed forwarder for
   that VLAN, then it is forwarded according to 4.4.1.1 if the frame is
   unicast, and 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 DA is looked up in the Encapsulation
   Database for that VLAN to find the egress RBridge RBm, or discover
   that DA is unknown.

   If DA is known, with egress Rbridge RBm, then RB1 converts the native
   frame to a TRILL data frame with outer MAC addresses from RB1 unicast
   to the next hop RBridge towards RBm and a TRILL header with M = 0,
   the ingress nickname for itself, and the egress nickname for RBm.

   If DA is unknown, RB1 converts the native frame to a TRILL data frame
   with outer MAC addresses of RB1 as source and the All-Rbridges
   multicast address as destination and a TRILL header with the multi-
   destination bit M = 1, the ingress nickname for itself, and the
   egress nickname for the root of the distribution tree it wants to


R. Perlman, et al                                              [Page 36]


INTERNET-DRAFT                                          RBridge Protocol


   use.  The default is for RB1 to write its own nickname into the
   egress nickname field. However, RB1 MAY choose a different
   distribution tree if either RB1 has not elected to be a tree root, or
   if RB1 has been configured to path-split multicast. In that case RB1
   MUST select a tree by specifying an RBridge that has elected to be a
   tree root. Also, RB1 MUST select a tree that RB1 has announced (in
   RB1's own LSP) to be one of the ones that RB1 MAY choose as a
   distribution tree. (see Section 4.3.1)



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 discarded.

   If the frame is an IGMP [RFC3376], MLD [RFC2710], or MRD [RFC4286]
   message, then RB1 SHOULD analyze the frame, learn any group
   membership or IP multicast router presence indicated, and announce
   that information for the appropriate VLAN in its IS-IS link state
   (see Section 4.5).

   For all such frames, RB1 chooses a distribution tree, encapsulates,
   and forwards the frame on the pruned distribution tree (see Section
   4.3.2).  In the encapsulation, M = 1, 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 port there is only one next hop RBridge, the
   frame MAY be sent with the unicast Outer.MacDA of the target RBridge.
   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 be flooded if a multicast destination is used.



4.4.2 Receipt of a TRILL Frame

   TRILL frames are indicated by a TRILL outer Ethertype. 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 Designated RBridge status for that port.



R. Perlman, et al                                              [Page 37]


INTERNET-DRAFT                                          RBridge Protocol


   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 and 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 a per-VLAN instance TRILL
   IS-IS frame. If M == 0, the frame is 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 a per-VLAN IS-IS instance for that
   VLAN, the inner frame is decapsulated and provided to that local per-
   VLAN IS-IS instance.



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 IS-IS adjacency on that port.

   The Inner.MacDA is then checked. If it is unicast, processing
   continues as described in Section 4.4.2.2.1, otherwise processing
   continues as described in Section 4.4.2.2.2.

4.4.2.2.1 Unicast TRILL Data Frames

   If M == 1 the frame is discarded.

   If the egress RBridge indicated is the RBridge performing the
   processing (RBn), the frame being forwarded is reconverted to native


R. Perlman, et al                                              [Page 38]


INTERNET-DRAFT                                          RBridge Protocol


   form. This frame is then either sent onto the link containing the
   destination or locally processed if the RBridge itself is the
   destination.

   A known unicast TRILL data frame can arrive at the egress Rbridge
   only to find that the MAC destination address is not actually known
   by that RBridge. One way this can happen is that the destination MAC
   address 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 except that it is MAY refrain from sending the
   frame on links where it knows there can not 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
   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.

4.4.2.2.2 Multi-Destination TRILL Data Frames

   If M == 0, the frame is discarded.

   The Outer.MacSA is then checked and the frame discarded if it is not
   a tree adjacency for the tree indicated by the egress RBridge
   nickname or the RPF 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 links in
   its VLAN and/or locally processed as appropriate.

   If the hop count in the frame is zero, it is 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.2.

   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
   port there is only one next hop RBridge, the frame MAY be sent with a
   unicast 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 be flooded if a multicast
   destination is used.






R. Perlman, et al                                              [Page 39]


INTERNET-DRAFT                                          RBridge Protocol


4.4.3 Tree Distribution Optimization

   RBridges MUST determine the VLAN associated with all native frames
   and properly enforce VLAN rules on the emission of native frames at
   egress RBridge ports according to how they 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 which do not.

   The situation is more complex for multicast. RBridges SHOULD analyze
   IP derived 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 frames
   based on such learning and announcements. But, as with VLANs, they
   are not required to prune based on IP multicast listener and router
   attachment state. Unlike VLANs, where VLAN attachment state of ports
   MUST be maintained and honored, RBridges are not required to even
   maintain IP multicast listener and router attachment state.  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.
   They silently discard such frames.

   An RBridge that does not examine 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.)

   See also "Considerations for Internet Group Management Protocol
   (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches"
   [RFC4541].



4.5 IGMP, MLD, and MRD Learning

   RBridges SHOULD learn, based on seeing IGMP [RFC3376], MLD [RFC2710],
   and MRD [RFC4286] frames, which IP derived multicast messages should


R. Perlman, et al                                              [Page 40]


INTERNET-DRAFT                                          RBridge Protocol


   be forwarded onto which links.

   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.

   IP multicast group membership reports have to be sent throughout the
   campus to all IP multicast routers, distinguishing IPv4 and IPv6. All
   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.

   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 such IP 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 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, 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.



R. Perlman, et al                                              [Page 41]


INTERNET-DRAFT                                          RBridge Protocol


4.6.1 Learning End Station Addresses

   There are three independent ways an RBridge can learn end station
   addresses as follows:

   1. For links where it is the appointed VLAN-x forwarder and for VLAN-
      x frames, from the observation of data, learning the { source MAC,
      VLAN, port } triplet of received frames and the { source MAC,
      VLAN, remote RBridge nickname } triplet of data frames that it
      decapsulates.

   2. By running a per-VLAN IS-IS instance which receives remote
      information and transmits local information.

   3. By management configuration.

   RBridges MUST implement capability 1 above and MUST use it unless
   configured, for one or more particular VLANs and/or ports, to not
   learn from either received local frames or from decapsulated TRILL
   data frames or both.

   RBridges MAY implement capability 2 above. If implemented, such a
   per-VLAN IS-IS instance is run only when the RBridge is configured to
   do so on a per-VLAN basis.

   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 1 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 IS-IS 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 tabled of learned MAC addresses consists of { confidence, VLAN,
   MAC address, local port } for addresses learned from local native
   frames and { confidence, VLAN, MAC address, egress RBridge nickname }
   for addresses learned from remote encapsulated frames, plus
   additional information to implement timeout of learned addresses,
   statically configured addresses, and the like.

   When a new learned address and related information are to be entered
   into the local database there are several possibilities:

   o  If this is a new { address, VLAN } pair, the information is
      entered accompanied by the confidence level.



R. Perlman, et al                                              [Page 42]


INTERNET-DRAFT                                          RBridge Protocol


   o  If there is already an entry for this { address, VLAN } pair with
      the same accompanying 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.

   o  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.

   In the later two cases above, timer information is appropriately
   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.

   The RBridge time out for locally learned end station address
   information from the last time a native frame was received or
   decapsulated with the information conforms to the recommendations of
   [802.1Q]. It is configurable per RBridge with a default value of 300
   seconds.

   The situation is different for end station address information
   acquired via a per-VLAN IS-IS instance. It is up to the originating
   RBridge to decide when to remove such information from the link state
   (or up to IS-IS timeouts if the originating RBridge becomes
   inaccessible).



4.7 IEEE 802.1 Registration Protocols

   IEEE [802.1ak] defines the bridge multiple registration protocol
   (MRP). A block of 16 multicast addresses from 01-80-C2-00-00-20 to
   01-80-C2-00-00-2F is reserved for up to 16 different applications of
   this protocol but only two applications have been defined:
   registration of multicast addresses (Multiple MAC Registration
   Protocol, MMRP) and registration of VLANs (Multiple VLAN Registration
   Protocol, MVRP). MMRP and MVRP, speaking very generally, allow a
   bridge or end station to send a frame which indicates that it wishes
   to received traffic for a particular multicast group or groups or
   particular VLAN or VLANs or no longer wishes to receive such traffic.


R. Perlman, et al                                              [Page 43]


INTERNET-DRAFT                                          RBridge Protocol


   802.1 bridges which don't understand MRP frames for a particular
   application are required to forward them like other multicast frames.



4.7.1 Non-VLAN Registration Frames

   RBridges treat IEEE 802.1 registration protocol frames like any other
   non-IP-derived multicast for all but VLAN registration frames which
   are discussed below.

   Thus MAC registration frames , which have multicast DA
   01-80-C2-00-00-20, and the 14 reserved registration protocol
   multicast addresses, which have DAs from 01-80-C2-00-00-22 through
   01-80-C2-00-00-2F, are flooded to all RBridges that are an appointer
   forwarder for the frame's VLAN and which have the Other Multicast
   flag set (which is the default).  Those RBridges then transmit those
   frames in native form on all enabled ports which have been configured
   to permit native traffic (which is the default).

   Rbridges MAY implement a more complex strategy integrating MAC
   registration functionality or future additional MRP applications with
   RBridges and this may affect the flow of these frames; however, the
   details of such implementation are beyond the scope of this document.



4.7.2 VLAN Registration Frames

   VLAN registration frames are handled in a completely different way
   from other 802.1 registration protocol frames as described below.

   VLAN registration frames are never encapsulated or forwarded as TRILL
   frames between RBridges.



4.7.2.1 VLAN Registration Frame Receipt

   RBridges may be configured on a per port bases as to whether they can
   act on receiving VLAN registration frames, which is the RECOMMENDED
   default, or discard them. In addition, they may be configured on a
   per port per VLAN basis as to whether that VLAN is enable or disabled
   for output and whether its enablement status is fixed (can only be
   changed by management configuration) or dynamic (can be changed by
   VLAN registration frames). Dynamic but initially disabled is the
   RECOMMENDED default, except for the Port VLAN ID which defaults to
   fixed enabled VLAN number 1.

   RBridges SHOULD, for any of their port where acting on VLAN


R. Perlman, et al                                              [Page 44]


INTERNET-DRAFT                                          RBridge Protocol


   registration frames is enable and any VLANs are dynamic, run a
   registration state machine and appropriately enable or disable those
   dynamic VLANs based on MVRP frames received.  This VLAN enablement
   status will be sent to other RBridges on the link in Hellos and
   information as to those VLANs which are enabled and where the RBridge
   is appointed VLAN-x forwarder will be flooded to all Rbridges in the
   campus via the link state database.



4.7.2.2 VLAN Registration Frame Transmission

   RBridges are configurable on a per port basis to enable sending VLAN
   registration frames out a port either (1) never, (2) if a bridge is
   seen out that port, or (3) always. The RECOMMENDED default is to
   enable the sending of such frames only if a bridge is seen out that
   port, which is determined by the receipt of BPDUs.

   The purpose of sending VLAN registration frames is to attract or
   repel traffic associated with particular VLANs although, of course,
   this will only be effective to the extent that the receivers of those
   frames can dynamically change their behavior in response.

   If MVRP frames are being sent out a port by an RBridge, they request
   traffic for all VLANs that are enabled for input/output on that port,
   whether that enablement is fixed or dynamic, and request no traffic
   for all other VLANs.



4.8 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 4.3 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 is the same
   for all RBridges and transit RBridges MUST respect the tree root


R. Perlman, et al                                              [Page 45]


INTERNET-DRAFT                                          RBridge Protocol


   specified by the ingress RBridge, a campus will operate correctly
   with a mix of RBridges some of which use different roots for
   different frames and some of which use a single root for all frames.

                             +---+
                             |RBy|---------------+
                             +---+               |
                            /  |  \              |
                          /    |    \            |
                        /      |      \          |
                     +---+   +---+   +---+       |
                     |RB1|---|RB2|---|RB3|       |
                     +---+   +---+   +---+\      |
                       |       |       |    \    |
                     +---+   +---+   +---+    \+---+
                     |RB4|---|RB5|---|RB6|-----|RBz|
                     +---+   +---+   +---+    /+---+
                       |       |       |    /
                     +---+   +---+   +---+/
                     |RB7|---|RB8|---|RB9|
                     +---+   +---+   +---+

                  Figure 4.3 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 4.4, there are three equal
   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.)



R. Perlman, et al                                              [Page 46]


INTERNET-DRAFT                                          RBridge Protocol


                               +---+       double line = 10 Gbps
                 -----      ===|RB3|---     single line = 1 Gbps
                /     \   //   +---+   \
            +---+     +---+            +---+
         ===|RB1|-----|RB2|            |RB5|===
            +---+     +---+            +---+
                \     /   \    +---+   //
                 -----     ----|RB4|===
                               +---+

                       Figure 4.4 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 pair of end station ports to be a flow.



4.9 Shared VLAN Learning

   Although outside the scope of this specification, there are some
   Layer 2 features in which a set of VLANs is considered to be a group,
   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 (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.







R. Perlman, et al                                              [Page 47]


INTERNET-DRAFT                                          RBridge Protocol


5. Pseudo Code

   [WARNING: Section 5 has not been fully updated to correspond with the
   rest of this draft.]

   This section provides partial high level pseudo code for the RBridge
   processing of all possible types of received and transmitted IEEE
   802.3 frames regardless of their contents (including native, TRILL,
   and control frames).  In case of conflict between this section and
   any of the other sections in this document, the pseudo code is
   authoritative; however, certain optional processing is shown in the
   pseudo code with such optionality being indicated. Of course, any
   other arrangement of processing is fine as long as the results are
   the same as the pseudo code in this section.

   Frame destination address abbreviations used in this section are as
   follows:

      Abbreviation   Destination Address(es)
      ------------------------------------------------------------
      ****     Any address.
      802MUL   Multicast address in the range 01-80-C2-00-00-00
                  to 01-80-C2-00-00-0F.
      ALLRB    The All-Rbridges multicast address, <tbd>.
      ALLRBI   The All-IS-IS-Rbridges multicast address, <tbd>.
      BROAD    The broadcast address: FF-FF-FF-FF-FF-FF
      IP4MUL   IPv4 based multicast addresses (the range
                  00-01-5E-00-00-00 to 00-01-5E-7F-FF-FF)
      IP6MUL   IPv6 based multicast addresses (the range
                  33-33-00-00-00-00 to 33-33-FF-FF-FF-FF)
      OTHERM   Multicast addresses other than ALLRB, ALLRBI,
                  IP4MUL, IP6MUL, 802MUL, or VRPMUL.
      OTHERU   Unicast addresses other than SELF.
      SELF     The unicast address of the Rbridge port at which
                  the frame in question is being processed.
      VRPMUL   Multicast address for MVRP frames: 01-80-C2-00-00-21.

                     Table 5.1 MAC Address Abbreviations

   Section 5.1 below discusses 802MUL addressed frames, most of which
   are handled by the port and are partially or fully out of scope for
   TRILL. Section 5.2 then discusses other received frames and frames
   emitted in direct response to such other received frames.  Section
   5.3 discusses frames not sent in direct response to received frames.








R. Perlman, et al                                              [Page 48]


INTERNET-DRAFT                                          RBridge Protocol


5.1 802MUL Destination Frames

   [WARNING: This section has not been fully updated to correspond with
   the rest of this draft.]

   Frames addressed to an 802MUL multicast address are sometimes handled
   by a port under IEEE 802 protocols which are out of scope for
   RBridges proper as show in Figure 5.1.  Such frames, by definition,
   are never forwarded by 802.1 customer bridges and are not forwarded
   by RBridges.

   An RBridge MAY learn source MAC address from such frames as described
   in Section 5.2.2.1.

                     +--------------------------------------------+
                     |   +--------+                 +-----------+ |
                     |   |  Port  |                 | Rbridge   | |
                     |   |        |     RBridge     | Forwarder | |
                     |   |  +--+  |                 |           | |
                     |   | \|  |  |                 |           | |
       ---------------------+  |  |                 |           | |
                     |   | /|  |/ |                 |   \       | |
       802MUL Frames |   |  |  +- | - - - - - - - - - - - -     | |
       /             |   |  |  |\ |                 |   /       | |
       ---------------------+  |  |                 |           | |
       \             |   |  |  |  |                 |           | |
                     |   |  +--+  |                 |  +-----+  | |
                     | \ |       \|                 | \|     |  | |
       ----------------- | -------| -------------------+     |  | |
                     | / |       /|                 | /|     |  | |
        Other Frames |   |        |   Other Frames  |  |     |  | |
       /             |   | /      | /               |  |     |  | |
       ----------------- | -------| -------------------+     |  | |
       \             |   | \      | \               |  |     |  | |
                     |   |        |                 |  +-----+  | |
                     |   +--------+                 +-----------+ |
                     +--------------------------------------------+

                     Figure 5.1 802MUL and RBridge Frames

   The following table give the sections where the various protocols
   which use 802MUL multicast addresses are discussed:










R. Perlman, et al                                              [Page 49]


INTERNET-DRAFT                                          RBridge Protocol


      Address              Section and Description
      ---------------------------------------------------------
      01-80-C2-00-00-00    5.1.1 All Bridges.
      01-80-C2-00-00-01    5.1.2 [802.3] Clause 31 (PAUSE, etc)
      01-80-C2-00-00-02    5.1.2 [802.3] Clause 43 ( Link
                            Aggregation) and Clause 57 (OAM)
      01-80-C2-00-00-03    5.1.3 [802.1X] Port Authenticator
                            Entity (PAE)
      01-80-C2-00-00-04/5  5.1.2 Reserved.
      01-80-C2-00-00-06/7  5.1.6 Reserved.
      01-80-C2-00-00-08    5.1.6 All Provider Bridges
      01-80-C2-00-00-09/C  5.1.6 Reserved.
      01-80-C2-00-00-0D    5.1.5 Provider Bridge GVRP Address
      01-80-C2-00-00-0E    5.1.4 [802.1AB] Link Layer Discovery
                            Protocol
      01-80-C2-00-00-0F    5.1.2 Reserved.

                          Table 5.2 802MUL Addresses



5.1.1 All Bridges Frames

   Frames sent with the All Bridges multicast address
   (01-80-C2-00-00-00) use the bridge protocol NSAP 0x42 so the frame
   begins LL-LL-42-42-03-PP-PP where 0xLLLL is the length and the
   trailing 0xPPPP indicates the particular All Bridges protocol.

   If 0xPPPP is 0x0000 the frame is a BPDU (Bridge Protocol Data Unit),
   used to implement the spanning tree protocol  and further discussed
   below.  If 0xPPPP is 0x0001 the frame is a GARP (General Attribute
   Registration Protocol) PDU which has been replaced by MRP. When MRP
   is used, the Ethertypes for MMRP or MVRP appear. See Section 5.1.5.

   An RBridge port MUST examine received BPDUs to determine the current
   root bridge and advertise what it sees as the current root bridge on
   that port via the core IS-IS instance (see Section 4.2.3). It would
   be sufficient for the RBridge to test that the DSAP/SSAP are 0x4242,
   the control octet is 0x03, and the first four octets of the BPDU
   payload are zero.  If so, the spanning tree root bridge identifier is
   the eight octets from the sixth octet through the 13th octet.  (The
   fifth octet is an octet of flags that need not be examined by the
   RBridge.)  The last six of these eight octets are the part of the
   root identifier reported in the LSP.(Octets six and seven include a
   priority.) When MSTP (Multiple Spanning Tree Protocol) is running on
   a link, this is the CIST (Common and Internal Spanning Tree) root.

   Note: RBridges do not implement spanning tree or the spanning tree
   state machine. Frames are not blocked from admission to an RBridge
   except as provided in this TRILL protocol specification.  It is never


R. Perlman, et al                                              [Page 50]


INTERNET-DRAFT                                          RBridge Protocol


   the case that a bridging spanning tree extends through an RBridge
   between two of its ports. Those ports always terminate the spanning
   tree. See also section 5.3.1.



5.1.2 Media Multicast Frames

   These frames are for media specific port features or are reserved for
   the future standardization of such features. Such features are
   outside of the scope of TRILL which is generally media independent.



5.1.3 802.1X Frames

   IEEE [802.1X] specifies a protocol provides for MAC authentication
   which can be used as the basis for authentication of end stations.
   That an end station has been so authenticated MAY be used to increase
   the confidence in end station MAC addresses reported via the optional
   per-VLAN IS-IS instance (see Section 4.6.1).  These frames are also
   identified by Ethertype 0x888E.

   An amendment to 802.1X [802.1af] is under development such that
   802.1X authentication would produce keying material usable in MACsec
   [802.1AE] which can in turn be used to authenticate and encrypt
   frames between ports.



5.1.4 802.1AB Frames

   Frames with this multicast address are used in the Station and Media
   Access Control Connectivity Discovery standard [802.1AB] which
   specifies the Link Layer Discovery Protocol (LLDP). These frames are
   also identified by the Ethertype 0x88CC.

   This protocol is generally outside of the scope of TRILL.



5.1.5 MRP, MMRP, and MVRP

   [WARNING: This section needs revision.]

   IEEE [802.1D] bridging defines a Generic Attribute Registration
   Protocol, GARP, on which a GARP Multicast Registration Protocol,
   GMRP, and a GARP VLAN Registration Protocol, GVRP, are based. GARP
   uses the bridge spanning tree protocol NSAP 0x42 and the frame begins
   LL-LL-42-42-03-00-01 where 0xLLLL is the length and the trailing


R. Perlman, et al                                              [Page 51]


INTERNET-DRAFT                                          RBridge Protocol


   0x0001 indicate the frame is a GARP PDU (see also Section 5.1.1).

   The multicast addresses in the range 01-80-C2-00-00-20 to
   01-80-C2-00-00-2F have been reserved for GARP applications.  [802.1D]
   requires that bridges transparently propagate frames to any multicast
   address in this range if they do not implement the corresponding GARP
   application.  RBridges do not implement any of these applications.
   They treat such frames as any other non-IP-derived Layer 2 multicast.

   The GMRP application of GARP uses multicast address
   01-80-C2-00-00-20.  It would provide a basis for the optimization of
   the distribution of frames with Layer 2 multicast addresses. However,
   RBridges provide for optional automatic IP based multicast
   optimization instead.

   The GVRP application of GARP uses multicast address
   01-80-C2-00-00-21.  It provides for the registration of VLANs and is
   not supported by RBridges.



5.1.6 Other Bridge Multicast Frames

   These frames relate to other bridge features outside of the scope of
   TRILL or are reserved for future standardization of such features.



5.2 Processing a Frame Received by an RBridge

   [WARNING: This section has not been fully updated to correspond with
   the rest of this draft.]

   The RBridge performing the processing is RBn.

   /* Ethertype abbreviations used are as follows:
      ------------------------------------------------------
      ****            Any Ethertype.
      IP**            IPv4 or IPv6 message Ethertype.
      IPv4    0x0800  IP version 4 message Ethertype.
      IPv6    0x86DD  IP version 6 message Ethertype.
      ISIS    0xFE    IS-IS Message NSAP value.
      MVRP    0x88F5  MVRP frame Ethertype
      TRILL   <TBD>   TRILL frame Ethertype.

         Table 5.3 Ethertype Abbreviastions
   */





R. Perlman, et al                                              [Page 52]


INTERNET-DRAFT                                          RBridge Protocol


   if ( port administratively disabled )
      {
      exit; /* discard frame */
      }

   /* Set per frame global data */

   Frame-VLAN = Determine Frame VLAN per Section 4.1.3;
   Frame-priority = Determine Frame Priority per Section 4.1.3;
   Frame-protocol = Extract Frame Ethertype / NSAP;

   AF = Appointed Forwarder status of RBn for Frame-VLAN for
           receiving port;

   The Frame-protocol, Outer.MacDA, and AF are then used to sequentially
   search the table below from the top.  As soon as a match is found,
   the processing indicated (either discard the frame or process as give
   in the reference) is performed.

   The "AF" column is "Y" if the RBridge must be the appointed forwarder
   on that port for Frame-VLAN, "N" if it must not be the appointed
   forwarder, and "*" if it does not matter.

         Sequential Table: Search from top for first match
      Ethertype  Dest.   AF    Section/Description
      ------------------------------------------------------------
      TRILL      SELF    *     5.2.3 TRILL encapsulated frame.
      TRILL      OTHERU  *     TRILL encapsulated frame addressed
                                 to another Rbridge; discard.
      TRILL      ALLRB   *     5.2.3 TRILL encapsulated frame.
      TRILL      BROAD   *     Erroneous frame but MAY be treated
                                 as if Destination was ALLRB.
      ****       ALLRB   *     Erroneous frame; discard.
      ****       ALLRBI  *     Erroneous frame; discard.
      ****       802MUL  *     5.1 Should not get here.

      MVRP       VRPMUL  *     5,2,X VLAN registration frame.
      MVRP       ****    *     Erroneous frame: discard.
      ****       VRPMUL  *     Erroneous frame: discard.
      IP**       ****    Y     5.2.1 Process IP frame.
      ****       IPMUL   *     Erroneous frame; discard.
      ****       ****    Y     5.2.4 Process native frame.
      ****       ****    N     Discard native frame

      Table 5.4 Initial Frame Dispatch







R. Perlman, et al                                              [Page 53]


INTERNET-DRAFT                                          RBridge Protocol


5.2.1 Further Dispatch for IP Frames

   Frames containing IP (Internet Protocol) payload, both IPv4 and IPv6,
   are treated in different ways depending on the particular protocol
   within IP which they are carrying. The following table is searched
   sequentially from the top and the first match used.  The "Ver."
   column is the version of IP used in the frame and "Proto" is the
   Payload IP protocol for the frame.

      Ver.   Proto     Section/Description
      ------------------------------------------------------------
      IPv4   IGMP    5.2.5 Internet Group Membership Protocol
      IPv6   MLD     5.2.5 Multicast Listener Discovery
      IP**   MRD     5.2.6 Multicast Router Discovery
      IP**   ****    5.2.4 Other

      Table 5.4 IP Frame Dispatch



5.2.2 Common Subroutines

   The following pseudo code subroutines are called from several places
   in Section 5.



5.2.2.1 Learn Source MAC Address

   If this pseudo code subroutine is called more than once for the same
   frame, all calls after the first have no effect and do not actually
   have to be performed.

   if (Outer.MacSA has the "group" bit off)
      {
      Learn Outer.MacSA for the port on which the frame was
      received for the determined VLAN unless configured
      not to do such learning.
      }



5.2.2.2 TRILL Frame Multi-destination Forwarding

   Forward a TRILL Frame over a distribution tree with VLAN pruning.

   {{ This code needs to be extended to perform similar pruning for
   multicast frames being forwarded to that done by Section 5.2.4 on
   received multicast native frames.}}



R. Perlman, et al                                              [Page 54]


INTERNET-DRAFT                                          RBridge Protocol


   if ( (Trill.HopCount = 0 ) or
        (RPF check fails on Outer.MacSA (Section 4.3.1) )
      {
      Exit; /* do not forward the frame */
      }
   else
      {
      For ( all ports from RBn on the tree rooted at the
            Trill.EgressNickname except that on which the
            frame was received )
         {
         if ( no downstream RBridges for Inner.VLAN )
            {
            Continue to next "for" value;
            }
         Execute 5.2.2.3;
         }
      }



5.2.2.3 TRILL Data Frame Tree Transmission

   Trill.HopCount -= 1 /* at least, see Section 3.4 */
   Outer.MacDA = ALLRB (or optionally, if there is
      only one destination, its unicast address).;
   Execute 5.2.2.4



5.2.2.4 TRILL Data Frame Transmission

   Outer.MacSA = MAC address of the port on which the
      frame is being sent;
   Outer.VLAN = DRB specified RBridge traffic VLAN for
      the port on which the frame is being sent;
   Outer.priority = Inner.priority;
   Include or omit Outer C-tag / priority tag as per
      802.1Q customer bridge port transmission rules;
   Transmit frame out port;












R. Perlman, et al                                              [Page 55]


INTERNET-DRAFT                                          RBridge Protocol


5.2.3 TRILL Ethertype Frames

   if (Trill.V > 0)
      {
      Discard the frame, unknown format.
      }
   elseif (Inner.MacDA == ALLRBI)  /* IS-IS */
      {
      Execute Section 5.2.3.1.
      }
   else  /* Inner.MacDA != ALLRBI, Data */
      {
      Execute Section 5.2.3.2.
      }



5.2.3.1 TRILL IS-IS Frames

   /* get here for TRILL Ethertype frames where Outer.MacDA is
      either ALLRB or SELF and the Inner.MacDA is
      All-IS-IS-Rbridges. TRILL Ethertype frames with other
      Outer.MacDA values are discarded by the dispatch table */

   if ( (Trill.M == 0) or
        (Inner.Protocol Type != ISIS ) or
        (Outer.MacSA !=
           a tree adjacency for tree indicated) )
     {
     Discard the frame.
     }
   elseif (inner VLAN tag not present)
     {
     Process payload as a core TRILL IS-IS message
       for RBn.
     Note: nicknames may be invalid, ignore them.
     }
   else /* inner VLAN tag is present */
     {
     If RBn has end stations on links for which it is the
     appointed forwarder for the indicated VLAN, give the
     IS-IS message to the per-VLAN IS-IS instance if
     implemented.

     Execute 5.2.2.2;  /* forward VLAN pruned */
     }






R. Perlman, et al                                              [Page 56]


INTERNET-DRAFT                                          RBridge Protocol


5.2.3.2 TRILL Data Frames

   /* get here for TRILL Ethertype frames where Outer.MacDA is
      either ALLRB or SELF and the Inner.MacDA is not
      All-IS-IS-Rbridges. TRILL Ethertype frames with other
      Outer.MacDA values are discarded by the dispatch table */

   if (Trill.M == 1)
     {                /* a multi-destination frame */
     If (Outer.MacSA !=
             a tree adjacency for tree indicated) )
       {
       Discard the frame.
       }
     else
       {
       If RBn is an appointed forwarder for the indicated VLAN,
       decapsulate the data frame and forward it onto appropriate
       links in the VLAN.

       Execute Section 5.2.2.2.
       }
     }
   else /* Trill.M == 0 */
      {
      if (Trill.EgressNickname == RBn)
         {
         If (Inner.MacDA is a group address)
           {
           Discard the frame.
           }
         Convert to native format and forward the extracted
         frame onto the link containing the destination or,
         if you don't know the destination, onto all local
         links in the Inner.VLAN for which you are an
         appointed forwarder.

         Locally process the frame if the Inner.MacDA == RBn.
         }
      else
         { /* The frame needs to be forwarded to another RBridge */
         if (Trill.HopCount = 0)
            {
            Discard the frame.
            }
         else
            {
            if (Trill.EgressNickname unknown)
               {
               Discard the frame.


R. Perlman, et al                                              [Page 57]


INTERNET-DRAFT                                          RBridge Protocol


               }
            Outer.MacDA = LookUpNextHop(Trill.EgressNickname);
            Outer.MacSA = MAC address of the port on which the
               frame is being sent;
            Outer.VLAN = DRB specified RBridge traffic VLAN for
               the port on which the frame is being sent;
            Outer.priority = Inner.priority;
            Include or omit Outer C-tag / priority tag as per
               802.1Q customer bridge port transmission rules;
            Transmit frame out port;
            }
      }



5.2.4 Native Frame Receipt

   The following pseudo code is executed for frames that are not of the
   TRILL Ethertype and are received on a port and VLAN for which the
   RBridge is the appointed forwarder (see Section 4.2.4).

   Execute Section 5.2.2.1.
   if (Outer.MacDA == SELF)
      {
      Process locally;
      /* A native frame for the RBridge received from a local
         link, for example a management protocol frame from a
         directly connected management station. */
      }
   elseif ({Outer.MacDA, Frame-VLAN} is a known unicast address)
      {
      if (Outer.MacDA is on the directly connected link on
            which the frame was received)
         {
         Exit; /* Destination has already seen it */
         }
      elseif (Outer.MacDA in Frame-VLAN is on another
                directly connect link)
         {
         Include or omit Outer C-tag / priority tag as per
            802.1Q customer bridge port transmission rules;
         Forward the native frame out the port for the link.
         }
      else
         {
         /* Assume that the egress RBridge is RBm */
         Inner.VLAN = Frame-VLAN;
         Inner.priority = Frame-priority;
         Trill.V = 0;
         Trill.R = 0;


R. Perlman, et al                                              [Page 58]


INTERNET-DRAFT                                          RBridge Protocol


         Trill.M = FALSE; /* this is not multi-destination */
         Trill.HopCount = determined value (see Section 3.4);
         Trill.EgressNickname = RBm;
         Trill.IngressNickname = RBn;
         Outer.MacDA = LookUpNextHop(Trill.EgressNickname);
         Outer.Ethertype = TRILL;
         Execute Section 5.2.2.4;
         }
   else
      { /* unknown unicast or general multicast or broadcast */
      Forward in native form to other links where RBn is the
        appointed forwarder for Frame-VLAN;
      Inner.VLAN = Frame-VLAN;
      Inner.priority = Frame-priority;
      Trill.V = 0;
      Trill.R = 0;
      Trill.M = TRUE; /* this is a multi-destination frame */
      Trill.EgressNickname = RBi /* Distribution Tree, See below */
      Trill.IngressNickname = RBn;
      Outer.Ethertype = TRILL;
      For ( all ports from RBn on the tree rooted at the
            Trill.EgressNickname )
         {
         if ( no downstream RBridges for Frame-VLAN for this port )
            {
            Continue to next "for" value;
            }
         if ( ( Inner.MacDA <= 00-01-5E-7F-FF-FF ) and
              ( Inner.MacDA >= 00-01-5E-00-00-00 ) )
            {
            returnValue = Execute 5.2.4.1;
            }
         elseif ( ( Inner.MacDA <= 33-33-FF-FF-FF-FF ) and
                  ( Inner.MacDA >= 33-33-00-00-00-00 ) )
            {
            returnValue = Execute 5.2.4.2;
            }
         elseif ( ( Inner.MacDA == FF-FF-FF-FF-FF-FF ) or
                  ( Inner.MacDA == ALLRBI ) )
            {
            returnValue = True;
            }
         elseif ( no downstream RBridges with Other Multicast
                    bit set for Frame-VLAN )
            {
            returnValue = False;
            }
         else
            {
            returnValue = True;


R. Perlman, et al                                              [Page 59]


INTERNET-DRAFT                                          RBridge Protocol


            }
         if ( returnValue )
            {
            Trill.HopCount = determined value (see Section 3.4);
            Execute 5.2.2.3;
            }
         } /* end For */
      }

   In the last case above, the egress nickname indicates the chosen
   distribution tree RBi. The default is for RBn to put its own address
   there. However, if RBn is configured to decline to be a tree root,
   then RBn MUST select some other RBridge RBi which has elected to be a
   tree root or the RBridge with the lowest ID if none have elected to
   be a tree root.



5.2.4.1 Native IPv4 Multicast Frame

   if ( Frame-protocol != IPv4 )
      {
      return ( False );  /* inconsistent frame */
      }
   elseif ( frame is an IGMP announcement )
      {
      if ( there are downstream IPv4 multicast routers )
         {
         return ( True );
         }
      else
         {
         return ( False );
         }
      }
   elseif ( IPv4 Destination multicast address is in the range
              which must be broadcast )
      {
      return ( True );
      }
   elseif ( there is a downstream listener or IPv4
            multicast router for Inner.MacDA )
      {
      return ( True );
      }
   else
      {
      return ( False );
      }



R. Perlman, et al                                              [Page 60]


INTERNET-DRAFT                                          RBridge Protocol


5.2.4.2 Native IPv6 Multicast Frame

   if ( Frame-protocol != IPv6)
      {
      return ( False );  /* inconsistent frame */
      }
   elseif ( frame is an MLD announcement )
      {
      if ( there are downstream IPv6 multicast routers )
         {
         return ( True );
         }
      else
         {
         return ( False );
         }
      }
   elseif ( IPv6 Destination multicast address is in the range
              which must be broadcast )
      {
      return ( True );
      }
   elseif ( there is a downstream listener or IPv6
            multicast router for Inner.MacDA )
      {
      return ( True );
      }
   else
      {
      return ( False );
      }



5.2.5 IGMP and MLD Frames

   An IGMP (IPv4 [RFC3376]) or MLD (IPv6 [RFC2710]) announcement
   received from a link by the appointed forwarder for Frame-VLAN
   teaches RBn a group membership on that link. RBn adds receiver for
   that Layer 2 group address for Frame-VLAN in its core link state
   instance.

   Then execute Section 5.2.4.



5.2.6 MRD Frames

   An MRD [RFC4286] reply or IGMP [RFC3376] query or MLD [RFC2710] query
   received from a link by the appointed forwarder for Frame-VLAN


R. Perlman, et al                                              [Page 61]


INTERNET-DRAFT                                          RBridge Protocol


   teaches RBn that there is an IP multicast router on that link. RBn
   adds that information, for IPv4 or IPv6 as appropriate, into its core
   IS-IS link state information for Frame-VLAN.

   Then execute Section 5.2.4.



5.3 Frames Spontaneously Sourced

   [WARNING: This section has not been fully updated to correspond with
   the rest of this draft.]

   The sections below discuss all frames that might be sent by an
   RBridge due to events other than the arrival of a frame.



5.3.1 Bridge/Media Frames Sourced

   RBridges are not required to originate any of the frames discussed in
   Section 5.1 (although it may be necessary for an 802.3 port to
   implement PAUSE to operate correctly in the presence of allowed clock
   skew).

   An RBridge port may optionally emit BPDUs as described in Section
   6.2.2. However, RBridges do not implement spanning tree or the
   spanning tree state machine.  It is never the case that a bridging
   spanning tree extends through an RBridge between its ports. Those
   ports always terminate the spanning tree.

   If an Rbridge port implements [802.1X], this MAY be used in
   determining the confidence level of learned addresses (see Section
   5.1.3).

   Other IEEE 802.1 and media specific frames may also be sent by an
   RBridge port but are generally out of scope for this document.



5.3.2 IS-IS Frames Sourced

   An RBridge R1 MUST send core instance TRILL IS-IS frames as described
   in 5.3.2.1. In addition, if it is appointed forwarder for a link that
   has end stations in a particular VLAN, it MAY run an IS-IS instance
   for that VLAN and emit TRILL per-VLAN IS-IS frames as described in
   5.3.1.2.





R. Perlman, et al                                              [Page 62]


INTERNET-DRAFT                                          RBridge Protocol


5.3.2.1 Core IS-IS Frames

   For core IS-IS frames, a TRILL header is added and no VLAN tag is
   included in the inner frame. The 802.3 LLC NSAP format MUST be used,
   that is LL-LL-FE-FE-03 where 0xLLLL is the length, 0x03 is the CTL
   octet, and 0xFE is the NSAP for IS-IS.  (The IS-IS standard also
   permits the less efficient SNAP SAP format LL-LL-AA-
   AA-03-00-00-00-80-FE which is not used in TRILL.)

   The frame it is formed as follows:

      Outer.MacDA = ALLRB;
      Outer.MacSA = RBn; // MAC address of transmission port
      Outer.Ethertype = TRILL.
      Trill.V = 1;
      Trill.R = 0;
      Trill.M = 0;
      Trill.HopCount = 1;
      Trill.IngressNickname = 0;
      Trill.EgressNickname = 0;
      Inner.MacDA = ALLRBI;
      Inner.MacSA = RBn;
      Inner.FrameLength = IS-IS frame length;
      Inner.DSAP = 0xFE;
      Inner.SSAP = 0xFE;
      Inner.CTL = 3;
      followed by the rest of the IS-IS Frame.

   The frame is then sent out all ports of the RBridge if it is a Hello.
   If it is a non-Hello, it is sent out all ports on which there is an
   IS-IS adjacency.  For each port not either known to be a point-to-
   point connection to an Rbridge or configured not to use Outer VLAN
   Tags, an Outer VLAN Tag is added as follows:

      Outer VLAN Tag priority = 7;
      Outer VLAN ID = VLAN ID associated with inter-Rbridge
         traffic on the port.

   Note that this Outer VLAN Tag may be different on different ports.

   The Inner.MacDA is always All-IS-IS-Rbridges for all TRILL IS-IS
   frames. Furthermore, core instance TRILL IS-IS Hellos MUST always be
   send out all enabled ports to the All-Rbridges multicast address.
   However, non-Hello core TRILL IS-IS messages for which there is only
   one destination MAY be sent to a unicast Outer.MacDA as follows:

      Outer.MacDA = DestinationRBridge;
      Outer.MacSA = RB1;  // MAC address of transmission port
      Outer.Ethertype = TRILL.
      Trill.V = 1;


R. Perlman, et al                                              [Page 63]


INTERNET-DRAFT                                          RBridge Protocol


      Trill.R = 0;
      Trill.M = 0;
      Trill.HopCount = 1;
      Trill.IngressNickname = 0;
      Trill.EgressNickname = 0;
      Inner.MacDA = DestinationRBridge;
      Inner.MacSA = RB1;
      Inner.FrameLength = IS-IS frame length;
      Inner.DSAP = 0xFE;
      Inner.SSAP = 0xFE;
      Inner.CTL = 3;
      followed by the rest of the IS-IS Frame.

   The frame is then transmitted on the port for DestinationRBridge with
   an Outer VLAN Tag possibly added using the same logic as for a
   multicast core TRILL IS-IS frame above.



5.3.2.2 Per-VLAN IS-IS Frames

   For per-VLAN TRILL IS-IS frames, a TRILL header is added and a VLAN
   tag is always included in the inner frame. Note that, in a strict
   sense, IS-IS has no Ethertype but the 802.3 NSAP format must be used
   as discusses at the start of section 5.3.2.1.

   If the frame is per-VLAN multicast, it is formed as follows:

      Outer.MacDA = All-RBridges;
      Outer.MacSA = RB1;
      Outer.Ethertype = TRILL.
      Trill.V = 0;
      Trill.R = 0;
      Trill.M = 1;
      Trill.HopCount = count to reach farthest node in the
                       distribution tree;
      Trill.IngressNickname = RB1 nickname;
      Trill.EgressNickname = SelectedDistributionTree;
      Inner.MacDA = All-IS-IS-RBridges;
      Inner.MacSA = RB1;
      Ethertype = VLAN Tag;
      Inner VLAN Tag priority = 7;
      Inner.VLAN = Relevant VLAN;
      Inner.FrameLength = IS-IS frame length
      Inner.DSAP = 0xFE;
      Inner.SSAP = 0xFE.
      Inner.CTL = 3;
      followed by the rest of the IS-IS Frame.

   The frame is then sent out the ports appropriate for the selected


R. Perlman, et al                                              [Page 64]


INTERNET-DRAFT                                          RBridge Protocol


   distribution tree pruned to the selected VLAN.  The presence or
   absence of downstream RBridges with the Other Multicast (OM) flag on
   for that VLAN is ignored and the frame is distributed to all RBridges
   that indicate they are connected to that VLAN.  Other than this
   special handling of downstream Other Multicast flags, per-VLAN
   instance TRILL IS-IS frames are distributed like any other non-IP-
   derived Layer 2 multicast.



5.3.3 Other Frames Sourced

   Other frames may be sourced due to management protocols or general
   applications running on an RBridge. These can be handled as if they
   were received by the RBridge on a port for which it was the appointed
   forwarder and on which there were no know directly connected
   stations, as described in Section 5.2.4.

   [WARNING: Section 5 has not been fully updated to correspond with the
   rest of this draft.]
































R. Perlman, et al                                              [Page 65]


INTERNET-DRAFT                                          RBridge Protocol


6. Incremental Deployment Considerations

   Because RBridges are generally compatible with current IEEE 802.1Q
   customer bridges, a LAN can be upgraded by incrementally replacing
   such bridges with RBridges. Any remaining bridges are transparent to
   RBridge traffic.  The physical links directly interconnected by such
   bridges, which, together with the bridges, constitute bridged LANs,
   appear to RBridges to be multi-access links.  If the bridges that
   were replaced by RBridges were un-managed, zero configuration
   bridges, then the RBridge replacements will not require
   configuration.

   The campus will work best if all IEEE 802.1 bridges are replaced with
   RBridges, assuming the RBridges have the same basic speed and
   capacity as the bridges. However, there may be intermediate states,
   where only some bridges have been replaced by RBridges.



6.1 VLAN Connectivity Changes

   Even with partial RBridge deployment, RBridges will provide
   connectivity between all links in a particular VLAN that are
   connected to an RBridge, assuming TRILL connectivity between the
   RBridges themselves. This is true even where the bridged LAN into
   which the RBridges are being introduced was configured so as to
   partition one or more particular VLANs into unconnected islands.



6.2 Link Cost Determination

   With an RBridged campus having no bridges 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
   bridges, this is no longer possible. For example, as shown in Figure
   9, 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 6,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


R. Perlman, et al                                              [Page 66]


INTERNET-DRAFT                                          RBridge Protocol


   from how it is seen by the other.

   However, this problem is not unique to RBridges. Routers and bridges
   can encounter similar situations.



6.3 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. 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
      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 to other bridges
      and peripheral bridges that connected to end stations and 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 6.4.

   2. TRILL traffic sent to the All-Rbridge 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 intended RBridge next hop recipient, 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 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 which 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


R. Perlman, et al                                              [Page 67]


INTERNET-DRAFT                                          RBridge Protocol


      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.4). 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 6.4.2) 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
      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 evade
   the congestion that can be caused by the spanning tree protocol.
   Replacing the IEEE 802.1 bridges in such LANs with RBridges may
   enable a reduction in or elimination of VLANs and configuration
   complexity.



6.4 Wiring Closet Topology

   If 802.1 bridges are present and RBridges are not configured, the
   bridge spanning tree or the appointed forwarder designation may make
   inappropriate decisions.  Below is a detailed example of the more
   general problem that can occur when a bridge 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 6.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.









R. Perlman, et al                                              [Page 68]


INTERNET-DRAFT                                          RBridge Protocol


                   +-------------------------------+
                   |             |          |      |
                   |  Data    +-----+    +-----+   |
                   | Center  -| RB1 |----| RB2 |-  |
                   |          +-----+    +-----+   |
                   |             |          |      |
                   +-------------------------------+
                                 |          |
                                 |          |
                   +-------------------------------+
                   |             |          |      |
                   |          +----+     +----+    |
                   | Wiring   | B1 |-----| B2 |    |
                   | Closet   +----+     +----+    |
                   |                               |
                   +-------------------------------+

                     Figure 6.2 Wiring Closet Topology

   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 would be that one of RB1 or RB2 (say RB1) would
   become DRB for the bridged LAN including B1 and B2 and appoint itself
   forwarded 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 probably be to make use of both
   the RB1-B1 and RB2-B2 links.

   Three solutions to this problem are described below.



6.4.1 The RBridge Solution

   Of course, if B1 and B2 are replaced with RBridges, the right thing
   will happen with zero configuration, but this may not be immediately
   practical if bridges are being incrementally replaced by RBridges.



6.4.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


R. Perlman, et al                                              [Page 69]


INTERNET-DRAFT                                          RBridge Protocol


   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 RBs fail or become disconnected, the other will have
   only itself to appoint 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 which might
   require further measures, outside the scope of this specification, to
   rectify.



6.4.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
   logically partition the bridged LAN by blocking the B1-B2 link at one
   end or the other as desired (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
   can not see each others 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 BPDU, the Root is "RBx" with highest priority, cost to Root is
   0, Designated Bridge ID is "RB1" when R1 transmits and "RB2" when R2
   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 tie-breaker 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.







R. Perlman, et al                                              [Page 70]


INTERNET-DRAFT                                          RBridge Protocol


6.4.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 6.4.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 71]


INTERNET-DRAFT                                          RBridge Protocol


7. RBridge Addresses, Parameters, and Constants

   IS-IS requires each RBridge to have a unique 6-octet System ID. This
   is easily obtainable, for example, as any one of the 6-octet MAC
   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. All-RBridges for
   use as the destination address in multi-destination frames.  And All-
   IS-IS-RBridges as the inner destination MAC address for TRILL IS-IS
   frames.

   To support VLANs, RBridges (like bridges today), must be configured
   appropriately. RBridge ports may also be configured to map frame
   priorities (see Section 4.1.3).

   RBridges may be configured with a nickname and nickname selection
   priority.

   RBridges may be configured to have per-VLAN IS-IS instances 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 parameter RequestTree that indicates whether an
   RBridge wants to be the root of a distribution tree which defaults to
   true.

   The per RBridge per-VLAN Other Multicast bit, which defaults to true,
   to request the receipt of non-IP derived multicast traffic.

   Configuration for the send-BPDUs solution to the wiring closet
   topology problem (see Section 6.4.2) 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 it should use in the spanning tree protocol on the
   specified port.












R. Perlman, et al                                              [Page 72]


INTERNET-DRAFT                                          RBridge Protocol


8. 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 RBridge IS-IS
   instances to use IS-IS security [RFC3567] and ignore unauthenticated
   control 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 per-VLAN IS-IS instance (see Section 4.6).

   TRILL encapsulates native frames inside the TRILL Ethertype while
   they are in transit between that frame's ingress and egress RBridge.
   Thus, TRILL ignorant devices with firewall features and which can not
   be detected by RBridges as end stations will generally not be able to
   examine the interior of such frames for security checking purposes
   and may be less effective.  Since routers and hosts appear to
   RBridges to be end stations, such frames will be decapsulated before
   being sent to such devices and 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 separate of traffic but
   care should be taken is using VLANs for security purposes. To have
   reasonable assurance of such separation, all the RBridges and links
   in a campus must by secured and configured so as to prohibit end
   stations from using dynamic VLAN registration frames or otherwise
   gaining access to any VLAN carrying sensitive traffic for which they
   are not authorized.

   RBridges do not prevent nodes from impersonating other nodes, for
   instance, by issuing bogus ARP/ND replies.  However, RBridges do not
   interfere with any schemes that would secure neighbor discovery.








R. Perlman, et al                                              [Page 73]


INTERNET-DRAFT                                          RBridge Protocol


9. Assignment Considerations

   This section discuses IANA and IEEE 802 assignment considerations.



9.1 IANA Considerations

   A new IANA registry is created for TRILL, the initial contents of
   which is TRILL Version number 0.

   New TRILL Header Version numbers  and uses of TRILL Header Reserved
   bits are assigned by an IETF Standards Action [RFC2434] as modified
   by [RFC4020].



9.2 IEEE 802 Assignment Considerations

   The Ethertype <tbd> is assigned by IEEE 802 to indicate a TRILL
   encapsulated frame.

   The Layer 2 multicast addresses <tbd1> and <tbd2> are assigned by
   IEEE 802 for "All-Rbridges" and "All-IS-IS-Rbridges".




























R. Perlman, et al                                              [Page 74]


INTERNET-DRAFT                                          RBridge Protocol


10. Acronyms

      AllL1ISs - All Level 1 Intermediate Systems

      AllL2ISs - All Level 2 Intermediate Systems

      CHbH - Critical Hop-by-Hop

      CItE - Critical Ingress-to-Egress

      DA - Destination Address

      ECMP - Equal Cost Multi-Path

      DRB - Designated RBridge

      FCS - Frame Check Sum

      IEEE - Institute of Electrical and Electronic Engineers

      IGMP - Internet Group Membership Protocol

      IS-IS - Intermediate Systems to Intermediate System

      LSP - Link State PDU

      MAC - Media Access Control

      MLD - Multicast Listener Discovery

      MMRP - Multiple MAC Registration Protocol

      MRD - Multicast Router Discovery

      MRP - Multiple Registration Protocol

      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



R. Perlman, et al                                              [Page 75]


INTERNET-DRAFT                                          RBridge Protocol


      SNP - Sequence Number PDU

      SPF - Shortest Path First

      TLV - Type, Length, Value

      TRILL - TRansparent Interconnection of Lots of Links

      VLAN - Virtual Local Area Network











































R. Perlman, et al                                              [Page 76]


INTERNET-DRAFT                                          RBridge Protocol


11. Normative References

   [802.1ak] "IEEE Standard for Local and metropolitan area networks /
      Virtual Bridged Local Area Networks / Multiple Registration
      Protocol", 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.

   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
      IANA Considerations Section in RFCs", BCP 26, RFC 2434, October
      1998.

   [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.

   [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of
      Standards Track Code Points", BCP 100, RFC 4020, February 2005.

   [RFC4286] Haberman, B., Martin, J., "Multicast Router Discovery", RFC
      4286, December 2005.



R. Perlman, et al                                              [Page 77]


INTERNET-DRAFT                                          RBridge Protocol


12. 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-04.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-02.txt, February 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.

   [RFC3410] Case, J., Mundy, R., Partain, D., and B.  Stewart,
      "Introduction and Applicability Statements for Internet-Standard
      Management Framework", RFC 3410, 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 78]


INTERNET-DRAFT                                          RBridge Protocol


Appendix A: Revision History

   RFC Editor: Please delete this appendix 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 79]


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 80]


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 this draft has not been fully updated to
   incorporate the changes below.]


R. Perlman, et al                                              [Page 81]


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.

   15. Replace some remaining references to Q-tag with C-tag.

   16. Miscellaneous minor editing and terminology updates. Changed
       Figure numbers to be relative to major section. Added Table
       captions.

   [WARNING: Section 5 of this draft has not been fully updated to
   incorporate the changes above.]





R. Perlman, et al                                              [Page 82]


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 83]


INTERNET-DRAFT                                          RBridge Protocol


Authors' Addresses

   Radia Perlman
   Sun Microsystems

   Email: Radia.Perlman@sun.com


   Donald E. Eastlake, 3rd
   Motorola Laboratories
   111 Locke Drive
   Marlborough, MA 01752 USA

   Phone: +1-508-786-7554
   Email: Donald.Eastlake@motorola.com


   Silvano Gai
   Nuova Systems
   2600 San Tomas Expressway
   Santa Clara, CA 95051 USA

   Phone: +1-408-387-6123
   Email: sgai@nuovasystems.com


   Dinesh G. Dutt
   Cisco Systems
   170 Tasman Drive
   San Jose, CA 95134-1706 USA

   Phone: +1-408-527-0955
   EMail: ddutt@cisco.com


   Anoop Ghanwani
   Brocade
   1745 Technology Drive
   San Jose, CA 95110 USA

   Phone: +1-408-333-7149
   Email: anoop@brocade.com



Expiration and File Name

   This draft expires in August 2008.

   Its file name is draft-ietf-trill-rbridge-07.txt.


R. Perlman, et al                                              [Page 84]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/