tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6325

 Errata 
Proposed STD
Pages: 99
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: TRILL

Routing Bridges (RBridges): Base Protocol Specification

Part 1 of 4, p. 1 to 20
None       Next RFC Part

Updated by:    6327    6439    7172    7177    7357    7179    7180    7455    7780    7783


Top       ToC       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.

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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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 RFC Part