Internet Engineering Task Force (IETF) M. Vigoureux, Ed.
Request for Comments: 5860 Alcatel-Lucent
Category: Standards Track D. Ward, Ed.
ISSN: 2070-1721 Juniper Networks
M. Betts, Ed.
M. C. Betts Consulting Ltd.
May 2010
Internet Engineering Task Force (IETF) M. Vigoureux, Ed.
Request for Comments: 5860 Alcatel-Lucent
Category: Standards Track D. Ward, Ed.
ISSN: 2070-1721 Juniper Networks
M. Betts, Ed.
M. C. Betts Consulting Ltd.
May 2010
Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks
MPLS传输网络中的操作、管理和维护（OAM）要求
Abstract
摘要
This document lists architectural and functional requirements for the Operations, Administration, and Maintenance of MPLS Transport Profile. These requirements apply to pseudowires, Label Switched Paths, and Sections.
本文档列出了MPLS传输配置文件的操作、管理和维护的体系结构和功能要求。这些要求适用于伪导线、标签交换路径和截面。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5860.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5860.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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 of This Document . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language and Terminology . . . . . . . . . . 4
2. OAM Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Architectural Requirements . . . . . . . . . . . . . . . . 6
2.1.1. Scope of OAM . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. Independence . . . . . . . . . . . . . . . . . . . . . 6
2.1.3. Data Plane . . . . . . . . . . . . . . . . . . . . . . 7
2.1.4. OAM and IP Capabilities . . . . . . . . . . . . . . . 7
2.1.5. Interoperability and Interworking . . . . . . . . . . 8
2.1.6. Configuration . . . . . . . . . . . . . . . . . . . . 8
2.2. Functional Requirements . . . . . . . . . . . . . . . . . 9
2.2.1. General Requirements . . . . . . . . . . . . . . . . . 9
2.2.2. Continuity Checks . . . . . . . . . . . . . . . . . . 10
2.2.3. Connectivity Verifications . . . . . . . . . . . . . . 10
2.2.4. Route Tracing . . . . . . . . . . . . . . . . . . . . 11
2.2.5. Diagnostic Tests . . . . . . . . . . . . . . . . . . . 11
2.2.6. Lock Instruct . . . . . . . . . . . . . . . . . . . . 11
2.2.7. Lock Reporting . . . . . . . . . . . . . . . . . . . . 12
2.2.8. Alarm Reporting . . . . . . . . . . . . . . . . . . . 12
2.2.9. Remote Defect Indication . . . . . . . . . . . . . . . 13
2.2.10. Client Failure Indication . . . . . . . . . . . . . . 13
2.2.11. Packet Loss Measurement . . . . . . . . . . . . . . . 13
2.2.12. Packet Delay Measurement . . . . . . . . . . . . . . . 14
3. Congestion Considerations . . . . . . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Normative References . . . . . . . . . . . . . . . . . . . 16
6.2. Informative References . . . . . . . . . . . . . . . . . . 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope of This Document . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language and Terminology . . . . . . . . . . 4
2. OAM Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Architectural Requirements . . . . . . . . . . . . . . . . 6
2.1.1. Scope of OAM . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. Independence . . . . . . . . . . . . . . . . . . . . . 6
2.1.3. Data Plane . . . . . . . . . . . . . . . . . . . . . . 7
2.1.4. OAM and IP Capabilities . . . . . . . . . . . . . . . 7
2.1.5. Interoperability and Interworking . . . . . . . . . . 8
2.1.6. Configuration . . . . . . . . . . . . . . . . . . . . 8
2.2. Functional Requirements . . . . . . . . . . . . . . . . . 9
2.2.1. General Requirements . . . . . . . . . . . . . . . . . 9
2.2.2. Continuity Checks . . . . . . . . . . . . . . . . . . 10
2.2.3. Connectivity Verifications . . . . . . . . . . . . . . 10
2.2.4. Route Tracing . . . . . . . . . . . . . . . . . . . . 11
2.2.5. Diagnostic Tests . . . . . . . . . . . . . . . . . . . 11
2.2.6. Lock Instruct . . . . . . . . . . . . . . . . . . . . 11
2.2.7. Lock Reporting . . . . . . . . . . . . . . . . . . . . 12
2.2.8. Alarm Reporting . . . . . . . . . . . . . . . . . . . 12
2.2.9. Remote Defect Indication . . . . . . . . . . . . . . . 13
2.2.10. Client Failure Indication . . . . . . . . . . . . . . 13
2.2.11. Packet Loss Measurement . . . . . . . . . . . . . . . 13
2.2.12. Packet Delay Measurement . . . . . . . . . . . . . . . 14
3. Congestion Considerations . . . . . . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Normative References . . . . . . . . . . . . . . . . . . . 16
6.2. Informative References . . . . . . . . . . . . . . . . . . 16
In the context of MPLS Transport Profile (MPLS-TP, see [9] and [1]), the rationales for Operations, Administration, and Maintenance (OAM) are twofold as it can serve:
在MPLS传输配置文件（MPLS-TP，见[9]和[1]）的上下文中，操作、管理和维护（OAM）的原理有两方面，因为它可以服务于：
o as a network-oriented functionality, used by a transport network operator to monitor his network infrastructure and to implement internal mechanisms in order to enhance the general behavior and the level of performance of his network (e.g., protection mechanism in case of node or link failure). As an example, fault localization is typically associated with this use case.
o 作为面向网络的功能，由传输网络运营商用于监控其网络基础设施和实施内部机制，以增强其网络的一般行为和性能水平（例如，节点或链路故障时的保护机制）。例如，故障定位通常与此用例相关联。
o as a service-oriented functionality, used by a transport service provider to monitor services offered to end customers in order to be able to react rapidly in case of a problem and to be able to verify some of the Service Level Agreement (SLA) parameters (e.g., using performance monitoring) negotiated with the end customers. Note that a transport service could be provided over several networks or administrative domains that may not all be owned and managed by the same transport service provider.
o 作为一种面向服务的功能，由运输服务提供商用于监控向最终客户提供的服务，以便在出现问题时能够快速做出反应，并能够验证与最终客户协商的一些服务水平协议（SLA）参数（例如，使用性能监控）。请注意，可以通过多个网络或管理域提供传输服务，这些网络或管理域可能并非全部由同一传输服务提供商拥有和管理。
More generally, OAM is an important and fundamental functionality in transport networks as it contributes to:
更一般地说，OAM是传输网络中一项重要的基本功能，因为它有助于：
o the reduction of operational complexity and costs, by allowing for efficient and automatic detection, localization, and handling and diagnosis of defects, as well as by minimizing service interruptions and operational repair times.
o 通过允许对缺陷进行高效、自动的检测、定位、处理和诊断，以及通过最小化服务中断和运营维修时间，降低运营复杂性和成本。
o the enhancement of network availability, by ensuring that defects (for example, those resulting in misdirected customer traffic) and faults are detected, diagnosed, and dealt with before a customer reports the problem.
o 通过确保在客户报告问题之前检测、诊断和处理缺陷（例如，导致客户流量错误的缺陷）和故障，从而提高网络可用性。
o meeting service and performance objectives, as the OAM functionality allows for SLA verification in a multi-maintenance domain environment and allows for the determination of service degradation due, for example, to packet delay or packet loss.
o 满足服务和性能目标，因为OAM功能允许在多维护域环境中进行SLA验证，并允许确定例如由于数据包延迟或数据包丢失而导致的服务降级。
This document lists architectural and functional requirements for the OAM functionality of MPLS-TP. These requirements apply to pseudowires (PWs), Label Switched Paths (LSPs), and Sections.
本文档列出了MPLS-TP的OAM功能的体系结构和功能需求。这些要求适用于伪导线（PW）、标签交换路径（LSP）和截面。
These requirements are derived from the set of requirements specified by ITU-T and published in the ITU-T Supplement Y.Sup4 [10].
这些要求源自ITU-T规定的一组要求，并在ITU-T补编Y.Sup4[10]中发布。
By covering transport specificities, these requirements complement those identified in RFC 4377 [11]; yet, some requirements may be similar.
通过涵盖运输特殊性，这些要求补充了RFC 4377[11]中确定的要求；然而，有些要求可能是类似的。
This document only lists architectural and functional OAM requirements. It does not detail the implications of their applicability to the various types (e.g., point-to-point, point-to-multipoint, unidirectional, bidirectional, etc.) of PWs, LSPs, and Sections. Furthermore, this document does not provide requirements on how the protocol solution(s) should behave to achieve the functional objectives. Please see [12] for further information.
本文档仅列出了体系结构和功能OAM需求。本节未详细说明其适用于PWs、LSP和区段的各种类型（例如，点对点、点对多点、单向、双向等）的含义。此外，本文件未提供协议解决方案如何实现功能目标的要求。有关更多信息，请参见[12]。
Note that the OAM functions identified in this document may be used for fault-management, performance-monitoring, and/or protection-switching applications. For example, connectivity verification can be used for fault management by detecting failure conditions, but may also be used for performance monitoring through its contribution to the evaluation of performance metrics (e.g., unavailability time). Nevertheless, it is outside the scope of this document to specify which function should be used for which application.
注意，本文件中确定的OAM功能可用于故障管理、性能监控和/或保护切换应用。例如，连通性验证可通过检测故障条件用于故障管理，但也可通过其对性能指标评估的贡献（例如，不可用时间）用于性能监控。尽管如此，本文件的范围不包括指定应用程序应使用的功能。
Note also that it is anticipated that implementers may wish to implement OAM message handling in hardware. Although not a requirement, this fact could be taken as a design consideration.
还请注意，预计实现者可能希望在硬件中实现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 [2]. 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[2]中所述进行解释。尽管本文件不是协议规范，但本语言的使用澄清了协议设计师的指示，以生产满足本文件规定要求的解决方案。
In this document, we:
在本文件中，我们：
o refer to the inability of a function to perform a required action as a fault. This does not include an inability due to preventive maintenance, lack of external resources, or planned actions. See also ITU-T G.806 [3].
o 将功能无法执行所需操作视为故障。这不包括由于预防性维护、缺乏外部资源或计划的行动而导致的无能力。另见ITU-T G.806[3]。
o refer to the situation in which the density of anomalies has reached a level where the ability to perform a required function has been interrupted as a defect. See also ITU-T G.806 [3].
o 指异常密度达到某一水平时，执行所需功能的能力因缺陷而中断的情况。另见ITU-T G.806[3]。
o refer to OAM actions that are carried out continuously or at least over long periods of time, permitting proactive reporting of fault and/or performance results as proactive OAM.
o 指连续或至少长时间执行的OAM操作，允许作为主动OAM主动报告故障和/或性能结果。
o refer to OAM actions that are initiated via manual intervention for a limited time to carry out troubleshooting as on-demand OAM.
o 请参阅在有限时间内通过手动干预启动的OAM操作，以作为按需OAM执行故障排除。
o refer to a Label Edge Router (LER), for a given LSP or Section, and to a PW Terminating Provider Edge (T-PE), for a given PW, as an End Point. Further, we refer to a Label Switching Router (LSR), for a given LSP, and to a PW Switching Provider Edge (S-PE), for a given PW, as an Intermediate Point. This document does not make a distinction between End Points (e.g., source and destination) as it can be inferred from the context of the sentences.
o 对于给定的LSP或部分，请参考标签边缘路由器（LER），对于给定的PW，请参考PW端接提供程序边缘（T-PE），作为端点。此外，对于给定的LSP，我们将标签交换路由器（LSR）作为中间点，对于给定的PW，我们将PW交换提供程序边缘（S-PE）作为中间点。本文件不区分端点（例如，来源和目的地），因为它可以从句子的上下文中推断出来。
o use the term "node" as a general reference to End Points and Intermediate Points.
o 使用术语“节点”作为端点和中间点的一般参考。
o refer to both segment and concatenated segments as segments (see [1] for definitions relating to the term "segment" as well as for other definitions relating to MPLS-TP).
o 将段和连接段都称为段（有关术语“段”的定义以及与MPLS-TP相关的其他定义，请参见[1]）。
o refer to both single segment PWs and multi-segment PWs as PWs.
o 将单段PWs和多段PWs都称为PWs。
o refer to both bidirectional associated LSPs and bidirectional co-routed LSPs as bidirectional LSPs.
o 将双向关联LSP和双向共路由LSP都称为双向LSP。
This section lists the requirements by which the OAM functionality of MPLS-TP should abide.
本节列出了MPLS-TP的OAM功能应遵守的要求。
The requirements listed below may be met by one or more OAM protocols; the definition or selection of these protocols is outside the scope of this document.
一个或多个OAM协议可以满足以下列出的要求；这些协议的定义或选择不在本文件范围内。
RFC 5654 [1] states (Requirement #2) that the MPLS-TP design, SHOULD as far as reasonably possible, reuse existing MPLS standards. This general requirement applies to MPLS-TP OAM. MPLS-TP OAM is defined in this document through a set of functional requirements. These requirements will be met by protocol solutions defined in other documents. The way in which those protocols are operated and the way in which a network operator can control and use the MPLS-TP OAM functions SHOULD be as similar as possible to the mechanisms and techniques used to operate OAM in other transport technologies.
RFC 5654[1]规定（要求2），MPLS-TP设计应尽可能合理地重用现有MPLS标准。此一般要求适用于MPLS-TP OAM。MPLS-TP OAM在本文档中通过一组功能需求进行定义。其他文件中定义的协议解决方案将满足这些要求。这些协议的操作方式以及网络运营商控制和使用MPLS-TP OAM功能的方式应尽可能类似于其他传输技术中用于操作OAM的机制和技术。
The protocol solution(s) developed to meet the requirements identified in this document MUST at least be applicable to point-to-point bidirectional PWs, point-to-point co-routed bidirectional LSPs, and point-to-point bidirectional Sections. Section 2.2 provides additional information with regard to the applicability to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs.
为满足本文件中确定的要求而开发的协议解决方案必须至少适用于点对点双向PWs、点对点共路由双向LSP和点对点双向段。第2.2节提供了关于点对点关联双向LSP、点对点单向LSP和点对多点LSP适用性的附加信息。
The service emulated by a PW may span multiple domains. An LSP may also span multiple domains. The protocol solution(s) MUST be applicable to end-to-end and to segments. More generally, it MUST be possible to operate OAM functions on a per-domain basis and across multiple domains.
PW模拟的服务可能跨越多个域。LSP也可以跨越多个域。协议解决方案必须适用于端到端和段。更一般地说，必须能够在每个域的基础上跨多个域运行OAM功能。
Since LSPs may be stacked, the protocol solution(s) MUST be applicable on any LSP, regardless of the label stack depth. Furthermore, it MUST be possible to estimate OAM fault and performance metrics of a single PW or LSP segment or of an aggregate of PW or LSP segments.
由于LSP可以堆叠，协议解决方案必须适用于任何LSP，无论标签堆叠深度如何。此外，必须能够估计单个PW或LSP段或PW或LSP段集合的OAM故障和性能指标。
The protocol solution(s) SHOULD be independent of the underlying tunneling or point-to-point technology or transmission media.
协议解决方案应独立于底层隧道或点对点技术或传输介质。
The protocol solution(s) SHOULD be independent of the service a PW may emulate.
协议解决方案应独立于PW可能模拟的服务。
Any OAM function operated on a PW, LSP, or Section SHOULD be independent of the OAM function(s) operated on a different PW, LSP, or Section. In other words, only the OAM functions operated on a given LSP (for example) should be used to achieve the OAM objectives for that LSP.
在PW、LSP或区段上运行的任何OAM功能应独立于在不同PW、LSP或区段上运行的OAM功能。换句话说，只有在给定LSP上运行的OAM功能（例如）才应该用于实现该LSP的OAM目标。
The protocol solution(s) MUST support the capability to be concurrently and independently operated end-to-end and on segments. Therefore, any OAM function applied to segment(s) of a PW or LSP SHOULD be independent of the OAM function(s) operated on the end-to-end PW or LSP. It SHOULD also be possible to distinguish an OAM packet running over a segment of a PW or LSP from another OAM packet running on the end-to-end PW or LSP.
协议解决方案必须支持在端到端和段上同时独立运行的能力。因此，应用于PW或LSP段的任何OAM功能应独立于端到端PW或LSP上运行的OAM功能。还应该能够区分在PW或LSP段上运行的OAM分组与在端到端PW或LSP上运行的另一OAM分组。
Furthermore, any OAM function applied to segment(s) of a PW or LSP SHOULD be independent of the OAM function(s) applied to other segment(s) of the same PW or LSP.
此外，应用于PW或LSP的段的任何OAM功能应独立于应用于相同PW或LSP的其他段的OAM功能。
Note: Independence should not be understood in terms of isolation as there can be interactions between OAM functions operated, for example, on two different LSPs.
注：独立性不应理解为隔离，因为在两个不同的LSP上运行的OAM功能之间可能存在交互。
OAM functions operate in the data plane. OAM packets MUST run in-band; that is, OAM packets for a specific PW, LSP, or Section MUST follow the exact same data path as user traffic of that PW, LSP, or Section. This is often referred to as fate sharing.
OAM功能在数据平面中运行。OAM数据包必须在频带内运行；也就是说，特定PW、LSP或部分的OAM数据包必须遵循与该PW、LSP或部分的用户流量完全相同的数据路径。这通常被称为命运分享。
It MUST be possible to discriminate user traffic from OAM packets. This includes a means to differentiate OAM packets from user traffic as well as the capability to apply specific treatment to OAM packets, at the nodes processing these OAM packets.
必须能够区分用户流量和OAM数据包。这包括将OAM分组与用户流量区分开来的方法，以及在处理这些OAM分组的节点处对OAM分组应用特定处理的能力。
As part of the design of OAM protocol solution(s) for MPLS-TP, a mechanism for enabling the encapsulation and differentiation of OAM messages on a PW, LSP, or Section, MUST be provided. Such mechanism SHOULD also support the encapsulation and differentiation of existing IP/MPLS and PW OAM messages.
作为MPLS-TP OAM协议解决方案设计的一部分，必须提供一种机制，用于在PW、LSP或段上封装和区分OAM消息。这种机制还应该支持现有IP/MPLS和PW OAM消息的封装和区分。
There are environments where IP capabilities are present in the data plane. IP/MPLS environments are examples of such environments. There are also environments where IP capabilities may not be present in the data plane. MPLS-TP environments are examples of environments where IP capabilities might or might not be present.
有些环境中，IP功能存在于数据平面中。IP/MPLS环境就是此类环境的示例。在某些环境中，数据平面中可能不存在IP功能。MPLS-TP环境是IP功能可能存在或不存在的环境示例。
Note: Presence or absence of IP capabilities is deployment scenario dependent.
注意：IP功能的存在与否取决于部署场景。
It MUST be possible to deploy the OAM functionality in any of these environments. As a result, it MUST be possible to operate OAM functions with or without relying on IP capabilities, and it MUST be possible to choose to make use of IP capabilities when these are present.
必须能够在任何这些环境中部署OAM功能。因此，必须能够使用或不使用IP功能来运行OAM功能，并且必须能够在存在IP功能时选择使用这些功能。
Furthermore, the mechanism required for enabling the encapsulation and differentiation of OAM messages (see Section 2.1.3) MUST support the capability to differentiate OAM messages of an OAM function
此外，启用OAM消息的封装和区分所需的机制（参见第2.1.3节）必须支持区分OAM功能的OAM消息的能力
operated by relying on IP capabilities (e.g., using encapsulation in an IP header) from OAM messages of an OAM function operated without relying on any IP capability.
通过依赖于来自OAM功能的OAM消息的IP能力（例如，在IP报头中使用封装）来操作，该OAM功能在不依赖任何IP能力的情况下操作。
Note that IP capabilities include the capability to form a standard IP header, to encapsulate a payload in an IP header, to parse and analyze the fields of an IP header, and to take actions based on the content of these fields.
请注意，IP功能包括形成标准IP报头、将有效负载封装在IP报头中、解析和分析IP报头的字段以及根据这些字段的内容采取操作的功能。
For certain functions, OAM messages need to incorporate identification information (e.g., of source and/or destination nodes). The protocol solution(s) MUST at least support identification information in the form of an IP addressing structure and MUST also be extensible to support additional identification schemes.
对于某些功能，OAM消息需要包含标识信息（例如，源和/或目标节点的标识信息）。协议解决方案必须至少支持IP寻址结构形式的标识信息，并且必须可扩展以支持其他标识方案。
It is REQUIRED that OAM interoperability is achieved between distinct domains materializing the environments described in Section 2.1.4. It is also REQUIRED that the first two requirements of Section 2.1.4 still hold and MUST still be met when interoperability is achieved.
要求在实现第2.1.4节所述环境的不同域之间实现OAM互操作性。还要求第2.1.4节的前两个要求仍然有效，并且在实现互操作性时必须满足。
When MPLS-TP is run with IP routing and forwarding capabilities, it MUST be possible to operate any of the existing IP/MPLS and PW OAM protocols (e.g., LSP-Ping [4], MPLS-BFD [13], VCCV [5], and VCCV-BFD [14]).
当使用IP路由和转发功能运行MPLS-TP时，必须能够操作任何现有的IP/MPLS和PW OAM协议（例如，LSP Ping[4]、MPLS-BFD[13]、VCCV[5]和VCCV-BFD[14]）。
OAM functions MUST operate and be configurable even in the absence of a control plane. Conversely, it SHOULD be possible to configure as well as enable/disable the capability to operate OAM functions as part of connectivity management, and it SHOULD also be possible to configure as well as enable/disable the capability to operate OAM functions after connectivity has been established.
即使在没有控制平面的情况下，OAM功能也必须运行并可配置。相反，作为连接管理的一部分，应该可以配置以及启用/禁用操作OAM功能的能力，并且还应该可以配置以及启用/禁用在建立连接后操作OAM功能的能力。
In the latter case, the customer MUST NOT perceive service degradation as a result of OAM enabling/disabling. Ideally, OAM enabling/disabling should take place without introducing any customer impairments (e.g., no customer packet losses). Procedures aimed to prevent any traffic impairment MUST be defined for the enabling/ disabling of OAM functions.
在后一种情况下，客户不得认为OAM启用/禁用会导致服务降级。理想情况下，OAM启用/禁用应该在不引入任何客户损害（例如，没有客户数据包丢失）的情况下进行。必须为OAM功能的启用/禁用定义旨在防止任何流量损害的程序。
Means for configuring OAM functions and for connectivity management are outside the scope of this document.
配置OAM功能和连接管理的方法不在本文档的范围内。
Hereafter are listed the required functionalities composing the MPLS-TP OAM toolset. The list may not be exhaustive and as such the OAM mechanisms developed in support of the identified requirements SHALL be extensible and thus SHALL NOT preclude the definition of additional OAM functionalities, in the future.
下文列出了构成MPLS-TP OAM工具集所需的功能。该列表可能并非详尽无遗，因此，为支持确定的需求而开发的OAM机制应是可扩展的，因此不应排除将来对附加OAM功能的定义。
The design of OAM mechanisms for MPLS-TP, MUST allow for the ability to support experimental OAM functions. These functions MUST be disabled by default.
MPLS-TP的OAM机制的设计必须考虑到支持实验性OAM功能的能力。默认情况下，必须禁用这些功能。
The use of any OAM function MUST be optional and it MUST be possible to select the set of OAM function(s) to use on any PW, LSP, or Section.
任何OAM功能的使用必须是可选的，并且必须能够选择在任何PW、LSP或区段上使用的OAM功能集。
It is RECOMMENDED that any protocol solution, meeting one or more functional requirement(s), be the same for PWs, LSPs, and Sections.
建议满足一个或多个功能要求的任何协议解决方案，对于PWs、LSP和章节应相同。
It is RECOMMENDED that any protocol solution, meeting one or more functional requirement(s), effectively provides a fully featured function; that is, a function that is applicable to all the cases identified for that functionality. In that context, protocol solution(s) MUST state their applicability.
建议满足一个或多个功能需求的任何协议解决方案有效地提供功能齐全的功能；即，适用于为该功能确定的所有情况的功能。在这种情况下，协议解决方案必须说明其适用性。
Unless otherwise stated, the OAM functionalities MUST NOT rely on user traffic; that is, only OAM messages MUST be used to achieve the objectives.
除非另有说明，否则OAM功能不得依赖于用户流量；也就是说，只有OAM消息才能用于实现目标。
For the on-demand OAM functions, the result of which may vary depending on packet size, it SHOULD be possible to perform these functions using different packet sizes.
对于按需OAM功能（其结果可能随数据包大小而变化），应该可以使用不同的数据包大小来执行这些功能。
If a defect or fault occurs on a PW, LSP, or Section, mechanisms MUST be provided to detect it, diagnose it, localize it, and notify the appropriate nodes. Mechanisms SHOULD exist such that corrective actions can be taken.
如果PW、LSP或区段出现缺陷或故障，则必须提供检测、诊断、定位和通知相应节点的机制。应存在能够采取纠正措施的机制。
Furthermore, mechanisms MUST be available for a service provider to be aware of a fault or defect affecting the service(s) he provides, even if the fault or defect is located outside of his domain.
此外，必须有机制让服务提供商知道影响其提供的服务的故障或缺陷，即使故障或缺陷位于其域之外。
Protocol solution(s) developed to meet these requirements may rely on information exchange. Information exchange between various nodes involved in the operation of an OAM function SHOULD be reliable such that, for example, defects or faults are properly detected or that state changes are effectively known by the appropriate nodes.
为满足这些要求而开发的协议解决方案可能依赖于信息交换。参与OAM功能操作的各个节点之间的信息交换应该是可靠的，例如，缺陷或故障被正确检测，或者状态变化被适当的节点有效地知道。
The MPLS-TP OAM toolset MUST provide a function to enable an End Point to monitor the liveness of a PW, LSP, or Section.
MPLS-TP OAM工具集必须提供一个功能，使端点能够监视PW、LSP或区段的活动性。
This function SHOULD be performed between End Points of PWs, LSPs, and Sections.
此功能应在PWs、LSP和截面的端点之间执行。
This function SHOULD be performed proactively.
应主动执行此功能。
The protocol solution(s) developed to perform this function MUST also apply to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs.
为执行此功能而开发的协议解决方案还必须适用于点对点关联的双向LSP、点对点单向LSP和点对多点LSP。
The MPLS-TP OAM toolset MUST provide a function to enable an End Point to determine whether or not it is connected to specific End Point(s) by means of the expected PW, LSP, or Section.
MPLS-TP OAM工具集必须提供一个功能，使端点能够确定它是否通过预期的PW、LSP或区段连接到特定的端点。
This function SHOULD be performed proactively between End Points of PWs, LSPs, and Sections.
应在PWs、LSP和区段的端点之间主动执行此功能。
This function SHOULD be performed on-demand between End Points and Intermediate Points of PWs and LSPs, and between End Points of PWs, LSPs, and Sections.
该功能应在PWs和LSP的端点和中间点之间，以及PWs、LSP和区段的端点之间按需执行。
The protocol solution(s) developed to perform this function proactively MUST also apply to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs.
为主动执行此功能而开发的协议解决方案还必须适用于点对点关联的双向LSP、点对点单向LSP和点对多点LSP。
The protocol solution(s) developed to perform this function on-demand MAY also apply to point-to-point associated bidirectional LSPs, to point-to-point unidirectional LSPs, and point-to-multipoint LSPs in case a return path exists.
为按需执行此功能而开发的协议解决方案也可适用于点对点关联的双向LSP、点对点单向LSP以及存在返回路径时的点对多点LSP。
The MPLS-TP OAM toolset MUST provide functionality to enable an End Point to discover the Intermediate (if any) and End Point(s) along a PW, LSP, or Section, and more generally to trace the route of a PW, LSP, or Section. The information collected MUST include identifiers related to the nodes and interfaces composing that route.
MPLS-TP OAM工具集必须提供使端点能够沿PW、LSP或区段发现中间点（如果有）和端点的功能，更一般地说，还可以跟踪PW、LSP或区段的路线。收集的信息必须包括与构成该路由的节点和接口相关的标识符。
This function SHOULD be performed on-demand.
此功能应按需执行。
This function SHOULD be performed between End Points and Intermediate Points of PWs and LSPs, and between End Points of PWs, LSPs, and Sections.
该功能应在PWs和LSP的端点和中间点之间以及PWs、LSP和截面的端点之间执行。
The protocol solution(s) developed to perform this function MAY also apply to point-to-point associated bidirectional LSPs, to point-to-point unidirectional LSPs, and point-to-multipoint LSPs in case a return path exists.
为执行此功能而开发的协议解决方案也可适用于点对点关联的双向LSP、点对点单向LSP以及存在返回路径时的点对多点LSP。
The MPLS-TP OAM toolset MUST provide a function to enable conducting diagnostic tests on a PW, LSP, or Section. An example of such a diagnostic test consists of performing a loop-back function at a node such that all OAM and data traffic are looped back to the originating End Point. Another example of such diagnostic test consists in estimating the bandwidth of, e.g., an LSP.
MPLS-TP OAM工具集必须提供在PW、LSP或区段上执行诊断测试的功能。此类诊断测试的一个示例包括在节点上执行环回功能，以便将所有OAM和数据流量环回到发起端点。此类诊断测试的另一个示例包括估计例如LSP的带宽。
This function SHOULD be performed on-demand.
此功能应按需执行。
This function SHOULD be performed between End Points and Intermediate Points of PWs and LSPs, and between End Points of PWs, LSPs, and Sections.
该功能应在PWs和LSP的端点和中间点之间以及PWs、LSP和截面的端点之间执行。
The protocol solution(s) developed to perform this function MAY also apply to point-to-point associated bidirectional LSPs, to point-to-point unidirectional LSPs and point-to-multipoint LSPs, in case a return path exists.
如果存在返回路径，则为执行此功能而开发的协议解决方案也可适用于点对点关联的双向LSP、点对点单向LSP和点对多点LSP。
The MPLS-TP OAM toolset MUST provide functionality to enable an End Point of a PW, LSP, or Section to instruct its associated End Point(s) to lock the PW, LSP, or Section. Note that lock corresponds to an administrative status in which it is expected that only test traffic, if any, and OAM (dedicated to the PW, LSP, or Section) can be mapped on that PW, LSP, or Section.
MPLS-TP OAM工具集必须提供使PW、LSP或区段的端点能够指示其相关端点锁定PW、LSP或区段的功能。注意，锁对应于一种管理状态，在这种状态下，预期只有测试流量（如果有）和OAM（专用于PW、LSP或区段）可以映射到该PW、LSP或区段。
This function SHOULD be performed on-demand.
此功能应按需执行。
This function SHOULD be performed between End Points of PWs, LSPs, and Sections.
此功能应在PWs、LSP和截面的端点之间执行。
The protocol solution(s) developed to perform this function MUST also apply to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs.
为执行此功能而开发的协议解决方案还必须适用于点对点关联的双向LSP、点对点单向LSP和点对多点LSP。
Based on the tunneling capabilities of MPLS, there are cases where Intermediate Point(s) of a PW or of an LSP coincide with End Point(s) of another LSP on which the former is mapped/tunneled. Further, it may happen that the tunnel LSP is out of service as a result of a lock action on that tunnel LSP. By means outside of the scope of this document, the Intermediate Point(s) of the PW or LSP may be aware of this condition. The MPLS-TP OAM toolset MUST provide a function to enable an Intermediate Point of a PW or LSP to report, to an End Point of that same PW or LSP, a lock condition indirectly affecting that PW or LSP.
基于MPLS的隧道能力，存在PW或LSP的中间点与另一LSP的端点重合的情况，前者映射/隧道在另一LSP上。此外，可能发生隧道LSP由于对该隧道LSP的锁定动作而停止服务。通过本文件范围之外的方式，PW或LSP的中间点可能知道这种情况。MPLS-TP OAM工具集必须提供一种功能，使PW或LSP的中间点能够向该PW或LSP的端点报告间接影响该PW或LSP的锁定条件。
This function SHOULD be performed proactively.
应主动执行此功能。
This function SHOULD be performed between Intermediate Points and End Points of PWs and LSPs.
该功能应在PWs和LSP的中间点和端点之间执行。
The protocol solution(s) developed to perform this function MUST also apply to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs.
为执行此功能而开发的协议解决方案还必须适用于点对点关联的双向LSP、点对点单向LSP和点对多点LSP。
Based on the tunneling capabilities of MPLS, there are cases where Intermediate Point(s) of a PW or of an LSP coincide with End Point(s) of another LSP on which the former is mapped/tunneled. Further, it may happen that the tunnel LSP be out of service as a result of a fault on that tunnel LSP. By means outside of the scope of this document, the Intermediate Point(s) of the PW or LSP may be aware of this condition. The MPLS-TP OAM toolset MUST provide functionality to enable an Intermediate Point of a PW or LSP to report, to an End Point of that same PW or LSP, a fault or defect condition indirectly affecting that PW or LSP.
基于MPLS的隧道能力，存在PW或LSP的中间点与另一LSP的端点重合的情况，前者映射/隧道在另一LSP上。此外，隧道LSP可能由于该隧道LSP上的故障而停止服务。通过本文件范围之外的方式，PW或LSP的中间点可能知道这种情况。MPLS-TP OAM工具集必须提供功能，使PW或LSP的中间点能够向该PW或LSP的端点报告间接影响该PW或LSP的故障或缺陷状况。
This function SHOULD be performed proactively.
应主动执行此功能。
This function SHOULD be performed between Intermediate Points and End Points of PWs and LSPs.
该功能应在PWs和LSP的中间点和端点之间执行。
The protocol solution(s) developed to perform this function MUST also apply to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs.
为执行此功能而开发的协议解决方案还必须适用于点对点关联的双向LSP、点对点单向LSP和点对多点LSP。
The MPLS-TP OAM toolset MUST provide a function to enable an End Point to report, to its associated End Point, a fault or defect condition that it detects on a PW, LSP, or Section for which they are the End Points.
MPLS-TP OAM工具集必须提供一种功能，使端点能够向其相关端点报告其在PW、LSP或其作为端点的区段上检测到的故障或缺陷状况。
This function SHOULD be performed proactively.
应主动执行此功能。
This function SHOULD be performed between End Points of PWs, LSPs, and Sections.
此功能应在PWs、LSP和截面的端点之间执行。
The protocol solution(s) developed to perform this function MUST also apply to point-to-point associated bidirectional LSPs and MAY also apply to point-to-point unidirectional LSPs and point-to-multipoint LSPs in case a return path exists.
为执行此功能而开发的协议解决方案还必须适用于点对点关联的双向LSP，并且在存在返回路径的情况下，还可以适用于点对点单向LSP和点对多点LSP。
The MPLS-TP OAM toolset MUST provide a function to enable the propagation, from edge to edge of an MPLS-TP network, of information pertaining to a client (i.e., external to the MPLS-TP network) defect or fault condition detected at an End Point of a PW or LSP, if the client layer OAM functionality does not provide an alarm notification/propagation functionality.
MPLS-TP OAM工具集必须提供一种功能，以便能够在MPLS-TP网络的边缘之间传播与在PW或LSP端点检测到的客户机（即，MPLS-TP网络外部）缺陷或故障状况相关的信息，如果客户端层OAM功能不提供报警通知/传播功能。
This function SHOULD be performed proactively.
应主动执行此功能。
This function SHOULD be performed between End Points of PWs and LSPs.
该功能应在PWs和LSP的端点之间执行。
The protocol solution(s) developed to perform this function MUST also apply to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs.
为执行此功能而开发的协议解决方案还必须适用于点对点关联的双向LSP、点对点单向LSP和点对多点LSP。
The MPLS-TP OAM toolset MUST provide a function to enable the quantification of packet loss ratio over a PW, LSP, or Section.
MPLS-TP OAM工具集必须提供能够量化PW、LSP或区段上的数据包丢失率的功能。
The loss of a packet is defined in RFC2680 [6] (see Section 2.4). This definition is used here.
RFC2680[6]中定义了数据包丢失（见第2.4节）。这里使用这个定义。
Packet-loss ratio is defined here to be the ratio of the number of user packets lost to the total number of user packets sent during a defined time interval.
包丢失率在这里定义为在定义的时间间隔内丢失的用户包数量与发送的用户包总数的比率。
This function MAY either be performed proactively or on-demand.
此功能可以主动执行，也可以按需执行。
This function SHOULD be performed between End Points of PWs, LSPs, and Sections.
此功能应在PWs、LSP和截面的端点之间执行。
It SHOULD be possible to rely on user traffic to perform this functionality.
应该可以依靠用户流量来执行此功能。
The protocol solution(s) developed to perform this function MUST also apply to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs.
为执行此功能而开发的协议解决方案还必须适用于点对点关联的双向LSP、点对点单向LSP和点对多点LSP。
The MPLS-TP OAM toolset MUST provide a function to enable the quantification of the one-way, and if appropriate, the two-way, delay of a PW, LSP, or Section.
MPLS-TP OAM工具集必须提供一个功能，以实现PW、LSP或区段的单向和双向延迟的量化。
o The one-way delay is defined in [7] to be the time elapsed from the start of transmission of the first bit of a packet by an End Point until the reception of the last bit of that packet by the other End Point.
o [7]将单向延迟定义为从一个端点开始发送数据包的第一位到另一个端点接收该数据包的最后一位所经过的时间。
o The two-way delay is defined in [8] to be the time elapsed from the start of transmission of the first bit of a packet by an End Point until the reception of the last bit of that packet by the same End Point.
o 在[8]中，双向延迟被定义为从数据包的第一位开始由端点传输到该数据包的最后一位由同一端点接收所经过的时间。
Two-way delay may be quantified using data traffic loopback at the remote End Point of the PW, LSP, or Section (see Section 2.2.5).
双向延迟可使用PW、LSP或区段远程端点处的数据流量环回进行量化（见第2.2.5节）。
Accurate quantification of one-way delay may require clock synchronization, the means for which are outside the scope of this document.
准确量化单向延迟可能需要时钟同步，其方法不在本文件范围内。
This function SHOULD be performed on-demand and MAY be performed proactively.
此功能应按需执行，并可主动执行。
This function SHOULD be performed between End Points of PWs, LSPs, and Sections.
此功能应在PWs、LSP和截面的端点之间执行。
The protocol solution(s) developed to perform this function MUST also apply to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs, but only to enable the quantification of the one-way delay.
为执行此功能而开发的协议解决方案还必须适用于点对点关联的双向LSP、点对点单向LSP和点对多点LSP，但仅用于量化单向延迟。
A mechanism (e.g., rate limiting) MUST be provided to prevent OAM packets from causing congestion in the Packet Switched Network.
必须提供一种机制（例如，速率限制），以防止OAM分组在分组交换网络中造成拥塞。
This document, in itself, does not imply any security consideration but OAM, as such, is subject to several security considerations. OAM messages can reveal sensitive information such as passwords, performance data and details about, e.g., the network topology.
本文件本身并不意味着任何安全考虑，但OAM本身受若干安全考虑的制约。OAM消息可能会泄露敏感信息，如密码、性能数据和有关网络拓扑等的详细信息。
The nature of OAM therefore suggests having some form of authentication, authorization, and encryption in place. This will prevent unauthorized access to MPLS-TP equipment and it will prevent third parties from learning about sensitive information about the transport network.
因此，OAM的性质建议采用某种形式的身份验证、授权和加密。这将防止未经授权访问MPLS-TP设备，并防止第三方了解有关传输网络的敏感信息。
OAM systems (network management stations) SHOULD be designed such that OAM functions cannot be accessed without authorization.
OAM系统（网络管理站）的设计应确保未经授权不能访问OAM功能。
OAM protocol solutions MUST include the facility for OAM messages to authenticated to prove their origin and to make sure that they are destined for the receiving node. The use of such facilities MUST be configurable.
OAM协议解决方案必须包括对OAM消息进行身份验证的功能，以证明它们的来源，并确保它们的目的地是接收节点。这些设施的使用必须是可配置的。
An OAM packet received over a PW, LSP, or Section MUST NOT be forwarded beyond the End Point of that PW, LSP, or Section, so as to avoid that the OAM packet leaves the current administrative domain.
通过PW、LSP或部分接收的OAM数据包不得转发到该PW、LSP或部分的端点之外，以避免OAM数据包离开当前管理域。
The editors gratefully acknowledge the contributions of Matthew Bocci, Italo Busi, Thomas Dietz, Annamaria Fulignoli, Huub van Helvoort, Enrique Hernandez-Valencia, Wataru Imajuku, Kam Lam, Marc Lasserre, Lieven Levrau, Han Li, Julien Meuric, Philippe Niger, Benjamin Niven-Jenkins, Jing Ruiquan, Nurit Sprecher, Yuji Tochio, Satoshi Ueno, and Yaacov Weingarten.
编辑们感激地感谢马修·博奇、伊塔洛·布西、托马斯·迪茨、安娜玛丽亚·富利诺利、胡布·凡·赫尔沃特、恩里克·埃尔南德斯·巴伦西亚、瓦塔鲁·伊马朱库、金林、马克·拉塞尔、列文·列夫劳、韩丽、朱利安·梅乌里、菲利普·尼日、本杰明·尼文·詹金斯、经瑞泉、努瑞特·斯普雷彻、尤吉·托乔、佐藤·上野、，还有亚科夫·温加滕。
The authors would like to thank all members of the teams (the Joint Working Team, the MPLS Interoperability Design Team in IETF, and the MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and specification of MPLS-TP.
作者要感谢参与MPLS-TP定义和规范的所有团队成员（联合工作团队、IETF中的MPLS互操作性设计团队和ITU-T中的MPLS-TP特设小组）。
[1] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[1] Niven Jenkins，B.，Brungard，D.，Betts，M.，Sprecher，N.，和S.Ueno，“MPLS传输配置文件的要求”，RFC 56542009年9月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] ITU-T Recommendation G.806, "Characteristics of transport equipment - Description methodology and generic functionality", 2009.
[3] ITU-T建议G.806，“运输设备的特性——描述方法和通用功能”，2009年。
[4] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[4] Kompella，K.和G.Swallow，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，2006年2月。
[5] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[5] Nadeau，T.和C.Pignataro，“伪线虚拟电路连接验证（VCCV）：伪线的控制通道”，RFC 5085，2007年12月。
[6] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
[6] Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的单向分组丢失度量”，RFC 2680，1999年9月。
[7] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[7] Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的单向延迟度量”，RFC 2679，1999年9月。
[8] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999.
[8] Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的往返延迟度量”，RFC 2681，1999年9月。
[9] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", Work in Progress, May 2010.
[9] Bocci，M.，Ed.，Bryant，S.，Ed.，Frost，D.，Ed.，Levrau，L.，和L.Berger，“传输网络中MPLS的框架”，正在进行的工作，2010年5月。
[10] ITU-T Supplement Y.Sup4, "ITU-T Y.1300-series: Supplement on transport requirements for T-MPLS OAM and considerations for the application of IETF MPLS technology", 2008.
[10] ITU-T补编Y.Sup4，“ITU-T Y.1300系列：T-MPLS OAM传输要求和IETF-MPLS技术应用注意事项补编”，2008年。
[11] 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.
[11] Nadeau，T.，Morrow，M.，Swallow，G.，Allan，D.，和S.Matsushima，“多协议标签交换（MPLS）网络的运营和管理（OAM）要求”，RFC 4377，2006年2月。
[12] Busi, I., Ed., Niven-Jenkins, B., Ed., and D. Allan, Ed., "MPLS-TP OAM Framework", Work in Progress, April 2010.
[12] Busi，I.，Ed.，Niven Jenkins，B.，Ed.，和D.Allan，Ed.，“MPLS-TP OAM框架”，正在进行的工作，2010年4月。
[13] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD For MPLS LSPs", Work in Progress, June 2008.
[13] Aggarwal，R.，Kompella，K.，Nadeau，T.，和G.Swallow，“MPLS LSP的BFD”，正在进行的工作，2008年6月。
[14] Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", Work in Progress, July 2009.
[14] Nadeau，T.，Ed.和C.Pignataro，Ed.，“用于伪线虚拟电路连接验证（VCCV）的双向转发检测（BFD）”，正在进行的工作，2009年7月。
Authors' Addresses
作者地址
Martin Vigoureux (editor) Alcatel-Lucent Route de Villejust Nozay 91620 France
Martin Vigoureux（编辑）阿尔卡特-朗讯维勒赫斯特-诺扎伊路线91620法国
EMail: martin.vigoureux@alcatel-lucent.com
EMail: martin.vigoureux@alcatel-lucent.com
David Ward (editor) Juniper Networks
David Ward（编辑）Juniper Networks
EMail: dward@juniper.net
EMail: dward@juniper.net
Malcolm Betts (editor) M. C. Betts Consulting Ltd.
Malcolm Betts（编辑）M.C.Betts咨询有限公司。
EMail: malcolm.betts@rogers.com
EMail: malcolm.betts@rogers.com