GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc7455

Internet Engineering Task Force (IETF) T. Senevirathne Request for Comments: 7455 N. Finn Updates: 6325 S. Salam Category: Standards Track D. Kumar ISSN: 2070-1721 Cisco

                                                       D. Eastlake 3rd
                                                             S. Aldrin
                                                                 Y. Li
                                                                Huawei
                                                            March 2015

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

Abstract

 This document specifies Transparent Interconnection of Lots of Links
 (TRILL) Operations, Administration, and Maintenance (OAM) fault
 management.  Methods in this document follow the CFM (Connectivity
 Fault Management) framework defined in IEEE 802.1 and reuse OAM tools
 where possible.  Additional messages and TLVs are defined for TRILL-
 specific applications or for cases where a different set of
 information is required other than CFM as defined in IEEE 802.1.
 This document updates RFC 6325.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7455.

Senevirathne, et al. Standards Track [Page 1] RFC 7455 TRILL Fault Management March 2015

Copyright Notice

 Copyright (c) 2015 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Senevirathne, et al. Standards Track [Page 2] RFC 7455 TRILL Fault Management March 2015

Table of Contents

 1. Introduction ....................................................5
 2. Conventions Used in This Document ...............................5
 3. General Format of TRILL OAM Packets .............................6
    3.1. Identification of TRILL OAM Frames .........................8
    3.2. Use of TRILL OAM Alert Flag ................................8
         3.2.1. Handling of TRILL Frames with the "A" Flag ..........9
    3.3. OAM Capability Announcement ................................9
    3.4. Identification of the OAM Message .........................10
 4. TRILL OAM Layering vs. IEEE Layering ...........................11
    4.1. Processing at the ISS Layer ...............................12
         4.1.1. Receive Processing .................................12
         4.1.2. Transmit Processing ................................12
    4.2. End-Station VLAN and Priority Processing ..................12
         4.2.1. Receive Processing .................................12
         4.2.2. Transmit Processing ................................12
    4.3. TRILL Encapsulation and Decapsulation Layer ...............12
         4.3.1. Receive Processing for Unicast Packets .............12
         4.3.2. Transmit Processing for Unicast Packets ............13
         4.3.3. Receive Processing for Multicast Packets ...........14
         4.3.4. Transmit Processing of Multicast Packets ...........15
    4.4. TRILL OAM Layer Processing ................................16
 5. Maintenance Associations (MAs) in TRILL ........................17
 6. MEP Addressing .................................................18
    6.1. Use of MIP in TRILL .......................................21
 7. Continuity Check Message (CCM) .................................22
 8. TRILL OAM Message Channel ......................................25
    8.1. TRILL OAM Message Header ..................................25
    8.2. TRILL-Specific OAM OpCodes ................................26
    8.3. Format of TRILL OAM TLV ...................................26
    8.4. TRILL OAM TLVs ............................................27
         8.4.1. Common TLVs between CFM and TRILL ..................27
         8.4.2. TRILL OAM-Specific TLVs ............................27
         8.4.3. TRILL OAM Application Identifier TLV ...............28
         8.4.4. Out-of-Band Reply Address TLV ......................30
         8.4.5. Diagnostic Label TLV ...............................31
         8.4.6. Original Data Payload TLV ..........................32
         8.4.7. RBridge Scope TLV ..................................32
         8.4.8. Previous RBridge Nickname TLV ......................33
         8.4.9. Next-Hop RBridge List TLV ..........................34
         8.4.10. Multicast Receiver Port Count TLV .................34
         8.4.11. Flow Identifier TLV ...............................35
         8.4.12. Reflector Entropy TLV .............................36
         8.4.13. Authentication TLV ................................37

Senevirathne, et al. Standards Track [Page 3] RFC 7455 TRILL Fault Management March 2015

 9. Loopback Message ...............................................38
    9.1. Loopback Message Format ...................................38
    9.2. Theory of Operation .......................................39
         9.2.1. Actions by Originator RBridge ......................39
         9.2.2. Intermediate RBridge ...............................39
         9.2.3. Destination RBridge ................................40
 10. Path Trace Message ............................................40
    10.1. Theory of Operation ......................................41
         10.1.1. Actions by Originator RBridge .....................41
         10.1.2. Intermediate RBridge ..............................42
         10.1.3. Destination RBridge ...............................43
 11. Multi-Destination Tree Verification Message (MTVM) ............43
    11.1. MTVM Format ..............................................44
    11.2. Theory of Operation ......................................44
         11.2.1. Actions by Originator RBridge .....................44
         11.2.2. Receiving RBridge .................................45
         11.2.3. In-Scope RBridges .................................45
 12. Application of Continuity Check Message (CCM) in TRILL ........46
    12.1. CCM Error Notification ...................................47
    12.2. Theory of Operation ......................................48
         12.2.1. Actions by Originator RBridge .....................48
         12.2.2. Intermediate RBridge ..............................49
         12.2.3. Destination RBridge ...............................49
 13. Fragmented Reply ..............................................50
 14. Security Considerations .......................................50
 15. IANA Considerations ...........................................52
    15.1. OAM Capability Flags .....................................52
    15.2. CFM Code Points ..........................................52
    15.3. MAC Addresses ............................................53
    15.4. Return Codes and Sub-codes ...............................53
    15.5. TRILL Nickname Address Family ............................54
 16. References ....................................................54
    16.1. Normative References .....................................54
    16.2. Informative References ...................................55
 Appendix A. Backwards Compatibility ...............................57
    A.1.  Maintenance Point (MEP/MIP) Model ........................57
    A.2.  Data-Plane Encoding and Frame Identification .............57
 Appendix B. Base Mode for TRILL OAM ...............................59
 Appendix C. MAC Addresses Request .................................61
 Acknowledgments ...................................................62
 Authors' Addresses ................................................62

Senevirathne, et al. Standards Track [Page 4] RFC 7455 TRILL Fault Management March 2015

1. Introduction

 The general structure of TRILL OAM messages is presented in
 [RFC7174].  TRILL OAM messages consist of six parts: Link Header,
 TRILL Header, Flow Entropy, OAM Ethertype, OAM Message Channel, and
 Link Trailer.
 The OAM Message Channel carries various control information and OAM-
 related data between TRILL switches, also known as RBridges or
 Routing Bridges.
 A common OAM Message Channel representation can be shared between
 different technologies.  This consistency between different OAM
 technologies promotes nested fault monitoring and isolation between
 technologies that share the same OAM framework.
 The TRILL OAM Message Channel is formatted as specified in IEEE
 Connectivity Fault Management (CFM) [8021Q].
 The ITU-T Y.1731 [Y1731] standard utilizes the same messaging format
 as [8021Q] OAM messages where applicable.  This document takes a
 similar stance and reuses [8021Q] in TRILL OAM.  It is assumed that
 readers are familiar with [8021Q] and [Y1731].  Readers who are not
 familiar with these documents are encouraged to review them.
 This document specifies TRILL OAM fault management.  It updates
 [RFC6325] as specified in Section 3.1.  TRILL performance monitoring
 is specified in [RFC7456].

2. Conventions Used in This Document

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in RFC 2119 [RFC2119].
 Capitalized IANA Considerations terms such as "Standards Action" are
 to be interpreted as described in [RFC5226].
 Acronyms used in the document include the following:
    CCM   - Continuity Check Message [8021Q]
    DA    - Destination Address
    ECMP  - Equal-Cost Multipath
    FGL   - Fine-Grained Label

Senevirathne, et al. Standards Track [Page 5] RFC 7455 TRILL Fault Management March 2015

    ISS   - Internal Sub-Layer Service [8021Q]
    LBM   - Loopback Message [8021Q]
    LBR   - Loopback Reply [8021Q]
    MA    - Maintenance Association [8021Q] [RFC7174]
    MAC   - Media Access Control (MAC)
    MD    - Maintenance Domain [8021Q]
    MEP   - Maintenance End Point [RFC7174] [8021Q]
    MIP   - Maintenance Intermediate Point [RFC7174] [8021Q]
    MP    - Maintenance Point [RFC7174]
    MTVM  - Multi-destination Tree Verification Message
    MTVR  - Multi-destination Tree Verification Reply
    OAM   - Operations, Administration, and Maintenance [RFC6291]
    PRI   - Priority of Ethernet Frames [8021Q]
    PTM   - Path Trace Message
    PTR   - Path Trace Reply
    SA    - Source Address
    SAP   - Service Access Point [8021Q]
    TRILL - Transparent Interconnection of Lots of Links [RFC6325]

3. General Format of TRILL OAM Packets

 The TRILL forwarding paradigm allows an implementation to select a
 path from a set of equal-cost paths to forward a unicast TRILL Data
 packet.  For multi-destination TRILL Data packets, a distribution
 tree is chosen by the TRILL switch that ingresses or creates the
 packet.  Selection of the path of choice is implementation dependent
 at each hop for unicast and at the ingress for multi-destination.
 However, it is a common practice to utilize Layer 2 through Layer 4
 information in the frame payload for path selection.

Senevirathne, et al. Standards Track [Page 6] RFC 7455 TRILL Fault Management March 2015

 For accurate monitoring and/or diagnostics, OAM messages are required
 to follow the same path as corresponding data packets.  [RFC7174]
 presents the high-level format of OAM messages.  The details of the
 TRILL OAM frame format are defined in this document.
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               |
       .    Link  Header               . Variable
       |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               |
       +    TRILL Header               + 6 or more bytes
       |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               |
       .   Flow Entropy                . 96 bytes
       .                               .
       |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   OAM Ethertype               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               |
       .   OAM Message Channel         . Variable
       .                               .
       |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Link Trailer              | Variable
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             Figure 1: Format of TRILL OAM Messages
 o  Link Header: Media-dependent header.  For Ethernet, this includes
    the Destination MAC, Source MAC, VLAN (optional), and Ethertype
    fields.
 o  TRILL Header: Fixed size of 6 bytes when the Extended Header is
    not included [RFC6325].
 o  Flow Entropy: A 96-byte, fixed-size field.  The rightmost bits of
    the field MUST be padded with zeros, up to 96 bytes, when the
    flow-entropy information is less than 96 bytes.  Flow Entropy
    enables emulation of the forwarding behavior of the desired data
    packets.  The Flow Entropy field starts with the Inner.MacDA.  The
    offset of the Inner.MacDA depends on whether extensions are
    included or not as specified in [RFC7179] and [RFC6325].  Such
    extensions are not commonly supported in current TRILL
    implementations.

Senevirathne, et al. Standards Track [Page 7] RFC 7455 TRILL Fault Management March 2015

 o  OAM Ethertype: A 16-bit Ethertype that identifies the OAM Message
    Channel that follows.  This document specifies using the Ethertype
    0x8902 allocated for CFM [8021Q].
 o  OAM Message Channel: A variable-size section that carries OAM-
    related information.  The message format is as specified in
    [8021Q].
 o  Link Trailer: Media-dependent trailer.  For Ethernet, this is the
    FCS (Frame Check Sequence).

3.1. Identification of TRILL OAM Frames

 TRILL, as originally specified in [RFC6325], did not have a specific
 flag or method to identify OAM frames.  This document updates
 [RFC6325] to include specific methods to identify TRILL OAM frames.
 Section 3.2 explains the details of the method.

3.2. Use of TRILL OAM Alert Flag

 The TRILL Header, as defined in [RFC6325], has two reserved bits.
 This document specifies use of the reserved bit next to the Version
 field in the TRILL Header as the Alert flag.  The Alert flag will be
 denoted by "A".  RBridges MUST NOT use the "A" flag for forwarding
 decisions such as the selection of which ECMP path or multi-
 destination tree to select.
 Implementations that comply with this document MUST utilize the "A"
 flag and CFM Ethertype to identify TRILL OAM frames.
                                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                  | V |A|R|M|Op-Length| Hop Count |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Egress RBridge Nickname     |  Ingress RBridge Nickname     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Options...
  +-+-+-+-+-+-+-+-+-+-+-+-
               Figure 2: TRILL Header with the "A" Flag
 o  A (1 bit): Indicates this is a possible OAM frame and is subject
    to specific handling as specified in this document.
 All other TRILL Header fields carry the same meaning as defined in
 [RFC6325].

Senevirathne, et al. Standards Track [Page 8] RFC 7455 TRILL Fault Management March 2015

3.2.1. Handling of TRILL Frames with the "A" Flag

 The value "1" in the "A" flag indicates TRILL frames that may qualify
 as OAM frames.  Implementations are further REQUIRED to validate such
 frames by comparing the value at the OAM Ethertype (Figure 1)
 location with the CFM Ethertype "0x8902" [8021Q].  If the value
 matches, such frames are identified as TRILL OAM frames and SHOULD be
 processed as discussed in Section 4.
 Frames with the "A" flag set that do not contain a CFM Ethertype are
 not considered OAM frames.  Such frames MUST be silently discarded.
 OAM-capable RBridges MUST NOT generate OAM frames to an RBridge that
 is not OAM capable.
 Intermediate RBridges that are not OAM capable (i.e., do not
 understand the "A" flag) follow the process defined in Section 3.3 of
 [RFC6325] and forward OAM frames with the "A" flag unaltered.

3.3. OAM Capability Announcement

 Any given RBridge can be (1) OAM incapable, (2) OAM capable with new
 extensions, or (3) OAM capable with the backwards-compatibility
 method.  The OAM request originator, prior to origination of the
 request, is required to identify the OAM capability of the target and
 generate the appropriate OAM message.
 The capability flags defined in the TRILL Version sub-TLV (TRILL-VER)
 [RFC7176] will be utilized for announcing OAM capabilities.  The
 following OAM-related capability flags are defined:
    O - OAM capable
    B - Backwards-compatible OAM
 A capability announcement with the "O" flag set to 1 and the "B" flag
 set to 1 indicates that the originating RBridge is OAM capable but
 utilizes the backwards-compatibility method defined in Appendix A.  A
 capability announcement with the "O" flag set to 1 and the "B" flag
 set to 0 indicates that the originating RBridge is OAM capable and
 utilizes the method specified in Section 3.2.
 When the "O" flag is set to 0, the announcing implementation is
 considered not capable of OAM, and the "B" flag is ignored.

Senevirathne, et al. Standards Track [Page 9] RFC 7455 TRILL Fault Management March 2015

    +-+-+-+-+-+-+-+-+
    | Type          |              (1 byte)
    +-+-+-+-+-+-+-+-+
    | Length        |              (1 byte)
    +-+-+-+-+-+-+-+-+
    | Max-version   |              (1 byte)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
    |A|F|O|B|Other Capabilities and Header Flags|  (4 bytes)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+
     0                   1                 3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7   0 1
  Figure 3: TRILL-VER Sub-TLV [RFC7176] with "O" and "B" Flags
 In Figure 3, "A" is the Affinity sub-TLV support flag as indicated in
 [RFC7176], and "F" is the FGL-safe flag as indicated in [RFC7172] and
 [RFC7176].  The "O" and "B" flags are located after the "F" flag in
 the Capability and Header Flags field of the TRILL-VER sub-TLV, as
 depicted in Figure 3 above.  Usage of the "O" and "B" flags is
 discussed above.
 Absence of the TRILL-VER sub-TLV means the announcing RBridge is not
 OAM capable.

3.4. Identification of the OAM Message

 The ingress RBridge nickname allows recipients to identify the origin
 of the message in most cases.  However, when an out-of-band reply is
 generated, the responding RBridge nickname is not easy to identify.
 The [8021Q] Sender ID TLV (1) provides methods to identify the device
 by including the Chassis ID.  The Chassis ID allows different
 addressing formats such as IANA Address Family enumerations.  IANA
 has allocated Address Family Number 16396 for TRILL nickname.  In
 TRILL OAM, the Chassis ID sub-type of the Sender ID TLV is set to
 16396, and the Chassis ID field contains the corresponding TRILL
 nickname.
 When the Sender ID TLV is present and the Chassis ID sub-type is set
 to 16396, the sender RBridge TRILL nickname SHOULD be derived from
 the nickname embedded in the Chassis ID.  Otherwise, the sender
 RBridge TRILL nickname SHOULD be derived from the ingress RBridge
 nickname.

Senevirathne, et al. Standards Track [Page 10] RFC 7455 TRILL Fault Management March 2015

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.

Senevirathne, et al. Standards Track [Page 11] RFC 7455 TRILL Fault Management March 2015

 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:

Senevirathne, et al. Standards Track [Page 12] RFC 7455 TRILL Fault Management March 2015

  1. Discard DA, SA, VLAN, and PRI. From M2, derive (TRILL-HDR,

iDA, iSA, i-VL, M3).

  1. If TRILL nickname is Local and TRILL Header Alert flag is set:
  • Pass on to OAM processing.
  1. 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]:
  1. 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:
  1. 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:
  1. 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:
  1. 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).

  1. Else:
  • Discard packet.

Senevirathne, et al. Standards Track [Page 13] RFC 7455 TRILL Fault Management March 2015

 o  If the egress TRILL nickname is not local:
  1. 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:
  1. Strip DA, SA, and V. From M2, extract (TRILL-HDR, iDA, iSA,

iVL, and M3).

  1. If the TRILL Alert flag is set and the OAM Ethertype is present

at the end of Flow Entropy:

  • Perform OAM processing.
  1. 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:
  1. 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:
  1. Discard the packet.
 o  If the DA is All-Edge-RBridges and the Ethertype is RBridge-
    Channel [RFC7178]:
  1. Process as a possible multicast native RBridge Channel packet.

Senevirathne, et al. Standards Track [Page 14] RFC 7455 TRILL Fault Management March 2015

 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:
  1. 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:
  1. Insert TRILL-HDR and construct (TRILL-HDR, iDA, iSA, IVL, M3).
  1. 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:
  1. 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:
  1. 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.
  1. 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.

Senevirathne, et al. Standards Track [Page 15] RFC 7455 TRILL Fault Management March 2015

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:
  1. 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:
  1. 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).

Senevirathne, et al. Standards Track [Page 16] RFC 7455 TRILL Fault Management March 2015

  • If MD-Level matches MD-Level of MIP, then:
          +  Make a copy for OAM processing and continue.
 o  Else, for a non-OAM packet:
  1. 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.

Senevirathne, et al. Standards Track [Page 17] RFC 7455 TRILL Fault Management March 2015

           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.

Senevirathne, et al. Standards Track [Page 18] RFC 7455 TRILL Fault Management March 2015

 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.

Senevirathne, et al. Standards Track [Page 19] RFC 7455 TRILL Fault Management March 2015

                          |
                          .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.

Senevirathne, et al. Standards Track [Page 20] RFC 7455 TRILL Fault Management March 2015

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.

Senevirathne, et al. Standards Track [Page 21] RFC 7455 TRILL Fault Management March 2015

                    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

Senevirathne, et al. Standards Track [Page 22] RFC 7455 TRILL Fault Management March 2015

 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.

Senevirathne, et al. Standards Track [Page 23] RFC 7455 TRILL Fault Management March 2015

           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.

Senevirathne, et al. Standards Track [Page 24] RFC 7455 TRILL Fault Management March 2015

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.

Senevirathne, et al. Standards Track [Page 25] RFC 7455 TRILL Fault Management March 2015

 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.

Senevirathne, et al. Standards Track [Page 26] RFC 7455 TRILL Fault Management March 2015

 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.

Senevirathne, et al. Standards Track [Page 27] RFC 7455 TRILL Fault Management March 2015

     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.

Senevirathne, et al. Standards Track [Page 28] RFC 7455 TRILL Fault Management March 2015

 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.

Senevirathne, et al. Standards Track [Page 29] RFC 7455 TRILL Fault Management March 2015

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.

Senevirathne, et al. Standards Track [Page 30] RFC 7455 TRILL Fault Management March 2015

 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.

Senevirathne, et al. Standards Track [Page 31] RFC 7455 TRILL Fault Management March 2015

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.

Senevirathne, et al. Standards Track [Page 32] RFC 7455 TRILL Fault Management March 2015

                       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

Senevirathne, et al. Standards Track [Page 33] RFC 7455 TRILL Fault Management March 2015

 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.

Senevirathne, et al. Standards Track [Page 34] RFC 7455 TRILL Fault Management March 2015

 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.

Senevirathne, et al. Standards Track [Page 35] RFC 7455 TRILL Fault Management March 2015

 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.

Senevirathne, et al. Standards Track [Page 36] RFC 7455 TRILL Fault Management March 2015

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.

Senevirathne, et al. Standards Track [Page 37] RFC 7455 TRILL Fault Management March 2015

 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.

9. Loopback Message

9.1. Loopback Message Format

                       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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |MD-L | Version | OpCode        |  Flags        |FirstTLVOffset |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                   Loopback Transaction Identifier             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  .         TLVs                                                  .
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Figure 23: Loopback Message Format
 The figure above depicts the format of the Loopback Request and
 Response messages as defined in [8021Q].  The OpCode for the Loopback
 Message is set to 3, and the OpCode for the reply message is set to 2
 [8021Q].  The Loopback Transaction Identifier (commonly called the
 Session Identification Number or Session ID in this document) is a
 32-bit integer that allows the requesting RBridge to uniquely
 identify the corresponding session.  Responding RBridges, without
 modification, MUST echo the received "Loopback Transaction
 Identifier" number.

Senevirathne, et al. Standards Track [Page 38] RFC 7455 TRILL Fault Management March 2015

9.2. Theory of Operation

9.2.1. Actions by Originator RBridge

 The originator RBridge takes the following actions:
 o  Identifies the destination RBridge nickname based on user
    specification or based on the specified destination MAC or IP
    address.
 o  Constructs the Flow Entropy based on user-specified parameters or
    implementation-specific default parameters.
 o  Constructs the TRILL OAM header: sets the OpCode to Loopback
    Message type (3) [8021Q].  Assigns applicable Loopback Transaction
    Identifier number for the request.
 o  The TRILL OAM Application Identifier TLV MUST be included with the
    flags set to applicable values.
 o  Includes following OAM TLVs, where applicable:
  1. Out-of-Band Reply Address TLV
  1. Diagnostic Label TLV
  1. Sender ID TLV
 o  Specifies the Hop Count of the TRILL Data frame per user
    specification or utilize an applicable Hop Count value.
 o  Dispatches the OAM frame for transmission.
 RBridges may continue to retransmit the request at periodic intervals
 until a response is received or the retransmission count expires.  At
 each transmission, the Session Identification Number MUST be
 incremented.

9.2.2. Intermediate RBridge

 Intermediate RBridges forward the frame as a normal data frame; no
 special handling is required.

Senevirathne, et al. Standards Track [Page 39] RFC 7455 TRILL Fault Management March 2015

9.2.3. Destination RBridge

 If the Loopback Message is addressed to the local RBridge and
 satisfies the OAM identification criteria specified in Section 3.1,
 then the RBridge data plane forwards the message to the CPU for
 further processing.
 The TRILL OAM application layer further validates the received OAM
 frame by checking for the presence of OAM Ethertype at the end of the
 Flow Entropy.  Frames that do not contain OAM Ethertype at the end of
 the Flow Entropy MUST be discarded.
 Construction of the TRILL OAM response:
 o  The TRILL OAM application encodes the received TRILL Header and
    Flow Entropy in the Original Data Payload TLV and includes it in
    the OAM message.
 o  Set the Return Code to (1) "Reply" and Return Sub-code to zero (0)
    "Valid Response".  Update the TRILL OAM OpCode to 2 (Loopback
    Message Reply).
 o  Optionally, if the VLAN/FGL identifier value of the received Flow
    Entropy differs from the value specified in the Diagnostic Label
    TLV, set the "C" flag (Cross Connect Error) in the TRILL OAM
    Application Identifier TLV.
 o  Include the Sender ID TLV (1).
 o  If in-band response was requested, dispatch the frame to the TRILL
    data plane with request-originator RBridge nickname as the egress
    RBridge nickname.
 o  If out-of-band response was requested, dispatch the frame to the
    IP forwarding process.

10. Path Trace Message

 The primary use of the Path Trace Message is for fault isolation.  It
 may also be used for plotting the path taken from a given RBridge to
 another RBridge.
 [8021Q] accomplishes the objectives of the TRILL Path Trace Message
 using Link Trace Messages.  Link Trace Messages utilize a well-known
 multicast MAC address.  This works for [8021Q] because both the
 unicast and multicast paths are congruent.  However, in TRILL,
 multicast and unicast are not congruent.  Hence, TRILL OAM uses a new
 message format: the Path Trace Message.

Senevirathne, et al. Standards Track [Page 40] RFC 7455 TRILL Fault Management March 2015

 The Path Trace Message has the same format as the Loopback Message.
 The OpCode for Path Trace Reply is 64, and the OpCode for the Path
 Trace Message is 65.
 Operation of the Path Trace Message is identical to the Loopback
 Message except that it is first transmitted with a TRILL Header Hop
 Count field value of 1.  The sending RBridge expects an "Intermediate
 RBridge" Return Sub-code from the next hop or a "Valid response"
 Return Sub-code response from the destination RBridge.  If an
 "Intermediate RBridge" Return Sub-code is received in the response,
 the originator RBridge records the information received from the
 intermediate node that generated the message and resends the message
 by incrementing the previous Hop Count value by 1.  This process is
 continued until, a response is received from the destination RBridge,
 a Path Trace process timeout occurs, or the Hop Count reaches a
 configured maximum value.

10.1. Theory of Operation

10.1.1. Actions by Originator RBridge

 The originator RBridge takes the following actions:
 o  Identifies the destination RBridge based on user specification or
    based on location of the specified MAC address.
 o  Constructs the Flow Entropy based on user-specified parameters or
    implementation-specific default parameters.
 o  Constructs the TRILL OAM header: set the OpCode to Path Trace
    Message type (65).  Assign an applicable Session Identification
    number for the request.  Return Code and Return Sub-code MUST be
    set to zero.
 o  The TRILL OAM Application Identifier TLV MUST be included with the
    flags set to applicable values.
 o  Includes the following OAM TLVs, where applicable:
  1. Out-of-Band Reply Address TLV
  1. Diagnostic Label TLV
  1. Sender ID TLV
 o  Specifies the Hop Count of the TRILL Data frame as 1 for the first
    request.

Senevirathne, et al. Standards Track [Page 41] RFC 7455 TRILL Fault Management March 2015

 o  Dispatches the OAM frame to the TRILL data plane for transmission.
 An RBridge may continue to retransmit the request at periodic
 intervals until a response is received or the retransmission count
 expires.  At each new retransmission, the Session Identification
 number MUST be incremented.  Additionally, for responses received
 from intermediate RBridges, the RBridge nickname and interface
 information MUST be recorded.

10.1.2. Intermediate RBridge

 Path Trace Messages transit through Intermediate RBridges
 transparently, unless the Hop Count has expired.
 The TRILL OAM application layer further validates the received OAM
 frame by examining the presence of the TRILL Alert flag and OAM
 Ethertype at the end of the Flow Entropy and by examining the
 MD-Level.  Frames that do not contain OAM Ethertype at the end of the
 Flow Entropy MUST be discarded.
 Construction of the TRILL OAM response:
 o  The TRILL OAM application encodes the received TRILL Header and
    Flow Entropy in the Original Data Payload TLV and includes it in
    the OAM message.
 o  Set the Return Code to (1) "Reply" and Return Sub-code to two (2)
    "Intermediate RBridge".  Update the TRILL OAM OpCode to 64 (Path
    Trace Reply).
 o  If the VLAN/FGL identifier value of the received Flow Entropy
    differs from the value specified in the diagnostic label, set the
    "C" flag (Cross Connect Error) in the TRILL OAM Application
    Identifier TLV.
 o  Include the following TLVs:
  1. Previous RBridge Nickname TLV (69)
  1. Reply Ingress TLV (5)
  1. Reply Egress TLV (6)
  1. Interface Status TLV (4)
  1. Next-Hop RBridge List TLV (70) (Repeat for each ECMP)
  1. Sender ID TLV (1)

Senevirathne, et al. Standards Track [Page 42] RFC 7455 TRILL Fault Management March 2015

 o  If a cross-connect error is detected, set the "C" flag (Cross-
    Connect Error) in the reply's TRILL OAM Application Identifier
    TLV.
 o  If in-band response was requested, dispatch the frame to the TRILL
    data plane with request-originator RBridge nickname as the egress
    RBridge nickname.
 o  If out-of-band response was requested, dispatch the frame to the
    standard IP forwarding process.

10.1.3. Destination RBridge

 Processing is identical to that in Section 10.1.2 with the exception
 that the TRILL OAM OpCode is set to Path Trace Reply (64).

11. Multi-Destination Tree Verification Message (MTVM)

 Multi-destination Tree Verification Messages allow verifying TRILL
 distribution tree integrity and pruning.  TRILL VLAN/FGL and
 multicast pruning are described in [RFC6325], [RFC7180], and
 [RFC7172].  Multi-destination Tree Verification and Multicast Group
 Verification Messages are designed to detect pruning defects.
 Additionally, these tools can be used for plotting a given multicast
 tree within the TRILL campus.
 Multi-destination Tree Verification OAM frames are copied to the CPU
 of every intermediate RBridge that is part of the distribution tree
 being verified.  The originator of the Multi-destination Tree
 Verification Message specifies the scope of RBridges from which a
 response is required.  Only the RBridges listed in the scope field
 respond to the request.  Other RBridges silently discard the request.
 Inclusion of the scope field is required to prevent receiving an
 excessive number of responses.  The typical scenario of distribution
 tree verification or group verification involves verifying multicast
 connectivity to a selected set of end nodes as opposed to the entire
 network.  Availability of the scope facilitates narrowing down the
 focus to only the RBridges of interest.
 Implementations MAY choose to rate-limit CPU-bound multicast traffic.
 As a result of rate-limiting or due to other congestion conditions,
 MTVM messages may be discarded from time to time by the intermediate
 RBridges, and the requester may be required to retransmit the
 request.  Implementations SHOULD narrow the embedded scope of
 retransmission requests only to RBridges that have failed to respond.

Senevirathne, et al. Standards Track [Page 43] RFC 7455 TRILL Fault Management March 2015

11.1. MTVM Format

 The format of MTVM is identical to the Loopback Message format
 defined in Section 9 with the exception that the OpCode used is 67.

11.2. Theory of Operation

11.2.1. Actions by Originator RBridge

 The user is required, at a minimum, to specify either the
 distribution trees that need to be verified, the Multicast MAC
 address and VLAN/FGL, or the VLAN/FGL and Multicast Destination IP
 address.  Alternatively, for more specific multicast flow
 verification, the user MAY specify more information, e.g., source MAC
 address, VLAN/FGL, and Destination and Source IP addresses.
 Implementations, at a minimum, must allow the user to specify a
 choice of distribution trees, Destination Multicast MAC address, and
 VLAN/FGL that needs to be verified.  Although it is not mandatory, it
 is highly desired to provide an option to specify the scope.  It
 should be noted that the source MAC address and some other parameters
 may not be specified if the backwards-compatibility method in
 Appendix A is used to identify the OAM frames.
 Default parameters MUST be used for unspecified parameters.  Flow
 Entropy is constructed based on user-specified parameters and/or
 default parameters.
 Based on user specified parameters, the originating RBridge does the
 following:
 o  Identifies the nickname that represents the multicast tree.
 o  Obtains the applicable Hop Count value for the selected multicast
    tree.
 o  Constructs TRILL OAM message header and includes the Session
    Identification number.  The Session Identification Number
    facilitates the originator mapping the response to the correct
    request.
 o  Includes the TRILL OAM Application Identifier TLV, which MUST be
    included.
 o  Includes the OpCode Multicast Tree Verification Message (67).
 o  Includes RBridge Scope TLV (68).

Senevirathne, et al. Standards Track [Page 44] RFC 7455 TRILL Fault Management March 2015

 o  Optionally, includes the following TLVs, where applicable:
  1. Out-of-Band IP Address TLV (65)
  1. Diagnostic Label TLV (66)
  1. Sender ID TLV (1)
 o  Specifies the Hop Count of the TRILL Data frame per user
    specification or alternatively utilizes the applicable Hop Count
    value if the TRILL Hop Count is not being specified by the user.
 o  Dispatches the OAM frame to the TRILL data plane to be ingressed
    for transmission.
 The RBridge may continue to retransmit the request at a periodic
 interval until either a response is received or the retransmission
 count expires.  At each new retransmission, the Session
 Identification Number MUST be incremented.  At each retransmission,
 the RBridge may further reduce the scope to the RBridges that it has
 not received a response from.

11.2.2. Receiving RBridge

 Receiving RBridges identify multicast verification frames per the
 procedure explained in Section 3.2.
 The RBridge validates the frame and analyzes the scope RBridge list.
 If the RBridge Scope TLV is present and the local RBridge nickname is
 not specified in the scope list, it will silently discard the frame.
 If the local RBridge is specified in the scope list OR the RBridge
 Scope TLV is absent, the receiving RBridge proceeds with further
 processing as defined in Section 11.2.3.

11.2.3. In-Scope RBridges

 Construction of the TRILL OAM response:
 o  The TRILL OAM application encodes the received TRILL Header and
    Flow Entropy in the Original Data Payload TLV and includes them in
    the OAM message.
 o  Set the Return Code to zero (0) and Return Sub-code to zero (0).
    Update the TRILL OAM OpCode to 66 (Multi-destination Tree
    Verification Reply).

Senevirathne, et al. Standards Track [Page 45] RFC 7455 TRILL Fault Management March 2015

 o  Include following TLVs:
  1. Previous RBridge Nickname TLV (69)
  1. Reply Ingress TLV (5)
  1. Interface Status TLV (4)
  1. Next-Hop RBridge List TLV (70)
  1. Sender ID TLV (1)
  1. Multicast Receiver Port Count TLV (71)
 o  If a VLAN/FGL cross-connect error is detected, set the "C" flag
    (Cross-Connect Error) in the TRILL OAM Application Identifier TLV.
 o  If in-band response was requested, dispatch the frame to the TRILL
    data plane with request-originator RBridge nickname as the egress
    RBridge nickname.
 o  If out-of-band response was requested, dispatch the frame to the
    standard IP forwarding process.

12. Application of Continuity Check Message (CCM) in TRILL

 Section 7 provides an overview of CCM Messages defined in [8021Q] and
 how they can be used within TRILL OAM.  This section presents the
 application and theory of operations of CCM within the TRILL OAM
 framework.  Readers are referred to [8021Q] for CCM message format
 and applicable TLV definitions and usages.  Only the TRILL-specific
 aspects are explained below.
 In TRILL, between any two given MEPs, there can be multiple potential
 paths.  Whereas in [8021Q], there is always a single path between any
 two MEPs at any given time.  [RFC6905] requires solutions to have the
 ability to monitor continuity over one or more paths.
 CCM Messages are uni-directional, such that there is no explicit
 response to a received CCM message.  Connectivity status is indicated
 by setting the applicable flags (e.g., RDI) of the CCM messages
 transmitted by a MEP.
 It is important that the solution presented in this document
 accomplishes the requirements specified in [RFC6905] within the
 framework of [8021Q] in a straightforward manner and with minimum
 changes.  Section 8 defines multiple flows within the CCM object,

Senevirathne, et al. Standards Track [Page 46] RFC 7455 TRILL Fault Management March 2015

 each corresponding to a flow that a given MEP wishes to monitor.
 Hence, CCM, in multipath environments like TRILL, monitors per-flow
 connectivity and cross-connect errors.
 Receiving MEPs do not cross-check whether a received CCM belongs to a
 specific flow from the originating RBridge.  Any attempt to track
 status of individual flows may explode the amount of state
 information that any given RBridge has to maintain.
 The obvious question arises: how does the originating RBridge know
 which flow or flows are at fault?
 This is accomplished with a combination of the RDI flag in the CCM
 header, Flow Identifier TLV, and SNMP Notifications (Traps).
 Section 12.1 discusses the procedure.

12.1. CCM Error Notification

 Each MEP transmits four CCM messages per each flow.  ([8021Q] detects
 CCM fault when three consecutive CCM messages are lost).  Each CCM
 message has a unique sequence number (Session ID) and unique flow-
 identifier.  The flow-identifier is included in the OAM message via
 the Flow Identifier TLV.
 When a MEP notices a CCM timeout from a remote MEP (MEP-A), it sets
 the RDI flag on the next CCM message it generates.  Additionally, it
 logs and sends an SNMP notification that contains the remote MEP
 Identification, flow-identifier, and the sequence number of the last
 CCM message it received, and, if available, the flow-identifier and
 the sequence number of the first CCM message it received after the
 failure.  Each MEP maintains a unique flow-identifier per each flow;
 hence, the operator can easily identify flows that correspond to the
 specific flow-identifier.
 The following example illustrates the above.
 Assume there are two MEPs: MEP-A and MEP-B.
 Assume there are three flows between MEP-A and MEP-B.
 Let's assume MEP-A allocates sequence numbers as follows:
    Flow-1 Sequence={1,2,3,4,13,14,15,16,.. } flow-identifier=(1)
    Flow-2 Sequence={5,6,7,8,17,18,19,20,.. } flow-identifier=(2)
    Flow-3 Sequence={9,10,12,11,21,22,23,24,.. } flow-identifier=(3)

Senevirathne, et al. Standards Track [Page 47] RFC 7455 TRILL Fault Management March 2015

 Let's assume Flow-2 is at fault.
 MEP-B receives CCM from MEP-A with sequence numbers 1, 2, 3, and 4
 but did not receive 5, 6, 7, and 8.  CCM timeout is set to three CCM
 intervals in [8021Q].  Hence, MEP-B detects the error at the 8th CCM
 message.  At this time, the sequence number of the last good CCM
 message MEP-B has received from MEP-A is 4, and the flow-identifier
 of the last good CCM Message is (1).  Hence, MEP-B will generate a
 CCM error SNMP notification with MEP-A, last good flow-identifier
 (1), and sequence number 4.
 When MEP-A switches to Flow-3 after transmitting Flow-2, MEP-B will
 start receiving CCM messages.  In the foregoing example, it will be a
 CCM message with sequence numbers 9, 10, 11, 12, and 21 and so on.
 When in receipt of a new CCM message from a specific MEP, after a CCM
 timeout, the TRILL OAM will generate an SNMP Notification of CCM
 resume with remote MEP-ID, the first valid flow-identifier, and the
 sequence number after the CCM timeout.  In the foregoing example, it
 is MEP-A, flow-identifier (3), and sequence number 9.
 The remote MEP list under the CCM MIB Object is augmented to contain
 "Last Sequence Number", flow-identifier, and "CCM Timeout" variables.
 "Last Sequence Number" and flow-identifier are updated every time a
 CCM is received from a remote MEP.  The CCM Timeout variable is set
 when the CCM timeout occurs and is cleared when a CCM is received.

12.2. Theory of Operation

12.2.1. Actions by Originator RBridge

 The originator RBridge takes the following actions:
 o  Derives the Flow Entropy field based on flow-entropy information
    specified in the CCM Management object.
 o  Constructs the TRILL CCM OAM header as specified in [8021Q].
 o  The TRILL OAM Application Identifier TLV MUST be included as the
    first TLV with the flags set to applicable values.
 o  Includes other TLVs specified in [8021Q].
 o  Includes the following optional TLV, where applicable:
  1. Sender ID TLV (1)
 o  Specifies the Hop Count of the TRILL Data frame per user
    specification or utilize an applicable Hop Count value.

Senevirathne, et al. Standards Track [Page 48] RFC 7455 TRILL Fault Management March 2015

 o  Dispatches the OAM frame to the TRILL data plane for transmission.
 An RBridge transmits a total of four requests, each at CCM
 retransmission interval.  At each transmission, the Session
 Identification number MUST be incremented by one.
 At the 5th retransmission interval, the Flow Entropy of the CCM
 packet is updated to the next flow-entropy information specified in
 the CCM Management object.  If the current Flow Entropy is the last
 Flow Entropy specified, move to the first Flow Entropy specified and
 continue the process.

12.2.2. Intermediate RBridge

 Intermediate RBridges forward the frame as a normal data frame; no
 special handling is required.

12.2.3. Destination RBridge

 If the CCM Message is addressed to the local RBridge or multicast and
 satisfies the OAM identification methods specified in Section 3.2,
 then the RBridge data plane forwards the message to the CPU for
 further processing.
 The TRILL OAM application layer further validates the received OAM
 frame by examining the presence of OAM Ethertype at the end of the
 Flow Entropy.  Frames that do not contain OAM Ethertype at the end of
 the Flow Entropy MUST be discarded.
 The TRILL OAM application layer then validates the MD-Level and pass
 the packet to the OpCode demultiplexer.  The OpCode demultiplexer
 delivers CCM packets to the CCM process.
 The CCM process performs the processing specified in [8021Q].
 Additionally, the CCM process updates the CCM Management object with
 the sequence number of the received CCM packet.  Note: The last
 received CCM sequence number and CCM timeout are tracked per each
 remote MEP.
 If the CCM timeout is true for the sending remote MEP, then clear the
 CCM timeout in the CCM Management object and generate the SNMP
 notification as specified above.

Senevirathne, et al. Standards Track [Page 49] RFC 7455 TRILL Fault Management March 2015

13. Fragmented Reply

 TRILL OAM allows fragmented reply messages.  In case of fragmented
 replies, all parts of the reply MUST follow the procedure defined in
 this section.
 The same Session Identification Number MUST be included in all
 related fragments of the same message.
 The TRILL OAM Application Identifier TLV MUST be included, with the
 Fragment-ID field monotonically increasing with each fragment
 transmitted with the appropriate Final flag field.  The Final flag
 MUST only be equal to one on the final fragment of the reply.
 On the receiver, the process MUST order the fragments based on the
 Fragment-ID.  Any fragments received after the final fragment MUST be
 discarded.  Messages with incomplete fragments (i.e., messages with
 one or missing fragments after the receipt of the fragment with the
 final flag set) MUST be discarded as well.
 If the number of fragments exceeds the maximum supported fragments
 (255), then the Return Code of the reply message MUST be set to 1
 (Reply message), and the Return Sub-code MUST be set to 1 (Fragment
 limit exceeded).

14. Security Considerations

 Forged OAM packets could cause false error or failure indications,
 mask actual errors or failures, or be used for denial of service.
 Source addresses for messages can be forged and the out-of-band reply
 facility (see Section 8.4.4) provides for explicitly supplying the
 address for replies.  For protection against forged OAM packets, the
 Authentication TLV (see Section 8.4.13) can be used in an OAM message
 in TRILL.  This TLV is virtually identical to the IS-IS
 Authentication TLV specified in [IS-IS] and depends on IS-IS keying
 material and the current state of IS-IS keying as discussed in
 [KARPISIS] and [RFC5310].  In particular, there is currently no
 standardized IS-IS automated key management.
 Of course, authentication is ineffective unless verified and
 ineffective against senders who have the keying material needed to
 produce OAM messages that will pass authentication checks.
 Implementations MUST implement rate-limiting functionality to protect
 against exploitation of OAM messages as a means of denial-of-service
 attacks.  Aggressive rate-limiting may trigger false positive errors
 against CCM and LBM-based session monitoring.

Senevirathne, et al. Standards Track [Page 50] RFC 7455 TRILL Fault Management March 2015

 Even with authentication, replay of authenticated messages may be
 possible.  There are four types of messages: Continuity Check (CCM),
 Loopback, Path Trace, and Multi-destination Tree Verification (MTVM).
 In the case of CCM messages, sequence numbers are required (see
 Section 12.1) that can protect against replay.  In the case of
 Loopback Messages (see Section 9.1), a Loopback Transaction
 Identifier is included that, as required by [8021Q], is incremented
 with each transmission and can detect replays.  PTMs (see Section 10)
 and MTVMs (see Section 11.1) are specified to have the same format as
 Loopback Messages (although with different OpCodes), so they also
 have an identifier incremented with each transmission that can detect
 replays.  Thus, all TRILL OAM messages have a field that can be used
 for replay protection.
 For general TRILL-related security considerations, please refer to
 [RFC6325].
 [8021Q] requires that the MEP filters or passes through OAM messages
 based on the MD-Level.  The MD-Level is embedded deep in the OAM
 message.  Hence, conventional methods of frame filtering may not be
 able to filter frames based on the MD-Level.  As a result, OAM
 messages that must be dropped due to MD-Level mismatch may leak into
 a TRILL domain with a different MD-Level.
 This leaking may not cause any functionality loss.  The receiving
 MEP/MIP is required to validate the MD-level prior to acting on the
 message.  Any frames received with an incorrect MD-Level need to be
 dropped.
 Generally, a single operator manages each TRILL campus; hence, there
 is no risk of security exposure.  However, in the event of multi-
 operator deployments, operators should be aware of possible exposure
 of device-specific information, and appropriate measures must be
 taken.
 It is also important to note that the MPLS OAM framework [RFC4379]
 does not include the concept of domains and OAM filtering based on
 operators.  It is our opinion that the lack of OAM frame filtering
 based on domains does not introduce significant functional deficiency
 or security risk.
 It is possible to mandate requiring different credentials to use
 different OAM functions or capabilities within a specific OAM
 function.  Implementations may consider grouping users to different
 security clearance levels and restricting functions and capabilities
 to different clearance levels.  However, exact implementation details
 of such a framework are outside the scope of this document.

Senevirathne, et al. Standards Track [Page 51] RFC 7455 TRILL Fault Management March 2015

15. IANA Considerations

 IANA has made the assignments described below.

15.1. OAM Capability Flags

 Two TRILL-VER sub-TLV Capability Flags (see Section 3.3) have been
 assigned as follows:
   Bit     Description               Reference
   ---     -----------               ---------
   2       OAM capable               RFC 7455
   3       Backwards-compatible OAM  RFC 7455

15.2. CFM Code Points

 Four OpCodes have been assigned from the "CFM OAM IETF OpCodes" sub-
 registry as follows:
   Value     Assignment                                   Reference
   -----     ----------                                   ---------
   64        Path Trace Reply                             RFC 7455
   65        Path Trace Message                           RFC 7455
   66        Multi-destination Tree Verification Reply    RFC 7455
   67        Multi-destination Tree Verification Message  RFC 7455
 Eleven TLV Types have been assigned from the "CFM OAM IETF TLV Types"
 sub-registry as follows:
   Value     Assignment                            Reference
   -----     ----------                            ---------
   64        TRILL OAM Application Identifier TLV  RFC 7455
   65        Out-of-Band Reply Address TLV         RFC 7455
   66        Diagnostic Label TLV                  RFC 7455
   67        Original Data Payload TLV             RFC 7455
   68        RBridge Scope TLV                     RFC 7455
   69        Previous RBridge Nickname TLV         RFC 7455
   70        Next-Hop RBridge List TLV             RFC 7455
   71        Multicast Receiver Port Count TLV     RFC 7455
   72        Flow Identifier TLV                   RFC 7455
   73        Reflector Entropy TLV                 RFC 7455
   74        Authentication TLV                    RFC 7455

Senevirathne, et al. Standards Track [Page 52] RFC 7455 TRILL Fault Management March 2015

15.3. MAC Addresses

 IANA has assigned a unicast and a multicast MAC address under the
 IANA Organizationally Unique Identifier (OUI) for identification of
 OAM packets as discussed for the backwards-compatibility method
 (Appendix A.2) and based on the request template in Appendix C.  The
 assigned addresses are 00-00-5E-90-01-00 (unicast) and
 01-00-5E-90-01-00 (multicast).

15.4. Return Codes and Sub-codes

 IANA has created the "TRILL OAM Return Codes" registry within the
 "Transparent Interconnection of Lots of Links (TRILL) Parameters"
 registry and a separate sub-code sub-registry for each Return Code as
 shown below:
 Registry: TRILL OAM Return Codes
 Registration Procedure: Standards Action
    Return Code    Assignment        References
    -----------    ----------        ----------
       0           Request message   RFC 7455
       1           Reply message     RFC 7455
       2-255       Unassigned        RFC 7455
 Sub-Registry: Sub-codes for TRILL OAM Return Code 0
 Registration Procedure: Standards Action
    Sub-code      Assignment        References
    --------      ----------        ----------
       0          Valid request     RFC 7455
       1-255      Unassigned        RFC 7455
 Sub-Registry: Sub-codes for TRILL OAM Return Code 1
 Registration Procedure: Standards Action
    Sub-code      Assignment              References
    --------      ----------              ----------
       0          Valid response          RFC 7455
       1          Fragment limit exceeded RFC 7455
       2          Intermediate RBridge    RFC 7455
       3-255      Unassigned              RFC 7455

Senevirathne, et al. Standards Track [Page 53] RFC 7455 TRILL Fault Management March 2015

15.5. TRILL Nickname Address Family

 IANA has allocated 16396 as the Address Family Number for TRILL
 nickname.

16. References

16.1. Normative References

 [8021Q]    IEEE, "IEEE Standard for Local and metropolitan area
            networks -- Bridges and Bridged Networks", IEEE Std
            802.1Q, December 2014.
 [IS-IS]    ISO/IEC, "Information technology -- Telecommunications and
            information exchange between systems -- Intermediate
            System to Intermediate System intra-domain routeing
            information exchange protocol for use in conjunction with
            the protocol for providing the connectionless-mode network
            service (ISO 8473)", ISO/IEC 10589:2002, Second Edition,
            2002.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997,
            <http://www.rfc-editor.org/info/rfc2119>.
 [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 5226,
            May 2008, <http://www.rfc-editor.org/info/rfc5226>.
 [RFC5310]  Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
            and M. Fanto, "IS-IS Generic Cryptographic
            Authentication", RFC 5310, February 2009,
            <http://www.rfc-editor.org/info/rfc5310>.
 [RFC6325]  Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
            Ghanwani, "Routing Bridges (RBridges): Base Protocol
            Specification", RFC 6325, July 2011,
            <http://www.rfc-editor.org/info/rfc6325>.
 [RFC7172]  Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and
            D. Dutt, "Transparent Interconnection of Lots of Links
            (TRILL): Fine-Grained Labeling", RFC 7172, May 2014,
            <http://www.rfc-editor.org/info/rfc7172>.

Senevirathne, et al. Standards Track [Page 54] RFC 7455 TRILL Fault Management March 2015

16.2. Informative References

 [KARPISIS] Chunduri, U., Tian, A., and W. Lu, "KARP IS-IS security
            analysis", Work in Progress, draft-ietf-karp-isis-
            analysis-04, March 2015.
 [RFC4379]  Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key
            Ciphersuites for Transport Layer Security (TLS)", RFC
            4279, December 2005,
            <http://www.rfc-editor.org/info/rfc4279>.
 [RFC6291]  Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
            D., and S. Mansfield, "Guidelines for the Use of the "OAM"
            Acronym in the IETF", BCP 161, RFC 6291, June 2011,
            <http://www.rfc-editor.org/info/rfc6291>.
 [RFC6361]  Carlson, J. and D. Eastlake 3rd, "PPP Transparent
            Interconnection of Lots of Links (TRILL) Protocol Control
            Protocol", RFC 6361, August 2011,
            <http://www.rfc-editor.org/info/rfc6361>.
 [RFC6905]  Senevirathne, T., Bond, D., Aldrin, S., Li, Y., and R.
            Watve, "Requirements for Operations, Administration, and
            Maintenance (OAM) in Transparent Interconnection of Lots
            of Links (TRILL)", RFC 6905, March 2013,
            <http://www.rfc-editor.org/info/rfc6905>.
 [RFC7174]  Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake
            3rd, "Transparent Interconnection of Lots of Links (TRILL)
            Operations, Administration, and Maintenance (OAM)
            Framework", RFC 7174, May 2014,
            <http://www.rfc-editor.org/info/rfc7174>.
 [RFC7176]  Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt,
            D., and A. Banerjee, "Transparent Interconnection of Lots
            of Links (TRILL) Use of IS-IS", RFC 7176, May 2014,
            <http://www.rfc-editor.org/info/rfc7176>.
 [RFC7178]  Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D.
            Ward, "Transparent Interconnection of Lots of Links
            (TRILL): RBridge Channel Support", RFC 7178, May 2014,
            <http://www.rfc-editor.org/info/rfc7178>.
 [RFC7179]  Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and C.
            Bestler, "Transparent Interconnection of Lots of Links
            (TRILL): Header Extension", RFC 7179, May 2014,
            <http://www.rfc-editor.org/info/rfc7179>.

Senevirathne, et al. Standards Track [Page 55] RFC 7455 TRILL Fault Management March 2015

 [RFC7180]  Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., and
            A. Banerjee, "Transparent Interconnection of Lots of Links
            (TRILL): Clarifications, Corrections, and Updates", RFC
            7180, May 2014, <http://www.rfc-editor.org/info/rfc7180>.
 [RFC7456]  Mizrahi, T., Senevirathne, T., Salam, S., Kumar, D., and
            D. Eastlake 3rd, "Loss and Delay Measurement in
            Transparent Interconnection of Lots of Links (TRILL)", RFC
            7456, March 2015,
            <http://www.rfc-editor.org/info/rfc7456>.
 [TRILLOAMMIB]
            Kumar, D., Salam, S., and T. Senevirathne, "TRILL OAM
            MIB", Work in Progress, draft-deepak-trill-oam-mib-01,
            October 2013.
 [Y1731]    ITU-T, "OAM functions and mechanisms for Ethernet based
            networks", ITU-T Recommendation G.8013/Y.1731, November
            2013.

Senevirathne, et al. Standards Track [Page 56] RFC 7455 TRILL Fault Management March 2015

Appendix A. Backwards Compatibility

 The methodology presented in this document is in-line with the
 framework defined in [8021Q] for providing fault management coverage.
 However, in practice, some TRILL platforms may not have the
 capabilities to support some of the required techniques.  In this
 appendix, we present a method that allows RBridges, which do not have
 the required hardware capabilities, to participate in the TRILL OAM
 solution.
 There are two broad areas to be considered: 1) the Maintenance Point
 (MEP/MIP) Model and 2) data-plane encoding and frame identification.

A.1. Maintenance Point (MEP/MIP) Model

 For backwards compatibility, MEPs and MIPs are located in the CPU.
 This will be referred to as the "central brain" model as opposed to
 "port brain" model.
 In the "central brain" model, an RBridge using either Access Control
 Lists (ACLs) or some other method forwards qualifying OAM messages to
 the CPU.  The CPU then performs the required processing and
 multiplexing to the correct MP (Maintenance Point).
 Additionally, RBridges MUST have the capability to prevent the
 leaking of OAM packets, as specified in [RFC6905].

A.2. Data-Plane Encoding and Frame Identification

 The backwards-compatibility method presented in this section defines
 methods to identify OAM frames when implementations do not have
 capabilities to utilize the TRILL OAM Alert flag presented earlier in
 this document to identify OAM frames in the hardware.
 It is assumed that ECMP path selection of non-IP flows utilizes MAC
 DA, MAC SA, and VLAN; IP flows utilize IP DA, IP SA, TCP/UDP port
 numbers, and other Layer 3 and Layer 4 information.  The well-known
 fields to identify OAM flows are chosen such that they mimic the ECMP
 selection of the actual data along the path.  However, it is
 important to note that there may be implementations that would
 utilize these well-known fields for ECMP selections.  Hence,
 implementations that support OAM SHOULD move to utilizing the TRILL
 Alert flag, as soon as possible, and methods presented here SHOULD be
 used only as an interim solution.

Senevirathne, et al. Standards Track [Page 57] RFC 7455 TRILL Fault Management March 2015

 Identification methods are divided in to four broader groups:
 1.  Identification of Unicast non-IP OAM Flows,
 2.  Identification of Multicast non-IP OAM Flows,
 3.  Identification of Unicast IP OAM Flows, and
 4.  Identification of Multicast IP OAM Flows.
 As presented in Figure 24, based on the flow type (as defined above),
 implementations are required to use a well-known value in either the
 Inner.MacSA field or OAM Ethertype field to identify OAM flows.
 A receiving RBridge identifies OAM flows based on the presence of the
 well-known values in the specified fields.  Additionally, for unicast
 flows, the egress RBridge nickname of the packet MUST match that of
 the local RBridge, or for multicast flows, the TRILL Header multicast
 ("M") flag MUST be set.
 Unicast OAM flows that qualify for local processing MUST be
 redirected to the OAM process and MUST NOT be forwarded (to prevent
 leaking of the packet out of the TRILL campus).
 A copy of multicast OAM flows that qualify for local processing MUST
 be sent to the OAM process, and the packets MUST be forwarded along
 the normal path.  Additionally, methods MUST be in place to prevent
 multicast packets from leaking out of the TRILL campus.
 Figure 24 summarizes the identification of different OAM frames from
 data frames.
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Flow Entropy   |Inner.MacSA  |OAM Ethertype  |Egress   |
    |               |             |               |nickname |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Unicast no IP  | N/A         |Match          |Match    |
    |               |             |               |         |
    |Multicast no IP| N/A         |Match          |N/A      |
    |               |             |               |         |
    |Unicast IP     | Match       |N/A            |Match    |
    |               |             |               |         |
    |Multicast IP   | Match       |N/A            |N/A      |
    |               |             |               |         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     Figure 24: Identification of TRILL OAM Frames

Senevirathne, et al. Standards Track [Page 58] RFC 7455 TRILL Fault Management March 2015

 The unicast and multicast Inner.MacSAs used for the unicast and
 multicast IP cases, respectively, are 00-00-5E-90-01-00 and
 01-00-5E-90-01-00.  These have been assigned per the request in
 Appendix C.
 It is important to note that all RBridges MUST generate OAM flows
 with the "A" flag set and CFM Ethertype "0x8902" at the Flow Entropy
 off-set.  However, well-known values MUST be utilized as part of the
 flow-entropy when generating OAM messages destined for older RBridges
 that are compliant to the backwards-compatibility method defined in
 this appendix.

Appendix B. Base Mode for TRILL OAM

 CFM, as defined in [8021Q], requires configuration of several
 parameters before the protocol can be used.  These parameters include
 MAID, Maintenance Domain Level (MD-Level), and MEP-IDs.  The Base
 Mode for TRILL OAM defined here facilitates ease of use and provides
 out-of-the-box plug-and-play capabilities, supporting the operational
 and manageability considerations described in Section 6 of [RFC7174].
 All RBridges that support TRILL OAM MUST support the Base Mode
 operation.
 All RBridges MUST create a default MA with MAID as specified herein.
 MAID [8021Q] has a flexible format and includes two parts:
 Maintenance Domain Name and Short MA Name.  In the Base Mode
 operation, the value of the Maintenance Domain Name must be the
 character string "TrillBaseMode" (excluding the quotes).  In the Base
 Mode operation, the Short MA Name format is set to a 2-octet integer
 format (value 3 in Short MA Format field) and Short MA Name set to
 65532 (0xFFFC).
 The default MA belongs to MD-Level 3.
 In the Base Mode of operation, each RBridge creates a single UP MEP
 associated with a virtual OAM port with no physical layer (NULL PHY).
 The MEP-ID associated with this MEP is the 2-octet RBridge nickname.
 By default, all RBridges operating in Base Mode for TRILL OAM are
 able to initiate LBM, PTM, and other OAM tools with no configuration.
 Implementations MAY provide default flow-entropy to be included in
 OAM messages.  Content of the default flow-entropy is outside the
 scope of this document.

Senevirathne, et al. Standards Track [Page 59] RFC 7455 TRILL Fault Management March 2015

 Figure 25 depicts encoding of MAID within CCM messages.
    +-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Field Name     |Size     |
    |               |         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Maintenance    | 1       |
    |Domain Format  |         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Maintenance    | 2       |
    |Domain Length  |         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Maintenance    | variable|
    |Domain Name    |         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Short MA       | 1       |
    |Name   Format  |         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Short MA       | 2       |
    |Name  Length   |         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Short MA       | variable|
    |Name           |         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Padding        | Variable|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+
    Figure 25: MAID Structure as Defined in [8021Q]
 Maintenance Domain Name Format: set to value 4
 Maintenance Domain Name Length: set to value 13
 Maintenance Domain Name: set to TrillBaseMode
 Short MA Name Format: set to value 3
 Short MA Name Length: set to value 2
 Short MA Name: set to FFFC
 Padding: set of zero up to 48 octets of total length of the MAID
 Please refer to [8021Q] for details.

Senevirathne, et al. Standards Track [Page 60] RFC 7455 TRILL Fault Management March 2015

Appendix C. MAC Addresses Request

 Applicant Name: IETF TRILL Working Group
 Applicant Email:  tsenevir@cisco.com
 Applicant Telephone: +1-408-853-2291
 Use Name: TRILL OAM
 Document: RFC 7455
 Specify whether this is an application for EUI-48 or EUI-64
 identifiers: EUI-48
 Size of Block requested: 1
 Specify multicast, unicast, or both: Both

Senevirathne, et al. Standards Track [Page 61] RFC 7455 TRILL Fault Management March 2015

Acknowledgments

 Work on this document was largely inspired by the directions provided
 by Stewart Bryant in finding a common OAM solution between SDOs.
 Acknowledgments are due for many who volunteered to review this
 document, notably, Jari Arkko, Adrian Farrel, Pete Resnick, Stephen
 Farrell, Dan Romascanu, Gayle Nobel, and Tal Mizrahi.
 Special appreciation is due to Dinesh Dutt for his support and
 encouragement, especially during the initial discussion phase of
 TRILL OAM.

Authors' Addresses

 Tissa Senevirathne
 Cisco Systems
 375 East Tasman Drive
 San Jose, CA 95134
 United States
 Phone: +1 408-853-2291
 EMail: tsenevir@cisco.com
 Norman Finn
 Cisco Systems
 510 McCarthy Blvd
 Milpitas, CA 95035
 United States
 EMail: nfinn@cisco.com
 Samer Salam
 Cisco Systems
 595 Burrard St., Suite 2123
 Vancouver, BC V7X 1J1
 Canada
 EMail: ssalam@cisco.com

Senevirathne, et al. Standards Track [Page 62] RFC 7455 TRILL Fault Management March 2015

 Deepak Kumar
 Cisco Systems
 510 McCarthy Blvd
 Milpitas, CA 95035
 United States
 Phone: +1 408-853-9760
 EMail: dekumar@cisco.com
 Donald Eastlake 3rd
 Huawei Technologies
 155 Beaver Street
 Milford, MA 01757
 United States
 Phone: +1-508-333-2270
 EMail: d3e3e3@gmail.com
 Sam Aldrin
 Huawei Technologies
 2330 Central Express Way
 Santa Clara, CA 95951
 United States
 EMail: aldrin.ietf@gmail.com
 Yizhou Li
 Huawei Technologies
 101 Software Avenue
 Nanjing 210012
 China
 Phone: +86-25-56625375
 EMail: liyizhou@huawei.com

Senevirathne, et al. Standards Track [Page 63]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7455.txt · Last modified: 2015/03/11 00:33 (external edit)