Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6325

Routing Bridges (RBridges): Base Protocol Specification

Pages: 99
Proposed Standard
Errata
Updated by:  63276439717271777357717971807455778077838139824983618377
Part 4 of 4 – Pages 71 to 99
First   Prev   None

Top   ToC   RFC6325 - Page 71   prevText

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   ToC   RFC6325 - 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   ToC   RFC6325 - 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   ToC   RFC6325 - 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   ToC   RFC6325 - 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   ToC   RFC6325 - 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   ToC   RFC6325 - 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   ToC   RFC6325 - 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   ToC   RFC6325 - 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   ToC   RFC6325 - 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   ToC   RFC6325 - 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   ToC   RFC6325 - 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   ToC   RFC6325 - 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   ToC   RFC6325 - 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   ToC   RFC6325 - 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   ToC   RFC6325 - 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   ToC   RFC6325 - 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   ToC   RFC6325 - 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   ToC   RFC6325 - 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   ToC   RFC6325 - 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   ToC   RFC6325 - 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   ToC   RFC6325 - 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   ToC   RFC6325 - 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   ToC   RFC6325 - 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   ToC   RFC6325 - 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   ToC   RFC6325 - 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   ToC   RFC6325 - 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   ToC   RFC6325 - 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   ToC   RFC6325 - 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