Internet Engineering Task Force (IETF) T. Senevirathne
Request for Comments: 6905 Cisco
Category: Informational D. Bond
ISSN: 2070-1721 IBM
S. Aldrin
Y. Li
Huawei
R. Watve
Cisco
March 2013
Internet Engineering Task Force (IETF) T. Senevirathne
Request for Comments: 6905 Cisco
Category: Informational D. Bond
ISSN: 2070-1721 IBM
S. Aldrin
Y. Li
Huawei
R. Watve
Cisco
March 2013
Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL)
大量链路透明互连（TRILL）中的操作、管理和维护（OAM）要求
Abstract
摘要
Operations, Administration, and Maintenance (OAM) is a general term used to identify functions and toolsets to troubleshoot and monitor networks. This document presents OAM requirements applicable to the Transparent Interconnection of Lots of Links (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/rfc6905.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6905.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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 ....................................................3
1.1. Scope ......................................................3
2. Conventions Used in This Document ...............................3
3. Terminology .....................................................3
4. OAM Requirements ................................................4
4.1. Data Plane .................................................4
4.2. Connectivity Verification ..................................5
4.2.1. Unicast .............................................5
4.2.2. Distribution Trees ..................................5
4.3. Continuity Check ...........................................5
4.4. Path Tracing ...............................................6
4.5. General Requirements .......................................6
4.6. Performance Monitoring .....................................7
4.6.1. Packet Loss .........................................7
4.6.2. Packet Delay ........................................7
4.7. ECMP Utilization ...........................................8
4.8. Security and Operational Considerations ....................8
4.9. Fault Indications ..........................................8
4.10. Defect Indications ........................................9
4.11. Live Traffic Monitoring ...................................9
5. Security Considerations .........................................9
6. References ......................................................9
6.1. Normative References .......................................9
6.2. Informative References ....................................10
7. Acknowledgments ................................................11
8. Contributors ...................................................11
1. Introduction ....................................................3
1.1. Scope ......................................................3
2. Conventions Used in This Document ...............................3
3. Terminology .....................................................3
4. OAM Requirements ................................................4
4.1. Data Plane .................................................4
4.2. Connectivity Verification ..................................5
4.2.1. Unicast .............................................5
4.2.2. Distribution Trees ..................................5
4.3. Continuity Check ...........................................5
4.4. Path Tracing ...............................................6
4.5. General Requirements .......................................6
4.6. Performance Monitoring .....................................7
4.6.1. Packet Loss .........................................7
4.6.2. Packet Delay ........................................7
4.7. ECMP Utilization ...........................................8
4.8. Security and Operational Considerations ....................8
4.9. Fault Indications ..........................................8
4.10. Defect Indications ........................................9
4.11. Live Traffic Monitoring ...................................9
5. Security Considerations .........................................9
6. References ......................................................9
6.1. Normative References .......................................9
6.2. Informative References ....................................10
7. Acknowledgments ................................................11
8. Contributors ...................................................11
The Operations, Administration, and Maintenance (OAM) generally covers various production aspects of a network. In this document, we use the term OAM as defined in [RFC6291].
操作、管理和维护（OAM）通常涵盖网络的各个生产方面。在本文档中，我们使用[RFC6291]中定义的术语OAM。
The success of network operations depends on the ability to proactively monitor it for faults, performance, etc., as well as the ability to efficiently and quickly troubleshoot defects and failures. A well-defined OAM toolset is a vital requirement for wider adoption of Transparent Interconnection of Lots of Links (TRILL) as the next generation data-forwarding technology in larger networks such as data centers.
网络运营的成功取决于主动监控故障、性能等的能力，以及高效快速地排除缺陷和故障的能力。定义良好的OAM工具集是更广泛地采用大量链路透明互连（TRILL）作为大型网络（如数据中心）中的下一代数据转发技术的关键要求。
In this document, we define the requirements for TRILL OAM. It is assumed that the readers are familiar with the OAM concepts and terminologies defined in other OAM standards such as [8021ag], [RFC5860], and [RFC4377]. This document does not attempt to redefine the terms and concepts specified elsewhere.
在本文档中，我们定义了TRILL OAM的需求。假设读者熟悉[8021ag]、[RFC5860]和[RFC4377]等其他OAM标准中定义的OAM概念和术语。本文件不试图重新定义其他地方指定的术语和概念。
The scope of this document is OAM between Routing Bridges (RBridges) of a TRILL campus over links selected by TRILL routing.
本文档的范围是TRILL校园的路由桥（RBridges）之间通过TRILL路由选择的链路进行OAM。
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]. Although this document is not a protocol specification, the use of this language clarifies the instructions to protocol designers producing solutions that satisfy the requirements set out in this document.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。尽管本文件不是协议规范，但本语言的使用澄清了协议设计师的指示，以生产满足本文件规定要求的解决方案。
Section: This term refers to a segment of a path between any two given RBridges. As an example, consider the case where RB1 is connected to RBx via RB2, RB3, and RB4. The segment between RB2 to RB4 is referred to as a section of the path RB1 to RBx. More details of this definition can be found in [RFC5960].
区段：该术语是指任意两个给定脊线之间的路径段。作为一个例子，考虑RB1通过RB2、RB3和RB4连接到RBX的情况。RB2到RB4之间的段称为路径RB1到RBx的一部分。有关此定义的更多详细信息，请参见[RFC5960]。
Flow: This term indicates a set of packets that share the same path and per-hop behavior (such as priority). A flow is typically identified by a portion of the inner payload that affects the hop-by-hop forwarding decisions. This may contain Layer 2 through Layer 4 information.
流：该术语表示共享相同路径和每跳行为（如优先级）的一组数据包。流通常由影响逐跳转发决策的内部有效负载的一部分来标识。这可能包含第2层到第4层的信息。
All Selectable Least-Cost Paths: This term refers to a subset of all potentially available least-cost paths to a specified destination RBridge that are available (and usable) for forwarding of frames. It is important to note that in practice, due to limitations in implementations, not all available least-cost paths may be selectable for forwarding.
所有可选择的最低成本路径：该术语是指到指定目标RBridge的所有潜在可用最低成本路径的子集，这些路径可用于（和可用）帧转发。需要注意的是，在实践中，由于实现中的限制，并非所有可用的最低成本路径都可以选择用于转发。
Connectivity: This term indicates reachability between an arbitrary RBridge RB1 and any other RBridge RB2. The specific path can be either explicit (i.e., associated with a specific flow) or unspecified. Unspecified means that messages used for connectivity verification take whatever path the RBs happen to select. Please refer to [OAMOVER] for details.
连通性：该术语表示任意RBridge RB1和任何其他RBridge RB2之间的可达性。特定路径可以是显式的（即与特定流关联）或未指定的。未指定意味着用于连接验证的消息采用RBs碰巧选择的任何路径。有关详细信息，请参阅[OAMOVER]。
Continuity Verification: This term refers to proactive verification of liveliness between two RBridges at periodic intervals and the generation of explicit notification when connectivity failures occur. Please refer to [OAMOVER] for details.
连续性验证：该术语指定期对两个RBridge之间的活动性进行主动验证，并在发生连接故障时生成显式通知。有关详细信息，请参阅[OAMOVER]。
Fault: This term refers to an inability to perform a required action, e.g., an unsuccessful attempt to deliver a packet. Please refer to [TERMTP] for definition.
故障：该术语指无法执行所需的操作，例如，试图传递数据包失败。有关定义，请参考[TERMTP]。
Defect: This term refers to an interruption in the normal operation, such that over a period of time no packets are delivered successfully. Please refer to [TERMTP] for definition.
缺陷：这一术语指的是正常操作中的中断，在一段时间内没有成功发送数据包。有关定义，请参考[TERMTP]。
Failure: This term refers to the termination of the required function over a longer period of time. Persistence of a defect for a period of time is interpreted as a failure. Please refer to [TERMTP] for definition.
故障：该术语指在较长时间内终止所需功能。缺陷持续一段时间被解释为失败。有关定义，请参考[TERMTP]。
Simulated Flow: This term refers to a sequence of OAM-generated packets designed to follow a specific path. The fields of the packets in the simulated flow may or may not be identical to the fields of data packets of an actual flow being simulated. However, the purpose of the simulated flow is to have OAM packets of the simulated flow follow a specific path.
模拟流：这个术语是指OAM生成的数据包序列，这些数据包被设计为遵循特定的路径。模拟流中的分组字段可能与正在模拟的实际流的数据分组字段相同，也可能不同。然而，模拟流的目的是使模拟流的OAM分组遵循特定路径。
OAM frames, utilized for connectivity verification, continuity checks, performance measurements, etc., will by default take whatever path TRILL chooses based on the current topology and per-hop equal-cost path choices. In some cases, it may be required that the OAM
用于连接验证、连续性检查、性能测量等的OAM帧在默认情况下将采用TRILL根据当前拓扑和每跳等成本路径选择选择的任何路径。在某些情况下，可能要求OAM
frames utilize specific paths. Thus, it MUST be possible to arrange that OAM frames follow the path taken by a specific flow.
帧利用特定的路径。因此，必须能够安排OAM帧跟随特定流所采取的路径。
RBridges MUST have the ability to identify frames that require OAM processing.
RBridges必须能够识别需要OAM处理的帧。
TRILL OAM frames MUST remain within a TRILL campus and MUST NOT be egressed from a TRILL network as native frames.
TRILL OAM帧必须保持在TRILL校园内，并且不得作为本机帧从TRILL网络中退出。
OAM MUST have the ability to include all Ethernet traffic types carried by TRILL.
OAM必须能够包括TRILL承载的所有以太网通信类型。
From an arbitrary RBridge RB1, OAM MUST have the ability to verify connectivity to any other RBridge RB2.
从任意RBridge RB1开始，OAM必须能够验证与任何其他RBridge RB2的连接。
From an arbitrary RBridge RB1, OAM MUST have the ability to verify connectivity to any other RBridge RB2 for a specific flow via the path associated with the specified flow.
从任意RBridge RB1开始，OAM必须能够通过与指定流关联的路径验证特定流与任何其他RBridge RB2的连接。
OAM MUST have the ability to verify connectivity from an arbitrary RBridge RB1 to either a specific set of RBridges or all member RBridges, for a specified distribution tree. This functionality is referred to as verification of the unpruned distribution tree.
对于指定的分发树，OAM必须能够验证从任意RBridge RB1到特定RBridge集或所有成员RBridge的连接。此功能称为未运行分发树的验证。
OAM MUST have the ability to verify connectivity from an arbitrary RBridge RB1 to either a specific set of RBridges or all member RBridges, for a specified distribution tree and for a specified flow. This functionality is referred to as verification of the pruned tree.
对于指定的分发树和指定的流，OAM必须能够验证从任意RBridge RB1到特定RBridge集或所有成员RBridge的连接。此功能称为修剪树的验证。
OAM MUST provide functions that allow any arbitrary RBridge RB1 to perform a Continuity Check to any other RBridge.
OAM必须提供允许任意RBridge RB1对任何其他RBridge执行连续性检查的功能。
OAM MUST provide functions that allow any arbitrary RBridge RB1 to perform a Continuity Check to any other RBridge using a path associated with a specified flow.
OAM必须提供允许任意RBridge RB1使用与指定流关联的路径对任何其他RBridge执行连续性检查的功能。
OAM SHOULD provide functions that allow any arbitrary RBridge to perform a Continuity Check to any other RBridge over any section of any selectable least-cost path.
OAM应提供允许任意RBridge在任何可选最低成本路径的任何部分上对任何其他RBridge执行连续性检查的功能。
OAM SHOULD provide the ability to perform a Continuity Check on sections of any selectable path within the network.
OAM应提供对网络内任何可选路径的部分执行连续性检查的能力。
OAM SHOULD provide the ability to perform a multicast Continuity Check for specified distribution tree(s), as well as specified combinations of distribution trees and flows. The former is referred to as an unpruned multi-destination tree Continuity Check and the latter is referred to as a pruned tree Continuity Check.
OAM应该能够对指定的分发树以及分发树和流的指定组合执行多播连续性检查。前者称为未运行的多目标树连续性检查，后者称为修剪树连续性检查。
OAM MUST provide the ability to trace a path between any two RBridges corresponding to a specified unicast flow.
OAM必须提供跟踪与指定单播流对应的任意两个RBridge之间的路径的能力。
OAM SHOULD provide the ability to trace all selectable least-cost paths between any two RBridges.
OAM应提供跟踪任意两个RBridge之间所有可选择的最低成本路径的能力。
OAM SHOULD provide functionality to trace all branches of a specified distribution tree (unpruned tree).
OAM应该提供跟踪指定分发树（未运行的树）的所有分支的功能。
OAM SHOULD provide functionality to trace all branches of a specified distribution tree for a specified flow (pruned tree).
OAM应该提供跟踪指定流（修剪树）的指定分发树的所有分支的功能。
OAM MUST provide the ability to initiate and maintain multiple concurrent sessions for multiple OAM functions between any arbitrary RBridge RB1 to any other RBridge. In general, multiple OAM operations will run concurrently. For example, proactive continuity checks may take place between RB1 and RB2 at the same time that an operator decides to test connectivity between the same two RBs. Multiple OAM functions and instances of those functions MUST be able to run concurrently without interfering with each other.
OAM必须能够为任意RBridge RB1到任何其他RBridge之间的多个OAM功能启动和维护多个并发会话。通常，多个OAM操作将同时运行。例如，当运营商决定测试同两个RB之间的连接时，RB1和RB2之间可能同时进行主动连续性检查。多个OAM函数和这些函数的实例必须能够在不相互干扰的情况下并发运行。
OAM MUST provide a single OAM framework for all TRILL OAM functions within the scope of this document.
OAM必须为本文档范围内的所有TRILL OAM功能提供单个OAM框架。
OAM, as practical and as possible, SHOULD reuse functional, operational, and semantic elements of existing OAM standards.
OAM应该尽可能地重用现有OAM标准的功能、操作和语义元素。
OAM MUST maintain related error and operational counters. Such counters MUST be accessible via network management applications (e.g., SNMP).
OAM必须维护相关的错误和操作计数器。此类计数器必须可通过网络管理应用程序（如SNMP）访问。
OAM functions related to continuity and connectivity checks MUST be able to be invoked either proactively or on demand.
必须能够主动或按需调用与连续性和连接检查相关的OAM功能。
OAM MAY be required to provide the ability to specify a desired response mode for a specific OAM message. The desired response mode can be in-band, out-of-band, or none.
OAM可能需要提供为特定OAM消息指定所需响应模式的能力。所需的响应模式可以是带内、带外或无。
The OAM Framework MUST be extensible to include new functionality. For example, the solution needs to include a version number to differentiate older and newer implementations and TLV structures for flexibility to include new information elements.
OAM框架必须是可扩展的，以包含新的功能。例如，解决方案需要包含一个版本号，以区分较旧和较新的实现，以及TLV结构，以便灵活地包含新的信息元素。
OAM MAY provide methods to verify control-plane and forwarding-plane alignments.
OAM可以提供验证控制平面和转发平面对齐的方法。
OAM SHOULD leverage existing OAM technologies, where practical.
如果可行，OAM应该利用现有的OAM技术。
In this document, the term "packet loss" is used as defined in Section 2.4 of [RFC2680].
在本文件中，术语“数据包丢失”的定义见[RFC2680]第2.4节。
OAM SHOULD provide the ability to measure packet loss statistics for a flow from any arbitrary RBridge RB1 to any other RBridge.
OAM应该能够测量从任意RBridge RB1到任何其他RBridge的流的丢包统计数据。
OAM SHOULD provide the ability to measure packet loss statistics over a section for a flow between any arbitrary RBridge RB1 to any other RBridge.
OAM应提供在任意RBridge RB1到任何其他RBridge之间的流的一个部分上测量数据包丢失统计信息的能力。
OAM SHOULD provide the ability to measure packet loss statistics between any two RBridges over all least-cost paths.
OAM应该能够在所有成本最低的路径上测量任意两个RBridge之间的数据包丢失统计信息。
An RBridge SHOULD be able to perform the above packet loss measurement functions either proactively or on demand.
RBridge应能够主动或按需执行上述丢包测量功能。
There are two types of packet delays -- one-way delay and two-way delay (Round-Trip Delay).
有两种类型的数据包延迟——单向延迟和双向延迟（往返延迟）。
One-way delay is defined in [RFC2679] as the time elapsed from the start of transmission of the first bit of a packet by an RBridge until the reception of the last bit of the packet by the destination RBridge.
[RFC2679]将单向延迟定义为从RBridge开始传输数据包的第一位到目的RBridge接收数据包的最后一位所经过的时间。
Two-way delay is also referred to as Round-Trip Delay and is defined similar to [RFC2681]; i.e., the time elapsed from the start of transmission of the first bit of a packet from RB1, receipt of the packet at RB2, RB2 sending a response packet back to RB1, and RB1 receiving the last bit of that response packet.
双向延迟也称为往返延迟，其定义类似于[RFC2681]；i、 例如，从开始从RB1发送分组的第一位、在RB2接收分组、RB2向RB1发送响应分组以及RB1接收该响应分组的最后一位所经过的时间。
OAM SHOULD provide functions to measure two-way delay between two RBridges.
OAM应提供测量两个RBridge之间双向延迟的功能。
OAM MAY provide functions to measure one-way delay between two RBridges for a specified flow.
OAM可以提供用于测量指定流的两个RBridge之间的单向延迟的功能。
OAM MAY provide functions to measure one-way delay between two RBridges for a specified flow over a specific section.
OAM可提供用于测量特定区段上指定流量的两个RBridge之间的单向延迟的功能。
OAM MAY provide functionality to monitor the effectiveness of per-hop Equal-Cost Multipath (ECMP) hashing. For example, individual RBridges could maintain counters that show how packets are being distributed across equal-cost next hops for a specified destination RBridge or RBridges as a result of ECMP hashing.
OAM可以提供监视每跳等成本多路径（ECMP）散列的有效性的功能。例如，单个RBridge可以维护计数器，这些计数器显示由于ECMP散列，数据包如何分布在指定目的地RBridge或RBridge的等成本下一个跃点上。
Methods MUST be provided to protect against exploitation of OAM framework for security and denial-of-service attacks.
必须提供方法以防止OAM框架被利用进行安全和拒绝服务攻击。
Methods MUST be provided to prevent OAM messages from causing congestion in the networks. Periodically generated messages with high frequencies may lead to congestion, hence methods such as shaping or rate limiting SHOULD be utilized.
必须提供防止OAM消息在网络中造成拥塞的方法。周期性生成的高频消息可能导致拥塞，因此应采用整形或速率限制等方法。
Certain OAM functions may be utilized to gather operational information such as topology of the network. Methods MUST be provided to prevent unauthorized users accessing OAM functions to gather critical and sensitive information of the network.
某些OAM功能可用于收集诸如网络拓扑之类的操作信息。必须提供防止未经授权的用户访问OAM功能以收集网络的关键和敏感信息的方法。
OAM packets MUST be limited to within the TRILL campus, and the implementation MUST provide methods to prevent leaking of OAM packets out of the TRILL campus. Additionally, methods MUST be provided to prevent accepting OAM packets from outside the TRILL campus.
OAM数据包必须限制在TRILL园区内，并且实现必须提供防止OAM数据包泄漏出TRILL园区的方法。此外，必须提供防止从TRILL校园外部接受OAM数据包的方法。
OAM MUST provide a Fault Indication framework to notify the packet's ingress RBridge or other interested parties (such as syslog servers) about faults.
OAM必须提供故障指示框架，以通知数据包的入口RBridge或其他相关方（如syslog服务器）有关故障。
OAM MUST provide functions to selectively enable or disable different types of Fault Indications.
OAM必须提供有选择地启用或禁用不同类型故障指示的功能。
OAM SHOULD provide a framework for Defect Detection and Indication.
OAM应提供缺陷检测和指示的框架。
OAM Defect Detection and Indication Framework SHOULD provide methods to selectively enable or disable Defect Detection per defect type.
OAM缺陷检测和指示框架应提供有选择地启用或禁用每种缺陷类型的缺陷检测的方法。
OAM Defect Detection and Indication Framework SHOULD provide methods to configure Defect Detection thresholds per different types of defects.
OAM缺陷检测和指示框架应提供根据不同类型的缺陷配置缺陷检测阈值的方法。
OAM Defect Detection and Indication Framework SHOULD provide methods to log defect indications to a locally defined archive (such as log buffer) or Simple Network Management Protocol (SNMP) traps.
OAM缺陷检测和指示框架应提供将缺陷指示记录到本地定义的归档（如日志缓冲区）或简单网络管理协议（SNMP）陷阱的方法。
OAM Defect Detection and Indication Framework SHOULD provide a Remote Defect Indication framework that facilitates notifying the originator/owner of the flow experiencing the defect, which is the ingress RBridge.
OAM缺陷检测和指示框架应提供远程缺陷指示框架，该框架有助于通知发起人/所有者遇到缺陷的流，即入口RBridge。
Remote Defect Indication MAY be either in-band or out-of-band.
远程缺陷指示可以是带内或带外。
OAM implementations MAY provide methods to utilize live traffic for troubleshooting and performance monitoring.
OAM实现可以提供利用实时流量进行故障排除和性能监视的方法。
Security requirements are specified in Section 4.8. For general TRILL security considerations, please refer to [RFC6325].
第4.8节规定了安全要求。有关一般TRILL安全注意事项，请参阅[RFC6325]。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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月。
[8021ag] IEEE, "Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault Management", IEEE Std 802.1ag-2007, 2007.
[8021ag]IEEE，“虚拟桥接局域网修正案5：连接故障管理”，IEEE标准802.1ag-2007，2007年。
[OAMOVER] Mizrahi, T., Sprecher, N., Bellagamba, E., Y. Weingarten, "An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms", Work in Progress, January 2013.
[OAM]Mizrahi，T.，Sprecher，N.，Bellagamba，E.，Y.Weingarten，“运营、管理和维护（OAM）机制概述”，进展中的工作，2013年1月。
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2679]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的单向延迟度量”，RFC 2679，1999年9月。
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2680]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的单向数据包丢失度量”，RFC 2680，1999年9月。
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999.
[RFC2681]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的往返延迟度量”，RFC 2681，1999年9月。
[RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. Matsushima, "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006.
[RFC4377]Nadeau，T.，Morrow，M.，Swallow，G.，Allan，D.，和S.Matsushima，“多协议标签交换（MPLS）网络的运营和管理（OAM）要求”，RFC 4377，2006年2月。
[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月。
[RFC5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS Transport Profile Data Plane Architecture", RFC 5960, August 2010.
[RFC5960]Frost，D.，Ed.，Bryant，S.，Ed.，和M.Bocci，Ed.，“MPLS传输配置文件数据平面架构”，RFC 59602010年8月。
[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月。
[TERMTP] van Helvoort, H., Ed., Andersson, L., Ed., and N. Sprecher, Ed., "A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T' Transport Network Recommendations", Work in Progress, February 2013.
[TERMTP]van Helvoort，H.，Ed.，Andersson，L.，Ed.，和N.Sprecher，Ed.，“多协议标签交换传输配置文件（MPLS-TP）草案/RFC和ITU-T‘传输网络建议’中使用的术语词典”，正在进行的工作，2013年2月。
Special acknowledgments to IEEE 802.1 chair, Tony Jeffree, for allowing us to solicit comments from IEEE 802.1 group. Also recognized are the comments received from the IEEE group, IESG, Stewart Bryant, Ralph Droms, Adrian Farrel, Benoit Claise, Ayal Lior, and others.
特别感谢IEEE 802.1主席Tony Jeffree允许我们征求IEEE 802.1集团的意见。此外，IEEE集团、IESG、Stewart Bryant、Ralph Droms、Adrian Farrel、Benoit Claise、Ayal Lior和其他人的评论也得到了认可。
Thomas Narten IBM Corporation 3039 Cornwallis Avenue, PO Box 12195 Research Triangle Park, NC 27709 USA
美国北卡罗来纳州研究三角公园康沃利斯大道3039号邮政信箱12195托马斯·纳腾IBM公司，邮编27709
EMail:narten@us.ibm.com
电邮：narten@us.ibm.com
Donald Eastlake Huawei Technologies 155 Beaver Street, Milford, MA 01757 USA
美国马萨诸塞州米尔福德市海狸街155号唐纳德东湖华为技术有限公司01757
EMail: d3e3e3@gmail.com
EMail: d3e3e3@gmail.com
Anoop Ghanwani Dell 350 Holger Way San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市霍尔格大道350号Anoop Ghanwani Dell，邮编95134
Phone: +1-408-571-3500
EMail: Anoop@alumni.duke.edu
Phone: +1-408-571-3500
EMail: Anoop@alumni.duke.edu
Jon Hudson Brocade 120 Holger Way San Jose, CA 95134 USA
Jon Hudson Brocade美国加利福尼亚州圣何塞霍尔格大道120号，邮编95134
EMail: jon.hudson@gmail.com
EMail: jon.hudson@gmail.com
Naveen Nimmu Broadcom 9th Floor, Building no 9, Raheja Mind space Hi-Tec City, Madhapur, Hyderabad - 500 081 India
Naveen Nimmu Broadcom印度海得拉巴Madhapur Raheja Mind space高科技城9号楼9楼-500 081
Phone: +1-408-218-8893
EMail: naveen@broadcom.com
Phone: +1-408-218-8893
EMail: naveen@broadcom.com
Radia Perlman Intel Labs 2700 156th Ave NE, Suite 300, Bellevue, WA 98007 USA
Radia Perlman英特尔实验室2700美国华盛顿州贝尔维尤第156大道东北300号套房，邮编：98007
Phone: +1-425-881-4824
EMail: radia.perlman@intel.com
Phone: +1-425-881-4824
EMail: radia.perlman@intel.com
Tal Mizrahi Marvell 6 Hamada St. Yokneam, 20692 Israel
Tal Mizrahi Marvell 6 Hamada St.Yokneam，20692以色列
EMail: talmi@marvell.com
EMail: talmi@marvell.com
Authors' Addresses
作者地址
Tissa Senevirathne Cisco Systems 375 East Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞东塔斯曼大道375号，邮编95134
Phone: +1-408-853-2291
EMail: tsenevir@cisco.com
Phone: +1-408-853-2291
EMail: tsenevir@cisco.com
David Bond IBM 4400 North 1st Street San Jose, CA 95134 USA
David Bond IBM 4400美国加利福尼亚州圣何塞北第一街95134号
Phone: +1-603-339-7575
EMail: mokon@mokon.net
Phone: +1-603-339-7575
EMail: mokon@mokon.net
Sam Aldrin Huawei Technologies 2330 Central Express Way Santa Clara, CA 95951 USA
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
Rohit Watve Cisco Systems 375 East Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市东塔斯曼大道375号罗希特沃特夫思科系统公司，邮编95134
Phone: +1-408-424-2091
EMail: rwatve@cisco.com
Phone: +1-408-424-2091
EMail: rwatve@cisco.com