[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 draft-ietf-trill-oam-fm

TRILL Working group                                  Tissa Senevirathne
Internet Draft                                              Norman Finn
Intended status: Standard Track                             Samer Salam
                                                           Deepak Kumar
                                                                  CISCO

                                                        Donald Eastlake
                                                             Sam Aldrin
                                                              Yizhou Li
                                                                 Huawei

                                                           May 28, 2013
Expires: November 2013



                          TRILL Fault Management
                      draft-tissa-trill-oam-fm-02.txt


Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on November 28, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors. All rights reserved.




Senevirathne          Expires November 28, 2013                [Page 1]


Internet-Draft          TRILL Fault Management                 May 2013


   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.

Abstract

   TRILL OAM Fault Management specification is presented in this
   document. Methods in this document follow the IEEE 802.1 CFM
   framework and reuse OAM tools where possible. Additional messages and
   TLVs are defined for TRILL specific applications or where a different
   set of information is required other than IEEE 802.1 CFM.

Table of Contents


   1. Introduction...................................................4
   2. Conventions used in this document..............................4
   3. General Format of TRILL OAM frames.............................5
      3.1. Identification of TRILL OAM frames........................7
      3.2. Use of TRILL OAM Flag.....................................7
         3.2.1. Handling of TRILL frames with the "A" Flag...........8
      3.3. Backwards Compatibility Method............................8
      3.4. OAM Capability Announcement..............................10
   4. TRILL OAM Layering vs. IEEE Layering..........................11
      4.1. Processing at 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 Procession.................................12
      4.3. TRILL Encapsulation and De-capsulation Layer.............13
         4.3.1. Receive Processing for Unicast packets..............13
         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 (MA) in TRILL........................17
   6. MEP Addressing................................................18
      6.1. Use of MIP in TRILL......................................21
   7. Approach for Backwards Compatibility..........................23
   8. Continuity Check Message (CCM)................................24


Senevirathne          Expires November 28, 2013                [Page 2]


Internet-Draft          TRILL Fault Management                 May 2013


   9. TRILL OAM Message Channel.....................................26
      9.1. TRILL OAM Message header.................................26
      9.2. TRILL OAM Opcodes........................................27
      9.3. Format of TRILL OAM TLV..................................27
      9.4. TRILL OAM TLVs...........................................28
         9.4.1. Common TLVs between 802.1ag and TRILL...............28
         9.4.2. TRILL OAM Specific TLVs.............................29
         9.4.3. TRILL OAM Application Identifier TLV................29
         9.4.4. Out Of Band Reply Address TLV.......................31
         9.4.5. Diagnostics Label TLV...............................31
         9.4.6. Original Data Payload TLV...........................32
         9.4.7. RBridge scope TLV...................................33
         9.4.8. Previous RBridge nickname TLV.......................33
         9.4.9. Next Hop RBridge List TLV...........................34
         9.4.10. Multicast Receiver Port count TLV..................35
         9.4.11. Flow Identifier (flow-id) TLV......................35
   10. Loopback Message.............................................37
      10.1. Loopback OAM Message format.............................37
      10.2. Theory of Operation.....................................37
         10.2.1. Originator RBridge.................................37
         10.2.2. Intermediate RBridge...............................38
         10.2.3. Destination RBridge................................38
   11. Path Trace Message...........................................39
      11.1. Theory of Operation.....................................39
         11.1.1. Originator RBridge.................................39
         11.1.2. Intermediate RBridge...............................40
         11.1.3. Destination RBridge................................41
   12. Multi-Destination Tree Verification (MTV) Message............41
      12.1. Multi-Destination Tree Verification (MTV) OAM Message Format
      ..............................................................42
      12.2. Theory of Operation.....................................42
         12.2.1. Originator RBridge.................................42
         12.2.2. Receiving RBridge..................................44
         12.2.3. In scope RBridges..................................44
   13. Application of Continuity Check Message (CCM) in TRILL.......45
      13.1. CCM Error Notification..................................45
      13.2. Theory of Operation.....................................47
         13.2.1. Originator RBridge.................................47
         13.2.2. Intermediate RBridge...............................47
         13.2.3. Destination RBridge................................47
   14. Fragmented Reply.............................................48
   15. Security Considerations......................................48
   16. IEEE Allocation Considerations...............................48
   17. IANA Considerations..........................................49
   18. References...................................................49
      18.1. Normative References....................................49
      18.2. Informative References..................................49


Senevirathne          Expires November 28, 2013                [Page 3]


Internet-Draft          TRILL Fault Management                 May 2013


   19. Acknowledgments..............................................50
   Appendix A. Unicast MAC Request..................................51

1. Introduction

   The general structure of TRILL OAM messages is presented in
   [TRLOAMFRM]. According to [TRLOAMFRM], TRILL OAM messages consist of
   five parts: link header, TRILL header, flow entropy, OAM message
   channel, and link trailer.

   The OAM message channel allows defining various control information
   and carrying 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 enables consistency between different
   OAM technologies and promotes nested fault monitoring and isolation
   between technologies that share the same OAM framework.

   This document uses the message format defined in IEEE 802.1ag
   Connectivity Fault Management (CFM) [8021Q] as the basis for the
   TRILL OAM message channel.

   The ITU-T Y.1731 [Y1731] standard utilizes the same messaging format
   as [8021Q] and OAM messages where applicable. This documenttake a
   similar stance and propose reusing [8021Q] in TRILL OAM. It is
   assumed readers are familiar with [8021Q] and [Y1731]. Readers who
   are not familiar with these documents are encouraged to review them.

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

   Acronyms used in the document include the following:

      MP - Maintenance Point [TRLOAMFRM]

      MEP - Maintenance End Point [TRLOAMFRM] [8021Q]

      MIP - Maintenance Intermediate Point [TRLOAMFRM] [8021Q]

      MA - Maintenance Association [8021Q] [TRLOAMFRM]

      MD - Maintenance Domain [8021Q]



Senevirathne          Expires November 28, 2013                [Page 4]


Internet-Draft          TRILL Fault Management                 May 2013


      CCM - Continuity Check Message [8021Q]

      LBM - Loop Back Message [8021Q]

      PTM - Path Trace Message

      MTV - Multi-destination Tree Verification Message

      OAM - Operations, Administration, and Maintenance [RFC6291]

      TRILL - Transparent Interconnection of Lots of Links [RFC6325]

      FGL  - Fine Grained Label [RFCfgl]

      ECMP - Equal Cost Multipath

      ISS  - Internal Sub Layer Service [8021Q]



3. General Format of TRILL OAM frames

   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.

   For accurate monitoring and/or diagnostics, OAM Messages are required
   to follow the same path as corresponding data packets. [TRLOAMFRM]
   proposes a high-level format of the OAM messages. The details of the
   TRILL OAM frame format are defined in this document.














Senevirathne          Expires November 28, 2013                [Page 5]


Internet-Draft          TRILL Fault Management                 May 2013


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   .    Link  Header               . (variable)
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +    TRILL Header               + 8 or more bytes
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   .   Flow Entropy                . 96 bytes
   .                               .
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   OAM Ether Type              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   .   OAM Message Channel         . Variable
   .                               .
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Link Trailer              | Variable
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                   Figure 1 Format of TRILL OAM Messages



   Link Header: Media-dependent header. For Ethernet, this includes
   Destination MAC, Source MAC, VLAN (optional) and EtherType fields.

   TRILL Header: Minimum of 8 bytes when the Extended Header is not
   included [RFC6325]

   Flow Entropy: This is a 96-byte fixed size field. The least
   significant bits of the field MUST be padded with zeros, up to 96
   bytes, when the flow entropy 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 [TRILLEXT] and [RFC6325].

   OAM Ether Type: OAM Ether Type is 16-bit EtherType that identifies
   the OAM Message channel that follows. This document specifies using
   the EtherType allocated for 802.1ag for this purpose. Identifying the


Senevirathne          Expires November 28, 2013                [Page 6]


Internet-Draft          TRILL Fault Management                 May 2013


   OAM Message Channel with a dedicated EtherType allows the easy
   identification of the beginning of the OAM message channel across
   multiple standards.

   OAM Message Channel: This is a variable size section that carries OAM
   related information. Message format defined in [8021Q] will be reused
   for TRILL OAM.

   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 a method to identify OAM frames. This document updates
   [RFC6325] to include specific methods to identify TRILL OAM frames.
   Section 3.2. below explains the details of the method. However, it is
   important, for backwards compatibility reasons, to define methods of
   identifying TRILL OAM frames without using these extensions. Section
   3.3. presents a set of possible methods for identifying OAM frames
   without using the proposed extensions of section 3.2. The methods
   defined in section 3.3. impose limitations on the construction of the
   flow entropy field of the OAM frames but MUST be used when backward
   compatibility is required with TRILL switches not supporting the
   method specified in Section 3.2.


  3.2. Use of TRILL OAM Flag

   The TRILL Header, as defined in [RFC6325], has two reserved bits that
   are currently unused. RBridges are currently required to ignore these
   fields. This document specifies use of the reserved bit next to
   Version field in the TRILL header as the Alert flag. Alert flag will
   be denoted by "A".


   Implementations that support the extension of using the "A" flag to
   identify frames MUST use that flag and the methods specified in
   section 3.2.1. The "A" flag MUST NOT be utilized for forwarding
   decisions such as the selection of which ECMP path or multi-
   destination tree to use.








Senevirathne          Expires November 28, 2013                [Page 7]


Internet-Draft          TRILL Fault Management                 May 2013


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


                           Figure 2 TRILL Header

   A (1 bit) - Indicates this is a possible OAM frame and is subject to
   specific handling as specified in this document.

   All other fields carry the same meaning as defined in RFC6325.

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

   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 Ether Type (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.

3.3. Backwards Compatibility Method

   Backward compatibility method presented in this section defines
   methods to identify OAM frames when implementations do not have
   capabilities to utilize TRILL OAM Alert flag presented earlier. It is
   assumed ECMP path selection of non-IP flows utilize MAC DA, MAC SA
   and VLAN, IP Flows utilize IP DA, IP SA and 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 TRILL OAM Flag, as soon as
   possible and methods presented here SHOULD be used only as an interim
   solution.



   Identification methods are divided in to 4 broader groups.

   Identification of Unicast non-IP OAM Flows,



Senevirathne          Expires November 28, 2013                [Page 8]


Internet-Draft          TRILL Fault Management                 May 2013


   Identification of Multicast non-IP OAM Flows,

   Identification of Unicast IP OAM Flows and

   Identification of Multicast IP OAM Flows



   As presented in the table below, based on the flow type (as defined
   above), implementations are required to use a well-known value in
   either the source MAC field or Ethertype field to identify OAM flows.

   Receiving RBridges identifies OAM flows based on the presence of the
   well-known values in the specified fields, AND additionally, for
   unicast flows, egress RBRdige nickname of the packet MUST match that
   of the local RBRidge or for multicast flows, TRILL header mutlicast
   flag MUST be set.

   Unicast OAM flows that qualify for local processing MUST be
   redirected to the OAM process and MUST NOT be forward along (that 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 packet MUST be forwarded along the
   normal path. Additionally, methods MUST be in place to prevent
   multicast packets leaking out of the TRILL campus.

   The following table summarizes the identification of different OAM
   frames from data frames.



   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Flow Entropy   |Inner    |OAM Ether|Egress   |
   |               |MacSA    |Type     |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 3 Identification of TRILL OAM Frames


Senevirathne          Expires November 28, 2013                [Page 9]


Internet-Draft          TRILL Fault Management                 May 2013




  3.4. OAM Capability Announcement

   Any given TRILL RBridge can be (1) OAM incapable or (2) OAM capable
   with new extensions or (3) OAM capable with backwards-compatible
   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.

   Capability flags defined in TRILL version sub-TLV (TRILL-VER)
   [rfc6326bis] will be utilized for announcing OAM capabilities. The
   following OAM related Flags are defined:

   O - OAM Capable

   B - Backwards Compatible.

   A capability announcement, with O Flag set to 1 and B flag set to 1,
   indicates that the implementation is OAM capable but utilize
   backwards compatible method defined in section 3.3. A capability
   announcement, with O Flag set to 1 and B flag set to 0, indicates
   that the implementation is OAM capable and utilizes the method
   specified in section 3.2.

   When O Flag is set to 0, the announcing implementation is considered
   not capable of OAM and in this case the B flag is ignored.

      +-+-+-+-+-+-+-+-+
      | Type          |              (1 byte)
      +-+-+-+-+-+-+-+-+
      | Length        |              (1 byte)
      +-+-+-+-+-+-+-+-+
      | Max-version   |              (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
      |A|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 4 TRILL-VER sub-TLV [rfc6326bis] with O and B flags


   NOTE: Bit position of O and B flags in the TRILL-VER sub-TLV are
   presented above as an example. Actual positions of the flags will be
   determined by TRILL WG and IANA and future revision of this document
   will be updated to include the allocations.


Senevirathne          Expires November 28, 2013               [Page 10]


Internet-Draft          TRILL Fault Management                 May 2013



4. TRILL OAM Layering vs. IEEE Layering

   This section presents the placement of the TRILL OAM shim within the
   IEEE 802.1 layers. The processing of both the Transmit and Receive
   directions is 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 5 Placement of TRILL MP within IEEE 802.1





Senevirathne          Expires November 28, 2013               [Page 11]


Internet-Draft          TRILL Fault Management                 May 2013


   [RFC6325] Section 4.6 provides a detailed explanation of frame
   processing. Please refer to [RFC6325] for processing scenarios not
   covered herein.

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

   On links using an inherently point-to-point technology, such as PPP
   [RFC6361], there is no Outer.MacDA, Outer.MacSA, our Outer.VLAN
   because these are part of the link for Ethernet. Point-to-point links
   typically have link headers without these fields. These fields are
   primarily significant for native frames from and/or to end stations.

4.1. Processing at ISS Layer

4.1.1. Receive Processing

   The ISS Layer receives an indication from the port. It extracts DA,
   SA and marks the remainder of the payload as M1. 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

   Receives (DA, SA, M1) indication from ISS Layer. Extracts the VLAN ID
   an priority from the M1 part of the received indication and
   constructs (DA, SA, VLAN, PRI, M2). VLAN+PRI+M2 map to M1 in the
   received indication. Pass (DA, SA, VLAN, PRI, M2) to the TRILL
   encap/decap procession layer.

4.2.2. Transmit Procession

   Receive (DA, SA, VLAN, PRI, M2) indication from TRILL encap/decap
   processing layer. Merge VLAN, M2 to form M1. Pass down (DA, SA, M1)
   to the ISS processing Layer.




Senevirathne          Expires November 28, 2013               [Page 12]


Internet-Draft          TRILL Fault Management                 May 2013


4.3. TRILL Encapsulation and De-capsulation Layer

4.3.1. Receive Processing for Unicast packets

   Receive indication (DA, SA, VLAN,PRI,M2) from End Station VLAN and
   Priority Processing Layer.

      o If DA matches port Local DA and Frame is of TRILL EtherType

        . Discard DA, SA, VLAN, PRI. From M2, derive (TRILL-HDR, iDA,
          iSA, i-VL, M3)

        . If TRILL nickname is Local and TRILL-OAM Flag is set

            Pass on to OAM processing

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

     o If DA matches port Local DA and EtherType is RBridge-Channel
   [Channel]

        . Process as a possible unicast native RBridge Channel packet

     o If DA matches port Local DA and EtherType is neither TRILL nor
     RBridge-Channel

         . Discard packet

     o If DA does not match and port is Appointed Forwarder for VLAN and
   EtherType is not TRILL or RBridge-Channel

        . Insert TRILL-Hdr and send (TRILL-HDR, iDA, iSA,i-VL, M3)
          indication to RBridge Layer <- This is the ingress function

4.3.2. Transmit Processing for unicast packets

     o  Receive indication (TRILL-HDR, iDA, iSA, iVL, M3) from RBridge
        Layer

     o  If egress TRILL nickname is local

          o If port is Appointed Forwarder for iVL and the port is not
             configured as a trunk or p2p port and (TRILL Alert Flag set
             and OAM EtherType present) then

               . Strip TRILL-HDR and construct (DA, SA, VLAN, M2)


Senevirathne          Expires November 28, 2013               [Page 13]


Internet-Draft          TRILL Fault Management                 May 2013


          o Else

               . Discard packet

     o  If egress TRILL nickname is not local

          o Insert Outer.MacDA, Outer.MacSA, Outer.VLAN, 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 VLAN End Station processing Layer.

4.3.3. Receive Processing for Multicast packets

     o  Receive (DA,SA,V,M2) from VLAN aware end station processing
        layer

     o  If the DA is All-RBridges and the EtherType is TRILL

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

          o If TRILL OAM Flag is set and OAM EtherType is present at the
             end of Flow entropy

               . Perform OAM Processing

          o Else extract the TRILL header, inner MAC addresses and inner
             VLAN and pass indication (TRILL-HDR, iDA, iSA, iVL and M3)
             to 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 Ethertype
        is not TRILL or L2-IS-IS respectively

          o Discard the packet

     o  If the EtherType is TRILL but the multicast DA is not All-
        RBridge or if the EtherType is L2-IS-IS but the multicast Da is
        not All-IS-IS-RBridges

          o Discard the packet

     o  If DA is All-Edge-RBridges and EtherType is RBridge-Channel
        [Channel]


Senevirathne          Expires November 28, 2013               [Page 14]


Internet-Draft          TRILL Fault Management                 May 2013


          o   Process as a possible multicast native RBridge Channel
             packet

     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

          o 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: Link Aggregation Protocol, Link
             Layer Discovery Protocol).

     o  If the DA is some other multicast value

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

          o Pass the (TRILL-HDR, iDA, iSA, IVL, M3) to 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 RBridge
        layer.

     o  If TRILL-HDR multicast flag set and TRILL-HDR Alert flag set
        and OAM EtherType present then:

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

             NOTE: Second copy of native format is not made.

     o  Else If TRILL-HDR multicast flag set and Alert flag not set

          o 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, iVL and construct (DA,SA,V,M2) for native
             format.





Senevirathne          Expires November 28, 2013               [Page 15]


Internet-Draft          TRILL Fault Management                 May 2013


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

     o  Pass the indication (DA,SA,V,M2) to End Station VLAN processing
        layer.

  4.4. TRILL OAM Layer Processing

   TRILL OAM Processing Layer is located between the TRILL Encapsulation
   / De-capsulation layer and RBridge Layer. It performs 1.
   Identification of OAM frames that need local processing 2. Perform
   OAM processing or redirect to the CPU for OAM processing.

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

     o  If the TRILL Multicast Flag is set and TRILL Alert Flag is set
        and TRILL OAM EtherType is present then
          o If MEP or MIP is configured on the Inner.VLAN 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
                    .  Re-direct to OAM Processing (Do not forward
                       further)
               . If MD-LEVEL matches MD-LEVEL of MIP then
                    .  Make a Copy for OAM processing and continue


     o  Else if TRILL Alert Flag is set and TRILL OAM EtherType is
        present then
          o If MEP or MIP is configured on the Inner.VLAN of the packet
             then
               . discard packets that have MD-LEVEL not present or MD-
                  LEVEL is Less than that of the MEP.
               . If MD-LEVEL matches MD-LEVEL of the MEP then
                    .  Re-direct to OAM Processing (Do not forward
                       further)
               . If MD-LEVEL matches MD-LEVEL of MIP then
               . Make a Copy for OAM processing and continue

     o  Else // Non OAM l Packet
          o  Continue




Senevirathne          Expires November 28, 2013               [Page 16]


Internet-Draft          TRILL Fault Management                 May 2013


     o  Pass the indication (DA,SA,V,M2) to End Station VLAN processing
        layer.

   NOTE: In the Received path, processing above compares against Down
   MEP and MIP Half functions. In the transmit processing it compares
   against Up MEP and MIP Half functions.

   Appointed Forwarder is a Functionality that TRILL Encap/De-Cap layer
   performs. The TRILL Encap/De-cap Layer is responsible for prevention
   of leaking of OAM packets as native frames.


5. Maintenance Associations (MA) 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 802.ag MIB definitions,
   each MEP's MIB contains one or more flow entropy definitions
   corresponding to the set of flows that the MEP monitors.

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












Senevirathne          Expires November 28, 2013               [Page 17]


Internet-Draft          TRILL Fault Management                 May 2013


             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 6 Correlation of TRILL augmented MIB




6. MEP Addressing

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

   At the MEP, OAM packets go through a hierarchy of op-code de-
   multiplexers. The op-code de-multiplexers channel the incoming OAM
   packets to the appropriate message processor (e.g. LBM) The reader
   may refer to Figure 7 below for a visual depiction of these different
   de-multiplexers.

   1. Identify the packets that need OAM processing at the Local RBridge
     as specifies in Section 4.



Senevirathne          Expires November 28, 2013               [Page 18]


Internet-Draft          TRILL Fault Management                 May 2013


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

   2. The MEP first validates the MD-LEVEL and then

        a.  Redirect to MD-LEVEL De-multiplexer

   3. MD-LEVEL de-multiplexer 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 belonging to different MAs)

        a.  If the packet MD-LEVEL is equal to the configured MD-LEVEL
          of the MEP, then pass to the Opcode de-multiplexer

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

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

   4. Opcode De-multiplexer compares the opcode in the packet with
     supported opcodes

        a.  If Op-code is CCM, LBM, LBR, PTM, PTR, MTVM, MTVR, then pass
          on to the correct Processor

        b.  If Op-code is Unknown, then discard.



















Senevirathne          Expires November 28, 2013               [Page 19]


Internet-Draft          TRILL Fault Management                 May 2013




                               |
                               .CCM   LBM   PTM    MTV
                               |      |    |      |
                             +-+-+-+-+-+-+-+-+-+-+-+-+
                             |        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 7 OAM De-Multiplexers at MEP for active SAP

        T : Denotes Tap, that identifies OAM frames that need local
        processing. These are the packets with OAM flag set AND OAM
        Ether type is present after the flow entropy of the packet

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

        L : Denotes MD-Level processing. Packets with MD-Level less than
        the Level will be dropped. Packets with equal MD-Level are
        passed on to the opcode de-multiplexer. Others are passed on to
        the next level MD processors or eventually to the merge point
        (M).

        NOTE: LBM, MTV and PT are not subject to MA de-multiplexers.
        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          Expires November 28, 2013               [Page 20]


Internet-Draft          TRILL Fault Management                 May 2013






  6.1. Use of MIP in TRILL

   Maintenance Intermediate Points (MIP) 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 11. , 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.

   Similar approach as 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          Expires November 28, 2013               [Page 21]


Internet-Draft          TRILL Fault Management                 May 2013





                                             PT     MTV
                                              |      |
                             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             |             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 8 OAM De-Multiplexers at MIP for active SAP

   T: TAP processing for MIP. All packets with OAM flag set are
   captured.

   L : MD Level Processing, Packet with matching MD Level are "copied"
   to the Opcode de-multiplexer and 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 OP code de-
   multiplexer.

   M : Merge processor, merge OAM packets to be forwarded along with the
   data flow.

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

   Packets with unknown OpCodes are counted and discarded.







Senevirathne          Expires November 28, 2013               [Page 22]


Internet-Draft          TRILL Fault Management                 May 2013


7. Approach for Backwards Compatibility

   Methodology presented above in this document is in-line with the
   [8021Q] framework for providing fault management coverage. However,
   in practice, some platforms may not have the required capabilities to
   support some of the proposed techniques. In this section, we present
   a method that allows RBridges, which do not have the required
   hardware capabilities, to participate in the proposed OAM solution.

   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 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] and in the
   Transmission processing in Figure 9.



   Receiver Processing:

   If (M==1 && F==1) then
      Copy to CPU and Forward normally as defined in [RFC6325]
   Else if (M==0 && F==1 && egress nickname is the processing RBridge)
   then
      Forward to CPU BUT DO NOT forward along the data plane

   Else
      Forward as defined in [RFC6325]
   End;

   Transmit Processing:

   If (F==1) then
     Forward as defined in [RFC6325] BUT Do not de-capsulate and forward
   as a native frame
   Else
     Forward as defined in [RFC6325]


          Figure 9 Pseudo code for Backward compatible Processing



Senevirathne          Expires November 28, 2013               [Page 23]


Internet-Draft          TRILL Fault Management                 May 2013




    [8021Q] requires that the MEP filters or pass 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 in to
   a TRILL domain with 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 will be
   dropped.

   Generally, TRILL campuses are managed by a single operator, 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 [RFC4379] framework
   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.

8. 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 MEPID is a 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 identifies the interested 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 is defined within the
   MA. CCM transmit logic will utilize these flow entropy values when


Senevirathne          Expires November 28, 2013               [Page 24]


Internet-Draft          TRILL Fault Management                 May 2013


   constructing the CCM packets. Please see section 13.  below for the
   theory of operation of CCM.

   The MIB of [8021Q] is augmented with the definition of flow-entropy.
   Please see [TRILLOAMMIB] for definition of these and other TRILL
   related OAM MIB definitions. Below Figure depicts the correlation
   between MA, CCM and proposed flow-entropy.




             MA---
            |
             --- MEP
            |
            . - Remote MEP List
                   .
                   |
                    --- MEP-A
                   |
                    --- MEP-B
                   .

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

                   |
                    --- (Flow Entropy-1) {note we have to define
                   |                      destination nickname with
                    --- (Flow-entropy-2)  the flow entropy discuss}
                   |
                   . ---(Flow Entropy n)
           |
           . - CCM
                  |
                   --- (standard 8021ag entries)
                  |
                   --- (hop-count) { Augments IEEE8021-CFM-MIB}
                  |
                   --- (Other TBD TRILL OAM specific entries)
                                                   {Augmented}
           |
           .
           |
            - Other MIB entries




Senevirathne          Expires November 28, 2013               [Page 25]


Internet-Draft          TRILL Fault Management                 May 2013



                 Figure 10Augmentation 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.

9. TRILL OAM Message Channel

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

9.1. TRILL OAM Message header

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

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


                        Figure 11OAM Message Format



     o  MD-L: Maintenance Domain Level (3 bits). Identifies the
        maintenance domain level. For TRILL, in general, this field is
        set to zero. However, extension of TRILL, for example to support


Senevirathne          Expires November 28, 2013               [Page 26]


Internet-Draft          TRILL Fault Management                 May 2013


        multilevel, may create different MD-LEVELs and 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 propose to change the Version
        defined in [8021Q].

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

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

   MD-L, Version, Opcode, Flags and FirstTLVOffset fields collectively
   are referred to as the OAM Message Header.

   The Opcode specific information section of the OAM Message may
   contain Session Identification number, time-stamp, etc.

  9.2. TRILL OAM Opcodes

   The following Opcodes are defined for TRILL. Each of the Opcodes
   indicates a separate type of TRILL OAM message. Details of the
   messages are presented in the related sections.

   TRILL OAM Message Opcodes:

   TBD-64 : Path Trace Reply
    TBD-65 : Path Trace Message
    TBD-66 : Multicast Tree Verification Reply
    TBD-67 : Multicast Tree Verification Message


  9.3. Format of TRILL OAM TLV

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







Senevirathne          Expires November 28, 2013               [Page 27]


Internet-Draft          TRILL Fault Management                 May 2013


    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 12 TRILL OAM TLV



   Type (1 octet) : Specifies the Type of the TLV (see sections 9.4.
   for TLV types).

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

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

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

9.4. TRILL OAM TLVs

   TRILL related TLVs are defined in this section. [8021Q] defined TLVs
   are reused, where applicable. Types 32-63 are reserved for ITU-T
   Y.1731. We propose to reserve Types 64-95 for TRILL OAM TLVs.

9.4.1. Common TLVs between 802.1ag and TRILL

   The following TLVs are defined in [8021Q]. We propose to re-use 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


Senevirathne          Expires November 28, 2013               [Page 28]


Internet-Draft          TRILL Fault Management                 May 2013


     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



9.4.2. TRILL OAM Specific TLVs

   As indicated above, Types 64-95 will be requested to be reserved for
   TRILL OAM purposes. 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.

     Type           TLV Name
   -----------    ----------------------
    TBD-TLV-64     TRILL OAM Application Identifier
    TBD-TLV-65     Out of Band IP Address
    TBD-TLV-66     Diagnostic VLAN
    TBD-TLV-67     RBridge Scope
    TBD-TLV-68     Original Payload
    TBD-TLV-69     Previous RBridge Nickname
    TBD-TLV-70     RILL Next Hop RBridge List (ECMP)
    TBD-TLV-71     Multicast Receiver Availability
    TBD-TLV-72     Flow Identifier
    TBD-TLV-73 to TBD-TLV-95  Reserved


9.4.3. TRILL OAM Application Identifier TLV

   TRILL OAM Application Identifier TLV carries TRILL OAM application
   specific information. 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 an RBridge, unless that RBridge
   is also running Ethernet CFM.










Senevirathne          Expires November 28, 2013               [Page 29]


Internet-Draft          TRILL Fault Management                 May 2013


                        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       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Return Code  |Return sub-code|      Reserved         |F|C|O|I|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                      Figure 13TRILL OAM Message TLV

   Type (1 octet) = 64 indicate that this is the TRILL OAM Version

   Length (2 octets) = 6

   TRILL OAM Version (1 Octet), currently set to zero. Indicates the
   TRILL OAM version. TRILL OAM version can be different than the
   [8021Q] version.

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

   Return sub-code (1 Octet): Return sub-code is set to zero on
   transmission of request message. Return sub-code identifies
   categories within a specific Return code. Return sub-code MUST be
   interpreted within a Return code.

   Reserved: set to zero on transmission and ignored on reception.

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

   C (1 bit ): Label error (VLAN/Label mapping error), if set indicates
   that the label (VLAN/FGL) in the flow entropy is different than the
   label included in the diagnostic TLV.  This field is ignored in
   request messages and MUST only be interpreted in response messages.

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

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

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




Senevirathne          Expires November 28, 2013               [Page 30]


Internet-Draft          TRILL Fault Management                 May 2013


9.4.4. Out Of Band Reply Address TLV

   Out of Band Reply Address TLV specifies the address to which an out
   of band OAM reply message MUST be sent. When O bit in the TRILL
   Version TLV is not set, 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 14Out of Band IP Address TLV

   Type (1 octet) = 64

   Length (2 octets) = Variable. Minimum length is 2.

   Address Type (1 Octet): 0 - IPv4. 1 - IPv6. 2 - TRILL RBridge
   nickname. All other values reserved.

   Addr Length (1 Octet). 4 - IPv4. 16 - IPv6, 2 - TRILL RBRidge
   nickname.

   Reply Address (variable): Address where the reply needed to be sent.
   Length depends on the address specification.

9.4.5. Diagnostics Label TLV

   Diagnostic label 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. Label Error Flag in the response (TRILL OAM
   Message Version TLV) MUST be set when the two VLANs do not match.








Senevirathne          Expires November 28, 2013               [Page 31]


Internet-Draft          TRILL Fault Management                 May 2013



                        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(VLAN)             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                       Figure 15Diagnostic VLAN TLV

   Type (1 octet) = 65 indicates that this is the TRILL Diagnostic VLAN
   TLV

   Length (2 octets) = 5

   L-Type (Label type, 1 octet)

      0- indicate 802.1Q 12 bit VLAN.

      1 - indicate TRILL 24 bit fine grain label

   Label (24 bits): Either 12 bit VLAN or 24 bit fine grain label.

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

9.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 16Original Data Payload TLV



Senevirathne          Expires November 28, 2013               [Page 32]


Internet-Draft          TRILL Fault Management                 May 2013


   Length (2 octets) =  variable

9.4.7. RBridge scope TLV

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

   Each TLV can contain up to 255 nicknames of in scope RBridges. A
   Multicast 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 12. for details.

                        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 17RBridge Scope TLV

   Type (1 octet) = 67 indicates that this is the "RBridge scope TLV"

   Length (2 octets) = variable. Minimum value is 2.

   Nickname (2 octets) = 16 bit RBridge nickname.

9.4.8. Previous RBridge nickname TLV

   "Previous RBridge nickname TLV" identifies the nickname or nicknames
   of the upstream RBridge. [RFC6325] allows a given RBridge to hold
   multiple nicknames.





Senevirathne          Expires November 28, 2013               [Page 33]


Internet-Draft          TRILL Fault Management                 May 2013


    "Upstream 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                     |   nickname                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                  Figure 18Upstream RBridge nickname TLV

   Type (1 octet) = 69 indicates that this is the "Upstream RBridge
   nickname"

   Length (2 octets) = 4.

   Nickname (2 octets) = 16 bit RBridge nickname.

9.4.9. Next Hop RBridge List TLV

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

   "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 19Next Hop RBridge List TLV



Senevirathne          Expires November 28, 2013               [Page 34]


Internet-Draft          TRILL Fault Management                 May 2013


   Type (1 octet) = 70 indicates that this is the "Next nickname"

   Length (2 octets) = variable. Minimum value is 2.

   Nickname (2 octets) = 16 bit RBridge nickname.

9.4.10. Multicast Receiver Port count TLV

   "Multicast Receiver Port Count TLV" identifies the number of ports
   interested in receiving the specified multicast stream within the
   responding RBridge on the VLAN specified by the Diagnostic VLAN TLV.

   Multicast Receiver Port count 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 20Multicast Receiver Availability TLV

   Type (1 octet) = 71 indicates that this is the "Multicast
   Availability TLV"

   Length (2 octets) = 5.

   Number of Receivers (4 octets) = Indicates the number of Multicast
   receivers available on the responding RBridge on the VLAN specified
   by the diagnostic VLAN.

9.4.11. Flow Identifier (flow-id) TLV

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











Senevirathne          Expires November 28, 2013               [Page 35]


Internet-Draft          TRILL Fault Management                 May 2013


                        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-id                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                    Figure 21Out of Band IP Address TLV

   Type (1 octet) = 72

   Length (2 octets) = 5.

   Reserved (1 octet) set to 0 on transmission and ignored on reception.

   MEP-ID (2 octets) = MEP-ID of the originator [8021Q].

   Flow-id (2 octets) = uniquely identifies the flow per MEP. Different
   MEPs may allocate the same flow-id value. The {MEP-ID, flow-id} pair
   is globally unique.

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























Senevirathne          Expires November 28, 2013               [Page 36]


Internet-Draft          TRILL Fault Management                 May 2013


10. Loopback Message

  10.1. Loopback OAM 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 22Loopback OAM Message Format

   The above figure depicts the format of the Loopback Request and
   response messages as defined in [8021Q]. The Opcode for Loopback
   Message is set to 65 and the Opcode for the Reply Message is set to
   64. The Session Identification Number 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..

  10.2. Theory of Operation

10.2.1. Originator RBridge



   Identifies the destination RBridge nickname based on user
   specification or based on the specified destination MAC or IP
   address.

   Constructs the flow entropy based on user specified parameters or
   implementation specific default parameters.

   Constructs the TRILL OAM header: sets the opcode to Loopback message
   type (3). Assign applicable Loopback Transaction Identifier number
   for the request.

   The TRILL OAM Version TLV MUST be included and with the flags set to
   applicable values.


Senevirathne          Expires November 28, 2013               [Page 37]


Internet-Draft          TRILL Fault Management                 May 2013


   Include following OAM TLVs, where applicable

     o  Out-of-band Reply address TLV

     o  Diagnostic Label TLV

     o  Sender ID TLV

   Specify the Hop count of the TRILL data frame per user specification
   or utilize an applicable Hop count value.

   Dispatch the OAM frame for transmission.

   RBridge may continue to retransmit the request at periodic intervals,
   until a response is received or the re-transmission count expires. At
   each transmission Session Identification number MUST be incremented.

10.2.2. Intermediate RBridge

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

10.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 and 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:

   TRILL OAM application encodes the received TRILL header and flow
   entropy in the Original payload TLV and includes it in the OAM
   message.

   Set the Return Code and Return sub code to applicable values. Update
   the TRILL OAM opcode to 2 (Loopback Message Reply)

   Optionally, if the VLAN/FGL identifier value of the received flow
   entropy differs from the value specified in the diagnostic Label, set
   the Label Error Flag on TRILL OAM Application Identifier TLV.



Senevirathne          Expires November 28, 2013               [Page 38]


Internet-Draft          TRILL Fault Management                 May 2013


   Include the sender ID TLV (1)

   If in-band response was requested, dispatch the frame to the TRILL
   data plane with request-originator RBridge nickname as the egress
   RBridge nickname.

   If out-of-band response was requested, dispatch the frame to the IP
   forwarding process.

11. 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 for 802.1 both
   the unicast and multicast paths are congruent. However, TRILL is
   multicast and unicast incongruent. Hence,  TRILL OAM is required to
   utilize a new message format: the Path Trace message.

   The Path Trace Message has the same format as Loopback Message.
   Opcode for Path Trace Reply Message is 65 and Request 64

   Operation of the Path Trace message is identical to the Loopback
   message except that it is first transmitted with a TRILL Hop count
   field value of 1. The sending RBridge expects a Time Expiry Return-
   Code from the next hop or a successful response. If a Time Expiry
   Return-code is received as the response, the originator RBridge
   records the information received from intermediate node that
   generated the Time Expiry 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
   or Path Trace process timeout occur or Hop count reaches a configured
   maximum value.

  11.1. Theory of Operation

11.1.1. Originator RBridge

   Identify the destination RBridge based on user specification or based
   on location of the specified MAC address.




Senevirathne          Expires November 28, 2013               [Page 39]


Internet-Draft          TRILL Fault Management                 May 2013


   Construct the flow entropy based on user specified parameters or
   implementation specific default parameters.

   Construct the TRILL OAM header: Set the opcode to Path Trace Request
   message type (65). Assign an applicable Session Identification number
   for the request. Return-code and sub-code MUST be set to zero.

   The TRILL OAM Application Identifier TLV MUST be included and set the
   flags to applicable values.

   Include following OAM TLVs, where applicable

     o  Out-of-band IP address TLV

     o  Diagnostic Label TLV

     o  Include the Sender ID TLV

   Specify the Hop count of the TRILL data frame as 1 for the first
   request.

   Dispatch 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 re-transmission count
   expires. At each new re-transmission, the Session Identification
   number MUST be incremented. Additionally, for responses received from
   intermediate RBridges, the RBridge nickname and interface information
   MUST be recorded.



11.1.2. Intermediate RBridge

   Path Trace Messages transit through Intermediate RBridges
   transparently, unless Hop-count has expired.

   TRILL OAM application layer further validates the received OAM frame
   by examining the presence of TRILL OAM 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:





Senevirathne          Expires November 28, 2013               [Page 40]


Internet-Draft          TRILL Fault Management                 May 2013


   TRILL OAM application encodes the received TRILL header and flow
   entropy in the Original payload TLV and include it in the OAM
   message.

   Set the Return Code to (2) "Time Expired" and Return sub code to zero
   (0). Update the TRILL OAM opcode to 64 (Path Trace Message  Reply).

   If the VLAN/FGL identifier value of the received flow entropy differs
   from the value specified in the diagnostic Label, set the Label Error
   Flag on TRILL OAM Application Identifier TLV.



   Include following TLVs

   Upstream RBridge nickname TLV (69)

   Reply Ingress TLV (5)

   Reply Egress TLV (6)

   Interface Status TLV (4)

   TRILL Next Hop RBridge (Repeat for each ECMP) (70)

   Sender ID TLV (1)

   If Label error detected, set C flag (Label error detected) in the
   version.

   If in-band response was requested, dispatch the frame to the TRILL
   data plane with request-originator RBRidge nickname as the egress
   RBridge nickname.

   If out-of-band response was requested, dispatch the frame to the
   standard IP forwarding process.

11.1.3. Destination RBridge

   Processing is identical to section 11.1.2. With the exception that
   TRILL OAM Opcode is set to Path Trace Reply (64).

12. Multi-Destination Tree Verification (MTV) Message

   Multi-Destination Tree Verification messages allow verifying TRILL
   distribution tree integrity and pruning. TRILL VLAN/FGL and multicast
   pruning are described in [RFC6325] [RFCclcorrect] and [RFCfgl].


Senevirathne          Expires November 28, 2013               [Page 41]


Internet-Draft          TRILL Fault Management                 May 2013


   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 parameter 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,
   MTV 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
   request only to RBRidges that have failed to respond.

  12.1. Multi-Destination Tree Verification (MTV) OAM Message Format

   Format of MTV OAM Message format is identical to that of Loopback
   Message format defined in section 10. with the exception that the
   Loopback Transaction Identifier, in section 10.1. , is replaced with
   the Session Identifier.

  12.2. Theory of Operation

12.2.1. Originator RBridge

   The user is required at a minimum to specify either the distribution
   trees that need to be verified, or the Multicast MAC address and
   VLAN/FGL, or 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,
   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 needed 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


Senevirathne          Expires November 28, 2013               [Page 42]


Internet-Draft          TRILL Fault Management                 May 2013


   the Backwards Compatibility Method of section 3.2 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
   identifies the nickname that represents the multicast tree.

   Obtain the applicable Hop count value for the selected multicast
   tree.

   Construct TRILL OAM message header and include Session Identification
   number. Session Identification number facilitate the originator to
   map the response to the correct request.

   TRILL OAM Application Identifier TLV MUST be included.

   Op-Code MUST be specified as Multicast Tree Verification Message (70)

   Include RBridge scope TLV (67)

   Optionally, include following TLV, where applicable

     o  Out-of-band IP address

     o  Diagnostic Label

     o  Sender ID TLV (1)

   Specify the Hop count of the TRILL data frame per user specification
   or alternatively utilize the applicable Hop count value if TRILL Hop
   count is not being specified by the user.

   Dispatch 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 re-transmission
   count expires. At each new re-transmission, the Session
   Identification number MUST be incremented. At each re-transmission,
   the RBridge may further reduce the scope to the RBridges that it has
   not received a response from.





Senevirathne          Expires November 28, 2013               [Page 43]


Internet-Draft          TRILL Fault Management                 May 2013


12.2.2. Receiving RBridge

   Receiving RBridges identify multicast verification frames per the
   procedure explained in sections 3.2.

   CPU of 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
   RBridge scope TLV is absent, the receiving RBridge proceeds with
   further processing as defined in section 12.2.3.

12.2.3.  In scope RBridges

   Construction of the TRILL OAM response:

   TRILL OAM application encodes the received TRILL header and flow
   entropy in the Original payload TLV and includes them in the OAM
   message.

   Set the Return Code to (0) and Return sub code to zero (0). Update
   the TRILL OAM opcode to 66 (Multicast Tree Verification Reply).

   Include following TLVs:

   Upstream RBridge nickname TLV (69)

   Reply Ingress TLV (5)

   Interface Status TLV (4)

   TRILL Next Hop RBridge (Repeat for each downstream RBridge) (70)

   Sender ID TLV (1)

   Multicast Receiver Availability TLV (71)

   If VLAN cross connect error detected, set C flag (Cross connect error
   detected) in the version.

   If in-band response was requested, dispatch the frame to the TRILL
   data plane with request-originator RBridge nickname as the egress
   RBridge nickname.

   If out-of-band response was requested, dispatch the frame to the
   standard IP forwarding process.



Senevirathne          Expires November 28, 2013               [Page 44]


Internet-Draft          TRILL Fault Management                 May 2013


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

   Section 8. provides an overview of CCM Messages defined in [8021Q]
   and how they can be used within the 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 an MEP.

   It is important that the proposed solution accomplishes the
   requirements specified in [RFC6905] within the framework of [8021Q]
   in a straightforward manner and with minimum changes. Section 8,
   above proposed to define multiple flows within the CCM object, each
   corresponding to a flow that a given MEP wishes to monitor.

   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?

  13.1. CCM Error Notification

   This is accomplished with a combination of the RDI flag in the CCM
   header, flow-id TLV, and SNMP Notifications (Traps).

   Each MEP transmits 4 CCM messages per each flow. ([8021Q] detects CCM
   fault when 3 consecutive CCM messages are lost). Each CCM Message has
   a unique sequence number and unique flow-identifier. The flow
   identifier is included in the OAM message via flow-id TLV.

   When an 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 SNMP notification that contain the remote MEP
   Identification, flow-id and the Sequence Number of the last CCM


Senevirathne          Expires November 28, 2013               [Page 45]


Internet-Draft          TRILL Fault Management                 May 2013


   message it received and if available, the flow-id and the Sequence
   Number of the first CCM message it received after the failure. Each
   MEP maintains a unique flow-id per each flow, hence the operator can
   easily identify flows that correspond to the specific flow-id.

   The following example illustrates the above.

   Assume there are two MEPs, MEP-A and MEP-B.

   Assume there are 3 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-id=(1)

   Flow-2 Sequence={5,6,7,8,17,18,19,20,.. } flow-id=(2)

   Flow-3 Sequence={9,10,12,11,21,22,23,24,.. } flow-id=(3)

   Let's Assume Flow-2 is at fault.

   MEP-B, receives CCM from MEP-A with sequence numbers 1,2,3,4, but did
   not receive 5,6,7,8. CCM timeout is set to 3 CCM intervals in
   [8021Q]. Hence MEP-B detects the error at the 8'th CCM message. At
   this time the sequence number of the last good CCM message MEP-B has
   received from MEP-A is 4 and flow-id of the last good CCM Message is
   (1). Hence MEP-B will generate a CCM error SNMP notification with
   MEP-A and Last good flow-id (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 CCM
   message with Sequence Numbers 9,10,11,12,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 and the first valid flow-id and the
   Sequence number after the CCM timeout. In the foregoing example, it
   is MEP-A, flow-id (1) and Sequence Number 9.

   The remote MEP list under the CCM MIB Object is augmented to contain
   "Last Sequence Number", flow-id and "CCM Timeout" variables. Last
   Sequence Number and flow-id are updated every time a CCM is received
   from a remote MEP. CCM Timeout variable is set when the CCM timeout
   occurs and is cleared when a CCM is received.






Senevirathne          Expires November 28, 2013               [Page 46]


Internet-Draft          TRILL Fault Management                 May 2013


13.2. Theory of Operation

13.2.1. Originator RBridge

   Derive the flow entropy based on flow entropy specified in the CCM
   Management object.

   Construct the TRILL CCM OAM header as specified in [8021Q].

   TRILL OAM Version TLV MUST be included as the first TLV and set the
   flags to applicable values.

   Include other TLVs specified in [8021Q]

   Include the following optional TRILL OAM TLVs, where applicable

     o  Sender ID TLV

   Specify the Hop count of the TRILL data frame per user specification
   or utilize an applicable Hop count value.

   Dispatch the OAM frame to the TRILL data plane for transmission.

   An RBridge transmits a total of 4 requests, each at CCM
   retransmission interval. At each transmission the Session
   Identification number MUST be incremented by one.

   At the 5'th retransmission interval, flow entropy of the CCM packet
   is updated to the next flow entropy specified in the CCM Management
   Object. If current flow entropy is the last flow entropy specified,
   move to the first flow entropy specified and continue the process.

13.2.2. Intermediate RBridge

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

13.2.3. Destination RBridge

   If the CCM Message is addressed to the local RBridge or multicast and
   satisfies OAM identification methods specified in sections 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



Senevirathne          Expires November 28, 2013               [Page 47]


Internet-Draft          TRILL Fault Management                 May 2013


   flow entropy. Frames that do not contain OAM-Ethertype at the end of
   the flow entropy MUST be discarded.

   Validate the MD-LEVEL and pass the packet to the Opcode de-
   multiplexer. The Opcode de-multiplexer delivers CCM packets to the
   CCM process.

   The CCM Process performs 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.



14. Fragmented Reply

   The response Message allow Fragmented Replies.. In case of Fragmented
   Replies, all messages MUST follow the procedure defined in this
   section.

   All Reply Messages MUST be encoded as described in this document.

   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
   appropriate Final Flag field. The Final Flag, MUST, only be set on
   the final fragment of the reply.

15. Security Considerations

   For general TRILL related security considerations, please refer to
   [RFC6325]. Specific security considerations related methods presented
   in this document are currently under investigation.

16. IEEE Allocation Considerations

   The IEEE 802.1 Working Group is requested to allocate a separate
   opcode and TLV space within 802.1QCFM messages for TRILL purpose.




Senevirathne          Expires November 28, 2013               [Page 48]


Internet-Draft          TRILL Fault Management                 May 2013


17. IANA Considerations

   - IANA is requested to allocate a multicast MAC address from the
   block assigned to TRILL [RFC6325].

   - Set up sub-registry within the TRILL Parameters registry for block
   of TRILL "OAM OpCodes" (Section 9.2. )-

   - Set up sub-registry within the TRILL Parameters registry for TRILL
   "OAM TLV Types" (Section 9.4. )-

   - Request a unicast MAC addressed, reserved for identification of
   OAM packets discussed in backward compatibility method (Section 3.3.
   ) See Appendix A.





18. References

  18.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6325] Perlman, R., et.al., "Routing Bridges (RBridges): Base
             Protocol Specification", RFC 6325, July 2011.

   [RFCfgl] D. Eastlake, M. Zhang, P. Agarwal, R. Perlman, D. Dutt,
             "TRILL: Fine-Grained Labeling", draft-ietf-trill-fine-
             labeling, work in progress.

   [8021Q] IEEE, "Media Access Control (MAC) Bridges and Virtual Bridged
             Local Area Networks", IEEE Std 802.1Q-2011, August, 2011.



  18.2. Informative References

    [RFC4379] Kompella, K. et.al, "Detecting Multi-Protocol Label
             Switched (MPLS) Data Plane Failures", RFC 4379, February
             2006.

   [RFC6291] Andersson, L., et.al., "Guidelines f<or the use of the
             "OAM" Acronym in the IETF" RFC 6291, June 2011.



Senevirathne          Expires November 28, 2013               [Page 49]


Internet-Draft          TRILL Fault Management                 May 2013


   [RFC6361] Carlson, J. and Eastlake, D. "PPP Transparent
             Interconnection of Lots of Links (TRILL) Protocol Control
             Protocol", RFC 6361, August 201.

   [RFC6905] Senevirathne, T. et.al"Requirements for Operations,
             Administration, and Maintenance (OAM) in Transparent
             Interconnection of Lots of Links (TRILL)", RFC 6905, March
             2013.

   [TRLOAMFRM] Salam, S., et.al., "TRILL OAM Framework", draft-ietf-
             trill-oam-framework, Work in Progress, November, 2012.



   [RFCclcorrect] Eastlake, Donald, et.al. "TRILL: Clarifications,
             Corrections, and Updates, draft-ietf-trill-clear-correct,
             July 2012.

   [TRILLEXT] Eastlake, Donald, et.al. "TRILL: Header Extension", draft-
             ietf-trill-rbridge-extension, June, 2012.

   [Y1731] ITU, "OAM functions and mechanisms for Ethernet based
             networks", ITU-T G.8013/Y.1731, July, 2011.

   [Channel] D. Eastlake, et.al. , "TRILL: RBridge Channel Support",
             draft-ietf-trill-rbridge-channel-08.txt, in RFC Edtior's
             queue.

   [TRILLOAMMIB] Deepak Kumar et.al, "TRILL OAM MIB", draft-deepak-
             trill-oam-mib, May 2013.



19. Acknowledgments

   Work in 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, Dan Romascanu and Gayle Nobel.

   This document was prepared using 2-Word-v2.0.template.dot.







Senevirathne          Expires November 28, 2013               [Page 50]


Internet-Draft          TRILL Fault Management                 May 2013


Appendix A.                 Unicast MAC Request

      Applicant Name: IETF TRILL Working Group

      Applicant Email:  tsenevir@cisco.com

      Applicant Telephone: 408-853-2291

      Use Name: TRILL OAM

      Document: draft-tissa-trill-oam-fm

      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: Unicast






























Senevirathne          Expires November 28, 2013               [Page 51]


Internet-Draft          TRILL Fault Management                 May 2013


Authors' Addresses


   Tissa Senevirathne
   CISCO Systems
   375 East Tasman Drive.
   San Jose, CA 95134
   USA.

   Phone: +1 408-853-2291
   Email: tsenevir@cisco.com

   Norman Finn
   CISCO Systems
   510 McCarthy Blvd
   Milpitas, CA 95035
   USA


   Email: nfinn@cisco.com


   Samer Salam
   CISCO Systems
   595 Burrard St. Suite 2123
   Vancouver, BC V7X 1J1, Canada


   Email: ssalam@cisco.com

   Deepak Kumar
   CISCO Systems
   510 McCarthy Blvd,
   Milpitas, CA 95035, USA

   Phone : +1 408-853-9760
   Email: dekumar@cisco.com

   Donald Eastlake
   Huawei Technologies
   155 Beaver Street
   Milford, MA 01757

   Phone: +1-508-333-2270
   Email: d3e3e3@gmail.com




Senevirathne          Expires November 28, 2013               [Page 52]


Internet-Draft          TRILL Fault Management                 May 2013


   Sam Aldrin
   Huawei Technologies
   2330 Central Express Way
   Santa Clara, CA 95951
   USA

   Email: aldrin.ietf@gmail.com

   Yizhou Li
   Huawei Technologies
   101 Software Avenue,
   Nanjing 210012
   China

   Phone: +86-25-56625375
   Email: liyizhou@huawei.com

































Senevirathne          Expires November 28, 2013               [Page 53]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/