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 3rdS. AldrinY. Li
March 2015 Transparent Interconnection of Lots of Links (TRILL): Fault Management
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
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.
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
The OAM Message Channel carries various control information and OAM-
related data between TRILL switches, also known as RBridges or
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
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
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
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 |
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
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
Absence of the TRILL-VER sub-TLV means the announcing RBridge is not
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
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