tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6325

 
 
 

Routing Bridges (RBridges): Base Protocol Specification

Part 4 of 4, p. 71 to 99
Prev RFC Part

 


prevText      Top      Up      ToC       Page 71 
4.9.  RBridge Ports

   Section 4.9.1 below describes the several RBridge port configuration
   bits, Section 4.9.2 gives a logical port structure in terms of frame
   processing, and Sections 4.9.3 and 4.9.4 describe the handling of
   high-level control frames.

4.9.1.  RBridge Port Configuration

   There are four per-port configuration bits as follows:

   o  Disable port bit.  When this bit is set, all frames received or to
      be transmitted are discarded, with the possible exception of some
      Layer 2 control frames (see Section 1.4) that may be generated and
      transmitted or received and processed within the port.  By
      default, ports are enabled.

Top      Up      ToC       Page 72 
   o  End-station service disable (trunk port) bit.  When this bit is
      set, all native frames received on the port and all native frames
      that would have been sent on the port are discarded.  (See
      Appendix B.)  (Note that, for this document, "native frames" does
      not include Layer 2 control frames.)  By default, ports are not
      restricted to being trunk ports.

      If a port with end-station service disabled reports, in a TRILL-
      Hello frame it sends out that port, which VLANs it provides end-
      station support for, it reports that there are none.

   o  TRILL traffic disable (access port) bit.  If this bit is set, the
      goal is to avoid sending any TRILL frames, except TRILL-Hello
      frames, on the port since it is intended only for native end-
      station traffic.  By default, ports are not restricted to being
      access ports.  This bit is reported in TRILL-Hello frames.  If RB1
      is the DRB and has this bit set in its TRILL-Hello, the DRB still
      appoints VLAN forwarders.  However, usually no pseudonode is
      reported, and none of the inter-RBridge links associated with that
      link are reported in LSPs.

      If the DRB RB1 does not have this bit set, but neighbor RB2 on the
      link does have the bit set, then RB1 does not appoint RB2 as
      appointed forwarder for any VLAN, and none of the RBridges
      (including the pseudonode) report RB2 as a neighbor in LSPs.

      In some cases even though the DRB has the "access port" flag set,
      the DRB MAY choose to create a pseudonode for the access port.  In
      this case, the other RBridges report connectivity to the
      pseudonode in their LSP, but the DRB sets the "overload" flag in
      the pseudonode LSP.

   o  Use P2P Hellos bit.  If this bit is set, Hellos sent on this port
      are IS-IS P2P Hellos.  By default TRILL-Hellos are used.  See
      Section 4.2.4.1 for more information on P2P links.

   The dominance relationship of these four configuration bits is as
   follows, where configuration bits to the left dominate those to the
   right.  That is to say, when any pair of bits is asserted,
   inconsistencies in behavior they mandate are resolved in favor of
   behavior mandated by the bit to the left of the other bit in this
   list.

         Disable > P2P > Access > Trunk

Top      Up      ToC       Page 73 
4.9.2.  RBridge Port Structure

   An RBridge port can be modeled as having a lower-level structure
   similar to that of an [802.1Q-2005] bridge port as shown in Figure
   11.  In this figure, the double lines represent the general flow of
   the frames and information while single lines represent information
   flow only.  The dashed lines in connection with VRP (GVRP/MVRP) are
   to show that VRP support is optional.  An actual RBridge port
   implementation may be structured in any way that provides the correct
   behavior.

Top      Up      ToC       Page 74 
                     +----------------------------------------------
                     |                RBridge
                     |
                     | Interport Forwarding, IS-IS.  Management, ...
                     |
                     +----++----------------------+-------------++--
                          ||                      |             ||
                    TRILL || Data                 |             ||
                          ||                   +--+---------+   ||
            +-------------++-----+             |   TRILL    |   ||
            |    Encapsulation   |      +------+ IS-IS Hello|   ||
            |    Decapsulation   |      |      | Processing |   ||
            |     Processing     |      |      +-----++-----+   ||
            +--------------------+      |            ||         ||
            |  RBridge Appointed +------+            ||         ||
        +---+   Forwarder and    |                   ||         ||
        |   |  Inhibition Logic  +==============\\   ||   //====++
        |   +---------+--------+-+   Native       \\ ++ //
        |             |        |     Frames         \++/
        |             |        |                     ||
   +----+-----+  +- - + - - +  |                     ||
   |  RBridge |  |  RBridge |  |                     || All TRILL and
   |   BPDU   |  |    VRP   |  |                     || Native Frames
   |Processing|  |Processing|  |                     ||
   +-----++---+  + - - -+- -+  |            +--------++--+ <- EISS
         ||             |      |            |   802.1Q   |
         ||            |       |            | Port VLAN  |
         ||             |      |            |and Priority|
         ||            |       |            | Processing |
     +---++------------++------+------------+------------+ <-- ISS
     |        802.1/802.3 Low-Level Control Frame        |
     |        Processing, Port/Link Control Logic        |
     +------------++-------------------------------------+
                  ||
                  ||        +------------+
                  ||        | 802.3 PHY  |
                  ++========+ (Physical  +======== 802.3
                            | Interface) |         Link
                            +------------+

                  Figure 11: Detailed RBridge Port Model

   Low-level control frames are handled in the lower-level port/link
   control logic in the same way as in an [802.1Q-2005] bridge port.
   This can optionally include a variety of 802.1 or link specific
   protocols such as PAUSE (Annex 31B of [802.3]), link layer discovery
   [802.1AB], link aggregation [802.1AX], MAC security [802.1AE], or
   port-based access control [802.1X].  While handled at a low level,

Top      Up      ToC       Page 75 
   these frames may affect higher-level processing.  For example, a
   Layer 2 registration protocol may affect the confidence in learned
   addresses.  The upper interface to this lower-level port control
   logic corresponds to the Internal Sublayer Service (ISS) in
   [802.1Q-2005].

   High-level control frames (BPDUs and, if supported, VRP frames) are
   not VLAN tagged.  Although they extend through the ISS interface,
   they are not subject to port VLAN processing.  Behavior on receipt of
   a VLAN tagged BPDU or VLAN tagged VRP frame is unspecified.  If a VRP
   is not implemented, then all VRP frames are discarded.  Handling of
   BPDUs is described in Section 4.9.3.  Handling of VRP frames is
   described in Section 4.9.4.

   Frames other than Layer 2 control frames, that is, all TRILL and
   native frames, are subject to port VLAN and priority processing that
   is the same as for an [802.1Q-2005] bridge.  The upper interface to
   the port VLAN and priority processing corresponds to the Extended
   Internal Sublayer Service (EISS) in [802.1Q-2005].

   In this model, RBridge port processing below the EISS layer is
   identical to an [802.1Q-2005] bridge except for (1) the handling of
   high-level control frames and (2) that the discard of frames that
   have exceeded the Maximum Transit Delay is not mandatory but MAY be
   done.

   As described in more detail elsewhere in this document, incoming
   native frames are only accepted if the RBridge is an uninhibited
   appointed forwarder for the frame's VLAN, after which they are
   normally encapsulated and forwarded; outgoing native frames are
   usually obtained by decapsulation and are only output if the RBridge
   is an uninhibited appointed forwarder for the frame's VLAN.

   TRILL-Hellos, MTU-probes, and MTU-acks are handled per port and, like
   all TRILL IS-IS frames, are never forwarded.  They can affect the
   appointed forwarder and inhibition logic as well as the RBridge's
   LSP.

   Except TRILL-Hellos, MTU-probes, and MTU-acks, all TRILL control as
   well as TRILL data and ESADI frames are passed up to higher-level
   RBridge processing on receipt and passed down for transmission on
   creation or forwarding.  Note that these frames are never blocked due
   to the appointed forwarder and inhibition logic, which affects only
   native frames, but there are additional filters on some of them such
   as the Reverse Path Forwarding Check.

Top      Up      ToC       Page 76 
4.9.3.  BPDU Handling

   If RBridge campus topology were static, RBridges would simply be end
   stations from a bridging perspective, terminating but not otherwise
   interacting with spanning tree.  However, there are reasons for
   RBridges to listen to and sometimes to transmit BPDUs as described
   below.  Even when RBridges listen to and transmit BPDUs, this is a
   local RBridge port activity.  The ports of a particular RBridge never
   interact so as to make the RBridge as a whole a spanning tree node.

4.9.3.1.  Receipt of BPDUs

   Rbridges MUST listen to spanning tree configuration BPDUs received on
   a port and keep track of the root bridge, if any, on that link.  If
   MSTP is running on the link, this is the CIST root.  This information
   is reported per VLAN by the RBridge in its LSP and may be used as
   described in Section 4.2.4.3.  In addition, the receipt of spanning
   tree configuration BPDUs is used as an indication that a link is a
   bridged LAN, which can affect the RBridge transmission of BPDUs.

   An RBridge MUST NOT encapsulate or forward any BPDU frame it
   receives.

   RBridges discard any topology change BPDUs they receive, but note
   Section 4.9.3.3.

4.9.3.2.  Root Bridge Changes

   A change in the root bridge seen in the spanning tree BPDUs received
   at an RBridge port may indicate a change in bridged LAN topology,
   including the possibility of the merger of two bridged LANs or the
   like, without any physical indication at the port.  During topology
   transients, bridges may go into pre-forwarding states that block
   TRILL-Hello frames.  For these reasons, when an RBridge sees a root
   bridge change on a port for which it is appointed forwarder for one
   or more VLANs, it is inhibited for a period of time between zero and
   30 seconds.  (An inhibited appointed forwarder discards all native
   frames received from or that it would otherwise have sent to the
   link.)  This time period is configurable per port and defaults to 30
   seconds.

   For example, consider two bridged LANs carrying multiple VLANs, each
   with various RBridge appointed forwarders.  Should they become
   merged, due to a cable being plugged in or the like, those RBridges
   attached to the original bridged LAN with the lower priority root
   will see a root bridge change while those attached to the other
   original bridged LAN will not.  Thus, all appointed forwarders in the

Top      Up      ToC       Page 77 
   lower priority set will be inhibited for a time period while things
   are sorted out by BPDUs within the merged bridged LAN and TRILL-Hello
   frames between the RBridges involved.

4.9.3.3.  Transmission of BPDUs

   When an RBridge ceases to be appointed forwarder for one or more
   VLANs out a particular port, it SHOULD, as long as it continues to
   receive spanning tree BPDUs on that port, send topology change BPDUs
   until it sees the topology change acknowledged in a spanning tree
   configuration BPDU.

   RBridges MAY support a capability for sending spanning tree BPDUs for
   the purpose of attempting to force a bridged LAN to partition as
   discussed in Appendix A.3.3.

4.9.4.  Dynamic VLAN Registration

   Dynamic VLAN registration provides a means for bridges (and less
   commonly end stations) to request that VLANs be enabled or disabled
   on ports leading to the requestor.  This is done by VLAN registration
   protocol (VRP) frames: GVRP or MVRP.  RBridges MAY implement GVRP
   and/or MVRP as described below.

   VRP frames are never encapsulated as TRILL frames between RBridges or
   forwarded in native form by an RBridge.  If an RBridge does not
   implement a VRP, it discards any VRP frames received and sends none.

   RBridge ports may have dynamically enabled VLANs.  If an RBridge
   supports a VRP, the actual enablement of dynamic VLANs is determined
   by GVRP/MVRP frames received at the port as it would be for an
   [802.1Q-2005] / [802.1ak] bridge.

   An RBridge that supports a VRP sends GVRP/MVRP frames as an
   [802.1Q-2005] / [802.1ak] bridge would send on each port that is not
   configured as an RBridge trunk port or P2P port.  For this purpose,
   it sends VRP frames to request traffic in the VLANs for which it is
   appointed forwarder and in the Designated VLAN, unless the Designated
   VLAN is disabled on the port, and to not request traffic in any other
   VLAN.

5.  RBridge Parameters

   This section lists parameters for RBridges.  It is expected that the
   TRILL MIB will include many of the items listed in this section plus
   additional Rbridge status and data including traffic and error
   counts.

Top      Up      ToC       Page 78 
   The default value and range are given for parameters added by TRILL.
   Where a parameter is defined as a 16-bit unsigned integer and an
   explicit maximum is not given, that maximum is 2**16-1.  For
   parameters imported from [802.1Q-2005], [802.1D], or IS-IS [ISO10589]
   [RFC1195], see those standards for default and range if not given
   here.

5.1.  Per RBridge

   The following parameters occur per RBridge:

   o  Number of nicknames, which defaults to 1 and may be configured in
      the range of 1 to 256.

   o  The desired number of distribution trees to be calculated by every
      RBridge in the campus and a desired number of distribution trees
      for the advertising RBridge to use, both of which are unsigned
      16-bit integers that default to 1 (see Section 4.5).

   o  The maximum number of distribution trees the RBridge can compute.
      This is a 16-bit unsigned integer that is implementation and
      environment dependent and not subject to management configuration.

   o  Two lists of nicknames, one designating the distribution trees to
      be computed and one designating distribution trees to be used as
      discussed in Section 4.5.  By default, these lists are empty.

   o  The parameters Ageing Timer and Forward Delay with the default and
      range specified in [802.1Q-2005].

   o  Two unsigned octets that are, respectively, the confidence in
      { MAC, VLAN, local port } triples learned from locally received
      native frames and the confidence in { MAC, VLAN, remote RBridge }
      triples learned from decapsulating frames.  These each default to
      0x20 and may each be configured to values from 0x00 to 0xFE.

   o  The desired minimum acceptable inter-RBridge link MTU for the
      campus, that is, originatingLSPBufferSize.  This is a 16-bit
      unsigned integer number of octets that defaults to 1470 bytes,
      which is the minimum valid value.  Any lower value being
      advertised by an RBridge is ignored.

   o  The number of failed MTU-probes before the RBridge concludes that
      a particular MTU is not supported, which defaults to 3 and may be
      configured between 1 and 255.

Top      Up      ToC       Page 79 
   Static end-station address information and confidence in such end
   station information statically configured can also be configured with
   a default confidence of 0xFF and range of 0x00 to 0xFF.  By default,
   there is no such static address information.  The quantity of such
   information that can be configured is implementation dependent.

5.2.  Per Nickname Per RBridge

   The following is configuration information per nickname at each
   RBridge:

   o  Priority to hold the nickname, which defaults to 0x40 if no
      specific value has been configured or 0xC0 if it is configured
      (see Section 3.7.3).

   o  Nickname priority to be selected as a distribution tree root, a
      16-bit unsigned integer that defaults to 0x8000.

   o  Nickname value, an unsigned 16-bit quantity that defaults to the
      configured value if configured, else to the last value held if the
      RBridge coming up after a reboot and that value is remembered,
      else to a random value; however, in all cases the reserved values
      0x0000 and 0xFFC0 through 0xFFFF are excluded (see Section 3.7.3).

5.3.  Per Port Per RBridge

   An RBridge has the following per-port configuration parameters:

   o  The same parameters as an [802.1Q-2005] port in terms of C-VLAN
      IDs.  In addition, there is an Announcing VLANs set that defaults
      to the enabled VLANs on the port (see Section 4.4.3) and ranges
      from the null set to the set of all legal VLAN IDs.

   o  The same parameters as an [802.1Q-2005] port in terms of frame
      priority code point mapping (see [802.1Q-2005]).

   o  The inhibition time for the port when it observed a change in the
      root bridge of an attached bridged LAN.  This is in units of
      seconds, defaults to 30, and can be configured to any value from 0
      to 30.

   o  The Desired Designated VLAN that the RBridge will advertise in its
      TRILL Hellos if it is the DRB for the link via that port.  This
      defaults to the lowest VLAN ID enabled on the port and may be
      configured to any valid VLAN ID that is enabled on the port (0x001
      through 0xFFE).

Top      Up      ToC       Page 80 
   o  Four per-port configuration bits: disable port (default 0 ==
      enabled), disable end-station service (trunk, default 0 ==
      enabled), access port (default 0 == not restricted to being an
      access port), and use P2P Hellos (default 0 == use TRILL Hellos).
      (See Section 4.9.1.)

   o  One bit per port such that, if the bit is set, it disables
      learning { MAC address, VLAN, port } triples from locally received
      native frames on the port.  Default value is 0 == learning
      enabled.

   o  The priority of the RBridge to be DRB and its Holding Time via
      that port with defaults and range as specified in IS-IS [ISO10589]
      [RFC1195].

   o  A bit that, when set, enables the receipt of TRILL-encapsulated
      frames from an Outer.MacSA with which the RBridges does not have
      an IS-IS adjacency.  Default value is 0 == disabled.

   o  Configuration for the optional send-BPDUs solution to the wiring
      closet topology problem as described in Appendix A.3.3.  Default
      Bridge Address is the System ID of the RBridge with the lowest
      System ID.  If RB1 and RB2 are part of a wiring closet topology,
      both need to be configured to know about this, and know the ID
      that should be used in the spanning tree protocol on the specified
      port.

5.4.  Per VLAN Per RBridge

   An RBridge has the following per-VLAN configuration parameters:

   o  Per-VLAN ESADI protocol participation flag, 7-bit priority, and
      Holding Time.  Default participation flag is 0 == not
      participating.  Default and range of priority and Holding Time as
      specified in IS-IS [ISO10589] [RFC1195].

   o  One bit per VLAN that, if set, disables learning { MAC address,
      VLAN, remote RBridge } triples from frames decapsulated in the
      VLAN.  Defaults to 0 == learning enabled.

6.  Security Considerations

   Layer 2 bridging is not inherently secure.  It is, for example,
   subject to spoofing of source addresses and bridging control
   messages.  A goal for TRILL is that RBridges do not add new issues
   beyond those existing in current bridging technology.

Top      Up      ToC       Page 81 
   Countermeasures are available such as to configure the TRILL IS-IS
   and ESADI protocols to use IS-IS security [RFC5304] [RFC5310] and
   ignore unauthenticated TRILL control and ESADI frames received.
   RBridges using IS-IS security will need configuration.

   IEEE 802.1 port admission and link security mechanisms, such as
   [802.1X] and [802.1AE], can also be used.  These are best thought of
   as being implemented below TRILL (see Section 4.9.2) and are outside
   the scope of TRILL (just as they are generally out of scope for
   bridging standards [802.1D] and 802.1Q); however, TRILL can make use
   of secure registration through the confidence level communicated in
   the optional TRILL ESADI protocol (see Section 4.8).

   TRILL encapsulates native frames inside the RBridge campus while they
   are in transit between ingress RBridge and egress RBridge(s) as
   described in Sections 2.3 and 4.1.  Thus, TRILL ignorant devices with
   firewall features that cannot be detected by RBridges as end stations
   will generally not be able to inspect the content of such frames for
   security checking purposes.  This may render them ineffective.  Layer
   3 routers and hosts appear to RBridges to be end stations, and native
   frames will be decapsulated before being sent to such devices.  Thus,
   they will not see the TRILL Ethertype.  Firewall devices that do not
   appear to an RBridge to be an end station, for example, bridges with
   co-located firewalls, should be modified to understand TRILL
   encapsulation.

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

6.1.  VLAN Security Considerations

   TRILL supports VLANs.  These provide logical separation of traffic,
   but care should be taken in using VLANs for security purposes.  To
   have reasonable assurance of such separation, all the RBridges and
   links (including bridged LANs) in a campus must be secured and
   configured so as to prohibit end stations from using dynamic VLAN
   registration frames or otherwise gaining access to any VLAN carrying
   traffic for which they are not authorized to read and/or inject.

   Furthermore, if VLANs were used to keep some information off links
   where it might be observed in a bridged LAN, this will no longer
   work, in general, when bridges are replaced with RBridges; with
   encapsulation and a different outer VLAN tag, the data will travel
   the least cost transit path regardless of VLAN.  Appropriate counter
   measures are to use end-to-end encryption or an appropriate TRILL
   security option should one be specified.

Top      Up      ToC       Page 82 
6.2.  BPDU/Hello Denial-of-Service Considerations

   The TRILL protocol requires that an appointed forwarder at an RBridge
   port be temporarily inhibited if it sees a TRILL-Hello from another
   RBridge claiming to be the appointed forwarder for the same VLAN or
   sees a root bridge change out that port.  Thus, it would seem that
   forged BPDUs showing repeated root bridge changes and forged TRILL-
   Hello frames with the Appointed Forwarder flag set could represent a
   significant denial-of-service attack.  However, the situation is not
   as bad as it seems.

   The best defense against forged TRILL-Hello frames or other IS-IS
   messages is the use of IS-IS security [RFC5304] [RFC5310].  Rogue end
   stations would not normally have access to the required IS-IS keying
   material needed to forge authenticatible messages.

   Authentication similar to IS-IS security is usually unavailable for
   BPDUs.  However, it is also the case that in typical modern wired
   LANs, all the links are point-to-point.  If you have an all-RBridged
   point-to-point campus, then the worst that an end-station can do by
   forging BPDUs or TRILL-Hello frames is to deny itself service.  This
   could be either through falsely inhibiting the forwarding of native
   frames by the RBridge to which it is connected or by falsely
   activating the optional decapsulation check (see Section 4.2.4.3).

   However, when an RBridge campus contains bridged LANs, those bridged
   LANs appear to any connected RBridges to be multi-access links.  The
   forging of BPDUs by an end-station attached to such a bridged LAN
   could affect service to other end-stations attached to the same
   bridged LAN.  Note that bridges never forward BPDUs but process them,
   although this processing may result in the issuance of further BPDUs.
   Thus, for an end-station to forge BPDUs to cause continuing changes
   in the root bridge as seen by an RBridge through intervening bridges
   would typically require it to cause root bridge thrashing throughout
   the bridged LAN that would be disruptive even in the absence of
   RBridges.

   Some bridges can be configured to not send BPDUs and/or to ignore
   BPDUs on particular ports, and RBridges can be configured not to
   inhibit appointed forwarding on a port due to root bridge changes;
   however, such configuration should be used with caution as it can be
   unsafe.

7.  Assignment Considerations

   This section discuses IANA and IEEE 802 assignment considerations.
   See [RFC5226].

Top      Up      ToC       Page 83 
7.1.  IANA Considerations

   A new IANA registry has been created for TRILL Parameters with two
   subregistries as below.

   The initial contents of the TRILL Nicknames subregistry are as
   follows:

      0x0000 Reserved to indicate no nickname specified
      0x0001-0xFFBF Dynamically allocated by the RBridges within each
          RBridge campus
      0xFFC0-0xFFFE Available for allocation by RFC Required (single
          value) or IETF Review (single or multiple values)
      0xFFFF Permanently reserved

   The initial contents of the TRILL Multicast Address subregistry are
   as follows:

      01-80-C2-00-00-40  Assigned as All-RBridges
      01-80-C2-00-00-41  Assigned as All-IS-IS-RBridges
      01-80-C2-00-00-42  Assigned as All-ESADI-RBridges
      01-80-C2-00-00-43 to 01-80-C2-00-00-4F  Available for allocation
                         by IETF Review

7.2.  IEEE Registration Authority Considerations

   The Ethertype 0x22F3 is assigned by the IEEE Registration Authority
   to the TRILL Protocol.

   The Ethertype 0x22F4 is assigned by the IEEE Registration Authority
   for L2-IS-IS.

   The block of 16 multicast MAC addresses from <01-80-C2-00-00-40> to
   <01-80-C2-00-00-4F> is assigned by the IEEE Registration Authority
   for IETF TRILL protocol use.

8.  Normative References

   [802.1ak]  "IEEE Standard for Local and metropolitan area networks /
              Virtual Bridged Local Area Networks / Multiple
              Registration Protocol", IEEE Standard 802.1ak-2007, 22
              June 2007.

   [802.1D]   "IEEE Standard for Local and metropolitan area networks /
              Media Access Control (MAC) Bridges", 802.1D-2004, 9 June
              2004.

Top      Up      ToC       Page 84 
   [802.1Q-2005]
              "IEEE Standard for Local and metropolitan area networks /
              Virtual Bridged Local Area Networks", 802.1Q-2005, 19 May
              2006.

   [802.3]    "IEEE Standard for Information technology /
              Telecommunications and information exchange between
              systems / Local and metropolitan area networks / Specific
              requirements Part 3: Carrier sense multiple access with
              collision detection (CSMA/CD) access method and physical
              layer specifications", 802.3-2008, 26 December 2008.

   [ISO10589] ISO/IEC, "Intermediate system to Intermediate system
              routeing information exchange protocol for use in
              conjunction with the Protocol for providing the
              Connectionless-mode Network Service (ISO 8473)", ISO/IEC
              10589:2002.

   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
              RFC 1112, August 1989.

   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
              dual environments", RFC 1195, December 1990.

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

   [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
              Networks", RFC 2464, December 1998.

   [RFC2710]  Deering, S., Fenner, W., and B. Haberman, "Multicast
              Listener Discovery (MLD) for IPv6", RFC 2710, October
              1999.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002.

   [RFC3417]  Presuhn, R., Ed., "Transport Mappings for the Simple
              Network Management Protocol (SNMP)", STD 62, RFC 3417,
              December 2002.

   [RFC3419]  Daniele, M. and J. Schoenwaelder, "Textual Conventions for
              Transport Addresses", RFC 3419, December 2002.

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

Top      Up      ToC       Page 85 
   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5303]  Katz, D., Saluja, R., and D. Eastlake 3rd, "Three-Way
              Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303,
              October 2008.

   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", RFC 5305, October 2008.

   [RFC6165]  Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2
              Systems", RFC 6165, April 2011.

   [RFC6326]  Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A.
              Ghanwani, "Transparent Interconnection of Lots of Links
              (TRILL) Use of IS-IS", RFC 6326, July 2011.

9.  Informative References

   [802.1AB]  "IEEE Standard for Local and Metropolitan Networks /
              Station and Media Access Control Connectivity Discovery",
              802.1AB-2009, 17 September 2009.

   [802.1ad]  "IEEE Standard for and metropolitan area networks /
              Virtual Bridged Local Area Networks / Provider Bridges",
              802.1ad-2005, 26 May 2005.

   [802.1ah]  "IEEE Standard for Local and Metropolitan Area Networks /
              Virtual Bridged Local Area Networks / Provider Backbone
              Bridges", 802.1ah-2008, 1 January 2008.

   [802.1aj]  Virtual Bridged Local Area Networks / Two-Port Media
              Access Control (MAC) Relay, 802.1aj Draft 4.2, 24
              September 2009.

   [802.1AE]  "IEEE Standard for Local and metropolitan area networks /
              Media Access Control (MAC) Security", 802.1AE-2006, 18
              August 2006.

   [802.1AX]  "IEEE Standard for Local and metropolitan area networks /
              Link Aggregation", 802.1AX-2008, 1 January 2008.

   [802.1X]  "IEEE Standard for Local and metropolitan area networks /
              Port Based Network Access Control", 802.1X-REV Draft 2.9,
              3 September 2008.

Top      Up      ToC       Page 86 
   [RBridges] Perlman, R., "RBridges: Transparent Routing", Proc.
              Infocom 2005, March 2004.

   [RFC1661]  Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD
              51, RFC 1661, July 1994.

   [RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An
              Architecture for Describing Simple Network Management
              Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
              December 2002.

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              June 2005.

   [RFC4541]  Christensen, M., Kimball, K., and F. Solensky,
              "Considerations for Internet Group Management Protocol
              (IGMP) and Multicast Listener Discovery (MLD) Snooping
              Switches", RFC 4541, May 2006.

   [RFC4789]  Schoenwaelder, J. and T. Jeffree, "Simple Network
              Management Protocol (SNMP) over IEEE 802 Networks", RFC
              4789, November 2006.

   [RFC5304]  Li, T. and R. Atkinson, "IS-IS Cryptographic
              Authentication", RFC 5304, October 2008.

   [RFC5310]  Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
              and M. Fanto, "IS-IS Generic Cryptographic
              Authentication", RFC 5310, February 2009.

   [RFC5342]  Eastlake 3rd, D., "IANA Considerations and IETF Protocol
              Usage for IEEE 802 Parameters", BCP 141, RFC 5342,
              September 2008.

   [RFC5556]  Touch, J. and R. Perlman, "Transparent Interconnection of
              Lots of Links (TRILL): Problem and Applicability
              Statement", RFC 5556, May 2009.

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

   [VLAN-MAPPING]
              Perlman, R., Dutt, D., Banerjee, A., Rijhsinghani, A., and
              D. Eastlake 3rd, "RBridges: Campus VLAN and Priority
              Regions", Work in Progress, April 2011.

Top      Up      ToC       Page 87 
Appendix A.  Incremental Deployment Considerations

   Some aspects of partial RBridge deployment are described below for
   link cost determination (Appendix A.1) and possible congestion due to
   appointed forwarder bottlenecks (Appendix A.2).  A particular example
   of a problem related to the TRILL use of a single appointed forwarder
   per link per VLAN (the "wiring closet topology") is explored in
   detail in Appendix A.3.

A.1.  Link Cost Determination

   With an RBridged campus having no bridges or repeaters on the links
   between RBridges, the RBridges can accurately determine the number of
   physical hops involved in a path and the line speed of each hop,
   assuming this is reported by their port logic.  With intervening
   devices, this is no longer possible.  For example, as shown in Figure
   12, 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 12: Link Cost of a Bridged Link

   Even in the case of a single intervening bridge, two RBridges may
   know they are connected but each sees the link as a different speed
   from how it is seen by the other.

   However, this problem is not unique to RBridges.  Bridges can
   encounter similar situations due to links hidden by repeaters, and
   routers can encounter similar situations due to links hidden by
   bridges, repeaters, or Rbridges.

A.2.  Appointed Forwarders and Bridged LANs

   With partial RBridge deployment, the RBridges may partition a bridged
   LAN into a relatively small number of relatively large remnant
   bridged LANs, or possibly not partition it at all so a single bridged
   LAN remains.  Such configuration can result in the following problem:

   The requirement that native frames enter and leave a link via the
   link's appointed forwarder for the 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

Top      Up      ToC       Page 88 
   topology.  For example, if a bridged LAN had a star-like structure
   with core bridges that connected only to other bridges and peripheral
   bridges that connected to end stations and are connected to core
   bridges, the replacement of all of the core bridges by RBridges
   without replacing the peripheral bridges would generally improve
   performance without inducing appointed forwarder congestion.

   Solutions to this problem are discussed below and a particular
   example explored in Appendix A.3.

   Inserting RBridges so that all the bridged portions of the LAN stay
   connected to each other and have multiple RBridge connections is
   generally the least efficient arrangement.

   There are four techniques that may help if the problem above occurs
   and that can, to some extent, be used in combination:

   1. Replace more IEEE 802.1 customer bridges with RBridges so as to
      minimize the size of the remnant bridged LANs between RBridges.
      This requires no configuration of the RBridges unless the bridges
      they replace required configuration.

   2. Re-arrange network topology to minimize the problem.  If the
      bridges and RBridges involved are configured, this may require
      changes in their configuration.

   3. Configure the RBridges and bridges so that end stations on a
      remnant bridged LAN are separated into different VLANs that have
      different appointed forwarders.  If the end stations were already
      assigned to different VLANs, this is straightforward (see Section
      4.2.4.2).  If the end stations were on the same VLAN and have to
      be split into different VLANs, this technique may lead to
      connectivity problems between end stations.

   4. Configure the RBridges such that their ports that are connected to
      the bridged LAN send spanning tree configuration BPDUs (see
      Section A.3.3) in such a way as to force the partition of the
      bridged LAN.  (Note: A spanning tree is never formed through an
      RBridge but always terminates at RBridge ports.)  To use this
      technique, the RBridges must support this optional feature, and
      would need to be configured to use it, but the bridges involved
      would rarely have to be configured.  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 that use VLANs,
   or use more VLANs than would otherwise be necessary, to support the
   Multiple Spanning Tree Protocol or otherwise reduce the congestion

Top      Up      ToC       Page 89 
   that can be caused by a single spanning tree.  Replacing the IEEE
   802.1 bridges in such LANs with RBridges may enable a reduction in or
   elimination of VLANs and configuration complexity.

A.3.  Wiring Closet Topology

   If 802.1 bridges are present and RBridges are not properly
   configured, the bridge spanning tree or the DRB may make
   inappropriate decisions.  Below is a specific example of the more
   general problem that can occur when a bridged LAN is connected to
   multiple RBridges.

   In cases where there are two (or more) groups of end nodes, each
   attached to a bridge (say, B1 and B2), and each bridge is attached to
   an RBridge (say, RB1 and RB2, respectively), with an additional link
   connecting B1 and B2 (see Figure 13), 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 fails.

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

                     Figure 13: 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 might be that one of RB1 or RB2 (say, RB1) would
   become DRB for the bridged LAN including B1 and B2 and appoint itself
   forwarder for the VLANs on that bridged LAN.  As a result, RB1 would
   forward all traffic to/from the link, so end nodes attached to B2

Top      Up      ToC       Page 90 
   would be connected to the campus via the path B2-B1-RB1, rather than
   the desired B2-RB2.  This wastes the bandwidth of the B2-RB2 path and
   cuts available bandwidth between the end stations and the data center
   in half.  The desired behavior would be to make use of both the
   RB1-B1 and RB2-B2 links.

   Three solutions to this problem are described below.

A.3.1.  The RBridge Solution

   Of course, if B1 and B2 are replaced with RBridges, the right thing
   will happen without configuration (other than VLAN support), but this
   may not be immediately practical if bridges are being incrementally
   replaced by RBridges.

A.3.2.  The VLAN Solution

   If the end stations attached to B1 and B2 are already divided among a
   number of VLANs, RB1 and RB2 could be configured so that whichever
   becomes DRB for this link will appoint itself forwarder for some of
   these VLANs and appoint the other RBridge for the remaining VLANs.
   Should either of the RBridges fail or become disconnected, the other
   will have only itself to appoint as forwarder for all the VLANs.

   If the end stations are all on a single VLAN, then it would be
   necessary to assign them between at least two VLANs to use this
   solution.  This may lead to connectivity problems that might require
   further measures to rectify.

A.3.3.  The Spanning Tree Solution

   Another solution is to configure the relevant ports on RB1 and RB2 to
   be part of a "wiring closet group", with a configured per-RBridge
   port "Bridge Address" Bx (which may be RB1 or RB2's System ID).  Both
   RB1 and RB2 emit spanning tree BPDUs on their configured ports as
   highest priority root Bx.  This causes the spanning tree to logically
   partition the bridged LAN as desired by blocking the B1-B2 link at
   one end or the other (unless one of the bridges is configured to also
   have highest priority and has a lower ID, which we consider to be a
   misconfiguration).  With the B1-B2 link blocked, RB1 and RB2 cannot
   see each other's TRILL-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 through the RB1-B1-B2-RB2 path.

   In the spanning tree configuration BPDU, the Root is "Bx" with
   highest priority, cost to Root is 0, Designated Bridge ID is "RB1"
   when RB1 transmits and "RB2" when RB2 transmits, and port ID is a

Top      Up      ToC       Page 91 
   value chosen independently by each of RB1 and RB2 to distinguish each
   of its own ports.  The topology change flag is zero, and the topology
   change acknowledgement flag is set if and only if a topology change
   BPDU has been received on the port since the last configuration BPDU
   was transmitted on the port.  (If RB1 and RB2 were actually bridges
   on the same shared medium with no bridges between them, the result
   would be that the one with the larger ID sees "better" BPDUs (because
   of the tiebreaker on the third field: the ID of the transmitting
   bridge), and would turn off its port.)

   Should either RB1 or the RB1-B1 link or RB2 or the RB2-B2 link fail,
   the spanning tree algorithm will stop seeing one of the RBx roots and
   will unblock the B1-B2 link maintaining connectivity of all the end
   stations with the data center.

   If the link RB1-B1-B2-RB2 is on the cut set of the campus and RB2 and
   RB1 have been configured to believe they are part of a wiring closet
   group, the campus becomes partitioned as the link is blocked.

A.3.4.  Comparison of Solutions

   Replacing all 802.1 customer 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 spanning tree BPDUs
   as described in Appendix A.3.3 above.  It also makes the bridged LAN
   whose partition is being forced unavailable for through traffic.
   Finally, while in this specific example it neatly breaks the link
   between the two bridges B1 and B2, if there were a more complex
   bridged LAN, 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-B1 link and
   the RB2-B2 link although this is still better than using only one of
   these links exclusively.

Top      Up      ToC       Page 92 
Appendix B.  Trunk and Access Port Configuration

   Many modern bridged LANs are organized into a core and access model,
   The core bridges have only point-to-point links to other bridges
   while the access bridges connect to end stations, core bridges, and
   possibly other access bridges.  It seems likely that some RBridge
   campuses will be organized in a similar fashion.

   An RBridge port can be configured as a trunk port, that is, a link to
   another RBridge or RBridges, by configuring it to disable end-station
   support.  There is no reason for such a port to have more than one
   VLAN enabled and in its Announcing Set on the port.  Of course, the
   RBridge (or RBridges) to which it is connected must have the same
   VLAN enabled.  There is no reason for this VLAN to be other than the
   default VLAN 1 unless the link is actually over carrier Ethernet or
   other facilities that only provide some other specific VLAN or the
   like.  Such configuration minimizes wasted TRILL-Hellos and
   eliminates useless decapsulation and transmission of multi-
   destination traffic in native form onto the link (see Sections 4.2.4
   and 4.9.1).

   An RBridge access port would be expected to lead to a link with end
   stations and possibly one or more bridges.  Such a link might also
   have more than one RBridge connected to it to provide more reliable
   service to the end stations.  It would be a goal to minimize or
   eliminate transit traffic on such a link as it is intended for end-
   station native traffic.  This can be accomplished by turning on the
   access port configuration bit for the RBridge port or ports connected
   to the link as further detailed in Section 4.9.1.

   When designing RBridge configuration user interfaces, consideration
   should be given to making it convenient to configure ports as trunk
   and access ports.

Appendix C.  Multipathing

   Rbridges support multipathing of both known unicast and multi-
   destination traffic.  Implementation of multipathing is optional.

   Multi-destination traffic can be multipathed by using different
   distribution tree roots for different frames.  For example, assume
   that in Figure 14 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, a distribution tree rooted at RBy will predominantly use the
   vertical links among RB1 through RB9 while one rooted at RBz will
   predominantly use the horizontal.  If RBy chooses its nickname as the
   distribution tree root for half of this traffic and an RBz nickname

Top      Up      ToC       Page 93 
   as the root for the other half, it may be able to substantially
   increase the aggregate bandwidth by making use of both the vertical
   and horizontal links among RB1 through RB9.

   Since the distribution trees an RBridge must calculate are the same
   for all RBridges and transit RBridges MUST respect the tree root
   specified by the ingress RBridge, a campus will operate correctly
   with a mix of RBridges some of which use different roots for
   different multi-destination frames they ingress and some of which use
   a single root for all such frames.

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

                  Figure 14: Multi-Destination Multipath

   Known unicast Equal Cost Multipathing (ECMP) can occur at an RBridge
   if, instead of using a tiebreaker criterion when building SPF paths,
   information is retained about ports through which equal cost paths
   are available.  Different unicast frames can then be sent through
   those different ports and will be forwarded by equal cost paths.  For
   example, in Figure 15, which shows only RBridges and omits any
   bridges present, there are three equal cost paths between RB1 and RB2
   and two equal cost paths between RB2 and RB5.  Thus, for traffic
   transiting this part of the campus from left to right, RB1 may be
   able to perform three way ECMP and RB2 may be able to perform two-way
   ECMP.

   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

Top      Up      ToC       Page 94 
   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.

   There are actually three possibilities for the parallel paths between
   RB1 and RB2 as follows:

   1. If two or three of these paths have pseudonodes, then all three
      will be distinctly visible in the campus-wide link state and ECMP
      as described above is applicable.

   2. If the paths use P2P Hellos or otherwise do not have pseudonodes,
      these three paths would appear as a single adjacency in the link
      state.  In this case, multipathing across them would be an
      entirely local matter for RB1 and RB2.  It can be freely done for
      known unicast frames but not for multi-destination frames as
      described in Section 4.5.2.

   3. If and only if the three paths between RB1 and RB2 are single hop
      equal bandwidth links with no intervening bridges, then it would
      be permissible to combine them into one logical link through the
      [802.1AX] "link aggregation" feature.  Rbridges MAY implement link
      aggregation since that feature operates below TRILL (see Section
      4.9.2).

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

                    Figure 15: Known Unicast 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 where re-ordering within a flow is
   damaging.  How to determine flows or what granularity flows should
   have is beyond the scope of this document.  (This issue is discussed
   in [802.1AX].)

Top      Up      ToC       Page 95 
Appendix D.  Determination of VLAN and Priority

   A high-level, informative summary of how VLAN ID and priority are
   determined for incoming native frames, omitting some details, is
   given in the bulleted items below.  For more detailed information,
   see [802.1Q-2005].

   o  When an untagged native frame arrives, an unconfigured RBridge
      associates the default priority zero and the VLAN ID 1 with it.
      It actually sets the VLAN for the untagged frame to be the "port
      VLAN ID" associated with that port.  The port VLAN ID defaults to
      VLAN ID 1 but may be configured to be any other VLAN ID.  An
      Rbridge may also be configured on a per-port basis to discard such
      frames or to associate a different priority code point with them.
      Determination of the VLAN ID associated with an incoming untagged
      non-control frame may also be made dependent on the Ethertype or
      NSAP (referred to in 802.1 as the Protocol) of the arriving frame,
      the source MAC address, or other local rules.

   o  When a priority tagged native frame arrives, an unconfigured
      RBridge associates with it both the port VLAN ID, which defaults
      to 1, and the priority code point provided in the priority tag in
      the frame.  An Rbridge may be configured on a per-port basis to
      discard such frames or to associate them with a different VLAN ID
      as described in the point immediately above.  It may also be
      configured to map the priority code point provided in the frame by
      specifying, for each of the eight possible values that might be in
      the frame, what actual priority code point will be associated with
      the frame by the RBridge.

   o  When a C-tagged (formerly called Q-tagged) native frame arrives,
      an unconfigured RBridge associates with it the VLAN ID and
      priority in the C-tag.  An RBridge may be configured on a per-port
      per-VLAN basis to discard such frames.  It may also be configured
      on a per-port basis to map the priority value as specified above
      for priority tagged frames.

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

Appendix E.  Support of IEEE 802.1Q-2005 Amendments

   This informational appendix briefly comments on RBridge support for
   completed and in-process amendments to IEEE [802.1Q-2005].  There is
   no assurance that existing RBridge protocol specifications or
   existing bridges will support not yet specified future [802.1Q-2005]
   amendments just as there is no assurance that existing bridge

Top      Up      ToC       Page 96 
   protocol specifications or existing RBridges will support not yet
   specified future TRILL amendments.

   The information below is frozen as of 25 October 2009.  For the
   latest status, see the IEEE 802.1 working group
   (http://grouper.ieee.org/groups/802/1/).

E.1.  Completed Amendments

   802.1ad-2005 Provider Bridges - Sometimes called "Q-in-Q", because
         VLAN tags used to be called "Q-tags", 802.1ad specifies
         Provider Bridges that tunnel customer bridge traffic within
         service VLAN tags (S-tags).  If the customer LAN is an RBridge
         campus, that traffic will be bridged by Provider Bridges.
         Customer bridge features involving Provider Bridge awareness,
         such as the ability to configure a customer bridge port to add
         an S-tag to a frame before sending it to a Provider Bridge, are
         below the EISS layer and can be supported in RBridge ports
         without modification to the TRILL protocol.

   802.1ag-2007 Connectivity Fault Management (CFM) - This 802.1 feature
         is at least in part dependent on the symmetric path and other
         characteristics of spanning tree.  The comments provided to the
         IETF TRILL working group by the IEEE 802.1 working group stated
         that "TRILL weakens the applicability of CFM".

   802.1ak-2007 Multiple Registration Protocol - Supported to the extent
         described in Section 4.9.4.

   802.1ah-2008 Provider Backbone Bridges - Sometimes called "MAC-in-
         MAC", 802.1ah provides for Provider Backbone Bridges that
         tunnel customer bridge traffic within different outer MAC
         addresses and using a tag (the "I-tag") to preserve the
         original MAC addresses and signal other information.  If the
         customer LAN is an RBridge campus, that traffic will be bridged
         by Provider Backbone Bridges.  Customer bridge features
         involving Provider Backbone Bridge awareness, such as the
         ability to configure a customer bridge port to add an I-tag to
         a frame before sending it to a Provider Backbone Bridge, are
         below the EISS layer and can be supported in RBridge ports
         without modification to the TRILL protocol.

   802.1Qaw-2009 Management of Data-Driven and Data-Dependent
         Connectivity Fault - Amendment building on 802.1ag.  See
         comments on 802.1ag-2007 above.

Top      Up      ToC       Page 97 
   802.1Qay-2009 Provider Backbone Bridge Traffic Engineering -
         Amendment building on 802.1ah to configure traffic engineered
         routing.  See comments on 802.1ah-2008 above.

E.2.  In-Process Amendments

   The following are amendments to IEEE [802.1Q-2005] that are in
   process.  As such, the brief comments below are based on drafts and
   may be incorrect for later versions or any final amendment.

   802.1aj Two-port MAC Relay [802.1aj] - This amendment specifies a MAC
         relay that will be transparent to RBridges.  RBridges are
         compatible with IEEE 802.1aj devices as currently specified, in
         the same sense that IEEE 802.1Q-2005 bridges are compatible
         with such devices.

   802.1aq Shortest Path Bridging - This amendment provides for improved
         routing in bridged LANs.

   802.1Qat Stream Reservation Protocol - Modification to 802.1Q to
         support the 802.1 Timing and Synchronization.  This protocol
         reserves resources for streams at supporting bridges.

   802.1Qau Congestion Notification - It currently appears that
         modifications to RBridge behavior above the EISS level would be
         needed to support this amendment.  Such modifications are
         beyond the scope of this document.

   802.1Qav Forwarding and Queuing Enhancements for Time-Sensitive
         Streams - Modification to 802.1Q to support the 802.1 Timing
         and Synchronization protocol.  This amendment specifies methods
         to support the resource reservations made through the 802.1Qat
         protocol (see above).

   802.1Qaz Enhanced Transmission Selection - It appears that this
         amendment will be below the EISS layer and can be supported in
         RBridge ports without modification to the TRILL protocol.

   802.1Qbb Priority-based Flow Control - Commonly called "per-priority
         pause", it appears that this amendment will be below the EISS
         layer and can be supported in RBridge ports without
         modification to the TRILL protocol.

   802.1bc Remote Customer Service Interfaces.  This is an extension to
         802.1Q provider bridging.  See 802.1ad-2005 above.

Top      Up      ToC       Page 98 
   802.1Qbe Multiple Backbone Service Instance Identifier (I-SID)
         Registration Protocol (MIRP).  This is an extension to 802.1Q
         provider backbone bridging.  See 802.1ah-2008 above.

   802.1Qbf Provider Backbone Bridge Traffic Engineering (PBB-TE)
         Infrastructure Segment Protection.  This amendment extends
         802.1Q to support certain types of failover between provider
         backbone bridges.  See 802.1ah-2008 above.

Appendix F.  Acknowledgements

   Many people have contributed to this design, including the following,
   in alphabetic order:

      Bernard Aboba, Alia Atlas, Ayan Banerjee, Caitlin Bestler, Suresh
      Boddapati, David Michael Bond, Stewart Bryant, Ross Callon, James
      Carlson, Pasi Eronen, Dino Farinacci, Adrian Farrell, Don Fedyk,
      Bill Fenner, Eric Gray, Sujay Gupta, Joel Halpern, Andrew Lange,
      Acee Lindem, Vishwas Manral, Peter McCann, Israel Meilik, David
      Melman, Nandakumar Natarajan, Erik Nordmark, Jeff Pickering, Tim
      Polk, Dan Romascanu, Sanjay Sane, Pekka Savola, Matthew R. Thomas,
      Joe Touch, Mark Townsley, Kate Zebrose.

Top      Up      ToC       Page 99 
Authors' Addresses

   Radia Perlman
   Intel Labs
   2200 Mission College Blvd.
   Santa Clara, CA 95054-1549 USA

   Phone: +1-408-765-8080
   EMail: Radia@alum.mit.edu


   Donald E. Eastlake, 3rd
   Huawei Technologies
   155 Beaver Street
   Milford, MA 01757 USA

   Phone: +1-508-333-2270
   EMail: d3e3e3@gmail.com


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

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


   Silvano Gai
   Cisco Systems
   170 Tasman Drive
   San Jose, CA 95134-1706 USA

   EMail: silvano@ip6.com


   Anoop Ghanwani
   Brocade
   130 Holger Way
   San Jose, CA 95134 USA

   Phone: +1-408-333-7149
   EMail: anoop@alumni.duke.edu