[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 6327

TRILL Working Group                                  Donald Eastlake 3rd
INTERNET-DRAFT                                                    Huawei
Intended status: Proposed Standard                         Radia Perlman
Updates: RFCtrill                                             Intel Labs
                                                          Anoop Ghanwani
                                                          Dinesh G. Dutt
                                                           Cisco Systems
                                                          Vishwas Manral
                                                             IP Infusion
Expires: June 14, 2011                                 December 15, 2010

                          RBridges: Adjacency


   This document describes the TRILL LAN Hello protocol as regards
   adjacency, designated RBridge selection, and MTU procedures, with
   state machines.

Status of This Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  Distribution of this document is
   unlimited.  Comments should be sent to the TRILL working group
   mailing list <rbridge@postel.org>.

   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at


   The authors of [RFCtrill] and those listed in the Acknowledgements
   section of [RFCtrill] are hereby acknowledged by reference.

D. Eastlake, et al                                              [Page 1]

INTERNET-DRAFT                                       RBridges: Adjacency

Table of Contents

      1. Introduction............................................3
      1.1 Content and Precedence.................................3
      1.2 Terminology and Acronyms...............................4
      1.2 Conventions used in this document......................4

      2. The TRILL Hello Environment and Purposes................5
      2.1 Incrementally Replacing 802.1Q-2005 Bridges............5
      2.2 Handling Native Frames.................................5
      2.3 Zero or Minimal Configuration..........................7
      2.4 MTU Robustness.........................................7
      2.5 Purposes of the TRILL Hello Protocol...................7

      3. Adjacency State Machinery...............................9
      3.1 TRILL LAN Hellos and MTU Test..........................9
      3.2 Adjacency Table Entries and States.....................9
      3.3 Adjacency Events......................................10
      3.4 Adjacency State Diagram and Table.....................12
      3.5 Multiple Parallel Links...............................13
      3.6 Insufficient Space in Adjacency Table.................14

      4. RBridge LAN Ports and DRB State........................15
      4.1 Port Table Entries and DRB Election State.............15
      4.2 DRB Election Events...................................16
      4.3 State Table and Diagram...............................17

      5. MTU Matching...........................................18
      6. Pseudonodes............................................19

      7. TRILL Hello Reception and Transmission.................20
      7.1 Receiving TRILL Hellos................................20
      7.2 Transmitting TRILL Hellos.............................21

      8. Multiple Ports on the Same Link........................22
      9. Security Considerations................................22
      10. IANA Considerations...................................22

      11. References............................................23
      11.1 Normative References.................................23
      11.2 Informative References...............................23

D. Eastlake, et al                                              [Page 2]

INTERNET-DRAFT                                       RBridges: Adjacency

1. Introduction

   The IETF TRILL protocol [RFCtrill] provides optimal pair-wise data
   frame forwarding without configuration, safe forwarding even during
   periods of temporary loops, and support for multipathing of both
   unicast and multicast traffic. TRILL accomplishes this by using [IS-
   IS] link state routing and encapsulating traffic using a header that
   includes a hop count. The design supports VLANs and optimization of
   the distribution of multi-destination frames based on VLANs and IP
   derived multicast groups. Devices that implement TRILL are called

   The purpose of this document is to improve the quality of the
   description of the TRILL LAN Hello protocol. It includes reference
   implementation details. Alternative implementations that interoperate
   on the wire are permitted. There is no change to IS-IS point-to-point
   Hellos used on links configured as point-to-point in TRILL, which are
   beyond the scope of this document.

   The scope of this document is limited to the following aspects of the
   TRILL LAN Hello protocol:

      - Adjacency formation

      - DRB (aka DIS) election

      - Rules for two-way and MTU matching for advertisements

      - Creation and use of pseudo-nodes

   For other aspects of the TRILL base protocols see [RFCtrill].

1.1 Content and Precedence

   Section 2 below explains the rationale for the differences between
   the TRILL LAN Hello protocol and the Layer 3 IS-IS LAN Hello protocol
   [IS-IS] [RFC1195] in light of the environment for which the TRILL
   protocol is designed. It also describes the purposes of the TRILL LAN
   Hello protocol.

   Section 3 describes the adjacency state machine and the states and
   relevant events.

   Section 4 describes the Designated RBridge (DRB) election state
   machine for RBridge ports and the relevant states and events.

   Section 5 describes MTU testing and matching on a TRILL link.

D. Eastlake, et al                                              [Page 3]

INTERNET-DRAFT                                       RBridges: Adjacency

   Section 6 discusses pseudonode creation and use.

   Section 7 provides more details on the reception and transmission of
   TRILL LAN Hellos.

   Section 8 discusses multiple ports from one RBridge on the same link.

   While no change in the technical provisions of [RFCtrill] is
   intended, in case of conflict, this document prevails.

1.2 Terminology and Acronyms

   This document uses the acronyms defined in [RFCtrill] supplemented by
   the following additional acronym:

   SNPA - Sub-Network Point of Attachment

1.2 Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

D. Eastlake, et al                                              [Page 4]

INTERNET-DRAFT                                       RBridges: Adjacency

2. The TRILL Hello Environment and Purposes

   [IS-IS] has subnet independent functions and subnet dependent
   functions. Because of the differences between the environment of
   Layer 3 routers and the environment of TRILL RBridges, the TRILL
   protocol needs a third type of subnet different from the broadcast
   (LAN) subnet and the point-to-point subnet types encountered at Layer
   3. These environmental differences are described below followed by a
   summation, in Section 2.5, of the purposes of the TRILL LAN Hello

2.1 Incrementally Replacing 802.1Q-2005 Bridges

   RBridges can incrementally replace IEEE [802.1Q-2005] bridges. Thus
   RBridges need to provide similar services, including delivery of
   frames only to links in the frame's VLAN and priority queuing of
   frames, to the extent that multiple queues are implemented at an
   RBridge port.

   RBridge ports are IEEE [802.1Q-2005] ports in terms of their frame
   VLAN and priority configuration and processing as described in
   Section 2.6 of [RFCtrill]. When a frame is received through an
   RBridge port, like a frame received through any [802.1Q-2005] port,
   it has an associated VLAN ID and frame priority. When a frame is
   presented to an [802.1Q-2005] port for queuing and transmission, it
   must be accompanied by a VLAN ID and frame priority, although whether
   the frame, if actually transmitted, will be VLAN tagged is determined
   by whether the port is configured to "strip VLAN tags" in that case.
   Furthermore, in the general case, a broadcast link between RBridges
   is a VLAN-capable bridged LAN that can be configured to partition

   Because devices that restrict VLAN connectivity, such as bridged LANs
   or provider bridging equipment, can be part of the link between
   RBridges, TRILL Data and TRILL IS-IS frames between RBridges use the
   link's Designated VLAN. The Designated VLAN is dictated for a link by
   the elected Designated RBridge (equivalent to the Designated
   Intermediate System at Layer 3). Because TRILL Data frames flow
   between RBridges on a link only in the link's Designated VLAN,
   adjacency for routing calculations is based only on connectivity
   characteristics in that VLAN.

2.2 Handling Native Frames

   Layer 3 packets are already "tamed" when they are originated by an
   end station: they include a TTL and layer 3 source and destination

D. Eastlake, et al                                              [Page 5]

INTERNET-DRAFT                                       RBridges: Adjacency

   addresses. Furthermore, there is no requirement to preserve their
   outer layer 2 addressing and, at least for unicast packets, they are
   addressed to their first hop router. In contrast, RBridges running
   TRILL must accept, transport, and deliver untamed "native" frames (as
   defined in Section 1.4 of [RFCtrill]). Native frames lack a TRILL TTL
   field as well as having layer 2 addresses that are used as the basis
   for their forwarding and which must be preserved for delivery to
   their destination. One resulting difference is that RBridge ports
   must receive in promiscuous MAC address mode while Layer 3 router
   ports typically receive in a regularly selective MAC address mode.

   TRILL handles this by having, on the link where an end station
   originated a native frame, one RBridge "ingress" that native frame by
   adding a TRILL Header that includes a hop count, thus converting it
   to a TRILL Data frame. This augmented frame is then routed to one
   RBridge on the link having the destination end-station for the frame
   (or one RBridge on each such link if it is a multi-destination
   frame). Such final RBridges perform an "egress" function, removing
   the TRILL Header and delivering the original frame to its
   destination(s). (For the purposes of TRILL, a Layer 3 router is an
   end station.)

   Great care must be taken to avoid a loop that would involve egressing
   a native frame and then re-ingressing it because, while it is in
   native form, it would not be protected by a hop count. Such a loop
   could involve multiplication of the number of frames each time around
   and would likely saturate all links involved within milliseconds. For
   TRILL, safety against such loops for a link is more important than
   data connectivity on that link.

   The primary TRILL defense mechanism against such loops, which is
   mandatory, is to assure that, as far as practically possible, there
   is only a single RBridge on each link that is in charge of ingressing
   and egressing native frames from and to that link. This is the
   Designated RBridge which is elected using TRILL LAN Hellos as further
   described in Sections 2.5 and 4 below.

   Because bridged LANs between RBridges can be configured in complex
   ways, including so as to pass frames in some VLANs in one direction
   only, and loop safety is so important, there are additional TRILL
   defenses against loops, where the looping traffic is in native format
   for part of the loop, that are beyond the scope of this document.
   These additional defenses have no effect on adjacency states or the
   receipt or forwarding of TRILL Data frames, they only affect native
   frame ingress and egress.

D. Eastlake, et al                                              [Page 6]

INTERNET-DRAFT                                       RBridges: Adjacency

2.3 Zero or Minimal Configuration

   RBridges are expected to provide service with zero configuration,
   except for services such as non-default VLAN or priority that require
   configuration when offered by [802.1Q-2005] bridges. This differs
   from Layer 3 routing where routers typically need to be configured as
   to the subnets connected to each port, etc., to provide service.

2.4 MTU Robustness

   TRILL IS-IS needs to be robust against links with reasonably
   restricted MTUs, including links that accommodate only classic
   Ethernet frames, despite the addition of reasonable headers including
   a VLAN tags. This is particularly true for TRILL LAN Hellos so as to
   assure that a unique DRB is elected.

   TRILL will also be used inside data centers where it is not uncommon
   for all of the links and switches to support frames substantially
   larger than the classic Ethernet maximum, for example by having an
   MTU adequate to comfortably handle Fiber Channel over Ethernet
   frames, for which T11 recommends a 2,500 byte MTU [FCoE]. It would be
   beneficial for an RBridge campus with such a larger MTU to be able to
   safely make use of it.

   These needs are met by limiting the size of TRILL LAN Hellos and by
   the use of MTU testing as described below.

2.5 Purposes of the TRILL Hello Protocol

   There are three purposes for the TRILL Hello protocol as listed below
   along with a reference to the Section of this document in which each
   is discussed:

   a) To determine which RBridge neighbors have acceptable connectivity
   to be reported as part of the topology (Section 3)

   b) To elect a unique Designated RBridge on the link (Section 4)

   c) To determine the MTU with which it is possible to communicate with
   each RBridge neighbor (Section 5)

   In Layer 3 IS-IS all three of these functions are combined. Hellos
   are padded to the maximum length so that a router neighbor is not
   even discovered if it is impossible to communicate with it using
   maximum sized packets. Also, even if Hellos from a neighbor RB2 are
   received by RB1, if connectivity to RB2 is not 2-way (i.e., RB2 does

D. Eastlake, et al                                              [Page 7]

INTERNET-DRAFT                                       RBridges: Adjacency

   not list RB1 in RB2's Hello), then RB1 does not consider RB2 as a
   Designated Router candidate. Because of this logic, it is possible at
   Layer 3 for multiple Designated Routers to be elected on a LAN, with
   each representing the LAN as a pseudonode. It appears to the topology
   as if the LAN is now two or more separate LANs. Although this is
   surprising, it does not disrupt Layer 3 IS-IS.

   In contrast, this behavior is not acceptable for TRILL, since in
   TRILL it is essential that all RBridges on the link know about each
   other, and choose a single RBridge to be the DRB and control the
   native frame ingress and egress on that link. Otherwise, multiple
   RBridges might encapsulate/decapsulate the same native frame, forming
   loops that are not protected by the hop count in the TRILL header as
   discussed above.

   So, the TRILL Hello protocol is best understood by focusing on each
   of these functions separately.

   One other issue with TRILL LAN Hellos is to ensure that subsets of
   the information can appear in any single message, and be processable,
   in the spirit of IS-IS LSPs and CSNPs. TRILL Hello frames, even
   though they are not padded, can become very large. An example where
   this might be the case is when some sort of backbone technology
   interconnects hundreds of TRILL sites over what would appear to TRILL
   to be a giant Ethernet, where the RBridges connected to that cloud
   will perceive that backbone to be a single link with hundreds of
   neighbors. Thus the TRILL Hellos uses a different Neighbor TLV
   [RFCtisis] which lists neighbors seen for a range of MAC (SNPA)

D. Eastlake, et al                                              [Page 8]

INTERNET-DRAFT                                       RBridges: Adjacency

3. Adjacency State Machinery

   Each RBridge port has associated with it a table of zero or more
   adjacencies. The sub-sections below give the states such adjacencies
   can have, the events which cause state changes and the actions
   associated with those state changes, and a state table and diagram.

3.1 TRILL LAN Hellos and MTU Test

   The determination of LSP reported adjacencies on links which are not
   configured as point-to-point is made using TRILL LAN Hellos (see also
   Section 7) and an optional MTU test. Appropriate TRILL LAN Hello
   exchange and the satisfaction of the MTU test (see Section 5), if the
   MTU test is enabled, is required for there to be an adjacency that
   will be reported in an LSP of the RBridge in question.

   Because bridges acting as glue on the LAN might be configured in such
   a way that some VLANs are partitioned, it is necessary for RBridges
   to transmit Hellos with multiple VLAN tags. The conceptually simplest
   solution may have been to have all RBridges transmit 4,094 times as
   many Hellos, one with each legal VLAN ID, but this would obviously
   have deleterious performance implications. So, the TRILL protocol
   specifies that if RB1 knows it is not DRB, it transmits its Hellos on
   only a limited set of VLANs, and only an RBridge that believes itself
   to be DRB on a port "sprays" its TRILL Hellos on all of the VLANs it
   has enabled on a port (with the ability to configure to send on only
   a subset of those). The details are given in [RFCtrill] Section

   The MAC address (SNPA) of an RBridge port MUST NOT be used as the MAC
   address of a port of any other RBridge on the same link; however, if
   a particular RBridge has more than one port on a link, those ports
   may use the same MAC address (see Section 8). All TRILL LAN Hellos
   issued by an RBridge on a particular port MUST have the same source
   MAC address and priority regardless of the VLAN in which the Hello is

3.2 Adjacency Table Entries and States

   Each adjacency is in one of the following four states:

         This is a virtual state for convenience in creating state
         diagrams and tables. It indicates that the adjacency is non-
         existent and there is no entry in the adjacency table for it.

D. Eastlake, et al                                              [Page 9]

INTERNET-DRAFT                                       RBridges: Adjacency

         An adjacent neighbor has been detected either (1) not on the
         Designated VLAN or (2) on the Designated VLAN but neither 2-way
         connectivity nor the MTU of such connectivity has been

         2-way connectivity to the neighbor has been found on the
         Designated VLAN but MTU testing is enabled and has not yet
         confirmed that the connectivity meets the campus minimum MTU

         There is 2-way connectivity to the neighbor on the Designated
         VLAN and either MTU testing has confirmed that the connectivity
         meets the campus minimum MTU requirement or MTU testing is not
         enabled. This connectivity will be reported in an LSP (with
         appropriate provision for the link pseudonode, if any).

   For an adjacency in any of the three non-down states (Detect, 2-Way,
   and Report), there will be an adjacency table entry. That entry will
   give the state of the adjacency and will also include the information
   listed below.

      o  The address of the neighbor (that is, its SNPA), usually a
         48-bit MAC address.

      o  Two Hello holding timers, each consisting of an 16-bit unsigned
         integer number of seconds: a Designated VLAN holding timer and
         a non-Designated VLAN holding timer.

      o  The 7-bit unsigned priority of the neighbor to be DRB.

      o  The VLAN that the neighbor RBridge wants to be the Designated
         VLAN on the link.

3.3 Adjacency Events

   The following events can change the state of an adjacency:


      1. Receive a TRILL LAN Hello on the Designated VLAN with a TRILL
         Neighbor TLV that explicitly lists the receiver's address

      2. Receive a TRILL LAN Hello that either (1) is not on the
         Designated VLAN (any TRILL Neighbor TLV in such a Hello is

D. Eastlake, et al                                             [Page 10]

INTERNET-DRAFT                                       RBridges: Adjacency

         ignored) or (2) is on the Designated VLAN but does not contain
         a TRILL Neighbor TLV covering an address range including the
         receiver's address (SNPA)

      3. Receive a TRILL LAN Hello on the Designated VLAN with one or
         more TRILL Neighbor TLVs covering an address range including
         the receiver's address (SNPA) none of which lists the receiver

      4. Decrement of Hello holding timers changes them so both are zero

      5. Decrement of Hello holding timers results in expiry of the
         Designated VLAN Hello holding timer but the non-Designated VLAN
         Hello holding timer is still non-zero

      6. MTU test successful

      7. MTU test was successful but now fails

      8. The RBridge port goes operationally down

   The receipt of a TRILL LAN Hello, that is the occurrence of events 1,
   2, or 3, causes the following three actions (except where the Hello
   would create a new adjacency table entry, the table is full, and the
   Hello is too low a priority to displace an existing entry as
   described in Section 3.6). The Designated VLAN used in these actions
   is the Designated VLAN dictated by the DRB determined without taking
   the received TRILL LAN Hello into account (see Section 4).

      o  The appropriate Hello holding timer for the adjacency,
         depending on whether the Hello was received on the Designated
         VLAN or not, is set to the Holding Time field of the Hello.

      o  The priority of the neighbor RBridge to be DRB is set to the
         priority field of the Hello.

      o  If the creation of a new adjacency table entry or the priority
         update above changes the results of the DRB election on the
         link, the appropriate RBridge port event (3 or 4) occurs as
         described in Section 4.2.

   The Hello holding timers of every entry in the adjacency table are
   counted down once a second unless that timer is already at zero. This
   may cause event 4 or 5 for that adjacency.

   Concerning Events 6 and 7, if MTU testing is not enabled, event 6 is
   considered to occur immediately upon the adjacency entering the 2-Way
   state and event 7 cannot occur.

   See further TRILL LAN Hello receipt detail in Section 7.

D. Eastlake, et al                                             [Page 11]

INTERNET-DRAFT                                       RBridges: Adjacency

3.4 Adjacency State Diagram and Table

   The table below shows the transitions between the states defined
   above based on the events defined above:

               | Event |  Down  | Detect | 2-Way  | Report |
               |   1   | 2-Way  | 2-Way  | 2-Way  | Report |
               |   2   | Detect | Detect | 2-Way  | Report |
               |   3   | Detect | Detect | Detect | Detect |
               |   4   |  N/A   | Down   | Down   | Down   |
               |   5   |  N/A   | Detect | Detect | Detect |
               |   6   |  N/A   |  N/A   | Report | Report |
               |   7   |  N/A   |  N/A   | 2-Way  | 2-Way  |
               |   8   | Down   | Down   | Down   | Down   |

   N/A indicates that the event to the left is Not Applicable in the
   state at the top of the column.

   Below is the same information as that in the state table presented as
   a diagram:

D. Eastlake, et al                                             [Page 12]

INTERNET-DRAFT                                       RBridges: Adjacency

                            |     Down      |<--------+
                            +---------------+         |
                              |     |  ^  |           |
                              |2,3  |8 |  |1          |
                              |     +--+  |           |
                              |           +-----------|---+
                              V                       |   |
                            +----------------+ 4,8    |   |
                     +----->|      Detect    |------->|   |
                     |      +----------------+        |   |
                     |        |    |       ^          |   |
                     |        |1   |2,3,5  |          |   |
                     |        |    +-------+          |   |
                     |        |                       |   |
                     |        |          +------------|---+
                     |        |          |            |
                     |        V          V            |
                     |  3,5 +----------------+ 4,8    |
                     |<-----|     2-Way      |------->|
                     |      +----------------+        |
                     |        |   ^  |     ^          |
                     |        |6  |  |1,2,7|          |
                     |        |   |  +-----+          |
                     |        |   |                   |
                     |        |   |7                  |
                     |        V   |                   |
                     |  3,5 +-------------+ 4,8       |
                     |<-----|   Report    |--------=->|
                               |        ^
                               |1,2,6   |

3.5 Multiple Parallel Links

   There can be multiple parallel adjacencies between neighbor RBridges
   that are visible to TRILL. (Multiple low level links that have been
   bonded together by technologies such as link aggregation [802.1AX]
   appear to TRILL as a single link over which a single adjacency could
   be established.)

   Any such links that have pseudonodes (see Section 6) are
   distinguished in the topology and such adjacencies, if they are in
   the Report state, appear in LSPs as per [IS-IS]. However, there can
   be multiple parallel adjacencies without pseudonodes because they are
   point-to-point and/or TRILL LAN adjacencies for which a pseudonode is
   not being created. Such parallel non-pseudonode adjacencies in the

D. Eastlake, et al                                             [Page 13]

INTERNET-DRAFT                                       RBridges: Adjacency

   Report state appear in LSPs as a single adjacency. The cost of such
   an adjacency MAY be adjusted downwards to account for the parallel
   paths.  Multipathing across such parallel connections can be freely
   done for unicast traffic on a per flow basis but is restricted for
   multi-destination traffic, as described in [RFCtrill] Section 4.5.2,
   point 3, and Appendix C.

3.6 Insufficient Space in Adjacency Table

   If a TRILL LAN Hello would create a new adjacency table entry, that
   is, would transition an adjacency out of the Down state, there may be
   no space for the new entry. In that case, the DRB election priority
   (see Section 4.2) of the new entry that would be created is compared
   with that priority for the existing entries. If the new entry is
   higher priority than the lowest priority existing entry, it replaces
   the lowest priority existing entry which is transitioned to the Down
   state (see Section 3). This is the same policy as Section 8.4.3 of

D. Eastlake, et al                                             [Page 14]

INTERNET-DRAFT                                       RBridges: Adjacency

4. RBridge LAN Ports and DRB State

   The information at an RBridge associated with each of its LAN ports
   includes the following:

      o  Enablement bit, which defaults to enabled.

      o  SNPA (usually a 48-bit MAC address) of the port.

      o  The Holding Time used in TRILL Hellos sent on the port.

      o  The DRB status of the port, determined as specified below.

      o  The desired Designated VLAN. The VLAN this RBridge wants to be
         the Designated VLAN for the link out this port.

      o  A table of zero or more adjacencies (see Section 3).

4.1 Port Table Entries and DRB Election State

   The TRILL equivalent of the DIS (Designated Intermediate System) on a
   link is the DRB or Designated RBridge. The DRB election state
   machinery is described below.

   Each RBridge port is in one of the following four DRB states:

         The port is operationally down. It might be administratively
         disabled or down at the link layer. In this state, Hellos are
         not accepted on the port and there will be no adjacency table
         entries for the port.

         The port has become DRB but is in a pre-forwarding state with
         regard to native frames and is inhibited from ingressing or
         egressing them.

         The port is DRB and may ingress and egress native frames.

      Not DRB:
         The port is deferring to another port on the link which it
         believes is DRB.

D. Eastlake, et al                                             [Page 15]

INTERNET-DRAFT                                       RBridges: Adjacency

4.2 DRB Election Events

   The following events can change the DRB state of a port:


      1. Enablement of the port.

      2. Expiration of the pre-forwarding timer.

      3. Adjacency table for the port changes and there are one or more
         other RBridge ports on the link that are higher priority to be
         DRB than the local port.

      4. Adjacency table for the port changes and there are no other
         RBridge ports on the link that are higher priority to be DRB
         than the local port.

      5. The port becomes operationally down.

   Events 1 and 4 cause a pre-forwarding timer associated with the port
   to be set to the port Holding Time. The pre-forwarding time is
   counted down once a second for each port, if non-zero. When the pre-
   forwarding timer for a port is decremented to zero, it causes an
   event 2 for that port.

   Event 1 is considered to occur on RBridge boot if the port is
   administratively and link layer enabled.

   Determination of events 3 and 4 occurs by comparing priorities (with
   neighbor MAC address (SNPA) as a tie breaker) across all entries in
   the port's adjacency table including those in the Detect and 2-Way
   states as well as those in the Report state.

   Events 3 and 4 result in a change in the apparent DRB on the link.
   The normal case is that all RBridge ports on the link would be
   configured with the same desired Designated VLAN. However, if the
   change in apparent DRB results in a change in Designated VLAN, then,
   for all adjacency table entries for that port, the following steps
   occur in the order given:

      o  The non-Designated VLAN Hello Holding timer is set to the
         maximum of its value and the value of the Designated VLAN Hello
         Holding timer.

      o  If the Designated VLAN Hello Holding timer is zero, skip this
         step. If the Designated VLAN Hello Holding timer is non-zero,
         it is set to zero and an adjacency event 5 occurs for the
         adjacency (see Section 3.3).

D. Eastlake, et al                                             [Page 16]

INTERNET-DRAFT                                       RBridges: Adjacency

4.3 State Table and Diagram

   The table below shows the transitions between the DRB states defined
   above based on the events defined above:

             | Event | Down    | Pre-DRB |  DRB    | Not DRB |
             |   1   | Pre-DRB |  N/A    |  N/A    |  N/A    |
             |   2   | Down    |  DRB    |  N/A    | Not DRB |
             |   3   |  N/A    | Not DRB | Not DRB | Not DRB |
             |   4   |  N/A    | Pre-DRB | DRB     | Pre DRB |
             |   5   |  N/A    | Down    | Down    | Down    |

   N/A indicates that the event to the left is Not Applicable in the
   state at the top of the column.

   Below is the same information as in the state table presented as a

                        |  Down     |<---------+
                        +-----------+          |
                          |   |  ^             |
                          |1  |2 |             |
                          |   +--+             |
                          |                    |
                          V                    |
                       +--------------+  5     |
                       |   Pre-DRB    |------->|
                       +-+--------+---+        |
                        |   ^  |  ^  |         |
                        |3  |  |4 |  |2        |
                        |   |  +--+  |         |
                        |   |        |         |
                        |   |        V         |
                        |   |  +-------+  5    |
                        |   |  |  DRB  |------>|
                        |   |  +-------+       |
                        |   |   |  |  ^        |
                        |   |   |3 |4 |        |
                        |   |   |  +--+        |
                        |   |4  |              |
                        V   |   V              |
                       +--------------+  5     |
                       |   Not DRB    |------->|
                            |     ^
                            |2,3  |

D. Eastlake, et al                                             [Page 17]

INTERNET-DRAFT                                       RBridges: Adjacency

5. MTU Matching

   The purpose of MTU testing is to ensure that the links used in the
   campus topology can all pass TRILL IS-IS frames at the desired
   RBridge campus MTU.

   An RBridge, RB1, determines the desired campus link MTU by
   calculating the minimum of its originatingL1LSPBufferSize and the
   originatingLSPBufferSize advertised in the link state database by
   other RBridges in the campus but not less than 1,470 bytes.  Although
   originatingLSPBufferSize in Layer 3 [IS-IS] is limited to the range
   512 to 1,492 bytes inclusive, in TRILL it is limited to the range
   1,470 to 65,535 bytes inclusive.

   Although MTU testing is optional, it is mandatory for an RBridge to
   respond to an MTU-probe PDU with an MTU-ack PDU [RFCtrill]

   RB1 can test the MTU size to RB2 as described in Section 4.3.2 of
   [RFCtrill]. For this purpose, MTU testing is only done in the
   Designated VLAN. An adjacency that fails the MTU test at the campus
   desired MTU will not enter the "Report" state or, if the adjacency is
   in that state, it leaves that state. Thus an adjacency failing the
   MTU test will not be reported by the RBridge performing the test.
   Since inclusion in the campus topology for route computation requires
   the adjacency to be reported by both ends, as long as the MTU failure
   is noticed by the RBridge at either end of the adjacency, it will not
   be so used.

   If it tests MTU, RB1 lists the largest size for which the MTU test
   succeeds or a flag indicating that it fails at the campus MTU, with
   the neighbor in RB1's TRILL Neighbor TLV and MAY report this with the
   adjacency in an Extended Reachability TLV in RB1's LSP. RB1 MAY
   choose to test MTU sizes greater than the desired campus MTU as well
   as the desired campus MTU.

   Most types of TRILL IS-IS frames, such as LSPs, can make use of the
   campus MTU. The exceptions are TRILL Hellos, which must be kept small
   for loop safety, and the MTU PDUs whose size must be adjusted
   appropriately for the tests being performed.

D. Eastlake, et al                                             [Page 18]

INTERNET-DRAFT                                       RBridges: Adjacency

6. Pseudonodes

   The Designated RBridge (DRB), determined as described above, controls
   whether a pseudonode will be used on a link.

   It is anticipated that many links between RBridges will be point-to-
   point, in which case using a pseudonode merely adds to the
   complexity. If the DRB sets the bypass pseudonode bit in its TRILL
   LAN Hellos, the RBridges on the link just directly report their
   adjacencies that are in the Report state. If the DRB does not set the
   bypass pseudonode bit in its TRILL Hellos, then it specifies a
   pseudonode for the link and sends LSPs on behalf of the pseudonode as
   usual. Setting the bypass pseudonode bit has no effect on how LSPs
   are flooded on a link. It only affects what LSPs are generated.

   For example, if RB1 and RB2 are the only RBridges on the link and RB1
   is DRB, then if RB1 creates a pseudonode that is used, there are 3
   LSPs: for, say, RB1.25 (the pseudonode), RB1, and RB2, where RB1.25
   reports connectivity to RB1 and RB2, and RB1 and RB2 each just say
   they are connected to RB1.25.  Whereas if DRB RB1 sets the bypass
   pseudonode bit in its Hellos, then there will be only 2 LSPs: RB1 and
   RB2 each reporting connectivity to each other.

   A DRB SHOULD set the bypass pseudonode bit in its Hellos if it has
   not seen at least two simultaneous adjacencies in the Report state at
   some time since it last re-booted or was reset by network management.

D. Eastlake, et al                                             [Page 19]

INTERNET-DRAFT                                       RBridges: Adjacency

7. TRILL Hello Reception and Transmission

   This section provides further details on the receipt and transmission
   of TRILL LAN Hellos.

   TRILL LAN Hellos, like all TRILL IS-IS frames, are primarily
   distinguished from Layer 3 IS-IS frames by being sent to the All-IS-
   IS-RBridges multicast address (01-80-C2-00-00-41). TRILL IS-IS frames
   also have the L2-IS-IS Ethertype (0x22F4) and are Ethertype encoded.

   Although future extensions to TRILL may include use of Level 2 IS-IS,
   [RFCtrill] specifies TRILL using a single Level 1 Area with Area
   Address zero (see Section 4.2 of [RFCtisis]).

   IS-IS Layer 3 routers are frequently connected to other Layer 3
   routers that are part of a different routing domain. In that case,
   the externalDomain flag is normally set for the port through which
   such a connection is made. The setting of this flag causes no IS-IS
   PDUs to be sent out the port and any IS-IS PDUs received to be
   discarded, including Hellos. RBridges operate in a different
   environment where all neighbor RBridges merge into a single campus.
   For loop safety, RBridges do not implement the externalDomain flag or
   implement it with the fixed value "false". They send and receive
   TRILL LAN Hellos on every port that is not disabled or configured as

7.1 Receiving TRILL Hellos

   Assuming a frame has the All-IS-IS-RBridges multicast address and
   L2-IS-IS Ethertype, it will be examined to see if it appears to be an
   IS-IS PDU. If so, and it appears to be a LAN Hello PDU, the following
   tests are performed.

      o If the Circuit Type field is other than 1, the PDU is discarded.

      o  If the PDU does not contain an Area Address TLV or it contains
         an Area Address TLV that is other than the single Area Address
         zero, it is discarded.

      o  If the Hello includes a Protocols Supported TLV that does not
         list the TRILL NLPID (0xC0), it is discarded.

      o  If the Hello does not contain an MT Port Capabilities TLV
         containing a VLAN-FLAGS sub-TLV [RFCtisis], it is discarded.

      o  If the maximumAreaAddresses field of the PDU is not 1, it is

D. Eastlake, et al                                             [Page 20]

INTERNET-DRAFT                                       RBridges: Adjacency

      o  If IS-IS authentication is in use on the link and the PDU
         either has no Authentication TLV or validation of that
         Authentication TLV fails, it is discarded.

   If none of the rules in the list above has been satisfied, the frame
   can be assumed to be a well-formed TRILL Hello received on the link.
   It is treated as an adjacency Event 1, 2, or 3 based on the criteria
   listed in Section 3.3.

7.2 Transmitting TRILL Hellos

   TRILL LAN Hellos are sent with the same timing as Layer 3 IS-IS LAN
   Hellos [IS-IS].

   TRILL Hello messages MUST NOT exceed 1,470 octets in length and
   SHOULD NOT be padded.

   TRILL Hello PDU headers MUST conform to the following:

      o  Maximum Area Addresses equal to 1.

      o  Circuit Type equal to 1.

   Each TRILL Hello MUST contain (1) a Protocols Supported TLV listing
   the TRILL NLPID (0xC0), (2) an Area Addresses TLV listing the single
   Area zero, and (3) an MT Port Capabilities TLV containing a VLAN-
   FLAGS sub-TLV [RFCtisis].

   If there are no adjacencies with a non-zero Desiganted VLAN Hello
   Holding timer, an empty TRILL Neighbor TLV MUST be included in each
   Hello.  If there are such adjacencies, then the Hello MAY contain a
   TRILL Neighbor TLV as described in Section of [RFCtrill]. To
   ensure that any RBridge RB2 can definitively determine whether RB1
   can hear RB2, RB1's neighbor list MUST eventually cover every
   possible range of IDs, that is, within a period that depends on RB1's
   policy and not necessarily within any specific period such as the
   holding time. In other words, if X1 is the smallest reported in one
   of RB1's neighbor lists, and the "smallest" flag is not set, then X1
   MUST appear in a different neighbor list as well, as the largest ID
   reported in that fragment. Or, lists may overlap, as long as there is
   no gap, such that some range, say between Xi and Xj, never appears in
   any list.

   TRILL Hellos MAY contain an Authentication TLV.

D. Eastlake, et al                                             [Page 21]

INTERNET-DRAFT                                       RBridges: Adjacency

8. Multiple Ports on the Same Link

   It is possible for an RBridge RB1 to have multiple ports on the same
   link. It is important for RB1 to recognize which of its ports are on
   the same link.  RB1 detects this condition based on receiving TRILL
   LAN Hello messages with the same LAN ID on multiple ports.

   Although the DRB election is port-based (see Section 4), the election
   designates an RBridge as DRB for the link. An RBridge may choose to
   load split some tasks among its ports on the link it if has more than
   one and it is safe to do so as described in Section 4.4.4 of

9. Security Considerations

   This memo provides improved documentation of some aspects of the
   TRILL base protocol and does not change the security considerations
   thereof. See Section 6 of [RFCtrill].

10. IANA Considerations

   This document requires no IANA actions. RFC Editor: Please delete
   this section before publication.

D. Eastlake, et al                                             [Page 22]

INTERNET-DRAFT                                       RBridges: Adjacency

11. References

   Normative and Informational references for this document are listed

11.1 Normative References

   [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to
         Intermediate System Intra-Domain Routing Exchange Protocol for
         use in Conjunction with the Protocol for Providing the
         Connectionless-mode Network Service (ISO 8473)", 2002.

   [RFC1195] - Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
         dual environments", RFC 1195, December 1990.

   [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
         Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFCtisis] - Eastlake, D., A. Banerjee, D. Dutt, R. Perlman, A.
         Ghanwani, "TRILL Use of IS-IS", draft-ietf-isis-trill, work in

   [RFCtrill] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A.
         Ghanwani, "RBridges: Base Protocol Specification", draft-ietf-
         trill-rbridge-protocol-16.txt, in RFC Editor's queue.

11.2 Informative References

   [802.1AX] - "IEEE Standard for Local and metropolitan area networks /
         Link Aggregation", 802.1AX-2008, 1 January 2008.

   [FCoE] - From www.t11.org discussion of "FCoE Max Size" generated
         from T11/09-251v1, 04/27/2009, "FCoE frame or FCoE PDU".

D. Eastlake, et al                                             [Page 23]

INTERNET-DRAFT                                       RBridges: Adjacency

Authors' Addresses

   Donald E. Eastlake, 3rd
   155 Beaver Street
   Milford, MA 01757 USA

   Phone: +1-508-333-2270
   Email: d3e3e3@gmail.com

   Radia Perlman
   Intel Labs
   2200 Mission College Blvd.
   Santa Clara, CA 95054-1549 USA

   Phone: +1-408-765-8080
   Email: Radia@alum.mit.edu

   Anoop Ghanwani
   Brocade Communications Systems
   130 Holger Way
   San Jose, CA 95134 USA

   Phone: +1-408-333-7149
   Email: anoop@brocade.com

   Dinesh G. Dutt
   Cisco Systems
   170 Tasman Drive
   San Jose, CA 95134-1706 USA

   Phone: +1-408-527-0955
   Email: ddutt@cisco.com

   Vishwas Manral
   IP Infusion Inc.
   1188 E. Arques Ave.
   Sunnyvale, CA 94089 USA

   Tel:   +1-408-400-1900
   email: vishwas@ipinfusion.com

D. Eastlake, et al                                             [Page 24]

INTERNET-DRAFT                                       RBridges: Adjacency

Copyright and IPR Provisions

   Copyright (c) 2010 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 BSD License.  The definitive version of an IETF
   Document is that published by, or under the auspices of, the IETF.
   Versions of IETF Documents that are published by third parties,
   including those that are translated into other languages, should not
   be considered to be definitive versions of IETF Documents. The
   definitive version of these Legal Provisions is that published by, or
   under the auspices of, the IETF. Versions of these Legal Provisions
   that are published by third parties, including those that are
   translated into other languages, should not be considered to be
   definitive versions of these Legal Provisions.  For the avoidance of
   doubt, each Contributor to the IETF Standards Process licenses each
   Contribution that he or she makes as part of the IETF Standards
   Process to the IETF Trust pursuant to the provisions of RFC 5378. No
   language to the contrary, or terms, conditions or rights that differ
   from or are inconsistent with the rights and licenses granted under
   RFC 5378, shall have any effect and shall be null and void, whether
   published or posted by such Contributor, or included with or in such

D. Eastlake, et al                                             [Page 25]

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