Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6325

Routing Bridges (RBridges): Base Protocol Specification

Pages: 99
Proposed Standard
Errata
Updated by:  63276439717271777357717971807455778077838139824983618377
Part 1 of 4 – Pages 1 to 20
None   None   Next

Top   ToC   RFC6325 - Page 1
Internet Engineering Task Force (IETF)                        R. Perlman
Request for Comments: 6325                                    Intel Labs
Category: Standards Track                                D. Eastlake 3rd
ISSN: 2070-1721                                                   Huawei
                                                                 D. Dutt
                                                                  S. Gai
                                                           Cisco Systems
                                                             A. Ghanwani
                                                                 Brocade
                                                               July 2011


        Routing Bridges (RBridges): Base Protocol Specification

Abstract

Routing Bridges (RBridges) provide optimal pair-wise forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. They achieve these goals using IS-IS routing and encapsulation of traffic with a header that includes a hop count. RBridges are compatible with previous IEEE 802.1 customer bridges as well as IPv4 and IPv6 routers and end nodes. They are as invisible to current IP routers as bridges are and, like routers, they terminate the bridge spanning tree protocol. The design supports VLANs and the optimization of the distribution of multi-destination frames based on VLAN ID and based on IP-derived multicast groups. It also allows unicast forwarding tables at transit RBridges to be sized according to the number of RBridges (rather than the number of end nodes), which allows their forwarding tables to be substantially smaller than in conventional customer bridges. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6325.
Top   ToC   RFC6325 - Page 2
Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.
Top   ToC   RFC6325 - Page 3

Table of Contents

1. Introduction ....................................................6 1.1. Algorhyme V2, by Ray Perlner ...............................7 1.2. Normative Content and Precedence ...........................7 1.3. Terminology and Notation in This Document ..................7 1.4. Categories of Layer 2 Frames ...............................8 1.5. Acronyms ...................................................9 2. RBridges .......................................................11 2.1. General Overview ..........................................11 2.2. End-Station Addresses .....................................12 2.3. RBridge Encapsulation Architecture ........................13 2.4. Forwarding Overview .......................................15 2.4.1. Known-Unicast ......................................16 2.4.2. Multi-Destination ..................................16 2.5. RBridges and VLANs ........................................17 2.5.1. Link VLAN Assumptions ..............................17 2.6. RBridges and IEEE 802.1 Bridges ...........................18 2.6.1. RBridge Ports and 802.1 Layering ...................18 2.6.2. Incremental Deployment .............................20 3. Details of the TRILL Header ....................................20 3.1. TRILL Header Format .......................................20 3.2. Version (V) ...............................................21 3.3. Reserved (R) ..............................................21 3.4. Multi-destination (M) .....................................22 3.5. Op-Length .................................................22 3.6. Hop Count .................................................22 3.7. RBridge Nicknames .........................................23 3.7.1. Egress RBridge Nickname ............................23 3.7.2. Ingress RBridge Nickname ...........................24 3.7.3. RBridge Nickname Selection .........................24 3.8. TRILL Header Options ......................................26 4. Other RBridge Design Details ...................................27 4.1. Ethernet Data Encapsulation ...............................27 4.1.1. VLAN Tag Information ...............................30 4.1.2. Inner VLAN Tag .....................................31 4.1.3. Outer VLAN Tag .....................................31 4.1.4. Frame Check Sequence (FCS) .........................32 4.2. Link State Protocol (IS-IS) ...............................32 4.2.1. IS-IS RBridge Identity .............................32 4.2.2. IS-IS Instances ....................................33 4.2.3. TRILL IS-IS Frames .................................33 4.2.4. TRILL Link Hellos, DRBs, and Appointed Forwarders ..34 4.2.4.1. P2P Hello Links ...........................35 4.2.4.2. Designated RBridge ........................35 4.2.4.3. Appointed VLAN-x Forwarder ................36 4.2.4.4. TRILL LSP Information .....................37 4.2.5. The TRILL ESADI Protocol ...........................40
Top   ToC   RFC6325 - Page 4
                  4.2.5.1. TRILL ESADI Participation .................42
                  4.2.5.2. TRILL ESADI Information ...................42
           4.2.6. SPF, Forwarding, and Ambiguous Destinations ........43
      4.3. Inter-RBridge Link MTU Size ...............................43
           4.3.1. Determining Campus-Wide TRILL IS-IS MTU Size .......44
           4.3.2. Testing Link MTU Size ..............................44
      4.4. TRILL-Hello Protocol ......................................45
           4.4.1. TRILL-Hello Rationale ..............................45
           4.4.2. TRILL-Hello Contents and Timing ....................46
                  4.4.2.1. TRILL Neighbor List .......................48
           4.4.3. TRILL MTU-Probe and TRILL Hello VLAN Tagging .......49
           4.4.4. Multiple Ports on the Same Link ....................50
           4.4.5. VLAN Mapping within a Link .........................51
      4.5. Distribution Trees ........................................52
           4.5.1. Distribution Tree Calculation ......................54
           4.5.2. Multi-Destination Frame Checks .....................55
           4.5.3. Pruning the Distribution Tree ......................57
           4.5.4. Tree Distribution Optimization .....................58
           4.5.5. Forwarding Using a Distribution Tree ...............59
      4.6. Frame Processing Behavior .................................60
           4.6.1. Receipt of a Native Frame ..........................60
                  4.6.1.1. Native Unicast Case .......................60
                  4.6.1.2. Native Multicast and Broadcast Frames .....61
           4.6.2. Receipt of a TRILL Frame ...........................62
                  4.6.2.1. TRILL Control Frames ......................63
                  4.6.2.2. TRILL ESADI Frames ........................63
                  4.6.2.3. TRILL Data Frames .........................63
                  4.6.2.4. Known Unicast TRILL Data Frames ...........63
                  4.6.2.5. Multi-Destination TRILL Data Frames .......64
           4.6.3. Receipt of a Layer 2 Control Frame .................65
      4.7. IGMP, MLD, and MRD Learning ...............................66
      4.8. End-Station Address Details ...............................66
           4.8.1. Learning End-Station Addresses .....................67
           4.8.2. Learning Confidence Level Rationale ................68
           4.8.3. Forgetting End-Station Addresses ...................69
           4.8.4. Shared VLAN Learning ...............................70
      4.9. RBridge Ports .............................................71
           4.9.1. RBridge Port Configuration .........................71
           4.9.2. RBridge Port Structure .............................73
           4.9.3. BPDU Handling ......................................76
                  4.9.3.1. Receipt of BPDUs ..........................76
                  4.9.3.2. Root Bridge Changes .......................76
                  4.9.3.3. Transmission of BPDUs .....................77
           4.9.4. Dynamic VLAN Registration ..........................77
   5. RBridge Parameters .............................................77
      5.1. Per RBridge ...............................................78
      5.2. Per Nickname Per RBridge ..................................79
      5.3. Per Port Per RBridge ......................................79
Top   ToC   RFC6325 - Page 5
      5.4. Per VLAN Per RBridge ......................................80
   6. Security Considerations ........................................80
      6.1. VLAN Security Considerations ..............................81

      6.2. BPDU/Hello Denial-of-Service Considerations ...............82
   7. Assignment Considerations ......................................82
      7.1. IANA Considerations .......................................83
      7.2. IEEE Registration Authority Considerations ................83
   8. Normative References ...........................................83
   9. Informative References .........................................85
   Appendix A. Incremental Deployment Considerations .................87
      A.1. Link Cost Determination ...................................87
      A.2. Appointed Forwarders and Bridged LANs .....................87
      A.3. Wiring Closet Topology ....................................89
           A.3.1. The RBridge Solution ...............................90
           A.3.2. The VLAN Solution ..................................90
           A.3.3. The Spanning Tree Solution .........................90
           A.3.4. Comparison of Solutions ............................91
   Appendix B. Trunk and Access Port Configuration ...................92
   Appendix C. Multipathing ..........................................92
   Appendix D. Determination of VLAN and Priority ....................95
   Appendix E. Support of IEEE 802.1Q-2005 Amendments ................95
      E.1. Completed Amendments ......................................96
      E.2. In-Process Amendments .....................................97
   Appendix F. Acknowledgements ......................................98

Table of Figures

Figure 1: Interconnected RBridges .................................14 Figure 2: An Ethernet Encapsulated TRILL Frame ....................14 Figure 3: A PPP Encapsulated TRILL Frame ..........................14 Figure 4: RBridge Port Model ......................................19 Figure 5: TRILL Header ............................................21 Figure 6: Options Area Initial Flags Octet ........................26 Figure 7: TRILL Data Encapsulation over Ethernet ..................29 Figure 8: VLAN Tag Information ....................................30 Figure 9: TRILL IS-IS Frame Format ................................34 Figure 10: TRILL ESADI Frame Format ...............................41 Figure 11: Detailed RBridge Port Model ............................74 Figure 12: Link Cost of a Bridged Link ............................87 Figure 13: Wiring Closet Topology .................................89 Figure 14: Multi-Destination Multipath ............................93 Figure 15: Known Unicast Multipath ................................94
Top   ToC   RFC6325 - Page 6

1. Introduction

In traditional IPv4 and IPv6 networks, each subnet has a unique prefix. Therefore, a node in multiple subnets has multiple IP addresses, typically one per interface. This also means that when an interface moves from one subnet to another, it changes its IP address. Administration of IP networks is complicated because IP routers require per-port subnet address configuration. Careful IP address management is required to avoid creating subnets that are sparsely populated, wasting addresses. IEEE 802.1 bridges avoid these problems by transparently gluing many physical links into what appears to IP to be a single LAN [802.1D]. However, 802.1 bridge forwarding using the spanning tree protocol has some disadvantages: o The spanning tree protocol works by blocking ports, limiting the number of forwarding links, and therefore creates bottlenecks by concentrating traffic onto selected links. o Forwarding is not pair-wise shortest path, but is instead whatever path remains after the spanning tree eliminates redundant paths. o The Ethernet header does not contain a hop count (or Time to Live (TTL)) field. This is dangerous when there are temporary loops such as when spanning tree messages are lost or components such as repeaters are added. o VLANs can partition when the spanning tree reconfigures. This document presents the design for RBridges (Routing Bridges [RBridges]) that implement the TRILL protocol and are poetically summarized below. Rbridges combine the advantages of bridges and routers and, as specified in this document, are the application of link state routing to the VLAN-aware customer bridging problem. With the exceptions discussed in this document, RBridges can incrementally replace IEEE [802.1Q-2005] or [802.1D] customer bridges. While RBridges can be applied to a variety of link protocols, this specification focuses on IEEE [802.3] links. Use with other link types is expected to be covered in other documents. The TRILL protocol, as specified herein, is designed to be a Local Area Network protocol and not designed with the goal of scaling beyond the size of existing bridged LANs. For further discussion of the problem domain addressed by RBridges, see [RFC5556].
Top   ToC   RFC6325 - Page 7

1.1. Algorhyme V2, by Ray Perlner

I hope that we shall one day see A graph more lovely than a tree. A graph to boost efficiency While still configuration-free. A network where RBridges can Route packets to their target LAN. The paths they find, to our elation, Are least cost paths to destination! With packet hop counts we now see, The network need not be loop-free! RBridges work transparently, Without a common spanning tree.

1.2. Normative Content and Precedence

The bulk of the normative material in this specification appears in Sections 1 through 4. In case of conflict between provisions in these four sections, the provision in the higher numbered section prevails.

1.3. Terminology and Notation in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. "TRILL" is the protocol specified herein while an "RBridge" is a device that implements that protocol. The second letter in Rbridge is case insensitive. Both Rbridge and RBridge are correct. In this document, the term "link", unless otherwise qualified, means "bridged LAN", that is to say, the combination of one or more [802.3] links with zero or more bridges, hubs, repeaters, or the like. The term "simple link" or the like is used indicate a point-to-point or multi-access link with no included bridges or RBridges. In this document, the term "port", unless otherwise qualified, includes physical, virtual [802.1AE], and pseudo [802.1X] ports. The term "physical port" or the like is used to indicate the physical point of connection between an RBridge and a link.
Top   ToC   RFC6325 - Page 8
   A "campus" is to RBridges as a "bridged LAN" is to bridges.  An
   RBridge campus consists of a network of RBridges, bridges, hubs,
   repeaters, simple links, and the like and it is bounded by end
   stations and routers.

   The term "spanning tree" in this document includes both classic
   spanning tree and rapid spanning tree (as in the Rapid Spanning Tree
   Protocol).

   This document uses hexadecimal notation for MAC addresses.  Two
   hexadecimal digits represent each octet (that is, 8-bit byte), giving
   the value of the octet as an unsigned integer.  A hyphen separates
   successive octets.  This document consistently uses IETF bit
   ordering, although the physical order of bit transmission within an
   octet on an IEEE [802.3] link is from the lowest order bit to the
   highest order bit, the reverse of IETF ordering.

1.4. Categories of Layer 2 Frames

In this document, Layer 2 frames are divided into five categories: o Layer 2 control frames (such as Bridge PDUs (BPDUs)) o native frames (non-TRILL-encapsulated data frames) o TRILL Data frames (TRILL-encapsulated data frames) o TRILL control frames o TRILL other frames The way these five types of frames are distinguished is as follows: o Layer 2 control frames are those with a multicast destination address in the range 01-80-C2-00-00-00 to 01-80-C2-00-00-0F or equal to 01-80-C2-00-00-21. RBridges MUST NOT encapsulate and forward such frames, though they MAY, unless otherwise specified in this document, perform the Layer 2 function (such as MAC-level security) of the control frame. Frames with a destination address of 01-80-C2-00-00-00 (BPDU) or 01-80-C2-00-00-21 (VLAN Registration Protocol) are called "high-level control frames" in this document. All other Layer 2 control frames are called "low- level control frames". o Native frames are those that are not control frames and have an Ethertype other than "TRILL" or "L2-IS-IS" and have a destination MAC address that is not one of the 16 multicast addresses reserved for TRILL. o TRILL Data frames have the Ethertype "TRILL". In addition, TRILL data frames, if multicast, have the multicast destination MAC address "All-RBridges".
Top   ToC   RFC6325 - Page 9
   o  TRILL control frames have the Ethertype "L2-IS-IS".  In addition,
      TRILL control frames, if multicast, have the multicast destination
      MAC addresses of "All-IS-IS-RBridges".  (Note that ESADI frames
      look on the outside like TRILL data and are so handled but, when
      decapsulated, have the L2-IS-IS Ethertype.)

   o  TRILL other frames are those with any of the 16 multicast
      destination addresses reserved for TRILL other than All-RBridges
      and All-IS-IS-RBridges.  RBridges conformant to this specification
      MUST discard TRILL other frames.

1.5. Acronyms

AllL1ISs - All Level 1 Intermediate Systems AllL2ISs - All Level 2 Intermediate Systems BPDU - Bridge PDU CHbH - Critical Hop-by-Hop CItE - Critical Ingress-to-Egress CSNP - Complete Sequence Number PDU DA - Destination Address DR - Designated Router DRB - Designated RBridge EAP - Extensible Authentication Protocol ECMP - Equal Cost Multipath EISS - Extended Internal Sublayer Service ESADI - End-Station Address Distribution Information FCS - Frame Check Sequence GARP - Generic Attribute Registration Protocol GVRP - GARP VLAN Registration Protocol IEEE - Institute of Electrical and Electronics Engineers IGMP - Internet Group Management Protocol
Top   ToC   RFC6325 - Page 10
   IP - Internet Protocol

   IS-IS - Intermediate System to Intermediate System

   ISS - Internal Sublayer Service

   LAN - Local Area Network

   LSP - Link State PDU

   MAC - Media Access Control

   MLD - Multicast Listener Discovery

   MRD - Multicast Router Discovery

   MTU - Maximum Transmission Unit

   MVRP - Multiple VLAN Registration Protocol

   NSAP - Network Service Access Point

   P2P - Point-to-point

   PDU - Protocol Data Unit

   PPP - Point-to-Point Protocol

   RBridge - Routing Bridge

   RPF - Reverse Path Forwarding

   SA - Source Address

   SNMP - Simple Network Management Protocol

   SPF - Shortest Path First

   TLV - Type, Length, Value

   TRILL - TRansparent Interconnection of Lots of Links

   VLAN - Virtual Local Area Network

   VRP - VLAN Registration Protocol
Top   ToC   RFC6325 - Page 11

2. RBridges

This section provides a high-level overview of RBridges, which implement the TRILL protocol, omitting some details. Sections 3 and 4 below provide more detailed specifications. TRILL, as described in this document and with the exceptions discussed herein, provides [802.1Q-2005] VLAN-aware customer bridging service. As described below, TRILL is layered above the ports of an RBridge. The RBridges specified by this document do not supply provider [802.1ad] or provider backbone [802.1ah] bridging or the like. The extension of TRILL to provide such provider services is left for future work that will be separately documented. However, provider or provider backbone bridges may be used to interconnect parts of an RBridge campus.

2.1. General Overview

RBridges run a link state protocol amongst themselves. This gives them enough information to compute pair-wise optimal paths for unicast, and calculate distribution trees for delivery of frames either to destinations whose location is unknown or to multicast/broadcast groups [RBridges] [RP1999]. To mitigate temporary loop issues, RBridges forward based on a header with a hop count. RBridges also specify the next hop RBridge as the frame destination when forwarding unicast frames across a shared- media link, which avoids spawning additional copies of frames during a temporary loop. A Reverse Path Forwarding Check and other checks are performed on multi-destination frames to further control potentially looping traffic (see Section 4.5.2). The first RBridge that a unicast frame encounters in a campus, RB1, encapsulates the received frame with a TRILL header that specifies the last RBridge, RB2, where the frame is decapsulated. RB1 is known as the "ingress RBridge" and RB2 is known as the "egress RBridge". To save room in the TRILL header and simplify forwarding lookups, a dynamic nickname acquisition protocol is run among the RBridges to select 2-octet nicknames for RBridges, unique within the campus, which are an abbreviation for the IS-IS ID of the RBridge. The 2-octet nicknames are used to specify the ingress and egress RBridges in the TRILL header. Multipathing of multi-destination frames through alternative distribution trees and ECMP (Equal Cost Multipath) of unicast frames are supported (see Appendix C).
Top   ToC   RFC6325 - Page 12
   Networks with a more mesh-like structure will benefit to a greater
   extent from the multipathing and optimal paths provided by TRILL than
   will more tree-like networks.

   RBridges run a protocol on a link to elect a "Designated RBridge"
   (DRB).  The TRILL-IS-IS election protocol on a link is a little
   different from the Layer 3 IS-IS [ISO10589] election protocol,
   because in TRILL it is essential that only one RBridge be elected
   DRB, whereas in Layer 3 IS-IS it is possible for multiple routers to
   be elected Designated Router (also known as Designated Intermediate
   System).  As with an IS-IS router, the DRB may give a pseudonode name
   to the link, issue an LSP (Link State PDU) on behalf of the
   pseudonode, and issues CSNPs (Complete Sequence Number PDUs) on the
   link.  Additionally, the DRB has some TRILL-specific duties,
   including specifying which VLAN will be the Designated VLAN used for
   communication between RBridges on that link (see Section 4.2.4.2).

   The DRB either encapsulates/decapsulates all data traffic to/from the
   link, or, for load splitting, delegates this responsibility, for one
   or more VLANs, to other RBridges on the link.  There must at all
   times be at most one RBridge on the link that
   encapsulates/decapsulates traffic for a particular VLAN.  We will
   refer to the RBridge appointed to forward VLAN-x traffic on behalf of
   the link as the "appointed VLAN-x forwarder" (see Section 4.2.4.3).
   (Section 2.5 discusses VLANs further.)

   Rbridges SHOULD support SNMPv3 [RFC3411].  The Rbridge MIB will be
   specified in a separate document.  If IP service is available to an
   RBridge, it SHOULD support SNMPv3 over UDP over IPv4 [RFC3417] and
   IPv6 [RFC3419]; however, management can be used, within a campus,
   even for an RBridge that lacks an IP or other Layer 3 transport stack
   or which does not have a Layer 3 address, by transporting SNMP with
   Ethernet [RFC4789].

2.2. End-Station Addresses

An RBridge, RB1, that is the VLAN-x forwarder on any of its links MUST learn the location of VLAN-x end nodes, both on the links for which it is VLAN-x forwarder and on other links in the campus. RB1 learns the port, VLAN, and Layer 2 (MAC) addresses of end nodes on links for which it is VLAN-x forwarder from the source address of frames received, as bridges do (for example, see Section 8.7 of [802.1Q-2005]), or through configuration or a Layer 2 explicit registration protocol such as IEEE 802.11 association and authentication. RB1 learns the VLAN and Layer 2 address of distant VLAN-x end nodes, and the corresponding RBridge to which they are
Top   ToC   RFC6325 - Page 13
   attached, by looking at the ingress RBridge nickname in the TRILL
   header and the VLAN and source MAC address of the inner frame of
   TRILL Data frames that it decapsulates.

   Additionally, an RBridge that is the appointed VLAN-x forwarder on
   one or more links MAY use the End-Station Address Distribution
   Information (ESADI) protocol to announce some or all of the attached
   VLAN-x end nodes on those links.

   The ESADI protocol could be used to announce end nodes that have been
   explicitly enrolled.  Such information might be more authoritative
   than that learned from data frames being decapsulated onto the link.
   Also, the addresses enrolled and distributed in this way can be more
   secure for two reasons: (1) the enrollment might be authenticated
   (for example, by cryptographically based EAP methods via [802.1X]),
   and (2) the ESADI protocol also supports cryptographic authentication
   of its messages [RFC5304] [RFC5310] for more secure transmission.

   If an end station is unplugged from one RBridge and plugged into
   another, then, depending on circumstances, frames addressed to that
   end station can be black-holed.  That is, they can be sent just to
   the older RBridge that the end station used to be connected to until
   cached address information at some remote RBridge(s) times out,
   possibly for a number of minutes or longer.  With the ESADI protocol,
   the link interruption from the unplugging can cause an immediate
   update to be sent.

   Even if the ESADI protocol is used to announce or learn attached end
   nodes, RBridges MUST still learn from received native frames and
   decapsulated TRILL Data frames unless configured not to do so.
   Advertising end nodes using ESADI is optional, as is learning from
   these announcements.

   (See Section 4.8 for further end-station address details.)

2.3. RBridge Encapsulation Architecture

The Layer 2 technology used to connect Rbridges may be either IEEE [802.3] or some other link technology such as PPP [RFC1661]. This is possible since the RBridge relay function is layered on top of the Layer 2 technologies. However, this document specifies only an IEEE 802.3 encapsulation. Figure 1 shows two RBridges, RB1 and RB2, interconnected through an Ethernet cloud. The Ethernet cloud may include hubs, point-to-point or shared media, IEEE 802.1D bridges, or 802.1Q bridges.
Top   ToC   RFC6325 - Page 14
                               ------------
                              /            \
                 +-----+     /   Ethernet   \    +-----+
                 | RB1 |----<                >---| RB2 |
                 +-----+     \    Cloud     /    +-----+
                              \            /
                               ------------

                     Figure 1: Interconnected RBridges

   Figure 2 shows the format of a TRILL data or ESADI frame traveling
   through the Ethernet cloud between RB1 and RB2.

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

              Figure 2: An Ethernet Encapsulated TRILL Frame

   In the case of media different from Ethernet, the header specific to
   that media replaces the outer Ethernet header.  For example, Figure 3
   shows a TRILL encapsulation over PPP.

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

                 Figure 3: A PPP Encapsulated TRILL Frame

   The outer header is link-specific and, although this document
   specifies only [802.3] links, other links are allowed.
Top   ToC   RFC6325 - Page 15
   In both cases, the inner Ethernet header and the Ethernet Payload
   come from the original frame and are encapsulated with a TRILL header
   as they travel between RBridges.  Use of a TRILL header offers the
   following benefits:

   1. loop mitigation through use of a hop count field;

   2. elimination of the need for end-station VLAN and MAC address
      learning in transit RBridges;

   3. direction of unicast frames towards the egress RBridge (this
      enables unicast forwarding tables of transit RBridges to be sized
      with the number of RBridges rather than the total number of end
      nodes); and

   4. provision of a separate VLAN tag for forwarding traffic between
      RBridges, independent of the VLAN of the native frame.

   When forwarding unicast frames between RBridges, the outer header has
   the MAC destination address of the next hop Rbridge, to avoid frame
   duplication if the inter-RBridge link is multi-access.  This also
   enables multipathing of unicast, since the transmitting RBridge can
   specify the next hop.  Having the outer header specify the
   transmitting RBridge as the source address ensures that any bridges
   inside the Ethernet cloud will not get confused, as they might be if
   multipathing is in use and they were to see the original source or
   ingress RBridge in the outer header.

2.4. Forwarding Overview

RBridges are true routers in the sense that, in the forwarding of a frame by a transit RBridge, the outer Layer 2 header is replaced at each hop with an appropriate Layer 2 header for the next hop, and a hop count is decreased. Despite these modifications of the outer Layer 2 header and the hop count in the TRILL header, the original encapsulated frame is preserved, including the original frame's VLAN tag. See Section 4.6 for more details. From a forwarding standpoint, transit frames may be classified into two categories: known-unicast and multi-destination. Layer 2 control frames and TRILL control and TRILL other frames are not transit frames, are not forwarded by RBridges, and are not included in these categories.
Top   ToC   RFC6325 - Page 16

2.4.1. Known-Unicast

These frames have a unicast inner MAC destination address (Inner.MacDA) and are those for which the ingress RBridge knows the egress RBridge for the destination MAC address in the frame's VLAN. Such frames are forwarded Rbridge hop by Rbridge hop to their egress Rbridge.

2.4.2. Multi-Destination

These are frames that must be delivered to multiple destinations. Multi-destination frames include the following: 1. unicast frames for which the location of the destination is unknown: the Inner.MacDA is unicast, but the ingress RBridge does not know its location in the frame's VLAN. 2. multicast frames for which the Layer 2 destination address is derived from an IP multicast address: the Inner.MacDA is multicast, from the set of Layer 2 multicast addresses derived from IPv4 [RFC1112] or IPv6 [RFC2464] multicast addresses. These frames are handled somewhat differently in different subcases: 2.1. IGMP [RFC3376] and MLD [RFC2710] multicast group membership reports 2.2. IGMP [RFC3376] and MLD [RFC2710] queries and MRD [RFC4286] announcement messages 2.3. other IP-derived Layer 2 multicast frames 3. multicast frames for which the Layer 2 destination address is not derived from an IP multicast address: the Inner.MacDA is multicast, and not from the set of Layer 2 multicast addresses derived from IPv4 or IPv6 multicast addresses. 4. broadcast frames: the Inner.MacDA is broadcast (FF-FF-FF-FF-FF-FF). RBridges build distribution trees (see Section 4.5) and use these trees for forwarding multi-destination frames. Each distribution tree reaches all RBridges in the campus, is shared across all VLANs, and may be used for the distribution of a native frame that is in any VLAN. However, the distribution of any particular frame on a distribution tree is pruned in different ways for different cases to avoid unnecessary propagation of the frame.
Top   ToC   RFC6325 - Page 17

2.5. RBridges and VLANs

A VLAN is a way to partition end nodes in a campus into different Layer 2 communities [802.1Q-2005]. Use of VLANs requires configuration. By default, the port of receipt determines the VLAN of a frame sent by an end station. End stations can also explicitly insert this information in a frame. IEEE [802.1Q-2005] bridges can be configured to support multiple customer VLANs over a single simple link by inserting/removing a VLAN tag in the frame. VLAN tags used by TRILL have the same format as VLAN tags defined in IEEE [802.1Q-2005]. As shown in Figure 2, there are two places where such tags may be present in a TRILL-encapsulated frame sent over an IEEE [802.3] link: one in the outer header (Outer.VLAN) and one in the inner header (Inner.VLAN). Inner and outer VLANs are further discussed in Section 4.1. RBridges enforce delivery of a native frame originating in a particular VLAN only to other links in the same VLAN; however, there are a few differences in the handling of VLANs between an RBridge campus and an 802.1 bridged LAN as described below. (See Section 4.2.4 for further discussion of TRILL IS-IS operation on a link.)

2.5.1. Link VLAN Assumptions

Certain configurations of bridges may cause partitions of a VLAN on a link. For such configurations, a frame sent by one RBridge to a neighbor on that link might not arrive, if tagged with a VLAN that is partitioned due to bridge configuration. TRILL requires at least one VLAN per link that gives full connectivity to all the RBridges on that link. The default VLAN is 1, though RBridges may be configured to use a different VLAN. The DRB dictates to the other RBridges which VLAN to use. Since there will be only one appointed forwarder for any VLAN, say, VLAN-x, on a link, if bridges are configured to cause VLAN-x to be partitioned on a link, some VLAN-x end nodes on that link may be orphaned (unable to communicate with the rest of the campus). It is possible for bridge and port configuration to cause VLAN mapping on a link (where a VLAN-x frame turns into a VLAN-y frame). TRILL detects this by inserting a copy of the outer VLAN into TRILL- Hello messages and checking it on receipt. If detected, it takes
Top   ToC   RFC6325 - Page 18
   steps to ensure that there is at most a single appointed forwarder on
   the link, to avoid possible frame duplication or loops (see Section
   4.4.5).

   TRILL behaves as conservatively as possible, avoiding loops rather
   than avoiding partial connectivity.  As a result, lack of
   connectivity may result from bridge or port misconfiguration.

2.6. RBridges and IEEE 802.1 Bridges

RBridge ports are, except as described below, layered on top of IEEE [802.1Q-2005] port facilities.

2.6.1. RBridge Ports and 802.1 Layering

RBridge ports make use of [802.1Q-2005] port VLAN and priority processing. In addition, they MAY implement other lower-level 802.1 protocols as well as protocols for the link in use, such as PAUSE (Annex 31B of [802.3]), port-based access control [802.1X], MAC security [802.1AE], or link aggregation [802.1AX]. However, RBridges do not use spanning tree and do not block ports as spanning tree does. Figure 4 shows a high-level diagram of an RBridge with one port connected to an IEEE 802.3 link. Single lines represent the flow of control information, double lines the flow of both frames and control information.
Top   ToC   RFC6325 - Page 19
                          +-----------------------------------------
                          |                RBridge
                          |
                          |     Forwarding Engine, IS-IS, etc.
                          | Processing of native and TRILL frames
                          |
                          +----+---+--------++----------------------
                               |   |        ||         other ports...
                 +-------------+   |        ||
                 |                 |        ||
    +------------+-------------+   |        ||
    |         RBridge          |   |   +----++-------+ <- EISS
    |                          |   |   |             |
    | High-Level Control Frame |   |   | 802.1Q-2005 |
    |  Processing (BPDU, VRP)  |   |   |  Port VLAN  |
    |                          |   |   |  & 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 4: RBridge Port Model

   The upper interface to the low-level port/link control logic
   corresponds to the Internal Sublayer Service (ISS) in [802.1Q-2005].
   In RBridges, high-level control frames are processed above the ISS
   interface.

   The upper interface to the port VLAN and priority processing
   corresponds to the Extended Internal Sublayer Service (EISS) in
   [802.1Q-2005].  In RBridges, native and TRILL frames are processed
   above the EISS interface and are subject to port VLAN and priority
   processing.
Top   ToC   RFC6325 - Page 20

2.6.2. Incremental Deployment

Because RBridges are compatible with IEEE [802.1Q-2005] customer bridges, except as discussed in this document, a bridged LAN can be upgraded by incrementally replacing such bridges with RBridges. Bridges that have not yet been replaced are transparent to RBridge traffic. The physical links directly interconnected by such bridges, together with the bridges themselves, constitute bridged LANs. These bridged LANs appear to RBridges to be multi-access links. If the bridges replaced by RBridges were default configuration bridges, then their RBridge replacements will not require configuration. Because RBridges, as described in this document, only provide customer services, they cannot replace provider bridges or provider backbone bridges, just as a customer bridge can't replace a provider bridge. However, such provider devices can be part of the bridged LAN between RBridges. Extension of TRILL to support provider services is left for future work and will be separately documented. Of course, if the bridges replaced had any port level protocols enabled, such as port-based access control [802.1X] or MAC security [802.1AE], replacement RBridges would need the same port level protocols enabled and similarly configured. In addition, the replacement RBridges would have to support the same link type and link level protocols as the replaced bridges. An RBridge campus will work best if all IEEE [802.1D] and [802.1Q-2005] bridges are replaced with RBridges, assuming the RBridges have the same speed and capacity as the bridges. However, there may be intermediate states, where only some bridges have been replaced by RBridges, with inferior performance. See Appendix A for further discussion of incremental deployment.


(page 20 continued on part 2)

Next Section