3.  Details of the TRILL Header

   This section specifies the TRILL header.  Section 4 below provides
   other RBridge design details.

3.1.  TRILL Header Format

   The TRILL header is shown in Figure 5 and is independent of the data
   link layer used.  When that layer is IEEE [802.3], it is prefixed
   with the 16-bit TRILL Ethertype [RFC5342], making it 64-bit aligned.
   If Op-Length is a multiple of 64 bits, then 64-bit alignment is
   normally maintained for the content of an encapsulated frame.

                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   | V | R |M|Op-Length| Hop Count |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Egress RBridge Nickname     |  Ingress RBridge Nickname     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Options...
   +-+-+-+-+-+-+-+-+-+-+-+-

                          Figure 5: TRILL Header

   The header contains the following fields that are described in the
   sections referenced:

   o  V (Version): 2-bit unsigned integer.  See Section 3.2.

   o  R (Reserved): 2 bits.  See Section 3.3.

   o  M (Multi-destination): 1 bit.  See Section 3.4.

   o  Op-Length (Options Length): 5-bit unsigned integer.  See Section
      3.5.

   o  Hop Count: 6-bit unsigned integer.  See Section 3.6.

   o  Egress RBridge Nickname: 16-bit identifier.  See Section 3.7.1.

   o  Ingress RBridge Nickname: 16-bit identifier.  See Section 3.7.2.

   o  Options: present if Op-Length is non-zero.  See Section 3.8.

3.2.  Version (V)

   Version (V) is a 2-bit field.  Version zero of TRILL is specified in
   this document.  An RBridge RB1 MUST check the V field in a received
   TRILL-encapsulated frame.  If the V field has a value not recognized
   by RB1, then RB1 MUST silently discard the frame.  The allocation of
   new TRILL Version numbers requires an IETF Standards Action.

3.3.  Reserved (R)

   The two R bits are reserved for future use in extensions to this
   version zero of the TRILL protocol.  They MUST be set to zero when
   the TRILL header is added by an ingress RBridge, transparently copied
   but otherwise ignored by transit RBridges, and ignored by egress
   RBridges.  The allocation of reserved TRILL header bits requires an
   IETF Standards Action.

3.4.  Multi-destination (M)

   The Multi-destination bit (see Section 2.4.2) indicates that the
   frame is to be delivered to a class of destination end stations via a
   distribution tree and that the egress RBridge nickname field
   specifies this tree.  In particular:

   o  M = 0 (FALSE) - The egress RBridge nickname contains a nickname of
      the egress Rbridge for a known unicast MAC address.

   o  M = 1 (TRUE) - The egress RBridge nickname field contains a
      nickname that specifies a distribution tree.  This nickname is
      selected by the ingress RBridge for a TRILL Data frame or by the
      source RBridge for a TRILL ESADI frame.

3.5.  Op-Length

   There are provisions to express in the TRILL header that a frame is
   using an optional capability and to encode information into the
   header in connection with that capability.

   The Op-Length header field gives the length of the TRILL header
   options in units of 4 octets, which allows up to 124 octets of
   options area.  If Op-Length is zero, there are no options present.
   If options are present, they follow immediately after the Ingress
   Rbridge Nickname field.

   See Section 3.8 for more information on TRILL header options.

3.6.  Hop Count

   The Hop Count field is a 6-bit unsigned integer.  An Rbridge drops
   frames received with a hop count of zero, otherwise it decrements the
   hop count.  (This behavior is different from IPv4 and IPv6 in order
   to support the later addition of a traceroute-like facility that
   would be able to get a hop count exceeded from an egress RBridge.)

   For known unicast frames, the ingress RBridge SHOULD set the Hop
   Count in excess of the number of RBridge hops it expects to the
   egress RBridge to allow for alternate routing later in the path.

   For multi-destination frames, the Hop Count SHOULD be set by the
   ingress RBridge (or source RBridge for a TRILL ESADI frame) to at
   least the expected number of hops to the most distant RBridge.  To
   accomplish this, RBridge RBn calculates, for each branch from RBn of
   the specified distribution tree rooted at RBi, the maximum number of
   hops in that branch.

   Multi-destination frames are of particular danger because a loop
   involving one or more distribution tree forks could result in the
   rapid generation of multiple copies of the frame, even with the
   normal hop count mechanism.  It is for this reason that multi-
   destination frames are subject to a stringent Reverse Path Forwarding
   Check and other checks as described in Section 4.5.2.  As an optional
   additional traffic control measure, when forwarding a multi-
   destination frame onto a distribution tree branch, transit RBridge
   RBm MAY decrease the hop count by more than 1, unless decreasing the
   hop count by more than 1 would result in a hop count insufficient to
   reach all destinations in that branch of the tree rooted at RBi.
   Using a hop count close or equal to the minimum needed on multi-
   destination frames provides additional protection against problems
   with temporary loops when forwarding.

   Although the RBridge MAY decrease the hop count of multi-destination
   frames by more than 1, under the circumstances described above, the
   RBridge forwarding a frame MUST decrease the hop count by at least 1,
   and discards the frame if it cannot do so because the hop count is 0.
   The option to decrease the hop count by more than 1 under the
   circumstances described above applies only to multi-destination
   frames, not to known unicast frames.

3.7.  RBridge Nicknames

   Nicknames are 16-bit dynamically assigned quantities that act as
   abbreviations for RBridges' IS-IS IDs to achieve a more compact
   encoding and can be used to specify potentially different trees with
   the same root.  This assignment allows specifying up to 2**16
   RBridges; however, the value 0x0000 is reserved to indicate that a
   nickname is not specified, the values 0xFFC0 through 0xFFFE are
   reserved for future specification, and the value 0xFFFF is
   permanently reserved.  RBridges piggyback a nickname acquisition
   protocol on the link state protocol (see Section 3.7.3) to acquire
   one or more nicknames unique within the campus.

3.7.1.  Egress RBridge Nickname

   There are two cases for the contents of the egress RBridge nickname
   field, depending on the M bit (see Section 3.4).  The nickname is
   filled in by the ingress RBridge for TRILL Data frames and by the
   source RBridge for TRILL ESADI frames.

   o  For known unicast TRILL Data frames, M == 0 and the egress RBridge
      nickname field specifies the egress RBridge; that is, it specifies
      the RBridge that needs to remove the TRILL encapsulation and
      forward the native frame.  Once the egress nickname field is set,
      it MUST NOT be changed by any subsequent transit RBridge.

   o  For multi-destination TRILL Data frames and for TRILL ESADI
      frames, M == 1.  The egress RBridge nickname field contains a
      nickname specifying the distribution tree selected to be used to
      forward the frame.  This root nickname MUST NOT be changed by
      transit RBridges.

3.7.2.  Ingress RBridge Nickname

   The ingress RBridge nickname is set to a nickname of the ingress
   RBridge for TRILL Data frames and to a nickname of the source RBridge
   for TRILL ESADI frames.  If the RBridge setting the ingress nickname
   has multiple nicknames, it SHOULD use the same nickname in the
   ingress field whenever it encapsulates a frame with any particular
   Inner.MacSA and Inner.VLAN value.  This simplifies end node learning.

   Once the ingress nickname field is set, it MUST NOT be changed by any
   subsequent transit RBridge.

3.7.3.  RBridge Nickname Selection

   The nickname selection protocol is piggybacked on TRILL IS-IS as
   follows:

   o  The nickname or nicknames being used by an RBridge are carried in
      an IS-IS TLV (type-length-value data element) along with a
      priority of use value [RFC6326].  Each RBridge chooses its own
      nickname or nicknames.

   o  Nickname values MAY be configured.  An RBridge that has been
      configured with one or more nickname values will have priority for
      those nickname values over all Rbridges with non-configured
      nicknames.

   o  The nickname value 0x0000 and the values from 0xFFC0 through
      0xFFFF are reserved and MUST NOT be selected by or configured for
      an RBridge.  The value 0x0000 is used to indicate that a nickname
      is not known.

   o  The priority of use field reported with a nickname is an unsigned
      8-bit value, where the most significant bit (0x80) indicates that
      the nickname value was configured.  The bottom 7 bits have the
      default value 0x40, but MAY be configured to be some other value.
      Additionally, an RBridge MAY increase its priority after holding a
      nickname for some amount of time.  However, the most significant
      bit of the priority MUST NOT be set unless the nickname value was
      configured.

   o  Once an RBridge has successfully acquired a nickname, it SHOULD
      attempt to reuse it in the case of a reboot.

   o  Each RBridge is responsible for ensuring that its nickname or each
      of its nicknames is unique.  If RB1 chooses nickname x, and RB1
      discovers, through receipt of an LSP for RB2 at any later time,
      that RB2 has also chosen x, then the RBridge or pseudonode with
      the numerically higher IS-IS ID (LAN ID) keeps the nickname, or if
      there is a tie in priority, the RBridge with the numerically
      higher IS-IS System ID keeps the nickname, and the other RBridge
      MUST select a new nickname.  This can require an RBridge with a
      configured nickname to select a replacement nickname.

   o  To minimize the probability of nickname collisions, an RBridge
      selects a nickname randomly from the apparently available
      nicknames, based on its copy of the link state.  This random
      selection can be by the RBridge hashing some of its parameters,
      e.g., SystemID, time and date, and other entropy sources, such as
      those given in [RFC4086], each time or by the RBridge using such
      hashing to create a seed and making any selections based on
      pseudo-random numbers generated from that seed [RFC4086].  The
      random numbers or seed and the algorithm used SHOULD make
      uniformly distributed selections over the available nicknames.
      Convergence to a nickname-collision-free campus is accelerated by
      selecting new nicknames only from those that appear to be
      available and by having the highest priority nickname involved in
      a nickname conflict retain its value.  There is no reason for all
      Rbridges to use the same algorithm for selecting nicknames.

   o  If two RBridge campuses merge, then transient nickname collisions
      are possible.  As soon as each RBridge receives the LSPs from the
      other RBridges, the RBridges that need to change nicknames select
      new nicknames that do not, to the best of their knowledge, collide
      with any existing nicknames.  Some RBridges may need to change
      nicknames more than once before the situation is resolved.

   o  To minimize the probability of a new RBridge usurping a nickname
      already in use, an RBridge SHOULD wait to acquire the link state
      database from a neighbor before it announces any nicknames that
      were not configured.

   o  An RBridge by default has only a single nickname but MAY be
      configured to request multiple nicknames.  Each such nickname
      would specify a shortest path tree with the RBridge as root but,
      since the tree number is used in tiebreaking when there are
      multiple equal cost paths (see Section 4.5.1), the trees for the
      different nicknames will likely utilize different links.  Because
      of the potential tree computation load it imposes, this capability

      to request multiple nicknames for an RBridge should be used
      sparingly.  For example, it should be used at a few RBridges that,
      because of campus topology, are particularly good places from
      which to calculate multiple different shortest path distribution
      trees.  Such trees need separate nicknames so traffic can be
      multipathed across them.

   o  If it is desired for a pseudonode to be a tree root, the DRB MAY
      request one or more nicknames in the pseudonode LSP.

   Every nickname in use in a campus identifies an RBridge (or
   pseudonode) and every nickname designates a distribution tree rooted
   at the RBridge (or pseudonode) it identifies.  However, only a
   limited number of these potential distribution trees are actually
   computed by all the RBridges in a campus as discussed in Section 4.5.

3.8.  TRILL Header Options

   All Rbridges MUST be able to skip the number of 4-octet chunks
   indicated by the Op-Length field (see Section 3.5) in order to find
   the inner frame, since RBridges must be able to find the destination
   MAC address and VLAN tag in the inner frame.  (Transit RBridges need
   such information to filter VLANs, IP multicast, and the like.  Egress
   Rbridges need to find the inner header to correctly decapsulate and
   handle the inner frame.)

   To ensure backward-compatible safe operation, when Op-Length is non-
   zero indicating that options are present, the top two bits of the
   first octet of the options area are specified as follows:

               +------+------+----+----+----+----+----+----+
               | CHbH | CItE |          Reserved           |
               +------+------+----+----+----+----+----+----+

                Figure 6: Options Area Initial Flags Octet

   If the CHbH (Critical Hop-by-Hop) bit is one, one or more critical
   hop-by-hop options are present.  Transit RBridges that do not support
   all of the critical hop-by-hop options present, for example, an
   RBridge that supported no options, MUST drop the frame.  If the CHbH
   bit is zero, the frame is safe, from the point of view of options
   processing, for a transit RBridge to forward, regardless of what
   options that RBridge does or does not support.  A transit RBridge
   that supports none of the options present MUST transparently forward
   the options area when it forwards a frame.

   If the CItE (Critical Ingress-to-Egress) bit is one, one or more
   critical ingress-to-egress options are present.  If it is zero, no

   such options are present.  If either CHbH or CItE is non-zero, egress
   RBridges that don't support all critical options present, for
   example, an RBridge that supports no options, MUST drop the frame.
   If both CHbH and CItE are zero, the frame is safe, from the point of
   view of options, for any egress RBridge to process, regardless of
   what options that RBridge does or does not support.

   Options, including the meaning of the bits labeled as Reserved in
   Figure 6, will be further specified in other documents and are
   expected to include provisions for hop-by-hop and ingress-to-egress
   options as well as critical and non-critical options.

   Note: Most RBridge implementations are expected to be optimized for
      the simplest and most common cases of frame forwarding and
      processing.  The inclusion of options may, and the inclusion of
      complex or lengthy options likely will, cause frame processing
      using a "slow path" with inferior performance to "fast path"
      processing.  Limited slow path throughput may cause such frames to
      be discarded.

4.  Other RBridge Design Details

   Section 3 above specifies the TRILL header, while this section
   specifies other RBridge design details.

4.1.  Ethernet Data Encapsulation

   TRILL data and ESADI frames in transit on Ethernet links are
   encapsulated with an outer Ethernet header (see Figure 2).  This
   outer header looks, to a bridge on the path between two RBridges,
   like the header of a regular Ethernet frame; therefore, bridges
   forward the frame as they normally would.  To enable RBridges to
   distinguish such TRILL Data frames, a new TRILL Ethertype (see
   Section 7.2) is used in the outer header.

   Figure 7 details a TRILL Data frame with an outer VLAN tag traveling
   on an Ethernet link as shown at the top of the figure, that is,
   between transit RBridges RB3 and RB4.  The native frame originated at
   end station ESa, was encapsulated by ingress RBridge RB1, and will
   ultimately be decapsulated by egress RBridge RB2 and delivered to
   destination end station ESb.  The encapsulation shown has the
   advantage, if TRILL options are absent or the length of such options
   is a multiple of 64 bits, of aligning the original Ethernet frame at
   a 64-bit boundary.

   When a TRILL Data frame is carried over an Ethernet cloud, it has
   three pairs of addresses:

   o  Outer Ethernet Header: Outer Destination MAC Address (Outer.MacDA)
      and Outer Source MAC Address (Outer.MacSA): These addresses are
      used to specify the next hop RBridge and the transmitting RBridge,
      respectively.

   o  TRILL Header: Egress Nickname and Ingress Nickname.  These specify
      nicknames of the egress and ingress RBridges, respectively, unless
      the frame is multi-destination, in which case the Egress Nickname
      specifies the distribution tree on which the frame is being sent.

   o  Inner Ethernet Header: Inner Destination MAC Address (Inner.MacDA)
      and Inner Source MAC Address (Inner.MacSA): These addresses are as
      transmitted by the original end station, specifying, respectively,
      the destination and source of the inner frame.

   A TRILL Data frame also potentially has two VLAN tags, as discussed
   in Sections 4.1.2 and 4.1.3 below, that can carry two different VLAN
   Identifiers and specify priority.

   Flow:
     +-----+  +-------+   +-------+       +-------+   +-------+  +----+
     | ESa +--+  RB1  +---+  RB3  +-------+  RB4  +---+  RB2  +--+ESb |
     +-----+  |ingress|   |transit|   ^   |transit|   |egress |  +----+
              +-------+   +-------+   |   +-------+   +-------+
                                      |
   Outer Ethernet Header:             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Outer Destination MAC Address  (RB4)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Outer Destination MAC Address | Outer Source MAC Address      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Outer Source MAC Address  (RB3)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Ethertype = C-Tag [802.1Q-2005]| Outer.VLAN Tag Information    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   TRILL Header:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Ethertype = TRILL             | V | R |M|Op-Length| Hop Count |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Egress (RB2) Nickname         | Ingress (RB1) Nickname        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Inner Ethernet Header:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Inner Destination MAC Address  (ESb)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Inner Destination MAC Address | Inner Source MAC Address      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Inner Source MAC Address  (ESa)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Ethertype = C-Tag [802.1Q-2005]| Inner.VLAN Tag Information    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Payload:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Ethertype of Original Payload |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
      |                                  Original Ethernet Payload    |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Frame Check Sequence:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               New FCS (Frame Check Sequence)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 7: TRILL Data Encapsulation over Ethernet

4.1.1.  VLAN Tag Information

   A "VLAN Tag" (formerly known as a Q-tag), also known as a "C-tag" for
   customer tag, includes a VLAN ID and a priority field as shown in
   Figure 8.  The "VLAN ID" may be zero, indicating that no VLAN is
   specified, just a priority, although such frames are called "priority
   tagged" rather than "VLAN tagged" [802.1Q-2005].

   Use of [802.1ad] S-tags, also known as service tags, and use of
   stacked tags, are beyond the scope of this document.

     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     | Priority  | C |                  VLAN ID                      |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

                      Figure 8: VLAN Tag Information

   As recommended in [802.1Q-2005], Rbridges SHOULD be implemented so as
   to allow use of the full range of VLAN IDs from 0x001 through 0xFFE.
   Rbridges MAY support a smaller number of simultaneously active VLAN
   IDs.  VLAN ID zero is the null VLAN identifier and indicates that no
   VLAN is specified while VLAN ID 0xFFF is reserved.

   The VLAN ID 0xFFF MUST NOT be used.  Rbridges MUST discard any frame
   they receive with an Outer.VLAN ID of 0xFFF.  Rbridges MUST discard
   any frame for which they examine the Inner.VLAN ID and find it to be
   0xFFF; such examination is required at all egress Rbridges that
   decapsulate a frame.

   The "C" bit shown in Figure 8 is not used in the Inner.VLAN in TRILL.
   It MUST be set to zero there by ingress RBridges, transparently
   forwarded by transit RBridges, and is ignored by egress RBridges.

   As specified in [802.1Q-2005], the priority field contains an
   unsigned value from 0 through 7 where 1 indicates the lowest
   priority, 7 the highest priority, and the default priority zero is
   considered to be higher than priority 1 but lower than priority 2.
   The [802.1ad] amendment to [802.1Q-2005] permits mapping some
   adjacent pairs of priority levels into a single priority level with
   and without drop eligibility.  Ongoing work in IEEE 802.1 (802.1az,
   Appendix E) suggests the ability to configure "priority groups" that
   have a certain guaranteed bandwidth.  RBridges ports MAY also
   implement such options.  RBridges are not required to implement any
   particular number of distinct priority levels but may treat one or
   more adjacent priority levels in the same fashion.

   Frames with the same source address, destination address, VLAN, and
   priority that are received on the same port as each other and are
   transmitted on the same port MUST be transmitted in the order
   received unless the RBridge classifies the frames into more fine-
   grained flows, in which case this ordering requirement applies to
   each such flow.  Frames in the same VLAN with the same priority and
   received on the same port may be sent out different ports if
   multipathing is in effect.  (See Appendix C.)

   The C-Tag Ethertype [RFC5342] is 0x8100.

4.1.2.  Inner VLAN Tag

   The "Inner VLAN Tag Information" (Inner.VLAN) field contains the VLAN
   tag information associated with the native frame when it was
   ingressed or the VLAN tag information associated with a TRILL ESADI
   frame when that frame was created.  When a TRILL frame passes through
   a transit RBridge, the Inner.VLAN MUST NOT be changed except when
   VLAN mapping is being intentionally performed within that RBridge.

   When a native frame arrives at an RBridge, the associated VLAN ID and
   priority are determined as specified in [802.1Q-2005] (see Appendix D
   and [802.1Q-2005], Section 6.7).  If the RBridge is an appointed
   forwarder for that VLAN and the delivery of the frame requires
   transmission to one or more other links, this ingress RBridge forms a
   TRILL Data frame with the associated VLAN ID and priority placed in
   the Inner.VLAN information.

   The VLAN ID is required at the ingress Rbridge as one element in
   determining the appropriate egress Rbridge for a known unicast frame
   and is needed at the ingress and every transit Rbridge for multi-
   destination frames to correctly prune the distribution tree.

4.1.3.  Outer VLAN Tag

   TRILL frames sent by an RBridge, except for some TRILL-Hello frames,
   use an Outer.VLAN ID specified by the Designated RBridge (DRB) for
   the link onto which they are being sent, referred to as the
   Designated VLAN.  For TRILL data and ESADI frames, the priority in
   the Outer.VLAN tag SHOULD be set to the priority in the Inner.VLAN
   tag.

   TRILL frames forwarded by a transit RBridge use the priority present
   in the Inner.VLAN of the frame as received.  TRILL Data frames are
   sent with the priority associated with the corresponding native frame
   when received (see Appendix D).  TRILL IS-IS frames SHOULD be sent
   with priority 7.

   Whether an Outer.VLAN tag actually appears on the wire when a TRILL
   frame is sent depends on the configuration of the RBridge port
   through which it is sent in the same way as the appearance of a VLAN
   tag on a frame sent by an [802.1Q-2005] bridge depends on the
   configuration of the bridge port (see Section 4.9.2).

4.1.4.  Frame Check Sequence (FCS)

   Each Ethernet frame has a single Frame Check Sequence (FCS) that is
   computed to cover the entire frame, for detecting frame corruption
   due to bit errors on a link.  Thus, when a frame is encapsulated, the
   original FCS is not included but is discarded.  Any received frame
   for which the FCS check fails SHOULD be discarded (this may not be
   possible in the case of cut through forwarding).  The FCS normally
   changes on encapsulation, decapsulation, and every TRILL hop due to
   changes in the outer destination and source addresses, the
   decrementing of the hop count, etc.

   Although the FCS is normally calculated just before transmission, it
   is desirable, when practical, for an FCS to accompany a frame within
   an RBridge after receipt.  That FCS could then be dynamically updated
   to account for changes to the frame during Rbridge processing and
   used for transmission or checked against the FCS calculated for frame
   transmission.  This optional, more continuous use of an FCS would be
   helpful in detecting some internal RBridge failures such as memory
   errors.

4.2.  Link State Protocol (IS-IS)

   TRILL uses an extension of IS-IS [ISO10589] [RFC1195] as its routing
   protocol.  IS-IS has the following advantages:

   o  It runs directly over Layer 2, so therefore it may be run without
      configuration (no IP addresses need to be assigned).

   o  It is easy to extend by defining new TLV (type-length-value) data
      elements and sub-elements for carrying TRILL information.

   This section describes TRILL use of IS-IS, except for the TRILL-Hello
   protocol, which is described in Section 4.4, and the MTU-probe and
   MTU-ack messages that are described in Section 4.3.

4.2.1.  IS-IS RBridge Identity

   Each RBridge has a unique 48-bit (6-octet) IS-IS System ID.  This ID
   may be derived from any of the RBridge's unique MAC addresses.

   A pseudonode is assigned a 7-octet ID by the DRB that created it, by
   taking a 6-octet ID owned by the DRB, and appending another octet.
   The 6-octet ID used to form a pseudonode ID SHOULD be the DRB's ID
   unless the DRB has to create IDs for pseudonodes for more than 255
   links.  The only constraint for correct operation is that the 7-octet
   ID be unique within the campus, and that the 7th octet be nonzero.
   An RBridge has a 7-octet ID consisting of its 6-octet system ID
   concatenated with a zero octet.

   In this document, we use the term "IS-IS ID" to refer to the 7-octet
   quantity that can be either the ID of an RBridge or a pseudonode.

4.2.2.  IS-IS Instances

   TRILL implements a separate IS-IS instance from any used by Layer 3,
   that is, different from the one used by routers.  Layer 3 IS-IS
   frames must be distinguished from TRILL IS-IS frames even when those
   Layer 3 IS-IS frames are transiting an RBridge campus.

   Layer 3 IS-IS native frames have special multicast destination
   addresses specified for that purpose, such as AllL1ISs or AllL2ISs.
   When they are TRILL encapsulated, these multicast addresses appear as
   the Inner.MacDA and the Outer.MacDA will be the All-RBridges
   multicast address.

   Within TRILL, there is an IS-IS instance across all Rbridges in the
   campus as described in Section 4.2.3.  This instance uses TRILL IS-IS
   frames that are distinguished by having a different Ethertype
   "L2-IS-IS".  Additionally, for TRILL IS-IS frames that are multicast,
   there is a distinct multicast destination address of
   All-IS-IS-RBridges.  TRILL IS-IS frames do not have a TRILL header.

   ESADI is a separate protocol from the IS-IS instance implemented by
   all the RBridges.  There is a separate ESADI instance for each VLAN,
   and ESADI frames are encapsulated just like TRILL Data frames.  After
   the TRILL header, the ESADI frame has an inner Ethernet header with
   the Inner.MacDA of "All-ESADI-RBridges" and the "L2-IS-IS" Ethertype
   followed by the ESADI frame.

4.2.3.  TRILL IS-IS Frames

   All Rbridges MUST participate in the TRILL IS-IS instance, which
   constitutes a single Level 1 IS-IS area using the fixed area address
   zero.  TRILL IS-IS frames are never forwarded by an RBridge but are
   locally processed on receipt.  (Such processing may cause the RBridge
   to send additional TRILL IS-IS frames.)

   A TRILL IS-IS frame on an 802.3 link is structured as shown below.
   All such frames are Ethertype encoded.  The RBridge port out of which
   such a frame is sent will strip the outer VLAN tag if configured to
   do so.

   Outer Ethernet Header:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             All-IS-IS-RBridges Multicast Address              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | All-IS-IS-RBridges continued  | Source RBridge MAC Address    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Source RBridge MAC Address continued              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Ethertype = C-Tag [802.1Q-2005]| Outer.VLAN Tag Information    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   L2-IS-IS Ethertype          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   IS-IS Payload:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs    |

   Frame Check Sequence:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 FCS (Frame Check Sequence)                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 9: TRILL IS-IS Frame Format

   The VLAN specified in the Outer.VLAN information will be the
   Designated VLAN for the link on which the frame is sent, except in
   the case of some TRILL Hellos.

4.2.4.  TRILL Link Hellos, DRBs, and Appointed Forwarders

   RBridges default to using TRILL Hellos unless, on a per-port basis,
   they are configured to use P2P Hellos.  TRILL-Hello frames are
   specified in Section 4.4.

   RBridges are normally configured to use P2P Hellos only when there
   are exactly two of them on a link.  However, it can occur that
   RBridges are misconfigured as to which type of hello to use.  This is
   safe but may cause lack of RBridge-to-RBridge connectivity.  An
   RBridge port configured to use P2P Hellos ignores TRILL Hellos, and
   an RBridge port configured to use TRILL Hellos ignores P2P Hellos.

   If any of the RBridge ports on a link is configured to use TRILL
   Hellos, one of such RBridge ports using TRILL Hellos is elected DRB
   (Designated RBridge) for the link.  This election is based on

   configured priority (most significant field), and source MAC address,
   as communicated by TRILL-Hello frames.  The DRB, as described in
   Section 4.2.4.2, designates the VLAN to be used on the link for
   inter-RBridge communication by the non-P2P RBridge ports and appoints
   itself or other RBridges on the link as appointed forwarder (see
   Section 4.2.4.3) for VLANs on the link.

4.2.4.1.  P2P Hello Links

   RBridge ports can be configured to use IS-IS P2P Hellos.  This
   implies that the port is a point-to-point link to another RBridge.
   An RBridge MUST NOT provide any end-station (native frame) service on
   a port configured to use P2P Hellos.

   As with Layer 3 IS-IS, such P2P ports do not participate in a DRB
   election.  They send all frames VLAN tagged as being in the Desired
   Designated VLAN configured for the port, although this tag may be
   stripped if the port is so configured.  Since all traffic through the
   port should be TRILL frames or Layer 2 control frames, such a port
   cannot be an appointed forwarder.  RBridge P2P ports MUST use the
   IS-IS three-way handshake [RFC5303] so that extended circuit IDs are
   associated with the link for tie breaking purposes (see Section
   4.5.2).

   Even if all simple links in a network are physically point-to-point,
   if some of the nodes are bridges, the bridged LANs that include those
   bridges appear to be multi-access links to attached RBridges.  This
   would necessitate using TRILL Hellos for proper operation in many
   cases.

   While it is safe to erroneously configure ports as P2P, this may
   result in lack of connectivity.

4.2.4.2.  Designated RBridge

   TRILL IS-IS elects one RBridge for each LAN link to be the Designated
   RBridge (DRB), that is, to have special duties.  The Designated
   RBridge:

   o  Chooses, for the link, and announces in its TRILL Hellos, the
      Designated VLAN ID to be used for inter-RBridge communication.
      This VLAN is used for all TRILL-encapsulated data and ESADI frames
      and TRILL IS-IS frames except some TRILL-Hello frames.

   o  If the link is represented in the IS-IS topology as a pseudonode,
      chooses a pseudonode ID and announces that in its TRILL Hellos and
      issues an LSP on behalf of the pseudonode.

   o  Issues CSNPs.

   o  For each VLAN-x appearing on the link, chooses an RBridge on the
      link to be the appointed VLAN-x forwarder (the DRB MAY choose
      itself to be the appointed VLAN-x forwarder for all or some of the
      VLANs).

   o  Before appointing a VLAN-x forwarder (including appointing
      itself), wait at least its Holding Time (to ensure it is the DRB).

   o  If configured to send TRILL-Hello frames, continues to send them
      on all its enabled VLANs that have been configured in the
      Announcing VLANs set of the DRB, which defaults to all enabled
      VLANs.

4.2.4.3.  Appointed VLAN-x Forwarder

   The appointed VLAN-x forwarder for a link is responsible for the
   following points.  In connection with the loop avoidance points, when
   an appointed forwarder for a port is "inhibited", it drops any native
   frames it receives and does not transmit but instead drops any native
   frames it decapsulates, in the VLAN for which it is appointed.

   o  Loop avoidance:

      -  Inhibiting itself for a time, configurable per port from zero
         to 30 seconds, which defaults to 30 seconds, after it sees a
         root bridge change on the link (see Section 4.9.3.2).

      -  Inhibiting itself for VLAN-x, if it has received a Hello in
         which the sender asserts that it is appointed forwarder and
         that is either
         +  received on VLAN-x (has VLAN-x as its Outer.VLAN) or
         +  was originally sent on VLAN-x as indicated inside the body
            of the Hello.

      -  Optionally, not decapsulating a frame from ingress RBridge RBm
         unless it has RBm's LSP, and the root bridge on the link it is
         about to forward onto is not listed in RBm's list of root
         bridges for VLAN-x.  This is known as the "decapsulation check"
         or "root bridge collision check".

   o  Unless inhibited (see above), receiving VLAN-x native traffic from
      the link and forwarding it as appropriate.

   o  Receiving VLAN-x traffic for the link and, unless inhibited,
      transmitting it in native form after decapsulating it as
      appropriate.

   o  Learning the MAC address of local VLAN-x nodes by looking at the
      source address of VLAN-x frames from the link.

   o  Optionally learning the port of local VLAN-x nodes based on any
      sort of Layer 2 registration protocols, such as IEEE 802.11
      association and authentication.

   o  Keeping track of the { egress RBridge, VLAN, MAC address } of
      distant VLAN-x end nodes, learned by looking at the fields
      { ingress RBridge, Inner.VLAN ID, Inner.MacSA } from VLAN-x frames
      being received for decapsulation onto the link.

   o  Optionally observe native IGMP [RFC3376], MLD [RFC2710], and MRD
      [RFC4286] frames to learn the presence of local multicast
      listeners and multicast routers.

   o  Optionally listening to TRILL ESADI messages for VLAN-x to learn
      { egress RBridge, VLAN-x, MAC address } triplets and the
      confidence level of such explicitly advertised end nodes.

   o  Optionally advertising VLAN-x end nodes, on links for which it is
      appointed VLAN-x forwarder, in ESADI messages.

   o  Sending TRILL-Hello frames on VLAN-x unless the Announcing VLANs
      set for the port has been configured to disable them.

   o  Listening to BPDUs on the common spanning tree to learn the root
      bridge, if any, for that link and to report in its LSP the
      complete set of root bridges seen on any of its links for which it
      is appointed forwarder for VLAN-x.

   When an appointed forwarder observes that the DRB on a link has
   changed, it no longer considers itself appointed for that link until
   appointed by the new DRB.

4.2.4.4.  TRILL LSP Information

   The information items in the TRILL IS-IS LSP that are mentioned
   elsewhere in this document are listed below.  Unless an item is
   stated in the list below to be optional, it MUST be included.  Other
   items MAY be included unless their inclusion is prohibited elsewhere
   in this document.  The actual encoding of this information and the
   IS-IS Type or sub-Type values for any new IS-IS TLV or sub-TLV data
   elements are specified in separate documents [RFC6165] [RFC6326].

   1. The IS-IS IDs of neighbors (pseudonodes as well as RBridges) of
      RBridge RBn, and the cost of the link to each of those neighbors.
      RBridges MUST use the Extended IS Reachability TLV (#22, also

      known as "wide metric" [RFC5305]) and MUST NOT use the IS
      Reachability TLV (#2, also known as "narrow metric").  To
      facilitate efficient operation without configuration and
      consistent with [802.1D], RBridges SHOULD, by default, set the
      cost of a link to the integer part of twenty trillion
      (20,000,000,000,000) divided by the RBridge port's bit rate but
      not more than 2**24-2 (16,777,214); for example, the cost for a
      link accessed by a 1Gbps port would default to 20,000.  (Note that
      2**24-1 has a special meaning in IS-IS and would exclude the link
      from SPF routes.)  However, the link cost MAY, by default, be
      decreased for aggregated links and/or increased to not more than
      2**24-2 if the link appears to be a bridged LAN.  The tested MTU
      for the link (see Section 4.3) MAY be included via a sub-TLV.

   2. The following information in connection with the nickname or each
      of the nicknames of RBridge RBn:

      2.1. The nickname value (2 octets).

      2.2. The unsigned 8-bit priority for RBn to have that nickname
           (see Section 3.7.3).

      2.3. The 16-bit unsigned priority of that nickname to becoming a
           distribution tree root.

   3. The maximum TRILL Header Version supported by RBridge RBn.

   4. The following information, in addition to the per-nickname tree
      root priority, in connection with distribution tree determination
      and announcement.  (See Section 4.5 for further details on how
      this information is used.)

      4.1. An unsigned 16-bit number that is the number of trees all
           RBridges in the campus calculate if RBn has the highest
           priority tree root.

      4.2. A second unsigned 16-bit number that is the number of trees
           RBn would like to use.

      4.3. A third unsigned 16-bit number that is the maximum number of
           distribution trees that RBn is able to calculate.

      4.4. A first list of nicknames that are intended distribution
           trees for all RBridges in the campus to calculate.

      4.5. A second list of nicknames that are distribution trees RBn
           would like to use when ingressing multi-destination frames.

   5. The list of VLAN IDs of VLANs directly connected to RBn for links
      on which RBn is the appointed forwarder for that VLAN.  (Note: An
      RBridge may advertise that it is connected to additional VLANs in
      order to receive additional frames to support certain VLAN-based
      features beyond the scope of this specification as mentioned in
      Section 4.8.4 and in a separate document concerning VLAN mapping
      inside RBridges.) RBridges may associate advertised connectivity
      to different groups of VLANs with specific nicknames they hold.
      In addition, the LSP contains the following information on a per-
      VLAN basis:

      5.1. Per-VLAN Multicast Router attached flags: This is two bits of
           information that indicate whether there is an IPv4 and/or
           IPv6 multicast router attached to the Rbridge on that VLAN.
           An RBridge that does not do IP multicast control snooping
           MUST set both of these bits (see Section 4.5.4).  This
           information is used because IGMP [RFC3376] and MLD [RFC2710]
           Membership Reports MUST be transmitted to all links with IP
           multicast routers, and SHOULD NOT be transmitted to links
           without such routers.  Also, all frames for IP-derived
           multicast addresses MUST be transmitted to all links with IP
           multicast routers (within a VLAN), in addition to links from
           which an IP node has explicitly asked to join the group the
           frame is for, except for some IP multicast addresses that
           MUST be treated as broadcast.

      5.2. Per-VLAN mandatory announcement of the set of IDs of Root
           bridges for any of RBn's links on which RBn is appointed
           forwarder for that VLAN.  Where MSTP (Multiple Spanning Tree
           Protocol) is running on a link, this is the root bridge of
           the CIST (Common and Internal Spanning Tree).  This is to
           quickly detect cases where two Layer 2 clouds accidentally
           get merged, and where there might otherwise temporarily be
           two DRBs for the same VLAN on the same link.  (See Section
           4.2.4.3.)

      5.3. Optionally, per-VLAN Layer 2 multicast addresses derived from
           IPv4 IGMP and IPv6 MLD notification messages received from
           attached end nodes on that VLAN, indicating the location of
           listeners for these multicast addresses (see Section 4.5.5).

      5.4. Per-VLAN ESADI protocol participation flag, priority, and
           holding time.  If this flag is one, it indicates that the
           RBridge wishes to receive such TRILL ESADI frames (see
           Section 4.2.5.1).

      5.5. Per-VLAN appointed forwarder status lost counter (see Section
           4.8.3).

   6. Optionally, the largest TRILL IS-IS frame that the RBridge can
      handle using the originatingLSPBufferSize TLV #14 (see Section
      4.3).

   7. Optionally, a list of VLAN groups where address learning is shared
      across that VLAN group (see Section 4.8.4).  Each VLAN group is a
      list of VLAN IDs, where the first VLAN ID listed in a group, if
      present, is the "primary" and the others are "secondary".  This is
      to detect misconfiguration of features outside the scope of this
      document.  RBridges that do not support features such as "shared
      VLAN learning" ignore this field.

   8. Optionally, the Authentication TLV #10 (see Section 6).

4.2.5.  The TRILL ESADI Protocol

   RBridges that are the appointed VLAN-x forwarder for a link MAY
   participate in the TRILL ESADI protocol for that VLAN.  But all
   transit RBridges MUST properly forward TRILL ESADI frames as if they
   were multicast TRILL Data frames.  TRILL ESADI frames are structured
   like IS-IS frames but are always TRILL encapsulated on the wire as if
   they were TRILL Data frames.

   Because of this forwarding, it appears to the ESADI protocol at an
   RBridge that it is directly connected by a shared virtual link to all
   other RBridges in the campus running ESADI for that VLAN.  RBridges
   that do not implement the ESADI protocol or are not appointed
   forwarder for that VLAN do not decapsulate or locally process any
   TRILL ESADI frames they receive for that VLAN.  In other words, these
   frames are transparently tunneled through transit RBridges.  Such
   transit RBridges treat them exactly as multicast TRILL Data frames
   and no special processing is invoked due to such forwarding.

   TRILL ESADI frames sent on an IEEE 802.3 link are structured as shown
   below.  The outer VLAN tag will not be present if it was stripped by
   the port out of which the frame was sent.

   Outer Ethernet Header:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Next Hop Destination Address                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Next Hop Destination Address  | Sending RBridge MAC Address   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Sending RBridge Port MAC Address                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Ethertype = C-Tag [802.1Q-2005]| Outer.VLAN Tag Information    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   TRILL Header:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Ethertype = TRILL             | V | R |M|Op-Length| Hop Count |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Egress (Dist. Tree) Nickname  | Ingress (Origin) Nickname     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Inner Ethernet Header:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             All-ESADI-RBridges Multicast Address              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | All-ESADI-RBridges continued  | Origin RBridge MAC Address    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Origin RBridge MAC Address continued           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Ethertype = C-Tag [802.1Q-2005]| Inner.VLAN Tag Information    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Ethertype = L2-IS-IS          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ESADI Payload (formatted as IS-IS):
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs    |

   Frame Check Sequence:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  FCS (Frame Check Sequence)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 10: TRILL ESADI Frame Format

   The Next Hop Destination Address or Outer.MacDA is the All-RBridges
   multicast address.  The VLAN specified in the Outer.VLAN information
   will always be the Designated VLAN for the link on which the frame is
   sent.  The V and R fields will be zero while the M field will be one.
   The VLAN specified in the Inner.VLAN information will be the VLAN to
   which the ESADI frame applies.  The Origin RBridge MAC Address or
   Inner.MacSA MUST be a globally unique MAC address owned by the

   RBridge originating the ESADI frame, for example, any of its port MAC
   addresses, and each RBridge MUST use the same Inner.MacSA for all of
   the ESADI frames that RBridge originates.

4.2.5.1.  TRILL ESADI Participation

   An RBridge does not send any Hellos because of participation in the
   ESADI protocol.  The information available in the TRILL IS-IS link
   state database is sufficient to determine the ESADI DRB on the
   virtual link for the ESADI protocol for each VLAN.  In particular,
   the link state database information for each RBridge includes the
   VLANs, if any, for which that RBridge is participating in the ESADI
   protocol, its priority for being selected as DRB for the ESADI
   protocol for each of those VLANs, its holding time, and its IS-IS
   system ID for breaking ties in priority.

   An RBridge need not perform any routing calculation because of
   participation in the ESADI protocol.  Since all RBridges
   participating in ESADI for a particular VLAN appear to be connected
   to the same single virtual link, there are no routing decisions to be
   made.  A participating RBridge merely transmits the ESADI frames it
   originates on this virtual link.

   The ESADI DRB sends TRILL-ESADI-CSNP frames on the ESADI virtual
   link.  For robustness, a participating RBridge that determines that
   some other RBridge should be ESADI DRB on such a virtual link but has
   not received or sent a TRILL-ESADI-CSNP in at least the ESADI DRB
   holding time MAY also send a TRILL-ESADI-CSNP on the virtual link.  A
   participating RBridge that determines that no other RBridges are
   participating in the ESADI protocol for a particular VLAN SHOULD NOT
   send ESADI information or TRILL-ESADI-CSNPs on the virtual link for
   that VLAN.

4.2.5.2.  TRILL ESADI Information

   The information distributed with the ESADI protocol is the list of
   local end-station MAC addresses known to the originating RBridge and,
   for each such address, a one-octet unsigned "confidence" rating in
   the range 0-254 (see Section 4.8).

   It is intended to optionally provide for VLAN ID translation within
   RBridges, as specified in [VLAN-MAPPING].  This includes translating
   TRILL ESADI frames.  If TRILL ESADI frames could contain VLAN IDs in
   arbitrary internal locations, such translation would be impractical.
   Thus, TRILL ESADI frames MUST NOT contain the VLAN ID of the VLAN to
   which they apply in the body of the frame after the Inner.VLAN tag.

4.2.6.  SPF, Forwarding, and Ambiguous Destinations

   This section describes the logical result desired.  Alternative
   implementation methods may be used as long as they produce the same
   forwarding behavior.

   When building a forwarding table, an RBridge RB1 calculates shortest
   paths from itself as described in Appendix C.1 of [RFC1195].
   Nicknames are added into the shortest path calculation as a final
   step, just as with an end node.  If multiple RBridges, say, RBa and
   RBb, claim the same nickname, this is a transitory condition and one
   of RBa or RBb will defer and choose a new nickname.  However, RB1
   simply adds that nickname as if it were attached to both RBa and RBb,
   and uses its standard shortest path calculation to choose the next
   hop.

   An ingress RBridge RB2 maps a native frame's known unicast
   destination MAC address and VLAN into an egress RBridge nickname.  If
   RB2 learns addresses only from the observation of received and
   decapsulated frames, then such MAC addresses cannot be duplicated
   within a VLAN in RB2 tables because more recent learned information,
   if of a higher or equal confidence, overwrites previous information
   and, if of a lower confidence, is ignored.  However, duplicates of
   the same MAC within a VLAN can appear in ESADI data and between ESADI
   data and addresses learned from the observation of received and
   decapsulated frames, entered by manual configuration, or learned
   through Layer 2 registration protocols.  If duplicate MAC addresses
   occur within a VLAN, RB2 sends frames to the MAC with the highest
   confidence.  If confidences are also tied between the duplicates, for
   consistency it is suggested that RB2 direct all such frames (or all
   such frames in the same ECMP flow) toward the same egress RBridge;
   however, the use of other policies will not cause a network problem
   since transit RBridges do not examine the Inner.MacDA for known
   unicast frames.

4.3.  Inter-RBridge Link MTU Size

   There are two reasons why it is important to know what size of frame
   each inter-RBridge link in the campus can support:

   1. RBridge RB1 must know the size of link state information messages
      it can generate that will be guaranteed to be forwardable across
      all inter-RBridge links in the campus.

   2. If traffic engineering tools know which links support larger than
      minimally acceptable data packet sizes, paths can be computed that
      can support large data packets.

4.3.1.  Determining Campus-Wide TRILL IS-IS MTU Size

   In a stable campus, there must ultimately be agreement among all
   RBridges on the value of "Sz", the minimum acceptable inter-RBridge
   link size for the campus, for the proper operation of TRILL IS-IS.
   All RBridges MUST format their link state information messages to be
   in chunks of size no larger than what they believe Sz to be.  Also,
   every RBridge RB1 SHOULD test each of its RBridge adjacencies, say,
   to RB2, to ensure that the RB1-RB2 link can forward packets of at
   least size Sz.

   Sz has no direct effect on end stations and is not directly related
   to any end-station-to-end-station "path MTU".  Methods of using Sz or
   any link MTU information gathered by TRILL IS-IS in the traffic
   engineering of routes or the determination of any path MTU is beyond
   the scope of this document.  Native frames that, after TRILL
   encapsulation, exceed the MTU of a link on which they are sent will
   generally be discarded.

   Sz is determined by having each RBridge (optionally) advertise, in
   its LSP, its assumption of the value of the campus-wide Sz.  This LSP
   element is known in IS-IS as the originatingLSPBufferSize, TLV #14.
   The default and minimum value for Sz, and the implicitly advertised
   value of Sz if the TLV is absent, is 1470 octets.  This length (which
   is also the maximum size of a TRILL-Hello) was chosen to make it
   extremely unlikely that a TRILL control frame, even with reasonable
   additional headers, tags, and/or encapsulation, would encounter MTU
   problems on an inter-RBridge link.

   The campus-wide value of Sz is the smallest value of Sz advertised by
   any RBridge.

4.3.2.  Testing Link MTU Size

   There are two new TRILL IS-IS message types for use between pairs of
   RBridge neighbors to test the bidirectional packet size capacity of
   their connection.  These messages are:

      -- MTU-probe
      -- MTU-ack

   Both the MTU-probe and the MTU-ack are padded to the size being
   tested.

   Sending of MTU-probes is optional; however, an RBridge RB2 that
   receives an MTU-probe from RB1 MUST respond with an MTU-ack padded to
   the same size as the MTU-probe.  The MTU-probe MAY be multicast to

   All-RBridges, or unicast to a specific RBridge.  The MTU-ack is
   normally unicast to the source of the MTU-probe to which it responds
   but MAY be multicast to All-RBridges.

   If RB1 fails to receive an MTU-ack to a probe of size X from RB2
   after k tries (where k is a configurable parameter whose default is
   3), then RB1 assumes the RB1-RB2 link cannot support size X.  If X is
   not greater than Sz, then RB1 sets the "failed minimum MTU test" flag
   for RB2 in RB1's Hello.  If size X succeeds, and X > Sz, then RB1
   advertises the largest tested X for each adjacency in the TRILL
   Hellos RB1 sends on that link, and RB1 MAY advertise X as an
   attribute of the link to RB2 in RB1's LSP.