RFC 6325
Routing Bridges (RBridges): Base Protocol Specification
Pages: 99
Proposed Standard
→ Errata
Updated by: 6327 6439 7172 7177 7357 7179 7180 7455 7780 7783 8139 8249 8361 8377
Proposed Standard
→ Errata
Updated by: 6327 6439 7172 7177 7357 7179 7180 7455 7780 7783 8139 8249 8361 8377
Part 4 of 4 – Pages 71 to 99
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.
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
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.
+---------------------------------------------- | 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,
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.
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
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.
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.
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).
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.
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.
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].
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 Review7.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.
[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.
[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.
[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.
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
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
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
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
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.
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
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
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].)
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
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.
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.
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.
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