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
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
大量链路的透明互连（TRILL）：故障管理
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.
本文件规定了大量链路的透明互连（TRILL）操作、管理和维护（OAM）故障管理。本文档中的方法遵循IEEE 802.1中定义的CFM（连接故障管理）框架，并在可能的情况下重用OAM工具。额外的消息和TLV是为TRILL特定的应用程序定义的，或者在需要一组不同于IEEE 802.1中定义的CFM的信息的情况下定义的。本文档更新了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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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
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
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.
TRILL OAM消息的一般结构如[RFC7174]所示。TRILL OAM消息由六部分组成：链接头、TRILL头、流熵、OAM以太类型、OAM消息通道和链接尾。
The OAM Message Channel carries various control information and OAM-related data between TRILL switches, also known as RBridges or Routing Bridges.
OAM消息通道在TRILL交换机（也称为RBridge或路由桥）之间承载各种控制信息和OAM相关数据。
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.
可以在不同的技术之间共享通用的OAM消息通道表示。不同OAM技术之间的这种一致性促进了共享同一OAM框架的技术之间的嵌套故障监视和隔离。
The TRILL OAM Message Channel is formatted as specified in IEEE Connectivity Fault Management (CFM) [8021Q].
TRILL OAM消息通道按照IEEE连接故障管理（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.
ITU-T Y.1731[Y1731]标准在适用的情况下使用与[8021Q]OAM消息相同的消息格式。本文档采取了类似的立场，并在TRILL OAM中重用了[8021Q]。假设读者熟悉[8021Q]和[Y1731]。鼓励不熟悉这些文件的读者阅读。
This document specifies TRILL OAM fault management. It updates [RFC6325] as specified in Section 3.1. TRILL performance monitoring is specified in [RFC7456].
本文档规定了TRILL OAM故障管理。按照第3.1节的规定更新[RFC6325]。[RFC7456]中规定了颤音性能监控。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Capitalized IANA Considerations terms such as "Standards Action" are to be interpreted as described in [RFC5226].
大写的IANA注意事项术语，如“标准行动”应按照[RFC5226]中所述进行解释。
Acronyms used in the document include the following:
本文件中使用的首字母缩略词包括：
CCM - Continuity Check Message [8021Q]
CCM-连续性检查消息[8021Q]
DA - Destination Address
DA-目的地址
ECMP - Equal-Cost Multipath
ECMP-等成本多路径
FGL - Fine-Grained Label
FGL-细粒度标签
ISS - Internal Sub-Layer Service [8021Q]
ISS-内部子层服务[8021Q]
LBM - Loopback Message [8021Q]
LBM-环回消息[8021Q]
LBR - Loopback Reply [8021Q]
LBR-环回回复[8021Q]
MA - Maintenance Association [8021Q] [RFC7174]
MA-维修协会[8021Q][RFC7174]
MAC - Media Access Control (MAC)
MAC-媒体访问控制（MAC）
MD - Maintenance Domain [8021Q]
MD-维护域[8021Q]
MEP - Maintenance End Point [RFC7174] [8021Q]
MEP-维修终点[RFC7174][8021Q]
MIP - Maintenance Intermediate Point [RFC7174] [8021Q]
MIP-维修中间点[RFC7174][8021Q]
MP - Maintenance Point [RFC7174]
MP-维修点[RFC7174]
MTVM - Multi-destination Tree Verification Message
MTVM-多目标树验证消息
MTVR - Multi-destination Tree Verification Reply
MTVR-多目标树验证回复
OAM - Operations, Administration, and Maintenance [RFC6291]
OAM-运营、管理和维护[RFC6291]
PRI - Priority of Ethernet Frames [8021Q]
PRI-以太网帧的优先级[8021Q]
PTM - Path Trace Message
路径跟踪消息
PTR - Path Trace Reply
路径跟踪应答
SA - Source Address
SA-源地址
SAP - Service Access Point [8021Q]
SAP-服务接入点[8021Q]
TRILL - Transparent Interconnection of Lots of Links [RFC6325]
TRILL-大量链路的透明互连[RFC6325]
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.
TRILL转发范例允许实现从一组等成本路径中选择路径来转发单播TRILL数据分组。对于多目的地TRILL数据包，由进入或创建数据包的TRILL交换机选择分发树。对于单播，路径选择取决于每个跃点的实现，对于多目的地，路径选择取决于入口的实现。然而，通常的做法是利用帧有效载荷中的第2层到第4层信息进行路径选择。
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.
为了进行准确的监视和/或诊断，OAM消息需要遵循与相应数据包相同的路径。[RFC7174]显示OAM消息的高级格式。TRILL OAM帧格式的详细信息在本文档中定义。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Link Header . Variable
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ TRILL Header + 6 or more bytes
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Flow Entropy . 96 bytes
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Ethertype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. OAM Message Channel . Variable
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Trailer | Variable
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. 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
图1:TRILL OAM消息的格式
o Link Header: Media-dependent header. For Ethernet, this includes the Destination MAC, Source MAC, VLAN (optional), and Ethertype fields.
o 链接头：媒体相关头。对于以太网，这包括目标MAC、源MAC、VLAN（可选）和以太网类型字段。
o TRILL Header: Fixed size of 6 bytes when the Extended Header is not included [RFC6325].
o TRILL标头：不包括扩展标头时，固定大小为6字节[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 流熵：一个96字节的固定大小字段。当流熵信息小于96字节时，字段最右边的位必须用零填充，最多96字节。流熵可以模拟所需数据包的转发行为。流熵场从内部.MacDA开始。INTERNAR.MacDA的偏移量取决于是否包含[RFC7179]和[RFC6325]中指定的扩展。当前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 Ethertype：一个16位的Ethertype，用于标识随后的OAM消息通道。本文档指定使用分配给CFM[8021Q]的Ethertype 0x8902。
o OAM Message Channel: A variable-size section that carries OAM-related information. The message format is as specified in [8021Q].
o OAM消息通道：承载OAM相关信息的可变大小部分。消息格式如[8021Q]所述。
o Link Trailer: Media-dependent trailer. For Ethernet, this is the FCS (Frame Check Sequence).
o 链接预告片：媒体相关预告片。对于以太网，这是FCS（帧检查序列）。
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.
TRILL最初在[RFC6325]中指定，没有用于标识OAM帧的特定标志或方法。本文档更新了[RFC6325]，包括识别TRILL OAM帧的具体方法。第3.2节解释了该方法的细节。
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.
[RFC6325]中定义的TRILL报头有两个保留位。本文档指定使用颤音标题中版本字段旁边的保留位作为警报标志。警报标志将用“A”表示。RBridges不得将“A”标志用于转发决策，例如选择哪个ECMP路径或多目标树。
Implementations that comply with this document MUST utilize the "A" flag and CFM Ethertype to identify TRILL OAM frames.
符合本文档要求的实现必须使用“A”标志和CFM Ethertype来识别TRILL OAM帧。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |A|R|M|Op-Length| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress RBridge Nickname | Ingress RBridge Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options...
+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |A|R|M|Op-Length| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress RBridge Nickname | Ingress RBridge Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 2: TRILL Header with the "A" Flag
图2：带有“A”标志的颤音标题
o A (1 bit): Indicates this is a possible OAM frame and is subject to specific handling as specified in this document.
o A（1位）：表示这是一个可能的OAM帧，需要按照本文档中的规定进行特定处理。
All other TRILL Header fields carry the same meaning as defined in [RFC6325].
所有其他颤音标题字段的含义与[RFC6325]中的定义相同。
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.
“A”标志中的值“1”表示符合OAM帧条件的颤音帧。通过将OAM Ethertype（图1）位置的值与CFM Ethertype“0x8902”[8021Q]进行比较，还需要实现来验证这些帧。如果值匹配，则此类帧被标识为TRILL OAM帧，并应按照第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.
设置了“A”标志且不包含CFM Ethertype的帧不被视为OAM帧。这样的帧必须悄悄地丢弃。
OAM-capable RBridges MUST NOT generate OAM frames to an RBridge that is not OAM capable.
支持OAM的RBridge不能向不支持OAM的RBridge生成OAM帧。
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.
不支持OAM的中间RBridge（即，不理解“A”标志）遵循[RFC6325]第3.3节中定义的过程，并在“A”标志不变的情况下转发OAM帧。
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.
任何给定的RBridge都可以（1）不支持OAM，（2）支持使用新扩展的OAM，或（3）支持使用向后兼容方法的OAM。在发起请求之前，OAM请求发起人需要识别目标的OAM能力并生成适当的OAM消息。
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:
TRILL版本子TLV（TRILL-VER）[RFC7176]中定义的功能标志将用于宣布OAM功能。定义了以下与OAM相关的功能标志：
O - OAM capable
O-OAM功能
B - Backwards-compatible OAM
B-向后兼容的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.
“O”标志设置为1，“B”标志设置为1的能力公告表示发起RBridge支持OAM，但使用附录A中定义的向后兼容方法。将“O”标志设置为1和“B”的能力公告设置为0的标志表示发起RBridge支持OAM，并使用第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.
当“O”标志设置为0时，宣布实现被认为不能进行OAM，而忽略“B”标志。
+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+
| 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
图3：带“O”和“B”标志的颤音版本子TLV[RFC7176]
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.
在图3中，“A”是[RFC7176]中所示的亲和子TLV支持标志，“F”是[RFC7172]和[RFC7176]中所示的FGL安全标志。“O”和“B”标志位于TRILL-VER子TLV的能力和标题标志字段中的“F”标志之后，如上图3所示。上面讨论了“O”和“B”标志的用法。
Absence of the TRILL-VER sub-TLV means the announcing RBridge is not OAM capable.
缺少TRILL-VER子TLV意味着RBridge不支持OAM。
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.
在大多数情况下，ingress RBridge昵称允许收件人识别邮件的来源。然而，当生成带外应答时，响应的RBridge昵称不容易识别。
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.
[8021Q]发送方ID TLV（1）提供了通过包括机箱ID来识别设备的方法。机箱ID允许不同的寻址格式，如IANA地址族枚举。IANA已为TRILL昵称分配了地址系列号16396。在TRILL OAM中，发送方ID TLV的机箱ID子类型设置为16396，机箱ID字段包含相应的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 nickname.
当存在发送方ID TLV且机箱ID子类型设置为16396时，发送方RBridge TRILL昵称应源自机箱ID中嵌入的昵称。否则，发送方RBridge TRILL昵称应源自ingress RBridge昵称。
This section presents the placement of the TRILL OAM shim within the IEEE 802.1 layers. The transmit and receive processing are explained.
本节介绍TRILL OAM垫片在IEEE 802.1层中的位置。说明了发送和接收处理。
+-+-+-+-+-+-+-+-+-+-+
| RBridge Layer |
| Processing |
+-+-+-+-+-+-+-+-+-+-+
|
|
+-+-+-+-+-+-+
| TRILL OAM | UP MEP
| Layer | MIP
+-+-+-+-+-+-+ Down MEP
|
|
+-+-+-+-+-+-+
(3)--------> | TRILL |
| Encap/Decap
+-+-+-+-+-+-+
|
+-+-+-+-+-+-+
(2)--------> |End-station|
| VLAN & Priority Processing
+-+-+-+-+-+-+
|
+-+-+-+-+-+-+
(1)--------> |ISS |
|Processing |
+-+-+-+-+-+-+
|
|
|
+-+-+-+-+-+-+-+-+-+-+
| RBridge Layer |
| Processing |
+-+-+-+-+-+-+-+-+-+-+
|
|
+-+-+-+-+-+-+
| TRILL OAM | UP MEP
| Layer | MIP
+-+-+-+-+-+-+ Down MEP
|
|
+-+-+-+-+-+-+
(3)--------> | TRILL |
| Encap/Decap
+-+-+-+-+-+-+
|
+-+-+-+-+-+-+
(2)--------> |End-station|
| VLAN & Priority Processing
+-+-+-+-+-+-+
|
+-+-+-+-+-+-+
(1)--------> |ISS |
|Processing |
+-+-+-+-+-+-+
|
|
|
Figure 4: Placement of TRILL MP within IEEE 802.1
图4:IEEE 802.1中TRILL MP的位置
[RFC6325], Section 4.6 as updated by [RFC7180] provides a detailed explanation of frame processing. Please refer to those documents for additional details and for processing scenarios not covered herein.
[RFC6325]，由[RFC7180]更新的第4.6节提供了帧处理的详细说明。请参考这些文件以了解更多详细信息和本文未涵盖的处理场景。
Sections 4.1 and 4.2 apply to links using a broadcast LAN technology such as Ethernet.
第4.1节和第4.2节适用于使用广播LAN技术（如以太网）的链路。
On links using an inherently point-to-point technology, such as PPP [RFC6361], there is no Outer.MacDA, Outer.MacSA, or Outer.VLAN because these are part of the Link Header for Ethernet. Point-to-point links typically have Link Headers without these fields.
在使用固有点到点技术的链路上，如PPP[RFC6361]，没有Outer.MacDA、Outer.MacSA或Outer.VLAN，因为它们是以太网链路头的一部分。点到点链接通常具有不带这些字段的链接头。
The ISS layer receives an indication from the port. It extracts DA and SA, and it marks the remainder of the payload as M1. The ISS layer passes on (DA, SA, M1) as an indication to the higher layer.
ISS层接收来自端口的指示。它提取DA和SA，并将有效负载的剩余部分标记为M1。ISS层将（DA、SA、M1）作为指示传递给更高层。
For TRILL Ethernet frames, this is Outer.MacDA and Outer.MacSA. M1 is the remainder of the packet.
对于TRILL以太网帧，这是Outer.MacDA和Outer.MacSA。M1是数据包的剩余部分。
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.
ISS层从包含（DA、SA、M1）的较高层接收指示。它构造一个以太网帧并向下传递到端口。
Receive (DA, SA, M1) indication from the ISS layer. Extract the VLAN ID and priority from the M1 part of the received indication (or derive them from the port defaults or other default parameters) and construct (DA, SA, VLAN, PRI, M2). VLAN+PRI+M2 maps to M1 in the received indication. Pass (DA, SA, VLAN, PRI, M2) to the TRILL Encapsulation/Decapsulation layer.
从ISS层接收（DA、SA、M1）指示。从接收到的指示的M1部分提取VLAN ID和优先级（或从端口默认值或其他默认参数派生它们）并构造（DA、SA、VLAN、PRI、M2）。VLAN+PRI+M2映射到接收指示中的M1。将（DA、SA、VLAN、PRI、M2）传递到TRILL封装/去封装层。
Receive (DA, SA, VLAN, PRI, M2) indication from the TRILL Encapsulation/Decapsulation layer. Merge VLAN, PRI, M2 to form M1. Pass down (DA, SA, M1) to the ISS layer.
从TRILL封装/去封装层接收（DA、SA、VLAN、PRI、M2）指示。合并VLAN、PRI、M2形成M1。向下传递（DA、SA、M1）至ISS层。
o Receive indication (DA, SA, VLAN, PRI, M2) from the End-Station VLAN and Priority Processing layer.
o 从终端站VLAN和优先级处理层接收指示（DA、SA、VLAN、PRI、M2）。
o If the DA matches the port Local DA and the frame is of TRILL Ethertype:
o 如果DA与端口本地DA匹配且帧为TRILL Ethertype：
- Discard DA, SA, VLAN, and PRI. From M2, derive (TRILL-HDR, iDA, iSA, i-VL, M3).
- 丢弃DA、SA、VLAN和PRI。从M2推导（TRILL-HDR、iDA、iSA、i-VL、M3）。
- If TRILL nickname is Local and TRILL Header Alert flag is set:
- 如果颤音昵称为本地且设置了颤音标题警报标志：
* Pass on to OAM processing.
* 传递到OAM处理。
- Else, pass on (TRILL-HDR, iDA, iSA, i-VL, M3) to the RBridge layer.
- 否则，将（TRILL-HDR、iDA、iSA、i-VL、M3）传递到RBridge层。
o If the DA matches the port Local DA and the Ethertype is RBridge-Channel [RFC7178]:
o 如果DA与端口本地DA匹配且Ethertype为RBridge通道[RFC7178]：
- Process as a possible unicast native RBridge Channel packet.
- 作为可能的单播本机RBridge通道数据包进行处理。
o If the DA matches the port Local DA and the Ethertype is neither TRILL nor RBridge-Channel:
o 如果DA与端口本地DA匹配，且Ethertype既不是TRILL也不是RBridge通道：
- Discard packet.
- 丢弃数据包。
o If the DA does not match, the port is Appointed Forwarder for VLAN, and the Ethertype is not TRILL or RBridge-Channel:
o 如果DA不匹配，则端口被指定为VLAN的转发器，并且Ethertype不是TRILL或RBridge通道：
- Insert TRILL-HDR and send (TRILL-HDR, iDA, iSA,i-VL, M3) indication to the RBridge layer (this is the TRILL Ingress Function).
- 插入TRILL-HDR并向RBridge层发送（TRILL-HDR、iDA、iSA、i-VL、M3）指示（这是TRILL入口功能）。
o Receive indication (TRILL-HDR, iDA, iSA, iVL, M3) from the RBridge layer.
o 从RBridge层接收指示（TRILL-HDR、iDA、iSA、iVL、M3）。
o If the egress TRILL nickname is local:
o 如果出口颤音昵称是本地的：
- If the port is Appointed Forwarder for iVL, the port is not configured as a trunk or point-to-point (P2P) port, the TRILL Alert flag is set, and the OAM Ethertype is present, then:
- 如果该端口被指定为iVL的转发器，该端口未配置为中继或点对点（P2P）端口，设置了TRILL警报标志，并且存在OAM Ethertype，则：
* Strip TRILL-HDR and construct (DA, SA, VLAN, M2) (this is the TRILL Egress Function).
* 剥离TRILL-HDR并构建（DA、SA、VLAN、M2）（这是TRILL出口功能）。
- Else:
- 其他：
* Discard packet.
* 丢弃数据包。
o If the egress TRILL nickname is not local:
o 如果出口颤音昵称不是本地的：
- Insert Outer.MacDA, Outer.MacSA, Outer.VLAN, and TRILL Ethertype, and construct (DA, SA, VLAN, M2) where M2 is (TRILL-HDR, iDA, iSA, iVL, M).
- 插入Outer.MacDA、Outer.MacSA、Outer.VLAN和TRILL Ethertype，并构造（DA、SA、VLAN、M2），其中M2是（TRILL-HDR、iDA、iSA、iVL、M）。
o Forward (DA, SA, V, M2) to the End-Station VLAN and Priority Processing layer.
o 转发（DA、SA、V、M2）到终端站VLAN和优先级处理层。
o Receive (DA, SA, V, M2) from the End-Station VLAN and Priority Processing layer.
o 从终端站VLAN和优先级处理层接收（DA、SA、V、M2）。
o If the DA is All-RBridges and the Ethertype is TRILL:
o 如果DA为所有RBridges且Ethertype为TRILL：
- Strip DA, SA, and V. From M2, extract (TRILL-HDR, iDA, iSA, iVL, and M3).
- 从M2中剥离DA、SA和V，提取（TRILL-HDR、iDA、iSA、iVL和M3）。
- If the TRILL Alert flag is set and the OAM Ethertype is present at the end of Flow Entropy:
- 如果设置了颤音警报标志并且OAM Ethertype出现在流熵的末尾：
* Perform OAM processing.
* 执行OAM处理。
- Else, extract the TRILL Header, inner MAC addresses, and Inner.VLAN, and pass indication (TRILL-HDR, iDA, iSA, iVL and M3) to the TRILL RBridge layer.
- 否则，提取TRILL标头、内部MAC地址和inner.VLAN，并将指示（TRILL-HDR、iDA、iSA、iVL和M3）传递给TRILL RBridge层。
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 如果DA为All is RBRINGS且Ethertype为L2-is-is，则将帧传递给TRILL is-is处理。
o If the DA is All-RBridges or All-IS-IS-RBridges but the Ethertype is not TRILL or L2-IS-IS respectively:
o 如果DA为所有RBridges或所有is为RBridges，但Ethertype分别不是TRILL或L2-is-is：
- Discard the packet.
- 丢弃这个包。
o If the Ethertype is TRILL but the multicast DA is not All-RBridges or if the Ethertype is L2-IS-IS but the multicast DA is not All-IS-IS-RBridges:
o 如果Ethertype为TRILL，但多播DA不是全部RBridges，或者如果Ethertype为L2-is-is，但多播DA不是全部is RBridges：
- Discard the packet.
- 丢弃这个包。
o If the DA is All-Edge-RBridges and the Ethertype is RBridge-Channel [RFC7178]:
o 如果DA为所有边缘RBridges且Ethertype为RBridge通道[RFC7178]：
- Process as a possible multicast native RBridge Channel packet.
- 作为可能的多播本机RBridge通道数据包进行处理。
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 如果DA位于初始桥接/链路协议块（01-80-C2-00-00至01-80-C2-00-00-0F）或TRILL块中，且未分配给外部MacDA使用（01-80-C2-00-00-42至01-80-C2-00-00-4F），则：
- The frame is not propagated through an RBridge although some special processing may be done at the port as specified in [RFC6325], and the frame may be dispatched to Layer 2 processing at the port if certain protocols are supported by that port (examples include the Link Aggregation Protocol and the Link-Layer Discovery Protocol).
- 虽然可以在[RFC6325]中指定的端口处进行一些特殊处理，但帧不会通过RBridge传播，并且如果端口支持某些协议，则可以将帧发送到端口处的第2层处理（示例包括链路聚合协议和链路层发现协议）。
o If the DA is some other multicast value:
o 如果DA是其他多播值：
- Insert TRILL-HDR and construct (TRILL-HDR, iDA, iSA, IVL, M3).
- 插入TRILL-HDR并构建（TRILL-HDR、iDA、iSA、IVL、M3）。
- Pass the (TRILL-HDR, iDA, iSA, IVL, M3) to the RBridge layer.
- 将（TRILL-HDR、iDA、iSA、IVL、M3）传输至RBridge层。
The following ignores the case of transmitting TRILL IS-IS packets.
下面忽略传输TRILL IS-IS数据包的情况。
o Receive indication (TRILL-HDR, iDA, iSA, iVL, M3) from the RBridge layer.
o 从RBridge层接收指示（TRILL-HDR、iDA、iSA、iVL、M3）。
o If the TRILL Header multicast ("M") flag is set, the TRILL-HDR Alert flag is set, and the OAM Ethertype is present, then:
o 如果设置了TRILL标头多播（“M”）标志，设置了TRILL-HDR警报标志，并且存在OAM Ethertype，则：
- Construct (DA, SA, V, M2) by inserting TRILL Outer.MacDA of All-RBridges, Outer.MacSA, Outer.VLAN, and TRILL Ethertype. M2 here is (Ethertype TRILL, TRILL-HDR, iDA, iSA, iVL, M).
- 通过插入所有RBridge、Outer.MacSA、Outer.VLAN和TRILL Ethertype的TRILL Outer.MacDA来构造（DA、SA、V、M2）。这里是M2（Ethertype TRILL，TRILL-HDR，iDA，iSA，iVL，M）。
Note: A second copy of native format is not made.
注意：未制作本机格式的第二份副本。
o Else, if the TRILL Header multicast ("M") flag is set and the Alert flag not set:
o 否则，如果设置了TRILL标头多播（“M”）标志，但未设置警报标志：
- If the port is Appointed Forwarder for iVL and the port is not configured as a trunk port or a P2P port, strip TRILL-HDR, iSA, iDA, and iVL and construct (DA, SA, V, M2) for native format.
- 如果该端口被指定为iVL的转发器，且该端口未配置为中继端口或P2P端口，则剥离TRILL-HDR、iSA、iDA和iVL，并构建（DA、SA、V、M2）本机格式。
- Make a second copy (DA, SA, V, M2) by inserting TRILL Outer.MacDA, Outer.MacSA, Outer.VLAN, and TRILL Ethertype. M2 here is (Ethertype TRILL, TRILL-HDR, iDA, iSA, iVL, M).
- 通过插入TRILL Outer.MacDA、Outer.MacSA、Outer.VLAN和TRILL Ethertype创建第二个副本（DA、SA、V、M2）。这里是M2（Ethertype TRILL，TRILL-HDR，iDA，iSA，iVL，M）。
o Pass the indication (DA, SA, V, M2) to the End-Station VLAN and Priority Processing layer.
o 将指示（DA、SA、V、M2）传递到终端站VLAN和优先级处理层。
The TRILL OAM layer is located between the TRILL Encapsulation/Decapsulation layer and the RBridge layer. It performs the following: 1) identifies OAM frames that need local processing and 2) performs OAM processing or redirects to the CPU for OAM processing.
TRILL OAM层位于TRILL封装/去封装层和RBridge层之间。它执行以下操作：1）标识需要本地处理的OAM帧，2）执行OAM处理或重定向到CPU进行OAM处理。
o Receive indication (TRILL-HDR, iDA, iSA, iVL, M3) from the RBridge layer. M3 is the payload after Inner.VLAN iVL.
o 从RBridge层接收指示（TRILL-HDR、iDA、iSA、iVL、M3）。M3是Inner.VLAN iVL之后的有效负载。
o If the TRILL Header multicast ("M") flag is set, the TRILL Alert flag is set, and TRILL OAM Ethertype is present, then:
o 如果设置了TRILL Header multicast（“M”）标志，设置了TRILL Alert标志，并且存在TRILL OAM Ethertype，则：
- If MEP or MIP is configured on the Inner.VLAN/FGL of the packet, then:
- 如果在数据包的Inner.VLAN/FGL上配置了MEP或MIP，则：
* 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).
* 丢弃MD级别低于MEP的数据包或不存在MD级别的数据包（例如，由于数据包截断）。
* If MD-Level matches MD-Level of the MEP, then:
* 若MD级别与MEP的MD级别匹配，则：
+ Redirect to OAM processing (Do not forward further).
+ 重定向到OAM处理（不进一步转发）。
* If MD-Level matches MD-Level of MIP, then:
* 如果MD级别与MIP的MD级别匹配，则：
+ Make a copy for OAM processing and continue.
+ 为OAM处理制作一份副本并继续。
* If MD-Level matches MD-Level of MEP, then:
* 如果MD级别与MEP的MD级别匹配，则：
+ Redirect the OAM packet to OAM processing and do not forward along or forward as a native packet.
+ 将OAM数据包重定向到OAM处理，不要沿着或作为本机数据包转发。
o Else, if the TRILL Alert flag is set and the TRILL OAM Ethertype is present, then:
o 否则，如果设置了颤音警报标志且颤音OAM Ethertype存在，则：
- If MEP or MIP is configured on the Inner.VLAN/FGL of the packet, then:
- 如果在数据包的Inner.VLAN/FGL上配置了MEP或MIP，则：
* Discard packets that have MD-Level not present or where MD-Level is less than that of the MEP.
* 丢弃MD级别不存在或MD级别低于MEP级别的数据包。
* If MD-Level matches MD-Level of the MEP, then:
* 若MD级别与MEP的MD级别匹配，则：
+ Redirect to OAM processing (do not forward further).
+ 重定向到OAM处理（不进一步转发）。
* If MD-Level matches MD-Level of MIP, then:
* 如果MD级别与MIP的MD级别匹配，则：
+ Make a copy for OAM processing and continue.
+ 为OAM处理制作一份副本并继续。
o Else, for a non-OAM packet:
o 否则，对于非OAM数据包：
- Continue.
- 持续
o Pass the indication (DA, SA, V, M2) to the End-Station VLAN and Priority Processing layer.
o 将指示（DA、SA、V、M2）传递到终端站VLAN和优先级处理层。
Note: In the receive path, the processing above compares with the Down MEP and MIP Half functions. In the transmit processing, it compares with Up MEP and MIP Half functions.
注意：在接收路径中，上述处理与Down MEP和MIP半功能进行比较。在发送处理方面，它与Up-MEP和MIP-Half函数进行了比较。
Appointed Forwarder is a function that the TRILL Encapsulation/Decapsulation layer performs. The TRILL Encapsulation/Decapsulation layer is responsible for prevention of leaking of OAM packets as native frames.
指定转发器是TRILL封装/去封装层执行的功能。TRILL封装/去封装层负责防止OAM数据包作为本机帧泄漏。
[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.
[8021Q]将维护关联定义为一组节点之间的逻辑关系。每个维护关联（MA）由48字节的唯一MAID标识[8021Q]。CCM和其他相关OAM功能在MA的范围内运行。MA的定义与技术无关。类似地，它被编码在OAM消息中，而不是在分组的技术依赖部分中。因此，[8021Q]中定义的MAID可用于TRILL OAM，无需修改。这也允许我们按原样利用[8021Q]中定义的CCM和LBM消息。
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.
在TRILL中，MA可以包含两个或多个rbridge（mep）。对于单播，MA可能正好包含两个mep，这两个mep是流的两个端点。对于多播，MA可以包含两个或多个mep。
For TRILL, in addition to all of the standard [8021Q] CFM MIB definitions, each MEP's MIB contains one or more Flow Entropy definitions corresponding to the set of flows that the MEP monitors.
对于TRILL，除了所有标准[8021Q]CFM MIB定义外，每个MEP的MIB还包含一个或多个与MEP监控的流集相对应的流熵定义。
[8021Q] CFM MIB is augmented to add the TRILL-specific information. Figure 5 depicts the augmentation of the CFM MIB to add the TRILL-specific Flow Entropy.
[8021Q]CFM MIB被扩充以添加特定于颤音的信息。图5描述了CFM MIB的增强，以添加特定于颤音的流熵。
MA---
|
--- MEP
|
. - Remote MEP List
.
|
--- MEP-A
|
--- MEP-B
.
MA---
|
--- MEP
|
. - Remote MEP List
.
|
--- MEP-A
|
--- MEP-B
.
| . - Flow Entropy List { Augments IEEE8021-CFM-MIB}
| . - 流熵表{扩充IEEE8021-CFM-MIB}
|
--- (Flow Entropy-1)
|
--- (Flow Entropy-2)
|
. --- (Flow Entropy-n)
|
Other MIB entries
|
--- (Flow Entropy-1)
|
--- (Flow Entropy-2)
|
. --- (Flow Entropy-n)
|
Other MIB entries
Figure 5: Correlation of TRILL-Augmented MIB
图5：颤音增强MIB的相关性
The detailed TRILL OAM MIB will be specified in a separate document [TRILLOAMMIB].
详细的TRILL OAM MIB将在单独的文档[TrilloamIB]中指定。
In IEEE CFM [8021Q], OAM messages address the target MEP by utilizing a unique MAC address. In TRILL, a MEP is addressed by a combination of the egress RBridge nickname and the Inner.VLAN/FGL.
在IEEE CFM[8021Q]中，OAM消息通过使用唯一的MAC地址来寻址目标MEP。在TRILL中，通过出口RBridge昵称和Inner.VLAN/FGL的组合来寻址MEP。
Additionally, MEPs are represented by a 2-octet MEP-ID that is independent of the underlying technology. In CFM [8021Q], the value of MEP-ID is restricted to the range of 1 to 8191. However, on a CFM [8021Q] packet, MEP-IDs are encoded as a 2-octet field. In the TRILL Base Mode operation presented in Appendix B, MEP-IDs are mapped 1-to-1 with the RBridge nicknames. Hence, in TRILL, a MEP-ID MUST be a number in the range from 1 to 65535.
此外，MEP由独立于底层技术的2-octet MEP-ID表示。在CFM[8021Q]中，MEP-ID的值限制在1到8191的范围内。然而，在CFM[8021Q]数据包上，MEP ID被编码为2个八位组字段。在附录B中介绍的颤音基本模式操作中，MEP ID与RBridge昵称一一对应。因此，在TRILL中，MEP-ID必须是介于1到65535之间的数字。
At the MEP, OAM packets go through a hierarchy of OpCode demultiplexers. The OpCode demultiplexers channel the incoming OAM packets to the appropriate message processor (e.g., LBM). Refer to Figure 6 for a visual depiction of these different demultiplexers.
在MEP，OAM数据包通过操作码解复用器的层次结构。操作码解复用器将传入的OAM数据包传送到适当的消息处理器（例如LBM）。有关这些不同解复用器的视觉描述，请参阅图6。
The demultiplexing sequence is as follows:
解复用序列如下所示：
1. Identify the packets that need OAM processing at the local RBridge as specified in Section 4.
1. 按照第4节的规定，识别需要在本地RBridge进行OAM处理的数据包。
a. Identify the MEP that is associated with the Inner.VLAN/FGL.
a. 标识与Inner.VLAN/FGL关联的MEP。
2. The MEP first validates the MD-Level and then:
2. MEP首先验证MD级别，然后：
a. Redirects to the MD-Level demultiplexer.
a. 重定向到MD级解复用器。
3. The MD-Level demultiplexer compares the MD-Level of the packet against the MD-Level of the local MEPs of a given MD-Level on the port. (Note: there can be more than one MEP at the same MD-Level but they belong to different MAs.)
3. MD级别解复用器将数据包的MD级别与端口上给定MD级别的本地MEP的MD级别进行比较。（注：同一MD级别上可能有多个MEP，但它们属于不同的MAs。）
a. If the packet MD-Level is equal to the configured MD-Level of the MEP, then pass to the OpCode demultiplexer.
a. 如果数据包MD级别等于MEP配置的MD级别，则传递到操作码解复用器。
b. If the packet MD-Level is less than the configured MD-Level of the MEP, discard the packet.
b. 如果数据包MD级别低于MEP配置的MD级别，则丢弃该数据包。
c. If the packet MD-Level is greater than the configured MD-Level of the MEP, then pass on to the next-higher MD-Level demultiplexer, if available. Otherwise, if no such higher MD-Level demultiplexer exists, then forward the packet as normal data.
c. 如果数据包MD级别大于MEP配置的MD级别，则传递到下一个更高的MD级别解复用器（如果可用）。否则，如果不存在此类更高MD级别的解复用器，则将数据包作为正常数据转发。
4. The OpCode demultiplexer compares the OpCode in the packet with supported OpCodes.
4. 操作码解复用器将数据包中的操作码与支持的操作码进行比较。
a. If the OpCode is CCM, LBM, LBR, PTM, PTR, MTVM, or MTVR, then pass on to the correct processor.
a. 如果操作码是CCM、LBM、LBR、PTM、PTR、MTVM或MTVR，则传递到正确的处理器。
b. If the OpCode is unknown, then discard.
b. 如果操作码未知，则放弃。
|
.CCM LBM PTM MTVM . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+
| OP Code DE-Mux |--- Unknown
+-+-+-+-+-+-+-+-+-+-+-+-+
^ ^ ^
MD==Li | | |
+-+-+ +-+-+ +-+-+
| L |-->|L2 |-.- |Ln |---- >
+-+-+ +-+-+ +-+-+ |
| ^ | | |
MD<LI Drop | Drop Drop |
| |
MD not --- |TRILL OAM need local |
Present | Processing |
| |
TRILL Data ---- TRILL Data ----
------->| T |----------------- >| M |--- >
+ TRILL OAM ---- + pass through OAM ----
|
.CCM LBM PTM MTVM . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+
| OP Code DE-Mux |--- Unknown
+-+-+-+-+-+-+-+-+-+-+-+-+
^ ^ ^
MD==Li | | |
+-+-+ +-+-+ +-+-+
| L |-->|L2 |-.- |Ln |---- >
+-+-+ +-+-+ +-+-+ |
| ^ | | |
MD<LI Drop | Drop Drop |
| |
MD not --- |TRILL OAM need local |
Present | Processing |
| |
TRILL Data ---- TRILL Data ----
------->| T |----------------- >| M |--- >
+ TRILL OAM ---- + pass through OAM ----
Figure 6: OAM Demultiplexers at MEP for Active SAP
图6:MEP处活动SAP的OAM解复用器
o T: Denotes Tap. Identifies OAM frames that need local processing. These are the packets with the Alert flag set and OAM Ethertype present after the Flow Entropy of the packet.
o T:表示抽头。标识需要本地处理的OAM帧。这些是在数据包的流熵之后设置了警报标志和OAM Ethertype的数据包。
o M: The post-processing merge that merges data and OAM messages that are passed through. Additionally, the merge component ensures, as explained earlier, that OAM packets are not forwarded out as native frames.
o M：后处理合并，合并通过的数据和OAM消息。此外，如前所述，合并组件确保OAM数据包不会作为本机帧转发出去。
o L: Denotes MD-Level processing. Packets whose MD-Level is less than the MD-Level of the current processing step will be dropped. Packets with equal MD-Levels are passed on to the OpCode demultiplexer. Others are passed on to the next-level MD processors or eventually to the merge point (M).
o L：表示MD级处理。MD级别低于当前处理步骤MD级别的数据包将被丢弃。具有相同MD级别的数据包被传递到操作码解复用器。其他的被传递到下一级MD处理器，或最终传递到合并点（M）。
NOTE: LBM, LBR, MTVM, MTVR, PTM, and PTR are not subject to MA demultiplexers. These packets do not have an MA encoded in the packet. Adequate response can be generated to these packets, without loss of functionality, by any of the MEPs present on that interface or an entity within the RBridge.
注：LBM、LBR、MTVM、MTVR、PTM和PTR不受MA解复用器的影响。这些数据包中没有MA编码。接口上的任何MEP或RBridge中的实体都可以对这些数据包生成足够的响应，而不会丢失功能。
Maintenance Intermediate Points (MIPs) are mainly used for fault isolation. Link Trace Messages in [8021Q] utilize a well-known multicast MAC address, and MIPs generate responses to Link Trace Messages. Response to Link Trace Messages or lack thereof can be used for fault isolation in TRILL.
维修中间点（MIPs）主要用于故障隔离。[8021Q]中的链路跟踪消息利用众所周知的多播MAC地址，MIPs生成对链路跟踪消息的响应。对链路跟踪消息的响应或缺少链路跟踪消息可用于TRILL中的故障隔离。
As explained in Section 10, a Hop Count expiry approach will be utilized for fault isolation and path tracing. The approach is very similar to the well-known IP trace-route approach. Hence, explicit addressing of MIPs is not required for the purpose of fault isolation.
如第10节所述，跳数到期方法将用于故障隔离和路径跟踪。该方法与众所周知的IP跟踪路由方法非常相似。因此，出于故障隔离的目的，不需要对MIPs进行显式寻址。
Any given RBridge can have multiple MIPs located within an interface. As such, a mechanism is required to identify which MIP should respond to an incoming OAM message. Any MIP residing within the ingress interface may reply to the incoming Path Trace Message without loss of functionality or information. As specified in Section 3.4, the address of the responding RBridge can be identified by means of the Sender ID TLV (1). The Reply Ingress TLV (5) identifies the interface id. The combination of these allows the recipient of the response to uniquely identify the responder.
任何给定的RBridge都可以在一个接口中有多个MIP。因此，需要一种机制来识别哪个MIP应该响应传入的OAM消息。驻留在入口接口内的任何MIP都可以在不丢失功能或信息的情况下回复传入的路径跟踪消息。如第3.4节所述，可通过发送方ID TLV（1）识别响应RBridge的地址。应答入口TLV（5）标识接口id。这些组合允许应答接收者唯一标识应答者。
A similar approach to that presented above for MEPs can be used for MIP processing. It is important to note that "M", the merge block of a MIP, does not prevent OAM packets leaking out as native frames. On edge interfaces, MEPs MUST be configured to prevent the leaking of TRILL OAM packets out of the TRILL campus.
MIP处理可以使用与上述MEP类似的方法。重要的是要注意，MIP的合并块“M”不能防止OAM数据包作为本机帧泄漏。在边缘接口上，必须配置MEP以防止TRILL OAM数据包泄漏到TRILL园区之外。
PTM PTR MTVM MTVR
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OP Code De-Mux |-> Unknown
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^ ^ ^
MD==Li | | |
+-+-+ +-+-+ +-+-+
| L |- >|L2 |-.- |Ln |------+
+-+-+ +-+-+ +-+-+ |
^ |
| |
Drop | |
MD not --- |TRILL OAM |
Present | |
| v
TRILL Data ---- TRILL Data -----
------- >| T |------------------ >| M |---->
+ TRILL OAM ---- ----
PTM PTR MTVM MTVR
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OP Code De-Mux |-> Unknown
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^ ^ ^
MD==Li | | |
+-+-+ +-+-+ +-+-+
| L |- >|L2 |-.- |Ln |------+
+-+-+ +-+-+ +-+-+ |
^ |
| |
Drop | |
MD not --- |TRILL OAM |
Present | |
| v
TRILL Data ---- TRILL Data -----
------- >| T |------------------ >| M |---->
+ TRILL OAM ---- ----
Figure 7: OAM Demultiplexers at MIP for Active SAP
图7:MIP处用于活动SAP的OAM解复用器
o T: Tap processing for MIP. All packets with the TRILL Header Alert flag set are captured.
o T:MIP的点击处理。将捕获设置了TRILL标头警报标志的所有数据包。
o L: MD-Level Processing. Packets with matching MD-Levels are "copied" to the OpCode demultiplexer, and the original packet is passed on to the next MD-Level processor. Other packets are simply passed on to the next MD-Level processor without copying to the OpCode demultiplexer.
o L:MD级处理。具有匹配MD级别的数据包被“复制”到操作码解复用器，原始数据包被传递到下一个MD级别处理器。其他数据包只传递到下一个MD级处理器，而不复制到操作码解复用器。
o M: The intermediate point processing merge that merges data and OAM messages that are passed through.
o M：中间点处理合并，合并通过的数据和OAM消息。
Packets that carry Path Trace Message (PTM) or Multi-destination Tree Verification Message (MTVM) OpCodes are passed on to the respective processors.
携带路径跟踪消息（PTM）或多目标树验证消息（MTVM）操作码的数据包被传递到相应的处理器。
Packets with unknown OpCodes are counted and discarded.
具有未知操作码的数据包被计数并丢弃。
CCMs are used to monitor connectivity and configuration errors. [8021Q] monitors connectivity by listening to periodic CCM messages received from its remote MEP partners in the MA. An [8021Q] MEP identifies cross-connect errors by comparing the MAID in the received CCM message with the MEP's local MAID. The MAID [8021Q] is a 48-byte field that is technology independent. Similarly, the MEP-ID is a
CCM用于监控连接和配置错误。[8021Q]通过监听从其在MA中的远程MEP合作伙伴接收的周期性CCM消息来监控连接性。[8021Q]MEP通过将接收到的CCM消息中的MAID与MEP的本地MAID进行比较来识别交叉连接错误。MAID[8021Q]是一个48字节的字段，与技术无关。同样，MEP-ID是一个
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.
独立于技术的2字节字段。鉴于CCM字段的这种通用定义，[8021Q]中定义的CCM可以在颤音中使用，无需更改。当使用特定于颤音的TLV或子TLV编码时，特定于颤音的信息可以在CCMs中携带。这是可能的，因为CCM可能携带可选的TLV。
Unlike classical Ethernet environments, TRILL contains multipath forwarding. The path taken by a packet depends on the payload of the packet. The Maintenance Association (MA) identifies the interested Maintenance End Points (MEPs) of a given monitored path. For unicast, there are only two MEPs per MA. For multicast, there can be two or more MEPs in the MA. The entropy values of the monitored flows are defined within the MA. CCM transmit logic will utilize these Flow Entropy values when constructing the CCM packets. Please see Section 12 for the theory of operation of CCM.
与传统以太网环境不同，TRILL包含多路径转发。数据包所采用的路径取决于数据包的有效载荷。维护关联（MA）识别给定监控路径的相关维护端点（MEP）。对于单播，每MA只有两个mep。对于多播，MA中可以有两个或多个MEP。监测流量的熵值在MA中定义。CCM传输逻辑在构造CCM包时将利用这些流熵值。关于CCM的运行原理，请参见第12节。
The MIB in [8021Q] is augmented with the definition of Flow Entropy. Please see [TRILLOAMMIB] for this and other TRILL-related OAM MIB definitions. Figure 8 depicts the correlation between MA, CCM, and the Flow Entropy.
[8021Q]中的MIB增加了流熵的定义。有关此定义和其他与TRILL相关的OAM MIB定义，请参见[TrilloamIB]。图8描述了MA、CCM和流量熵之间的相关性。
MA---
|
--- MEP
|
. - Remote MEP List
.
|
--- MEP-A
|
--- MEP-B
.
MA---
|
--- MEP
|
. - Remote MEP List
.
|
--- MEP-A
|
--- MEP-B
.
| . - Flow Entropy List {Augments IEEE8021-CFM-MIB}
| . - 流熵表{扩充IEEE8021-CFM-MIB}
|
--- (Flow Entropy-1)
|
--- (Flow Entropy-2)
|
. ---(Flow Entropy-n)
|
. - CCM
|
--- (standard 8021ag entries)
|
--- (Hop Count) { Augments IEEE8021-CFM-MIB}
|
--- (Any other TRILL OAM-specific entries)
{Augmented}
|
.
|
- Other MIB entries
|
--- (Flow Entropy-1)
|
--- (Flow Entropy-2)
|
. ---(Flow Entropy-n)
|
. - CCM
|
--- (standard 8021ag entries)
|
--- (Hop Count) { Augments IEEE8021-CFM-MIB}
|
--- (Any other TRILL OAM-specific entries)
{Augmented}
|
.
|
- Other MIB entries
Figure 8: Augmentation of CCM MIB in TRILL
图8:TRILL中CCM MIB的扩充
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.
在多路径环境中，根据定义，流是单向的。可能会出现一个问题，即响应中应该使用什么样的流熵。CCM是单向的，没有明确的回复；因此，不会出现响应流熵的问题。在传输的CCM中，每个MEP使用远程缺陷指示（RDI）标志报告本地状态。此外，当发生连接故障时，MEP可能会发出SNMP陷阱[TRILLOAMMIB]作为警报。
The TRILL OAM Message Channel can be divided into two parts: TRILL OAM message header and TRILL OAM TLVs. Every OAM message MUST contain a single TRILL OAM message header and a set of one or more specified OAM message TLVs.
TRILL-OAM消息通道可分为两部分：TRILL-OAM消息头和TRILL-OAM TLV。每个OAM消息必须包含一个TRILL OAM消息头和一组一个或多个指定的OAM消息TLV。
As discussed earlier, a common messaging framework between [8021Q], TRILL, and other similar standards such as Y.1731 is accomplished by reusing the OAM message header defined in [8021Q].
如前所述，[8021Q]、TRILL和其他类似标准（如Y.1731）之间的公共消息传递框架是通过重用[8021Q]中定义的OAM消息头来实现的。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MD-L | Version | OpCode | Flags |FirstTLVOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. OpCode-Specific Information .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MD-L | Version | OpCode | Flags |FirstTLVOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. OpCode-Specific Information .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: OAM Message Format
图9:OAM消息格式
o MD-L: Maintenance Domain Level (3 bits). For TRILL, in general, this field is set to a single value across the TRILL campus. When using the TRILL Base Mode as specified in Appendix B, MD-L is set to 3. However, extension of TRILL (for example, to support multilevel) may create different MD-Levels, and the MD-L field must be appropriately set in those scenarios. (Please refer to [8021Q] for the definition of MD-Level).
o MD-L：维护域级别（3位）。对于TRILL，通常，此字段设置为整个TRILL校园中的单个值。当使用附录B中规定的颤音基本模式时，MD-L设置为3。但是，TRILL的扩展（例如，支持多级）可能会创建不同的MD级别，并且在这些场景中必须适当设置MD-L字段。（MD级别的定义请参考[8021Q]）。
o Version: Indicates the version (5 bits) as specified in [8021Q]. This document does not require changing the Version defined in [8021Q].
o 版本：表示[8021Q]中规定的版本（5位）。本文件不需要更改[8021Q]中定义的版本。
o OpCode: Operation Code (8 bits). Specifies the operation performed by the message. See Section 8.2.
o 操作码：操作码（8位）。指定消息执行的操作。见第8.2节。
o Flags: Includes operational flags (1 byte). The definition of flags is OpCode-specific and is covered in the applicable sections.
o 标志：包括操作标志（1字节）。标志的定义是特定于操作码的，并在适用章节中介绍。
o FirstTLVOffset: Defines the location of the first TLV, in bytes, starting from the end of the FirstTLVOffset field (1 byte). (Refer to [8021Q] for the definition of the FirstTLVOffset.)
o FirstTLVOffset：定义第一个TLV的位置，以字节为单位，从FirstTLVOffset字段（1字节）的末尾开始。（有关FirstTLVOffset的定义，请参阅[8021Q]）
o OpCode-Specific Information: May contain Session Identification Number, timestamp, etc.
o 操作码特定信息：可能包含会话标识号、时间戳等。
The MD-L, Version, OpCode, Flags, and FirstTLVOffset fields collectively are referred to as the OAM message header.
MD-L、版本、操作码、标志和FirstTLVOffset字段统称为OAM消息头。
The following TRILL-specific CFM OpCodes are defined. Each of the OpCodes indicates a separate type of TRILL OAM message. Details of the messages are presented in Sections 10 and 11.
定义了以下特定于颤音的CFM操作码。每个操作码都表示一种单独的TRILL OAM消息类型。第10节和第11节介绍了这些信息的详细信息。
TRILL OAM message OpCodes:
TRILL OAM消息操作码：
64: Path Trace Reply 65: Path Trace Message 66: Multi-destination Tree Verification Reply 67: Multi-destination Tree Verification Message
64:路径跟踪回复65:路径跟踪消息66:多目标树验证回复67:多目标树验证消息
Loopback and CCM Messages reuse the OpCodes defined by [8021Q].
环回和CCM消息重用[8021Q]定义的操作码。
The same CFM TLV format as defined in [8021Q] is used for TRILL OAM. The following figure depicts the general format of a TRILL OAM TLV:
TRILL OAM使用[8021Q]中定义的相同CFM TLV格式。下图描述了TRILL OAM TLV的一般格式：
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Value (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Value (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: TRILL OAM TLV
图10：TRILL OAM TLV
o Type (1 octet): Specifies the type of the TLV (see Section 8.4 for TLV types).
o 类型（1个八位组）：指定TLV的类型（TLV类型见第8.4节）。
o Length (2 octets): Specifies the length of the Value field in octets. Length of the Value field can be zero or more octets.
o 长度（2个八位字节）：以八位字节为单位指定值字段的长度。值字段的长度可以是零个或多个八位字节。
o Value (variable): The length and the content of this field depend on the type of TLV. Please refer to applicable TLV definitions for details.
o 值（变量）：此字段的长度和内容取决于TLV的类型。有关详细信息，请参考适用的TLV定义。
Semantics and usage of Type values allocated for TRILL OAM purpose are defined by this document and other future related documents.
本文档和其他未来相关文档定义了为TRILL OAM目的分配的类型值的语义和用法。
TRILL-related TLVs are defined in this section. TLVS defined in [8021Q] are reused, where applicable.
本节定义了与颤音相关的TLV。[8021Q]中定义的TLV在适用时可重复使用。
The following TLVs are defined in [8021Q]. We reuse them where applicable. The format and semantics of the TLVs are as defined in [8021Q].
[8021Q]中定义了以下TLV。我们在适用的地方重用它们。TLV的格式和语义如[8021Q]中所定义。
Type Name of TLV in [8021Q]
---- ----------------------
0 End TLV
1 Sender ID TLV
2 Port Status TLV
3 Data TLV
4 Interface Status TLV
5 Reply Ingress TLV
6 Reply Egress TLV
7 LTM Egress Identifier TLV
8 LTR Egress Identifier TLV
9-30 Reserved
31 Organization Specific TLV
Type Name of TLV in [8021Q]
---- ----------------------
0 End TLV
1 Sender ID TLV
2 Port Status TLV
3 Data TLV
4 Interface Status TLV
5 Reply Ingress TLV
6 Reply Egress TLV
7 LTM Egress Identifier TLV
8 LTR Egress Identifier TLV
9-30 Reserved
31 Organization Specific TLV
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.
下面列出的是TRILL OAM TLV及其相应代码的摘要。TRILL OAM TLV的格式和语义将在后续章节中定义。
Type TLV Name
---- ------------------------------------
64 TRILL OAM Application Identifier TLV
65 Out-of-Band Reply Address TLV
66 Diagnostic Label TLV
67 Original Data Payload TLV
68 RBridge Scope TLV
69 Previous RBridge Nickname TLV
70 Next-Hop RBridge List TLV
71 Multicast Receiver Port Count TLV
72 Flow Identifier TLV
73 Reflector Entropy TLV
74 Authentication TLV
Type TLV Name
---- ------------------------------------
64 TRILL OAM Application Identifier TLV
65 Out-of-Band Reply Address TLV
66 Diagnostic Label TLV
67 Original Data Payload TLV
68 RBridge Scope TLV
69 Previous RBridge Nickname TLV
70 Next-Hop RBridge List TLV
71 Multicast Receiver Port Count TLV
72 Flow Identifier TLV
73 Reflector Entropy TLV
74 Authentication TLV
The TRILL OAM Application Identifier TLV (64) MUST be the first TLV. An End TLV (0) MUST be included as the last TLV. All other TLVs can be included in any order.
TRILL OAM应用程序标识符TLV（64）必须是第一个TLV。必须将结束TLV（0）作为最后一个TLV包括在内。所有其他TLV可按任何顺序包含。
The TRILL OAM Application Identifier TLV carries information specific to TRILL OAM applications. The TRILL OAM Application Identifier TLV MUST always be present and MUST be the first TLV in TRILL OAM messages. Messages that do not include the TRILL OAM Application Identifier TLV as the first TLV MUST be discarded by a TRILL MP.
TRILL-OAM应用程序标识符TLV携带特定于TRILL-OAM应用程序的信息。TRILL OAM应用程序标识符TLV必须始终存在，并且必须是TRILL OAM消息中的第一个TLV。TRILL MP必须丢弃未将TRILL OAM应用程序标识符TLV作为第一个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 | Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved1 | Fragment-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code |Return Sub-code| Reserved2 |F|C|O|I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved1 | Fragment-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code |Return Sub-code| Reserved2 |F|C|O|I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: TRILL OAM Application Identifier TLV
图11:TRILL OAM应用程序标识符TLV
o Type (1 octet): 64, TRILL OAM Application Identifier TLV
o 类型（1个八位字节）：64，TRILL OAM应用程序标识符TLV
o Length (2 octets): 9
o 长度（2个八位字节）：9
o Version (1 octet): Currently set to zero. Indicates the TRILL OAM version. The TRILL OAM version can be different than the [8021Q] version.
o 版本（1个八位组）：当前设置为零。指示TRILL OAM版本。TRILL OAM版本可能不同于[8021Q]版本。
o Reserved1 (3 octets): Set to zero on transmission and ignored on reception.
o Reserved1（3个八位字节）：传输时设置为零，接收时忽略。
o Fragment-ID (1 octet): Indicates the fragment number of the current message. This applies only to reply messages; in request messages, it must be set to zero on transmission and ignored on receipt. The "F" flag defined below MUST be set with the final message, whether it is the last fragment of the fragmented message or the only message of the reply. Section 13 provides more details on OAM message fragmentation.
o 片段ID（1个八位组）：表示当前消息的片段编号。这仅适用于回复消息；在请求消息中，必须在传输时将其设置为零，在接收时将其忽略。下面定义的“F”标志必须与最终消息一起设置，无论它是分段消息的最后一个片段还是回复的唯一消息。第13节提供了有关OAM消息分段的更多详细信息。
o Return Code (1 octet): Set to zero on requests. Set to an appropriate value in response messages.
o 返回代码（1个八位字节）：请求时设置为零。在响应消息中设置为适当的值。
o Return Sub-code (1 octet): Set to zero on transmission of request message. The Return Sub-code identifies categories within a specific Return Code and MUST be interpreted within a Return Code.
o 返回子代码（1个八位字节）：在传输请求消息时设置为零。退货子代码标识特定退货代码中的类别，必须在退货代码中进行解释。
o Reserved2 (12 bits): Set to zero on transmission and ignored on reception.
o Reserved2（12位）：传输时设置为零，接收时忽略。
o F (1 bit): Final flag. When set, indicates this is the last response.
o F（1位）：最终标志。设置时，表示这是最后一次响应。
o C (1 bit): Cross-Connect Error flag (VLAN/FGL mapping error). If set, indicates that the label (VLAN/FGL) in the Flow Entropy is different than the label included in the Diagnostic Label TLV. This field is ignored in request messages and MUST only be interpreted in response messages.
o C（1位）：交叉连接错误标志（VLAN/FGL映射错误）。如果设置，则表示流熵中的标签（VLAN/FGL）不同于诊断标签TLV中包含的标签。此字段在请求消息中被忽略，只能在响应消息中解释。
o O (1 bit): If set, indicates OAM out-of-band response requested.
o O（1位）：如果设置，则表示请求的OAM带外响应。
o I (1 bit): If set, indicates OAM in-band response requested.
o I（1位）：如果设置，则表示请求的OAM带内响应。
NOTE: When both O and I bits are set to zero, this indicates that no response is required (silent mode). Users MAY specify both O and I, one of them, or none. When both O and I bits are set, the response is sent both in-band and out-of-band.
注意：当O和I位都设置为零时，这表示不需要响应（静默模式）。用户可以同时指定O和I、其中一个或无。当同时设置O和I位时，响应将在带内和带外发送。
The Out-of-Band Reply Address TLV specifies the address to which an out-of-band OAM reply message MUST be sent. When the O bit in the TRILL Version sub-TLV (Section 3.3) is not set, the Out-of-Band Reply Address TLV is ignored.
带外应答地址TLV指定带外OAM应答消息必须发送到的地址。当TRILL版本子TLV（第3.3节）中的O位未设置时，带外回复地址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 | Address Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Length | |
+-+-+-+-+-+-+-+-+ |
| |
. Reply Address .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Length | |
+-+-+-+-+-+-+-+-+ |
| |
. Reply Address .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Out-of-Band Reply Address TLV
图12：带外回复地址TLV
o Type (1 octet): 65, Out-of-Band Reply Address TLV
o 类型（1个八位组）：65，带外应答地址TLV
o Length (2 octets): Variable. Minimum length is 2 + the length (in octets) of the shortest address. Currently, the minimum value of this field is 4, but this could change in the future if a new address shorter than the TRILL nickname is defined.
o 长度（2个八位字节）：可变。最小长度为2+最短地址的长度（以八位字节为单位）。目前，该字段的最小值为4，但如果定义了一个短于颤音昵称的新地址，则将来可能会发生变化。
o Address Type (1 octet):
o 地址类型（1个八位字节）：
0 - IPv4
0-IPv4
1 - IPv6
1-IPv6
2 - TRILL nickname
2-颤音昵称
All other values reserved.
保留所有其他值。
o Addr Length (1 octet): Depends on the Address Type. Currently, defined values are:
o 地址长度（1个八位字节）：取决于地址类型。目前，定义的值为：
4 - IPv4
4-IPv4
16 - IPv6
16-IPv6
2 - TRILL nickname
2-颤音昵称
Other lengths may be acceptable for future Address Types.
对于未来的地址类型，可以接受其他长度。
o Reply Address (variable): Address where the reply needs to be sent. Length depends on the address specification.
o 回复地址（变量）：需要发送回复的地址。长度取决于地址规范。
The Diagnostic Label TLV specifies the data label (VLAN or FGL) in which the OAM messages are generated. Receiving RBridge MUST compare the data label of the Flow Entropy to the data label specified in the Diagnostic Label TLV. The "C" flag (Cross Connect Error) in the response (TRILL OAM Application Identifier TLV; Section 8.4.3) MUST be set when the two VLANs do not match.
诊断标签TLV指定生成OAM消息的数据标签（VLAN或FGL）。接收RBridge必须将流量熵的数据标签与诊断标签TLV中指定的数据标签进行比较。当两个VLAN不匹配时，必须设置响应（TRILL OAM应用程序标识符TLV；第8.4.3节）中的“C”标志（交叉连接错误）。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | L-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Diagnostic Label TLV
图13：诊断标签TLV
o Type (1 octet): 66, Diagnostic Label TLV
o 类型（1个八位组）：66，诊断标签TLV
o Length (2 octets): 5
o 长度（2个八位字节）：5
o L-Type (1 octet): Label type
o L型（1个八位组）：标签型
0 - Indicates a right-justified 802.1Q 12-bit VLAN padded on the left with bits that must be sent as zero and ignored on receipt
0-表示一个右对齐的802.1Q 12位VLAN，在左侧填充位，这些位必须作为零发送，并在接收时忽略
1 - Indicates a TRILL 24-bit fine-grained label
1-表示颤音24位细粒度标签
o Reserved (1 octet): Set to zero on transmission and ignored on reception.
o 保留（1个八位组）：传输时设置为零，接收时忽略。
o Label (24 bits): Either 12-bit VLAN or 24 bit fine-grained label.
o 标签（24位）：12位VLAN或24位细粒度标签。
RBridges do not perform label error checking when the Diagnostic Label TLV is not included in the OAM message. In certain deployments, intermediate devices may perform label translation. In such scenarios, the originator should not include the Diagnostic Label TLV in OAM messages. Inclusion of Diagnostic Label TLV will generate unwanted label error notifications.
当OAM消息中未包含诊断标签TLV时，RBridges不执行标签错误检查。在某些部署中，中间设备可以执行标签转换。在这种情况下，发起人不应在OAM消息中包含诊断标签TLV。包含诊断标签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 .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. Original Payload .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Original Data Payload TLV
图14：原始数据有效负载TLV
o Type (1 octet): 67, Original Data Payload TLV
o 类型（1个八位组）：67，原始数据有效载荷TLV
o Length (2 octets): variable
o 长度（2个八位字节）：可变
o Original Payload: The original TRILL Header and Flow Entropy. Used in constructing replies to the Loopback Message (see Section 9) and the Path Trace Message (see Section 10).
o 原始有效载荷：原始颤音标题和流熵。用于构造对环回消息（参见第9节）和路径跟踪消息（参见第10节）的回复。
The RBridge Scope TLV identifies nicknames of RBridges from which a response is required. The RBridge Scope TLV is only applicable to Multi-destination Tree Verification Messages. This TLV SHOULD NOT be included in other messages. Receiving RBridges MUST ignore this TLV on messages other than Multi-destination Tree Verification Messages.
RBridge作用域TLV标识需要响应的RBridge的昵称。RBridge作用域TLV仅适用于多目标树验证消息。此TLV不应包含在其他消息中。接收RBridges必须忽略除多目标树验证消息之外的消息上的此TLV。
Each TLV can contain up to 255 nicknames of in-scope RBridges. A Multi-destination Tree Verification Message may contain multiple RBridge scope TLVs, in the event that more than 255 in-scope RBridges need to be specified.
每个TLV最多可以包含255个作用域内RBridges的昵称。如果需要指定超过255个范围内RBridge，则多目标树验证消息可能包含多个RBridge范围TLV。
Absence of the RBridge Scope TLV indicates that a response is needed from all the RBridges. Please see Section 11 for details.
缺少RBridge作用域TLV表示需要所有RBridge的响应。详情请参见第11节。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | nOfnicknames |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname-1 | Nickname-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Nickname-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: RBridge Scope TLV
图15:RBridge范围TLV
o Type (1 octet): 68, RBridge Scope TLV
o 类型（1个八位组）：68，RBridge范围TLV
o Length (2 octets): Variable. Minimum value is 1.
o 长度（2个八位字节）：可变。最小值为1。
o nOfnicknames (1 octet): Indicates the number of nicknames included in this TLV. Zero (0) indicates no nicknames are included in the TLV. When this field is set to zero (0), the Length field MUST be set to 1.
o nOfnicknames（1个八位组）：表示此TLV中包含的昵称数。零（0）表示TLV中不包含昵称。当此字段设置为零（0）时，长度字段必须设置为1。
o Nickname (2 octets): 16-bit RBridge nickname
o 昵称（2个八位字节）：16位RBridge昵称
The Previous RBridge Nickname TLV identifies the nickname or nicknames of the previous RBridge. [RFC6325] allows a given RBridge to hold multiple nicknames.
前一个RBridge昵称TLV标识前一个RBridge的一个或多个昵称。[RFC6325]允许给定的RBridge保留多个昵称。
The Previous RBridge Nickname TLV is an optional TLV. Multiple instances of this TLV MAY be included when an upstream RBridge is represented by more than 255 nicknames (highly unlikely).
以前的RBridge昵称TLV是可选的TLV。当上游RBridge由超过255个昵称表示时（极不可能），可能包括该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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (continued) | Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (continued) | Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Previous RBridge Nickname TLV
图16：以前的RBridge昵称TLV
o Type (1 octet): 69, Previous RBridge Nickname TLV
o 类型（1个八位组）：69，以前的RBridge昵称TLV
o Length (2 octets): 5
o 长度（2个八位字节）：5
o Reserved (3 octet): Set to zero on transmission and ignored on reception.
o 保留（3个八位组）：传输时设置为零，接收时忽略。
o Nickname (2 octets): RBridge nickname
o 昵称（2个八位组）：RBridge昵称
The Next-Hop RBridge List TLV identifies the nickname or nicknames of the downstream next-hop RBridges. [RFC6325] allows a given RBridge to have multiple equal-cost paths to a specified destination. Each next-hop RBridge is represented by one of its nicknames.
下一跳RBridge列表TLV标识下游下一跳RBridge的一个或多个昵称。[RFC6325]允许给定的RBridge具有多条到指定目的地的等成本路径。每个下一跳RBridge由它的一个昵称表示。
The Next-Hop RBridge List TLV is an optional TLV. Multiple instances of this TLV MAY be included when there are more than 255 equal-cost paths to the destination.
下一跳RBridge列表TLV是可选的TLV。当到达目的地的成本路径超过255条时，可能会包括该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 | nOfnicknames |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname-1 | Nickname-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Nickname-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | nOfnicknames |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname-1 | Nickname-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Nickname-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Next-Hop RBridge List TLV
图17：下一跳RBridge列表TLV
o Type (1 octet): 70, Next-Hop RBridge List TLV
o 类型（1个八位字节）：70，下一跳RBridge列表TLV
o Length (2 octets): Variable. Minimum value is 1.
o 长度（2个八位字节）：可变。最小值为1。
o nOfnicknames (1 octet): Indicates the number of nicknames included in this TLV. Zero (0) indicates no nicknames are included in the TLV. When this field is set to zero (0), the Length field MUST be set to 1.
o nOfnicknames（1个八位组）：表示此TLV中包含的昵称数。零（0）表示TLV中不包含昵称。当此字段设置为零（0）时，长度字段必须设置为1。
o Nickname (2 octets): 16-bit RBridge nickname
o 昵称（2个八位字节）：16位RBridge昵称
The Multicast Receiver Port Count TLV identifies the number of ports interested in receiving the specified multicast stream within the responding RBridge on the label (VLAN or FGL) specified by the Diagnostic Label TLV.
多播接收器端口计数TLV标识诊断标签TLV指定的标签（VLAN或FGL）上响应RBridge内有兴趣接收指定多播流的端口数。
The Multicast Receiver Port Count TLV is an optional TLV.
多播接收器端口计数TLV是可选的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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Receivers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Multicast Receiver Port Count TLV
图18：多播接收器端口计数TLV
o Type (1 octet): 71, Multicast Receiver Port Count TLV
o 类型（1个八位组）：71，多播接收器端口计数TLV
o Length (2 octets): 5
o 长度（2个八位字节）：5
o Reserved (1 octet): Set to zero on transmission and ignored on reception.
o 保留（1个八位组）：传输时设置为零，接收时忽略。
o Number of Receivers (4 octets): Indicates the number of multicast receivers available on the responding RBridge on the label specified by the diagnostic label.
o 接收器数量（4个八位字节）：表示诊断标签指定的标签上响应RBridge上可用的多播接收器数量。
The Flow Identifier TLV uniquely identifies a specific flow. The flow-identifier value is unique per MEP and needs to be interpreted as such.
流标识符TLV唯一地标识特定流。每个MEP的流量标识符值都是唯一的，因此需要进行解释。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MEP-ID | flow-identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MEP-ID | flow-identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: Flow Identifier TLV
图19：流标识符TLV
o Type (1 octet): 72, Flow Identifier TLV
o 类型（1个八位组）：72，流标识符TLV
o Length (2 octets): 5
o 长度（2个八位字节）：5
o Reserved (1 octet): Set to 0 on transmission and ignored on reception.
o 保留（1个八位组）：传输时设置为0，接收时忽略。
o MEP-ID (2 octets): MEP-ID of the originator [8021Q]. In TRILL, MEP-ID can take a value from 1 to 65535.
o MEP-ID（2个八位字节）：发起者的MEP-ID[8021Q]。在TRILL中，MEP-ID可以取1到65535之间的值。
o flow-identifier (2 octets): Uniquely identifies the flow per MEP. Different MEPs may allocate the same flow-identifier value. The {MEP-ID, flow-identifier} pair is globally unique.
o 流量标识符（2个八位字节）：唯一标识每个MEP的流量。不同的MEP可以分配相同的流标识符值。{MEP-ID，流标识符}对是全局唯一的。
Inclusion of the MEP-ID in the Flow Identifier TLV allows the inclusion of a MEP-ID for messages that do not contain a MEP-ID in their OAM header. Applications may use MEP-ID information for different types of troubleshooting.
在流标识符TLV中包含MEP-ID允许为其OAM标头中不包含MEP-ID的消息包含MEP-ID。应用程序可以使用MEP-ID信息进行不同类型的故障排除。
The Reflector Entropy TLV is an optional TLV. This TLV, when present, tells the responder to utilize the Reflector Entropy specified within the TLV as the flow-entropy of the response message.
反射层熵TLV是可选的TLV。该TLV（当存在时）告知响应者利用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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Reflector Entropy .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Reflector Entropy .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: Reflector Entropy TLV
图20：反射熵TLV
o Type (1 octet): 73, Reflector Entropy TLV
o 类型（1个八位组）：73，反射熵TLV
o Length (2 octets): 97
o 长度（2个八位字节）：97
o Reserved (1 octet): Set to zero on transmission and ignored by the recipient.
o 保留（1个八位组）：传输时设置为零，收件人忽略。
o Reflector Entropy (96 octets): Flow Entropy to be used by the responder. May be padded with zeros if the desired flow-entropy information is less than 96 octets.
o 反射熵（96个八位组）：响应者使用的流熵。如果所需的流熵信息小于96个八位字节，则可以用零填充。
The Authentication TLV is an optional TLV that can appear in any OAM message or reply in TRILL.
认证TLV是可选的TLV，可以出现在任何OAM消息中或以TRILL形式回复。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Auth Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Authentication Value .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Auth Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Authentication Value .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: Authentication TLV
图21：认证TLV
o Type (1 octet): 74, Authentication TLV
o 类型（1个八位组）：74，认证TLV
o Length (2 octets): Variable
o 长度（2个八位字节）：可变
o The Auth Type and following Authentication Value are the same as the Auth Type and following value for the [IS-IS] Authentication TLV. It is RECOMMENDED that Auth Type 3 be used. Auth Types 0, 1, 2, and 54 MUST NOT be used. With Auth Type 3, the Authentication TLV is as follows:
o 身份验证类型和后续身份验证值与[IS-IS]身份验证TLV的身份验证类型和后续值相同。建议使用Auth Type 3。不能使用身份验证类型0、1、2和54。对于Auth Type 3，验证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 | Auth Type = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. Authentication Data (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Auth Type = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. Authentication Data (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: Authentication TLV with Auth Type 3
图22:Auth类型为3的认证TLV
With Auth Type 3, the process is generally as specified in [RFC5310] using the same Key ID space as TRILL [IS-IS]. The area covered by the Authentication TLV is from the beginning of the TRILL Header to the end of the TRILL OAM Message Channel; the Link Header and Trailer are not included. The TRILL Header Alert, Reserved bit, and Hop Count are treated as zero for the purposes of computing and verifying the Authentication Data.
对于Auth Type 3，该过程通常如[RFC5310]所述，使用与TRILL[is-is]相同的密钥ID空间。认证TLV所覆盖的区域是从TRILL报头的开始到TRILL OAM消息信道的结束；不包括连杆头和拖车。为了计算和验证身份验证数据，TRILL报头警报、保留位和跃点计数被视为零。
Key distribution is out of the scope of this document as the keying distributed for IS-IS is used.
密钥分发不在本文档范围内，因为使用了为is-is分发的密钥。
An RBridge supporting OAM authentication can be configured to either (1) ignore received OAM Authentication TLVs and not send them, (2) ignore received OAM Authentication TLVs but include them in all OAM packets sent, or (3) to include Authentication TLVs in all OAM messages sent and enforce authentication of OAM messages received. When an RBridge is enforcing authentication, it discards any OAM message subject to OAM processing that does not contain an Authentication TLV or an Authentication TLV does not verify.
支持OAM身份验证的RBridge可以配置为（1）忽略接收到的OAM身份验证TLV而不发送它们，（2）忽略接收到的OAM身份验证TLV，但将它们包括在发送的所有OAM数据包中，或者（3）在发送的所有OAM消息中包括身份验证TLV并强制对接收到的OAM消息进行身份验证。当RBridge强制进行身份验证时，它将丢弃任何经过OAM处理的、不包含身份验证TLV或身份验证TLV未验证的OAM消息。
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 .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MD-L | Version | OpCode | Flags |FirstTLVOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Loopback Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: Loopback Message Format
图23：环回消息格式
The figure above depicts the format of the Loopback Request and Response messages as defined in [8021Q]. The OpCode for the Loopback Message is set to 3, and the OpCode for the reply message is set to 2 [8021Q]. The Loopback Transaction Identifier (commonly called the Session Identification Number or Session ID in this document) is a 32-bit integer that allows the requesting RBridge to uniquely identify the corresponding session. Responding RBridges, without modification, MUST echo the received "Loopback Transaction Identifier" number.
上图描述了[8021Q]中定义的环回请求和响应消息的格式。环回消息的操作码设置为3，回复消息的操作码设置为2[8021Q]。环回事务标识符（在本文档中通常称为会话标识号或会话ID）是32位整数，允许请求RBridge唯一标识相应会话。未经修改的响应RBridge必须回显收到的“环回事务标识符”编号。
The originator RBridge takes the following actions:
发起人RBridge采取以下行动：
o Identifies the destination RBridge nickname based on user specification or based on the specified destination MAC or IP address.
o 根据用户规范或指定的目标MAC或IP地址标识目标RBridge昵称。
o Constructs the Flow Entropy based on user-specified parameters or implementation-specific default parameters.
o 基于用户指定的参数或实现特定的默认参数构造流熵。
o Constructs the TRILL OAM header: sets the OpCode to Loopback Message type (3) [8021Q]. Assigns applicable Loopback Transaction Identifier number for the request.
o 构造TRILL OAM头：将操作码设置为环回消息类型（3）[8021Q]。为请求分配适用的环回事务标识符编号。
o The TRILL OAM Application Identifier TLV MUST be included with the flags set to applicable values.
o TRILL OAM应用程序标识符TLV必须包含在设置为适用值的标志中。
o Includes following OAM TLVs, where applicable:
o 包括以下OAM TLV（如适用）：
- Out-of-Band Reply Address TLV
- 带外应答地址TLV
- Diagnostic Label TLV
- 诊断标签TLV
- Sender ID TLV
- 发送者ID TLV
o Specifies the Hop Count of the TRILL Data frame per user specification or utilize an applicable Hop Count value.
o 根据用户规范指定颤音数据帧的跃点计数，或使用适用的跃点计数值。
o Dispatches the OAM frame for transmission.
o 分派OAM帧以进行传输。
RBridges may continue to retransmit the request at periodic intervals until a response is received or the retransmission count expires. At each transmission, the Session Identification Number MUST be incremented.
RBridges可继续以周期性间隔重新传输请求，直到接收到响应或重新传输计数到期。在每次传输时，会话标识号必须递增。
Intermediate RBridges forward the frame as a normal data frame; no special handling is required.
中间帧作为正常数据帧转发该帧；无需特殊处理。
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.
如果环回消息发往本地RBridge并满足第3.1节中规定的OAM识别标准，则RBridge数据平面将消息转发给CPU进行进一步处理。
The TRILL OAM application layer further validates the received OAM frame by checking for the presence of OAM Ethertype at the end of the Flow Entropy. Frames that do not contain OAM Ethertype at the end of the Flow Entropy MUST be discarded.
TRILL OAM应用层通过检查流熵末尾是否存在OAM Ethertype来进一步验证接收到的OAM帧。必须丢弃流熵末尾不包含OAM Ethertype的帧。
Construction of the TRILL OAM response:
TRILL OAM响应的构建：
o The TRILL OAM application encodes the received TRILL Header and Flow Entropy in the Original Data Payload TLV and includes it in the OAM message.
o TRILL OAM应用程序在原始数据有效负载TLV中对接收到的TRILL报头和流熵进行编码，并将其包括在OAM消息中。
o Set the Return Code to (1) "Reply" and Return Sub-code to zero (0) "Valid Response". Update the TRILL OAM OpCode to 2 (Loopback Message Reply).
o 将返回代码设置为（1）“回复”，并将子代码设置为零（0）“有效响应”。将TRILL OAM操作码更新为2（环回消息回复）。
o Optionally, if the VLAN/FGL identifier value of the received Flow Entropy differs from the value specified in the Diagnostic Label TLV, set the "C" flag (Cross Connect Error) in the TRILL OAM Application Identifier TLV.
o 或者，如果接收到的流熵的VLAN/FGL标识符值不同于诊断标签TLV中指定的值，则在TRILL OAM应用程序标识符TLV中设置“C”标志（交叉连接错误）。
o Include the Sender ID TLV (1).
o 包括发送方ID TLV（1）。
o If in-band response was requested, dispatch the frame to the TRILL data plane with request-originator RBridge nickname as the egress RBridge nickname.
o 如果请求带内响应，则将帧发送到TRILL数据平面，并将请求发起人RBridge昵称作为出口RBridge昵称。
o If out-of-band response was requested, dispatch the frame to the IP forwarding process.
o 如果请求带外响应，则将帧分派到IP转发进程。
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.
路径跟踪消息的主要用途是用于故障隔离。它还可用于绘制从给定RBridge到另一RBridge的路径。
[8021Q] accomplishes the objectives of the TRILL Path Trace Message using Link Trace Messages. Link Trace Messages utilize a well-known multicast MAC address. This works for [8021Q] because both the unicast and multicast paths are congruent. However, in TRILL, multicast and unicast are not congruent. Hence, TRILL OAM uses a new message format: the Path Trace Message.
[8021Q]使用链路跟踪消息实现颤音路径跟踪消息的目标。链路跟踪消息利用众所周知的多播MAC地址。这适用于[8021Q]，因为单播和多播路径都是一致的。然而，在TRILL中，多播和单播并不一致。因此，TRILL OAM使用了一种新的消息格式：路径跟踪消息。
The Path Trace Message has the same format as the Loopback Message. The OpCode for Path Trace Reply is 64, and the OpCode for the Path Trace Message is 65.
路径跟踪消息的格式与环回消息的格式相同。路径跟踪回复的操作码为64，路径跟踪消息的操作码为65。
Operation of the Path Trace Message is identical to the Loopback Message except that it is first transmitted with a TRILL Header Hop Count field value of 1. The sending RBridge expects an "Intermediate RBridge" Return Sub-code from the next hop or a "Valid response" Return Sub-code response from the destination RBridge. If an "Intermediate RBridge" Return Sub-code is received in the response, the originator RBridge records the information received from the intermediate node that generated the message and resends the message by incrementing the previous Hop Count value by 1. This process is continued until, a response is received from the destination RBridge, a Path Trace process timeout occurs, or the Hop Count reaches a configured maximum value.
路径跟踪消息的操作与环回消息的操作相同，不同之处在于它首先以TRILL头跃点计数字段值1进行传输。发送RBridge需要来自下一跳的“中间RBridge”返回子码或来自目标RBridge的“有效响应”返回子码响应。如果在响应中接收到“中间RBridge”返回子码，则发起者RBridge记录从生成消息的中间节点接收到的信息，并通过将前一跳计数值增加1来重新发送消息。此过程将继续，直到收到来自目标RBridge的响应、发生路径跟踪过程超时或跃点计数达到配置的最大值。
The originator RBridge takes the following actions:
发起人RBridge采取以下行动：
o Identifies the destination RBridge based on user specification or based on location of the specified MAC address.
o 根据用户规范或指定MAC地址的位置标识目标RBridge。
o Constructs the Flow Entropy based on user-specified parameters or implementation-specific default parameters.
o 基于用户指定的参数或实现特定的默认参数构造流熵。
o Constructs the TRILL OAM header: set the OpCode to Path Trace Message type (65). Assign an applicable Session Identification number for the request. Return Code and Return Sub-code MUST be set to zero.
o 构造TRILL OAM头：将操作码设置为路径跟踪消息类型（65）。为请求分配适用的会话标识号。返回代码和返回子代码必须设置为零。
o The TRILL OAM Application Identifier TLV MUST be included with the flags set to applicable values.
o TRILL OAM应用程序标识符TLV必须包含在设置为适用值的标志中。
o Includes the following OAM TLVs, where applicable:
o 包括以下OAM TLV（如适用）：
- Out-of-Band Reply Address TLV
- 带外应答地址TLV
- Diagnostic Label TLV
- 诊断标签TLV
- Sender ID TLV
- 发送者ID TLV
o Specifies the Hop Count of the TRILL Data frame as 1 for the first request.
o 对于第一个请求，将颤音数据帧的跃点计数指定为1。
o Dispatches the OAM frame to the TRILL data plane for transmission.
o 将OAM帧分派到TRILL数据平面进行传输。
An RBridge may continue to retransmit the request at periodic intervals until a response is received or the retransmission count expires. At each new retransmission, the Session Identification number MUST be incremented. Additionally, for responses received from intermediate RBridges, the RBridge nickname and interface information MUST be recorded.
RBridge可以以周期性间隔继续重传请求，直到接收到响应或重传计数到期。每次重新传输时，会话标识号必须递增。此外，对于从中间RBridge接收的响应，必须记录RBridge昵称和接口信息。
Path Trace Messages transit through Intermediate RBridges transparently, unless the Hop Count has expired.
路径跟踪消息透明地通过中间RBridge传输，除非跃点计数已过期。
The TRILL OAM application layer further validates the received OAM frame by examining the presence of the TRILL Alert flag and OAM Ethertype at the end of the Flow Entropy and by examining the MD-Level. Frames that do not contain OAM Ethertype at the end of the Flow Entropy MUST be discarded.
TRILL OAM应用层通过检查流熵末尾是否存在TRILL Alert标志和OAM Ethertype以及检查MD级别，进一步验证接收到的OAM帧。必须丢弃流熵末尾不包含OAM Ethertype的帧。
Construction of the TRILL OAM response:
TRILL OAM响应的构建：
o The TRILL OAM application encodes the received TRILL Header and Flow Entropy in the Original Data Payload TLV and includes it in the OAM message.
o TRILL OAM应用程序在原始数据有效负载TLV中对接收到的TRILL报头和流熵进行编码，并将其包括在OAM消息中。
o Set the Return Code to (1) "Reply" and Return Sub-code to two (2) "Intermediate RBridge". Update the TRILL OAM OpCode to 64 (Path Trace Reply).
o 将返回代码设置为（1）“回复”，并将子代码设置为两（2）“中间RBridge”。将TRILL OAM操作码更新为64（路径跟踪回复）。
o If the VLAN/FGL identifier value of the received Flow Entropy differs from the value specified in the diagnostic label, set the "C" flag (Cross Connect Error) in the TRILL OAM Application Identifier TLV.
o 如果接收到的流熵的VLAN/FGL标识符值与诊断标签中指定的值不同，请在TRILL OAM应用程序标识符TLV中设置“C”标志（交叉连接错误）。
o Include the following TLVs:
o 包括以下TLV：
- Previous RBridge Nickname TLV (69)
- 以前的RBridge昵称TLV（69）
- Reply Ingress TLV (5)
- 应答入口TLV（5）
- Reply Egress TLV (6)
- 应答出口TLV（6）
- Interface Status TLV (4)
- 接口状态TLV（4）
- Next-Hop RBridge List TLV (70) (Repeat for each ECMP)
- 下一跳RBridge列表TLV（70）（对每个ECMP重复）
- Sender ID TLV (1)
- 发送者ID TLV（1）
o If a cross-connect error is detected, set the "C" flag (Cross-Connect Error) in the reply's TRILL OAM Application Identifier TLV.
o 如果检测到交叉连接错误，请在应答的TRILL OAM应用程序标识符TLV中设置“C”标志（交叉连接错误）。
o If in-band response was requested, dispatch the frame to the TRILL data plane with request-originator RBridge nickname as the egress RBridge nickname.
o 如果请求带内响应，则将帧发送到TRILL数据平面，并将请求发起人RBridge昵称作为出口RBridge昵称。
o If out-of-band response was requested, dispatch the frame to the standard IP forwarding process.
o 如果请求带外响应，则将帧分派到标准IP转发过程。
Processing is identical to that in Section 10.1.2 with the exception that the TRILL OAM OpCode is set to Path Trace Reply (64).
处理与第10.1.2节中的处理相同，但TRILL OAM操作码设置为路径跟踪应答（64）。
Multi-destination Tree Verification Messages allow verifying TRILL distribution tree integrity and pruning. TRILL VLAN/FGL and multicast pruning are described in [RFC6325], [RFC7180], and [RFC7172]. Multi-destination Tree Verification and Multicast Group Verification Messages are designed to detect pruning defects. Additionally, these tools can be used for plotting a given multicast tree within the TRILL campus.
多目标树验证消息允许验证TRILL分发树的完整性和修剪。TRILL VLAN/FGL和多播修剪在[RFC6325]、[RFC7180]和[RFC7172]中进行了描述。设计了多目标树验证和多播组验证消息来检测剪枝缺陷。此外，这些工具可用于在TRILL校园内绘制给定的多播树。
Multi-destination Tree Verification OAM frames are copied to the CPU of every intermediate RBridge that is part of the distribution tree being verified. The originator of the Multi-destination Tree Verification Message specifies the scope of RBridges from which a response is required. Only the RBridges listed in the scope field respond to the request. Other RBridges silently discard the request. Inclusion of the scope field is required to prevent receiving an excessive number of responses. The typical scenario of distribution tree verification or group verification involves verifying multicast connectivity to a selected set of end nodes as opposed to the entire network. Availability of the scope facilitates narrowing down the focus to only the RBridges of interest.
多目标树验证OAM帧被复制到每个中间RBridge的CPU，该中间RBridge是正在验证的分发树的一部分。多目标树验证消息的发起人指定需要响应的RBridge的范围。只有范围字段中列出的RBridge响应请求。其他rbridge会自动放弃该请求。需要包含范围字段，以防止收到过多的响应。分发树验证或组验证的典型场景涉及验证多播连接到选定的一组终端节点，而不是整个网络。范围的可用性有助于将重点缩小到感兴趣的领域。
Implementations MAY choose to rate-limit CPU-bound multicast traffic. As a result of rate-limiting or due to other congestion conditions, MTVM messages may be discarded from time to time by the intermediate RBridges, and the requester may be required to retransmit the request. Implementations SHOULD narrow the embedded scope of retransmission requests only to RBridges that have failed to respond.
实现可以选择限制CPU绑定的多播流量。由于速率限制或由于其他拥塞情况，中间rbridge可能会不时丢弃MTVM消息，并且请求者可能需要重新传输请求。实现应将重传请求的嵌入范围仅缩小到无法响应的RBridge。
The format of MTVM is identical to the Loopback Message format defined in Section 9 with the exception that the OpCode used is 67.
MTVM的格式与第9节中定义的环回消息格式相同，但使用的操作码为67。
The user is required, at a minimum, to specify either the distribution trees that need to be verified, the Multicast MAC address and VLAN/FGL, or the VLAN/FGL and Multicast Destination IP address. Alternatively, for more specific multicast flow verification, the user MAY specify more information, e.g., source MAC address, VLAN/FGL, and Destination and Source IP addresses. Implementations, at a minimum, must allow the user to specify a choice of distribution trees, Destination Multicast MAC address, and VLAN/FGL that needs to be verified. Although it is not mandatory, it is highly desired to provide an option to specify the scope. It should be noted that the source MAC address and some other parameters may not be specified if the backwards-compatibility method in Appendix A is used to identify the OAM frames.
用户至少需要指定需要验证的分发树、多播MAC地址和VLAN/FGL，或VLAN/FGL和多播目标IP地址。或者，对于更具体的多播流验证，用户可以指定更多信息，例如，源MAC地址、VLAN/FGL以及目的地和源IP地址。实现至少必须允许用户指定需要验证的分发树、目标多播MAC地址和VLAN/FGL的选择。虽然它不是强制性的，但是非常希望提供一个选项来指定范围。应注意，如果使用附录A中的向后兼容性方法来识别OAM帧，则可能不会指定源MAC地址和一些其他参数。
Default parameters MUST be used for unspecified parameters. Flow Entropy is constructed based on user-specified parameters and/or default parameters.
默认参数必须用于未指定的参数。基于用户指定的参数和/或默认参数构造流熵。
Based on user specified parameters, the originating RBridge does the following:
根据用户指定的参数，发起RBridge执行以下操作：
o Identifies the nickname that represents the multicast tree.
o 标识表示多播树的昵称。
o Obtains the applicable Hop Count value for the selected multicast tree.
o 获取所选多播树的适用跃点计数值。
o Constructs TRILL OAM message header and includes the Session Identification number. The Session Identification Number facilitates the originator mapping the response to the correct request.
o 构造TRILL OAM消息头并包含会话标识号。会话标识号有助于发端人将响应映射到正确的请求。
o Includes the TRILL OAM Application Identifier TLV, which MUST be included.
o 包括TRILL OAM应用程序标识符TLV，必须包括该标识符。
o Includes the OpCode Multicast Tree Verification Message (67).
o 包括操作码多播树验证消息（67）。
o Includes RBridge Scope TLV (68).
o 包括RBridge范围TLV（68）。
o Optionally, includes the following TLVs, where applicable:
o （可选）包括以下TLV（如适用）：
- Out-of-Band IP Address TLV (65)
- 带外IP地址TLV（65）
- Diagnostic Label TLV (66)
- 诊断标签TLV（66）
- Sender ID TLV (1)
- 发送者ID TLV（1）
o Specifies the Hop Count of the TRILL Data frame per user specification or alternatively utilizes the applicable Hop Count value if the TRILL Hop Count is not being specified by the user.
o 根据用户规范指定颤音数据帧的跃点计数，或者如果用户未指定颤音跃点计数，则使用适用的跃点计数值。
o Dispatches the OAM frame to the TRILL data plane to be ingressed for transmission.
o 将OAM帧分派到要进入传输的TRILL数据平面。
The RBridge may continue to retransmit the request at a periodic interval until either a response is received or the retransmission count expires. At each new retransmission, the Session Identification Number MUST be incremented. At each retransmission, the RBridge may further reduce the scope to the RBridges that it has not received a response from.
RBridge可以以周期性间隔继续重传请求，直到接收到响应或者重传计数到期。每次重新传输时，会话标识号必须递增。在每次重传时，RBridge可进一步将其未接收到来自的响应的范围缩小到RBridge。
Receiving RBridges identify multicast verification frames per the procedure explained in Section 3.2.
接收RBridge根据第3.2节中解释的程序识别多播验证帧。
The RBridge validates the frame and analyzes the scope RBridge list. If the RBridge Scope TLV is present and the local RBridge nickname is not specified in the scope list, it will silently discard the frame. If the local RBridge is specified in the scope list OR the RBridge Scope TLV is absent, the receiving RBridge proceeds with further processing as defined in Section 11.2.3.
RBridge验证帧并分析范围RBridge列表。如果存在RBridge作用域TLV，且作用域列表中未指定本地RBridge昵称，则它将自动放弃该帧。如果范围列表中指定了本地RBridge或RBridge范围TLV不存在，则接收RBridge继续进行第11.2.3节中定义的进一步处理。
Construction of the TRILL OAM response:
TRILL OAM响应的构建：
o The TRILL OAM application encodes the received TRILL Header and Flow Entropy in the Original Data Payload TLV and includes them in the OAM message.
o TRILL OAM应用程序在原始数据有效负载TLV中对接收到的TRILL报头和流熵进行编码，并将其包括在OAM消息中。
o Set the Return Code to zero (0) and Return Sub-code to zero (0). Update the TRILL OAM OpCode to 66 (Multi-destination Tree Verification Reply).
o 将返回代码设置为零（0），并将子代码设置为零（0）。将TRILL OAM操作码更新为66（多目标树验证回复）。
o Include following TLVs:
o 包括以下TLV：
- Previous RBridge Nickname TLV (69)
- 以前的RBridge昵称TLV（69）
- Reply Ingress TLV (5)
- 应答入口TLV（5）
- Interface Status TLV (4)
- 接口状态TLV（4）
- Next-Hop RBridge List TLV (70)
- 下一跳RBridge列表TLV（70）
- Sender ID TLV (1)
- 发送者ID TLV（1）
- Multicast Receiver Port Count TLV (71)
- 多播接收器端口计数TLV（71）
o If a VLAN/FGL cross-connect error is detected, set the "C" flag (Cross-Connect Error) in the TRILL OAM Application Identifier TLV.
o 如果检测到VLAN/FGL交叉连接错误，请在TRILL OAM应用程序标识符TLV中设置“C”标志（交叉连接错误）。
o If in-band response was requested, dispatch the frame to the TRILL data plane with request-originator RBridge nickname as the egress RBridge nickname.
o 如果请求带内响应，则将帧发送到TRILL数据平面，并将请求发起人RBridge昵称作为出口RBridge昵称。
o If out-of-band response was requested, dispatch the frame to the standard IP forwarding process.
o 如果请求带外响应，则将帧分派到标准IP转发过程。
Section 7 provides an overview of CCM Messages defined in [8021Q] and how they can be used within TRILL OAM. This section presents the application and theory of operations of CCM within the TRILL OAM framework. Readers are referred to [8021Q] for CCM message format and applicable TLV definitions and usages. Only the TRILL-specific aspects are explained below.
第7节概述了[8021Q]中定义的CCM消息，以及如何在TRILL OAM中使用这些消息。本节介绍了TRILL OAM框架中CCM的应用和操作原理。读者可参考[8021Q]了解CCM消息格式以及适用的TLV定义和用法。下面仅解释颤音的具体方面。
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.
在TRILL中，在任意两个给定MEP之间，可能存在多条潜在路径。然而，在[8021Q]中，在任何给定时间，任何两个MEP之间始终存在一条路径。[RFC6905]要求解决方案能够监控一条或多条路径上的连续性。
CCM Messages are uni-directional, such that there is no explicit response to a received CCM message. Connectivity status is indicated by setting the applicable flags (e.g., RDI) of the CCM messages transmitted by a MEP.
CCM消息是单向的，因此对接收到的CCM消息没有明确的响应。通过设置MEP传输的CCM消息的适用标志（例如RDI）来指示连接状态。
It is important that the solution presented in this document accomplishes the requirements specified in [RFC6905] within the framework of [8021Q] in a straightforward manner and with minimum changes. Section 8 defines multiple flows within the CCM object,
重要的是，本文件中提出的解决方案在[8021Q]的框架内以简单明了的方式和最少的变更完成[RFC6905]中规定的要求。第8节定义了CCM对象内的多个流，
each corresponding to a flow that a given MEP wishes to monitor. Hence, CCM, in multipath environments like TRILL, monitors per-flow connectivity and cross-connect errors.
每个对应于给定MEP希望监控的流。因此，在TRILL等多路径环境中，CCM监控每流连接和交叉连接错误。
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.
接收MEP不会交叉检查接收到的CCM是否属于来自发起RBridge的特定流。任何跟踪单个流状态的尝试都可能导致任何给定RBridge必须维护的状态信息量激增。
The obvious question arises: how does the originating RBridge know which flow or flows are at fault?
一个明显的问题出现了：原始RBridge如何知道哪些流有故障？
This is accomplished with a combination of the RDI flag in the CCM header, Flow Identifier TLV, and SNMP Notifications (Traps). Section 12.1 discusses the procedure.
这是通过CCM报头中的RDI标志、流标识符TLV和SNMP通知（陷阱）的组合来实现的。第12.1节讨论了该程序。
Each MEP transmits four CCM messages per each flow. ([8021Q] detects CCM fault when three consecutive CCM messages are lost). Each CCM message has a unique sequence number (Session ID) and unique flow-identifier. The flow-identifier is included in the OAM message via the Flow Identifier TLV.
每个MEP为每个流发送四条CCM消息。（[8021Q]在三条连续CCM消息丢失时检测CCM故障）。每个CCM消息都有一个唯一的序列号（会话ID）和唯一的流标识符。流标识符通过流标识符TLV包含在OAM消息中。
When a MEP notices a CCM timeout from a remote MEP (MEP-A), it sets the RDI flag on the next CCM message it generates. Additionally, it logs and sends an SNMP notification that contains the remote MEP Identification, flow-identifier, and the sequence number of the last CCM message it received, and, if available, the flow-identifier and the sequence number of the first CCM message it received after the failure. Each MEP maintains a unique flow-identifier per each flow; hence, the operator can easily identify flows that correspond to the specific flow-identifier.
当MEP从远程MEP（MEP-a）通知CCM超时时，它会在生成的下一条CCM消息上设置RDI标志。此外，它记录并发送一个SNMP通知，其中包含远程MEP标识、流标识符和它接收到的最后一条CCM消息的序列号，如果可用，还包括流标识符和它在故障后接收到的第一条CCM消息的序列号。每个MEP为每个流维护一个唯一的流标识符；因此，操作员可以容易地识别对应于特定流标识符的流。
The following example illustrates the above.
下面的示例说明了上述内容。
Assume there are two MEPs: MEP-A and MEP-B.
假设有两个MEP:MEP-A和MEP-B。
Assume there are three flows between MEP-A and MEP-B.
假设MEP-A和MEP-B之间有三个流。
Let's assume MEP-A allocates sequence numbers as follows:
假设MEP-A按如下方式分配序列号：
Flow-1 Sequence={1,2,3,4,13,14,15,16,.. } flow-identifier=(1)
Flow-1 Sequence={1,2,3,4,13,14,15,16,.. } flow-identifier=(1)
Flow-2 Sequence={5,6,7,8,17,18,19,20,.. } flow-identifier=(2)
Flow-2 Sequence={5,6,7,8,17,18,19,20,.. } flow-identifier=(2)
Flow-3 Sequence={9,10,12,11,21,22,23,24,.. } flow-identifier=(3)
Flow-3 Sequence={9,10,12,11,21,22,23,24,.. } flow-identifier=(3)
Let's assume Flow-2 is at fault.
让我们假设Flow-2有问题。
MEP-B receives CCM from MEP-A with sequence numbers 1, 2, 3, and 4 but did not receive 5, 6, 7, and 8. CCM timeout is set to three CCM intervals in [8021Q]. Hence, MEP-B detects the error at the 8th CCM message. At this time, the sequence number of the last good CCM message MEP-B has received from MEP-A is 4, and the flow-identifier of the last good CCM Message is (1). Hence, MEP-B will generate a CCM error SNMP notification with MEP-A, last good flow-identifier (1), and sequence number 4.
MEP-B从MEP-A接收序列号为1、2、3和4的CCM，但未接收序列号为5、6、7和8的CCM。在[8021Q]中，CCM超时设置为三个CCM间隔。因此，MEP-B在第8条CCM消息处检测到错误。此时，从MEP-A接收到的最后良好CCM消息MEP-B的序列号为4，并且最后良好CCM消息的流标识符为（1）。因此，MEP-B将生成带有MEP-a、最后一个良好流标识符（1）和序列号4的CCM错误SNMP通知。
When MEP-A switches to Flow-3 after transmitting Flow-2, MEP-B will start receiving CCM messages. In the foregoing example, it will be a CCM message with sequence numbers 9, 10, 11, 12, and 21 and so on. When in receipt of a new CCM message from a specific MEP, after a CCM timeout, the TRILL OAM will generate an SNMP Notification of CCM resume with remote MEP-ID, the first valid flow-identifier, and the sequence number after the CCM timeout. In the foregoing example, it is MEP-A, flow-identifier (3), and sequence number 9.
当MEP-A在传输Flow-2后切换到Flow-3时，MEP-B将开始接收CCM消息。在前面的示例中，它将是序列号为9、10、11、12和21等的CCM消息。当接收到来自特定MEP的新CCM消息时，在CCM超时后，TRILL OAM将生成CCM恢复的SNMP通知，其中包含远程MEP-ID、第一个有效流标识符和CCM超时后的序列号。在前面的示例中，它是MEP-A、流标识符（3）和序列号9。
The remote MEP list under the CCM MIB Object is augmented to contain "Last Sequence Number", flow-identifier, and "CCM Timeout" variables. "Last Sequence Number" and flow-identifier are updated every time a CCM is received from a remote MEP. The CCM Timeout variable is set when the CCM timeout occurs and is cleared when a CCM is received.
CCM MIB对象下的远程MEP列表被扩充为包含“最后序列号”、流标识符和“CCM超时”变量。每次从远程MEP接收到CCM时，“最后序列号”和流标识符都会更新。CCM Timeout变量在CCM超时发生时设置，并在收到CCM时清除。
The originator RBridge takes the following actions:
发起人RBridge采取以下行动：
o Derives the Flow Entropy field based on flow-entropy information specified in the CCM Management object.
o 根据CCM管理对象中指定的流熵信息导出流熵场。
o Constructs the TRILL CCM OAM header as specified in [8021Q].
o 按照[8021Q]中的规定构造TRILL CCM OAM标头。
o The TRILL OAM Application Identifier TLV MUST be included as the first TLV with the flags set to applicable values.
o TRILL OAM应用程序标识符TLV必须作为第一个TLV包含，并将标志设置为适用值。
o Includes other TLVs specified in [8021Q].
o 包括[8021Q]中规定的其他TLV。
o Includes the following optional TLV, where applicable:
o 包括以下可选TLV（如适用）：
- Sender ID TLV (1)
- 发送者ID TLV（1）
o Specifies the Hop Count of the TRILL Data frame per user specification or utilize an applicable Hop Count value.
o 根据用户规范指定颤音数据帧的跃点计数，或使用适用的跃点计数值。
o Dispatches the OAM frame to the TRILL data plane for transmission.
o 将OAM帧分派到TRILL数据平面进行传输。
An RBridge transmits a total of four requests, each at CCM retransmission interval. At each transmission, the Session Identification number MUST be incremented by one.
RBridge总共发送四个请求，每个请求以CCM重传间隔发送。在每次传输时，会话标识号必须增加1。
At the 5th retransmission interval, the Flow Entropy of the CCM packet is updated to the next flow-entropy information specified in the CCM Management object. If the current Flow Entropy is the last Flow Entropy specified, move to the first Flow Entropy specified and continue the process.
在第5重传间隔处，CCM分组的流熵被更新为CCM管理对象中指定的下一流熵信息。如果当前流熵是指定的最后一个流熵，则移动到指定的第一个流熵并继续该过程。
Intermediate RBridges forward the frame as a normal data frame; no special handling is required.
中间帧作为正常数据帧转发该帧；无需特殊处理。
If the CCM Message is addressed to the local RBridge or multicast and satisfies the OAM identification methods specified in Section 3.2, then the RBridge data plane forwards the message to the CPU for further processing.
如果CCM消息发往本地RBridge或多播，并且满足第3.2节中规定的OAM识别方法，则RBridge数据平面将消息转发给CPU进行进一步处理。
The TRILL OAM application layer further validates the received OAM frame by examining the presence of OAM Ethertype at the end of the Flow Entropy. Frames that do not contain OAM Ethertype at the end of the Flow Entropy MUST be discarded.
TRILL OAM应用层通过检查流熵末尾是否存在OAM Ethertype来进一步验证接收到的OAM帧。必须丢弃流熵末尾不包含OAM Ethertype的帧。
The TRILL OAM application layer then validates the MD-Level and pass the packet to the OpCode demultiplexer. The OpCode demultiplexer delivers CCM packets to the CCM process.
TRILL OAM应用层随后验证MD级别，并将数据包传递给操作码解复用器。操作码解复用器将CCM数据包传送到CCM进程。
The CCM process performs the processing specified in [8021Q].
CCM进程执行[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.
此外，CCM处理使用接收到的CCM分组的序列号更新CCM管理对象。注意：上次接收到的CCM序列号和CCM超时将根据每个远程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.
如果发送远程MEP的CCM超时为真，则清除CCM管理对象中的CCM超时，并按照上述规定生成SNMP通知。
TRILL OAM allows fragmented reply messages. In case of fragmented replies, all parts of the reply MUST follow the procedure defined in this section.
TRILL OAM允许分段回复消息。如果答复不完整，则答复的所有部分都必须遵循本节中定义的程序。
The same Session Identification Number MUST be included in all related fragments of the same message.
同一消息的所有相关片段中必须包含相同的会话标识号。
The TRILL OAM Application Identifier TLV MUST be included, with the Fragment-ID field monotonically increasing with each fragment transmitted with the appropriate Final flag field. The Final flag MUST only be equal to one on the final fragment of the reply.
必须包括TRILL OAM应用程序标识符TLV，片段ID字段随着使用适当的最终标志字段传输的每个片段而单调增加。Final标志必须仅等于回复的最后一个片段上的一个标志。
On the receiver, the process MUST order the fragments based on the Fragment-ID. Any fragments received after the final fragment MUST be discarded. Messages with incomplete fragments (i.e., messages with one or missing fragments after the receipt of the fragment with the final flag set) MUST be discarded as well.
在接收器上，进程必须基于Fragment-ID对片段进行排序。必须丢弃在最终片段之后接收到的任何片段。具有不完整片段的消息（即，在接收到带有最终标志集的片段后，具有一个或缺失片段的消息）也必须丢弃。
If the number of fragments exceeds the maximum supported fragments (255), then the Return Code of the reply message MUST be set to 1 (Reply message), and the Return Sub-code MUST be set to 1 (Fragment limit exceeded).
如果片段数超过了支持的最大片段数（255），则回复消息的返回代码必须设置为1（回复消息），返回子代码必须设置为1（超出了片段限制）。
Forged OAM packets could cause false error or failure indications, mask actual errors or failures, or be used for denial of service. Source addresses for messages can be forged and the out-of-band reply facility (see Section 8.4.4) provides for explicitly supplying the address for replies. For protection against forged OAM packets, the Authentication TLV (see Section 8.4.13) can be used in an OAM message in TRILL. This TLV is virtually identical to the IS-IS Authentication TLV specified in [IS-IS] and depends on IS-IS keying material and the current state of IS-IS keying as discussed in [KARPISIS] and [RFC5310]. In particular, there is currently no standardized IS-IS automated key management.
伪造的OAM数据包可能导致错误或故障指示，掩盖实际错误或故障，或用于拒绝服务。消息的源地址可以伪造，带外回复功能（见第8.4.4节）提供明确的回复地址。为了防止伪造的OAM数据包，可以在TRILL格式的OAM消息中使用认证TLV（见第8.4.13节）。该TLV实际上与[is-is]中规定的is-is认证TLV相同，取决于is-is密钥材料以及[KARPISIS]和[RFC5310]中讨论的is-is密钥的当前状态。特别是，目前还没有标准化的is-is自动密钥管理。
Of course, authentication is ineffective unless verified and ineffective against senders who have the keying material needed to produce OAM messages that will pass authentication checks. Implementations MUST implement rate-limiting functionality to protect against exploitation of OAM messages as a means of denial-of-service attacks. Aggressive rate-limiting may trigger false positive errors against CCM and LBM-based session monitoring.
当然，身份验证是无效的，除非对具有生成将通过身份验证检查的OAM消息所需的密钥材料的发件人进行验证和无效。实现必须实现速率限制功能，以防止OAM消息被利用作为拒绝服务攻击的手段。积极的速率限制可能会触发针对基于CCM和LBM的会话监视的误报错误。
Even with authentication, replay of authenticated messages may be possible. There are four types of messages: Continuity Check (CCM), Loopback, Path Trace, and Multi-destination Tree Verification (MTVM). In the case of CCM messages, sequence numbers are required (see Section 12.1) that can protect against replay. In the case of Loopback Messages (see Section 9.1), a Loopback Transaction Identifier is included that, as required by [8021Q], is incremented with each transmission and can detect replays. PTMs (see Section 10) and MTVMs (see Section 11.1) are specified to have the same format as Loopback Messages (although with different OpCodes), so they also have an identifier incremented with each transmission that can detect replays. Thus, all TRILL OAM messages have a field that can be used for replay protection.
即使使用身份验证，也可以重播经过身份验证的消息。有四种类型的消息：连续性检查（CCM）、环回、路径跟踪和多目标树验证（MTVM）。对于CCM消息，需要序列号（见第12.1节），以防止重播。在环回消息的情况下（见第9.1节），包括一个环回事务标识符，根据[8021Q]的要求，该标识符随每次传输而递增，并可检测重播。PTM（见第10节）和MTVM（见第11.1节）被指定为与环回消息具有相同的格式（尽管使用不同的操作码），因此它们的标识符也随着每次传输而增加，可以检测重播。因此，所有TRILL OAM消息都有一个可用于重播保护的字段。
For general TRILL-related security considerations, please refer to [RFC6325].
有关TRILL相关的一般安全注意事项，请参阅[RFC6325]。
[8021Q] requires that the MEP filters or passes through OAM messages based on the MD-Level. The MD-Level is embedded deep in the OAM message. Hence, conventional methods of frame filtering may not be able to filter frames based on the MD-Level. As a result, OAM messages that must be dropped due to MD-Level mismatch may leak into a TRILL domain with a different MD-Level.
[8021Q]要求MEP根据MD级别过滤或传递OAM消息。MD级别深入嵌入到OAM消息中。因此，传统的帧滤波方法可能无法基于MD级对帧进行滤波。因此，由于MD级别不匹配而必须丢弃的OAM消息可能会泄漏到具有不同MD级别的TRILL域中。
This leaking may not cause any functionality loss. The receiving MEP/MIP is required to validate the MD-level prior to acting on the message. Any frames received with an incorrect MD-Level need to be dropped.
此泄漏可能不会导致任何功能损失。接收MEP/MIP需要在对消息采取行动之前验证MD级别。需要删除接收到的MD级别不正确的任何帧。
Generally, a single operator manages each TRILL campus; hence, there is no risk of security exposure. However, in the event of multi-operator deployments, operators should be aware of possible exposure of device-specific information, and appropriate measures must be taken.
通常，一个运营商管理每个TRILL园区；因此，不存在安全风险。但是，在多运营商部署的情况下，运营商应意识到设备特定信息的可能暴露，并且必须采取适当的措施。
It is also important to note that the MPLS OAM framework [RFC4379] does not include the concept of domains and OAM filtering based on operators. It is our opinion that the lack of OAM frame filtering based on domains does not introduce significant functional deficiency or security risk.
还需要注意的是，MPLS OAM框架[RFC4379]不包括域和基于运营商的OAM过滤的概念。我们认为，缺乏基于域的OAM帧过滤不会带来明显的功能缺陷或安全风险。
It is possible to mandate requiring different credentials to use different OAM functions or capabilities within a specific OAM function. Implementations may consider grouping users to different security clearance levels and restricting functions and capabilities to different clearance levels. However, exact implementation details of such a framework are outside the scope of this document.
可以强制要求使用不同的凭证来使用不同的OAM功能或特定OAM功能中的功能。实现可以考虑将用户分组到不同的安全清除级别，并将功能和能力限制到不同的清除级别。然而，这种框架的具体实施细节不在本文件的范围之内。
IANA has made the assignments described below.
IANA已完成以下任务。
Two TRILL-VER sub-TLV Capability Flags (see Section 3.3) have been assigned as follows:
两个TRILL-VER子TLV能力标志（见第3.3节）分配如下：
Bit Description Reference
--- ----------- ---------
2 OAM capable RFC 7455
3 Backwards-compatible OAM RFC 7455
Bit Description Reference
--- ----------- ---------
2 OAM capable RFC 7455
3 Backwards-compatible OAM RFC 7455
Four OpCodes have been assigned from the "CFM OAM IETF OpCodes" sub-registry as follows:
从“CFM OAM IETF操作码”子注册表分配了四个操作码，如下所示：
Value Assignment Reference
----- ---------- ---------
64 Path Trace Reply RFC 7455
65 Path Trace Message RFC 7455
66 Multi-destination Tree Verification Reply RFC 7455
67 Multi-destination Tree Verification Message RFC 7455
Value Assignment Reference
----- ---------- ---------
64 Path Trace Reply RFC 7455
65 Path Trace Message RFC 7455
66 Multi-destination Tree Verification Reply RFC 7455
67 Multi-destination Tree Verification Message RFC 7455
Eleven TLV Types have been assigned from the "CFM OAM IETF TLV Types" sub-registry as follows:
从“CFM OAM IETF TLV类型”子注册表分配了11种TLV类型，如下所示：
Value Assignment Reference
----- ---------- ---------
64 TRILL OAM Application Identifier TLV RFC 7455
65 Out-of-Band Reply Address TLV RFC 7455
66 Diagnostic Label TLV RFC 7455
67 Original Data Payload TLV RFC 7455
68 RBridge Scope TLV RFC 7455
69 Previous RBridge Nickname TLV RFC 7455
70 Next-Hop RBridge List TLV RFC 7455
71 Multicast Receiver Port Count TLV RFC 7455
72 Flow Identifier TLV RFC 7455
73 Reflector Entropy TLV RFC 7455
74 Authentication TLV RFC 7455
Value Assignment Reference
----- ---------- ---------
64 TRILL OAM Application Identifier TLV RFC 7455
65 Out-of-Band Reply Address TLV RFC 7455
66 Diagnostic Label TLV RFC 7455
67 Original Data Payload TLV RFC 7455
68 RBridge Scope TLV RFC 7455
69 Previous RBridge Nickname TLV RFC 7455
70 Next-Hop RBridge List TLV RFC 7455
71 Multicast Receiver Port Count TLV RFC 7455
72 Flow Identifier TLV RFC 7455
73 Reflector Entropy TLV RFC 7455
74 Authentication TLV RFC 7455
IANA has assigned a unicast and a multicast MAC address under the IANA Organizationally Unique Identifier (OUI) for identification of OAM packets as discussed for the backwards-compatibility method (Appendix A.2) and based on the request template in Appendix C. The assigned addresses are 00-00-5E-90-01-00 (unicast) and 01-00-5E-90-01-00 (multicast).
IANA在IANA组织唯一标识符（OUI）下分配了单播和多播MAC地址，用于识别OAM数据包，如向后兼容方法（附录a.2）所述，并基于附录C中的请求模板。分配的地址为00-00-5E-90-01-00（单播）和01-00-5E-90-01-00（多播）.
IANA has created the "TRILL OAM Return Codes" registry within the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry and a separate sub-code sub-registry for each Return Code as shown below:
IANA已在“大量链接透明互连（TRILL）参数”注册表中创建了“TRILL OAM返回代码”注册表，并为每个返回代码创建了单独的子代码子注册表，如下所示：
Registry: TRILL OAM Return Codes
注册表：TRILL OAM返回代码
Registration Procedure: Standards Action
登记程序：标准行动
Return Code Assignment References
----------- ---------- ----------
0 Request message RFC 7455
1 Reply message RFC 7455
2-255 Unassigned RFC 7455
Return Code Assignment References
----------- ---------- ----------
0 Request message RFC 7455
1 Reply message RFC 7455
2-255 Unassigned RFC 7455
Sub-Registry: Sub-codes for TRILL OAM Return Code 0
子注册表：TRILL OAM返回代码0的子代码
Registration Procedure: Standards Action
登记程序：标准行动
Sub-code Assignment References
-------- ---------- ----------
0 Valid request RFC 7455
1-255 Unassigned RFC 7455
Sub-code Assignment References
-------- ---------- ----------
0 Valid request RFC 7455
1-255 Unassigned RFC 7455
Sub-Registry: Sub-codes for TRILL OAM Return Code 1
子注册表：TRILL OAM返回代码1的子代码
Registration Procedure: Standards Action
登记程序：标准行动
Sub-code Assignment References
-------- ---------- ----------
0 Valid response RFC 7455
1 Fragment limit exceeded RFC 7455
2 Intermediate RBridge RFC 7455
3-255 Unassigned RFC 7455
Sub-code Assignment References
-------- ---------- ----------
0 Valid response RFC 7455
1 Fragment limit exceeded RFC 7455
2 Intermediate RBridge RFC 7455
3-255 Unassigned RFC 7455
IANA has allocated 16396 as the Address Family Number for TRILL nickname.
IANA已分配16396作为TRILL昵称的地址系列号。
[8021Q] IEEE, "IEEE Standard for Local and metropolitan area networks -- Bridges and Bridged Networks", IEEE Std 802.1Q, December 2014.
[8021Q]IEEE，“局域网和城域网的IEEE标准——网桥和桥接网络”，IEEE标准802.1Q，2014年12月。
[IS-IS] ISO/IEC, "Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, 2002.
[IS-IS]ISO/IEC，“信息技术——系统间电信和信息交换——与提供无连接模式网络服务协议（ISO 8473）结合使用的中间系统到中间系统域内路由信息交换协议”，ISO/IEC 10589:2002，第二版，2002
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009, <http://www.rfc-editor.org/info/rfc5310>.
[RFC5310]Bhatia，M.，Manral，V.，Li，T.，Atkinson，R.，White，R.，和M.Fanto，“IS-IS通用密码认证”，RFC 53102009年2月<http://www.rfc-editor.org/info/rfc5310>.
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011, <http://www.rfc-editor.org/info/rfc6325>.
[RFC6325]Perlman，R.，Eastlake 3rd，D.，Dutt，D.，Gai，S.，和A.Ghanwani，“路由桥（RBridges）：基本协议规范”，RFC 63252011年7月<http://www.rfc-editor.org/info/rfc6325>.
[RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, May 2014, <http://www.rfc-editor.org/info/rfc7172>.
[RFC7172]Eastlake 3rd，D.，Zhang，M.，Agarwal，P.，Perlman，R.，和D.Dutt，“大量链路的透明互连（TRILL）：细粒度标记”，RFC 7172，2014年5月<http://www.rfc-editor.org/info/rfc7172>.
[KARPISIS] Chunduri, U., Tian, A., and W. Lu, "KARP IS-IS security analysis", Work in Progress, draft-ietf-karp-isis-analysis-04, March 2015.
[KARPISIS]Chunduri，U.，Tian，A.，和W.Lu，“KARP IS-IS安全分析”，正在进行的工作，草案-ietf-KARP-isis-analysis-042015年3月。
[RFC4379] Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005, <http://www.rfc-editor.org/info/rfc4279>.
[RFC4379]Eronen，P.，Ed.，和H.Tschofenig，Ed.，“用于传输层安全（TLS）的预共享密钥密码套件”，RFC 4279，2005年12月<http://www.rfc-editor.org/info/rfc4279>.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, June 2011, <http://www.rfc-editor.org/info/rfc6291>.
[RFC6291]Andersson，L.，van Helvoort，H.，Bonica，R.，Romascanu，D.，和S.Mansfield，“IETF中“OAM”首字母缩写词的使用指南”，BCP 161，RFC 62912011年6月<http://www.rfc-editor.org/info/rfc6291>.
[RFC6361] Carlson, J. and D. Eastlake 3rd, "PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol", RFC 6361, August 2011, <http://www.rfc-editor.org/info/rfc6361>.
[RFC6361]Carlson，J.和D.Eastlake 3rd，“大量链路的PPP透明互连（TRILL）协议控制协议”，RFC 63612011年8月<http://www.rfc-editor.org/info/rfc6361>.
[RFC6905] Senevirathne, T., Bond, D., Aldrin, S., Li, Y., and R. Watve, "Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL)", RFC 6905, March 2013, <http://www.rfc-editor.org/info/rfc6905>.
[RFC6905]Senevirathne，T.，Bond，D.，Aldrin，S.，Li，Y.，和R.Watve，“大量链路透明互连（TRILL）中的操作、管理和维护（OAM）要求”，RFC 69052013年3月<http://www.rfc-editor.org/info/rfc6905>.
[RFC7174] Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake 3rd, "Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework", RFC 7174, May 2014, <http://www.rfc-editor.org/info/rfc7174>.
[RFC7174]Salam，S.，Senevirathne，T.，Aldrin，S.，和D.Eastlake 3rd，“大量链路的透明互连（TRILL）运营、管理和维护（OAM）框架”，RFC 7174，2014年5月<http://www.rfc-editor.org/info/rfc7174>.
[RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, May 2014, <http://www.rfc-editor.org/info/rfc7176>.
[RFC7176]Eastlake 3rd，D.，Senevirathne，T.，Ghanwani，A.，Dutt，D.，和A.Banerjee，“IS-IS大量链路的透明互连（TRILL）使用”，RFC 7176，2014年5月<http://www.rfc-editor.org/info/rfc7176>.
[RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support", RFC 7178, May 2014, <http://www.rfc-editor.org/info/rfc7178>.
[RFC7178]Eastlake 3rd，D.，Manral，V.，Li，Y.，Aldrin，S.，和D.Ward，“大量链路的透明互连（TRILL）：RBridge信道支持”，RFC 7178，2014年5月<http://www.rfc-editor.org/info/rfc7178>.
[RFC7179] Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and C. Bestler, "Transparent Interconnection of Lots of Links (TRILL): Header Extension", RFC 7179, May 2014, <http://www.rfc-editor.org/info/rfc7179>.
[RFC7179]Eastlake 3rd，D.，Ghanwani，A.，Manral，V.，Li，Y.，和C.Bestler，“大量链路的透明互连（TRILL）：报头扩展”，RFC 7179，2014年5月<http://www.rfc-editor.org/info/rfc7179>.
[RFC7180] Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7180, May 2014, <http://www.rfc-editor.org/info/rfc7180>.
[RFC7180]Eastlake 3rd，D.，Zhang，M.，Ghanwani，A.，Manral，V.，和A.Banerjee，“大量链路的透明互连（TRILL）：澄清、更正和更新”，RFC 71802014年5月<http://www.rfc-editor.org/info/rfc7180>.
[RFC7456] Mizrahi, T., Senevirathne, T., Salam, S., Kumar, D., and D. Eastlake 3rd, "Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL)", RFC 7456, March 2015, <http://www.rfc-editor.org/info/rfc7456>.
[RFC7456]Mizrahi，T.，Senevirathne，T.，Salam，S.，Kumar，D.，和D.Eastlake 3rd，“大量链路透明互连中的损耗和延迟测量（TRILL）”，RFC 74562015年3月<http://www.rfc-editor.org/info/rfc7456>.
[TRILLOAMMIB] Kumar, D., Salam, S., and T. Senevirathne, "TRILL OAM MIB", Work in Progress, draft-deepak-trill-oam-mib-01, October 2013.
[TRILLOAMMIB]Kumar，D.，Salam，S.，和T.Senevirathne，“TRILL OAM MIB”，正在进行的工作，草稿-deepak-TRILL-OAM-MIB-012013年10月。
[Y1731] ITU-T, "OAM functions and mechanisms for Ethernet based networks", ITU-T Recommendation G.8013/Y.1731, November 2013.
[Y1731]ITU-T，“基于以太网的网络的OAM功能和机制”，ITU-T建议G.8013/Y.17311913年11月。
The methodology presented in this document is in-line with the framework defined in [8021Q] for providing fault management coverage. However, in practice, some TRILL platforms may not have the capabilities to support some of the required techniques. In this appendix, we present a method that allows RBridges, which do not have the required hardware capabilities, to participate in the TRILL OAM solution.
本文件中介绍的方法与[8021Q]中定义的用于提供故障管理覆盖范围的框架一致。然而，在实践中，一些TRILL平台可能不具备支持某些所需技术的能力。在本附录中，我们提出了一种方法，允许不具备所需硬件功能的RBridge参与TRILL OAM解决方案。
There are two broad areas to be considered: 1) the Maintenance Point (MEP/MIP) Model and 2) data-plane encoding and frame identification.
有两个广泛的领域需要考虑：1）维护点（MEP/MIP）模型和2）数据平面编码和帧识别。
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.
为了向后兼容，MEP和MIP位于CPU中。这将被称为“中枢脑”模型，而不是“港口脑”模型。
In the "central brain" model, an RBridge using either Access Control Lists (ACLs) or some other method forwards qualifying OAM messages to the CPU. The CPU then performs the required processing and multiplexing to the correct MP (Maintenance Point).
在“中央大脑”模型中，使用访问控制列表（ACL）或其他方法的RBridge将符合条件的OAM消息转发给CPU。然后，CPU执行所需的处理并多路复用到正确的MP（维护点）。
Additionally, RBridges MUST have the capability to prevent the leaking of OAM packets, as specified in [RFC6905].
此外，根据[RFC6905]中的规定，RBridges必须具有防止OAM数据包泄漏的能力。
The backwards-compatibility method presented in this section defines methods to identify OAM frames when implementations do not have capabilities to utilize the TRILL OAM Alert flag presented earlier in this document to identify OAM frames in the hardware.
本节中介绍的向后兼容性方法定义了当实现没有能力利用本文档前面介绍的TRILL OAM警报标志来识别硬件中的OAM帧时，识别OAM帧的方法。
It is assumed that ECMP path selection of non-IP flows utilizes MAC DA, MAC SA, and VLAN; IP flows utilize IP DA, IP SA, TCP/UDP port numbers, and other Layer 3 and Layer 4 information. The well-known fields to identify OAM flows are chosen such that they mimic the ECMP selection of the actual data along the path. However, it is important to note that there may be implementations that would utilize these well-known fields for ECMP selections. Hence, implementations that support OAM SHOULD move to utilizing the TRILL Alert flag, as soon as possible, and methods presented here SHOULD be used only as an interim solution.
假设非IP流的ECMP路径选择利用MAC DA、MAC SA和VLAN；IP流利用IP DA、IP SA、TCP/UDP端口号和其他第3层和第4层信息。选择用于识别OAM流的众所周知的字段，以便它们模拟沿路径的实际数据的ECMP选择。然而，需要注意的是，可能有一些实现会利用这些众所周知的字段进行ECMP选择。因此，支持OAM的实现应该尽快转向使用TRILL Alert标志，这里介绍的方法应该仅用作临时解决方案。
Identification methods are divided in to four broader groups:
识别方法分为四大类：
1. Identification of Unicast non-IP OAM Flows,
1. 识别单播非IP OAM流，
2. Identification of Multicast non-IP OAM Flows,
2. 多播非IP OAM流的标识，
3. Identification of Unicast IP OAM Flows, and
3. 识别单播IP OAM流，以及
4. Identification of Multicast IP OAM Flows.
4. 多播IP OAM流的标识。
As presented in Figure 24, based on the flow type (as defined above), implementations are required to use a well-known value in either the Inner.MacSA field or OAM Ethertype field to identify OAM flows.
如图24所示，基于流类型（如上所述），实现需要在Inner.MacSA字段或OAM Ethertype字段中使用已知值来标识OAM流。
A receiving RBridge identifies OAM flows based on the presence of the well-known values in the specified fields. Additionally, for unicast flows, the egress RBridge nickname of the packet MUST match that of the local RBridge, or for multicast flows, the TRILL Header multicast ("M") flag MUST be set.
接收RBridge基于指定字段中已知值的存在来识别OAM流。此外，对于单播流，分组的出口RBridge昵称必须与本地RBridge的昵称匹配，或者对于多播流，必须设置TRILL报头多播（“M”）标志。
Unicast OAM flows that qualify for local processing MUST be redirected to the OAM process and MUST NOT be forwarded (to prevent leaking of the packet out of the TRILL campus).
符合本地处理条件的单播OAM流必须重定向到OAM进程，并且不得转发（以防止数据包泄漏出TRILL园区）。
A copy of multicast OAM flows that qualify for local processing MUST be sent to the OAM process, and the packets MUST be forwarded along the normal path. Additionally, methods MUST be in place to prevent multicast packets from leaking out of the TRILL campus.
必须将符合本地处理条件的多播OAM流的副本发送到OAM进程，并且必须沿正常路径转发数据包。此外，必须有防止多播数据包从TRILL校园泄漏的方法。
Figure 24 summarizes the identification of different OAM frames from data frames.
图24总结了从数据帧识别不同的OAM帧。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Flow Entropy |Inner.MacSA |OAM Ethertype |Egress |
| | | |nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Unicast no IP | N/A |Match |Match |
| | | | |
|Multicast no IP| N/A |Match |N/A |
| | | | |
|Unicast IP | Match |N/A |Match |
| | | | |
|Multicast IP | Match |N/A |N/A |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Flow Entropy |Inner.MacSA |OAM Ethertype |Egress |
| | | |nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Unicast no IP | N/A |Match |Match |
| | | | |
|Multicast no IP| N/A |Match |N/A |
| | | | |
|Unicast IP | Match |N/A |Match |
| | | | |
|Multicast IP | Match |N/A |N/A |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: Identification of TRILL OAM Frames
图24：TRILL OAM帧的识别
The unicast and multicast Inner.MacSAs used for the unicast and multicast IP cases, respectively, are 00-00-5E-90-01-00 and 01-00-5E-90-01-00. These have been assigned per the request in Appendix C.
用于单播和多播IP情况的单播和多播Inner.macsa分别为00-00-5E-90-01-00和01-00-5E-90-01-00。已根据附录C中的要求分配这些。
It is important to note that all RBridges MUST generate OAM flows with the "A" flag set and CFM Ethertype "0x8902" at the Flow Entropy off-set. However, well-known values MUST be utilized as part of the flow-entropy when generating OAM messages destined for older RBridges that are compliant to the backwards-compatibility method defined in this appendix.
需要注意的是，所有RBridge都必须生成带有“A”标志集且CFM Ethertype“0x8902”处于流熵偏移的OAM流。但是，当生成针对旧RBridge的OAM消息时，必须将已知值用作流熵的一部分，这些旧RBridge符合本附录中定义的向后兼容性方法。
CFM, as defined in [8021Q], requires configuration of several parameters before the protocol can be used. These parameters include MAID, Maintenance Domain Level (MD-Level), and MEP-IDs. The Base Mode for TRILL OAM defined here facilitates ease of use and provides out-of-the-box plug-and-play capabilities, supporting the operational and manageability considerations described in Section 6 of [RFC7174].
[8021Q]中定义的CFM要求在使用协议之前配置多个参数。这些参数包括MAID、维护域级别（MD级别）和MEP ID。此处定义的TRILL OAM的基本模式便于使用，并提供现成的即插即用功能，支持[RFC7174]第6节中描述的操作和可管理性注意事项。
All RBridges that support TRILL OAM MUST support the Base Mode operation.
所有支持TRILL OAM的RBridge必须支持基本模式操作。
All RBridges MUST create a default MA with MAID as specified herein.
所有RBridges必须按照本文的规定使用MAID创建默认MA。
MAID [8021Q] has a flexible format and includes two parts: Maintenance Domain Name and Short MA Name. In the Base Mode operation, the value of the Maintenance Domain Name must be the character string "TrillBaseMode" (excluding the quotes). In the Base Mode operation, the Short MA Name format is set to a 2-octet integer format (value 3 in Short MA Format field) and Short MA Name set to 65532 (0xFFFC).
MAID[8021Q]格式灵活，包括两部分：维护域名和短MA名称。在基本模式操作中，维护域名的值必须是字符串“TrillBaseMode”（不包括引号）。在基本模式操作中，短MA名称格式设置为2八位整数格式（短MA格式字段中的值3），短MA名称设置为65532（0xFFFC）。
The default MA belongs to MD-Level 3.
默认MA属于MD级别3。
In the Base Mode of operation, each RBridge creates a single UP MEP associated with a virtual OAM port with no physical layer (NULL PHY). The MEP-ID associated with this MEP is the 2-octet RBridge nickname.
在基本操作模式下，每个RBridge创建一个与没有物理层（空PHY）的虚拟OAM端口关联的单一UP MEP。与此MEP关联的MEP-ID是2-octet RBridge昵称。
By default, all RBridges operating in Base Mode for TRILL OAM are able to initiate LBM, PTM, and other OAM tools with no configuration.
默认情况下，在TRILL OAM的基本模式下运行的所有RBridge都能够在没有配置的情况下启动LBM、PTM和其他OAM工具。
Implementations MAY provide default flow-entropy to be included in OAM messages. Content of the default flow-entropy is outside the scope of this document.
实现可以提供要包括在OAM消息中的默认流熵。默认流熵的内容超出了本文档的范围。
Figure 25 depicts encoding of MAID within CCM messages.
图25描述了CCM消息中的MAID编码。
+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Field Name |Size |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Maintenance | 1 |
|Domain Format | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Maintenance | 2 |
|Domain Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Maintenance | variable|
|Domain Name | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Short MA | 1 |
|Name Format | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Short MA | 2 |
|Name Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Short MA | variable|
|Name | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Padding | Variable|
+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Field Name |Size |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Maintenance | 1 |
|Domain Format | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Maintenance | 2 |
|Domain Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Maintenance | variable|
|Domain Name | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Short MA | 1 |
|Name Format | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Short MA | 2 |
|Name Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Short MA | variable|
|Name | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Padding | Variable|
+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: MAID Structure as Defined in [8021Q]
图25:[8021Q]中定义的MAID结构
Maintenance Domain Name Format: set to value 4
维护域名格式：设置为值4
Maintenance Domain Name Length: set to value 13
维护域名长度：设置为值13
Maintenance Domain Name: set to TrillBaseMode
维护域名：设置为TrillBaseMode
Short MA Name Format: set to value 3
短MA名称格式：设置为值3
Short MA Name Length: set to value 2
短MA名称长度：设置为值2
Short MA Name: set to FFFC
短MA名称：设置为FFFC
Padding: set of zero up to 48 octets of total length of the MAID
填充：一组零，最多48个八位字节的总长度
Please refer to [8021Q] for details.
详情请参阅[8021Q]。
Applicant Name: IETF TRILL Working Group
申请人名称：IETF TRILL工作组
Applicant Email: tsenevir@cisco.com
申请人电邮：tsenevir@cisco.com
Applicant Telephone: +1-408-853-2291
申请人电话：+1-408-853-2291
Use Name: TRILL OAM
使用名称：TRILL OAM
Document: RFC 7455
文件：RFC 7455
Specify whether this is an application for EUI-48 or EUI-64 identifiers: EUI-48
指定这是EUI-48还是EUI-64标识符的应用程序：EUI-48
Size of Block requested: 1
请求的块大小：1
Specify multicast, unicast, or both: Both
指定多播、单播或两者：两者
Acknowledgments
致谢
Work on this document was largely inspired by the directions provided by Stewart Bryant in finding a common OAM solution between SDOs.
本文档的工作主要受Stewart Bryant在SDO之间寻找通用OAM解决方案的指导启发。
Acknowledgments are due for many who volunteered to review this document, notably, Jari Arkko, Adrian Farrel, Pete Resnick, Stephen Farrell, Dan Romascanu, Gayle Nobel, and Tal Mizrahi.
感谢许多自愿审查本文件的人，特别是贾里·阿尔科、阿德里安·法雷尔、皮特·雷斯尼克、斯蒂芬·法雷尔、丹·罗马斯坎努、盖尔·诺贝尔和塔尔·米兹拉希。
Special appreciation is due to Dinesh Dutt for his support and encouragement, especially during the initial discussion phase of TRILL OAM.
特别感谢Dinesh Dutt的支持和鼓励，特别是在TRILL OAM的初始讨论阶段。
Authors' Addresses
作者地址
Tissa Senevirathne Cisco Systems 375 East Tasman Drive San Jose, CA 95134 United States
美国加利福尼亚州圣何塞东塔斯曼大道375号，邮编95134
Phone: +1 408-853-2291
EMail: tsenevir@cisco.com
Phone: +1 408-853-2291
EMail: tsenevir@cisco.com
Norman Finn Cisco Systems 510 McCarthy Blvd Milpitas, CA 95035 United States
诺曼·芬恩思科系统公司美国加利福尼亚州米尔皮塔斯麦卡锡大道510号，邮编95035
EMail: nfinn@cisco.com
EMail: nfinn@cisco.com
Samer Salam Cisco Systems 595 Burrard St., Suite 2123 Vancouver, BC V7X 1J1 Canada
Samer Salam Cisco Systems加拿大不列颠哥伦比亚省温哥华市伯拉德街595号2123室V7X 1J1
EMail: ssalam@cisco.com
EMail: ssalam@cisco.com
Deepak Kumar Cisco Systems 510 McCarthy Blvd Milpitas, CA 95035 United States
美国加利福尼亚州米尔皮塔斯麦卡锡大道510号迪帕克·库马尔思科系统公司，邮编95035
Phone: +1 408-853-9760
EMail: dekumar@cisco.com
Phone: +1 408-853-9760
EMail: dekumar@cisco.com
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 United States
唐纳德·伊斯特莱克第三华为技术有限公司美国马萨诸塞州米尔福德海狸街155号01757
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Sam Aldrin Huawei Technologies 2330 Central Express Way Santa Clara, CA 95951 United States
Sam Aldrin华为技术公司美国加利福尼亚州圣克拉拉中央高速公路2330号，邮编95951
EMail: aldrin.ietf@gmail.com
EMail: aldrin.ietf@gmail.com
Yizhou Li Huawei Technologies 101 Software Avenue Nanjing 210012 China
宜州利华为技术有限公司软件大道101号南京210012
Phone: +86-25-56625375
EMail: liyizhou@huawei.com
Phone: +86-25-56625375
EMail: liyizhou@huawei.com