RFC 7455
Transparent Interconnection of Lots of Links (TRILL): Fault Management
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 ManagementAbstract
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.
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.
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
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
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
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.
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.
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].
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.
+-+-+-+-+-+-+-+-+ | 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 page on part 2)
