Internet Engineering Task Force (IETF) S. Salam
Request for Comments: 7174 T. Senevirathne
Category: Informational Cisco
ISSN: 2070-1721 S. Aldrin
D. Eastlake 3rd
Huawei
May 2014
Internet Engineering Task Force (IETF) S. Salam
Request for Comments: 7174 T. Senevirathne
Category: Informational Cisco
ISSN: 2070-1721 S. Aldrin
D. Eastlake 3rd
Huawei
May 2014
Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework
多链路透明互连（TRILL）操作、管理和维护（OAM）框架
Abstract
摘要
This document specifies a reference framework for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL) networks. The focus of the document is on the fault and performance management aspects of TRILL OAM.
本文件规定了大量链路（TRILL）网络透明互连中操作、管理和维护（OAM）的参考框架。本文档的重点是TRILL OAM的故障和性能管理方面。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc7174.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7174.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从该文档中提取的代码组件必须
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.
包括信托法律条款第4.e节中所述的简化BSD许可证文本，且不提供简化BSD许可证中所述的担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Relationship to Other OAM Work .............................5
2. TRILL OAM Model .................................................6
2.1. OAM Layering ...............................................6
2.1.1. Relationship to CFM .................................7
2.1.2. Relationship to BFD .................................8
2.1.3. Relationship to Link OAM ............................8
2.2. TRILL OAM in the RBridge Port Model ........................8
2.3. Network, Service, and Flow OAM ............................10
2.4. Maintenance Domains .......................................10
2.5. Maintenance Entity and Maintenance Entity Group ...........11
2.6. MEPs and MIPs .............................................12
2.7. Maintenance Point Addressing ..............................13
3. OAM Frame Format ...............................................14
3.1. Motivation ................................................14
3.2. Determination of Flow Entropy .............................16
3.2.1. Address Learning and Flow Entropy ..................16
3.3. OAM Message Channel .......................................17
3.4. Identification of OAM Messages ............................17
4. Fault Management ...............................................18
4.1. Proactive Fault Management Functions ......................18
4.1.1. Fault Detection (Continuity Check) .................18
4.1.2. Defect Indication ..................................19
4.1.2.1. Forward Defect Indication .................19
4.1.2.2. Reverse Defect Indication (RDI) ...........19
4.2. On-Demand Fault Management Functions ......................20
4.2.1. Connectivity Verification ..........................20
4.2.1.1. Unicast ...................................20
4.2.1.2. Multicast .................................21
4.2.2. Fault Isolation ....................................21
5. Performance Monitoring .........................................22
5.1. Packet Loss ...............................................22
5.2. Packet Delay ..............................................23
6. Operational and Manageability Considerations ...................23
6.1. TRILL OAM Configuration ...................................23
6.1.1. Maintenance Domain Parameters ......................24
6.1.2. Maintenance Association Parameters .................24
6.1.3. Maintenance Endpoint Parameters ....................24
6.1.4. Continuity Check Parameters (Applicable per MA) ....25
6.1.5. Connectivity Verification Parameters
(Applicable per Operation) .........................25
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Relationship to Other OAM Work .............................5
2. TRILL OAM Model .................................................6
2.1. OAM Layering ...............................................6
2.1.1. Relationship to CFM .................................7
2.1.2. Relationship to BFD .................................8
2.1.3. Relationship to Link OAM ............................8
2.2. TRILL OAM in the RBridge Port Model ........................8
2.3. Network, Service, and Flow OAM ............................10
2.4. Maintenance Domains .......................................10
2.5. Maintenance Entity and Maintenance Entity Group ...........11
2.6. MEPs and MIPs .............................................12
2.7. Maintenance Point Addressing ..............................13
3. OAM Frame Format ...............................................14
3.1. Motivation ................................................14
3.2. Determination of Flow Entropy .............................16
3.2.1. Address Learning and Flow Entropy ..................16
3.3. OAM Message Channel .......................................17
3.4. Identification of OAM Messages ............................17
4. Fault Management ...............................................18
4.1. Proactive Fault Management Functions ......................18
4.1.1. Fault Detection (Continuity Check) .................18
4.1.2. Defect Indication ..................................19
4.1.2.1. Forward Defect Indication .................19
4.1.2.2. Reverse Defect Indication (RDI) ...........19
4.2. On-Demand Fault Management Functions ......................20
4.2.1. Connectivity Verification ..........................20
4.2.1.1. Unicast ...................................20
4.2.1.2. Multicast .................................21
4.2.2. Fault Isolation ....................................21
5. Performance Monitoring .........................................22
5.1. Packet Loss ...............................................22
5.2. Packet Delay ..............................................23
6. Operational and Manageability Considerations ...................23
6.1. TRILL OAM Configuration ...................................23
6.1.1. Maintenance Domain Parameters ......................24
6.1.2. Maintenance Association Parameters .................24
6.1.3. Maintenance Endpoint Parameters ....................24
6.1.4. Continuity Check Parameters (Applicable per MA) ....25
6.1.5. Connectivity Verification Parameters
(Applicable per Operation) .........................25
6.1.6. Fault Isolation Parameters (Applicable per
Operation) .........................................26
6.1.7. Packet Loss Monitoring .............................27
6.1.8. Packet Delay Monitoring ............................27
6.2. TRILL OAM Notifications ...................................28
6.3. Collecting Performance Monitoring Metrics .................28
7. Security Considerations ........................................29
8. Acknowledgments ................................................29
9. References .....................................................30
9.1. Normative References ......................................30
9.2. Informative References ....................................31
6.1.6. Fault Isolation Parameters (Applicable per
Operation) .........................................26
6.1.7. Packet Loss Monitoring .............................27
6.1.8. Packet Delay Monitoring ............................27
6.2. TRILL OAM Notifications ...................................28
6.3. Collecting Performance Monitoring Metrics .................28
7. Security Considerations ........................................29
8. Acknowledgments ................................................29
9. References .....................................................30
9.1. Normative References ......................................30
9.2. Informative References ....................................31
This document specifies a reference framework for Operations, Administration, and Maintenance (OAM) [RFC6291] in Transparent Interconnection of Lots of Links (TRILL) networks.
本文件规定了大量链路（TRILL）网络透明互连中操作、管理和维护（OAM）[RFC6291]的参考框架。
TRILL [RFC6325] specifies a protocol for shortest-path frame routing in multi-hop networks with arbitrary topologies and link technologies, using the IS-IS routing protocol. TRILL capable devices are referred to as TRILL Switches or RBridges (Routing Bridges). RBridges provide an optimized and transparent Layer 2 delivery service for Ethernet unicast and multicast traffic. Some characteristics of a TRILL network that are different from IEEE 802.1 bridging are the following:
TRILL[RFC6325]使用IS-IS路由协议，为具有任意拓扑和链路技术的多跳网络中的最短路径帧路由指定协议。支持TRILL的设备称为TRILL交换机或RBridge（路由桥）。RBridges为以太网单播和多播流量提供优化和透明的第2层交付服务。TRILL网络与IEEE 802.1桥接不同的一些特征如下：
- TRILL networks support arbitrary link technology between TRILL Switches. Hence, a TRILL Switch port may not have a 48-bit Media Access Control (MAC) address [802] but might, for example, have an IP address as an identifier [TRILL-IP] or no unique identifier (e.g., PPP [RFC6361]).
- TRILL网络支持TRILL交换机之间的任意链接技术。因此，TRILL交换机端口可能不具有48位媒体访问控制（MAC）地址[802]，但可能例如具有作为标识符的IP地址[TRILL-IP]或没有唯一标识符（例如，PPP[RFC6361]）。
- TRILL networks do not enforce congruence of unicast and multicast paths between a given pair of RBridges.
- TRILL网络不会在给定的RBridge对之间强制单播和多播路径的一致性。
- TRILL networks do not impose symmetry of the forward and reverse paths between a given pair of RBridges.
- TRILL网络不会在给定的一对RBridge之间施加正向和反向路径的对称性。
- TRILL Switches terminate spanning tree protocols instead of propagating them.
- TRILL交换机终止生成树协议，而不是传播它们。
In this document, we refer to the term "OAM" as defined in [RFC6291]. The Operations aspect involves finding problems that prevent proper functioning of the network. It also includes monitoring of the network to identify potential problems before they occur. Administration involves keeping track of network resources. Maintenance activities are focused on facilitating repairs and
在本文件中，我们引用了[RFC6291]中定义的术语“OAM”。操作方面包括查找妨碍网络正常运行的问题。它还包括对网络的监控，以在潜在问题发生之前识别它们。管理包括跟踪网络资源。维护活动的重点是促进维修和保养
upgrades as well as corrective and preventive measures. [ISO/IEC7498-4] defines 5 functional areas in the OSI model for network management, commonly referred to as FCAPS:
升级以及纠正和预防措施。[ISO/IEC7498-4]在OSI网络管理模型中定义了5个功能区域，通常称为FCAP：
- Fault Management
- 故障管理
- Configuration Management
- 配置管理
- Accounting Management
- 会计管理
- Performance Management
- 绩效管理
- Security Management
- 安全管理
The focus of this document is on the first and fourth functional aspects, Fault Management and Performance Management, in TRILL networks. These primarily map to the Operations and Maintenance parts of OAM.
本文档的重点是TRILL网络中的第一个和第四个功能方面，即故障管理和性能管理。这些主要映射到OAM的操作和维护部分。
This document provides a generic framework for a comprehensive solution that meets the requirements outlined in [RFC6905]. However, specific mechanisms to address these requirements are considered to be outside the scope of this document. Furthermore, future document(s) will specify the optional reporting of errors in TRILL user traffic, such as the use of a reserved or unknown egress nickname, etc.
本文件为满足[RFC6905]中概述的要求的综合解决方案提供了通用框架。然而，解决这些要求的具体机制被认为不在本文件的范围之内。此外，未来的文档将指定TRILL用户流量中错误的可选报告，例如使用保留或未知出口昵称等。
Definitions of many OAM terms can be found in [RFC7087].
许多OAM术语的定义见[RFC7087]。
The following acronyms are used in this document:
本文件中使用了以下首字母缩略词：
BFD - Bidirectional Forwarding Detection [RFC5880]
BFD-双向转发检测[RFC5880]
CFM - Connectivity Fault Management [802.1Q]
CFM-连接故障管理[802.1Q]
ECMP - Equal-Cost Multipath
ECMP-等成本多路径
FGL - Fine-Grained Label(ing) [RFC7172]
FGL-细粒度标签（ing）[RFC7172]
IEEE - Institute for Electrical and Electronic Engineers
IEEE-电气和电子工程师学会
IP - Internet Protocol (includes both IPv4 and IPv6)
IP-互联网协议（包括IPv4和IPv6）
LAN - Local Area Network
局域网
MA - Maintenance Association
文学硕士-维修协会
MAC - Media Access Control [802]
MAC-媒体访问控制[802]
ME - Maintenance Entity
ME-维护实体
MEP - Maintenance End Point
MEP-维护终点
MIP - Maintenance Intermediate Point
MIP-维护中间点
MP - Maintenance Point (MEP or MIP)
MP-维修点（MEP或MIP）
OAM - Operations, Administration, and Maintenance [RFC6291]
OAM-运营、管理和维护[RFC6291]
PPP - Point-to-Point Protocol [RFC1661]
PPP-点对点协议[RFC1661]
RBridge - Routing Bridge, a device implementing TRILL [RFC6325]
RBridge-路由桥，一种实现TRILL[RFC6325]的设备
RDI - Reverse Defect Indication
RDI-反向缺陷指示
TRILL - Transparent Interconnection of Lots of Links [RFC6325]
TRILL-大量链路的透明互连[RFC6325]
TRILL Switch - an alternate name for an RBridge
颤音开关-RBridge的替代名称
VLAN - Virtual LAN [802.1Q]
VLAN-虚拟局域网[802.1Q]
OAM is a technology area where a wealth of prior art exists. This document leverages concepts and draws upon elements defined and/or used in the following documents:
OAM是一个存在大量现有技术的技术领域。本文件利用了以下文件中定义和/或使用的概念和元素：
- [RFC6905] defines the requirements for TRILL OAM that serve as the basis for this framework. It also defines terminology that is used extensively in this document.
- [RFC6905]定义了作为此框架基础的TRILL OAM的要求。它还定义了本文档中广泛使用的术语。
- [802.1Q] specifies the Connectivity Fault Management (CFM) protocol, which defines the concepts of Maintenance Domains, Maintenance End Points, and Maintenance Intermediate Points.
- [802.1Q]规定了连接故障管理（CFM）协议，该协议定义了维护域、维护端点和维护中间点的概念。
- [Y.1731] extends Connectivity Fault Management in the following areas: it defines fault notification and alarm suppression functions for Ethernet. It also specifies mechanisms for Ethernet performance management, including loss, delay, jitter, and throughput measurement.
- [Y.1731]在以下领域扩展了连接故障管理：它定义了以太网的故障通知和报警抑制功能。它还指定了以太网性能管理机制，包括丢失、延迟、抖动和吞吐量测量。
- [RFC7175] defines a TRILL encapsulation for BFD that enables the use of the latter for network fast failure detection.
- [RFC7175]定义了BFD的TRILL封装，允许使用后者进行网络快速故障检测。
- [RFC5860] and [RFC6371] specify requirements and a framework for OAM in MPLS-based networks.
- [RFC5860]和[RFC6371]规定了基于MPLS的网络中OAM的要求和框架。
In the TRILL architecture, the TRILL layer is independent of the underlying link-layer technology. Therefore, it is possible to run TRILL over any transport layer capable of carrying TRILL packets such as Ethernet [RFC6325], PPP [RFC6361], or IP [TRILL-IP]. Furthermore, TRILL provides a virtual Ethernet connectivity service that is transparent to higher-layer entities (Layer 3 and above). This strict layering is observed by TRILL OAM.
在TRILL体系结构中，TRILL层独立于底层链路层技术。因此，可以在能够承载诸如以太网[RFC6325]、PPP[RFC6361]或IP[TRILL-IP]等TRILL数据包的任何传输层上运行TRILL。此外，TRILL提供了一个虚拟以太网连接服务，该服务对更高层实体（第3层及以上）是透明的。这种严格的分层是由TRILL OAM观察到的。
Of particular interest is the layering of TRILL OAM with respect to:
特别令人感兴趣的是TRILL-OAM在以下方面的分层：
- BFD, which is typically used for fast failure detection.
- BFD，通常用于快速故障检测。
- Ethernet CFM [802.1Q] on paths from an external device, over a TRILL campus, to another external device, especially since TRILL Switches are likely to be deployed where existing 802.1 bridges can be such external devices.
- 以太网CFM[802.1Q]位于从外部设备通过TRILL园区到另一个外部设备的路径上，特别是因为TRILL交换机可能部署在现有802.1网桥可以是此类外部设备的地方。
- Link OAM, on links interior to a TRILL campus, which is link-technology-specific.
- 链接OAM，位于TRILL校园的链接内部，这是特定于链接技术的。
Consider the example network depicted in Figure 1 below, where a TRILL network is interconnected via Ethernet links:
考虑下面的图1所示的示例网络，其中Trip网络通过以太网链路互连：
LAN LAN
+---+ +---+ ====== +---+ ============= +---+
+--+ | | | | | +--+ | | | | +--+ +--+ | | | +--+
|B1|---|RB1|---|RB2|---|B2|---|RB3|---|B3|---|B4|---|RB4|---|B5|
+--+ | | | | | +--+ | | | | +--+ +--+ | | | +--+
+---+ +---+ ====== +---+ ============= +---+
LAN LAN
+---+ +---+ ====== +---+ ============= +---+
+--+ | | | | | +--+ | | | | +--+ +--+ | | | +--+
|B1|---|RB1|---|RB2|---|B2|---|RB3|---|B3|---|B4|---|RB4|---|B5|
+--+ | | | | | +--+ | | | | +--+ +--+ | | | +--+
+---+ +---+ ====== +---+ ============= +---+
a. Ethernet CFM (Client Layer) on path over the TRILL campus
>---o------------------------------------------------o---<
a. Ethernet CFM (Client Layer) on path over the TRILL campus
>---o------------------------------------------------o---<
b. TRILL OAM (Network Layer)
>------o-----------o---------------------<
b. TRILL OAM (Network Layer)
>------o-----------o---------------------<
c. Ethernet CFM (Transport Layer) on interior Ethernet LANs
>---o--o---< >---o--o---o--o---<
c. Ethernet CFM (Transport Layer) on interior Ethernet LANs
>---o--o---< >---o--o---o--o---<
d. BFD (Media Independent Link Layer)
#---# #----------# #-----------------#
d. BFD (Media Independent Link Layer)
#---# #----------# #-----------------#
e. Link OAM (Media Dependent Link Layer)
*---* *---* *---* *---* *---* *---* *---* *---*
e. Link OAM (Media Dependent Link Layer)
*---* *---* *---* *---* *---* *---* *---* *---*
Legend: >, < MEP o MIP # BFD Endpoint * Link OAM Endpoint
Legend: >, < MEP o MIP # BFD Endpoint * Link OAM Endpoint
Figure 1: OAM Layering in TRILL
图1:TRILL中的OAM分层
Where Bn and RBn (n= 1,2,3, ...) denote IEEE 802.1Q bridges and TRILL RBridges, respectively.
其中Bn和RBn（n=1,2,3，…）分别表示IEEE 802.1Q网桥和TRILL RBridge。
In the context of a TRILL network, CFM can be used as either a client-layer OAM or a transport-layer OAM mechanism.
在TRILL网络的上下文中，CFM可以用作客户端层OAM或传输层OAM机制。
When acting as a client-layer OAM (see Figure 1a), CFM provides fault management capabilities for the user, on an end-to-end basis over the TRILL network. Edge ports of the TRILL network may be visible to CFM operations through the optional presence of a CFM Maintenance Intermediate Point (MIP) in the TRILL Switches' edge Ethernet ports.
当充当客户端层OAM时（见图1a），CFM通过TRILL网络为用户提供端到端的故障管理功能。通过TRILL交换机边缘以太网端口中可选的CFM维护中间点（MIP），CFM操作可以看到TRILL网络的边缘端口。
When acting as a transport-layer OAM (see Figure 1c), CFM provides fault management functions for the IEEE 802.1Q bridged LANs that may interconnect RBridges. Such bridged LANs can be used as TRILL level
当作为传输层OAM（见图1c）时，CFM为IEEE 802.1Q桥接LAN提供故障管理功能，该桥接LAN可以互连RBridge。这种桥接LAN可以用作TRILL级别
links between RBridges. RBridges directly connected to the intervening 802.1Q bridges may host CFM Down Maintenance End Points (MEPs).
RBridges之间的链接。直接连接到中间802.1Q网桥的RBridge可以承载CFM下行维护端点（MEP）。
One-hop BFD (see Figure 1d) runs between adjacent RBridges and provides fast link as well as node failure detection capability [RFC7175]. Note that TRILL BFD also provides some testing of the TRILL protocol stack and thus sits a layer above Link OAM, which is media specific. BFD's fast failure detection helps support rapid convergence in TRILL networks. The requirements for BFD are different from those of the TRILL OAM mechanisms that are the prime focus of this document. Furthermore, BFD does not use the frame format described in Section 3.1.
单跳BFD（见图1d）在相邻RBridge之间运行，提供快速链路和节点故障检测能力[RFC7175]。请注意，TRILL BFD还提供了对TRILL协议栈的一些测试，因此位于链路OAM之上的一层，这是特定于媒体的。BFD的快速故障检测有助于支持TRILL网络中的快速收敛。BFD的要求与TRILL OAM机制的要求不同，TRILL OAM机制是本文档的主要重点。此外，BFD不使用第3.1节中描述的帧格式。
TRILL BFD differs from TRILL OAM in two significant ways:
TRILL BFD与TRILL OAM在两个重要方面不同：
1. A TRILL BFD transmitter is always bound to a specific TRILL output port.
1. 颤音BFD发射机始终绑定到特定的颤音输出端口。
2. TRILL BFD messages can be transmitted by the originator out of a port to a neighbor RBridge when the adjacency is in the Detect or 2-Way states as well as when the adjacency is in the Report (Up) state [RFC7177].
2. 当邻接处于检测或双向状态以及邻接处于报告（Up）状态时，发起者可以将TRILL BFD消息从端口传输到相邻RBridge[RFC7177]。
In contrast, TRILL OAM messages are typically transmitted by appearing to have been received on a TRILL input port (refer to Section 2.2 for details). In that case, the output ports on which TRILL OAM messages are sent are determined by the TRILL routing function. The TRILL routing function will only send on links that are in the Report state and have been incorporated into the local view of the campus topology.
相比之下，TRILL OAM消息通常通过在TRILL输入端口上接收的方式进行传输（有关详细信息，请参阅第2.2节）。在这种情况下，发送TRILL OAM消息的输出端口由TRILL路由功能确定。TRILL路由功能仅在处于报告状态且已合并到校园拓扑的本地视图中的链接上发送。
Link OAM (see Figure 1e) depends on the nature of the technology used in the links interconnecting RBridges. For example, for Ethernet links, the OAM described in Clause 57 of [802.3] may be used.
链路OAM（见图1e）取决于连接RBRINGS的链路中使用的技术的性质。例如，对于以太网链路，可以使用[802.3]第57条中描述的OAM。
TRILL OAM processing can be represented as a layer situated between the port's TRILL encapsulation/decapsulation function and the TRILL forwarding engine function on any RBridge port. TRILL OAM requires services of the RBridge forwarding engine and utilizes information from the IS-IS control plane. Figure 2 below depicts TRILL OAM
TRILL OAM处理可以表示为位于端口的TRILL封装/去封装功能和任何RBridge端口上的TRILL转发引擎功能之间的层。TRILL OAM需要RBridge转发引擎的服务，并利用来自IS-IS控制平面的信息。下面的图2描述了TRILL OAM
processing in the context of the RBridge Port Model defined in [RFC6325]. In this figure, double lines represent flow of both frames and information.
在[RFC6325]中定义的RBridge端口模型的上下文中进行处理。在此图中，双线表示帧和信息流。
This figure shows a conceptual model. It is to be understood that implementations need not mirror this exact model as long as the intended OAM requirements and functionality are preserved.
此图显示了一个概念模型。应该理解的是，只要保留了预期的OAM需求和功能，实现就不需要镜像这个精确的模型。
+-----------------------------------------------+----
| (Flow of OAM Messages) RBridge
| +----------------------+
| |+-------------------+|| Forwarding Engine,
| || || IS-IS, etc.
| || || Processing of
| V V TRILL packets
+---------------------------------------------+-----
|| || ...other ports
+------------+ +------------+
UP MEP /\ | TRILL OAM | | TRILL OAM | /\ UP MEP
MIP () | Layer | | Layer | () MIP
DOWN MEP \/ +------------+ +------------+ \/ DOWN MEP
| TRILL | | TRILL |
| Encap/Decap| | Encap/Decap|
+------------+ +------------+
|End-Station | |End-Station |
|VLAN & | |VLAN & |
|Priority | |Priority |
|Processing | |Processing |
+------------+ +------------+ <-- ISS
|802.1/802.3 | |802.1/802.3 |
|Low-Level | |Low-Level |
|Control | |Control |
|Frame | |Frame |
|Processing, | |Processing, |
|Port/Link | |Port/Link |
|Control | |Control |
|Logic | |Logic |
+------------+ +------------+
| 802.3PHY | | 802.3PHY |
|(Physical | |(Physical |
| interface) | | interface) |
+------------+ +------------+
|| ||
Link Link
+-----------------------------------------------+----
| (Flow of OAM Messages) RBridge
| +----------------------+
| |+-------------------+|| Forwarding Engine,
| || || IS-IS, etc.
| || || Processing of
| V V TRILL packets
+---------------------------------------------+-----
|| || ...other ports
+------------+ +------------+
UP MEP /\ | TRILL OAM | | TRILL OAM | /\ UP MEP
MIP () | Layer | | Layer | () MIP
DOWN MEP \/ +------------+ +------------+ \/ DOWN MEP
| TRILL | | TRILL |
| Encap/Decap| | Encap/Decap|
+------------+ +------------+
|End-Station | |End-Station |
|VLAN & | |VLAN & |
|Priority | |Priority |
|Processing | |Processing |
+------------+ +------------+ <-- ISS
|802.1/802.3 | |802.1/802.3 |
|Low-Level | |Low-Level |
|Control | |Control |
|Frame | |Frame |
|Processing, | |Processing, |
|Port/Link | |Port/Link |
|Control | |Control |
|Logic | |Logic |
+------------+ +------------+
| 802.3PHY | | 802.3PHY |
|(Physical | |(Physical |
| interface) | | interface) |
+------------+ +------------+
|| ||
Link Link
Figure 2: TRILL OAM in RBridge Port Model
图2:RBridge端口模型中的TRILL OAM
Note that the terms "MEP" and "MIP" in the above figure are explained in detail in Section 2.6 below.
请注意，上图中的术语“MEP”和“MIP”在下文第2.6节中有详细说明。
OAM functions in a TRILL network can be conducted at different granularity. This gives rise to 'Network', 'Service', and 'Flow' OAM, listed in order of finer granularity.
TRILL网络中的OAM功能可以在不同的粒度上执行。这就产生了“网络”、“服务”和“流”OAM，按更细的粒度排列。
Network OAM mechanisms provide fault and performance management functions in the context of a 'test' VLAN or fine-grained label [RFC7172]. The test VLAN can be thought of as a management or diagnostics VLAN that extends to all RBridges in a TRILL network. In order to account for multipathing, Network OAM functions also make use of test flows (both unicast and multicast) to provide coverage of the various paths in the network.
网络OAM机制在“测试”VLAN或细粒度标签的上下文中提供故障和性能管理功能[RFC7172]。测试VLAN可以被认为是扩展到TRILL网络中所有RBridge的管理或诊断VLAN。为了考虑多路径，网络OAM功能还利用测试流（单播和多播）来覆盖网络中的各种路径。
Service OAM mechanisms provide fault and performance management functions in the context of the actual VLAN or fine-grained label set for which end-station service is enabled. Test flows are used here, as well, to provide coverage in the case of multipathing.
服务OAM机制在实际VLAN或为其启用终端站服务的细粒度标签集的上下文中提供故障和性能管理功能。这里还使用测试流来提供多路径情况下的覆盖。
Flow OAM mechanisms provide the most fine-grained fault and performance management capabilities, where OAM functions are performed in the context of end-station flows within VLANs or fine-grained labels. While Flow OAM provides the most granular control, it clearly poses scalability challenges if attempted on large numbers of flows.
流OAM机制提供了最细粒度的故障和性能管理功能，其中OAM功能在VLAN或细粒度标签内的终端站流上下文中执行。虽然Flow OAM提供了最细粒度的控制，但如果尝试在大量流上进行，显然会带来可伸缩性挑战。
The concept of Maintenance Domains, or OAM Domains, is well known in the industry. IEEE [802.1Q] defines the notion of a Maintenance Domain as a collection of devices (for example, network elements) that are grouped for administrative and/or management purposes. Maintenance Domains usually delineate trust relationships, varying addressing schemes, network infrastructure capabilities, etc.
维护域或OAM域的概念在业界是众所周知的。IEEE[802.1Q]将维护域的概念定义为为了管理和/或管理目的而分组的设备集合（例如，网络元素）。维护域通常描述信任关系、不同的寻址方案、网络基础设施功能等。
When mapped to TRILL, a Maintenance Domain is defined as a collection of RBridges in a network for which connectivity faults and performance degradation are to be managed by a single operator. All RBridges in a given Maintenance Domain are, by definition, managed by a single entity (for example, an enterprise or a data center operator, etc.). [RFC6325] defines the operation of TRILL in a single IS-IS area, with the assumption that a single operator manages the network. In this context, a single (default) Maintenance Domain is sufficient for TRILL OAM.
当映射到TRILL时，维护域被定义为网络中的RBridge集合，对于这些RBridge，连接故障和性能降级将由单个运营商进行管理。根据定义，给定维护域中的所有RBridge由单个实体（例如，企业或数据中心运营商等）管理。[RFC6325]定义了TRILL在单个IS-IS区域中的操作，假设由一个运营商管理网络。在这种情况下，对于TRILL OAM来说，一个（默认）维护域就足够了。
However, when considering scenarios where different TRILL networks need to be interconnected, for example, as discussed in [TRILL-ML], then the introduction of multiple Maintenance Domains, and Maintenance Domain hierarchies, becomes useful to map and enforce administrative boundaries. When considering multi-domain scenarios, the following rules must be followed: TRILL OAM Domains must not partially intersect but must either be disjoint or nest to form a hierarchy (that is, a higher Maintenance Domain may completely enclose a lower domain). A Maintenance Domain is typically identified by a Domain Name and a Maintenance Level (a numeric identifier). If two domains are nested, the encompassing domain must be assigned a higher Maintenance Level number than the enclosed domain. For this reason, the encompassing domain is commonly referred to as the 'higher' domain, and the enclosed domain is referred to as the 'lower' domain. OAM functions in the lower domain are completely transparent to the higher domain. Furthermore, OAM functions in the higher domain only have visibility to the boundary of the lower domain (for example, an attempt to trace the path in the higher domain will depict the entire lower domain as a single-hop between the RBridges that constitute the boundary of that lower domain). By the same token, OAM functions in the higher domain are transparent to RBridges that are internal to the lower domain. The hierarchical nesting of domains is established through operator configuration of the RBridges.
然而，当考虑不同TRILL网络需要互连的场景时，例如，如[TRILL-ML]中所述，则引入多个维护域和维护域层次结构对于映射和实施管理边界非常有用。在考虑多域场景时，必须遵循以下规则：TRILL OAM域不得部分相交，但必须不相交或嵌套以形成层次结构（即，维护级别较高的域可能完全包围较低的域）。维护域通常由域名和维护级别（数字标识符）标识。如果两个域嵌套，则必须为包含的域分配比包含的域更高的维护级别编号。因此，包含域通常被称为“较高”域，而包含域被称为“较低”域。较低域中的OAM函数对较高域完全透明。此外，较高域中的OAM函数仅对较低域的边界具有可见性（例如，尝试跟踪较高域中的路径将把整个较低域描述为构成该较低域边界的rbridge之间的单跳）。同样，更高域中的OAM功能对更低域内部的RBridge是透明的。域的层次嵌套是通过RBridge的操作符配置建立的。
+-------------------+ +---------------+ +-------------------+
| | | TRILL | | |
| Site 1 +----+Interconnect +----+ Site 2 |
| TRILL | RB | Network | RB | TRILL |
| (Level 1) +----+ (Level 2) +----+ (Level 1) |
| | | | | |
+-------------------+ +---------------+ +-------------------+
+-------------------+ +---------------+ +-------------------+
| | | TRILL | | |
| Site 1 +----+Interconnect +----+ Site 2 |
| TRILL | RB | Network | RB | TRILL |
| (Level 1) +----+ (Level 2) +----+ (Level 1) |
| | | | | |
+-------------------+ +---------------+ +-------------------+
<------------------------End-to-End Domain-------------------->
<------------------------End-to-End Domain-------------------->
<----Site Domain----> <--Interconnect --> <----Site Domain---->
Domain
<----Site Domain----> <--Interconnect --> <----Site Domain---->
Domain
Figure 3: TRILL OAM Maintenance Domains
图3:TRILL OAM维护域
TRILL OAM functions are performed in the context of logical endpoint pairs referred to as Maintenance Entities (ME). A Maintenance Entity defines a relationship between two points in a TRILL network where OAM functions (for example, monitoring operations) are applied. The two points that define a Maintenance Entity are known as Maintenance End Points (MEPs) -- see Section 2.6 below. The set of Maintenance
TRILL OAM函数在称为维护实体（ME）的逻辑端点对的上下文中执行。维护实体定义TRILL网络中应用OAM功能（例如，监视操作）的两点之间的关系。定义维护实体的两点称为维护端点（MEP）——见下文第2.6节。维护组
End Points that belong to the same Maintenance Domain are referred to as a Maintenance Association (MA). On the network path in between MEPs, there can be zero or more intermediate points, called Maintenance Intermediate Points (MIPs). MEPs can be part of more than one ME in a given MA.
属于同一维护域的端点称为维护关联（MA）。在MEP之间的网络路径上，可以有零个或多个中间点，称为维护中间点（MIP）。MEP可以是给定MA中多个ME的一部分。
OAM capabilities on RBridges can be defined in terms of logical groupings of functions that can be categorized into two functional objects: Maintenance End Points (MEPs) and Maintenance Intermediate Points (MIPs). The two are collectively referred to as Maintenance Points (MPs).
RBridge上的OAM功能可以根据功能的逻辑分组来定义，这些功能可以分为两个功能对象：维护端点（MEP）和维护中间点（MIP）。这两者统称为维修点（MPs）。
MEPs are the active components of TRILL OAM: MEPs source TRILL OAM messages periodically or on-demand based on operator configuration actions. Furthermore, MEPs ensure that TRILL OAM messages do not leak outside a given Maintenance Domain, for example, out of the TRILL network and into end stations. MIPs, on the other hand, are internal to a Maintenance Domain. They are the more passive components of TRILL OAM, primarily responsible for forwarding TRILL OAM messages and selectively responding to a subset of these messages.
MEP是TRILL OAM的活动组件：MEP根据操作员配置操作定期或按需发送TRILL OAM消息。此外，MEP确保TRILL OAM消息不会泄漏到给定维护域之外，例如，从TRILL网络泄漏到终端站。另一方面，MIP是维护域的内部。它们是TRILL-OAM中比较被动的组件，主要负责转发TRILL-OAM消息并有选择地响应这些消息的子集。
The following figure shows the MEP and MIP placement for the Maintenance Domains depicted in Figure 3 above.
下图显示了上面图3所示的维护域的MEP和MIP位置。
TRILL Site 1 Interconnect TRILL Site 2
+-----------------+ +------------------+ +-----------------+
| | | | | |
| +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ |
| |RB1|--|RB2|--|RB3|--|RB4|--|RB5|--|RB6|--|RB7|--|RB8| |
| +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ |
| | | | | |
+-----------------+ +------------------+ +-----------------+
TRILL Site 1 Interconnect TRILL Site 2
+-----------------+ +------------------+ +-----------------+
| | | | | |
| +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ |
| |RB1|--|RB2|--|RB3|--|RB4|--|RB5|--|RB6|--|RB7|--|RB8| |
| +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ |
| | | | | |
+-----------------+ +------------------+ +-----------------+
<E------------I--------------------I-------------E>
<E------------I--------------------I-------------E>
<E------I----E><E----I-------I----E><E-----I-----E>
<E------I----E><E----I-------I----E><E-----I-----E>
Legend E: MEP I: MIP
图例E:MEP I:MIP
Figure 4: MEPs and MIPs
图4:MEP和MIPs
A single RBridge may host multiple MEPs of different technologies, for example, TRILL OAM MEP(s) and [802.1Q] MEP(s). This does not mean that the protocol operation is necessarily consolidated into a single functional entity on those ports. The protocol functions for each MEP remain independent and reside in different shims in the RBridge Port Model of Figure 2: the TRILL OAM MEP resides in the "TRILL OAM Layer" block whereas a CFM MEP resides in the "End-Station VLAN & Priority Processing" block.
单个RBridge可以承载不同技术的多个MEP，例如TRILL OAM MEP和[802.1Q]MEP。这并不意味着协议操作必须整合到这些端口上的单个功能实体中。每个MEP的协议功能保持独立，并驻留在图2的RBridge端口模型中的不同垫片中：TRILL OAM MEP驻留在“TRILL OAM Layer”块中，而CFM MEP驻留在“End Station VLAN&Priority Processing”块中。
In the model of Section 2.2, a single MEP and/or MIP per MA can be instantiated per RBridge port. A MEP is further qualified with an administratively set direction (UP or DOWN), as follows:
在第2.2节的模型中，每个RBridge端口可以实例化单个MEP和/或MIP/MA。MEP还具有管理设置方向（向上或向下），如下所示：
- An UP MEP sends and receives OAM messages through the RBridge forwarding engine. This means that an UP MEP effectively communicates with MEPs on other RBridges through TRILL interfaces other than the one that the MEP is configured on.
- UP MEP通过RBridge转发引擎发送和接收OAM消息。这意味着UP MEP通过除配置MEP的接口之外的TRILL接口与其他RBridge上的MEP进行有效通信。
- A DOWN MEP sends and receives OAM messages through the link connected to the interface on which the MEP is configured.
- 下行MEP通过连接到配置MEP的接口的链路发送和接收OAM消息。
In order to support TRILL OAM functions on sections, as described in [RFC6905], while maintaining the simplicity of a single TRILL OAM Maintenance Domain, the TRILL OAM layer may be implemented on a virtual port with no physical layer (Null PHY). In this case, the Down MEP function is not supported, since the virtual port does not attach to a link; as such, a Down MEP on a virtual port would not be capable of sending or receiving OAM messages.
如[RFC6905]所述，为了在部分上支持TRILL-OAM功能，同时保持单个TRILL-OAM维护域的简单性，TRILL-OAM层可以在没有物理层（空PHY）的虚拟端口上实现。在这种情况下，由于虚拟端口未连接到链路，因此不支持Down MEP功能；因此，虚拟端口上的停机MEP将无法发送或接收OAM消息。
A TRILL OAM solution that conforms to this framework:
符合此框架的TRILL OAM解决方案：
- must support the MIP function on TRILL ports (to support Fault Isolation).
- 必须在TRILL端口上支持MIP功能（以支持故障隔离）。
- must support the UP MEP function on a TRILL virtual port (to support OAM functions on sections, as defined in [RFC6905]).
- 必须在TRILL虚拟端口上支持UP MEP功能（以支持[RFC6905]中定义的节上的OAM功能）。
- may support the UP MEP function on TRILL ports.
- 可能在TRILL端口上支持UP MEP功能。
- may support the DOWN MEP function on TRILL ports.
- 可能支持TRILL端口上的向下MEP功能。
TRILL OAM functions must provide the capability to address a specific Maintenance Point or a set of one or more Maintenance Points in an MA. To that end, RBridges need to recognize two sets of addresses:
TRILL OAM功能必须提供在MA中解决特定维护点或一组一个或多个维护点的能力。为此，RBridges需要识别两组地址：
- Individual MP addresses
- 个别议员地址
- Group MP addresses
- 组MP地址
TRILL OAM will support the Shared MP address model, where all MPs on an RBridge share the same Individual MP address. In other words, TRILL OAM messages can be addressed to a specific RBridge but not to a specific port on an RBridge.
TRILL OAM将支持共享MP地址模型，其中RBridge上的所有MP共享同一个MP地址。换句话说，TRILL OAM消息可以发送到特定的RBridge，但不能发送到RBridge上的特定端口。
One cannot discern, from observing the external behavior of an RBridge, whether TRILL OAM messages are actually delivered to a certain MP or another entity within the RBridge. The Shared MP address model takes advantage of this fact by allowing MPs in different RBridge ports to share the same Individual MP address. The MPs may still be implemented as residing on different RBridge ports, and for the most part, they have distinct identities.
通过观察RBridge的外部行为，我们无法辨别TRILL OAM消息是否实际传递给RBridge中的某个MP或另一个实体。共享MP地址模型利用了这一事实，允许不同RBridge端口中的MP共享同一个MP地址。MPs仍然可以被实现为驻留在不同的RBridge端口上，并且在大多数情况下，它们具有不同的身份。
The Group MP addresses enable the OAM mechanism to reach all the MPs in a given MA. Certain OAM functions, for example, pruned tree verification, require addressing a subset of the MPs in an MA. Group MP addresses are not defined for such subsets. Rather, the OAM function in question must use the Group MP addresses combined with an indication of the scope of the MP subset encoded in the OAM Message Channel. This prevents an unwieldy set of responses to Group MP addresses.
组MP地址使OAM机制能够到达给定MA中的所有MP。某些OAM功能，例如修剪树验证，需要在MA中寻址MPs的子集。未为此类子集定义组MP地址。相反，所讨论的OAM功能必须使用组MP地址，并结合OAM消息通道中编码的MP子集范围的指示。这可以防止对组MP地址的一组笨拙的响应。
In order for TRILL OAM messages to accurately test the data path, these messages must be transparent to transit RBridges. That is, a TRILL OAM message must be indistinguishable from a TRILL Data packet through normal transit RBridge processing. Only the target RBridge, which needs to process the message, should identify and trap the packet as a control message through normal processing. Additionally, methods must be provided to prevent OAM packets from being transmitted out as native frames.
为了使TRILL OAM消息能够准确地测试数据路径，这些消息必须对传输透明。也就是说，TRILL OAM消息必须通过正常的传输RBridge处理与TRILL数据包无法区分。只有需要处理消息的目标RBridge应该通过正常处理将数据包识别并捕获为控制消息。此外，必须提供防止OAM数据包作为本机帧发送出去的方法。
The TRILL OAM packet format defined below provides the necessary flexibility to exercise the data path as closely as possible to actual data packets.
下面定义的TRILL OAM数据包格式提供了必要的灵活性，使数据路径尽可能接近实际数据包。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Link Header . Variable
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial 6-byte fixed part of |
+ TRILL Header + 6 bytes
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TRILL Header Extensions |
. (if any) . Variable
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -
| DA / SA | \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
| Data Label | | Flow Entropy
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Fixed Size
. . |
. . /
| | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -
| OAM Ethertype | 2 bytes
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. OAM Message Channel . Variable
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Link Trailer . Variable
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Link Header . Variable
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial 6-byte fixed part of |
+ TRILL Header + 6 bytes
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TRILL Header Extensions |
. (if any) . Variable
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -
| DA / SA | \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
| Data Label | | Flow Entropy
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Fixed Size
. . |
. . /
| | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -
| OAM Ethertype | 2 bytes
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. OAM Message Channel . Variable
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Link Trailer . Variable
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: OAM Frame Format
图5:OAM帧格式
The TRILL Header and the Link Header and Trailer need to be as similar as practical to the TRILL Header and the Link Header and Trailer of the normal TRILL Data packet corresponding to the traffic that OAM is testing.
TRILL报头和链路报头和尾部需要与对应于OAM正在测试的业务的正常TRILL数据分组的TRILL报头和链路报头和尾部尽可能地相似。
The OAM Ethertype demarcates the boundary between the Flow Entropy field and the OAM Message Channel. The OAM Ethertype is expected at a deterministic offset from the TRILL Header, thereby allowing applications to clearly identify the beginning of the OAM Message Channel. Additionally, it facilitates the use of the same OAM frame structure by different Ethernet technologies.
OAM Ethertype划分了流熵场和OAM消息通道之间的边界。OAM Ethertype预期与TRILL报头的确定偏移量，从而允许应用程序清楚地识别OAM消息通道的开始。此外，它有助于通过不同的以太网技术使用相同的OAM帧结构。
The Link Trailer is usually a checksum, such as the Ethernet Frame Check Sequence, which is examined at a low level very early in the frame input process and automatically generated as part of the low-level frame output process. If the checksum fails, the frame is normally discarded with no higher-level processing.
链路尾部通常是校验和，如以太网帧检查序列，在帧输入过程的早期在低级别进行检查，并作为低级别帧输出过程的一部分自动生成。如果校验和失败，帧通常被丢弃，无需更高级别的处理。
The Flow Entropy field is a fixed-length field that is populated with either real packet data or synthetic data that mimics the intended flow. It always starts with a destination and source MAC address area followed by a Data Label area (either a VLAN or fine-grained label).
流熵场是一个固定长度的场，由真实分组数据或模拟预期流的合成数据填充。它总是从目标和源MAC地址区域开始，然后是数据标签区域（VLAN或细粒度标签）。
For a Layer 2 flow (that is, non-IP) the Flow Entropy field must specify the desired Ethernet header, including the MAC destination and source addresses as well as a VLAN tag or fine-grained label.
对于第2层流（即非IP），流熵字段必须指定所需的以太网报头，包括MAC目的地和源地址以及VLAN标记或细粒度标签。
For a Layer 3 flow, the Flow Entropy field must specify the desired Ethernet header, the IP header, and UDP or TCP header fields, although the Ethernet-layer header fields are also still present.
对于第3层流，流熵字段必须指定所需的以太网报头、IP报头以及UDP或TCP报头字段，尽管以太网层报头字段仍然存在。
Not all fields in the Flow Entropy field need to be identical to the data flow that the OAM message is mimicking. The only requirement is for the selected flow entropy to follow the same path as the data flow that it is mimicking. In other words, the selected flow entropy must result in the same ECMP selection or multicast pruning behavior or other applicable forwarding paradigm.
并非流熵字段中的所有字段都需要与OAM消息模拟的数据流相同。唯一的要求是选定的流熵与它模拟的数据流遵循相同的路径。换句话说，所选择的流熵必须导致相同的ECMP选择或多播剪枝行为或其他适用的转发范例。
When performing diagnostics on user flows, the OAM mechanisms must allow the network operator to configure the flow entropy parameters (for example, Layer 2 and/or 3) on the RBridge from which the diagnostic operations are to be triggered.
在对用户流执行诊断时，OAM机制必须允许网络运营商在要触发诊断操作的RBridge上配置流熵参数（例如，第2层和/或第3层）。
When running OAM functions over test flows, the TRILL OAM may provide a mechanism for discovering the flow entropy parameters by querying the RBridges dynamically, or it may allow the network operator to configure the flow entropy parameters.
当在测试流上运行OAM功能时，TRILL OAM可以通过动态查询rbridge来提供用于发现流熵参数的机制，或者它可以允许网络运营商配置流熵参数。
Edge TRILL Switches, like traditional 802.1 bridges, are required to learn MAC address associations. Learning is accomplished either by snooping data packets or through other methods. The Flow Entropy field of TRILL OAM messages mimics real packets and may impact the address-learning process of the TRILL data plane. TRILL OAM is required to provide methods to prevent any learning of addresses from
边缘颤音交换机，像传统的802.1网桥一样，需要学习MAC地址关联。学习可以通过窥探数据包或通过其他方法完成。TRILL-OAM消息的流熵场模仿真实分组，并且可能影响TRILL数据平面的地址学习过程。TRILL OAM需要提供方法来防止从中学习地址
the Flow Entropy field of OAM messages that would interfere with normal TRILL operation. This can be done, for example, by suppressing/preventing MAC address learning from OAM messages.
会干扰正常颤音操作的OAM消息的流熵场。这可以通过例如抑制/防止从OAM消息学习MAC地址来实现。
The OAM Message Channel provides methods to communicate OAM-specific details between RBridges. CFM [802.1Q] and [RFC4379] have implemented OAM message channels. It is desirable to select an appropriate technology and reuse it, instead of redesigning yet another OAM channel. TRILL is a transport layer that carries Ethernet frames, so the TRILL OAM model specified earlier is based on the CFM [802.1Q] model. The use of the CFM [802.1Q] encoding format for the OAM Message Channel is one possible choice. [TRILL-OAM] presents a proposal on the use of CFM [802.1Q] payload as the OAM Message Channel.
OAM消息通道提供了在RBridge之间传递OAM特定细节的方法。CFM[802.1Q]和[RFC4379]已经实现了OAM消息通道。最好选择适当的技术并重用它，而不是重新设计另一个OAM通道。TRILL是承载以太网帧的传输层，因此前面指定的TRILL OAM模型基于CFM[802.1Q]模型。对OAM消息信道使用CFM[802.1Q]编码格式是一种可能的选择。[TRILL-OAM]提出了使用CFM[802.1Q]有效载荷作为OAM消息信道的建议。
RBridges must be able to identify OAM messages that are destined to them, either individually or as a group, so as to properly process those messages.
RBridges必须能够识别发送给它们的OAM消息，无论是单独发送还是作为一个组发送，以便正确处理这些消息。
TRILL, as defined in [RFC6325], does not specify a method to identify OAM messages. The most reliable method to identify these messages, without imposing restrictions on the Flow Entropy field, involves modifying the definition of the TRILL Header to include an "Alert" flag. This flag signals that the content of the TRILL packet is a control message as opposed to user data. The use of such a flag would not be limited to TRILL OAM and may be leveraged by any other TRILL control protocol that requires in-band behavior. The TRILL Header currently has two reserved bits that are unused. One of those bits may be used as the Alert flag. In order to guarantee accurate in-band forwarding behavior, RBridges must not use the Alert flag in ECMP hashing decisions. Furthermore, to ensure that this flag remains protocol agnostic, TRILL OAM mechanisms must not rely solely on the Alert flag to identify OAM messages. Rather, these solutions must identify OAM messages based on the combination of the Alert flag and the OAM Ethertype.
[RFC6325]中定义的TRILL没有指定识别OAM消息的方法。在不对流熵场施加限制的情况下，识别这些消息的最可靠方法是修改TRILL报头的定义，以包含“警报”标志。此标志表示TRILL数据包的内容是与用户数据相反的控制消息。这种标志的使用不限于TRILL OAM，任何其他需要带内行为的TRILL控制协议都可以利用这种标志。TRILL标头当前有两个未使用的保留位。这些位之一可用作警报标志。为了保证准确的带内转发行为，RBridges不得在ECMP哈希决策中使用警报标志。此外，为了确保此标志仍然与协议无关，TRILL OAM机制不能仅依赖警报标志来识别OAM消息。相反，这些解决方案必须基于警报标志和OAM类型的组合来识别OAM消息。
Since the above mechanism requires modification of the TRILL Header, it is not backward compatible. TRILL OAM solutions should provide alternate methods to identify OAM messages that work on existing RBridge implementations, thereby providing backward compatibility.
由于上述机制需要修改TRILL报头，因此它不向后兼容。TRILL OAM解决方案应提供替代方法来识别在现有RBridge实现上工作的OAM消息，从而提供向后兼容性。
Section 4.1 below discusses proactive fault management, and Section 4.2 discusses on-demand fault management.
下面第4.1节讨论了主动故障管理，第4.2节讨论了按需故障管理。
Proactive fault management functions are configured by the network operator to run periodically without a time bound or are configured to trigger certain actions upon the occurrence of specific events.
主动式故障管理功能由网络运营商配置为定期运行，无时间限制，或配置为在特定事件发生时触发某些操作。
Proactive fault detection is performed by periodically monitoring the reachability between service endpoints, that is, MEPs in a given MA, through the exchange of Continuity Check messages. The reachability between any two arbitrary MEPs may be monitored for a specified path, all paths, or any representative path. The fact that TRILL networks do not enforce congruence between unicast and multicast paths means that the proactive fault detection mechanism must provide procedures to monitor the unicast paths independently of the multicast paths. Furthermore, where the network has ECMP, the proactive fault detection mechanism must be capable of exercising the equal-cost paths individually.
通过交换连续性检查消息，定期监控服务端点（即给定MA中的MEP）之间的可达性，执行主动式故障检测。可针对指定路径、所有路径或任何代表性路径监控任意两个MEP之间的可达性。TRILL网络不强制单播和多播路径之间的一致性这一事实意味着主动故障检测机制必须提供独立于多播路径监控单播路径的程序。此外，在网络具有ECMP的情况下，主动式故障检测机制必须能够单独执行等成本路径。
The set of MEPs exchanging Continuity Check messages in a given domain and for a specific monitored entity (flow, network, or service) must use the same transmission period. As long as the fault detection mechanism involves MEPs transmitting periodic heartbeat messages independently, then this OAM procedure is not affected by the lack of forward/reverse path symmetry in TRILL.
在给定域和特定受监控实体（流、网络或服务）中交换连续性检查消息的MEP集必须使用相同的传输周期。只要故障检测机制涉及MEP独立地传输周期性心跳消息，那么此OAM过程就不会受到TRILL中缺少前向/反向路径对称性的影响。
The proactive fault detection function must detect the following types of defects:
主动故障检测功能必须检测以下类型的缺陷：
- Loss of continuity to one or more remote MEPs
- 一个或多个远程MEP的连续性丧失
- Unexpected connectivity between isolated VLANs or fine-grained labels (mismerge)
- 隔离VLAN或细粒度标签之间的意外连接（错误合并）
- Unexpected connectivity to one or more remote MEPs
- 意外连接到一个或多个远程MEP
- Mismatch of the Continuity Check transmission period between MEPs
- MEP之间的连续性检查传输周期不匹配
TRILL OAM must support event-driven defect indication upon the detection of a connectivity defect. Defect indications can be categorized into two types; these types are discussed in the following subsections.
TRILL OAM必须在检测到连接缺陷时支持事件驱动的缺陷指示。缺陷显示可分为两种类型；以下小节将讨论这些类型。
Forward defect indication is used to signal a failure that is detected by a lower-layer OAM mechanism. A forward defect indication is transmitted away from the direction of the failure. For example, consider a simple network comprised of four RBridges connected in series: RB1, RB2, RB3, and RB4. Both RB1 and RB4 are hosting TRILL OAM MEPs, whereas RB2 and RB3 have MIPs. If the link between RB2 and RB3 fails, then RB2 can send a forward defect indication towards RB1 while RB3 sends a forward defect indication towards RB4.
前向缺陷指示用于向下层OAM机制检测到的故障发送信号。正向缺陷指示从故障方向向外传输。例如，考虑一个简单的网络，包括四个串联的RBR桥：RB1、RB2、RB3和RB4。RB1和RB4都托管TRILL OAM MEP，而RB2和RB3都有MIP。如果RB2和RB3之间的链路出现故障，则RB2可以向RB1发送前向缺陷指示，而RB3则向RB4发送前向缺陷指示。
Forward defect indication may be used for alarm suppression and/or for the purpose of interworking with other layer OAM protocols. Alarm suppression is useful when a transport/network-level fault translates to multiple service- or flow-level faults. In such a scenario, it is enough to alert a network management station (NMS) of the single transport/network-level fault in lieu of flooding that NMS with a multitude of Service or Flow granularity alarms.
前向缺陷指示可用于报警抑制和/或与其他层OAM协议互通。当传输/网络级故障转化为多个服务级或流级故障时，报警抑制非常有用。在这种情况下，只需向网络管理站（NMS）发出单一传输/网络级故障的警报，而不用向NMS发出大量服务或流粒度警报。
RDI is used to signal that the advertising MEP has detected a loss-of-continuity defect. RDI is transmitted in the direction of the failure. For example, consider the same series network as that in Section 4.1.2.1. If RB1 detects that is has lost connectivity to RB4 because it is no longer receiving Continuity Check messages from the MEP on RB4, then RB1 can transmit an RDI towards RB4 to inform the latter of the failure. If the failure is unidirectional (it is affecting the direction from RB4 to RB1), then the RDI enables RB4 to become aware of the unidirectional connectivity anomaly.
RDI用于表示广告MEP已检测到连续性缺失缺陷。RDI沿故障方向传输。例如，考虑与第4.1.2.1节相同的串联网络。如果RB1检测到is由于不再从RB4上的MEP接收连续性检查消息而失去与RB4的连接，则RB1可以向RB4发送RDI，以通知后者故障。如果故障是单向的（它影响从RB4到RB1的方向），则RDI使RB4能够意识到单向连接异常。
In the presence of equal-cost paths between MEPs, RDI must be able to identify on which equal-cost path the failure was detected.
在MEP之间存在等成本路径的情况下，RDI必须能够识别在哪个等成本路径上检测到故障。
RDI allows single-sided management, where the network operator can examine the state of a single MEP and deduce the overall health of a monitored entity (network, flow, or service).
RDI允许单边管理，其中网络运营商可以检查单个MEP的状态并推断受监控实体（网络、流或服务）的总体健康状况。
On-demand fault management functions are initiated manually by the network operator either as a one-time occurrence or as an action/test that continues for a time bound period. These functions enable the operator to run diagnostics to investigate a defect condition.
按需故障管理功能由网络运营商作为一次性事件或持续一段时间的操作/测试手动启动。这些功能使操作员能够运行诊断以调查缺陷状况。
As specified in [RFC6905], TRILL OAM must support on-demand Connectivity Verification for unicast and multicast. The Connectivity-Verification mechanism must provide a means for specifying and carrying in the messages:
如[RFC6905]所述，TRILL OAM必须支持单播和多播的按需连接验证。连接性验证机制必须提供指定和携带消息的方法：
- variable-length payload/padding to test MTU-related connectivity problems.
- 用于测试MTU相关连接问题的可变长度有效负载/填充。
- test message formats as defined in [RFC2544].
- 测试[RFC2544]中定义的消息格式。
A unicast Connectivity Verification operation must be initiated from a MEP and may target either a MIP or another MEP. For unicast, Connectivity Verification can be performed at either Network or Flow granularity.
单播连接验证操作必须从MEP启动，并且可能以MIP或其他MEP为目标。对于单播，可以在网络或流粒度上执行连接验证。
Connectivity verification at the Network granularity tests connectivity between a MEP on a source RBridge and a MIP or MEP on a target RBridge over a test flow in a test VLAN or fine-grained label. The operator must supply the source and target RBridges for the operation, and the test VLAN/flow information uses pre-set values or defaults.
网络粒度的连接性验证通过测试VLAN或细粒度标签中的测试流测试源RBridge上的MEP和目标RBridge上的MIP或MEP之间的连接性。操作员必须为操作提供源和目标RBridge，测试VLAN/流信息使用预设值或默认值。
Connectivity Verification at the Flow granularity tests connectivity between a MEP on a source RBridge and a MIP or MEP on a target RBridge over an operator-specified VLAN or fine-grained label with operator-specified flow parameters.
流粒度的连接性验证测试源RBridge上的MEP和目标RBridge上的MIP或MEP之间的连接性，该连接通过操作员指定的VLAN或具有操作员指定流参数的细粒度标签进行。
The above functions must be supported on sections, as defined in [RFC6905]. When Connectivity Verification is triggered over a section, and the initiating MEP does not coincide with the edge (ingress) RBridge, the MEP must use the edge RBridge nickname instead of the local RBridge nickname on the associated Connectivity Verification messages. The operator must supply the edge RBridge nickname as part of the operation parameters.
[RFC6905]中定义的章节必须支持上述功能。当在某个区段上触发连接验证，且发起的MEP与边缘（入口）RBridge不一致时，MEP必须在相关连接验证消息上使用边缘RBridge昵称，而不是本地RBridge昵称。操作员必须提供边缘RBridge昵称作为操作参数的一部分。
For multicast, the Connectivity Verification function tests all branches and leaf nodes of a multi-destination distribution tree for reachability. This function should include mechanisms to prevent reply storms from overwhelming the initiating RBridge. This may be done, for example, by staggering the replies through the introduction of a random delay timer, with a preset upper bound, on the responding RBridge (CFM [802.1Q] uses similar mechanisms for Linktrace Reply messages to mitigate the load on the originating MEP). The upper bound on the timer value should be selected by the OAM solution to be long enough to accommodate large distribution trees, while allowing the Connectivity Verification operation to conclude within a reasonable time. To further prevent reply storms, Connectivity Verification operation is initiated from a MEP and must target MEPs only. MIPs are transparent to multicast Connectivity Verification.
对于多播，连接性验证功能测试多目标分发树的所有分支和叶节点的可达性。该功能应包括防止回复风暴压倒起始RBridge的机制。例如，可以通过在响应的RBridge上引入具有预设上限的随机延迟定时器（CFM[802.1Q]对Linktrace应答消息使用类似的机制来减轻原始MEP上的负载）来交错应答。OAM解决方案应选择定时器值的上限，使其足够长，以适应大型分布树，同时允许在合理的时间内完成连接验证操作。为了进一步防止回复风暴，连接验证操作从MEP启动，并且必须仅针对MEP。MIP对多播连接验证是透明的。
Per [RFC6905], multicast Connectivity Verification must provide the following granularity of operation:
根据[RFC6905]，多播连接验证必须提供以下操作粒度：
A. Un-pruned Tree
未修剪的树
- Connectivity Verification for un-pruned multi-destination distribution tree. The operator in this case supplies the tree identifier (root nickname) and campus-wide diagnostic VLAN or fine-grained label.
- 未修剪多目标分发树的连接验证。在这种情况下，操作员提供树标识符（根昵称）和校园范围的诊断VLAN或细粒度标签。
B. Pruned Tree
修剪过的树
- Connectivity Verification for a VLAN or fine-grain label in a given multi-destination distribution tree. The operator in this case supplies the tree identifier and VLAN or fine-grained label.
- 给定多目标分发树中VLAN或细粒度标签的连接验证。本例中的操作员提供树标识符和VLAN或细粒度标签。
- Connectivity Verification for an IP multicast group in a given multi-destination distribution tree. The operator in this case supplies: the tree identifier, VLAN or fine-grained label, and IP (S,G) or (*,G).
- 给定多目标分发树中IP多播组的连接验证。本例中的操作员提供：树标识符、VLAN或细粒度标签以及IP（S，G）或（*，G）。
TRILL OAM must support an on-demand connectivity fault localization function. This is the capability to trace the path of a flow on a hop-by-hop (RBridge-by-RBridge) basis to isolate failures. This involves the capability to narrow down the locality of a fault to a particular port, link, or node. The characteristic of forward/reverse path asymmetry, in TRILL, renders Fault Isolation into a direction-sensitive operation. That is, given two RBridges, A
TRILL OAM必须支持按需连接故障定位功能。这是一种基于逐跳（RBridge by RBridge）跟踪流路径以隔离故障的能力。这涉及到将故障位置缩小到特定端口、链路或节点的能力。在颤音中，正向/反向路径不对称的特性使故障隔离成为方向敏感的操作。也就是说，给定两个RBridge，A
and B, localization of connectivity faults between them requires running Fault Isolation procedures from RBridge A to RBridge B as well as from RBridge B to RBridge A. Generally speaking, single-sided Fault Isolation is not possible in TRILL OAM.
和B，它们之间连接故障的定位需要运行从RBridge A到RBridge B以及从RBridge B到RBridge A的故障隔离程序。一般来说，TRILL OAM中不可能实现单侧故障隔离。
Furthermore, TRILL OAM should support Fault Isolation over distribution trees for both un-pruned as well as pruned trees. The former allows the tracing of all active branches of a tree, whereas the latter allows tracing of the active subset of branches associated with a given flow.
此外，TRILL OAM应支持未修剪树和修剪树的分布树故障隔离。前者允许跟踪树的所有活动分支，而后者允许跟踪与给定流关联的活动分支子集。
Performance monitoring functions are optional in TRILL OAM, per [RFC6905]. These functions can be performed both proactively and on-demand. Proactive management involves a scheduling function, where the performance monitoring probes can be triggered on a recurring basis. Since the basic performance monitoring functions involved are the same, we make no distinction between proactive and on-demand functions in this section.
根据[RFC6905]，TRILL OAM中的性能监控功能是可选的。这些功能可以主动执行，也可以按需执行。主动式管理涉及一个调度功能，在该功能中，可以定期触发性能监视探测。由于所涉及的基本性能监控功能是相同的，因此在本节中，我们不区分主动功能和按需功能。
Given that TRILL provides inherent support for multipoint-to-multipoint connectivity, then packet loss cannot be accurately measured by means of counting user data packets. This is because user packets can be delivered to more RBridges or more ports than are necessary (for example, due to broadcast, un-pruned multicast, or unknown unicast flooding). As such, a statistical means of approximating packet loss rate is required. This can be achieved by sending "synthetic" (TRILL OAM) packets that are counted only by those ports (MEPs) that are required to receive them. This provides a statistical approximation of the number of data frames lost, even with multipoint-to-multipoint connectivity. TRILL OAM mechanisms for synthetic packet loss measurement should follow the statistical considerations specified in [MEF35], especially with regard to the volume/frequency of synthetic traffic generation and associated impact on packet loss count accuracy.
鉴于TRILL为多点到多点连接提供了固有的支持，因此无法通过计算用户数据包来准确测量数据包丢失。这是因为用户数据包可以传送到比需要更多的RBridge或更多的端口（例如，由于广播、未删减的多播或未知的单播泛洪）。因此，需要近似分组丢失率的统计方法。这可以通过发送“合成”（TRILL OAM）数据包来实现，这些数据包仅由接收它们所需的端口（MEP）计数。这提供了丢失数据帧数量的统计近似值，即使在多点到多点连接的情况下也是如此。用于合成丢包测量的TRILL-OAM机制应遵循[MEF35]中规定的统计注意事项，特别是关于合成流量生成的量/频率以及对丢包计数准确性的相关影响。
Packet loss probes must be initiated from a MEP and must target a MEP. This function should be supported on sections, as defined in [RFC6905]. When packet loss is measured over a section, and the initiating MEP does not coincide with the edge (ingress) RBridge, the MEP must use the edge RBridge nickname instead of the local RBridge nickname on the associated loss measurement messages. The user must supply the edge RBridge nickname as part of the operation parameters.
数据包丢失探测必须从MEP启动，并且必须以MEP为目标。根据[RFC6905]中的定义，此功能应在节上得到支持。当在一个区段上测量数据包丢失，并且发起的MEP与边缘（入口）RBridge不一致时，MEP必须在相关的丢失测量消息上使用边缘RBridge昵称，而不是本地RBridge昵称。用户必须提供边缘RBridge昵称作为操作参数的一部分。
TRILL OAM mechanisms should support one-way and two-way Packet Loss Monitoring. In one-way monitoring, a source RBridge triggers Packet Loss Monitoring messages to a target RBridge, and the latter is responsible for calculating the loss in the direction from the source RBridge towards the target RBridge. In two-way monitoring, a source RBridge triggers Packet Loss Monitoring messages to a target RBridge, and the latter replies to the source with response messages. The source RBridge can then monitor packet loss in both directions (source to target and target to source).
TRILL OAM机制应支持单向和双向丢包监控。在单向监视中，源RBridge向目标RBridge触发分组丢失监视消息，目标RBridge负责计算从源RBridge到目标RBridge方向上的丢失。在双向监视中，源RBridge向目标RBridge触发丢包监视消息，目标RBridge用响应消息回复源。然后，源RBridge可以在两个方向（源到目标和目标到源）上监视数据包丢失。
Packet delay is measured by inserting timestamps in TRILL OAM packets. In order to ensure high accuracy of measurement, TRILL OAM must specify the timestamp location at fixed offsets within the OAM packet in order to facilitate hardware-based timestamping. Hardware implementations must implement the timestamping function as close to the wire as practical in order to maintain high accuracy.
通过在TRILL OAM数据包中插入时间戳来测量数据包延迟。为了确保测量的高精度，TRILL OAM必须在OAM数据包内的固定偏移量处指定时间戳位置，以便于基于硬件的时间戳。硬件实现必须尽可能靠近导线实现时间戳功能，以保持高精度。
TRILL OAM mechanisms should support one-way and two-way Packet Delay Monitoring. In one-way monitoring, a source RBridge triggers Packet Delay Monitoring messages to a target RBridge, and the latter is responsible for calculating the delay in the direction from the source RBridge towards the target RBridge. This requires synchronization of the clocks between the two RBridges. In two-way monitoring, a source RBridge triggers Packet Delay Monitoring messages to a target RBridge, and the latter replies to the source with response messages. The source RBridge can then monitor packet delay in both directions (source to target and target to source) as well as the cumulative round-trip delay. In this case as well, monitoring the delay in a single direction requires clock synchronization between the two RBridges, whereas monitoring the round-trip delay does not require clock synchronization. Mechanisms for clock synchronization between RBridges are outside the scope of this document.
TRILL OAM机制应支持单向和双向数据包延迟监控。在单向监视中，源RBridge触发到目标RBridge的包延迟监视消息，目标RBridge负责计算从源RBridge到目标RBridge方向上的延迟。这需要两个RBridge之间的时钟同步。在双向监视中，源RBridge向目标RBridge触发数据包延迟监视消息，目标RBridge用响应消息回复源。然后，源RBridge可以监视两个方向（源到目标和目标到源）上的数据包延迟以及累积往返延迟。在这种情况下，监测单个方向上的延迟需要两个RBridge之间的时钟同步，而监测往返延迟不需要时钟同步。RBridge之间的时钟同步机制不在本文档范围内。
RBridges may be configured to enable TRILL OAM functions via the device Command Line Interface (CLI) or through one of the defined management protocols, such as the Simple Network Management Protocol (SNMP) [RFC3410] or the Network Configuration Protocol (NETCONF) [RFC6241].
RBridge可配置为通过设备命令行界面（CLI）或通过定义的管理协议之一（例如简单网络管理协议（SNMP）[RFC3410]或网络配置协议（NETCONF）[RFC6241]）启用TRILL OAM功能。
In order to maintain the plug-and-play characteristics of TRILL, the number of parameters that need to be configured on RBridges, in order to activate TRILL OAM, should be kept to a minimum. To that end, TRILL OAM mechanisms should rely on default values and auto-discovery mechanisms (for example, leveraging IS-IS) where applicable. The following is a non-exhaustive list of configuration parameters that apply to TRILL OAM.
为了保持TRILL的即插即用特性，为了激活TRILL OAM，需要在RBridges上配置的参数数量应保持在最低限度。为此，TRILL OAM机制应在适用的情况下依赖默认值和自动发现机制（例如，利用IS-IS）。以下是适用于TRILL OAM的配置参数的非详尽列表。
- Maintenance Domain Name An alphanumeric name for the Maintenance Domain. This is an IETF [RFC2579] DisplayString, with the exception that character codes 0-31 (decimal) are not used. The recommended default value is the character string "DEFAULT".
- 维护域名维护域的字母数字名称。这是一个IETF[RFC2579]显示字符串，但不使用字符代码0-31（十进制）。建议的默认值是字符串“default”。
- Maintenance Domain Level An integer in the range 0 to 7 indicating the level at which the Maintenance Domain is to be created. Default value is 0.
- 维护域级别0到7之间的整数，表示要创建维护域的级别。默认值为0。
- MA Name An alphanumeric name that uniquely identifies the Maintenance Association. This is an IETF [RFC2579] DisplayString, with the exception that character codes 0-31 (decimal) are not used. The recommended default value is a character string set to the value of the VLAN or fine-grained label as "vl" or "fgl" concatenated with the VLAN ID or FGL ID as an unsigned decimal integer, for example, "vl42".
- MA名称唯一标识维护关联的字母数字名称。这是一个IETF[RFC2579]显示字符串，但不使用字符代码0-31（十进制）。建议的默认值是一个字符串，设置为VLAN或细粒度标签的值“vl”或“fgl”，并将VLAN ID或fgl ID连接为无符号十进制整数，例如“vl42”。
- List of MEP Identifiers A list of the identifiers of the MEPs that belong to the MA. This is optional and required only if the operator wants to detect missing MEPs as part of the Continuity Check function.
- MEP标识符列表属于MA的MEP标识符列表。这是可选的，仅当操作员希望检测缺失的MEP作为连续性检查功能的一部分时才需要。
- MEP Identifier An integer, unique over a given Maintenance Association, identifying a specific MEP. CFM [802.1Q] limits this to the range 1 to 8191. This document recommends expanding the range from 1 to 65535 so that the RBridge nickname can be used as a default value. This will help keep TRILL OAM low-touch in terms of configuration overhead.
- MEP标识符在给定维护关联上唯一的整数，用于标识特定MEP。CFM[802.1Q]将其限制在1到8191的范围内。本文档建议将范围从1扩展到65535，以便RBridge昵称可以用作默认值。这将有助于保持TRILL OAM在配置开销方面的低接触。
- Direction Indicates whether this is an UP MEP or DOWN MEP.
- 方向指示这是向上MEP还是向下MEP。
- Associated Interface Specifies the interface on which the MEP is configured.
- 关联接口指定配置MEP的接口。
- MA Context Specifies the Maintenance Association to which the MEP belongs.
- MA上下文指定MEP所属的维护关联。
- Transmission Interval Indicates the interval at which Continuity Check messages are sent by a MEP.
- 传输间隔表示MEP发送连续性检查消息的间隔。
- Loss Threshold Indicates the number of consecutive Continuity Check messages that a MEP must not receive from any one of the other MEPs in its MA before indicating either a MEP failure or a network failure. Recommended default value is 3.
- 丢失阈值表示MEP在指示MEP故障或网络故障之前，不得从其MA中的任何一个其他MEP接收的连续性检查消息数。建议的默认值为3。
- VLAN, Fine-Grained Label, and Flow Parameters The VLAN or fine-grained label and flow parameters to be used in the Continuity Check messages.
- VLAN、细粒度标签和流参数—要在连续性检查消息中使用的VLAN或细粒度标签和流参数。
- Hop Count The hop count to be used in the Continuity Check messages.
- 跃点计数要在连续性检查消息中使用的跃点计数。
- MA context Specifies the Maintenance Association in which the Connectivity Verification operation is to be performed.
- MA上下文指定要在其中执行连接验证操作的维护关联。
- Target RBridge Nickname (unicast), Tree Identifier (multicast), and IP Multicast Group For unicast, the nickname of the RBridge that is the target of the Connectivity Verification operation. For multicast, the target Tree Identifier for un-pruned tree verification or the Tree Identifier and IP multicast group (S, G) or (*, G) for pruned tree verification.
- 目标RBridge昵称（单播）、树标识符（多播）和单播的IP多播组，是连接验证操作的目标RBridge的昵称。对于多播，用于未修剪树验证的目标树标识符，或用于修剪树验证的树标识符和IP多播组（S，G）或（*，G）。
- VLAN, Fine-Grained Label, and Flow Parameters The VLAN or fine-grained label and flow parameters to be used in the Connectivity Verification message.
- VLAN、细粒度标签和流参数连接验证消息中要使用的VLAN或细粒度标签和流参数。
- Operation Timeout Value The timeout on the initiating MEP before the Connectivity Verification operation is declared to have failed. The recommended default value is 5 seconds.
- Operation Timeout Value在宣布连接验证操作失败之前，启动MEP的超时时间。建议的默认值为5秒。
- Repeat Count The number of Connectivity Verification messages that must be transmitted per operation. The recommended default value is 1.
- 重复计算每个操作必须传输的连接验证消息数。建议的默认值为1。
- Hop Count The hop count to be used in the Connectivity Verification messages.
- 跃点计数要在连接验证消息中使用的跃点计数。
- Reply Mode Indicates whether the response to the Connectivity Verification operation should be sent in-band or out-of-band.
- 回复模式指示对连接验证操作的响应应在带内还是带外发送。
- Scope List (Multicast) List of MEP Identifiers that must respond to the message.
- 必须响应消息的MEP标识符的作用域列表（多播）列表。
- MA Context Specifies the Maintenance Association in which the Fault Isolation operation is to be performed.
- MA上下文指定要在其中执行故障隔离操作的维护关联。
- Target RBridge Nickname (unicast), Tree Identifier (multicast), and IP Multicast Group For unicast, the nickname of the RBridge that is the target of the Fault Isolation operation. For multicast, the target Tree Identifier for un-pruned tree tracing or the Tree Identifier and IP multicast group (S, G) or (*, G) for pruned tree tracing.
- 目标RBridge昵称（单播）、树标识符（多播）和单播的IP多播组，作为故障隔离操作目标的RBridge的昵称。对于多播，用于未修剪树跟踪的目标树标识符，或用于修剪树跟踪的树标识符和IP多播组（S，G）或（*，G）。
- VLAN, Fine-Grained Label, and Flow Parameters The VLAN or fine-grain label and flow parameters to be used in the Fault Isolation messages.
- VLAN、细粒度标签和流参数要在故障隔离消息中使用的VLAN或细粒度标签和流参数。
- Operation Timeout Value The timeout on the initiating MEP before the Fault Isolation operation is declared to have failed. The recommended default value is 5 seconds.
- 操作超时值在宣布故障隔离操作失败之前，启动MEP上的超时。建议的默认值为5秒。
- Hop Count The hop count to be used in the Fault Isolation messages.
- 跃点计数要在故障隔离消息中使用的跃点计数。
- Reply Mode Indicates whether the response to the Fault Isolation operation should be sent in-band or out-of-band.
- 应答模式指示对故障隔离操作的响应应在带内还是带外发送。
- Scope List (Multicast) List of MEP Identifiers that must respond to the message.
- 必须响应消息的MEP标识符的作用域列表（多播）列表。
- MA Context Specifies the Maintenance Association in which the Packet Loss Monitoring operation is to be performed.
- MA上下文指定要在其中执行分组丢失监视操作的维护关联。
- Target RBridge Nickname The nickname of the RBridge that is the target of the Packet Loss Monitoring operation.
- Target RBridge昵称作为数据包丢失监视操作目标的RBridge的昵称。
- VLAN, Fine-Grained Label, and Flow Parameters The VLAN or fine-grained label and flow parameters to be used in the Packet Loss Monitoring messages.
- VLAN、细粒度标签和流参数要在数据包丢失监视消息中使用的VLAN或细粒度标签和流参数。
- Transmission Rate The transmission rate at which the Packet Loss Monitoring messages are to be sent.
- 传输速率发送丢包监控消息的传输速率。
- Monitoring Interval The total duration of time for which a single Packet Loss Monitoring probe is to continue.
- Monitoring Interval单个数据包丢失监视探测将继续的总持续时间。
- Repeat Count The number of probe operations to be performed. For on-demand monitoring, this is typically set to 1. For proactive monitoring, this may be set to allow for infinite monitoring.
- 重复计算要执行的探针操作数。对于按需监控，这通常设置为1。对于主动监控，可以将其设置为允许无限监控。
- Hop Count The hop count to be used in the Packet Loss Monitoring messages.
- 跃点计数要在数据包丢失监视消息中使用的跃点计数。
- Mode Indicates whether one-way or two-way loss measurement is required.
- 模式指示是否需要进行单向或双向损耗测量。
- MA Context Specifies the Maintenance Association in which the Packet Delay Monitoring operation is to be performed
- MA上下文指定要在其中执行数据包延迟监视操作的维护关联
- Target RBridge Nickname The nickname of the RBridge that is the target of the Packet Delay Monitoring operation.
- Target RBridge昵称作为数据包延迟监视操作目标的RBridge的昵称。
- VLAN, Fine-Grained Label, and Flow Parameters The VLAN or fine-grained label and flow parameters to be used in the Packet Delay Monitoring messages.
- VLAN、细粒度标签和流参数在数据包延迟监视消息中使用的VLAN或细粒度标签和流参数。
- Transmission Rate The transmission rate at which the Packet Delay Monitoring messages are to be sent.
- 传输速率发送数据包延迟监控消息的传输速率。
- Monitoring Interval The total duration of time for which a single Packet Delay Monitoring probe is to continue.
- Monitoring Interval单个数据包延迟监视探测将继续的总持续时间。
- Repeat Count The number of probe operations to be performed. For on-demand monitoring, this is typically set to 1. For proactive monitoring this may be set to allow for infinite monitoring.
- 重复计算要执行的探针操作数。对于按需监控，这通常设置为1。对于主动监控，可将其设置为允许无限监控。
- Hop Count The hop count to be used in the Packet Delay Monitoring messages.
- 跃点计数要在数据包延迟监视消息中使用的跃点计数。
- Mode Indicates whether one-way or two-way delay measurement is required.
- 模式指示是否需要单向或双向延迟测量。
TRILL OAM mechanisms should trigger notifications to alert operators to certain conditions. Such conditions include but are not limited to:
TRILL OAM机制应触发通知，提醒操作员注意某些情况。此类条件包括但不限于：
- Faults detected by proactive mechanisms.
- 主动机制检测到的故障。
- Reception of event-driven defect indications.
- 接收事件驱动的缺陷指示。
- Logged security incidents pertaining to the OAM Message Channel.
- 记录的与OAM消息通道有关的安全事件。
- Protocol errors (for example, as caused by misconfiguration).
- 协议错误（例如，由错误配置引起的错误）。
Notifications generated by TRILL OAM mechanisms may be via SNMP, Syslog messages [RFC5424], or any other standard management protocol that supports asynchronous notifications.
TRILL OAM机制生成的通知可以通过SNMP、系统日志消息[RFC5424]或支持异步通知的任何其他标准管理协议生成。
When performing the optional TRILL OAM performance monitoring functions, two RBridge designations are involved: a source RBridge and a target RBridge. The source RBridge is the one from which the performance monitoring probe is initiated, and the target RBridge is the destination of the probe. The goal is to monitor performance characteristics between the two RBridges. The RBridge from which the
在执行可选TRILL OAM性能监视功能时，涉及两个RBridge指定：源RBridge和目标RBridge。源RBridge是启动性能监视探测的源RBridge，目标RBridge是探测的目标RBridge。目标是监控两个RBridge之间的性能特征。从中删除的RBridge
network operator can extract the results of the probe (the performance monitoring metrics) depends on whether one-way or two-way performance monitoring functions are performed:
网络运营商可以提取探测结果（性能监测指标），这取决于是否执行单向或双向性能监测功能：
- In the case of one-way performance monitoring functions, the metrics will be available at the target RBridge.
- 对于单向性能监控功能，指标将在目标RBridge上可用。
- In the case of two-way performance monitoring functions, all the metrics will be available at the source RBridge, and a subset will be available at the target RBridge. More specifically, metrics in the direction from source to target as well as the direction from target to source will be available at the source RBridge. Metrics in the direction from source to target will be available at the target RBridge.
- 在双向性能监控功能的情况下，所有指标将在源RBridge上可用，而子集将在目标RBridge上可用。更具体地说，源RBridge将提供源到目标以及目标到源方向的度量。从源到目标方向的指标将在目标RBridge上可用。
TRILL OAM must provide mechanisms for:
TRILL OAM必须提供以下机制：
- Preventing denial-of-service attacks caused by exploitation of the OAM Message Channel, where a rogue device may overload the RBridges and the network with OAM messages. This could lead to interruption of the OAM services and, in the extreme case, disrupt network connectivity. Mechanisms such as control-plane policing combined with shaping or rate limiting of OAM messaging can be employed to mitigate this.
- 防止因利用OAM消息通道而导致的拒绝服务攻击，其中恶意设备可能会使用OAM消息使RBridge和网络过载。这可能导致OAM服务中断，在极端情况下，还会中断网络连接。可以采用诸如控制平面策略与OAM消息的成形或速率限制相结合的机制来缓解这种情况。
- Optionally authenticating at communicating endpoints (MEPs and MIPs) that an OAM message has originated at an appropriate communicating endpoint.
- 可选地，在通信端点（MEP和MIP）验证OAM消息是否已在适当的通信端点发出。
- Preventing TRILL OAM packets from leaking outside of the TRILL network or outside their corresponding Maintenance Domain. This can be done by having MEPs implement a filtering function based on the Maintenance Level associated with received OAM packets.
- 防止TRILL OAM数据包泄漏到TRILL网络之外或其相应的维护域之外。这可以通过让mep基于与接收到的OAM分组相关联的维护级别实现过滤功能来实现。
For general TRILL Security Considerations, see [RFC6325].
有关一般TRILL安全注意事项，请参阅[RFC6325]。
We thank Gayle Noble, Dan Romascanu, Olen Stokes, Susan Hares, Ali Karimi, and Prabhu Raj for their thorough review of this work and their comments.
我们感谢盖尔·诺布尔、丹·罗马斯坎努、奥伦·斯托克斯、苏珊·哈雷斯、阿里·卡里米和普拉布·拉吉对这项工作的全面审查和评论。
[802] IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Overview and Architecture", IEEE Std 802-2001, 8 March 2002.
[802]IEEE，“IEEE局域网和城域网标准-概述和体系结构”，IEEE标准802-2001，2002年3月8日。
[802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridge Local Area Networks", IEEE Std 802.1Q-2011, 31 August 2011.
[802.1Q]IEEE，“局域网和城域网IEEE标准-媒体访问控制（MAC）网桥和虚拟网桥局域网”，IEEE标准802.1Q-2011，2011年8月31日。
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
[RFC2544]Bradner，S.和J.McQuaid，“网络互连设备的基准测试方法”，RFC 2544，1999年3月。
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579]McCloghrie，K.，Ed.，Perkins，D.，Ed.，和J.Schoenwaeld，Ed.“SMIv2的文本约定”，STD 58，RFC 2579，1999年4月。
[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.
[RFC6291]Andersson，L.，van Helvoort，H.，Bonica，R.，Romascanu，D.，和S.Mansfield，“IETF中“OAM”首字母缩写词的使用指南”，BCP 161，RFC 62912011年6月。
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011.
[RFC6325]帕尔曼，R.，伊斯特莱克第三，D.，杜特，D.，盖伊，S.，和A.加瓦尼，“路由桥（RBridges）：基本协议规范”，RFC6325，2011年7月。
[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.
[RFC6905]Senevirathne，T.，Bond，D.，Aldrin，S.，Li，Y.，和R.Watve，“大量链路透明互连（TRILL）中的操作、管理和维护（OAM）要求”，RFC 69052013年3月。
[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.
[RFC7172]Eastlake 3rd，D.，Zhang，M.，Agarwal，P.，Perlman，R和D.Dutt，“大量链路的透明互连（TRILL）：细粒度标记”，RFC 7172，2014年5月。
[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, May 2014.
[RFC7177]Eastlake 3rd，D.，Perlman，R.，Ghanwani，A.，Yang，H.，和V.Manral，“大量链路的透明互连（TRILL）：邻接”，RFC 7177，2014年5月。
[802.3] IEEE, "IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", IEEE Std 802.3-2012, December 2012.
[802.3]IEEE，“IEEE信息技术标准-系统间电信和信息交换-局域网和城域网-特定要求-第3部分：带冲突检测的载波侦听多址（CSMA/CD）接入方法和物理层规范”，IEEE标准802.3-2012，2012年12月。
[ISO/IEC7498-4] ISO/IEC, "Information processing systems -- Open Systems Interconnection -- Basic Reference Model -- Part 4: Management framework", ISO/IEC 7498-4, 1989.
[ISO/IEC7498-4]ISO/IEC，“信息处理系统——开放系统互连——基本参考模型——第4部分：管理框架”，ISO/IEC 7498-42089。
[MEF35] Metro Ethernet Forum, "MEF 35 - Service OAM Performance Monitoring Implementation Agreement", April 2012.
[MEF35]城域以太网论坛，“MEF 35-业务OAM性能监控实施协议”，2012年4月。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.，编辑，“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410]Case，J.，Mundy，R.，Partain，D.，和B.Stewart，“互联网标准管理框架的介绍和适用性声明”，RFC 34102002年12月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379]Kompella，K.和G.Swallow，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，2006年2月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424]Gerhards，R.，“系统日志协议”，RFC 54242009年3月。
[RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010.
[RFC5860]Vigoureux，M.，Ed.，Ward，D.，Ed.，和M.Betts，Ed.，“MPLS传输网络中的操作、管理和维护（OAM）要求”，RFC 58602010年5月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880]Katz，D.和D.Ward，“双向转发检测（BFD）”，RFC 58802010年6月。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011.
[RFC6241]Enns，R.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.“网络配置协议（NETCONF）”，RFC 62412011年6月。
[RFC6361] Carlson, J. and D. Eastlake 3rd, "PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol", RFC 6361, August 2011.
[RFC6361]Carlson，J.和D.Eastlake 3rd，“大量链路的PPP透明互连（TRILL）协议控制协议”，RFC 63612011年8月。
[RFC6371] Busi, I., Ed., and D. Allan, Ed., "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011.
[RFC6371]Busi，I.，Ed.和D.Allan，Ed.“基于MPLS的传输网络的操作、管理和维护框架”，RFC 63712011年9月。
[RFC7087] van Helvoort, H., Ed., Andersson, L., Ed., and N. Sprecher, Ed., "A Thesaurus for the Interpretation of Terminology Used in MPLS Transport Profile (MPLS-TP) Internet-Drafts and RFCs in the Context of the ITU-T's Transport Network Recommendations", RFC 7087, December 2013.
[RFC7087]van Helvoort，H.，Ed.，Andersson，L.，Ed.，和N.Sprecher，Ed.，“在ITU-T传输网络建议的背景下，解释MPLS传输配置文件（MPLS-TP）互联网草案和RFC中使用的术语的同义词表”，RFC 7087，2013年12月。
[RFC7175] Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support", RFC 7175, May 2014.
[RFC7175]Manral，V.，Eastlake 3rd，D.，Ward，D.，和A.Banerjee，“大量链路的透明互连（TRILL）：双向转发检测（BFD）支持”，RFC 7175，2014年5月。
[TRILL-IP] Wasserman, M, Eastlake 3rd, D., and D. Zhang, "Transparent Interconnection of Lots of Links (TRILL) over IP", Work in Progress, March 2014.
[TRILL-IP]Wasserman，M，Eastlake 3rd，D.和D.Zhang，“IP上大量链路的透明互连（TRILL）”，正在进行的工作，2014年3月。
[TRILL-ML] Perlman, R., Eastlake 3rd, D., Ghanwani, A., and H. Zhai, "Flexible Multilevel TRILL (Transparent Interconnection of Lots of Links)", Work in Progress, January 2014.
[TRILL-ML]Perlman，R.，Eastlake 3rd，D.，Ghanwani，A.，和H.Zhai，“灵活多级TRILL（大量链路的透明互连）”，正在进行的工作，2014年1月。
[TRILL-OAM] Senevirathne, T., Salam, S., Kumar, D, Eastlake 3rd, D., Aldrin, S., and Y. Li, "TRILL Fault Management", Work in Progress, February 2014.
[TRILL-OAM]Senevirathne，T.，Salam，S.，Kumar，D，Eastlake 3rd，D.，Aldrin，S.，和Y.Li，“TRILL故障管理”，在建工程，2014年2月。
[Y.1731] ITU-T, "OAM functions and mechanisms for Ethernet based networks", ITU-T Recommendation Y.1731, February 2008.
[Y.1731]ITU-T，“基于以太网的网络的OAM功能和机制”，ITU-T建议Y.17312008年2月。
Authors' Addresses
作者地址
Samer Salam Cisco 595 Burrard Street, Suite 2123 Vancouver, BC V7X 1J1 Canada
加拿大不列颠哥伦比亚省温哥华市伯拉德街595号2123室Samer Salam Cisco V7X 1J1
EMail: ssalam@cisco.com
EMail: ssalam@cisco.com
Tissa Senevirathne Cisco 375 East Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞东塔斯曼大道375号，邮编95134
EMail: tsenevir@cisco.com
EMail: tsenevir@cisco.com
Sam Aldrin Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 USA
美国加利福尼亚州圣克拉拉中央高速公路2330号Sam Aldrin华为技术公司，邮编95050
EMail: sam.aldrin@gmail.com
EMail: sam.aldrin@gmail.com
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA
美国马萨诸塞州米尔福德市比弗街155号唐纳德东湖第三华为技术有限公司01757
Phone: 1-508-333-2270 EMail: d3e3e3@gmail.com
电话：1-508-333-2270电子邮件：d3e3e3@gmail.com