Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7455

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

Pages: 63
Proposed Standard
Updates:  6325
Part 2 of 3 – Pages 11 to 38
First   Prev   Next

Top   ToC   RFC7455 - Page 11   prevText

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   ToC   RFC7455 - 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   ToC   RFC7455 - 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   ToC   RFC7455 - 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   ToC   RFC7455 - 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   ToC   RFC7455 - 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   ToC   RFC7455 - 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   ToC   RFC7455 - 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   ToC   RFC7455 - 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   ToC   RFC7455 - 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   ToC   RFC7455 - 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   ToC   RFC7455 - 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   ToC   RFC7455 - 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   ToC   RFC7455 - 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   ToC   RFC7455 - 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   ToC   RFC7455 - 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   ToC   RFC7455 - 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   ToC   RFC7455 - 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   ToC   RFC7455 - 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   ToC   RFC7455 - 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   ToC   RFC7455 - 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   ToC   RFC7455 - 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   ToC   RFC7455 - 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   ToC   RFC7455 - 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   ToC   RFC7455 - 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   ToC   RFC7455 - 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   ToC   RFC7455 - 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   ToC   RFC7455 - 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 Section