[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                                                         R.Perlman
Internet Draft                                         Sun Microsystems
Intended status: Proposed Standard                          Silvano Gai
                                                           Nuova Systems
                                                          Dinesh G. Dutt
                                                           Cisco Systems
Expires: August 2007                                          March 2007

                   RBridges: Base Protocol Specification

Status of this Memo

   By submitting this Internet-Draft, each author represents that
   any applicable patent or other IPR claims of which he or she is
   aware have been or will be disclosed, and any of which he or she
   becomes aware will be disclosed, in accordance with Section 6 of
   BCP 79.

   Distribution of this document is unlimited. Comments should be sent
   to the TRILL working group mailing list.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire September 2007.


   RBridges allow for optimal pair-wise forwarding with zero
   configuration, safe forwarding even during periods of temporary
   loops, and the ability to cut down on ARP/ND and IP multicast

Perlman, Gai, Dutt     Expires  September 2007                 [Page 1]

Internet-Draft              RBridge Protocol                 March 2007

   traffic. They achieve these goals by replacing the Spanning Tree
   protocol with IS-IS.

   The design also supports VLANs, and allows forwarding tables to be
   based on RBridge destinations (rather than endnode destinations),
   which allows internal forwarding tables to be substantially smaller
   than in conventional bridge systems.


   Many people have contributed to this design, including the working
   group co-chairs Donald Eastlake 3rd and Erik Nordmark, and many other
   members of the working group including, in alphabetic order, Alia
   Atlas, Stewart Bryant, Dino Farinacci, Don Fedyk, Eric Gray, Sanjay
   Sane, and Joe Touch. We invite you to join the mailing list at

Table of Contents

   1. Introduction...................................................3
      1.1. Algorhyme V2..............................................4
      1.2. Conventions used in this document ........................5
   2. RBridges.......................................................5
      2.1. RBridge Architecture......................................6
      2.2. RBridges and VLAN.........................................8
      2.3. Forwarding of Different Frame Types.......................9
         2.3.1. Known-Unicast........................................9
         2.3.2. Multi-destination....................................9
      2.4. Advantages of RBridges...................................10
   3. Detailed RBridge Design.......................................10
      3.1. TRILL Header Format......................................10
         3.1.1. Version (V).........................................11
         3.1.2. Multi-destination (M)...............................11
         3.1.3. Hop Limit...........................................11
         3.1.4. RBridge addresses...................................12
   Egress RBridge Address.........................12
   Ingress RBridge Address........................12
      3.2. Ethernet Encapsulation...................................12
         3.2.1. Outer VLAN Tag......................................14
         3.2.2. Inner VLAN Tag......................................14
         3.2.3. FCS.................................................15
         3.2.4. Point-to-point links................................15
      3.3. Link State Protocol (IS-IS)..............................15
         3.3.1. IS-IS RBridge Identity..............................16
         3.3.2. Separate Instances..................................16
         3.3.3. Multiple RBridge IS-IS Instances....................16
   The IS-IS core instance........................16

Perlman, Gai, Dutt     Expires  September 2007                 [Page 2]

Internet-Draft              RBridge Protocol                 March 2007

   The IS-IS VLAN instance........................17
         3.3.4. Designated RBridge..................................18
      3.4. Distribution Trees.......................................20
         3.4.1. Distribution Tree Calculation.......................21
      3.5. Pruning the Distribution Tree............................22
      3.6. Forwarding using a Distribution Tree.....................22
      3.7. Wiring Closet Topology...................................23
      3.8. Learning Endnode Location................................24
      3.9. Forwarding Behavior......................................25
         3.9.1. Receipt of a Native Frame...........................25
   Unicast case...................................25
   Other multi-destination frames.................26
   IS-IS frames...................................26
         3.9.2. Receipt of an In-transit Frame......................27
   Flooded Frame..................................27
   Unicast Frame..................................28
   IS-IS Frame....................................28
      3.10. IGMP Learning...........................................28
      3.11. RBridge Addresses.......................................29
      3.12. Handling ARP/ND Queries.................................29
      3.13. Discovering IP Multicast Routers........................31
      3.14. Assuring Freshness of Endnode Information...............31
   4. RBridge Addresses, Parameters, and Constants..................32
   5. Security Considerations.......................................32
   6. IANA Considerations...........................................33
   7. References....................................................33
      7.1. Normative References.....................................33
      7.2. Informative References...................................34
   Intellectual Property Statement..................................35
   Disclaimer of Liability..........................................36
   Copyright Statement..............................................36

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 not fully
   populated and waste addresses. IEEE 802.1 bridges avoid these
   problems by transparently gluing many physical links into what
   appears to IP to be a single LAN.

Perlman, Gai, Dutt     Expires  September 2007                 [Page 3]

Internet-Draft              RBridge Protocol                 March 2007

   Bridge forwarding via the spanning tree has some disadvantages:

   o  The spanning tree blocks ports limiting the number of forwarding
      links and therefore creates bottleneck by concentrating traffic
      onto selected links.

   o  The Ethernet header does not contain a TTL field and this is
      dangerous when there are temporary loops such as when spanning
      tree messages are lost or components such as repeaters are added.

   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),
   which combines the advantages of bridges and routers [RBridges] and
   which is poetically summarized below. While RBridge technology can
   be applied to a variety of link protocols, this specification, where
   relevant, concentrates on 802.3 links.

1.1. Algorhyme V2

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

   RBridges work transparently.
   Without a common spanning tree.

                                 Ray Perlner

Perlman, Gai, Dutt     Expires  September 2007                 [Page 4]

Internet-Draft              RBridge Protocol                 March 2007

1.2 Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

2. RBridges

   The main idea is to have RBridges run a link state protocol amongst
   themselves. This enables them to have enough information to compute
   pairwise optimal paths for unicast, and to calculate distribution
   trees for delivery of frames either to unknown destinations, or to
   multicast/broadcast groups.

   ECMP (Equal Cost MultiPath) may be supported, but it may introduce
   frame reordering.

   To mitigate the temporary loop issues, RBridges forward based on a
   header with a hop limit (AKA TTL or hop count). Although the hop
   limit discards looping frames, it is also desirable not to spawn
   additional copies of frames by having RBridges specify the next
   RBridge recipient, while forwarding across a shared-media link.

   RBridges MUST learn the location of endnodes. They learn the location
   and layer 2 addresses of attached nodes from the source address of
   frames, as bridges do (for example, see section 8.7 of [802.1Q]).
   RBridges also learn the IP addresses of directly attached
   nodes and their association with MAC addresses from ARP/ND

   Once an RBridge learns the location of a directly attached endnode,
   it advertises this information to the other RBridges in its link
   state information.

Perlman, Gai, Dutt     Expires  September 2007                 [Page 5]

Internet-Draft              RBridge Protocol                 March 2007

2.1. RBridge Architecture

      |                  Higher Layer Entities                   |
      |   \ Trill Layer | RBridge Relay Entity | Trill Layer /   |
      | Data Link Layer |                      | Data Link Layer |
      +-----------------+                      +-----------------+
      | Physical Layer  |                      | Physical  Layer |
      +-------+---------+                      +-------+---------+
              |                                        |
             P1                                       P2

                    Figure 1 Architecture of an RBridge

   Figure 1 shows an RBridge that contains:

   o  An Rbridge Relay Entity that interconnects two Rbridge ports;

   o  At least one port (two in the example);

   o  Higher Layer Entities, including at least the IS-IS protocol.

   o  The TRILL Layer. An RBridge encapsulates incoming IEEE 802.3
      frames (in this document also referred to as Ethernet frames) with
      a TRILL header to forward them to other Rbridges.

   The layer 2 technology used to connect Rbridges may be either IEEE
   802.3 or some other technology such as PPP. This is possible since
   the functionality of an RBridge relay entity is layered on top of the
   layer 2 technologies.

   However, in accordance with the TRILL WG charter, the first edition
   of this document specifies only an IEEE 802.3 encapsulation.

   Figure 2 shows two RBridges R1 and R2 interconnected through an
   Ethernet cloud. There are no restrictions on what may compose the
   Ethernet cloud: point-to-point or shared media, hubs and bridges. The
   Ethernet cloud may support VLAN tagging or not.

Perlman, Gai, Dutt     Expires  September 2007                 [Page 6]

Internet-Draft              RBridge Protocol                 March 2007

                      /            \
          +----+     /   Ethernet   \    +----+
          | R1 |----<                >---| R2 |
          +----+     \    Cloud     /    +----+
                      \            /

                     Figure 2 Interconnected RBridges

   Figure 3 shows the format of a TRILL frame traveling through the
   Ethernet cloud from R1 to R2.

                   |     Outer Ethernet Header      |
                   |          TRILL Header          |
                   |     Inner Ethernet Header      |
                   |        Ethernet Payload        |
                   |         Ethernet FCS           |

               Figure 3 An Ethernet Encapsulated TRILL Frame

   In the case of other media different from Ethernet, the outer
   Ethernet header is replaced by the header specific to that media. For
   example, figure 4 shows a TRILL encapsulation over PPP.

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

                  Figure 4 A PPP Encapsulated TRILL Frame

Perlman, Gai, Dutt     Expires  September 2007                 [Page 7]

Internet-Draft              RBridge Protocol                 March 2007

   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
   those of the original frame.

   Frames are encapsulated with a TRILL header as they travel between
   RBridges for several reasons:

   1. to mitigates the loop issues with bridges a hop limit field is

   2. to prevent 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 endnodes.

   When forwarding between RBridges across a shared-media, the data link
   layer header contains the address of the next hop Rbridge, to avoid
   frame duplication and, in the case of loops, to avoid spawning
   additional copies of frames.

2.2. RBridges and VLAN

   A VLAN is a way to partition endnodes into different communities
   [802.1Q]. The usual method of determining which community a frame
   belongs to is based on the port from which it is received. IEEE
   802.1Q compliant bridges support VLANs and the same support is
   present in RBridges.

   IEEE 802.1Q bridges have the capability of supporting multiple VLANs
   over a single link by inserting/removing a VLAN tag into the frame.
   Some endnodes have the same capability.

   The VLAN tag is structured according to IEEE 802.1Q. As shown in
   figure 3, there are two places where such tags may be present in a
   TRILL-encapsulated frame: one in the outer header (outer VLAN) and
   one in the inner header (inner VLAN). Inners and Outer VLANs are
   further discussed in section 3.2.

   RBridges enforce that a frame originating in a particular inner VLAN
   gets delivered only to other links in the same inner VLAN.

Perlman, Gai, Dutt     Expires  September 2007                 [Page 8]

Internet-Draft              RBridge Protocol                 March 2007

   A side-effect of inner VLANs is that it makes RBridges more scalable,
   since endnode membership in an inner VLAN is only of interest to
   RBridges that have an attached port configured to be in that inner

2.3. Forwarding of Different Frame Types

   There are several types of frames which RBridges forward slightly
   differently. They are here classified into two main categories:
   known-unicast and multi-destination.

2.3.1. Known-Unicast

   These frames have an inner MAC Destination Address (Inner.MacDa) that
   is unicast and the MAC address location is known to the ingress
   RBridge (the RBridge that performs the TRILL encapsulation).

2.3.2. Multi-destination

   These are frames that must be delivered to multiple destinations,
   because either they have a group address or the location of the
   destination is unknown.

   They are:

   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;

   3. frames for layer 2 multicast addresses not derived from IP
      multicast addresses: the Inner.MacDa is multicast;

   4. frames for the layer 2 broadcast addresses: the Inner.MacDa is

   5. ARP queries: the Inner.MacDa is broadcast;

   6. ND queries: the Inner.MacDa is multicast;

Perlman, Gai, Dutt     Expires  September 2007                 [Page 9]

Internet-Draft              RBridge Protocol                 March 2007

   7. IGMP membership reports: the Inner.MacDa is multicast.

   RBridges build distribution trees (see Section 3.4. ) and use these
   trees for forwarding multi-destination frames.

2.4. Advantages of RBridges

   Like bridges, RBridges are zero configuration and transparent to IP
   nodes.  Like routers, RBridges forward on pair-wise shortest paths,
   and do not create broadcast storms during temporary loops.

   RBridges have the additional advantage that they may optimize IP
   multicast traffic, and ARP (IPv4) [RFC826] and ND (IPv6) [RFC2461]
   by avoiding the broadcast/multicast behavior of the queries.

   RBridges are fully compatible with current 802.1D and 802.1Q bridges
   as well as current IPv4 and IPv6 routers and endnodes.  They are as
   invisible to current IP routers as bridges are, and like routers,
   they terminate the spanning tree protocol.

3. Detailed RBridge Design

3.1. TRILL Header Format

   The TRILL header is shown in Figure 5 and it is independent of the
   data link layer used.

                                      | V | Hop Limit |M|  Reserved   |
      |  Ingress RBridge Address      |  Egress RBridge Address       |

                       Figure 5 TRILL Encapsulation

   o  V (Version): 2-bit. See Section 3.1.1.

   o  Hop Limit: 6-bit unsigned integer. See Section 3.1.3.

   o  M (Multi-destination): 1-bit. See Section 3.1.2.

   o  Reserved: 7-bit.

Perlman, Gai, Dutt     Expires  September 2007                [Page 10]

Internet-Draft              RBridge Protocol                 March 2007

   o  Ingress RBridge Address: 16-bit address. See Section

   o  Egress RBridge Address: 16-bit address. See Section

3.1.1. Version (V)

   According to IEEE's Ethertype format 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. In adhering to this guideline, a two bit
   field called version is used to identify the format in use. It is
   set to 0 by default. If it is set to 1, 2, 3 the header format is
   undefined by this version of the standard.

3.1.2. Multi-destination (M)

   The Multi-destination bit (see Section 2.3.2. ) specifies the content
   of the egress RBridge address:

   o  M = 0 (FALSE) - the egress RBridge address contains the address of
      the egress Rbridge;

   o  M = 1 (TRUE) - the egress RBridge address contains the address of
      the RBridge that is the root of the distribution tree.

3.1.3. Hop Limit

   A 6-bit unsigned integer. Each RBridge MUST check this field before
   forwarding the frame to another RBridge. If this field is zero, the
   frame MUST be discarded. If this field is non-zero, it MUST be
   decremented by one in the forwarded frame.

   This field was previously referred to as TTL (Time To Live) or hop
   count. In IPv6 the IETF has replaced the concept of TTL with Hop
   Limit. TRILL aligns with this newer definition.

Perlman, Gai, Dutt     Expires  September 2007                [Page 11]

Internet-Draft              RBridge Protocol                 March 2007

3.1.4. RBridge addresses

   16-bit address. This is the TRILL address of the RBridge. This
   assignment allows addressing up to 64K RBridges. This was also
   referred to in the past as "RBridge nickname" or "shim nickname".

   The simplest encoding of an RBridge address would be a 48-bits MAC
   address. However, to achieve a more compact encoding, RBridges
   piggyback a address acquisition protocol on the link state protocol
   (see Section 3.11. ), to acquire a unique 16-bit addresses (within
   the campus). Egress RBridge Address

   This field contains two types of information, depending on M-bit (see
   Section 3.1.2. ):

   o  For known-unicast frames, it contains the egress RBridge Address
      i.e. the RBridge that needs to remove the TRILL header from the

   o  For multi-destination frames, it contains the address of the root
      RBridge of the distribution tree to be used to forward the frame. Ingress RBridge Address

   The ingress RBridge address always contains the identifier of the
   ingress RBridge, i.e. the RBridge that added the TRILL header to the

3.2. Ethernet Encapsulation

   TRILL frames in transit on Ethernet links are encapsulated with an
   additional outer Ethernet header (see figure 3). This outer header
   looks, to an Ethernet 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 encapsulated frames, a new Ethertype = TRILL (to be
   assigned) is used in the outer header.

Perlman, Gai, Dutt     Expires  September 2007                [Page 12]

Internet-Draft              RBridge Protocol                 March 2007

   Figure 6 details a frame traveling on the Ethernet cloud of Figure 2
   from R1 to R2. This encapsulation has the advantage of aligning the
   original Ethernet frame at 64 bit boundaries.

      |               Outer Destination MAC Address                   |
      | Outer Destination MAC Address | Outer Source MAC Address      |
      |                   Outer Source MAC Address                    |
      | Ethertype = IEEE 802.1Q       | UP  |C|   Outer VID           |
      | Ethertype = TRILL             | V | Hop Limit |M|  Reserved   |
      |  Egress RBridge Address       |  Ingress RBridge Address      |
      |               Inner Destination MAC Address                   |
      | Inner Destination MAC Address | InnerSource MAC Address       |
      |                    Inner Source MAC Address                   |
      | Ethertype = IEEE 802.1Q       | UP  |C|   Inner VID           |
      |                                                               |
      |                 Original Ethernet Payload                     |
      |                                                               |
      |                           New FCS                             |
               Figure 6   TRILL Encapsulation over Ethernet

   When a TRILL frame is carried over an Ethernet cloud it has three
   sets of addresses:

   o  Outer MAC Addresses. These addresses are used to address the next
      hop RBridge over a shared Ethernet Cloud.

   o  TRILL Addresses. These are the end-to-end addresses of the
      RBridges doing the encapsulation/decapsulation (at least for the
      known unicast case, see Section 3.1.4. ).

   o  Inner MAC Addresses. These are the addresses of the endnodes, as
      originally inserted in the frames by the transmitting endnode.

Perlman, Gai, Dutt     Expires  September 2007                [Page 13]

Internet-Draft              RBridge Protocol                 March 2007

   It also potentially has two IEEE 802.1Q tags that carries two
   different VLAN Identifier (VID).

3.2.1. Outer VLAN Tag

   The Outer VLAN Tag: MAY or MAY NOT be present. If present, it is used
   to enable connectivity between two RBridges through an Ethernet cloud
   that support VLANs. Once two RBridges have established connectivity
   on an outer VLAN, they become adjacent and they start to operate as
   if connected by a direct link.

   For example, a network manager may configure VLAN 4 for RBridges RB1
   and RB2 to communicate (the outer VID contains the value 4). VLAN 3
   may be assigned for RB2 and RB3 to communicate (the outer VID
   contains the value 3). In this case RB2 becomes adjacent to both RB1
   (on VLAN 4) and RB3 (on VLAN 3), but RB1 and RB3 are not adjacent
   (since they have no common VLAN).

   There is no additional discussion of this field in the rest of the

3.2.2. Inner VLAN Tag

   The Inner VLAN Tag: contains the VLAN information associated with the
   original frame.

   Each Ethernet port of an RBridge uses the "ingress rule" specified in
   Section 6.7 of IEEE 802.1Q. This rule always associates a VID (VLAN
   Identifier) with any frame, independently of whether the frame came
   in tagged, untagged or priority tagged.

   Since the most common default value for the parameter PVID (Port VLAN
   Identifier) is 1, an Rbridge MAY suppress the inner VLAN tag for
   frames with VID = 1.

   The Inner VID is extremely important for TRILL (see section 2.2. ).

   In the rest of this document, any reference to the term VLAN should
   be interpreted as inner VLAN.

Perlman, Gai, Dutt     Expires  September 2007                [Page 14]

Internet-Draft              RBridge Protocol                 March 2007

3.2.3. FCS

   The frame has a single FCS that is computed to cover the entire
   frame. This has become standard practice in IEEE 802.1: the tagging
   structure effectively requires FCS recomputation at the boundaries of
   the network. Additionally, the IETF (with diffserv, ECN, routing)
   have also effectively required FCS recomputation at all boundaries of
   the network.

3.2.4. Point-to-point links

   If there is a direct RBridge-to-RBridge point-to-point link, there is
   no real need for the outer header. Therefore if the link is a point-
   to-point Ethernet link, it is acceptable to set the fields in the
   outer header to predefined values on transmission and ignore them on

3.3. Link State Protocol (IS-IS)

   In recent years, the IS-IS routing protocol [ISO10589] has become
   increasingly popular, with widespread usage among Service Providers.
   It is a link state protocol, which enables very fast convergence with
   large scalability. It is also a very flexible protocol and has been
   extended to incorporate leading edge features such as MPLS Traffic

   TRILL uses IS-IS, since it also provides the following advantages:

   o  it runs directly over the layer 2;

   o  it is easy to extend by defining new TLVs for carrying the TRILL

   o  it may be run with zero configuration.

   IS-IS exchanges information by exchanging LSPs (Link State PDUs).

Perlman, Gai, Dutt     Expires  September 2007                [Page 15]

Internet-Draft              RBridge Protocol                 March 2007

3.3.1. IS-IS RBridge Identity

   Each RBridge has a unique 6-byte System ID, which may be derived from
   any of the RBridge universal MAC addresses.

3.3.2. Separate Instances

   RBridge implements a separate IS-IS instance from the one used by any
   routing protocol, e.g. the ones used by IP routers. This instance is
   identified by a combination of Outer.Mac.DA, Outer.Ethertpe and
   Inner.Ethertype (see ).

   The RBridge IS-IS instance is also differentiated by defaulting to a
   distinct, constant "area address" (the value 0) that would never
   appear as a real IS-IS area address.

3.3.3. Multiple RBridge IS-IS Instances

   Each RBridge runs multiple IS-IS instances:

   o  One IS-IS core instance;

   o  IS-IS VLAN instances, one per each inner VLAN the RBridge is
      connected to.

   In theory this information could all be contained in one instance of
   RBridge IS-IS. However, since endnode information for a particular
   VLAN needs to be known only to RBridges that are connected to links
   configured to be in that VLAN, and since the core instance is global
   to all RBridges, it is appropriate to have multiple instances. The IS-IS core instance

   The information contained in the LSP of RBridge Rn core is:

   1. the TRILL address of RBridge Rn;

   2. the list of VIDs of VLANs directly connected to Rn;

   3. a flag RequestTree indicating whether RBridges MUST calculate a
      tree rooted at Rn (default RequestTree = TRUE);

Perlman, Gai, Dutt     Expires  September 2007                [Page 16]

Internet-Draft              RBridge Protocol                 March 2007

   4. the System IDs of RBridges which are neighbors of RBridge Rn, and
      the cost of the link to each of those neighbors.

   Using the previous information each RBridge can compute the optimal
   pair-wise forwarding for know-unicast traffic and the distribution
   trees for multi-destination traffic.

   The distribution trees (see Section 3.4. ) may also be pruned
   according to the list of VIDs connected to each RBridge (see Section
   3.5. ). In fact, if Rn is forwarding a multi-destination frame tagged
   with VLAN A, Rn need not forward it onto branches of the distribution
   tree that have no downstream VLAN A links. The IS-IS VLAN instance

   The endnode information for VLAN A, which is carried in the LSP
   injected by Rn in VLAN A, contains:

   1. L2INFO: layer 2 addresses of nodes on a VLAN A link attached to Rn
      which have transmitted frames, but have not transmitted ARP/ND
      requests/replies (i.e., these are not known to be IP nodes).

   2. L3and2INFO: layer 3, layer 2 addresses of IP nodes attached Rn on
      VLAN A, which Rn has learned through ARP/ND requests/replies. In
      the case of IPv6, for data compression, only the portion of the
      address following the campus-wide prefix is carried.

   3. Multicast Router attached: This is one bit of information that
      indicates whether there is an IP multicast router attached on VLAN
      A. This information is used because IGMP [RFC3376] Membership
      Reports MUST be transmitted to all links with IGMP routers, and
      SHOULD NOT be transmitted to links without IGMP routers. Also, all
      frames for IP-derived multicast addresses MUST be transmitted to
      all links with IGMP routers (within the VLAN), in addition to
      links from which an IP node has explicitly asked to join the group
      which the frame is for.

   4. Layer 2 addresses derived from IPv4 or IPv6 IGMP notification
      messages received from attached endnodes on VLAN A, indicating the
      location of listeners for these multicast addresses.

   If Rn has learned endnode E's location first from a data frame (and
   therefore has included E's layer 2 address in the L2INFO), and later
   E transmits an ARP/ND request/reply, Rn MUST include E in the
   L3andL2INFO, and SHOULD remove E from L2INFO.

Perlman, Gai, Dutt     Expires  September 2007                [Page 17]

Internet-Draft              RBridge Protocol                 March 2007

   The way that RBridges distinguish which IS-IS instance the VLAN link
   state information is for is based on the VLAN tag in the inner header
   i.e. the inner VLAN.

   Given that RBridges already support distribution trees pruned by VID
   (see Section ), the same mechanism is used by the per-VLAN
   instance of IS-IS to distribute endnode information solely to
   RBridges within a VLAN.

   Each per-VLAN instance of IS-IS appears to the RBridges as a single
   link with all the RBridges with endnodes in that VLAN as neighbor.

   When an RBridge originates an IS-S frame for the VLAN A instance, all
   RBridges forward it as an ordinary frame in VLAN A, along the
   specified distribution tree, even if they nave no endnodes connected
   to VLAN A.

   RBridges with endnodes in VLAN A also receive and process the frame
   in their VLAN-A IS-IS instance.

3.3.4. Designated RBridge

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

   o  learns and advertises the identities of attached endnodes;

   o  encapsulates and forwards frames that originate on that link to
      the rest of the campus;

   o  decapsulates and forwards frames onto that link received from
      other RBridges;

   o  initiates a distributed ARP/ND when an ARP/ND query is received
      for an unknown destination;

   o  answers ARP/ND queries when the target node is known.

   It is incorrect to have multiple RBridges being Designated RBridge on
   the same link at the same time. This could temporarily happen if a
   partitioned bridged LAN became connected with a bridge or repeater.
   The situation resolves once the better priority RBridge's IS-IS Hello
   is received by the other RBridges on the link.

Perlman, Gai, Dutt     Expires  September 2007                [Page 18]

Internet-Draft              RBridge Protocol                 March 2007

   BPDUs are messages that are transmitted and received even in
   preforwarding state (listening and learning states). If RBridges
   listen to BPDUs, and if the LANs for which R1 was Designated RBridge,
   and for which R2 was Designated RBridge get joined, then either R1 or
   R2 detect that the bridge Root has changed identity.

   A conservative solution would be to invoke something like a
   preforwarding state, in which the RBridge that detects the change
   stops forwarding anything to or from the link until it is sure the
   IS-IS link election would have completed. But the IS-IS election
   could get slowed down due to bridges in preforwarding state, and it
   would be undesirable to disrupt traffic to and from the link just
   because the root ID has changed.

   An alternative solution is to have RBridges participate in the
   spanning tree election, with higher priority for becoming root
   (actually, lowest numerical priority value) than any of the bridges,
   and with the same priority as for becoming Designated RBridge on the
   link. Then an RBridge is Designated RBridge if and only if it is the
   spanning tree Root. Note that RBridges MUST NOT merge spanning trees
   from different ports. If two ports of R1 are connected to the same
   bridged LAN, then the regular bridge spanning tree algorithm
   partitions the LAN into distinct LANs for each of R1's ports.
   However, if two of R1's ports are connected to the same shared medium
   (without any bridges between the ports), then the regular bridge
   spanning tree algorithm turns off one of R1's redundant ports.

   So for example, R1 sends BPDUs on each of its ports, with itself as
   Root (with highest, i.e., numerically lowest priority), 0 cost from
   Root, and the port ID. There are several possible cases:

   o  R1 is the highest priority RBridge on the bridged LAN, in which
      case it becomes spanning tree Root and Designated RBridge.

   o  R1 receives a BPDU from itself (because two of its ports are on
      the same shared medium without any bridges between). In this case,
      the numerically lowest port remains in ST forwarding state, and
      the other port(s) go into ST blocking state.

   R1 receives a BPDU from someone else with higher priority
   (numerically lower priority|ID), in which case R1 is not Root, and
   not Designated RBridge. It is possible this is due to a bridge
   being configured with the lowest priority, and then if R1 declines
   being Designated RBridge, the LAN becomes orphaned from the campus.
   We must treat this case as a misconfiguration of bridges, and the LAN
   becomes orphaned until the misconfiguration is corrected, but an
   RBridge could in theory eventually discover it is not receiving

Perlman, Gai, Dutt     Expires  September 2007                [Page 19]

Internet-Draft              RBridge Protocol                 March 2007

   any IS-IS Hellos, and become Designated RBridge even though it is not
   spanning tree Root.

3.4. Distribution Trees

   RBridges use distribution trees to forward multi-destination frames
   (see Section 2.3.2. ). Distribution Trees are bidirectional. A single
   distribution tree is 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.

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

   1. In some cases, a different tradeoff might be wanted in terms of
      expense of computation 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, in order to allow
      multipathing of multicast traffic injected by a particular Bridge.

   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
   distribution tree. Each RBridge Ri announces whether RBridges MUST
   compute a tree rooted at Ri via the RequestTree flag in its IS-IS
   core 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 ID.

Perlman, Gai, Dutt     Expires  September 2007                [Page 20]

Internet-Draft              RBridge Protocol                 March 2007

   If Ri is a tree root, then any RBridge Rn that needs to send multi-
   destination traffic MAY select the Ri-tree. Rn does so by specifying
   in the TRILL header:

      Trill.EgressRbridgeAddress = Ri;
      Trill.M = TRUE;

   All the other RBridges MUST comply with the decision of Rn.

   In IS-IS a shared link is modeled as a pseudonode. Pseudonodes MUST
   set RequestTree = FALSE.

3.4.1. Distribution Tree Calculation

   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

   Calculation of a tree rooted at Ri is done independently by each
   RBridge Rn by performing the SPF (Shortest Path First) calculation
   with Ri as the root without requiring any additional exchange of

   In the case a node Rn has two or more minimal equal cost path toward
   the root Ri 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 System ID.

   Each RBridge Rn keeps a set of adjacencies (port, neighbor pair) for
   each distribution tree. One of these adjacencies is toward the root
   Ri and the others are toward the leaves. Once the adjacencies are
   chosen, it is irrelevant which ones are towards the root Ri, and
   which are away from Ri. Let's suppose that Rn has calculated that
   adjacencies a, c, and f are in the Ri tree. A multi-destination frame
   for the distribution tree Ri is received only from one of the
   adjacencies a, c, or f (otherwise is discarded) and forwarded to the
   other two adjacencies.

Perlman, Gai, Dutt     Expires  September 2007                [Page 21]

Internet-Draft              RBridge Protocol                 March 2007

3.5. Pruning the Distribution Tree

   Each distribution tree is pruned per VLAN eliminating branches that
   have no potential receivers downstream. Multi-destination frames are
   forwarded only on branches that are not pruned.

   Further pruning is done in the case of IGMP Notification Messages
   [RFC3376], where these are to be delivered only to ports with IP
   Multicast Routers. In the case of a multicast derived from an IP
   multicast, these multicast data frames are delivered only to links
   that have registered listeners, plus links which have IP Multicast

   Let's assume that RBridge Rn knows that adjacencies (a, c, and f) are
   in the Ri-distribution tree. Rn marks pruning information for each of
   the adjacencies in the Ri-tree. For each adjacency and for each tree,
   Rn marks:

   o  the set of VLANs reachable downstream, and for each one of those,
      a flag indicating whether there are IP multicast routers
      downstream, and

   o  the set of layer 2 multicast addresses derived from IP
      multicast group for which there are receivers downstream.

3.6. Forwarding using a Distribution Tree

   Forwarding a multi-destination frame is done as follows:

   o  The RBridge Rn receives a multi-destination frame on VLAN A and
      the TRILL header indicates the selected tree is the Ri-tree;

   o  if the adjacency from which the frame was received is not one
      of the adjacencies in the Ri-tree, the frame is dropped;

   o  else if the frame is an IGMP Notification message then the frame
      is forwarded onto adjacencies in the Ri-tree that indicate there
      are downstream VLAN-A IP multicast routers;

   o  else if the frame is for a layer 2 multicast address derived from
      IP multicast groups then the frame is forward onto adjacencies in
      the Ri-tree that indicate there are downstream VLAN-A IP multicast
      routers, as well as adjacencies that indicate there are downstream
      VLAN-A receives for that group address;

Perlman, Gai, Dutt     Expires  September 2007                [Page 22]

Internet-Draft              RBridge Protocol                 March 2007

   o  else if the inner frame is for an unknown destination or layer 2
      multicast not derived from IP multicast, or distributed ARP/ND, or
      broadcast, the frame is forwarded onto an adjacency if and only if
      that adjacency is in the Ri-tree, and marked as reaching VLAN-A

   For each link for which Rn is Designated RBridge, Rn additionally
   checks to see if it should decapsulate the frame and send it to the
   link (e.g., if it is a distributed ARP/ND in the specified VLAN for
   that link), or process the frame (e.g., if it is a per-VLAN IS-IS
   instance link state announcement for a VLAN that Rn is attached to).

3.7. Wiring Closet Topology

   In cases where there are two (or more) groups of endnodes, each
   attached to a bridge (say B1 and B2 respectively), and each bridge is
   attached to an RBridge (say R1 and R2 respectively), with a link
   connecting B1 and B2 (see Figure 7), it may be desirable to have the
   B1-B2 link only as a backup in case one of R1 and R2, or the links
   B1-R1 or B2-R2 fail.

                               +----+     +----+
                               | R1 |-----| R2 |
                               +----+     +----+
                                  |          |
                    |             |          |      |
                    |          +----+     +----+    |
                    | Closet   | B1 |-----| B2 |    |
                    |          +----+     +----+    |
                    |                               |

                      Figure 7 Wiring Closet Topology

   For example, B1 and B2 may be in a wiring closet and it may be easy
   to provide a very short very high bandwidth link between them while
   R1 and R2 are at a distant data center such that the R1-B1 and R2-B2
   links are slower and more expensive.

   Default behavior would be that one of R1 or R2 (say R1) would become
   Designated RBridge, and forward traffic to/from the link, so endnodes
   attached to B2 would be connected to the campus via the path B2-B1-

Perlman, Gai, Dutt     Expires  September 2007                [Page 23]

Internet-Draft              RBridge Protocol                 March 2007

   R1, rather than the desired B2-R2. The desired behavior would
   probably be to make maximum use of both the R1-B1 and R2-B2 links.

   The solution is to configure R1 and R2 to be part of a "wiring closet
   group", with a configured System ID Rx (which may be R1 or R2's
   System ID). Both R1 and R2 participate in the bridge spanning tree on
   the configured ports as root Rx, which causes the spanning tree to
   break the B1-B2 link as desired, and both R1 and R2 act as Designated
   RBridge on each of their respective partitions.

   In the BPDU, the Root is "Rx", cost to Root is 0, Designated Bridge
   ID is "R1" when R1 transmits and "R2 when R2 transmits, and port ID
   is a value chosen independently by each of R1 and R2 to distinguish
   each of its own ports. If R1 and R2 were actually on the same shared
   medium with no bridges between them, the result is 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 turns off the

   The only misconfiguration that may occur is if the link R1-R2 is on
   the cut set of the campus, and R2 and/or R1 have been configured to
   believe they are part of a wiring closet group.  In that case, the
   link becomes partitioned.

3.8. Learning Endnode Location

   RBridges learn endnode location from native frames (similar to 802.1D
   bridges, see in section 7.0 of [802.1Q]). They learn (layer 3, layer
   2) pairs, for the purpose of supporting ARP/ND optimization, from
   listening to ARP/ND request/replies.

   This endnode information is learned by the Designated RBridge, and
   distributed to other RBridges through the link state protocol.
   RBridges need not remember endnode information for a VLAN unless
   there are endnodes for that VLAN on one of their directly connected

Perlman, Gai, Dutt     Expires  September 2007                [Page 24]

Internet-Draft              RBridge Protocol                 March 2007

3.9. Forwarding Behavior

3.9.1. Receipt of a Native Frame Unicast case

   Let's assume that Rn receives a unicast frame with Mac.Da = D, Mac.Sa
   = S and Ethertype != TRILL. Rn knows this is a native frame from the
   Ethertype value.

   Rn determines the VID according to the same rules as bridges do. Once
   the VLAN is established, the layer 2 address of D is looked up in the
   destination table for that VLAN to find the egress RBridge Rm, or
   discover that D is unknown.

   If D is known, with egress Rm, then Rn encapsulates the frame, in the
   following way:

     Outer.MacDa = next hop RBridge (in the path to Rm);
     Outer.MacSa = Rn;
     Outer.Ethertype = TRILL;
     Trill.v = 0;
     Trill.Reserved = 0;
     Trill.M = FALSE; // this is not a multi-destination frame
     Trill.HopLimit = default or configured hop limit;
     Trill.EgressRBridgesAddress = Rm;
     Trill.IngressRBridgesAddress = Rn;
     Followed by the received frame;

   If D is unknown, Rn encapsulates the frame, in the following way:

     Outer.MacDa = ALL-RBRIDGES;
     Outer.MacSa = Rn;
     Outer.Ethertype = TRILL;
     Trill.v = 0;
     Trill.Reserved = 0;
     Trill.M = TRUE; // this is a multi-destination frame
     Trill.HopLimit = default or configured hop limit;
     Trill.EgressRBridgesAddress = Ri // Distribution Tree, see below
     Trill.IngressRBridgesAddress = Rn;
     Followed by the received frame;

   In the latter case, the egress RBridge address indicates the chosen
   distribution tree Ri. The default is for Rn to put its own address
   there. However, if Rn is configured to decline to be a tree root,

Perlman, Gai, Dutt     Expires  September 2007                [Page 25]

Internet-Draft              RBridge Protocol                 March 2007

   then Rn MUST select some other RBridge Ri which has elected to be a
   tree root or the RBridge with the lowest ID if none have elected to
   be a tree root. Other multi-destination frames

   If the frame is an IGMP announcement, then Rn learns the group
   membership, and announces a receiver for that layer 2 group address
   in its per-VLAN link state instance.

   If the frame is a PIM or MRD [RFC4286] message, Rn learns that there
   is an IP multicast router (for the specified VLAN) on its link, and
   adds that information into its per-VLAN IS-IS link state information.
   If the frame is an ARP/ND reply, then Rn learns the (layer 3, layer
   2) correspondence, and adds that information into its per-VLAN link
   state information. IS-IS frames

   If the frame is from the IS-IS core instance of Rn, then there is no
   need for the TRILL Ethertype and inner headers.  The outer header

     Outer.MacDa = ALL-RBRIDGES;
     Outer.MacSa = Rn;
     Outer.Ethertype = IS-IS;

   In this case the IS-IS frame is never forwarded by the RBridge as a
   layer 2 frame, but instead is delivered to the RBridge IS-IS process
   for processing.

   The situation is different in the per-VLAN instances of IS-IS, since
   there is the need to carry the VID. The encapsulation is as follow:

     Outer.MacDa = ALL-RBRIDGES;
     Outer.MacSa = Rn;
     Outer.Ethertype = TRILL;
     Trill.v = 0;
     Trill.Reserved = 0;
     Trill.M = TRUE; // this is a multi-destination frame
     Trill.HopLimit = MAX-HOP-LIMIT;
     Trill.EgressRBridgesAddress = Ri; // Distribution Tree, see above
     Trill.IngressRBridgesAddress = Rn;

Perlman, Gai, Dutt     Expires  September 2007                [Page 26]

Internet-Draft              RBridge Protocol                 March 2007

   Followed by a VLAN-tagged IS-IS packet (same as for core instance,
   but with VLAN tag). In this case the frames are forwarded like a non-
   IP-multicast flooded frame, as well as processed, if the RBridge
   belongs to the specified VLAN.

3.9.2. Receipt of an In-transit Frame

   Let's suppose RBridge Rn receives a TRILL encapsulated frame (as
   indicated by Outer.Ethertype = TRILL). Flooded Frame

   if (Outer.MacDa == ALL-RBRIDGES)
      if (Outer.MacSa != a tree adjacency for the tree indicated)
            Discard the frame
            Rn forwards along the tree indicated by
            pruned as specified in section 3.5.

            It also removes the TRILL encapsulation
            and forwards the frame to the appropriate ports
            where it is a Designated RBridge.

Perlman, Gai, Dutt     Expires  September 2007                [Page 27]

Internet-Draft              RBridge Protocol                 March 2007 Unicast Frame

   if (Outer.MacDa != Rn)
      R1 Drops the frame   // the destination in the outer header
                           // is not R1
      if (Trill.EgressRBridgesAddress == Rn)
         Rn process the frame, i.e. it removes the TRILL encapsulation,
         extracts the inner frame and forwards it onto the link
         containing the destination, or processes the frame if the
         Inner.MacDa == Rn.

         // The frame needs to be forwarded to another RBridge
         Outer.MacDa = lookup (Trill.EgressRBridgesAddress);
         Outer.MACSa = Rn;
         Trill.HopLimit -= 1;
   } IS-IS Frame

   If the protocol type in the outer header indicates this is an IS-IS
   frame, then Rn processes the frame accordingly.

3.10. IGMP Learning

   RBridges learn, based on seeing IGMP [RFC3376] frames, which
   multicast addresses should be forwarded onto which links.

   IGMP messages have to be forwarded throughout the campus, since IP
   routers in the broadcast domain also need to see these messages.

   IGMP messages are forwarded by RBridges throughout the campus like
   any layer 2 multicast. They are recognized by having an IP message
   type=2 in the IP header. In addition, they are processed by RBridges

Perlman, Gai, Dutt     Expires  September 2007                [Page 28]

Internet-Draft              RBridge Protocol                 March 2007

   in order to extract, from announcements, what egress RBridges have
   receivers for which groups.

3.11. RBridge Addresses

   To make the TRILL header smaller, RBridges dynamically acquire 2-byte
   addresses that are unique within the campus. The address allocation
   protocol is piggybacked on the core IS-IS RBridge instance as

   o  The address requested by the RBridge is carried in a new TLV. Each
      RBridge chooses its own address.

   o  Each RBridge is also responsible for ensuring that its address is
      unique.  If R1 chooses address x, and R1 discovers, through
      receipt of R2's LSP, that R2 has also chosen x, then the RBridge
      with the lower System ID keeps the address, and the other RBridge
      MUST choose a new address.

   o  If two RBridge domains merge then transient address collisions
      are possible. As soon as each RBridge receives the link
      state frames from the other RBridges, the RBridges that need to
      change addresses choose new addresses that do not, to the best of
      their knowledge, collide with any existing addresses.

   To minimize the probability of address collisions, each RBridge
   chooses its address randomly hashing some of its parameters. There is
   no reason for all RBridges to use the same algorithm for choosing

   Once an RBridge has successfully acquired an address it SHOULD store
   it in non-volatile memory and reuse it in the case of a reboot.

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

3.12. Handling ARP/ND Queries

   IEEE 802.1 bridges forward an ARP/ND query as an ordinary
   broadcast/multicast frame to all links belonging to the same VLAN.

   Rbridges SHOULD implement an "optimized ARP/ND response"

Perlman, Gai, Dutt     Expires  September 2007                [Page 29]

Internet-Draft              RBridge Protocol                 March 2007

   When the target's location is assumed to be known by the first
   RBridge, it needs not flood the query. Alternative behaviors of the
   first Designated RBridge that receives the ARP/ND query would be to:

   1. send a response directly to the querier, with the layer 2 address
      of the target, as believed by the RBridge

   2. encapsulate the ARP/ND query to the target's Designated RBridge,
      and have the Designated RBridge at the target forward the query to
      the target. This behavior has the advantage that a response to the
      query is authoritative. If the query does not reach the target,
      then the querier does not get a response

   3. block ARP/ND queries that occur for some time after a query to the
      same target has been launched, and then respond to the querier
      when the response to the recently-launched query to that target is

   The reason not to do the most optimized behavior all the time is for
   timeliness of detecting a stale cache. Also, in the case of scure
   neighbor discovery (SEND) [RFC3971], cryptography might prevent
   behavior 1, since the RBridge would not be able to sign the response
   with the target's private key.

   It is not essential that all RBridges use the same strategy for which
   option to select for a particular query. However, once the first
   Designated RBridge decides on a strategy for a particular query, the
   other RBridges MUST carry that through. If the first RBridge responds
   directly to the querier, or blocks the query, then no other RBridges
   are involved.

   If the first Designated RBridge R1 decides to unicast the query to
   the target's Designated RBridge R2, then R2 decapsulates the query,
   and initiate an ARP/ND query on the target's link. When/if the
   target responds, R2 encapsulates and unicast the response to R1,
   which decapsulates the response and send it to the querier.

   If the first Designated RBridge R1 decides to flood the query (which
   it MUST do if the target is unknown, but MAY do if it wants to assure
   freshness of the information), the query is encapsulated to be
   flooded through the indicated VLAN.

   The distributed ARP/ND query is carried by RBridges through the
   RBridge distribution tree. Each Designated RBridge, in addition to
   forwarding the query through the distribution tree, initiates an
   ARP/ND query on its link(s). If a reply is received from the target
   by Designated RBridge R2, R2 initiates a link state update to inform

Perlman, Gai, Dutt     Expires  September 2007                [Page 30]

Internet-Draft              RBridge Protocol                 March 2007

   all the other RBridges of D's location, layer 3 address, and layer 2
   address, in addition to forwarding the reply to the querier.

   It is the querier's Designated RBridge R1 that chooses which strategy
   to employ when seeing an ARP/ND query.

   Some mix of these strategies (responding directly, unicasting the
   query to the target's Designated RBridge, or flooding the query)
   might be the best solution. For instance, even if the target's
   location and (layer 3, layer 2) correspondence is in the link state
   information R1 received from R2, if the target's location has not
   been recently verified by R1 through a broadcast ARP/ND or unicast
   query to the target, then R1 MAY broadcast or unicast the query or
   respond directly. So for instance, RBridges could keep track of the
   last time a broadcast ARP/ND occurred for each endnode E (by any
   source, and injected by any RBridge). Let's say the parameter is 20
   seconds. If a source S on RBridge R1's link does an ARP/ND for D, if
   R1 has not seen an ARP/ND for D within the last 20 seconds, R1
   unicasts the query to force a reply from the target; otherwise it
   proxies the reply.

   When R2 forwards a unicast ARP/ND query, if the target does not
   respond, then R2 MAY replay the query, and if the target still does
   not respond, R2 SHOULD remove the target from its link state

3.13. Discovering IP Multicast Routers

   Until Multicast Router Discovery [RFC4286] is universally deployed,
   RBridges discover IP multicast routers through their transmission of
   PIM messages. So an RBridge concludes there is an IP multicast router
   on its port if it either receives an MRD message or a PIM message on
   that port. A PIM message is recognized because the protocol type in
   the IP header is decimal 103.

3.14. Assuring Freshness of Endnode Information

   A Designate RBridge MUST be capable of ensuring freshness of its
   endnode information using periodic ARP/ND queries. Because this may
   be a problem if the endnodes are in power-saver mode, there MUST be a
   configuration option to disable or control the frequency of these
   queries. These queries SHOULD be enabled by default.

Perlman, Gai, Dutt     Expires  September 2007                [Page 31]

Internet-Draft              RBridge Protocol                 March 2007

4. RBridge Addresses, Parameters, and Constants

   Each RBridge needs a unique System ID.  The simplest such address is
   a unique 6-byte ID, since such an ID is easily obtainable as any of
   the EUI-48's owned by that RBridge.  IS-IS already requires each
   router to have such an address.

   The parameter DEFAULT-HOP-LIMIT (suggested value 20). It is the value
   used to initialize Trill.HopLimit when an RBridge encapsulates a
   frame if some other value has not been configured.

   A new Ethertype must be assigned to indicate a TRILL encapsulated

   A layer 2 multicast address for ALL-RBRIDGES must be assigned for
   use as the destination address in flooded frames.

   To support VLANs, RBridges (like bridges today), must be configured,
   for each port, with the PVID (Port VLAN ID) in which that port

   A parameter to determine whether an RBridge should periodically do
   queries to ensure that the endnode information is fresh, and if so,
   with what frequency.

   The parameter RequestTree that indicates whether an RBridge wants to
   be the root of a distribution tree.

   Configuration for wiring closet topology consists of System ID of the
   RBridge with lowest System ID. If R1 and R2 are part of a wiring
   closet topology, only R2 needs to be configured to know about this,
   and that R1 is the ID it should use in the spanning tree protocol on
   the specified port.

5. Security Considerations

   The goal is for RBridges to not add additional security issues over
   what would be present with traditional bridges.  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.

   As with routing schemes, authentication of RBridge messages would be
   a simple addition to the design (and it would be accomplished the
   same way as it would be in IS-IS).  However, any sort of

Perlman, Gai, Dutt     Expires  September 2007                [Page 32]

Internet-Draft              RBridge Protocol                 March 2007

   authentication requires additional configuration, which might
   interfere with the perception that RBridges, like bridges, are zero

6. IANA Considerations

   A new Ethertype must be assigned to indicate an TRILL encapsulated

   A layer 2 multicast address for "All RBridges" must be assigned for
   use as the destination address in flooded frames.

7. References

7.1. Normative References

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

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

   [RFC826] Plummer, D., "An Ethernet Address Resolution Protocol", RFC
   826, November 1982.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
   Discovery for IP Version 6 (IPv6)", RFC 2461 (Standards Track),
   December 1998.

   [RFC3376] Cain, B., "Internet Group Management Protocol, Version 3",
   RFC 3376, October 2002.

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

Perlman, Gai, Dutt     Expires  September 2007                [Page 33]

Internet-Draft              RBridge Protocol                 March 2007

   [SNOOP] Christensen, M., Kimball, K, Solensky, F., "Considerations
   for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-12.txt

7.2. Informative References

   [Arch] Gray, E., "The Architecture of an RBridge Solution to TRILL",
   draft-ietf-trill-rbridge-arch-01.txt, October 2006, work in progress.

   [PAS} Touch, J., & R. Perlman "Transparent Interconnection of Lots of
   Links (TRILL) / Problem and Applicability Statement", draft-ietf-
   trill-prob-01.txt, Octover 2006, work in progress.

   [RBridges] Perlman, R., "RBridges: Transparent Routing", Proc.
   Infocom 2005, March 2004.

   [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
   Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RP1999] Perlman, R., "Interconnection: Bridges, Routers, Switches,
   and Internetworking Protocols", Addison Wesley Chapter 3, 1999.

Perlman, Gai, Dutt     Expires  September 2007                [Page 34]

Internet-Draft              RBridge Protocol                 March 2007

   Author's Address

      Radia Perlman
      Sun Microsystems

      Email: Radia.Perlman@sun.com

      Silvano Gai
      Nuova Systems

      Email: sgai@nuovasystems.com

      Dinesh G. Dutt
      Cisco Systems, Inc.
      170 Tasman Dr.
      San Jose, CA 95134-1706

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

Intellectual Property Statement

   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

   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

Perlman, Gai, Dutt     Expires  September 2007                [Page 35]

Internet-Draft              RBridge Protocol                 March 2007

Disclaimer of Liability

   This document and the information contained herein are provided on

Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Perlman, Gai, Dutt     Expires  September 2007                [Page 36]

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