tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7455

Proposed STD
Pages: 63
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: TRILL

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

Part 1 of 3, p. 1 to 10
None       Next RFC Part

Updates:    6325


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                   T. Senevirathne
Request for Comments: 7455                                       N. Finn
Updates: 6325                                                   S. Salam
Category: Standards Track                                       D. Kumar
ISSN: 2070-1721                                                    Cisco
                                                         D. Eastlake 3rd
                                                               S. Aldrin
                                                                   Y. Li
                                                                  Huawei
                                                              March 2015


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

Abstract

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

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7455.

Page 2 
Copyright Notice

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

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

Top       Page 3 
Table of Contents

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

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

Top      ToC       Page 5 
1.  Introduction

   The general structure of TRILL OAM messages is presented in
   [RFC7174].  TRILL OAM messages consist of six parts: Link Header,
   TRILL Header, Flow Entropy, OAM Ethertype, OAM Message Channel, and
   Link Trailer.

   The OAM Message Channel carries various control information and OAM-
   related data between TRILL switches, also known as RBridges or
   Routing Bridges.

   A common OAM Message Channel representation can be shared between
   different technologies.  This consistency between different OAM
   technologies promotes nested fault monitoring and isolation between
   technologies that share the same OAM framework.

   The TRILL OAM Message Channel is formatted as specified in IEEE
   Connectivity Fault Management (CFM) [8021Q].

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

   This document specifies TRILL OAM fault management.  It updates
   [RFC6325] as specified in Section 3.1.  TRILL performance monitoring
   is specified in [RFC7456].

2.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   Capitalized IANA Considerations terms such as "Standards Action" are
   to be interpreted as described in [RFC5226].

   Acronyms used in the document include the following:

      CCM   - Continuity Check Message [8021Q]

      DA    - Destination Address

      ECMP  - Equal-Cost Multipath

      FGL   - Fine-Grained Label

Top      ToC       Page 6 
      ISS   - Internal Sub-Layer Service [8021Q]

      LBM   - Loopback Message [8021Q]

      LBR   - Loopback Reply [8021Q]

      MA    - Maintenance Association [8021Q] [RFC7174]

      MAC   - Media Access Control (MAC)

      MD    - Maintenance Domain [8021Q]

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

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

      MP    - Maintenance Point [RFC7174]

      MTVM  - Multi-destination Tree Verification Message

      MTVR  - Multi-destination Tree Verification Reply

      OAM   - Operations, Administration, and Maintenance [RFC6291]

      PRI   - Priority of Ethernet Frames [8021Q]

      PTM   - Path Trace Message

      PTR   - Path Trace Reply

      SA    - Source Address

      SAP   - Service Access Point [8021Q]

      TRILL - Transparent Interconnection of Lots of Links [RFC6325]

3.  General Format of TRILL OAM Packets

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

Top      ToC       Page 7 
   For accurate monitoring and/or diagnostics, OAM messages are required
   to follow the same path as corresponding data packets.  [RFC7174]
   presents the high-level format of OAM messages.  The details of the
   TRILL OAM frame format are defined in this document.

         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                               |
         .    Link  Header               . Variable
         |                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                               |
         +    TRILL Header               + 6 or more bytes
         |                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                               |
         .   Flow Entropy                . 96 bytes
         .                               .
         |                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |   OAM Ethertype               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                               |
         .   OAM Message Channel         . Variable
         .                               .
         |                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |     Link Trailer              | Variable
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 1: Format of TRILL OAM Messages

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

   o  TRILL Header: Fixed size of 6 bytes when the Extended Header is
      not included [RFC6325].

   o  Flow Entropy: A 96-byte, fixed-size field.  The rightmost bits of
      the field MUST be padded with zeros, up to 96 bytes, when the
      flow-entropy information is less than 96 bytes.  Flow Entropy
      enables emulation of the forwarding behavior of the desired data
      packets.  The Flow Entropy field starts with the Inner.MacDA.  The
      offset of the Inner.MacDA depends on whether extensions are
      included or not as specified in [RFC7179] and [RFC6325].  Such
      extensions are not commonly supported in current TRILL
      implementations.

Top      ToC       Page 8 
   o  OAM Ethertype: A 16-bit Ethertype that identifies the OAM Message
      Channel that follows.  This document specifies using the Ethertype
      0x8902 allocated for CFM [8021Q].

   o  OAM Message Channel: A variable-size section that carries OAM-
      related information.  The message format is as specified in
      [8021Q].

   o  Link Trailer: Media-dependent trailer.  For Ethernet, this is the
      FCS (Frame Check Sequence).

3.1.  Identification of TRILL OAM Frames

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

3.2.  Use of TRILL OAM Alert Flag

   The TRILL Header, as defined in [RFC6325], has two reserved bits.
   This document specifies use of the reserved bit next to the Version
   field in the TRILL Header as the Alert flag.  The Alert flag will be
   denoted by "A".  RBridges MUST NOT use the "A" flag for forwarding
   decisions such as the selection of which ECMP path or multi-
   destination tree to select.

   Implementations that comply with this document MUST utilize the "A"
   flag and CFM Ethertype to identify TRILL OAM frames.

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

                 Figure 2: TRILL Header with the "A" Flag

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

   All other TRILL Header fields carry the same meaning as defined in
   [RFC6325].

Top      ToC       Page 9 
3.2.1.  Handling of TRILL Frames with the "A" Flag

   The value "1" in the "A" flag indicates TRILL frames that may qualify
   as OAM frames.  Implementations are further REQUIRED to validate such
   frames by comparing the value at the OAM Ethertype (Figure 1)
   location with the CFM Ethertype "0x8902" [8021Q].  If the value
   matches, such frames are identified as TRILL OAM frames and SHOULD be
   processed as discussed in Section 4.

   Frames with the "A" flag set that do not contain a CFM Ethertype are
   not considered OAM frames.  Such frames MUST be silently discarded.

   OAM-capable RBridges MUST NOT generate OAM frames to an RBridge that
   is not OAM capable.

   Intermediate RBridges that are not OAM capable (i.e., do not
   understand the "A" flag) follow the process defined in Section 3.3 of
   [RFC6325] and forward OAM frames with the "A" flag unaltered.

3.3.  OAM Capability Announcement

   Any given RBridge can be (1) OAM incapable, (2) OAM capable with new
   extensions, or (3) OAM capable with the backwards-compatibility
   method.  The OAM request originator, prior to origination of the
   request, is required to identify the OAM capability of the target and
   generate the appropriate OAM message.

   The capability flags defined in the TRILL Version sub-TLV (TRILL-VER)
   [RFC7176] will be utilized for announcing OAM capabilities.  The
   following OAM-related capability flags are defined:

      O - OAM capable

      B - Backwards-compatible OAM

   A capability announcement with the "O" flag set to 1 and the "B" flag
   set to 1 indicates that the originating RBridge is OAM capable but
   utilizes the backwards-compatibility method defined in Appendix A.  A
   capability announcement with the "O" flag set to 1 and the "B" flag
   set to 0 indicates that the originating RBridge is OAM capable and
   utilizes the method specified in Section 3.2.

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

Top      ToC       Page 10 
      +-+-+-+-+-+-+-+-+
      | Type          |              (1 byte)
      +-+-+-+-+-+-+-+-+
      | Length        |              (1 byte)
      +-+-+-+-+-+-+-+-+
      | Max-version   |              (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
      |A|F|O|B|Other Capabilities and Header Flags|  (4 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+
       0                   1                 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7   0 1

    Figure 3: TRILL-VER Sub-TLV [RFC7176] with "O" and "B" Flags

   In Figure 3, "A" is the Affinity sub-TLV support flag as indicated in
   [RFC7176], and "F" is the FGL-safe flag as indicated in [RFC7172] and
   [RFC7176].  The "O" and "B" flags are located after the "F" flag in
   the Capability and Header Flags field of the TRILL-VER sub-TLV, as
   depicted in Figure 3 above.  Usage of the "O" and "B" flags is
   discussed above.

   Absence of the TRILL-VER sub-TLV means the announcing RBridge is not
   OAM capable.

3.4.  Identification of the OAM Message

   The ingress RBridge nickname allows recipients to identify the origin
   of the message in most cases.  However, when an out-of-band reply is
   generated, the responding RBridge nickname is not easy to identify.

   The [8021Q] Sender ID TLV (1) provides methods to identify the device
   by including the Chassis ID.  The Chassis ID allows different
   addressing formats such as IANA Address Family enumerations.  IANA
   has allocated Address Family Number 16396 for TRILL nickname.  In
   TRILL OAM, the Chassis ID sub-type of the Sender ID TLV is set to
   16396, and the Chassis ID field contains the corresponding TRILL
   nickname.

   When the Sender ID TLV is present and the Chassis ID sub-type is set
   to 16396, the sender RBridge TRILL nickname SHOULD be derived from
   the nickname embedded in the Chassis ID.  Otherwise, the sender
   RBridge TRILL nickname SHOULD be derived from the ingress RBridge
   nickname.


Next RFC Part