[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 draft-ietf-trill-rbridge-arch

     Network Working Group                             Eric Gray, Editor
     Internet Draft                                             Ericsson
     Expires: August, 2006
     
                                                           March 1, 2006
     
     
     
               The Architecture of an RBridge Solution to TRILL
                     draft-touch-trill-rbridge-arch-01.txt
     
     
     Status of this Memo
     
        By submitting this Internet-Draft, each author represents that
        any applicable patent or other IPR claims of which he or she is
        aware have been or will be disclosed, and any of which he or she
        becomes aware will be disclosed, in accordance with Section 6 of
        BCP 79.
     
        Internet-Drafts are working documents of the Internet
        Engineering Task Force (IETF), its areas, and its working
        groups.  Note that other groups may also distribute working
        documents as Internet-Drafts.
     
        Internet-Drafts are draft documents valid for a maximum of six
        months and may be updated, replaced, or obsoleted by other
        documents at any time.  It is inappropriate to use Internet-
        Drafts as reference material or to cite them other than as "work
        in progress."
     
        The list of current Internet-Drafts can be accessed at
             http://www.ietf.org/ietf/1id-abstracts.txt
     
        The list of Internet-Draft Shadow Directories can be accessed at
             http://www.ietf.org/shadow.html
     
        This Internet-Draft will expire on August 1, 2006.
     
     
     
     Abstract
     
        RBridges are link layer (L2) devices that use routing protocols
        as a control plane. They combine the link layer ability to allow
        hosts to reattach without renumbering with network layer routing
        benefits. RBridges use existing link state routing to provide
        higher RBridge to RBridge cross-section bandwidth, fast
     
     
     
     Gray                     Expires August, 2006              [Page 1]


     Internet-Draft           RBridge Architecture         February 2006
     
     
        convergence on reconfiguration, and more robust under link
        interruption than an equivalent set of conventional bridges
        using existing spanning tree forwarding. They are intended to
        apply to similar L2 network sizes as conventional bridges and
        are intended to be backward compatible with those bridges as
        both ingress/egress and transit. They also attempt to retain as
        much 'plug and play' as is already available in existing
        bridges. This document proposes an RBridge system as a solution
        to the TRILL problem. It also defines the RBridge architecture,
        defines its terminology, and describes basic components and
        desired behavior. One or more separate documents specify the
        protocols and mechanisms that satisfy the architecture presented
        herein.
     
     Conventions used 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 RFC-2119 [1].
     
     Table of Contents
     
     
        1. Introduction....................................... 3
        2. Background........................................ 4
           2.1. Existing Terminology............................ 4
           2.2. RBridge Terminology............................. 8
        3. Components....................................... 10
           3.1. RBridge Device................................ 10
           3.2. CFT......................................... 11
           3.3. CFT-IRT...................................... 11
           3.4. CTT......................................... 13
        4. Functional Description ............................. 13
           4.1. RBridge Campus Auto-configuration................ 13
           4.2. RBridge Peer Discovery......................... 15
           4.3. Tunneling.................................... 16
           4.4. RBridge General Operation....................... 17
           4.5. Ingress/Egress Operations....................... 19
           4.6. Transit Forwarding Operations.................... 20
              4.6.1. Unicast ................................. 21
              4.6.2. Broadcast, Multicast and Flooding............ 22
                 4.6.2.1. Broadcast............................ 22
                 4.6.2.2. Multicast............................ 23
                 4.6.2.3. Flooding............................. 24
           4.7. Routing Protocol Operation...................... 26
              4.7.1. Determining CFT........................... 26
     
     
     Gray                     Expires August, 2006              [Page 2]


     Internet-Draft           RBridge Architecture         February 2006
     
     
              4.7.2. Determing CFT-IRT......................... 26
              4.7.3. Determining CTT........................... 26
           4.8. Other Bridging and Ethernet Protocol Operations..... 26
              4.8.1. Outgoing BPDU Interactions.................. 27
              4.8.2. Incoming BPDU Interactions.................. 27
                 4.8.2.1. Transparent-STP....................... 28
                 4.8.2.2. Participate-STP....................... 29
                 4.8.2.3. Block-STP............................ 30
        5. How RBridges Address TRILL.......................... 30
        6. Conclusions ...................................... 30
        7. Security Considerations............................. 31
        8. IANA Considerations................................ 31
        9. Acknowledgments................................... 32
           9.1. Normative References........................... 32
           9.2. Informative References......................... 32
        Author's Addresses................................... 32
        Intellectual Property Statement ........................ 33
        Disclaimer of Validity................................ 33
        Copyright Statement.................................. 34
        Acknowledgment ...................................... 34
     
     1. Introduction
     
        This document describes an architecture that addresses the TRILL
        problem and applicability statement [3]. This architecture is
        composed of a set of devices called RBridges that cooperate
        together within an Ethernet network to provide a layer two
        delivery service that makes efficient use of available links
        using a link state routing protocol. The service provided is
        analogous to creation of a single, virtual device composed of an
        overlay of tunnels, constructed between RBridge devices, using
        link state routing. RBridges thus support increased RBridge to
        Rbridge bandwidth and fault tolerance, when compared to
        conventional Ethernet bridges (which forward frames via a
        spanning tree), while still being compatible with bridges and
        hubs.
     
        The remainder of this document outlines the TRILL architecture
        of an RBridge-based solution and describes RBridge components,
        interactions and functions. Note that this document is not
        intended to represent the only solution to the TRILL problem
        statement, nor does it specify the protocols that instantiate
        this architecture - or that only one such set of protocols is
        prescribed. The former may be contained in other architecture
        documents and the latter would be contained in separate
        specification documents (e.g. - [4]).
     
     
     
     Gray                     Expires August, 2006              [Page 3]


     Internet-Draft           RBridge Architecture         February 2006
     
     
     2. Background
     
        This architecture is based on the RBridge system described in an
        Infocom paper [2]. That paper describes the RBridge system as a
        specific instance; this document abstracts architectural
        features only. The remainder of this section describes the
        terminology of this document, which may differ from that of the
        original paper.
     
     2.1. Existing Terminology
     
        The following terminology is defined in other documents. A brief
        definition is included in this section for convenience and - in
        some cases - to remove any ambiguity in how the term may be used
        in this document, as well as derivative documents intended to
        specify components, protocol, behavior and encapsulation
        relative to the architecture specified in this document.
     
        o  802: IEEE Specification for Ethernet, i.e., including hubs
           and switches.
     
        o  802.1D: IEEE Specification for bridged Ethernet, including
           the BPDUs used in spanning tree protocol (STP) [6].
     
        o  ARP: Address Resolution Protocol - the protocol used to
           resolve L2 (MAC) addresses, using a given L3 (IP) address.
     
        o  Bridge: an Ethernet (L2, 802.1D) device with multiple ports
           that receives incoming frames on a port and transmits them on
           some or all of the other ports; bridges support both bridge
           learning and STP.
     
        o  Bridge Learning: process by which a switch or bridge
           determines on which single outgoing port to transmit (forward
           or copy) an incoming frame. This process depends on
           consistent forwarding as "learning" uses the source MAC
           address of frames received on each interface. Layer 2 (L2)
           forwarding devices "learn" the location of L2 destinations by
           peeking at layer 2 source addresses during frame forwarding,
           and store the association of source address and receiving
           interface.  L2 forwarding devices use this information to
           create "filtering database" entries and - gradually -
           eliminate the need for flooding.
     
        o  Bridge Protocol Data Unit (BPDU): the frame type associated
           with bridge control functions (for example: STP/RSTP).
     
     
     
     Gray                     Expires August, 2006              [Page 4]


     Internet-Draft           RBridge Architecture         February 2006
     
     
        o  Bridge Spanning Tree (BST): an Ethernet (L2, 802.1D)
           forwarding protocol based on the topology of a spanning tree.
     
        o  Broadcast Domain: the set of (layer 2) devices that MUST be
           reached (or reachable) by any (layer 2) broadcast traffic
           injected into the domain.
     
        o  Broadcast Traffic: traffic intended for receipt by all
           devices in a broadcast domain.
     
        o  Ethernet: See "802" above.
     
        o  Filtering Database - database containing association
           information of (source layer 2 address, arrival interface).
           The interface that is associated with a specific layer 2
           source address, is the same interface which is used to
           forward frames having that address as a destination.  When a
           layer 2 forwarding device has no entry for the destination
           layer 2 address of any frame it receives, the frame is
           "flooded".
     
        o  Flooded Traffic - traffic forwarded on all interfaces, except
           those on which it was received, within the same broadcast
           domain. Flooding is the mechanism by which traffic is
           delivered to a destination that is currently "unknown" (i.e.
           - either not yet "learned", or aged out of the "filtering
           database").
     
        o  Flooding - the process of forwarding traffic to ensure that
           frames reach all possible destinations when the destination
           location is not known.  In "flooding", a layer 2 forwarding
           device forwards a   frame for any destination not "known"
           (i.e. - not in the filtering database) on every active
           interface except that one on which it was received. See also
           VLAN flooding.
     
        o  Frame: in this document, frame refers to an Ethernet (L2)
           unit of transmission, including header, data, and trailer (or
           payload and envelope).
     
        o  Hub: an Ethernet (L2, 802) device with multiple ports which
           transparently transmits frames arriving on any port to all
           other ports.  This is a functional definition, as there are
           devices that combine this function with certain bridge-like
           functions that may - under certain conditions - be referred
           to as "hubs".
     
     
     
     Gray                     Expires August, 2006              [Page 5]


     Internet-Draft           RBridge Architecture         February 2006
     
     
        o  IGP: Interior Gateway Protocol - any of the potential routing
           protocols candidates considered as potentially useful RBridge
           routing protocols.
     
        o  IS-IS: Intermediate System to Intermediate System routing
           protocol.
     
        o  LAN: Local Area Network. A LAN is an L2 forwarding domain.
           This term is synonymous with Ethernet Subnet in the context
           of this document.
     
        o  LPT: Learned Port Table. See Filtering Database.
     
        o  MAC: Media Access Control - mechanisms and addressing for L2
           frame forwarding.
     
        o  Multicast Forwarding: forwarding methods that apply to frames
           with broadcast or multicast destination MAC addresses.
     
        o  ND: Neighbor Discovery - peer RBridge discovery, potentially
           based on routing peer (neighbor) discovery.
     
        o  Node: a device with an L2 (MAC) address that sources and/or
           sinks L2 frames.
     
        o  OSPF: Open Shortest Path First routing protocol.
     
        o  Packet: in this document, packet refers to L3 (or above) data
           transmission units (e.g. - an IP Packet (RFC791 [5]),
           including header and data.
     
        o  Router: a device that performs IP (L3) forwarding (the
           "routing function"); RBridges typically do not span routers.
     
        o  Routing Function: in this document, the "routing function"
           consists of forwarding IP packets between L2 broadcast
           domains, based on L3 addressing and forwarding information.
           In the process of performing the "routing function", devices
           (typically routers) usually forward packets from one L2
           broadcast domain to another (one, or more in the IP multicast
           case) - distinct - L2 broadcast domain(s). RBridges cannot
           span the routing function.
     
        o  Segment: an Ethernet link, either a single physical link or
           emulation thereof (e.g., via hubs) or a logical link or
           emulation thereof (e.g., via bridges).
     
     
     
     Gray                     Expires August, 2006              [Page 6]


     Internet-Draft           RBridge Architecture         February 2006
     
     
        o  Spanning Tree Protocol (STP): an Ethernet (802.1D) protocol
           for establishing and maintaining a single spanning tree among
           all the bridges on a local Ethernet segment. Also, Rapid
           Spanning Tree Protocol (RSTP). In this document, STP and RSTP
           are considered to be the same.
     
        o  Spanning Tree Table (STT): a table containing port activation
           status information as determined during STP.
     
        o  SPF: Shortest Path First - the algorithm name associated with
           routing based on use of the Dijkstra algorithm (Edsger Wybe
           Dijkstra) to determine a shortest path graph traversal.
     
        o  Subnet, Ethernet: a single segment, or a set of segments
           interconnected by an RBridge campus; in the latter case, the
           subnet may or may not be equivalent to a single segment. Also
           may be referred to as a broadcast domain or LAN. By
           definition, all nodes within an Ethernet Subnet (broadcast
           domain or LAN) must have L2 connectivity with all other nodes
           in the same Ethernet Subnet.
     
        o  Switch: an Ethernet (L2, 802) device with multiple point-to-
           point ports which transmits (forwards or copies) frames that
           arrive on one port to one or more other ports. Switches may
           include bridge learning. Switches may also exclude STP/RSTP.
     
        o  TRILL: Transparent Interconnect over Lots of Links - the
           working group and working name for the problem domain to be
           addressed in this document.
     
        o  Unicast Forwarding: forwarding methods that apply to frames
           with unicast destination MAC addresses.
     
        o  Unknown Destination - a destination for which a receiving
           device has no filtering database entry.  Destination (layer
           2) addresses are typically "learned" by (layer 2) forwarding
           devices via a process commonly referred to as "bridge
           learning".
     
        o  VLAN: Virtual Local Area Network. VLANs in general fall into
           two categories: link (or port) specific VLANs and tagged
           VLANs. In the former case, all frames forwarded and all
           directly connected nodes are assumed to be part of a single
           VLAN.  In the latter case, VLAN tagged frames are used to
           distinguish which VLAN each frame is intended for.
     
     
     
     
     Gray                     Expires August, 2006              [Page 7]


     Internet-Draft           RBridge Architecture         February 2006
     
     
        o  VLAN Flooding: flooding as described previously, except that
           frames are only forwarded on those interfaces configured for
           participation in the applicable VLAN.
     
     2.2. RBridge Terminology
     
        The following terms are defined in this document and intended
        for use in derivative documents intended to specify components,
        protocol, behavior and encapsulation relative to the
        architecture specified in this document.
     
        o  Campus (RBridge Campus): a set of cooperating RBridges, and
           the forwarding tunnels that connect them. Unless otherwise
           stated, the term "campus" is used in this document to mean
           "RBridge campus".
     
        o  Campus Forwarding Table (CFT): the per-hop forwarding table
           populated by the RBridge IGP based on lookups of the campus
           Transit Header (CTH) encapuslated within the outermost
           received L2 header, rather than that encapsulating L2 header.
           The outermost L2 encapsulation in this case includes the
           source MAC address of the immediate upstream RBridge
           transmitting the frame and destination MAC address of the
           receiving RBridge for use in the unicast forwarding case.
     
        o  CFT-IRT: a forwarding table used for propagation of
           broadcast, multicast or flooded frames along the Ingress
           RBridge Tree (IRT).
     
        o  Campus Transit Header (CTH): a 'shim' header that
           encapsulates the ingress L2 frame and persists throughout the
           transit of a campus, which is further encapsulated within a
           hop-by-hop L2 header (and trailer). The hop-by-hop L2
           encapsulation in this case includes the source MAC address of
           the immediate upstream RBridge transmitting the frame and
           destination MAC address of the receiving RBridge - at least
           in the unicast forwarding case.
     
        o  Campus Transit Table (CTT): a table that maps ingress frame
           L2 destinations to egress RBridge addresses, used to
           determine encapsulation of ingress frames for transit of the
           campus.
     
        o  Cooperating RBridges - those RBridges within a single
           Ethernet Subnet (broadcast domain or LAN) not having been
           configured to ignore each other. By default, all RBridges
           within a single Ethernet subnet will cooperate with each
     
     
     Gray                     Expires August, 2006              [Page 8]


     Internet-Draft           RBridge Architecture         February 2006
     
     
           other. It is possible for implementations to allow for
           configuration that will restrict "cooperation" between an
           RBridge and an apparent neighboring RBridge.  One reason why
           this might occur is if the trust model that applies in a
           particular deployment imposes a need for configuration of
           security information.  By default no such configuration is
           required however - should it be used in any specific scenario
           - it is possible (either deliberately or inadvertently) to
           configure neighboring RBridges so that they do not
           "cooperate".  In the remainder of this document, all RBridges
           are assumed to be in a cooperating (default) configuration.
     
        o  Designated RBridge (DR): the RBridge associated with ingress
           and egress traffic to a particular Ethernet link having
           shared access among multiple RBridges; that RBridge is such a
           link's "Designated RBridge". The Designated RBridge is
           determined by an election process among those RBridges having
           shared access via a single Segment.
     
        o  Edge RBridge (edge of an RBridge campus): describes RBridges
           that serve to ingress frames into the RBridge campus and
           egress frames from the RBridge Campus. L2 frames transiting
           an RBridge campus enter, and leave, the campus via one or
           more edge RBridges.
     
        o  Egress RBridge: for any specific frame, the RBridge through
           which that frame leaves the RBridge campus. For frames
           transiting an RBridge Campus, the egress RBridge is an edge
           RBridge where RBridge encapsulation is removed from the
           transit frames prior to exiting the Campus.
     
        o  Forwarding Tunnels: in this document, Campus Forwarding
           Tunnels (or Forwarding Tunnels) is used to refer to the paths
           for forwarding transit frames, encapsulated at an RBridge
           ingress and decapsulated at an RBridge egress.
     
        o  Ingress RBridge: for any specific frame, the RBridge through
           which that frame enters the RBridge campus. For frames
           transiting an RBridge Campus, the ingress RBridge is the edge
           RBridge where RBridge encapsulation is added to the transit
           traffic entering the Campus.
     
     
     
     
     
     
     
     
     Gray                     Expires August, 2006              [Page 9]


     Internet-Draft           RBridge Architecture         February 2006
     
     
        o  Ingress RBridge Tree: a tree computed for each edge RBridge -
           and potentially for each VLAN in which that RBridge
           participates - for delivery of broadcast, multicast and
           flooded frames from that RBridge to all relevant egress
           RBridges. This is the point-to-multipoint delivery tree used
           by an ingress RBridge to deliver multicast, broadcast or
           flooded traffic.  The tree consists of a set of one or more
           next-hops to be used when the ingress RBridge receives a
           multicast or broadcast frame (frame with a multicast or
           broadcast destination address), or frame with unknown
           destination addresses.  If forwarding frames hop-by-hop, next
           hop RBridges will, in turn, have a similar set of one or more
           next-hops to be used for forwarding these frames - when
           received from an upstream, or ingress, RBridge.  This
           progression continues until frames arrive at egress RBridges.
     
        o  Rbridge: a logical device as specified in this document,
           which incorporate both routing and bridging features, thus
           allowing for the achievment of TRILL Architecture goals. A
           single RBridge device which can aggregate with other RBridge
           devices to create an RBridge Campus.
     
        o  RBridge Campus: See "Campus".
     
     3. Components
     
        An RBridge campus is composed of RBridge devices and the
        forwarding tunnels that connect them; all other Ethernet link
        subnet devices, such as bridges, hubs, and nodes, operate
        conventionally in the presence of an RBridge.
     
     3.1. RBridge Device
     
        An RBridge is a bridge-like device that forwards frames on an
        Ethernet link segment. It has one or more Ethernet ports which
        may be wired or wireless; the particular physical layer is not
        relevant. An RBridge is defined more by its behavior than its
        structure, although it contains two tables which distinguish it
        from conventional bridges.
     
        Conventional bridges contain a learned port table (LPT), or
        filtering database, and a spanning tree table (STT). The LPT
        allows a bridge to avoid flooding all received frames, as is
        typical for a hub or repeater. The bridge learns which nodes are
        accessible from a particular port by assuming bi-directional
        consistency: the source addresses of incoming frames indicate
        that the incoming port is to be used as output for frames
     
     
     Gray                     Expires August, 2006             [Page 10]


     Internet-Draft           RBridge Architecture         February 2006
     
     
        destined to that address. Incoming frames are checked against
        the LPT and forwarded to the particular port if a match occurs,
        otherwise they are flooded out all ports except the incoming
        port.
     
        The STT indicates the ports used in the spanning tree. Details
        of STP operation are out of scope for this document, however the
        result of STP is to disable ports which would otherwise result
        in more than one path traversing a portion of the spanning tree.
     
        RBridges, by comparison, have a Campus Forwarding Table (CFT)
        and a Campus Transit Table (CTT), described in the following
        sections.
     
     3.2. CFT
     
        The CFT is a forwarding table for unicast traffic within the
        RBridge campus, allowing tunneled traffic to transit the campus
        from ingress to egress. The size of a fully-populated CFT is
        maximally bounded by the product of the number of egress
        RBridges and corresponding VLANs - assuming that hop-by-hop
        frame forwarding is not used. If hop-by-hop frame forwarding is
        used, the size of a fully populated CFT at each RBridge is
        maximally bounded by the product of the number of directly
        connected RBridge peers (where "directly connected" in this
        context refers to RBridges connected to each other without
        transiting one or more additional RBridges) and VLANs. RBridges
        may have separate CFTs for each VLAN, if this is supported by
        manual configuration. The CFT is continually maintained by
        RBridge routing protocol (see Section 4.7).
     
     3.3. CFT-IRT
     
        The CFT-IRT consists of a special-case set of forwarding entries
        used for support of Ingress RBridge Trees (IRT). The CFT-IRT may
        be part of the CFT, or instantiated as a separate table.
     
        In discussing entries to be included in the CFT-IRT, the
        following entities are temporarily defined, or further
        qualified:
     
        o  Ingress RBridge - the RBridge that is the head end of an IRT.
           All RBridges within an RBridge campus are potential ingress
           RBridges.
     
     
     
     
     
     Gray                     Expires August, 2006             [Page 11]


     Internet-Draft           RBridge Architecture         February 2006
     
     
        o  Egress RBridge - an RBridge that is the tail end of a path
           corresponding to a specific CFT-IRT entry. All RBridges
           within an RBridge campus are potential egress RBridges. Not
           all RBridges within an RBridge campus will be on the shortest
           path between any ingress RBridge and any other egress
           RBridge.
     
        o  Local RBridge - the RBridge that forms and maintains the CFT-
           IRT entry (or entries) under discussion. The local RBridge
           may be an Ingress RBridge, or an egress RBridge with respect
           to any set of entries in the CFT-IRT.
     
        o  RBridge Campus Egress Interface - an interface on any RBridge
           where a transit RBridge encapsulated frame would be
           decapsulated prior to forwarding. With respect to such an
           interface, the local RBridge is the egress RBridge.
     
        Each local RBridge will maintain a set of entries for at least
        the following - corresponding to a subset of all possible
        forwarding paths:
     
        o  Zero or more entries grouped for each ingress RBridge - keyed
           by the ingress RBridge identifier - used to determine
           downstream forwarding of broadcast, multicast, and flooded
           frames originally RBridge encapsulated by that ingress within
           the RBridge campus.
     
        o  Corresponding to each of these entry groups, one entry for
           each of zero or more egress RBridge - where the local RBridge
           is on the shortest path toward that egress RBridge.
     
        o  Corresponding to each of these entry groups, one entry for
           each of zero or more RBridge campus egress interfaces.
     
        Each entry would contain an indication of which single interface
        a broadcast, multicast or flooded frame would be forwarded for
        each (ingress RBridge, egress RBridge) pair - as well as any
        required encapsulation information, etc. required for forwarding
        on that interface, toward the corresponding specific egress
        RBridge.
     
        A local RBridge could maintain a full set of entries from every
        RBridge to every other RBridge, however - depending on topology
        - only a subset of these entries would ever be used.  In
        addition, a topology change that changed selection of shortest
        paths would also very likely change other elements of the
     
     
     
     Gray                     Expires August, 2006             [Page 12]


     Internet-Draft           RBridge Architecture         February 2006
     
     
        entries, negating possible benefits from having pre-computed
        CFT-IRT entries.
     
        CFT-IRT entries should also include VLAN identification
        information relative to each set of ingress RBridge, to allow
        scoping of broadcast, multicast and flooding forwarding by
        configured VLANs.
     
        How the CFT-IRT is maintained will be defined in appropriate
        protocol specifications used to instantiate this architecture.
        The protocol specification needs to include mechanisms and
        procedures required to establish and maintain the CFT-IRT in
        consideration of potential SPF recomputations resulting from
        network topology changes.
     
     3.4. CTT
     
        The CTT determines how arriving traffic will be encapsulated,
        for forwarding to the egress RBridge, via the RBridge Campus.
        The CTT can be considered a version of the LPT that operates
        across the RBridge campus as a whole. It becomes configured in
        much the same way as the LPT: by snooping incoming traffic, and
        assuming bi-directional consistency (see Section 4.7.2). The
        information is learned at the egress RBridge and propagated to
        all other RBridges in the campus via the RBridge routing
        protocol (also Section 4.7.2). The CTT may be populated on-
        demand or a-priori, and may be as large as the number of nodes
        on the Ethernet subnet, across all VLANs. RBridges may have
        separate CTTs for each VLAN, if separate VLANs are supported by
        manual configuration.
     
     4. Functional Description
     
        The design of an RBridge is largely defined by its behavior; the
        physical components are minimal, as outlined in Section 3.
     
     4.1. RBridge Campus Auto-configuration
     
        Cooperating RBridges self-organize to compose a single RBridge
        campus system. Consider first a set of bridges on a single
        Ethernet link subnet (Figure 1). Here bridges are shown as 'b',
        hubs as 'h', and nodes as 'N'; bridges and hubs are numbered.
        Note that the figure does not distinguish between types of
        nodes, i.e., hosts and routers; both are just nodes at the link
        layer, and are otherwise indistinguishable. The bridges organize
        into a single spanning tree, as shown by double lines ('=',
        '||', and '//') in the figure.
     
     
     Gray                     Expires August, 2006             [Page 13]


     Internet-Draft           RBridge Architecture         February 2006
     
     
                                  N       N---b3---N
                                  |           ||
                                  |           ||
                             N---h1--b4===b5==h2==b6
                                     |   //   |   ||
                                     |  //    N   ||
                                     | //         ||
                                 N---b7====b8-----b9-----N
                                           |      |\
                                           |      | \
                                           N      N  N
     
             Figure 1 Conventionally bridged Ethernet link subnet
     
        It is useful to note that hubs are relatively transparent to
        bridges, both for traffic from nodes to bridges (h1) and for
        traffic between bridges (h2). Also note that the same hub can
        support traffic between bridges and from a host to a bridge
        (h2), but that the spanning tree is exclusively between bridges.
        Bridges are thus compatible with hubs, both as transits and
        ingress/egress.
     
        An RBridge campus operates similarly, and can be viewed as a
        variant of the way bridges self-organize. Figure 2 shows the
        same topology where some of the RBridges are replaced by
        RBridges. In this figure, stars ('*') represent the paths the
        RBridge is capable of utilizing, due to the use of link state
        routing. Rbridges can tunnel directly to each other (r4-r5), or
        through hubs (h2) or bridges (b8).
     
                                  N       N---b3---N
                                  |           ||
                                  |           ||
                             N---h1--r4***r5**h2**r6
                                     *   *    |   *
                                     *  *     N   *
                                     * *          *
                                 N---r7****b8*****r9-----N
                                           |      |\
                                           |      | \
                                           N      N  N
     
                    Figure 2 RBridged Ethernet link subnet
     
        Every node in an RBridge is considered to have a primary point
        of attachment to the RBridge campus, as defined by the
        designated RBridge. Each Ethernet link segment attached to an
     
     
     Gray                     Expires August, 2006             [Page 14]


     Internet-Draft           RBridge Architecture         February 2006
     
     
        RBridge campus has a single designated RBridge; that RBridge is
        where all traffic that transits the RBridge enters and exits. In
        Figure 2, it is easy to see that the nodes off of h1 must attach
        at r4; the nodes off of b3, however, attach at either r5 or r6,
        depending on which is the designated RBridge.
     
        Without loss of generality, an RBridge topology can be
        reorganized (ignoring link length) such that all nodes, hubs,
        and bridges are arranged around the periphery, and all RBridges
        are considered directly connected by their tunnels (Figure 3).
        Note that this view ignores the ways in which hubs and bridges
        may serve both on the ingress/egress and for transit, hence this
        view is not useful for traffic analysis. Using this view, it is
        easy to distinguish between RBridge to RBridge traffic and other
        traffic on shared devices, such as h2 and b8, because RBridge to
        RBridge traffic content is hidden from non RBridge devices by
        the RBridge encapsulation.
     
                                  N       N---b3---N
                                  |           ||
                                  |           ||
                                  |           h2
                                  |          /| \
                                  |         / N  \
                                  |        /      \
                             N---h1--r4***r5******r6
                                     *   *        *
                                     *  *         *
                                     * *          *
                                 N---r7***********r9-----N
                                      \          /|\
                                       \        / | \
                                        \      /  N  N
                                         \    /
                                          \  /
                                           b8
                                           |
                                           N
     
               Figure 3 Reorganized RBridge Ethernet link subnet
     
     4.2. RBridge Peer Discovery
     
        Proper operation of the TRILL solution using RBridges depends on
        the existence of a mechanism for discovering peer RBridges and
        the RBridge topology. An accurate determination of RBridge
        topology is required in order to determine how traffic frames
     
     
     Gray                     Expires August, 2006             [Page 15]


     Internet-Draft           RBridge Architecture         February 2006
     
     
        will flow in the topology and thus avoid the establishment of
        persistent loops in frame forwarding.
     
        The discovery mechanisms must use protocol messages which will
        be propagated throughout the LAN, or broadcast domain, in order
        to ensure that all RBridges in the same broadcast domain are
        discovered and to allow for accurate determination of RBridge
        topology.
     
        These protocol messages should be distinguished in a manner that
        is consistent with the chosen RBridge routing protocol, or any
        other discovery mechanism used. An RBridge intercepts protocol
        messages that it recognizes as being of this type, performs any
        processing required and forwards these messages as required by
        the discovery protocol. For example, a receiving RBridge may
        first determine if it has seen this message before and insert
        itself in a list of RBridges traversed by this message prior to
        forwarding the message on at least all interfaces other than the
        one on which it was received.
     
        Note that forwarding the modified message on all interfaces in
        the example above is safe, if somewhat wasteful.
     
        RBridges must forward all other protocol messages in a manner
        consistent with L2 addressing and forwarding - as would be done
        by a typical 802.1D bridge. This includes any frames of the same
        type that are - for one reason or another - not recognized by
        the receiving RBridge.
     
        Note that forwarding unrecognized messages - even when of the
        same type - has the effect of providing some degree of
        robustness in the solution against configuration errors and
        against future variations of the discovery protocol.
     
        Handling of 802.1D BPDUs is as determined in section 4.8.2.
     
     4.3. Tunneling
     
        Rbridges pass encapsulated frame traffic to each other
        effectively using tunnels. These tunnels use an Ethernet link
        layer header, together with a shim header; it is the combination
        of these headers that distinguishes RBridge to RBridge traffic
        from other traffic. The link header includes source and
        destination addresses, which typically identify the ingress and
        egress RBridges. For incoming multicast and broadcast traffic,
        one of these addresses may represent the multicast group or
        broadcast address. Additionally, these addresses may be VLAN-
     
     
     Gray                     Expires August, 2006             [Page 16]


     Internet-Draft           RBridge Architecture         February 2006
     
     
        specific, i.e., such that each ingress and egress address have
        per-VLAN addresses.
     
        If using hop-by-hop frame forwarding, the destination MAC
        address is determined as the next-hop RBridge. Typically, the
        enclosed shim header will not change. An exception would be if
        the egress RBridge has changed for a frame while in transit
        within the campus.
     
        The additional shim header is required to support loop
        prevention for traffic within the RBridge campus; traffic loops
        in forwarding between RBridges and non-RBridge nodes, as well as
        across non-RBridge devices between RBridges, is prevented by
        loop prevention mechanisms that are beyond the scope of this
        document (but typically include STP or RSTP) on the applicable
        LAN segments.
     
        In addition, the shim header and encapsulation:
     
        o  must clearly identify the traffic as RBridge traffic - the
           outer Ethernet header may, for instance, use a protocol
           number unique to RBridges;
     
        o  should also identify a specific (egress) RBridge - the shim
           header may, for example, include an identifier unique to the
           egress RBridge;
     
        o  should include the RBridge transit route, a hopcount, or a
           timestamp to prevent indefinite looping of a frame.
     
     4.4. RBridge General Operation
     
        Operations that apply to all RBridges include peer and topology
        discovery (which may include negotiation of RBridge
        identifiers), designated RBridge election, link-state routing,
        SPF computation and advertising reach-ability for specific L2
        (MAC Ethernet destination) addresses within a broadcast domain.
     
        In addition, all RBridges will compute Ingress RBridge Trees for
        delivery of (potentially VLAN-scoped) broadcast, multicast and
        flooded frames to each peer RBridge. Setting up these trees
        early is important as there is otherwise no means for frame
        delivery across the RBridge campus during the learning phase.
        Because it is very likely to be impossible (at an early stage)
        for RBridges to determine which RBridges are edge RBridges, it
        is preferable that each RBridge compute these trees for all
     
     
     
     Gray                     Expires August, 2006             [Page 17]


     Internet-Draft           RBridge Architecture         February 2006
     
     
        RBridges as early as possible - even if some entries will not be
        used.
     
        The initial phase is the peer and topology discovery phase. This
        should continue for a sufficient amount of time to reduce the
        amount of re-negotiation (designated RBridge and - possibly -
        identifiers) and re-computation that will be triggered by
        discovery of new peers. The time values selected for delaying
        the next phase should take into account the time required for
        local STP and availability of segment connectivity between
        RBridge peers.
     
        The next phase is negotiation of designated RBridges for all
        shared access segments. This phase cannot complete before
        completion of peer and topology discovery. In parallel, RBridge
        routing protocol should begin the process of building the LSDB -
        assuming this was not done during the peer and topology
        discovery phase.
     
        It is at about this time that RBridges should start the process
        of establishing one or more ingress RBridge trees. If the
        discovery process has resulted in determination that a
        designated RBridge election will be required for all segments
        that any specific RBridge is connected to, that RBridge may
        delay setup of its Ingress RBridge Tree(s) pending the results
        of those elections. This is not required and will result in
        saving time only if that specific RBridge loses all elections
        (or all elections associated with a given VLAN).
     
        Once RBridges have established Ingress RBridge Trees, the
        learning and forwarding phase may begin. In this phase, RBridges
        initially forward frames by flooding them via Ingress RBridge
        Tree(s). Also during this phase, RBridges begin "learning" MAC
        address locations from local segments and propagating L2 reach-
        ability information via the RBridge routing protocol to all
        other RBridges.  Gradually, the CFT will be built up for all
        RBridges, and fewer frames will require flooding via the Ingress
        RBridge Tree(s).
     
        The learning phase typically does not complete. Consequently,
        the learning phase is also the operational phase. During the
        combined learning and operational phase, all RBridges maintain
        both an Ingress RBridge Tree and a CFT. RBridges not elected as
        designated RBridge may be required to become one in the event
        that the DR goes off-line.
     
     
     
     
     Gray                     Expires August, 2006             [Page 18]


     Internet-Draft           RBridge Architecture         February 2006
     
     
     4.5. Ingress/Egress Operations
     
        Operation specific to edge RBridges involves RBridge learning,
        advertisement, encapsulation (at ingress RBridges) and
        decapsulation (at egress RBridges).
     
        As described elsewhere, RBridge learning is similar to typical
        bridge learning - i.e. - all RBridges listen promiscuously to L2
        Frames on a local LAN segment and acquire location information
        associated with source MAC addresses in L2 frames they observe.
     
        In instances where more than one RBridge is connected to the
        same local LAN segment, only the designated RBridge performs
        RBridge learning for interface(s) connected to that segment.
     
        Except in the case where a designated RBridge exists, all
        RBridges participate in this learning activity as it is
        primarily by way of this activity that an RBridge can determine
        it is an edge RBridge. In addition, each RBridge (except where a
        designated RBridge exists) is expected to forward frames it
        receives in a manner essentially the same as it would if it were
        an 802.1D bridge.
     
        As each RBridge learns segment-local MAC source addresses, it
        creates an entry in its reachability table that associates that
        MAC source address with the interface on which it was learned.
        Periodically, as determined by the RBridge routing protocol,
        each RBridge advertises this learned information to its RBridge
        peers.
     
        These advertisements propagate to all edge RBridges (as
        potentially scoped by associated VLAN information for each
        advertisement). Each edge RBridge incorporates this information
        in the form of a CFT entry. Other RBridges may create such
        entries as well, either in anticipation of subsequent discovery
        that they are an edge RBridge, or in support of hop-by-hop frame
        forwarding.
     
        RBridges also discover that they are an edge RBridge as a result
        of receiving un-encapsulated frames that require forwarding.
        Assuming that an RBridge is the designated - or only - RBridge
        for a segment, and that it has not previously learned that the
        MAC destination for a frame is local (this will be the case -
        for instance - for the very first frame it observes), then the
        RBridge would be required to forward (or flood) the frame via
        the RBridge campus.
     
     
     
     Gray                     Expires August, 2006             [Page 19]


     Internet-Draft           RBridge Architecture         February 2006
     
     
        The RBridge in this case would flood the frame unless it has
        already created a CFT entry for the frame's MAC destination
        address.  If it has a corresponding CFT, then it would use that.
        This RBridge would be an ingress RBridge with respect to the
        frame being forwarded.
     
        The encapsulation used by this ingress RBridge would be
        determined by the CFT - if one exists -  or the CFT-equivalent
        entry for the Ingress RBridge Tree. The encapsulation - as
        discussed elsewhere - should include (in the shim header)
        information to identify the egress RBridge (for example, the
        RBridge identifier negotiated previously during the peer and
        topology discovery phase).
     
        When the encapsulated frame arrives at egress RBridge(s), it is
        decapsulated and forwarded via the egress interface(s) onto the
        local segment.
     
        Note that an egress RBridge will be either the designated - or
        only - RBridge on the local segment accessed via its egress
        interface(s). If the received frame does not correspond to a
        learned MAC destination address at an egress interface, it will
        forward the frame on all interfaces for which it is either the
        designated - or only - RBridge. If the received frame does
        correspond to a learned MAC destination address at an egress
        interface, the RBridge will forward the frame via that interface
        only.
     
     4.6. Transit Forwarding Operations
     
        There are two possible models for transit forwarding within an
        RBridge campus: edge-to-edge and hop-by-hop.  The difference
        between the two is in how the encapsulation is determined when
        the flow of RBridge encapsulated frames from an ingress RBridge
        to an egress RBridges includes one or more transit RBridges.
        Exactly one of these models will be selected - in any
        instantiation of this architecture- for each of the following
        forwarding modes:
     
        o  Unicast frame forwarding
        o  Forwarding of non-unicast frames
           o  Broadcast frame forwarding
           o  Multicast frame forwarding
           o  Frame flooding
     
     
     
     
     
     Gray                     Expires August, 2006             [Page 20]


     Internet-Draft           RBridge Architecture         February 2006
     
     
     4.6.1. Unicast
     
        Edge to edge:
     
        In edge to edge unicast forwarding, both the MAC destination in
        the outer Ethernet encapsulation and the shim header are
        specific to the egress RBridge associated with the unicast MAC
        destination address of the inner Ethernet header.
     
        Hop by hop:
     
        In hop by hop unicast forwarding, the shim header is specific to
        the egress RBridge and the MAC destination in the outer Ethernet
        encapsulation is specific to the next hop RBridge.
     
        Prior to preparing the frame for forwarding to the next hop
        RBridge, the MAC source address is examined and - if the MAC
        source address is an address of the local RBridge, the frame is
        discarded.
     
        As the frame is prepared for transmission at each RBridge, the
        next hop MAC destination information is determined at that
        RBridge based on the corresponding CFT for the destination MAC
        address of the inner Ethernet header (exactly as if this RBridge
        were the ingress RBridge for this frame).  In addition, prior to
        re-writing the outer MAC destination address, the next hop MAC
        destination address is compared to the MAC source address of the
        outer Ethernet header and the frame is discarded if the two are
        equivalent.
     
        Comparison between the approaches in the Unicast case:
     
        The edge to edge approach is simplest from a unicast forwarding
        perspective, however it is not generally consistent with the
        routing paradigm. Using this approach frames will not loop
        within the campus because the outer Ethernet encapsulation will
        ensure that the frame is forwarded consistently toward the
        determined egress RBridge until it arrives there. There could be
        potential efficiency issues - and potentially looping traffic -
        if a MAC destination node moves from one egress to another.
     
        The hop by hop approach uses more complex frame handling, but is
        also more consistent with the routing paradigm. Also, it is
        inconsistent with bridge forwarding in that it changes the MAC
        destination address in the outer encapsulation at each hop, and
        inconsistent with router forwarding in that it does not change
        the MAC source address at each hop.
     
     
     Gray                     Expires August, 2006             [Page 21]


     Internet-Draft           RBridge Architecture         February 2006
     
     
        Better efficiencies may be achieved as a result of the fact that
        the path followed by a frame may change while the frame is still
        in transit within the RBridge campus. However this may also
        result in transient looping of unicast frames within the campus
        as well.
     
     4.6.2. Broadcast, Multicast and Flooding
     
        Ingress RBridge Trees are used for forwarding of broadcast,
        multicast and unknown destination frames across the RBridge
        campus. In a simple implementation, it is possible to use the
        CFT-IRT entries for all frames of these types.
     
        However, this approach results in potentially extreme
        inefficiencies in the multicast and unknown destination flooding
        cases.
     
        As a consequence, instantiations of this architecture should
        allow for local optimizations on a hop by hop basis.
     
        Examples of such optimizations are included in the sections
        below.
     
     4.6.2.1. Broadcast
     
        The path followed in transit forwarding of broadcast frames will
        have been established through actions initiated by each RBridge
        (as any RBridge is eligible to subsequently become an ingress
        RBridge) in the process of computing CFT-IRT entries. Each
        RBridge assumes that it may be a transit as well as an ingress
        and egress RBridge and will establish forwarding information
        relative to itself and each of its peer RBridges, and stored in
        the CFT-IRT. CFT-IRT entries are computed at each RBridge for
        paths going toward all other RBridges - at least in cases where
        the RBridge performing CFT-IRT computations is on the shortest
        path.
     
        Forwarding information is in two forms: transit encapsulation
        information for interfaces over which the RBridge will forward a
        broadcast frame to one or more peer RBridges and a decapsulation
        indication for each interface over which the RBridge may egress
        frames from the campus. In each case, the CFT-IRT includes some
        identification of the interface on which a frame is forwarded
        toward any specific egress RBridge for frames received from any
        specific ingress RBridge.
     
     
     
     
     Gray                     Expires August, 2006             [Page 22]


     Internet-Draft           RBridge Architecture         February 2006
     
     
        Note that an interface over which an RBridge may egress frames
        is any interface for which the RBridge is the designated, or
        only, RBridge. RBridges must not wait to determine that one (or
        more) non-RBridge Ethernet nodes is present in an interface
        before deciding to forward decapsulated broadcast frames on that
        interface.
     
        Forwarding information is selected for each broadcast frame
        received by any RBridge (based on identifying the ingress
        RBridge for the frame) for all corresponding CFT-IRT entries.
        Each RBridge is thus required to replicate one RBridge
        encapsulated broadcast frame for each interface that is
        determined from CFT-IRT entries corresponding to the frames
        ingress RBridge. This includes decapsulated broadcast frames for
        each interface for which it is the designated (or only) RBridge.
     
        Note that frame replication and forwarding should be scoped by
        VLAN if VLAN support is provided. Also note that a designated
        RBridge (DR) may be required to transmit a decapsulated frame on
        the interface on which it received the RBridge encapsulated
        frame.
     
        This hop by hop approach for broadcast forwarding might be
        considered to add complexity because replication occurs at all
        RBridges along the ingress RBridge tree, potentially for both
        RBridge encapsulated and decapsulated broadcast frames. However,
        the replication process is similar to replication of broadcast
        traffic in 802.1D bridges with the exception that additional
        replication may be required at each interface for egress from
        the RBridge campus.
     
        Note that the additional replication associated with campus
        egress may be made to exactly conform to 802.1D bridge broadcast
        replication in implementations that model a campus egress as a
        separate logical interface.
     
        Using this approach results in one and only one copy of the
        broadcast frame being delivered to each egress RBridge.
     
     4.6.2.2. Multicast
     
        Multicast forwarding is reducible to broadcast forwarding in the
        simplest (default) case. However implementations may choose -
        using mechanisms that are out of scope for this document - to
        optimize multicast forwarding. In order for this to work
        effectively, however, hop by hop frame header evaluation is
        required.
     
     
     Gray                     Expires August, 2006             [Page 23]


     Internet-Draft           RBridge Architecture         February 2006
     
     
        Without optimization, multicast frames are injected by the
        ingress RBridge onto an IRT by - for instance - encapsulating
        the frame with a MAC destination multicast address, and
        forwarding it according to its local CFT-IRT. Without
        optimization, each RBridge along the path toward all egress
        RBridges will similarly forward the frame according to their
        local CFT-IRT.
     
        Using this approach results in one and only one copy of the
        multicast frame being delivered to appropriate egress RBridges.
     
        In any optimization approach, RBridge encapsulated multicast
        frames will use either a broadcast or a group MAC destination
        address. In either case, the recognizably distinct destination
        addressing allows a frame forwarding decision to be made at each
        RBridge hop. RBridges may thus be able to take advantage of
        local knowledge of multicast distribution requirements to
        eliminate the forwarding requirement on interfaces for which
        there is no recipient interested in receiving frames associated
        with any specific group address.
     
        Note that, because the multicast optimization would - in
        principle - further scope and reduce broadcast traffic, two
        things may be said:
     
        o  It is not necessary that all implementations in a deployment
           support the optimization in order for any local multicast
           optimization (consistent with the above description) to work
           (hence such an optimization is optional);
        o  Introduction of a multicast optimization will not result in
           potential forwarding loops where broadcast forwarding would
           not do so.
     
        In the simplest case, the ingress RBridge for a given multicast
        frame will re-use the MAC destination group address of a
        received multicast frame.  However this may not be required as
        it is possible that the mechanisms specified to support
        multicast will require examination of the decapsulated MAC
        destination group address at each RBridge that implements the
        optimization.
     
     4.6.2.3. Flooding
     
        Flooding is similarly reducible to broadcast forwarding in the
        simplest (default) case - with the exception that a frame being
        flooded across the RBridge campus is typically a unicast frame
        for which no CFT exists at the ingress RBridge. This is not a
     
     
     Gray                     Expires August, 2006             [Page 24]


     Internet-Draft           RBridge Architecture         February 2006
     
     
        minor distinction, however, because it impacts the way that
        addressing may be used to accomplish flooding within the RBridge
        campus.
     
        An ingress RBridge that does not have a CFT entry for a received
        frame MAC destination address, will inject the frame onto the
        ingress RBridge Tree by - for instance - encapsulating the frame
        with a MAC destination broadcast address, and forwarding it
        according to its local CFT-IRT. Without optimization, each
        RBridge along the path toward all egress RBridges will similarly
        forward the frame according to their local CFT-IRT.
     
        Using this approach results in one and only one copy of the
        flooded frame being delivered to all egress RBridges.
     
        However implementations may choose to optimize flooding. A
        Flooding optimization will only work at any specific RBridge if
        that RBridge re-evaluates the original (decapsulated) unicast
        frame.
     
        Any flooding optimization would operate similarly to the
        multicast optimization described above, except that - instead of
        requiring local information about multicast distribution - each
        RBridge implementing the optimization will need only to lookup
        the MAC destination address of the original (decapsulated) frame
        in its local CFT. If an entry is found, the frame could then be
        forwarded only if the specific RBridge is on the shortest path
        between the originating ingress RBridge and the appropriate
        egress RBridge.  This could be implemented - for example - as a
        specialized CFT-IRT entry.
     
        Note that, because the flooding optimization would - in
        principle - further scope and reduce flooded traffic, two things
        may be said:
     
        o  It is not necessary that all implementations in a deployment
           support the optimization in order for any local flooding
           optimization (consistent with the above description) to work
           (hence such an optimization is optional);
        o  Introduction of the flooding optimization will not result in
           potential forwarding loops where flooded forwarding would not
           do so.
     
        Because a forwarding decision can be made at each hop, it is
        possible to terminate flooding early if a CFT for the original
        MAC destination was in the process of being propagated when
     
     
     
     Gray                     Expires August, 2006             [Page 25]


     Internet-Draft           RBridge Architecture         February 2006
     
     
        flooding for the frame was started.  It is therefore possible to
        reduce the amount of flooding to some degree in this case.
     
     4.7. Routing Protocol Operation
     
        The details of routing protocol operation can be determined once
        a specific routing protocol has been selected.
     
     4.7.1. Determining CFT
     
        Specifics of mechanisms for initially determining, and
        subsequently maintaining, CFT entries are dependent on the
        routing protocol used.
     
        CFT contents and use should be consistent with section 3.2, and
        4.6.1 above.
     
     4.7.2. Determing CFT-IRT
     
        Specifics of mechanisms for initially determining, and
        subsequently maintaining, CFT-IRT entries are dependent on
        routing protocol use.
     
        CFT-IRT contents and use should be consistent with section 3.3,
        and 4.6.2 above.
     
     4.7.3. Determining CTT
     
        CTT contents should be exceptional, and require configuration.
        Typically, encapsulation would be explicitly defined in protocol
        instantiations of this architecture but may be modified by - for
        example - VLAN configuration, or Ethernet media changes.
     
     4.8. Other Bridging and Ethernet Protocol Operations
     
        In defining this architecture, several interaction models have
        been considered for protocol interaction between RBridges and
        other L2 forwarding devices - in particular, 802.1D bridges.
        Whatever model we adopt for these interactions must allow for
        the possibility of other types of L2 forwarding devices. Hence,
        a minimal participation model is most likely to be successful
        over the long term, assuming that RBridges are used in a L2
        topology that would be functional if RBridges were replaced by
        other types of L2 forwarding devices.
     
        Toward this end, RBridges - and the RBridge campus as a whole -
        may participate in Ethernet link protocols, notably the spanning
     
     
     Gray                     Expires August, 2006             [Page 26]


     Internet-Draft           RBridge Architecture         February 2006
     
     
        tree protocol (STP) on the ingress/egress links using exactly
        one of the following interaction models:
     
        o  Transparent Participation (Transparent-STP)
        o  Active Participation (Participate-STP)
        o  Blocking Participation (Block-STP)
     
        Only one of these variants would be supported by an instance of
        this architecture. All RBridges within a single campus must use
        the same model for interacting with non-RBridge protocols.
        Furthermore, it is the explicit intent that only one of these
        models is ultimately supported - at least as a default mode of
        compliant implementations.
     
     4.8.1. Outgoing BPDU Interactions
     
        All three approaches describe reactions of an RBridge campus to
        incoming BPDUs, but do not preclude preemptive emission, by
        RBridges, of BPDUs to the segments external to the RBridge
        campus. Such BPDUs might indicate that the a Designated RBridge
        is to become the root of its corresponding segment's spanning
        tree, which may be necessary for proper - or efficient - overall
        operation.
     
        This architecture adopts the following model for this type of
        interaction: the logical RBridge component does not itself
        initiate STP BPDUs, however an implementation may use one (or
        more) co-located 802.1D bridge instance(s) to do this. In this
        way, discussion of how - or when - to originate STP BPDUs is out
        of scope for this document.
     
     4.8.2. Incoming BPDU Interactions
     
        RBridges, and an RBridge campus, may interact with received
        BPDUs using exactly one of the following interaction models:
     
        o  Transparent Participation (Transparent-STP)
        o  Active Participation (Participate-STP)
        o  Blocking Participation (Block-STP)
     
        The first of these, Transparent-STP, causes the entire RBridge
        campus to appear as an 802 transparent device (e.g. - a Hub).
        Loops are prevented, among non-RBridge nodes, by mechanisms
        beyond the scope of this document, however this would typically
        be via the operation of STP between 802.1D bridges connected to
        the RBridge campus.
     
     
     
     Gray                     Expires August, 2006             [Page 27]


     Internet-Draft           RBridge Architecture         February 2006
     
     
        The second, causes the RBridge campus to emulate the behavior of
        802.1D bridges and corresponding direct replacement devices. In
        this case, the effect is to have the RBridge campus - as a whole
        - behave as a single 802.1D bridge. Loops are prevented, among
        non-RBridge nodes, by the operation of 802.1D STP.
     
        In the third variant, Block-STP, the campus appears transparent
        to non-RBridge devices - precisely as if all Ethernet nodes
        connected to any segment via one or more RBridges, were directly
        attached to that segment. Loops are prevented by the combined
        operation of link-state routing protocol between RBridges and
        mechanisms beyond the scope of this document (typically via STP
        operation between 802.1D bridges).
     
     4.8.2.1.Transparent-STP
     
        An RBridge campus could broadcast spanning tree messages (BPDUs)
        arriving at designated RBridges within the RBridge campus,
        emitting one copy on each egress link. Such an RBridge campus is
        said to support "Transparent-STP", and that Campus would
        effectively emulate a hub network connected to each link at the
        designated RBridge. Because hubs are compatible with bridges
        running STP, a transparent-STP campus may be similarly
        compatible.
     
        Transparent-STP would reduce the complexity of the spanning tree
        in an Ethernet link subnet because RBridges would not
        participate in the spanning tree protocol. It still would
        require BPDUs to be broadcast throughout the RBridge campus,
        which can cause spanning tree protocol to be delayed until the
        RBridge Campus is configured. The cost of these broadcasts can
        be reduced by use of an efficient RBridge routing protocol
        (e.g., supporting broadcast), but the cost is higher than in
        unicast (e.g., Participate-STP) and blocking (e.g., Block-STP)
        schemes.
     
        This approach may be further complicated by the possibility that
        links/segments connecting RBridges may include 802.1D bridges in
        a configuration requiring STP operation. In this case, either
        the BDPUs issued outside of the campus are propagated into the
        campus - and vice-versa - or BPDUs issued outside of the campus
        are tunneled from the receiving edge RBridge to all other
        RBridges for propagation into additional 802.1D segments.
     
        This approach has been considered and is not recommended because
        of the fact that it complicates STP interactions on the whole,
        and can potentially result in significant inefficiencies in
     
     
     Gray                     Expires August, 2006             [Page 28]


     Internet-Draft           RBridge Architecture         February 2006
     
     
        forwarding across the RBridge campus as a result of STP port
        blocking activity.
     
     4.8.2.2. Participate-STP
     
        An RBridge campus may interpret BPDUs received at its edge
        RBridges and emit new BPDUs at other RBridges to reflect
        connectivity within the RBridge campus. In this case, the
        "spanning tree" within the RBridge campus consists of tunnels
        connecting edge RBridges. In order to keep the interactions with
        802.1D bridges manageable, it is necessary for the entire campus
        to appear as a single multi-port bridge to all 802.1D bridges in
        the broadcast domain.
     
        An RBridge campus is expected to have the equivalent of one or
        more spanning trees within the RBridge campus (e.g. - to use for
        broadcast traffic) but these trees are computed by RBridge
        routing protocol rather than STP. These trees are referred to as
        Ingress RBridge Trees.  Participate-STP would cause the spanning
        tree(s) within the RBridge campus to be spliced to the spanning
        trees on segments external to the RBridge campus, in the form of
        a single 802.1D bridge.
     
        A participate-STP Campus would emulate a single bridge device,
        just as transparent-STP would emulate a single hub device or
        network.
     
        Participate-STP is similarly compatible with existing bridges
        and hubs, although the resulting Ethernet subnet spanning tree
        may be different. As with transparent-STP, the benefit to
        spanning tree scalability lies in the (presumably) more
        efficient and stable computation of the RBridge campus
        forwarding paths using the RBridge routing protocol. Here too,
        spanning tree protocol is affected by waiting for path
        computation within the RBridge campus.
     
        In this case, there are concerns about the 'chicken and egg'
        problem; spanning tree protocol needs to complete before links
        between RBridges can transit traffic, notably traffic between
        RBridges used to exchange the RBridge routing protocol. This
        case must be addressed in the protocol if this variant is
        selected.
     
        This approach has also been considered and is not recommended
        because it complicates STP interactions on the whole, is
        expected to have a significant impact on time required to
        establish an extended spanning tree, and can potentially result
     
     
     Gray                     Expires August, 2006             [Page 29]


     Internet-Draft           RBridge Architecture         February 2006
     
     
        in some inefficiencies in forwarding across the RBridge campus
        as a result of STP port blocking activity.
     
     4.8.2.3. Block-STP
     
        An bridge campus may completely block STP BPDUs that are
        received at any RBridge. Using this approach is a departure from
        the existing models for interactions in an 802.1D Ethernet
        broadcast domain.
     
        However, this approach has some significant advantages in terms
        of reducing the impact of extended spanning trees on over-all
        STP resolution time.  The reason for this is that - by blocking
        STP BPDUs - RBridges (and the RBridge campus) effectively
        partition the domain spanning tree into a number of smaller
        spanning trees connected by a RBridge campus.
     
        The Connections via the RBridge campus are free of persistent
        loops as a result of RBridge peer and topology discovery
        mechanisms working in conjucntion with an RBridge (link-state)
        routing protocol. This peer discovery mechanism ensures that
        RBridges become aware of all of the paths connecting them to
        other RBridges, and the RBridge routing protocol ensures that
        non-looping paths are established for frame forwarding across
        RBridge-to-RBridge connection.  The net effect is to ensure that
        persistent loops in frame forwarding do not occur - either
        between RBridges, or between RBridges and other Ethernet nodes.
     
     5. How RBridges Address TRILL
     
        This section is for further study, after determining the set of
        TRILL requirements that this architecture document is expected
        to address.
     
     6. Conclusions
     
        This document discusses options considered and factors affecting
        any protocol specific choices that may be made in instantiating
        the TRILL architecture using RBridges.
     
        Specific architectural and protocol instantiations should take
        these into consideration. In particular, protocol, encapsulation
        and procedure specifications should allow for potential
        optimizations described in the architectural document to the
        maximum extent possible.
     
     
     
     
     Gray                     Expires August, 2006             [Page 30]


     Internet-Draft           RBridge Architecture         February 2006
     
     
        Also, this document addresses considerations relative to
        interaction with existing technology and "future-proofing"
        solutions.  For both simplicity in description, and robust long
        term implementation of the technology, this document recommends
        the use of clear distinction - at all possible points - of
        definitions, protocols, procedures, etc. from related (but not
        identical) specifications and interactions.
     
        In particular, this document recommends the use of a "colocation
        model" in addressing issues with combining RBridge, Router and
        802.1D bridge behavior.
     
     7. Security Considerations
     
        As one stated requirement of this architecture is the need to be
        able to provide an L2 delivery mechanism that is potentially
        configuration free, the default operation mode for instances of
        this architecture should assume a trust model that does not
        require configuration of security information. This is - in fact
        - an identical trust model to that used by Ethernet devices in
        general.
     
        In consequence, the default mode does not require - but also
        does not preclude - the use of established security mechanisms
        associated with the existing protocols that may be extended or
        enhanced to satisfy this document's architectural definitions.
     
        In general, this architecture suggest the use of a link-state
        routing protocol - modified as required to support L2 reach-
        ability and link state between RBridges. Any mechanisms defined
        to support secure protocol exchanges between link-state routing
        peers may be extended to support this architecture as well.
     
        This architecture also suggests use of additional encapsulation
        mechanisms and - to the extent that any proposed mechanism may
        include (or be extended to include) secure transmission - it may
        be desirable to provide such (optional) extensions.
     
        To the extent possible, any extensions of protocol or
        encapsulation should allow for at least one mode of operation
        that doesn't require configuration - if necessary, for limited
        use in a physically secure deployment.
     
     8.IANA Considerations
     
        This document has no direct IANA considerations. It does
        suggest, that protocols that instantiate the architecture use a
     
     
     Gray                     Expires August, 2006             [Page 31]


     Internet-Draft           RBridge Architecture         February 2006
     
     
        shim header as a wrapper on the payload for RBridge to RBridge
        traffic, And this shim header may be identified by a new
        protocol type in the tunneled Ethernet link header. This
        protocol type, identified in an 802 header, would be allocated
        by the IEEE in cooperation with IANA.
     
     9.Acknowledgments
     
        The initial work for this document was largely done by Joe
        Touch, based on work he and Radia Perlman completed earlier.
        Subsequent changes are not to be blamed on them.
     
     9.1. Normative References
     
        [1]   Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.
     
     9.2. Informative References
     
        [2]   Perlman, R., "RBridges: Transparent Routing", Proc.
              Infocom 2005, March 2004.
     
        [3]   Touch, J., (ed.) "Transparent Interconnection of Lots of
              Links (TRILL): Problem and Applicability Statement", work
              in progress, draft-touch-trill-prob-00.txt, Nov. 17, 2005.
     
        [4]   Perlman, R., "RBridges: Base Protocol Specification", work
              in progress, draft-perlman-rbridge-06.txt, January, 2006.
     
        [5]   Postel, J., "INTERNET PROTOCOL", RFC 791, September, 1981.
     
        [6]   802.1D-2004 IEEE Standard for Local and Metropolitan Area
              Networks: Media Access Control (MAC) Bridges
     
     Author's Addresses
     
        Editor:
     
        Eric Gray
        Ericsson
        900 Chelmsford Street
        Lowell, MA, 01851
        Phone: +1 (978) 275-7470
        EMail: Eric.Gray@Ericsson.com
     
     
     
     
     
     Gray                     Expires August, 2006             [Page 32]


     Internet-Draft           RBridge Architecture         February 2006
     
     
     
        Contributors:
     
        Joe Touch
        USC/ISI
        4676 Admiralty Way
        Marina del Rey, CA 90292-6695, U.S.A.
        Phone: +1 (310) 448-9151
        EMail: touch@isi.edu
        URL:   http://www.isi.edu/touch
     
        Radia Perlman
        Sun Microsystems
     
        EMail: Radia.Perlman@sun.com
     
     
     Intellectual Property Statement
     
        The IETF takes no position regarding the validity or scope of
        any Intellectual Property Rights or other rights that might be
        claimed to pertain to the implementation or use of the
        technology described in this document or the extent to which any
        license under such rights might or might not be available; nor
        does it represent that it has made any independent effort to
        identify any such rights.  Information on the procedures with
        respect to rights in RFC documents can be found in BCP 78 and
        BCP 79.
     
        Copies of IPR disclosures made to the IETF Secretariat and any
        assurances of licenses to be made available, or the result of an
        attempt made to obtain a general license or permission for the
        use of such proprietary rights by implementers or users of this
        specification can be obtained from the IETF on-line IPR
        repository at http://www.ietf.org/ipr.
     
        The IETF invites any interested party to bring to its attention
        any copyrights, patents or patent applications, or other
        proprietary rights that may cover technology that may be
        required to implement this standard.  Please address the
        information to the IETF at ietf-ipr@ietf.org.
     
     Disclaimer of Validity
     
        This document and the information contained herein are provided
        on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
        REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
     
     
     Gray                     Expires August, 2006             [Page 33]


     Internet-Draft           RBridge Architecture         February 2006
     
     
        THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
        EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY
        THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
        RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
        FOR A PARTICULAR PURPOSE.
     
     Copyright Statement
     
        Copyright (C) The Internet Society (2006).
     
        This document is subject to the rights, licenses and
        restrictions contained in BCP 78, and except as set forth
        therein, the authors retain all their rights.
     
     Acknowledgment
     
        Funding for the RFC Editor function is currently provided by the
        Internet Society.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Gray                     Expires August, 2006             [Page 34]
     

Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/