Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 6325

Routing Bridges (RBridges): Base Protocol Specification

Pages: 99
Proposed Standard
Updated by:  63276439717271777357717971807455778077838139824983618377
Part 2 of 4 – Pages 20 to 45
First   Prev   Next

Top   ToC   RFC6325 - Page 20   prevText

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.
Top   ToC   RFC6325 - Page 21
                                   | 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

   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.
Top   ToC   RFC6325 - Page 22

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.
Top   ToC   RFC6325 - Page 23
   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.
Top   ToC   RFC6325 - Page 24
   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.
Top   ToC   RFC6325 - Page 25
   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
Top   ToC   RFC6325 - Page 26
      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
Top   ToC   RFC6325 - Page 27
   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:
Top   ToC   RFC6325 - Page 28
   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,

   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.
Top   ToC   RFC6325 - Page 29
     +-----+  +-------+   +-------+       +-------+   +-------+  +----+
     | 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    |
      | Ethertype of Original Payload |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
      |                                  Original Ethernet Payload    |
      |                                                               |
   Frame Check Sequence:
      |               New FCS (Frame Check Sequence)                  |

             Figure 7: TRILL Data Encapsulation over Ethernet
Top   ToC   RFC6325 - Page 30

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.
Top   ToC   RFC6325 - Page 31
   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.
Top   ToC   RFC6325 - Page 32
   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.
Top   ToC   RFC6325 - Page 33
   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.)
Top   ToC   RFC6325 - Page 34
   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
Top   ToC   RFC6325 - Page 35
   configured priority (most significant field), and source MAC address,
   as communicated by TRILL-Hello frames.  The DRB, as described in
   Section, 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 for VLANs on the link. 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. 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.
Top   ToC   RFC6325 - Page 36
   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

   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. 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 - 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.
Top   ToC   RFC6325 - Page 37
   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. 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
Top   ToC   RFC6325 - Page 38
      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.
Top   ToC   RFC6325 - Page 39
   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

      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

      5.5. Per-VLAN appointed forwarder status lost counter (see Section
Top   ToC   RFC6325 - Page 40
   6. Optionally, the largest TRILL IS-IS frame that the RBridge can
      handle using the originatingLSPBufferSize TLV #14 (see Section

   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.
Top   ToC   RFC6325 - Page 41
   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
Top   ToC   RFC6325 - Page 42
   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. 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. 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.
Top   ToC   RFC6325 - Page 43

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.
Top   ToC   RFC6325 - Page 44

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
Top   ToC   RFC6325 - Page 45
   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.

(page 45 continued on part 3)

Next Section