tech-invite   World Map     

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

RFC 7455

 
 
 

Transparent Interconnection of Lots of Links (TRILL): Fault Management

Part 2 of 3, p. 11 to 38
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 11 
4.  TRILL OAM Layering vs. IEEE Layering

   This section presents the placement of the TRILL OAM shim within the
   IEEE 802.1 layers.  The transmit and receive processing are
   explained.

                       +-+-+-+-+-+-+-+-+-+-+
                       |   RBridge Layer   |
                       |   Processing      |
                       +-+-+-+-+-+-+-+-+-+-+
                                |
                                |
                            +-+-+-+-+-+-+
                            | TRILL OAM | UP MEP
                            | Layer     |   MIP
                            +-+-+-+-+-+-+ Down MEP
                                 |
                                 |
                            +-+-+-+-+-+-+
      (3)-------->          | TRILL     |
                            | Encap/Decap
                            +-+-+-+-+-+-+
                                |
                            +-+-+-+-+-+-+
      (2)-------->          |End-station|
                            | VLAN & Priority Processing
                            +-+-+-+-+-+-+
                                |
                            +-+-+-+-+-+-+
      (1)-------->          |ISS        |
                            |Processing |
                            +-+-+-+-+-+-+
                                |
                                |
                                |

           Figure 4: Placement of TRILL MP within IEEE 802.1

   [RFC6325], Section 4.6 as updated by [RFC7180] provides a detailed
   explanation of frame processing.  Please refer to those documents for
   additional details and for processing scenarios not covered herein.

   Sections 4.1 and 4.2 apply to links using a broadcast LAN technology
   such as Ethernet.

Top      Up      ToC       Page 12 
   On links using an inherently point-to-point technology, such as PPP
   [RFC6361], there is no Outer.MacDA, Outer.MacSA, or Outer.VLAN
   because these are part of the Link Header for Ethernet.  Point-to-
   point links typically have Link Headers without these fields.

4.1.  Processing at the ISS Layer

4.1.1.  Receive Processing

   The ISS layer receives an indication from the port.  It extracts DA
   and SA, and it marks the remainder of the payload as M1.  The ISS
   layer passes on (DA, SA, M1) as an indication to the higher layer.

   For TRILL Ethernet frames, this is Outer.MacDA and Outer.MacSA.  M1
   is the remainder of the packet.

4.1.2.  Transmit Processing

   The ISS layer receives an indication from the higher layer that
   contains (DA, SA, M1).  It constructs an Ethernet frame and passes
   down to the port.

4.2.  End-Station VLAN and Priority Processing

4.2.1.  Receive Processing

   Receive (DA, SA, M1) indication from the ISS layer.  Extract the VLAN
   ID and priority from the M1 part of the received indication (or
   derive them from the port defaults or other default parameters) and
   construct (DA, SA, VLAN, PRI, M2).  VLAN+PRI+M2 maps to M1 in the
   received indication.  Pass (DA, SA, VLAN, PRI, M2) to the TRILL
   Encapsulation/Decapsulation layer.

4.2.2.  Transmit Processing

   Receive (DA, SA, VLAN, PRI, M2) indication from the TRILL
   Encapsulation/Decapsulation layer.  Merge VLAN, PRI, M2 to form M1.
   Pass down (DA, SA, M1) to the ISS layer.

4.3.  TRILL Encapsulation and Decapsulation Layer

4.3.1.  Receive Processing for Unicast Packets

   o  Receive indication (DA, SA, VLAN, PRI, M2) from the End-Station
      VLAN and Priority Processing layer.

   o  If the DA matches the port Local DA and the frame is of TRILL
      Ethertype:

Top      Up      ToC       Page 13 
      -  Discard DA, SA, VLAN, and PRI.  From M2, derive (TRILL-HDR,
         iDA, iSA, i-VL, M3).

      -  If TRILL nickname is Local and TRILL Header Alert flag is set:

         *  Pass on to OAM processing.

      -  Else, pass on (TRILL-HDR, iDA, iSA, i-VL, M3) to the RBridge
         layer.

   o  If the DA matches the port Local DA and the Ethertype is RBridge-
      Channel [RFC7178]:

      -  Process as a possible unicast native RBridge Channel packet.

   o  If the DA matches the port Local DA and the Ethertype is neither
      TRILL nor RBridge-Channel:

      -  Discard packet.

   o  If the DA does not match, the port is Appointed Forwarder for
      VLAN, and the Ethertype is not TRILL or RBridge-Channel:

      -  Insert TRILL-HDR and send (TRILL-HDR, iDA, iSA,i-VL, M3)
         indication to the RBridge layer (this is the TRILL Ingress
         Function).

4.3.2.  Transmit Processing for Unicast Packets

   o  Receive indication (TRILL-HDR, iDA, iSA, iVL, M3) from the RBridge
      layer.

   o  If the egress TRILL nickname is local:

      -  If the port is Appointed Forwarder for iVL, the port is not
         configured as a trunk or point-to-point (P2P) port, the TRILL
         Alert flag is set, and the OAM Ethertype is present, then:

         *  Strip TRILL-HDR and construct (DA, SA, VLAN, M2) (this is
            the TRILL Egress Function).

      - Else:

         *  Discard packet.

Top      Up      ToC       Page 14 
   o  If the egress TRILL nickname is not local:

      -  Insert Outer.MacDA, Outer.MacSA, Outer.VLAN, and TRILL
         Ethertype, and construct (DA, SA, VLAN, M2) where M2 is (TRILL-
         HDR, iDA, iSA, iVL, M).

   o  Forward (DA, SA, V, M2) to the End-Station VLAN and Priority
      Processing layer.

4.3.3.  Receive Processing for Multicast Packets

   o  Receive (DA, SA, V, M2) from the End-Station VLAN and Priority
      Processing layer.

   o  If the DA is All-RBridges and the Ethertype is TRILL:

      -  Strip DA, SA, and V.  From M2, extract (TRILL-HDR, iDA, iSA,
         iVL, and M3).

      -  If the TRILL Alert flag is set and the OAM Ethertype is present
         at the end of Flow Entropy:

         *  Perform OAM processing.

      -  Else, extract the TRILL Header, inner MAC addresses, and
         Inner.VLAN, and pass indication (TRILL-HDR, iDA, iSA, iVL and
         M3) to the TRILL RBridge layer.

   o  If the DA is All-IS-IS-RBridges and the Ethertype is L2-IS-IS,
      then pass frame up to TRILL IS-IS processing.

   o  If the DA is All-RBridges or All-IS-IS-RBridges but the Ethertype
      is not TRILL or L2-IS-IS respectively:

      -  Discard the packet.

   o  If the Ethertype is TRILL but the multicast DA is not All-RBridges
      or if the Ethertype is L2-IS-IS but the multicast DA is not All-
      IS-IS-RBridges:

      -  Discard the packet.

   o  If the DA is All-Edge-RBridges and the Ethertype is RBridge-
      Channel [RFC7178]:

      -  Process as a possible multicast native RBridge Channel packet.

Top      Up      ToC       Page 15 
   o  If the DA is in the initial bridging/link protocols block
      (01-80-C2-00-00-00 to 01-80-C2-00-00-0F) or is in the TRILL block
      and not assigned for Outer.MacDA use (01-80-C2-00-00-42 to
      01-80-C2-00-00-4F), then:

      -  The frame is not propagated through an RBridge although some
         special processing may be done at the port as specified in
         [RFC6325], and the frame may be dispatched to Layer 2
         processing at the port if certain protocols are supported by
         that port (examples include the Link Aggregation Protocol and
         the Link-Layer Discovery Protocol).

   o  If the DA is some other multicast value:

      -  Insert TRILL-HDR and construct (TRILL-HDR, iDA, iSA, IVL, M3).

      -  Pass the (TRILL-HDR, iDA, iSA, IVL, M3) to the RBridge layer.

4.3.4.  Transmit Processing of Multicast Packets

   The following ignores the case of transmitting TRILL IS-IS packets.

   o  Receive indication (TRILL-HDR, iDA, iSA, iVL, M3) from the RBridge
      layer.

   o  If the TRILL Header multicast ("M") flag is set, the TRILL-HDR
      Alert flag is set, and the OAM Ethertype is present, then:

      -  Construct (DA, SA, V, M2) by inserting TRILL Outer.MacDA of
         All-RBridges, Outer.MacSA, Outer.VLAN, and TRILL Ethertype.  M2
         here is (Ethertype TRILL, TRILL-HDR, iDA, iSA, iVL, M).

         Note: A second copy of native format is not made.

   o  Else, if the TRILL Header multicast ("M") flag is set and the
         Alert flag not set:

      -  If the port is Appointed Forwarder for iVL and the port is not
         configured as a trunk port or a P2P port, strip TRILL-HDR, iSA,
         iDA, and iVL and construct (DA, SA, V, M2) for native format.

      -  Make a second copy (DA, SA, V, M2) by inserting TRILL
         Outer.MacDA, Outer.MacSA, Outer.VLAN, and TRILL Ethertype.  M2
         here is (Ethertype TRILL, TRILL-HDR, iDA, iSA, iVL, M).

   o  Pass the indication (DA, SA, V, M2) to the End-Station VLAN and
      Priority Processing layer.

Top      Up      ToC       Page 16 
4.4.  TRILL OAM Layer Processing

   The TRILL OAM layer is located between the TRILL
   Encapsulation/Decapsulation layer and the RBridge layer.  It performs
   the following: 1) identifies OAM frames that need local processing
   and 2) performs OAM processing or redirects to the CPU for OAM
   processing.

   o  Receive indication (TRILL-HDR, iDA, iSA, iVL, M3) from the RBridge
      layer.  M3 is the payload after Inner.VLAN iVL.

   o  If the TRILL Header multicast ("M") flag is set, the TRILL Alert
      flag is set, and TRILL OAM Ethertype is present, then:

      -  If MEP or MIP is configured on the Inner.VLAN/FGL of the
         packet, then:

         *  Discard packets that have MD-Level less than that of the MEP
            or packets that do not have MD-Level present (e.g., due to
            packet truncation).

         *  If MD-Level matches MD-Level of the MEP, then:

            +  Redirect to OAM processing (Do not forward further).

         *  If MD-Level matches MD-Level of MIP, then:

            +  Make a copy for OAM processing and continue.

         *  If MD-Level matches MD-Level of MEP, then:

            +  Redirect the OAM packet to OAM processing and do not
               forward along or forward as a native packet.

   o  Else, if the TRILL Alert flag is set and the TRILL OAM Ethertype
      is present, then:

      -  If MEP or MIP is configured on the Inner.VLAN/FGL of the
         packet, then:

         *  Discard packets that have MD-Level not present or where MD-
            Level is less than that of the MEP.

         *  If MD-Level matches MD-Level of the MEP, then:

            +  Redirect to OAM processing (do not forward further).

Top      Up      ToC       Page 17 
         *  If MD-Level matches MD-Level of MIP, then:

            +  Make a copy for OAM processing and continue.

   o  Else, for a non-OAM packet:

      -  Continue.

   o  Pass the indication (DA, SA, V, M2) to the End-Station VLAN and
      Priority Processing layer.

   Note: In the receive path, the processing above compares with the
   Down MEP and MIP Half functions.  In the transmit processing, it
   compares with Up MEP and MIP Half functions.

   Appointed Forwarder is a function that the TRILL
   Encapsulation/Decapsulation layer performs.  The TRILL
   Encapsulation/Decapsulation layer is responsible for prevention of
   leaking of OAM packets as native frames.

5.  Maintenance Associations (MAs) in TRILL

   [8021Q] defines a Maintenance Association as a logical relationship
   between a group of nodes.  Each Maintenance Association (MA) is
   identified with a unique MAID of 48 bytes [8021Q].  CCM and other
   related OAM functions operate within the scope of an MA.  The
   definition of MA is technology independent.  Similarly, it is encoded
   within the OAM message, not in the technology-dependent portion of
   the packet.  Hence, the MAID as defined in [8021Q] can be utilized
   for TRILL OAM without modifications.  This also allows us to utilize
   CCM and LBM messages defined in [8021Q] as is.

   In TRILL, an MA may contain two or more RBridges (MEPs).  For
   unicast, it is likely that the MA contains exactly two MEPs that are
   the two end points of the flow.  For multicast, the MA may contain
   two or more MEPs.

   For TRILL, in addition to all of the standard [8021Q] CFM MIB
   definitions, each MEP's MIB contains one or more Flow Entropy
   definitions corresponding to the set of flows that the MEP monitors.

   [8021Q] CFM MIB is augmented to add the TRILL-specific information.
   Figure 5 depicts the augmentation of the CFM MIB to add the TRILL-
   specific Flow Entropy.

Top      Up      ToC       Page 18 
             MA---
            |
             --- MEP
            |
            . - Remote MEP List
                   .
                   |
                    --- MEP-A
                   |
                    --- MEP-B
                   .

            |
            . - Flow Entropy List { Augments IEEE8021-CFM-MIB}

                   |
                    --- (Flow Entropy-1)
                   |
                    --- (Flow Entropy-2)
                   |
                   . --- (Flow Entropy-n)
           |
            Other MIB entries

          Figure 5: Correlation of TRILL-Augmented MIB

   The detailed TRILL OAM MIB will be specified in a separate document
   [TRILLOAMMIB].

6.  MEP Addressing

   In IEEE CFM [8021Q], OAM messages address the target MEP by utilizing
   a unique MAC address.  In TRILL, a MEP is addressed by a combination
   of the egress RBridge nickname and the Inner.VLAN/FGL.

   Additionally, MEPs are represented by a 2-octet MEP-ID that is
   independent of the underlying technology.  In CFM [8021Q], the value
   of MEP-ID is restricted to the range of 1 to 8191.  However, on a CFM
   [8021Q] packet, MEP-IDs are encoded as a 2-octet field.  In the TRILL
   Base Mode operation presented in Appendix B, MEP-IDs are mapped
   1-to-1 with the RBridge nicknames.  Hence, in TRILL, a MEP-ID MUST be
   a number in the range from 1 to 65535.

   At the MEP, OAM packets go through a hierarchy of OpCode
   demultiplexers.  The OpCode demultiplexers channel the incoming OAM
   packets to the appropriate message processor (e.g., LBM).  Refer to
   Figure 6 for a visual depiction of these different demultiplexers.

Top      Up      ToC       Page 19 
   The demultiplexing sequence is as follows:

   1.  Identify the packets that need OAM processing at the local
       RBridge as specified in Section 4.

       a.  Identify the MEP that is associated with the Inner.VLAN/FGL.

   2.  The MEP first validates the MD-Level and then:

       a.  Redirects to the MD-Level demultiplexer.

   3.  The MD-Level demultiplexer compares the MD-Level of the packet
       against the MD-Level of the local MEPs of a given MD-Level on the
       port.  (Note: there can be more than one MEP at the same MD-Level
       but they belong to different MAs.)

       a.  If the packet MD-Level is equal to the configured MD-Level of
           the MEP, then pass to the OpCode demultiplexer.

       b.  If the packet MD-Level is less than the configured MD-Level
           of the MEP, discard the packet.

       c.  If the packet MD-Level is greater than the configured
           MD-Level of the MEP, then pass on to the next-higher MD-Level
           demultiplexer, if available.  Otherwise, if no such higher
           MD-Level demultiplexer exists, then forward the packet as
           normal data.

   4.  The OpCode demultiplexer compares the OpCode in the packet with
       supported OpCodes.

       a.  If the OpCode is CCM, LBM, LBR, PTM, PTR, MTVM, or MTVR, then
           pass on to the correct processor.

       b.  If the OpCode is unknown, then discard.

Top      Up      ToC       Page 20 
                            |
                            .CCM   LBM   PTM   MTVM . .
                            |      |    |      |
                          +-+-+-+-+-+-+-+-+-+-+-+-+
                          |        OP Code DE-Mux |--- Unknown
                          +-+-+-+-+-+-+-+-+-+-+-+-+
                            ^       ^          ^
                  MD==Li    |       |          |
                         +-+-+   +-+-+      +-+-+
                         | L |-->|L2 |-.-   |Ln |---- >
                         +-+-+   +-+-+      +-+-+      |
                          |  ^    |          |         |
                  MD<LI Drop |    Drop       Drop      |
                             |                         |
                  MD not --- |TRILL OAM need local     |
                  Present    | Processing              |
                             |                         |
                TRILL Data   ----  TRILL Data         ----
                   ------->| T  |----------------- >|  M |--- >
                + TRILL OAM  ----  + pass through OAM ----

            Figure 6: OAM Demultiplexers at MEP for Active SAP

   o  T: Denotes Tap.  Identifies OAM frames that need local processing.
      These are the packets with the Alert flag set and OAM Ethertype
      present after the Flow Entropy of the packet.

   o  M: The post-processing merge that merges data and OAM messages
      that are passed through.  Additionally, the merge component
      ensures, as explained earlier, that OAM packets are not forwarded
      out as native frames.

   o  L: Denotes MD-Level processing.  Packets whose MD-Level is less
      than the MD-Level of the current processing step will be dropped.
      Packets with equal MD-Levels are passed on to the OpCode
      demultiplexer.  Others are passed on to the next-level MD
      processors or eventually to the merge point (M).

   NOTE: LBM, LBR, MTVM, MTVR, PTM, and PTR are not subject to MA
   demultiplexers.  These packets do not have an MA encoded in the
   packet.  Adequate response can be generated to these packets, without
   loss of functionality, by any of the MEPs present on that interface
   or an entity within the RBridge.

Top      Up      ToC       Page 21 
6.1.  Use of MIP in TRILL

   Maintenance Intermediate Points (MIPs) are mainly used for fault
   isolation.  Link Trace Messages in [8021Q] utilize a well-known
   multicast MAC address, and MIPs generate responses to Link Trace
   Messages.  Response to Link Trace Messages or lack thereof can be
   used for fault isolation in TRILL.

   As explained in Section 10, a Hop Count expiry approach will be
   utilized for fault isolation and path tracing.  The approach is very
   similar to the well-known IP trace-route approach.  Hence, explicit
   addressing of MIPs is not required for the purpose of fault
   isolation.

   Any given RBridge can have multiple MIPs located within an interface.
   As such, a mechanism is required to identify which MIP should respond
   to an incoming OAM message.  Any MIP residing within the ingress
   interface may reply to the incoming Path Trace Message without loss
   of functionality or information.  As specified in Section 3.4, the
   address of the responding RBridge can be identified by means of the
   Sender ID TLV (1).  The Reply Ingress TLV (5) identifies the
   interface id.  The combination of these allows the recipient of the
   response to uniquely identify the responder.

   A similar approach to that presented above for MEPs can be used for
   MIP processing.  It is important to note that "M", the merge block of
   a MIP, does not prevent OAM packets leaking out as native frames.  On
   edge interfaces, MEPs MUST be configured to prevent the leaking of
   TRILL OAM packets out of the TRILL campus.

Top      Up      ToC       Page 22 
                      PTM     PTR     MTVM     MTVR
                       |       |     |      |
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |             OP Code De-Mux  |-> Unknown
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        ^       ^          ^
              MD==Li    |       |          |
                      +-+-+   +-+-+      +-+-+
                      | L |- >|L2 |-.-   |Ln |------+
                      +-+-+   +-+-+      +-+-+      |
                        ^                         |
                        |                         |
             Drop       |                         |
             MD not --- |TRILL OAM                |
             Present    |                         |
                        |                         v
         TRILL Data   ----  TRILL Data          -----
            ------- >| T  |------------------ >|  M  |---->
         + TRILL OAM  ----                      ----

          Figure 7: OAM Demultiplexers at MIP for Active SAP

   o  T: Tap processing for MIP.  All packets with the TRILL Header
      Alert flag set are captured.

   o  L: MD-Level Processing.  Packets with matching MD-Levels are
      "copied" to the OpCode demultiplexer, and the original packet is
      passed on to the next MD-Level processor.  Other packets are
      simply passed on to the next MD-Level processor without copying to
      the OpCode demultiplexer.

   o  M: The intermediate point processing merge that merges data and
      OAM messages that are passed through.

   Packets that carry Path Trace Message (PTM) or Multi-destination Tree
   Verification Message (MTVM) OpCodes are passed on to the respective
   processors.

   Packets with unknown OpCodes are counted and discarded.

7.  Continuity Check Message (CCM)

   CCMs are used to monitor connectivity and configuration errors.
   [8021Q] monitors connectivity by listening to periodic CCM messages
   received from its remote MEP partners in the MA.  An [8021Q] MEP
   identifies cross-connect errors by comparing the MAID in the received
   CCM message with the MEP's local MAID.  The MAID [8021Q] is a 48-byte
   field that is technology independent.  Similarly, the MEP-ID is a

Top      Up      ToC       Page 23 
   2-byte field that is independent of the technology.  Given this
   generic definition of CCM fields, CCM as defined in [8021Q] can be
   utilized in TRILL with no changes.  TRILL-specific information may be
   carried in CCMs when encoded using TRILL-specific TLVs or sub-TLVs.
   This is possible since CCMs may carry optional TLVs.

   Unlike classical Ethernet environments, TRILL contains multipath
   forwarding.  The path taken by a packet depends on the payload of the
   packet.  The Maintenance Association (MA) identifies the interested
   Maintenance End Points (MEPs) of a given monitored path.  For
   unicast, there are only two MEPs per MA.  For multicast, there can be
   two or more MEPs in the MA.  The entropy values of the monitored
   flows are defined within the MA.  CCM transmit logic will utilize
   these Flow Entropy values when constructing the CCM packets.  Please
   see Section 12 for the theory of operation of CCM.

   The MIB in [8021Q] is augmented with the definition of Flow Entropy.
   Please see [TRILLOAMMIB] for this and other TRILL-related OAM MIB
   definitions.  Figure 8 depicts the correlation between MA, CCM, and
   the Flow Entropy.

Top      Up      ToC       Page 24 
             MA---
            |
             --- MEP
            |
            . - Remote MEP List
                   .
                   |
                    --- MEP-A
                   |
                    --- MEP-B
                   .

            |
            . - Flow Entropy List {Augments IEEE8021-CFM-MIB}

                   |
                    --- (Flow Entropy-1)
                   |
                    --- (Flow Entropy-2)
                   |
                   . ---(Flow Entropy-n)
           |
           . - CCM
                  |
                   --- (standard 8021ag entries)
                  |
                   --- (Hop Count) { Augments IEEE8021-CFM-MIB}
                  |
                   --- (Any other TRILL OAM-specific entries)
                                                   {Augmented}
           |
           .
           |
            - Other MIB entries

               Figure 8: Augmentation of CCM MIB in TRILL

   In a multi-pathing environment, a flow, by definition, is
   unidirectional.  A question may arise as to what Flow Entropy should
   be used in the response.  CCMs are unidirectional and have no
   explicit reply; as such, the issue of the response Flow Entropy does
   not arise.  In the transmitted CCM, each MEP reports local status
   using the Remote Defect Indication (RDI) flag.  Additionally, a MEP
   may raise SNMP TRAPs [TRILLOAMMIB] as alarms when a connectivity
   failure occurs.

Top      Up      ToC       Page 25 
8.  TRILL OAM Message Channel

   The TRILL OAM Message Channel can be divided into two parts: TRILL
   OAM message header and TRILL OAM TLVs.  Every OAM message MUST
   contain a single TRILL OAM message header and a set of one or more
   specified OAM message TLVs.

8.1.  TRILL OAM Message Header

   As discussed earlier, a common messaging framework between [8021Q],
   TRILL, and other similar standards such as Y.1731 is accomplished by
   reusing the OAM message header defined in [8021Q].

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |MD-L | Version | OpCode        |  Flags        |FirstTLVOffset |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .   OpCode-Specific Information                                 .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .         TLVs                                                  .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 9: OAM Message Format

   o  MD-L: Maintenance Domain Level (3 bits).  For TRILL, in general,
      this field is set to a single value across the TRILL campus.  When
      using the TRILL Base Mode as specified in Appendix B, MD-L is set
      to 3.  However, extension of TRILL (for example, to support
      multilevel) may create different MD-Levels, and the MD-L field
      must be appropriately set in those scenarios.  (Please refer to
      [8021Q] for the definition of MD-Level).

   o  Version: Indicates the version (5 bits) as specified in [8021Q].
      This document does not require changing the Version defined in
      [8021Q].

   o  OpCode: Operation Code (8 bits).  Specifies the operation
      performed by the message.  See Section 8.2.

   o  Flags: Includes operational flags (1 byte).  The definition of
      flags is OpCode-specific and is covered in the applicable
      sections.

Top      Up      ToC       Page 26 
   o  FirstTLVOffset: Defines the location of the first TLV, in bytes,
      starting from the end of the FirstTLVOffset field (1 byte).
      (Refer to [8021Q] for the definition of the FirstTLVOffset.)

   o  OpCode-Specific Information: May contain Session Identification
      Number, timestamp, etc.

   The MD-L, Version, OpCode, Flags, and FirstTLVOffset fields
   collectively are referred to as the OAM message header.

8.2.  TRILL-Specific OAM OpCodes

   The following TRILL-specific CFM OpCodes are defined.  Each of the
   OpCodes indicates a separate type of TRILL OAM message.  Details of
   the messages are presented in Sections 10 and 11.

   TRILL OAM message OpCodes:

      64: Path Trace Reply
      65: Path Trace Message
      66: Multi-destination Tree Verification Reply
      67: Multi-destination Tree Verification Message

   Loopback and CCM Messages reuse the OpCodes defined by [8021Q].

8.3.  Format of TRILL OAM TLV

   The same CFM TLV format as defined in [8021Q] is used for TRILL OAM.
   The following figure depicts the general format of a TRILL OAM TLV:

        0                   1                   2
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Type       |        Length                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                               |
       .            Value (variable)                   .
       |                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 10: TRILL OAM TLV

   o  Type (1 octet): Specifies the type of the TLV (see Section 8.4 for
      TLV types).

   o  Length (2 octets): Specifies the length of the Value field in
      octets.  Length of the Value field can be zero or more octets.

Top      Up      ToC       Page 27 
   o  Value (variable): The length and the content of this field depend
      on the type of TLV.  Please refer to applicable TLV definitions
      for details.

   Semantics and usage of Type values allocated for TRILL OAM purpose
   are defined by this document and other future related documents.

8.4.  TRILL OAM TLVs

   TRILL-related TLVs are defined in this section.  TLVS defined in
   [8021Q] are reused, where applicable.

8.4.1.  Common TLVs between CFM and TRILL

   The following TLVs are defined in [8021Q].  We reuse them where
   applicable.  The format and semantics of the TLVs are as defined in
   [8021Q].

      Type   Name of TLV in [8021Q]
      ----   ----------------------
        0    End TLV
        1    Sender ID TLV
        2    Port Status TLV
        3    Data TLV
        4    Interface Status TLV
        5    Reply Ingress TLV
        6    Reply Egress TLV
        7    LTM Egress Identifier TLV
        8    LTR Egress Identifier TLV
        9-30 Reserved
        31   Organization Specific TLV

8.4.2.  TRILL OAM-Specific TLVs

   Listed below is a summary of TRILL OAM TLVs and their corresponding
   codes.  Format and semantics of TRILL OAM TLVs are defined in
   subsequent sections.

Top      Up      ToC       Page 28 
       Type         TLV Name
       ----         ------------------------------------
       64           TRILL OAM Application Identifier TLV
       65           Out-of-Band Reply Address TLV
       66           Diagnostic Label TLV
       67           Original Data Payload TLV
       68           RBridge Scope TLV
       69           Previous RBridge Nickname TLV
       70           Next-Hop RBridge List TLV
       71           Multicast Receiver Port Count TLV
       72           Flow Identifier TLV
       73           Reflector Entropy TLV
       74           Authentication TLV

   The TRILL OAM Application Identifier TLV (64) MUST be the first TLV.
   An End TLV (0) MUST be included as the last TLV.  All other TLVs can
   be included in any order.

8.4.3.  TRILL OAM Application Identifier TLV

   The TRILL OAM Application Identifier TLV carries information specific
   to TRILL OAM applications.  The TRILL OAM Application Identifier TLV
   MUST always be present and MUST be the first TLV in TRILL OAM
   messages.  Messages that do not include the TRILL OAM Application
   Identifier TLV as the first TLV MUST be discarded by a TRILL MP.

                         1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type       | Length                        | Version       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               Reserved1                       | Fragment-ID   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Return Code  |Return Sub-code|     Reserved2         |F|C|O|I|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 11: TRILL OAM Application Identifier TLV

   o  Type (1 octet): 64, TRILL OAM Application Identifier TLV

   o  Length (2 octets): 9

   o  Version (1 octet): Currently set to zero.  Indicates the TRILL OAM
      version.  The TRILL OAM version can be different than the [8021Q]
      version.

   o  Reserved1 (3 octets): Set to zero on transmission and ignored on
      reception.

Top      Up      ToC       Page 29 
   o  Fragment-ID (1 octet): Indicates the fragment number of the
      current message.  This applies only to reply messages; in request
      messages, it must be set to zero on transmission and ignored on
      receipt.  The "F" flag defined below MUST be set with the final
      message, whether it is the last fragment of the fragmented message
      or the only message of the reply.  Section 13 provides more
      details on OAM message fragmentation.

   o  Return Code (1 octet): Set to zero on requests.  Set to an
      appropriate value in response messages.

   o  Return Sub-code (1 octet): Set to zero on transmission of request
      message.  The Return Sub-code identifies categories within a
      specific Return Code and MUST be interpreted within a Return Code.

   o  Reserved2 (12 bits): Set to zero on transmission and ignored on
      reception.

   o  F (1 bit): Final flag.  When set, indicates this is the last
      response.

   o  C (1 bit): Cross-Connect Error flag (VLAN/FGL mapping error).  If
      set, indicates that the label (VLAN/FGL) in the Flow Entropy is
      different than the label included in the Diagnostic Label TLV.
      This field is ignored in request messages and MUST only be
      interpreted in response messages.

   o  O (1 bit): If set, indicates OAM out-of-band response requested.

   o  I (1 bit): If set, indicates OAM in-band response requested.

   NOTE: When both O and I bits are set to zero, this indicates that no
   response is required (silent mode).  Users MAY specify both O and I,
   one of them, or none.  When both O and I bits are set, the response
   is sent both in-band and out-of-band.

Top      Up      ToC       Page 30 
8.4.4.  Out-of-Band Reply Address TLV

   The Out-of-Band Reply Address TLV specifies the address to which an
   out-of-band OAM reply message MUST be sent.  When the O bit in the
   TRILL Version sub-TLV (Section 3.3) is not set, the Out-of-Band Reply
   Address TLV is ignored.

                         1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type       | Length                        | Address Type  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Addr Length   |                                               |
    +-+-+-+-+-+-+-+-+                                               |
    |                                                               |
    .       Reply Address                                           .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 12: Out-of-Band Reply Address TLV

   o  Type (1 octet): 65, Out-of-Band Reply Address TLV

   o  Length (2 octets): Variable.  Minimum length is 2 + the length (in
      octets) of the shortest address.  Currently, the minimum value of
      this field is 4, but this could change in the future if a new
      address shorter than the TRILL nickname is defined.

   o  Address Type (1 octet):

         0 - IPv4

         1 - IPv6

         2 - TRILL nickname

      All other values reserved.

   o  Addr Length (1 octet): Depends on the Address Type.  Currently,
      defined values are:

         4  - IPv4

         16 - IPv6

         2  - TRILL nickname

      Other lengths may be acceptable for future Address Types.

Top      Up      ToC       Page 31 
   o  Reply Address (variable): Address where the reply needs to be
      sent.  Length depends on the address specification.

8.4.5.  Diagnostic Label TLV

   The Diagnostic Label TLV specifies the data label (VLAN or FGL) in
   which the OAM messages are generated.  Receiving RBridge MUST compare
   the data label of the Flow Entropy to the data label specified in the
   Diagnostic Label TLV.  The "C" flag (Cross Connect Error) in the
   response (TRILL OAM Application Identifier TLV; Section 8.4.3) MUST
   be set when the two VLANs do not match.

                         1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type       | Length                        | L-Type        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Reserved      |                       Label                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 13: Diagnostic Label TLV

   o  Type (1 octet): 66, Diagnostic Label TLV

   o  Length (2 octets): 5

   o  L-Type (1 octet): Label type

      0 - Indicates a right-justified 802.1Q 12-bit VLAN padded on the
          left with bits that must be sent as zero and ignored on
          receipt

      1 - Indicates a TRILL 24-bit fine-grained label

   o  Reserved (1 octet): Set to zero on transmission and ignored on
      reception.

   o  Label (24 bits): Either 12-bit VLAN or 24 bit fine-grained label.

   RBridges do not perform label error checking when the Diagnostic
   Label TLV is not included in the OAM message.  In certain
   deployments, intermediate devices may perform label translation.  In
   such scenarios, the originator should not include the Diagnostic
   Label TLV in OAM messages.  Inclusion of Diagnostic Label TLV will
   generate unwanted label error notifications.

Top      Up      ToC       Page 32 
8.4.6.  Original Data Payload TLV

                         1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type       | Length                        |               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
    |                                                               |
    .                Original Payload                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 14: Original Data Payload TLV

   o  Type (1 octet): 67, Original Data Payload TLV

   o  Length (2 octets): variable

   o  Original Payload: The original TRILL Header and Flow Entropy.
      Used in constructing replies to the Loopback Message (see
      Section 9) and the Path Trace Message (see Section 10).

8.4.7.  RBridge Scope TLV

   The RBridge Scope TLV identifies nicknames of RBridges from which a
   response is required.  The RBridge Scope TLV is only applicable to
   Multi-destination Tree Verification Messages.  This TLV SHOULD NOT be
   included in other messages.  Receiving RBridges MUST ignore this TLV
   on messages other than Multi-destination Tree Verification Messages.

   Each TLV can contain up to 255 nicknames of in-scope RBridges.  A
   Multi-destination Tree Verification Message may contain multiple
   RBridge scope TLVs, in the event that more than 255 in-scope RBridges
   need to be specified.

   Absence of the RBridge Scope TLV indicates that a response is needed
   from all the RBridges.  Please see Section 11 for details.

Top      Up      ToC       Page 33 
                         1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type       | Length                        | nOfnicknames  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Nickname-1                   |   Nickname-2                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               |  Nickname-n                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 15: RBridge Scope TLV

   o  Type (1 octet): 68, RBridge Scope TLV

   o  Length (2 octets): Variable.  Minimum value is 1.

   o  nOfnicknames (1 octet): Indicates the number of nicknames included
      in this TLV.  Zero (0) indicates no nicknames are included in the
      TLV.  When this field is set to zero (0), the Length field MUST be
      set to 1.

   o  Nickname (2 octets): 16-bit RBridge nickname

8.4.8.  Previous RBridge Nickname TLV

   The Previous RBridge Nickname TLV identifies the nickname or
   nicknames of the previous RBridge.  [RFC6325] allows a given RBridge
   to hold multiple nicknames.

   The Previous RBridge Nickname TLV is an optional TLV.  Multiple
   instances of this TLV MAY be included when an upstream RBridge is
   represented by more than 255 nicknames (highly unlikely).

                         1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type       | Length                        | Reserved      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Reserved (continued)         |   Nickname                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 16: Previous RBridge Nickname TLV

   o  Type (1 octet): 69, Previous RBridge Nickname TLV

   o  Length (2 octets): 5

Top      Up      ToC       Page 34 
   o  Reserved (3 octet): Set to zero on transmission and ignored on
      reception.

   o  Nickname (2 octets): RBridge nickname

8.4.9.  Next-Hop RBridge List TLV

   The Next-Hop RBridge List TLV identifies the nickname or nicknames of
   the downstream next-hop RBridges.  [RFC6325] allows a given RBridge
   to have multiple equal-cost paths to a specified destination.  Each
   next-hop RBridge is represented by one of its nicknames.

   The Next-Hop RBridge List TLV is an optional TLV.  Multiple instances
   of this TLV MAY be included when there are more than 255 equal-cost
   paths to the destination.

                         1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type       | Length                        | nOfnicknames  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Nickname-1                   |   Nickname-2                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               |  Nickname-n                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 17: Next-Hop RBridge List TLV

   o  Type (1 octet): 70, Next-Hop RBridge List TLV

   o  Length (2 octets): Variable. Minimum value is 1.

   o  nOfnicknames (1 octet): Indicates the number of nicknames included
      in this TLV.  Zero (0) indicates no nicknames are included in the
      TLV.  When this field is set to zero (0), the Length field MUST be
      set to 1.

   o  Nickname (2 octets): 16-bit RBridge nickname

8.4.10.  Multicast Receiver Port Count TLV

   The Multicast Receiver Port Count TLV identifies the number of ports
   interested in receiving the specified multicast stream within the
   responding RBridge on the label (VLAN or FGL) specified by the
   Diagnostic Label TLV.

Top      Up      ToC       Page 35 
   The Multicast Receiver Port Count TLV is an optional TLV.

                         1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type       | Length                        | Reserved      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Number of Receivers                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 18: Multicast Receiver Port Count TLV

   o  Type (1 octet): 71, Multicast Receiver Port Count TLV

   o  Length (2 octets): 5

   o  Reserved (1 octet): Set to zero on transmission and ignored on
      reception.

   o  Number of Receivers (4 octets): Indicates the number of multicast
      receivers available on the responding RBridge on the label
      specified by the diagnostic label.

8.4.11.   Flow Identifier TLV

   The Flow Identifier TLV uniquely identifies a specific flow.  The
   flow-identifier value is unique per MEP and needs to be interpreted
   as such.

                         1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type       | Length                        | Reserved      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  MEP-ID                       |     flow-identifier           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 19: Flow Identifier TLV

   o  Type (1 octet): 72, Flow Identifier TLV

   o  Length (2 octets): 5

   o  Reserved (1 octet): Set to 0 on transmission and ignored on
      reception.

   o  MEP-ID (2 octets): MEP-ID of the originator [8021Q].  In TRILL,
      MEP-ID can take a value from 1 to 65535.

Top      Up      ToC       Page 36 
   o  flow-identifier (2 octets): Uniquely identifies the flow per MEP.
      Different MEPs may allocate the same flow-identifier value.  The
      {MEP-ID, flow-identifier} pair is globally unique.

   Inclusion of the MEP-ID in the Flow Identifier TLV allows the
   inclusion of a MEP-ID for messages that do not contain a MEP-ID in
   their OAM header.  Applications may use MEP-ID information for
   different types of troubleshooting.

8.4.12.  Reflector Entropy TLV

   The Reflector Entropy TLV is an optional TLV.  This TLV, when
   present, tells the responder to utilize the Reflector Entropy
   specified within the TLV as the flow-entropy of the response message.

                         1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type       | Length                        | Reserved      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .               Reflector Entropy                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 20: Reflector Entropy TLV

   o  Type (1 octet): 73, Reflector Entropy TLV

   o  Length (2 octets): 97

   o  Reserved (1 octet): Set to zero on transmission and ignored by the
      recipient.

   o  Reflector Entropy (96 octets): Flow Entropy to be used by the
      responder.  May be padded with zeros if the desired flow-entropy
      information is less than 96 octets.

Top      Up      ToC       Page 37 
8.4.13.  Authentication TLV

   The Authentication TLV is an optional TLV that can appear in any OAM
   message or reply in TRILL.

                         1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type       | Length                        |  Auth Type    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                 Authentication Value                          .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 21: Authentication TLV

   o  Type (1 octet): 74, Authentication TLV

   o  Length (2 octets): Variable

   o  The Auth Type and following Authentication Value are the same as
      the Auth Type and following value for the [IS-IS] Authentication
      TLV.  It is RECOMMENDED that Auth Type 3 be used.  Auth Types 0,
      1, 2, and 54 MUST NOT be used.  With Auth Type 3, the
      Authentication TLV is as follows:

                         1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type       | Length                        | Auth Type = 3 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Key ID                     |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               .
    .                      Authentication Data (variable)           .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 22: Authentication TLV with Auth Type 3

   With Auth Type 3, the process is generally as specified in [RFC5310]
   using the same Key ID space as TRILL [IS-IS].  The area covered by
   the Authentication TLV is from the beginning of the TRILL Header to
   the end of the TRILL OAM Message Channel; the Link Header and Trailer
   are not included.  The TRILL Header Alert, Reserved bit, and Hop
   Count are treated as zero for the purposes of computing and verifying
   the Authentication Data.

Top      Up      ToC       Page 38 
   Key distribution is out of the scope of this document as the keying
   distributed for IS-IS is used.

   An RBridge supporting OAM authentication can be configured to either
   (1) ignore received OAM Authentication TLVs and not send them, (2)
   ignore received OAM Authentication TLVs but include them in all OAM
   packets sent, or (3) to include Authentication TLVs in all OAM
   messages sent and enforce authentication of OAM messages received.
   When an RBridge is enforcing authentication, it discards any OAM
   message subject to OAM processing that does not contain an
   Authentication TLV or an Authentication TLV does not verify.



(page 38 continued on part 3)

Next RFC Part