Internet Engineering Task Force (IETF) N. Sprecher
Request for Comments: 6669 Nokia Siemens Networks
Category: Informational L. Fang
ISSN: 2070-1721 Cisco Systems
July 2012
Internet Engineering Task Force (IETF) N. Sprecher
Request for Comments: 6669 Nokia Siemens Networks
Category: Informational L. Fang
ISSN: 2070-1721 Cisco Systems
July 2012
An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks
基于MPLS的传输网络的操作、管理和维护（OAM）工具集概述
Abstract
摘要
This document provides an overview of the Operations, Administration, and Maintenance (OAM) toolset for MPLS-based transport networks. The toolset consists of a comprehensive set of fault management and performance monitoring capabilities (operating in the data plane) that are appropriate for transport networks as required in RFC 5860 and support the network and services at different nested levels. This overview includes a brief recap of the MPLS Transport Profile (MPLS-TP) OAM requirements and functions and the generic mechanisms created in the MPLS data plane that allow the OAM packets to run in-band and share their fate with data packets. The protocol definitions for each of the MPLS-TP OAM tools are defined in separate documents (RFCs or Working Group documents), which are referenced by this document.
本文档概述了基于MPLS的传输网络的操作、管理和维护（OAM）工具集。该工具集包括一套全面的故障管理和性能监控功能（在数据平面上运行），适用于RFC 5860中要求的传输网络，并支持不同嵌套级别的网络和服务。此概述包括对MPLS传输配置文件（MPLS-TP）OAM要求和功能的简要概述，以及在MPLS数据平面中创建的通用机制，这些机制允许OAM数据包在频带内运行并与数据包共享其命运。每个MPLS-TP OAM工具的协议定义在本文件引用的单独文件（RFC或工作组文件）中定义。
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/rfc6669.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6669.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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 ....................................................4
1.1. Scope ......................................................4
1.2. Acronyms ...................................................5
2. Basic OAM Infrastructure Functionality ..........................6
3. MPLS-TP OAM Functions ...........................................8
3.1. Continuity Check and Connectivity Verification .............8
3.1.1. Documents for CC-CV Tools ...........................8
3.2. Remote Defect Indication ...................................8
3.2.1. Documents for RDI ...................................9
3.3. Route Tracing ..............................................9
3.3.1. Documents for Route Tracing .........................9
3.4. Alarm Reporting ............................................9
3.4.1. Documents for Alarm Reporting .......................9
3.5. Lock Instruct ..............................................9
3.5.1. Documents for Lock Instruct ........................10
3.6. Lock Reporting ............................................10
3.6.1. Documents for Lock Reporting .......................10
3.7. Diagnostic ................................................10
3.7.1. Documents for Diagnostic Testing ...................10
3.8. Packet Loss Measurement ...................................10
3.8.1. Documents for Packet Loss Measurement ..............11
3.9. Packet Delay Measurement ..................................11
3.9.1. Documents for Delay Measurement ....................11
4. MPLS-TP OAM Documents Guide ....................................12
5. OAM Toolset Applicability and Utilization ......................13
5.1. Connectivity Check and Connectivity Verification ..........14
5.2. Diagnostic Tests and Lock Instruct ........................14
5.3. Lock Reporting ............................................15
5.4. Alarm Reporting and Link Down Indication ..................15
5.5. Remote Defect Indication ..................................16
5.6. Packet Loss and Delay Measurement .........................17
6. Security Considerations ........................................18
7. Acknowledgements ...............................................18
8. References .....................................................19
8.1. Normative References ......................................19
8.2. Informative References ....................................20
Contributors ......................................................21
1. Introduction ....................................................4
1.1. Scope ......................................................4
1.2. Acronyms ...................................................5
2. Basic OAM Infrastructure Functionality ..........................6
3. MPLS-TP OAM Functions ...........................................8
3.1. Continuity Check and Connectivity Verification .............8
3.1.1. Documents for CC-CV Tools ...........................8
3.2. Remote Defect Indication ...................................8
3.2.1. Documents for RDI ...................................9
3.3. Route Tracing ..............................................9
3.3.1. Documents for Route Tracing .........................9
3.4. Alarm Reporting ............................................9
3.4.1. Documents for Alarm Reporting .......................9
3.5. Lock Instruct ..............................................9
3.5.1. Documents for Lock Instruct ........................10
3.6. Lock Reporting ............................................10
3.6.1. Documents for Lock Reporting .......................10
3.7. Diagnostic ................................................10
3.7.1. Documents for Diagnostic Testing ...................10
3.8. Packet Loss Measurement ...................................10
3.8.1. Documents for Packet Loss Measurement ..............11
3.9. Packet Delay Measurement ..................................11
3.9.1. Documents for Delay Measurement ....................11
4. MPLS-TP OAM Documents Guide ....................................12
5. OAM Toolset Applicability and Utilization ......................13
5.1. Connectivity Check and Connectivity Verification ..........14
5.2. Diagnostic Tests and Lock Instruct ........................14
5.3. Lock Reporting ............................................15
5.4. Alarm Reporting and Link Down Indication ..................15
5.5. Remote Defect Indication ..................................16
5.6. Packet Loss and Delay Measurement .........................17
6. Security Considerations ........................................18
7. Acknowledgements ...............................................18
8. References .....................................................19
8.1. Normative References ......................................19
8.2. Informative References ....................................20
Contributors ......................................................21
The MPLS Transport Profile (MPLS-TP) architectural framework is defined in [RFC5921], and it describes a common set of protocol functions that supports the operational models and capabilities typical of such transport networks.
[RFC5921]中定义了MPLS传输配置文件（MPLS-TP）体系结构框架，它描述了一组通用的协议功能，支持此类传输网络的典型操作模型和功能。
Operations, Administration, and Maintenance (OAM) plays a significant role in carrier networks. It provides methods for fault management and performance monitoring in both the transport and service layers, in order to improve their ability to support services with guaranteed and strict Service Level Agreements (SLAs) while reducing their operational costs.
运营、管理和维护（OAM）在运营商网络中扮演着重要角色。它提供了传输层和服务层中的故障管理和性能监控方法，以提高它们通过有保证且严格的服务级别协议（SLA）支持服务的能力，同时降低运营成本。
[RFC5654], in general, and [RFC5860], in particular, define a set of requirements for the OAM functionality for MPLS-TP Label Switched Paths (LSPs), Pseudowires (PWs), and Sections.
一般而言，[RFC5654]，特别是[RFC5860]，为MPLS-TP标签交换路径（LSP）、伪线（PW）和区段的OAM功能定义了一组要求。
The OAM solution, developed by the joint IETF and ITU-T MPLS-TP project, has three objectives:
由IETF和ITU-T MPLS-TP联合项目开发的OAM解决方案有三个目标：
o The OAM toolset should be developed based on existing MPLS architecture, technology, and toolsets.
o OAM工具集应基于现有MPLS体系结构、技术和工具集进行开发。
o The OAM operational experience should be similar to that in other transport networks.
o OAM运营经验应与其他运输网络中的运营经验相似。
o The OAM toolset developed for MPLS-based transport networks needs to be fully interoperable with existing MPLS OAM tools as documented in Section 2.1.5. of [RFC5860].
o 为基于MPLS的传输网络开发的OAM工具集需要与第2.1.5节中记录的现有MPLS OAM工具完全互操作。属于[RFC5860]。
The MPLS-TP OAM toolset is based on the following existing tools:
MPLS-TP OAM工具集基于以下现有工具：
o LSP ping, as defined in [RFC4379].
o LSP ping，如[RFC4379]中所定义。
o Bidirectional Forwarding Detection (BFD), as defined in [RFC5880] and refined in [RFC5884].
o 双向转发检测（BFD），如[RFC5880]中定义并在[RFC5884]中完善。
o ITU-T OAM for the Ethernet toolset, as defined in [Y.1731]. This has been used as functionality guidelines for the performance measurement tools that were not previously supported in MPLS.
o [Y.1731]中定义的以太网工具集的ITU-T OAM。这已被用作MPLS以前不支持的性能度量工具的功能指南。
Note that certain extensions and adjustments have been specified, relative to the existing MPLS tools, in order to conform to the transport environment and the requirements of MPLS-TP. However, compatibility with the existing MPLS tools has been maintained.
请注意，为了符合传输环境和MPLS-TP的要求，已经指定了与现有MPLS工具相关的某些扩展和调整。但是，与现有MPLS工具的兼容性得到了维护。
This document provides an overview of the MPLS-TP OAM toolset, which consists of tools for MPLS-TP fault management and performance monitoring. This overview includes a brief recap of MPLS-TP OAM requirements, their functions, and the generic mechanisms used to support the MPLS-TP OAM operation.
本文档概述了MPLS-TP OAM工具集，该工具集包括用于MPLS-TP故障管理和性能监视的工具。本概述简要回顾了MPLS-TP OAM需求、它们的功能以及用于支持MPLS-TP OAM操作的通用机制。
The protocol definitions for individual MPLS-TP OAM tools are specified in separate RFCs (or Working Group documents), which are referenced by this document.
单个MPLS-TP OAM工具的协议定义在单独的RFC（或工作组文件）中指定，本文件引用了这些文件。
In addition, this document includes a table that cross-references the solution documents of the OAM functionality supported. Finally, the document presents the applicability and utilization of each tool in the MPLS-TP OAM toolset.
此外，本文档还包括一个表，该表交叉引用了所支持的OAM功能的解决方案文档。最后，本文介绍了MPLS-TP OAM工具集中每个工具的适用性和利用率。
This document uses the following acronyms:
本文件使用以下首字母缩略词：
ACH Associated Channel Header AIS Alarm Indication Signal BFD Bidirectional Forwarding Detection CC-CV Continuity Check and Connectivity Verification DM Delay Measurement FM Fault Management G-ACh Generic Associated Channel GAL G-ACh Label GMPLS Generalized Multiprotocol Label Switching IANA Internet Assigned Numbers Authority LDI Link Down Indication LKR Lock Report LM Loss Measurement LOC Loss of Continuity LSP Label Switched Path MEP Maintenance Entity Group End Point MEG Maintenance Entity Group MIP Maintenance Entity Group Intermediate Point MPLS Multiprotocol Label Switching MPLS-TP Transport Profile for MPLS OAM Operations, Administration, and Maintenance PM Performance Monitoring PW Pseudowire RDI Remote Defect Indication SLA Service Level Agreement TLV Type, Length, Value VCCV Virtual Circuit Connectivity Verification
ACH相关信道头AIS报警指示信号BFD双向转发检测CC-CV连续性检查和连接验证DM延迟测量FM故障管理G-ACH通用相关信道GAL G-ACH标签GMPLS通用多协议标签交换IANA互联网分配号码管理局LDI链路关闭指示LKR锁报告LM丢失测量LOC连续性丢失LSP标签交换路径MEP维护实体组端点MEG维护实体组MIP维护实体组中间点MPLS多协议标签交换MPLS-TP传输配置文件用于MPLS OAM操作、管理、，和维护PM性能监控PW伪线RDI远程缺陷指示SLA服务级别协议TLV类型、长度、值VCCV虚拟电路连接验证
[RFC5860] defines a set of requirements for OAM architecture and general principles of operations, which are evaluated below:
[RFC5860]定义了OAM体系结构和一般操作原则的一组要求，评估如下：
[RFC5860] requires that --
[RFC5860]要求--
o OAM mechanisms in MPLS-TP are independent of the transmission media and the client service being emulated by the PW ([RFC5860], Section 2.1.2).
o MPLS-TP中的OAM机制独立于传输介质和PW模拟的客户端服务（[RFC5860]，第2.1.2节）。
o MPLS-TP OAM must be able to support both an IP-based and non-IP-based environment. If the network is IP based, i.e., IP routing and forwarding are available, then it must be possible to choose to make use of IP capabilities. On the other hand, in environments where IP functionality is not available, the OAM tools must still be able to operate independent of IP forwarding and routing ([RFC5860], Section 2.1.4). It is required to have OAM interoperability between distinct domains materializing the environments ([RFC5860], Section 2.1.5).
o MPLS-TP OAM必须能够支持基于IP和非基于IP的环境。如果网络基于IP，即IP路由和转发可用，则必须能够选择使用IP功能。另一方面，在IP功能不可用的环境中，OAM工具仍必须能够独立于IP转发和路由运行（[RFC5860]，第2.1.4节）。要求实现环境的不同域之间具有OAM互操作性（[RFC5860]，第2.1.5节）。
o All OAM protocols support identification information, at least in the form of IP addressing structure, and are extensible to support additional identification schemes ([RFC5860], Section 2.1.4).
o 所有OAM协议至少以IP寻址结构的形式支持标识信息，并可扩展以支持其他标识方案（[RFC5860]，第2.1.4节）。
o OAM packets and the user traffic are congruent (i.e., OAM packets are transmitted in-band) and there is a need to differentiate OAM packets from user-plane packets [RFC5860], Section 2.1.3. Inherent in this requirement is the principle that full operation of the MPLS-TP OAM must be possible independently of the control or management plane used to operate the network [RFC5860], Section 2.1.3.
o OAM数据包和用户流量是一致的（即，OAM数据包在频带内传输），需要区分OAM数据包和用户平面数据包[RFC5860]，第2.1.3节。该要求固有的原则是，MPLS-TP OAM的完全运行必须独立于用于操作网络的控制或管理平面[RFC5860]，第2.1.3节。
o MPLS-TP OAM supports point-to-point bidirectional PWs, point-to-point co-routed bidirectional LSPs, and point-to-point bidirectional Sections ([RFC5860], Section 2.1.1). The applicability of particular MPLS-TP OAM functions to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs, is described in [RFC5860], Section 2.2. In addition, MPLS-TP OAM supports these LSPs and PWs when they span either single or multiple domains ([RFC5860], Section 2.1.1).
o MPLS-TP OAM支持点对点双向PWs、点对点共路由双向LSP和点对点双向段（[RFC5860]，第2.1.1节）。[RFC5860]第2.2节描述了特定MPLS-TP OAM功能对点对点关联双向LSP、点对点单向LSP和点对多点LSP的适用性。此外，当这些LSP和PW跨越单个或多个域时，MPLS-TP OAM支持这些LSP和PW（[RFC5860]，第2.1.1节）。
o OAM packets may be directed to an intermediate point of an LSP/PW ([RFC5860], Sections 2.2.3, 2.2.4, and 2.2.5).
o OAM数据包可定向到LSP/PW的中间点（[RFC5860]，第2.2.3、2.2.4和2.2.5节）。
[RFC5860], Section 2.2 recommends that any protocol solution meeting one or more functional requirement(s) be the same for PWs, LSPs, and Sections.
[RFC5860]，第2.2节建议满足一个或多个功能要求的任何协议解决方案对于PWs、LSP和章节是相同的。
The following document set addresses the basic requirements listed above:
以下文件集阐述了上述基本要求：
o [RFC6371] describes the architectural framework for conformance to the basic requirements listed above. It also defines the basic relationships between the MPLS structures, e.g., LSP, PW, and the structures necessary for OAM functionality, i.e., the Maintenance Entity Group (MEG), its end points, and intermediate points.
o [RFC6371]描述了符合上述基本要求的体系结构框架。它还定义了MPLS结构（如LSP、PW）与OAM功能所需的结构（即维护实体组（MEG）、其端点和中间点）之间的基本关系。
o [RFC5586] specifies the use of the MPLS-TP in-band control channels. It generalizes the applicability of the PW ACH to MPLS LSPs and Sections by defining a Generic Associated Channel (G-ACh). The G-ACh allows control packets to be multiplexed transparently over LSPs and Sections similar to that of PW VCCV [RFC5085]. The Generic Association Label (GAL) is defined by assigning a reserved MPLS label value and is used to identify the OAM control packets. The value of the ACH Channel Type field indicates the specific protocol carried on the associated control channel. Each MPLS-TP OAM protocol has an IANA-assigned channel type allocated to it.
o [RFC5586]指定MPLS-TP带内控制信道的使用。它通过定义通用关联信道（G-ACH），将PW ACH的适用性推广到MPLS LSP和区段。G-ACh允许在LSP和类似于PW VCCV[RFC5085]的部分上透明地复用控制数据包。通用关联标签（GAL）通过分配保留的MPLS标签值来定义，并用于标识OAM控制数据包。ACH信道类型字段的值表示相关控制信道上承载的特定协议。每个MPLS-TP OAM协议都有一个IANA分配的信道类型。
[RFC5085] defines an Associated Channel Header (ACH) that provides a PW associated control channel between a PW's end points, over which OAM and other control messages can be exchanged. [RFC5586] generalizes the PW Associated Channel Header (ACH) to provide common in-band control channels also at the LSP and MPLS-TP link levels. The G-ACh allows control packets to be multiplexed transparently over the same LSP or MPLS-TP link as in PW VCCV. Multiple control channels can exist between end points.
[RFC5085]定义了一个关联的通道头（ACH），它在PW端点之间提供了一个PW关联的控制通道，OAM和其他控制消息可以通过该通道进行交换。[RFC5586]概括了PW相关信道报头（ACH），以在LSP和MPLS-TP链路级别提供公共带内控制信道。G-ACh允许通过与PW VCCV中相同的LSP或MPLS-TP链路透明地复用控制分组。端点之间可以存在多个控制通道。
[RFC5085] also defines a label-based exception mechanism that helps a Label Switching Router (LSR) to identify the control packets and direct them to the appropriate entity for processing. The use of G-ACh and GAL provides the necessary mechanisms to allow OAM packets to run in-band and share their fate with data packets. It is expected that all of the OAM protocols will be used in conjunction with this Generic Associated Channel.
[RFC5085]还定义了一种基于标签的异常机制，帮助标签交换路由器（LSR）识别控制数据包，并将其定向到适当的实体进行处理。G-ACh和GAL的使用提供了必要的机制，允许OAM数据包在频带内运行，并与数据包共享它们的命运。预计所有OAM协议都将与此通用关联信道一起使用。
o [RFC6370] provides an IP-based identifier set for MPLS-TP that can be used to identify the transport entities in the network and referenced by the different OAM protocols.
o [RFC6370]为MPLS-TP提供了一个基于IP的标识符集，可用于标识网络中的传输实体，并由不同的OAM协议引用。
Note: [MPLS-TP-ITU-Idents] augments that set of identifiers to include identifier information in a format used by the ITU-T. Other identifier sets may be defined as well.
注：[MPLS TP ITU Idents]增加了该标识符集，以包括ITU-T使用的格式的标识符信息。还可以定义其他标识符集。
The following sections discuss the OAM functions that are required in [RFC5860] and expanded upon in [RFC6371].
以下各节讨论了[RFC5860]中所需并在[RFC6371]中扩展的OAM功能。
Continuity Check and Connectivity Verification (CC-CV) are OAM operations generally used in tandem and complement each other. These functions are generally run proactively, but may also be used on-demand for diagnoses of a specific condition. [RFC5860] states that the function should allow the MEPs to proactively monitor the liveliness and connectivity of a transport path (LSP, PW, or a Section) between them. In on-demand mode, this function should support monitoring between the MEPs and between a MEP and MIP. Note that as specified in [RFC6371], Sections 3.3 and 3.4, a MEP and a MIP can reside in an unspecified location within a node, or in a particular interface on a specific side of the forwarding engine.
连续性检查和连接性验证（CC-CV）是通常串联使用并相互补充的OAM操作。这些功能通常主动运行，但也可按需用于特定情况的诊断。[RFC5860]指出，该功能应允许MEP主动监测它们之间传输路径（LSP、PW或区段）的活跃性和连通性。在按需模式下，此功能应支持MEP之间以及MEP和MIP之间的监控。请注意，如[RFC6371]第3.3节和第3.4节所述，MEP和MIP可以位于节点内的未指定位置，或者位于转发引擎特定侧的特定接口中。
[RFC6371] highlights the need for the CC-CV messages to include unique identification of the MEG that is being monitored and the MEP that originated the message. The function, both proactively and in on-demand mode, needs to be transmitted at regular transmission rates pre-configured by the operator.
[RFC6371]强调CC-CV消息需要包括被监测的MEG和发出消息的MEP的唯一标识。无论是主动模式还是按需模式，都需要以操作员预先配置的常规传输速率传输功能。
[RFC6428] defines BFD extensions to support proactive CC-CV applications.
[RFC6428]定义BFD扩展以支持主动式CC-CV应用程序。
[RFC6426] provides LSP ping extensions that are used to implement on-demand connectivity verification.
[RFC6426]提供用于实现按需连接验证的LSP ping扩展。
Both of these tools will be used within the basic functionality framework described in Section 2.
这两种工具都将在第2节所述的基本功能框架内使用。
Remote Defect Indication (RDI) is used by a path end point to report that a defect is detected on a bidirectional connection to its peer end point. [RFC5860] points out that this function may be applied to a unidirectional LSP only if a return path exists. [RFC6371] points out that this function is associated with the proactive CC-CV function.
远程缺陷指示（RDI）由路径端点用于报告在与其对等端点的双向连接上检测到缺陷。[RFC5860]指出，仅当存在返回路径时，此功能才可应用于单向LSP。[RFC6371]指出该功能与主动CC-CV功能相关。
[RFC6428] provides an extension for BFD that includes the RDI indication in the BFD format and a specification of how this indication is to be used.
[RFC6428]提供BFD扩展，包括BFD格式的RDI指示以及如何使用该指示的规范。
[RFC5860] defines the need for functionality that would allow a path end point to identify the intermediate points (if any) and end point(s) along the path (LSP, PW, or a Section). This function would be used in on-demand mode. Normally, this path will be used for bidirectional PW, LSP, and Sections; however, unidirectional paths may be supported only if a return path exists.
[RFC5860]定义了允许路径端点识别路径（LSP、PW或截面）上的中间点（如有）和端点的功能需求。此功能将在按需模式下使用。通常，该路径将用于双向PW、LSP和区段；但是，仅当存在返回路径时，才支持单向路径。
[RFC6426] specifies that the LSP ping enhancements for MPLS-TP on-demand connectivity verification include information on the use of LSP ping for route tracing of an MPLS-TP path.
[RFC6426]指定用于MPLS-TP按需连接验证的LSP ping增强包括有关使用LSP ping跟踪MPLS-TP路径的信息。
Alarm Reporting is a function used by an intermediate point of a path (LSP or PW) to report to the end points of the path that a fault exists on the path. [RFC6371] states that this may occur as a result of a defect condition discovered at a server layer. The intermediate point generates an Alarm Indication Signal (AIS) that continues until the fault is cleared. The consequent action of this function is detailed in [RFC6371].
报警报告是路径中间点（LSP或PW）用于向路径端点报告路径上存在故障的功能。[RFC6371]指出，这可能是由于在服务器层发现的缺陷条件造成的。中间点产生报警指示信号（AIS），该信号持续到故障清除为止。[RFC6371]中详细说明了此函数的后续操作。
MPLS-TP defines a new protocol to address this functionality that is documented in [RFC6427]. This protocol uses all of the basic mechanisms detailed in Section 2.
MPLS-TP定义了一个新的协议来解决[RFC6427]中记录的这一功能。该协议使用了第2节详述的所有基本机制。
The Lock Instruct function is an administrative control tool that allows a path end point to instruct its peer end point to lock the path (LSP, PW, or Section). The tool is necessary to support single-side provisioning for administrative locking, according to [RFC6371]. This function is used on-demand.
锁定指示功能是一种管理控制工具，允许路径端点指示其对等端点锁定路径（LSP、PW或区段）。根据[RFC6371]，该工具对于支持管理锁定的单边设置是必需的。此功能按需使用。
[RFC6435] describes the details of a new ACH-based protocol format for this functionality.
[RFC6435]介绍了此功能的基于ACH的新协议格式的详细信息。
Lock Reporting, defined in [RFC5860], is similar to the Alarm Reporting function described above. It is used by an intermediate point to notify the end points of a transport path (LSP or PW) that an administrative lock condition exists for the transport path.
[RFC5860]中定义的锁定报告与上述报警报告功能类似。中间点使用它通知传输路径（LSP或PW）的端点该传输路径存在管理锁定条件。
MPLS-TP defines a new protocol to address this functionality that is documented in [RFC6427]. This protocol uses all the basic mechanisms detailed in Section 2.
MPLS-TP定义了一个新的协议来解决[RFC6427]中记录的这一功能。该协议使用第2节中详细介绍的所有基本机制。
[RFC5860] indicates a need to provide an OAM function that would enable conducting different diagnostic tests on a PW, LSP, or Section. [RFC6371] provides two types of specific tests to be used through this functionality:
[RFC5860]表示需要提供OAM功能，以便能够在PW、LSP或区段上执行不同的诊断测试。[RFC6371]提供了通过此功能使用的两种类型的特定测试：
o Throughput estimation - allowing the provider to verify the bandwidth/throughput of a transport path. This is an out-of-service tool that uses special packets of varying sizes to test the actual bandwidth and/or throughput of the path.
o 吞吐量估计-允许提供商验证传输路径的带宽/吞吐量。这是一个停用工具，它使用不同大小的特殊数据包来测试路径的实际带宽和/或吞吐量。
o Data-plane loopback - this out-of-service tool causes all traffic that reaches the target node, either a MEP or MIP, to be looped back to the originating MEP. For targeting MIPs, a co-routed bidirectional path is required.
o 数据平面环回-此停用工具导致到达目标节点（MEP或MIP）的所有流量环回到原始MEP。对于目标MIPs，需要一个共同路由的双向路径。
[RFC6435] describes the details of a new ACH-based protocol format for the data-plane loopback functionality.
[RFC6435]介绍了用于数据平面环回功能的新的基于ACH的协议格式的详细信息。
The tool for throughput estimation is under study.
吞吐量估计工具正在研究中。
Packet Loss Measurement is required by [RFC5860] to provide a quantification of the packet loss ratio on a transport path. This is the ratio of the number of user packets lost to the total number of user packets during a defined time interval. To employ this
[RFC5860]要求进行分组丢失测量，以提供传输路径上分组丢失率的量化。这是在定义的时间间隔内丢失的用户数据包数与用户数据包总数的比率。利用这个
function, [RFC6371] defines that the two end points of the transport path should exchange counters of messages transmitted and received within a time period bounded by loss-measurement messages. The framework warns that there may be small errors in the computation, which result from various issues.
函数[RFC6371]定义传输路径的两个端点应在损耗测量消息限定的时间段内交换发送和接收的消息计数器。该框架警告说，由于各种问题，计算中可能会出现小错误。
[RFC6374] describes the protocol formats and procedures for using the tool and enabling efficient and accurate measurement of packet loss, delay, and throughput in MPLS networks. [RFC6375] describes a profile of the general MPLS loss, delay, and throughput measurement techniques that suffice to meet the specific requirements of MPLS-TP. Note that the tool logic is based on the behavior of the parallel function described in [Y.1731].
[RFC6374]描述了使用该工具以及在MPLS网络中高效准确地测量数据包丢失、延迟和吞吐量的协议格式和程序。[RFC6375]描述了一般MPLS丢失、延迟和吞吐量测量技术的概况，这些技术足以满足MPLS-TP的特定要求。注意，工具逻辑基于[Y.1731]中描述的并行功能的行为。
Packet Delay Measurement is a function that is used to measure the one-way or two-way delay of packet transmission between a pair of the end points of a path (PW, LSP, or Section), as described in [RFC5860], where:
数据包延迟测量是用于测量路径（PW、LSP或区段）的一对端点之间数据包传输的单向或双向延迟的功能，如[RFC5860]中所述，其中：
o One-way packet delay is the time elapsed from the start of transmission of the first bit of the packet by a source node until the reception of the last bit of that packet by the destination node.
o 单向分组延迟是从源节点开始发送分组的第一位到目的节点接收该分组的最后一位所经过的时间。
o Two-way packet delay is the time elapsed from the start of transmission of the first bit of the packet by a source node until the reception of the last bit of the loop-backed packet by the same source node, when the loopback is performed at the packet's destination node.
o 双向数据包延迟是从源节点开始传输数据包的第一位到同一源节点接收到回送数据包的最后一位所经过的时间，此时在数据包的目的节点执行回送。
[RFC6371] describes how the tool could be used (both in proactive and on-demand modes) for either one-way or two-way measurement. However, it warns that the one-way delay option requires precise time synchronization between the end points.
[RFC6371]描述了该工具如何（在主动和按需模式下）用于单向或双向测量。但是，它警告说，单向延迟选项需要端点之间的精确时间同步。
[RFC6374] describes the protocol formats and procedures for using the tool and enabling efficient and accurate measurement of packet loss, delay, and throughput in MPLS networks. [RFC6375] describes a profile of the general MPLS loss, delay, and throughput measurement techniques that suffices to meet the specific requirements of MPLS-TP. Note that the tool logic is based on the behavior of the parallel function described in [Y.1731].
[RFC6374]描述了使用该工具以及在MPLS网络中高效准确地测量数据包丢失、延迟和吞吐量的协议格式和程序。[RFC6375]描述了一般MPLS丢失、延迟和吞吐量测量技术的概况，这些技术足以满足MPLS-TP的特定要求。注意，工具逻辑基于[Y.1731]中描述的并行功能的行为。
The complete MPLS-TP OAM protocol suite is covered by a small set of existing IETF documents. This set of documents may be expanded in the future to cover additional OAM functionality. In order to allow the reader to understand this set of documents, a cross-reference of the existing documents (RFCs or Working Group documents) for the initial phase of the specification of MPLS-based transport networks is provided below.
完整的MPLS-TP OAM协议套件包含在一小部分现有IETF文档中。这组文档将来可能会扩展，以涵盖其他OAM功能。为了让读者理解这组文档，下面提供了基于MPLS的传输网络规范初始阶段的现有文档（RFC或工作组文档）的交叉引用。
[RFC5586] provides a specification of the basic structure of protocol messages for in-band data-plane OAM in an MPLS environment.
[RFC5586]提供了MPLS环境中带内数据平面OAM协议消息基本结构的规范。
[RFC6370] provides definitions of different formats that may be used within OAM protocol messages to identify the network elements of an MPLS-based transport network.
[RFC6370]提供可在OAM协议消息中使用的不同格式的定义，以识别基于MPLS的传输网络的网络元件。
The following table (Table 1) provides the summary of proactive MPLS-TP OAM Fault Management toolset functions, the associated tool/protocol, and the corresponding RFCs in which they are defined.
下表（表1）总结了主动式MPLS-TP OAM故障管理工具集功能、相关工具/协议以及定义它们的相应RFC。
+--------------------------+-------------------------------+---------+
| OAM Functions | OAM Tools/Protocols | RFCs |
+--------------------------+-------------------------------+---------+
| Continuity Check and | Bidirectional Forwarding |[RFC6428]|
| Connectivity | Detection (BFD) | |
| Verification | | |
+--------------------------+-------------------------------+---------+
| Remote Defect Indication | Flag in Bidirectional |[RFC6428]|
| (RDI) | Forwarding Detection (BFD) | |
| | message | |
+--------------------------+-------------------------------+---------+
| Alarm Indication Signal | G-ACh-based AIS message |[RFC6427]|
| (AIS) | | |
+--------------------------+-------------------------------+---------+
| Link Down Indication | Flag in AIS message |[RFC6427]|
| (LDI) | | |
+--------------------------+-------------------------------+---------+
| Lock Reporting (LKR) | G-ACh-based LKR message |[RFC6427]|
| | | |
+--------------------------+-------------------------------+---------+
+--------------------------+-------------------------------+---------+
| OAM Functions | OAM Tools/Protocols | RFCs |
+--------------------------+-------------------------------+---------+
| Continuity Check and | Bidirectional Forwarding |[RFC6428]|
| Connectivity | Detection (BFD) | |
| Verification | | |
+--------------------------+-------------------------------+---------+
| Remote Defect Indication | Flag in Bidirectional |[RFC6428]|
| (RDI) | Forwarding Detection (BFD) | |
| | message | |
+--------------------------+-------------------------------+---------+
| Alarm Indication Signal | G-ACh-based AIS message |[RFC6427]|
| (AIS) | | |
+--------------------------+-------------------------------+---------+
| Link Down Indication | Flag in AIS message |[RFC6427]|
| (LDI) | | |
+--------------------------+-------------------------------+---------+
| Lock Reporting (LKR) | G-ACh-based LKR message |[RFC6427]|
| | | |
+--------------------------+-------------------------------+---------+
Table 1. Proactive Fault Management OAM Toolset
表1。主动式故障管理OAM工具集
The following table (Table 2) provides an overview of the on-demand MPLS-TP OAM Fault Management toolset functions, the associated tool/protocol, and the corresponding RFCs in which they are defined.
下表（表2）概述了按需MPLS-TP OAM故障管理工具集功能、相关工具/协议以及定义它们的相应RFC。
+------------------------+---------------------------------+---------+
| OAM Functions | OAM Tools/Protocols | RFCs |
+------------------------+---------------------------------+---------+
| Connectivity | LSP Ping |[RFC6426]|
| Verification | | |
+------------------------+---------------------------------+---------+
| Lock Instruct (LI) | (1) G-ACh-based Loopback, |[RFC6426]|
| | (2) Lock Instruct (LI) | |
+------------------------+---------------------------------+---------+
| Lock Report (LKR) | Flag in AIS message |[RFC6426]|
| | | |
+------------------------+---------------------------------+---------+
+------------------------+---------------------------------+---------+
| OAM Functions | OAM Tools/Protocols | RFCs |
+------------------------+---------------------------------+---------+
| Connectivity | LSP Ping |[RFC6426]|
| Verification | | |
+------------------------+---------------------------------+---------+
| Lock Instruct (LI) | (1) G-ACh-based Loopback, |[RFC6426]|
| | (2) Lock Instruct (LI) | |
+------------------------+---------------------------------+---------+
| Lock Report (LKR) | Flag in AIS message |[RFC6426]|
| | | |
+------------------------+---------------------------------+---------+
Table 2. On Demand Fault Management OAM Toolset
表2。按需故障管理OAM工具集
The following table (Table 3) provides the Performance Monitoring Functions, the associated tool/protocol definitions, and the corresponding RFCs in which they are defined.
下表（表3）提供了性能监控功能、相关工具/协议定义以及定义它们的相应RFC。
+----------------------+--------------------------+-----------------+
| OAM Functions | OAM Tools/Protocols | RFCs |
+----------------------+--------------------------+-----------------+
| Packet Loss | G-ACh-based LM & DM | [RFC6374] |
| Measurement (LM) | query messages | [RFC6375] |
+----------------------+--------------------------+-----------------+
| Packet Delay | G-ACh-based LM & DM | [RFC6374] |
| Measurement (DM) | query messages | [RFC6375] |
+----------------------+--------------------------+-----------------+
| Throughput | derived from Loss | [RFC6374] |
| Measurement | Measurement | [RFC6375] |
+----------------------+--------------------------+-----------------+
| Delay Variation | derived from Delay | [RFC6374] |
| Measurement | Measurement | [RFC6375] |
+----------------------+--------------------------+-----------------+
+----------------------+--------------------------+-----------------+
| OAM Functions | OAM Tools/Protocols | RFCs |
+----------------------+--------------------------+-----------------+
| Packet Loss | G-ACh-based LM & DM | [RFC6374] |
| Measurement (LM) | query messages | [RFC6375] |
+----------------------+--------------------------+-----------------+
| Packet Delay | G-ACh-based LM & DM | [RFC6374] |
| Measurement (DM) | query messages | [RFC6375] |
+----------------------+--------------------------+-----------------+
| Throughput | derived from Loss | [RFC6374] |
| Measurement | Measurement | [RFC6375] |
+----------------------+--------------------------+-----------------+
| Delay Variation | derived from Delay | [RFC6374] |
| Measurement | Measurement | [RFC6375] |
+----------------------+--------------------------+-----------------+
Table 3. Performance Monitoring OAM Toolset
表3。性能监视OAM工具集
The following subsections present the MPLS-TP OAM toolset from the perspective of the specified protocols and identifies the required functionality that is supported by the particular protocol.
以下小节从指定协议的角度介绍MPLS-TP OAM工具集，并确定特定协议支持的所需功能。
Proactive Continuity Check and Connectivity Verification (CC-CV) functions are used to detect loss of continuity (LOC) and unintended connectivity between two MEPs. Loss of connectivity, mis-merging, mis-connectivity, or unexpected Maintenance Entity Group End Points (MEPs) can be detected using the CC-CV tools. See Sections 3.1, 3.2, 3.3 in this document for CC-CV protocol references.
主动连续性检查和连接验证（CC-CV）功能用于检测两个MEP之间的连续性丧失（LOC）和意外连接。使用CC-CV工具可以检测到连接丢失、错误合并、错误连接或意外维护实体组端点（MEP）。CC-CV协议参考见本文件第3.1、3.2、3.3节。
The CC-CV tools are used to support MPLS-TP fault management, performance management, and protection switching. Proactive CC-CV control packets are sent by the source MEP to the sink MEP. The sink-MEP monitors the arrival of the CC-CV control packets and detects the defect. For bidirectional transport paths, the CC-CV protocol is usually transmitted simultaneously in both directions.
CC-CV工具用于支持MPLS-TP故障管理、性能管理和保护切换。主动CC-CV控制数据包由源MEP发送到接收器MEP。接收器MEP监视CC-CV控制数据包的到达并检测缺陷。对于双向传输路径，CC-CV协议通常在两个方向上同时传输。
The transmission interval of the CC-CV control packets can be configured. For example:
可以配置CC-CV控制数据包的传输间隔。例如：
o 3.3 ms is the default interval for protection switching.
o 3.3 ms是保护切换的默认间隔。
o 100 ms is the default interval for performance monitoring.
o 100 ms是性能监视的默认间隔。
o 1 s is the default interval for fault management.
o 1s是故障管理的默认间隔。
[RFC6435] describes a protocol that provides a mechanism to Lock and Unlock traffic (e.g., data and control traffic or specific OAM traffic) at a specific LSR on the path of the MPLS-TP LSP to allow loopback of the traffic to the source.
[RFC6435]描述了一种协议，该协议提供了一种在MPLS-TP LSP路径上的特定LSR处锁定和解锁流量（例如，数据和控制流量或特定OAM流量）的机制，以允许将流量回送到源。
These diagnostic functions apply to associated bidirectional MPLS-TP LSPs, including MPLS-TP LSPs, bidirectional RSVP-Traffic Engineering (RSVP-TE) tunnels (which is relevant for the MPLS-TP dynamic control-plane option with GMPLS), and single-segment and multi-segment Pseudowires. [RFC6435] provides the protocol definition for diagnostic tests functions.
这些诊断功能适用于相关的双向MPLS-TP LSP，包括MPLS-TP LSP、双向RSVP流量工程（RSVP-TE）隧道（与GMPLS的MPLS-TP动态控制平面选项相关）以及单段和多段伪线。[RFC6435]提供诊断测试功能的协议定义。
[RFC6435] defines a mechanism where a lock instruction is sent by a management application to both ends of a point-to-point LSP, requesting them to take the LSP out-of-service. When an end point gets the management request, it locks the LSP and sends a Lock Instruct message to the other end of the LSP. The Lock Instruct message is carried in a Generic ACH message and is sent periodically. The time between successive messages is no longer than the value set in the Refresh Timer field of the Lock Instruct message. An LSP end point keeps the LSP locked while it is either receiving the periodic
[RFC6435]定义了一种机制，其中管理应用程序向点到点LSP的两端发送锁指令，请求它们停止LSP的服务。当端点收到管理请求时，它锁定LSP并向LSP的另一端发送锁定指示消息。锁定指令消息在通用ACH消息中携带，并定期发送。连续消息之间的时间不超过锁定指示消息的刷新计时器字段中设置的值。LSP端点在接收周期性数据时保持LSP锁定
Lock Instruct messages or has an in-force lock instruction from the management application.
锁定指令消息或具有来自管理应用程序的有效锁定指令。
Note that since the management application will receive a management plane response from both ends of the LSP confirming that the LSP has been locked, there is no requirement for the Lock Instruct message to have a response. Therefore, [RFC6435] does not define a Lock Instruct response message.
注意，由于管理应用程序将从LSP的两端接收确认LSP已被锁定的管理平面响应，因此不要求锁定指示消息具有响应。因此，[RFC6435]未定义锁定指令响应消息。
The loopback operations include:
环回操作包括：
o Lock: take an LSP out of service for maintenance.
o 锁：使LSP停止使用以进行维护。
o Unlock: Restore a previously locked LSP to service.
o 解锁：将以前锁定的LSP恢复到服务状态。
o Set_Full_Loopback and Set_OAM_Loopback.
o 设置\u Full\u环回和设置\u OAM\u环回。
o Unset_Full_Loopback and Set_OAM_Loopback.
o 取消设置完整的环回并设置OAM环回。
Operators can use the loopback mode to test the connectivity or performance (loss, delay, delay variation, and throughput) of a given LSP up to a specific node on the path of the LSP.
运营商可以使用环回模式测试给定LSP到LSP路径上特定节点的连接性或性能（丢失、延迟、延迟变化和吞吐量）。
The Lock Report (LKR) function is used to communicate to the MEPS of the client (sub-)layer MEPs the administrative locking of a server (sub-)layer MEP, and consequential interruption of data traffic forwarding in the client layer. See Section 3.6 in this document for Lock Reporting protocol references.
锁定报告（LKR）功能用于将服务器（子）层MEP的管理锁定以及客户端层数据流量转发的相应中断传达给客户端（子）层MEP的MEP。有关锁报告协议参考，请参见本文件第3.6节。
When an operator is taking the LSP out of service for maintenance or another operational reason, using the LKR function can help to distinguish the condition as administrative locking from a defect condition.
当操作员出于维护或其他操作原因使LSP停止使用时，使用LKR功能有助于区分管理锁定和缺陷状态。
The Lock Report function may also serve the purpose of alarm suppression in the MPLS-TP network above the level at which the Lock has occurred. The receipt of an LKR message may be treated as the equivalent of the loss of continuity at the client layer.
锁定报告功能还可用于MPLS-TP网络中发生锁定级别以上的报警抑制。LKR消息的接收可被视为等同于客户端层的连续性丢失。
Alarm Indication Signal (AIS) message is used to suppress alarms following detection of defect conditions at the server (sub-)layer. When the Link Down Indication (LDI) is set, the AIS message may be used to trigger recovery mechanisms.
报警指示信号（AIS）消息用于在服务器（子）层检测到缺陷条件后抑制报警。当设置链路断开指示（LDI）时，AIS消息可用于触发恢复机制。
When a server MEP detects the failure, it asserts LOC or signal fail, which sets the flag up to generate an OAM packet with the AIS message. The AIS message is forwarded to the downstream sink MEP in the client layer. This enables the client layer to suppress the generation of secondary alarms.
当服务器MEP检测到故障时，它断言LOC或signal fail，这将设置标志以生成带有AIS消息的OAM数据包。AIS消息被转发到客户端层中的下游接收器MEP。这使客户端层能够抑制辅助报警的生成。
An LDI flag is defined in the AIS message. The LDI flag is set in the AIS message in response to detecting a fatal failure in the server layer. Receipt of an AIS message with this flag set may be interpreted by a MEP as an indication of signal fail at the client layer.
本地设计院（LDI）标志在AIS信息中定义。在AIS消息中设置LDI标志，以响应检测到服务器层中的致命故障。MEP可以将接收到设置了此标志的AIS消息解释为客户端层的信号失败指示。
The protocols for AIS and LDI are defined in [RFC6427].
AIS和LDI的协议在[RFC6427]中定义。
Fault OAM messages are generated by intermediate nodes where an LSP is switched and propagated to the end points (MEPs).
故障OAM消息由中间节点生成，其中LSP被切换并传播到端点（MEP）。
From a practical point of view, when both proactive Continuity Check functions and LDI are used, one may consider running the proactive Continuity Check functions at a slower rate (e.g., longer BFD hello intervals), and reply on LDI to trigger fast protection switch over upon failure detection in a given LSP.
从实用的角度来看，当使用主动连续性检查功能和LDI时，可以考虑以较慢的速率运行主动连续性检查功能（例如，较长的BFD hello间隔），并在LDI上应答，以触发在给定LSP中的故障检测时的快速保护切换。
The Remote Defect Indication (RDI) function enables an end point to report to its peer end point that a fault or defect condition is detected on the PW, LSP, or Section.
远程缺陷指示（RDI）功能使端点能够向其对等端点报告在PW、LSP或区段上检测到故障或缺陷状况。
The RDI OAM function is supported by the use of BFD control packets [RFC6428]. RDI is only used for bidirectional connections and is associated with proactive CC-CV activation.
使用BFD控制数据包[RFC6428]支持RDI OAM功能。RDI仅用于双向连接，并与主动CC-CV激活相关。
When an end point (MEP) detects a signal failure condition, it sets the flag up by setting the diagnostic field of the BFD control packet to a particular value to indicate the failure condition on the associated PW, LSP, or Section. Additionally, the BFD control packet is transmitted with the failure flag up to the other end point (its peer MEP).
当端点（MEP）检测到信号故障条件时，它通过将BFD控制数据包的诊断字段设置为特定值来设置标志，以指示相关PW、LSP或区段上的故障条件。此外，BFD控制数据包与故障标志一起传输到另一个端点（其对等MEP）。
The RDI function can be used to facilitate protection switching by synchronizing the two end points when unidirectional failure occurs and is detected by one end.
当发生单向故障并被一端检测到时，RDI功能可通过同步两个端点来促进保护切换。
The packet loss and delay measurement toolset enables operators to measure the quality of the packet transmission over a PW, LSP, or Section. Section 3.8 in this document defines the protocols for packet loss measurement, and Section 3.9 defines the protocols for packet delay measurement.
数据包丢失和延迟测量工具集使操作员能够测量通过PW、LSP或区段的数据包传输质量。本文件第3.8节定义了包丢失测量协议，第3.9节定义了包延迟测量协议。
The loss and delay protocols have the following characteristics and capabilities:
丢失和延迟协议具有以下特征和功能：
o They support the measurement of packet loss, delay, and throughput over Label Switched Paths (LSPs), Pseudowires, and MPLS Sections.
o 它们支持通过标签交换路径（LSP）、伪线和MPLS部分测量数据包丢失、延迟和吞吐量。
o The same LM and DM protocols can be used for both continuous/proactive and selective/on-demand measurements.
o 相同的LM和DM协议可用于连续/主动和选择性/按需测量。
o The LM and DM protocols use a simple query/response model for bidirectional measurement that allows a single node -- the querier -- to measure the loss or delay in both directions.
o LM和DM协议使用一个简单的查询/响应模型进行双向测量，该模型允许单个节点（查询者）测量两个方向上的损失或延迟。
o The LM and DM protocols use query messages for unidirectional loss and delay measurement. The measurement can either be carried out at the downstream node(s), or at the querier if an out-of-band return path is available.
o LM和DM协议使用查询消息进行单向损耗和延迟测量。测量可以在下游节点上进行，如果带外返回路径可用，也可以在查询器上进行。
o The LM and DM protocols do not require that the transmit-and-receive interfaces be the same when performing bidirectional measurement.
o 在执行双向测量时，LM和DM协议不要求发送和接收接口相同。
o The LM supports test-message-based measurement (i.e., inferred mode) as well as measurement based on data-plane counters (i.e., direct mode).
o LM支持基于测试消息的测量（即推断模式）以及基于数据平面计数器的测量（即直接模式）。
o The LM protocol supports both 32-bit and 64-bit counters.
o LM协议支持32位和64位计数器。
o The LM protocol supports measurement in terms of both packet counts and octet counts; although for simplicity, only packet counters are currently included in the MPLS-TP profile.
o LM协议支持数据包计数和八位字节计数的测量；尽管为简单起见，MPLS-TP配置文件中目前只包括数据包计数器。
o The LM protocol can be used to measure channel throughput as well as packet loss.
o LM协议可用于测量信道吞吐量和数据包丢失。
o The DM protocol supports varying the measurement message size in order to measure delays associated with different packet sizes.
o DM协议支持改变测量消息大小，以便测量与不同分组大小相关联的延迟。
o The DM protocol uses IEEE 1588 timestamps [IEEE1588] by default but also supports other timestamp formats, such as NTP.
o DM协议默认使用IEEE 1588时间戳[IEEE1588]，但也支持其他时间戳格式，如NTP。
This document, as an overview of MPLS OAM tools, does not by itself raise any particular security considerations.
本文档作为MPLS OAM工具的概述，本身并没有提出任何特定的安全注意事项。
The general security considerations are provided in [RFC5920] and [MPLS-TP-SEC]. Security considerations for each function within the OAM toolset have been recorded in each document that specifies a particular functionality.
[RFC5920]和[MPLS-TP-SEC]中提供了一般安全注意事项。OAM工具集中每个功能的安全注意事项都记录在指定特定功能的每个文档中。
In general, OAM is always an area where the security risk is high. For example, confidential information may be intercepted by attackers to gain access to networks; therefore, authentication, authorization, and encryption must be enforced to prevent security breaches.
一般来说，OAM总是一个安全风险很高的领域。例如，攻击者可能会截获机密信息以访问网络；因此，必须强制执行身份验证、授权和加密以防止安全漏洞。
It is also important to strictly follow operational security procedures. For example, in the case of MPLS-TP static provisioning, the operator interacts directly with the Network Management System (NMS) and devices, and it is critical in order to prevent human errors and malicious attacks.
严格遵守操作安全程序也很重要。例如，在MPLS-TP静态资源调配的情况下，运营商直接与网络管理系统（NMS）和设备交互，这对于防止人为错误和恶意攻击至关重要。
Since MPLS-TP OAM uses G-ACh, the security risks and mitigations described in [RFC5085] also apply here. In short, messages on the G-ACh could be intercepted, or false G-ACh packets could be inserted.
由于MPLS-TP OAM使用G-ACh，[RFC5085]中描述的安全风险和缓解措施也适用于此处。简言之，可以拦截G-ACh上的消息，或者插入错误的G-ACh数据包。
Additionally, DoS attacks can be mounted by flooding G-ACh messages to peer devices. To mitigate this type of attack, throttling mechanisms or rate limits can be used. For more details, please see [RFC5085].
此外，可以通过将G-ACh消息洪泛到对等设备来装载DoS攻击。为了减轻这种类型的攻击，可以使用节流机制或速率限制。有关更多详细信息，请参阅[RFC5085]。
The authors would like to thank the MPLS-TP experts from both the IETF and ITU-T for their helpful comments. In particular, we would like to thank Loa Andersson and the Area Directors for their suggestions and enhancements to the text.
作者要感谢IETF和ITU-T的MPLS-TP专家提出的有益意见。特别是，我们要感谢Loa Andersson和区域主任对文本提出的建议和改进。
Thanks to Tom Petch for useful comments and discussions.
感谢Tom Petch提供了有用的评论和讨论。
Thanks to Rui Costa for his review and comments, which helped improve this document.
感谢Rui Costa的审阅和评论，这有助于改进本文档。
[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月。
[RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5085]Nadeau，T.，Ed.，和C.Pignataro，Ed.，“伪线虚拟电路连接验证（VCCV）：伪线的控制通道”，RFC 5085，2007年12月。
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5586]Bocci，M.，Ed.，Vigoureux，M.，Ed.，和S.Bryant，Ed.，“MPLS通用关联信道”，RFC 55862009年6月。
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[RFC5654]Niven Jenkins，B.，Ed.，Brungard，D.，Ed.，Betts，M.，Ed.，Sprecher，N.，和S.Ueno，“MPLS传输配置文件的要求”，RFC 56542009年9月。
[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月。
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5884]Aggarwal，R.，Kompella，K.，Nadeau，T.，和G.Swallow，“MPLS标签交换路径（LSP）的双向转发检测（BFD）”，RFC 58842010年6月。
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
[RFC5921]Bocci，M.，Ed.，Bryant，S.，Ed.，Frost，D.，Ed.，Levrau，L.，和L.Berger，“传输网络中MPLS的框架”，RFC 59212010年7月。
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
[RFC6370]Bocci，M.，Swallow，G.和E.Gray，“MPLS传输配置文件（MPLS-TP）标识符”，RFC 63702011年9月。
[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月。
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, September 2011.
[RFC6374]Frost，D.和S.Bryant，“MPLS网络的数据包丢失和延迟测量”，RFC 63742011年9月。
[RFC6375] Frost, D., Ed., and S. Bryant, Ed., "A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks", RFC 6375, September 2011.
[RFC6375]Frost，D.，Ed.，和S.Bryant，Ed.，“基于MPLS的传输网络的数据包丢失和延迟测量模式”，RFC 63752011年9月。
[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS On-Demand Connectivity Verification and Route Tracing", RFC 6426, November 2011.
[RFC6426]Gray，E.，Bahadur，N.，Boutros，S.，和R.Aggarwal，“MPLS按需连接验证和路由跟踪”，RFC 6426，2011年11月。
[RFC6427] Swallow, G., Ed., Fulignoli, A., Ed., Vigoureux, M., Ed., Boutros, S., and D. Ward, "MPLS Fault Management Operations, Administration, and Maintenance (OAM)", RFC 6427, November 2011.
[RFC6427]Swallow，G.，Ed.，Fulignoli，A.，Ed.，Vigoureux，M.，Ed.，Boutros，S.，和D.Ward，“MPLS故障管理操作、管理和维护（OAM）”，RFC 64272011年11月。
[RFC6428] Allan, D., Ed., Swallow Ed., G., and J. Drake Ed., "Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile", RFC 6428, November 2011.
[RFC6428]Allan，D.，Ed.，Swallow Ed.，G.，和J.Drake Ed.“MPLS传输配置文件的主动连接验证、连续性检查和远程缺陷指示”，RFC 6428，2011年11月。
[RFC6435] Boutros, S., Ed., Sivabalan, S., Ed., Aggarwal, R., Ed., Vigoureux, M., Ed., and X. Dai, Ed., "MPLS Transport Profile Lock Instruct and Loopback Functions", RFC 6435, November 2011.
[RFC6435]Boutros，S.，Ed.，Sivabalan，S.，Ed.，Aggarwal，R.，Ed.，Vigoureux，M.，Ed.，和X.Dai，Ed.，“MPLS传输配置文件锁定指令和环回功能”，RFC 64352011年11月。
[IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", March 2008.
[IEEE1588]IEEE，“1588-2008网络测量和控制系统精密时钟同步协议IEEE标准”，2008年3月。
[MPLS-TP-ITU-Idents] Winter, R., van Helvoort, H., and M. Betts, "MPLS-TP Identifiers Following ITU-T Conventions", Work in Progress, March 2012.
[MPLS-TP ITU识别码]Winter，R.，van Helvoort，H.，和M.Betts，“遵循ITU-T公约的MPLS-TP识别码”，正在进行的工作，2012年3月。
[MPLS-TP-SEC] Fang, L., Niven-Jenkins, B., and S. Mansfield, "MPLS-TP Security Framework", Work in Progress, March 2012.
[MPLS-TP-SEC]Fang，L.，Niven Jenkins，B.，和S.Mansfield，“MPLS-TP安全框架”，正在进行的工作，2012年3月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月。
[Y.1731] International Telecommunications Union - Standardization, "OAM functions and mechanisms for Ethernet based networks", ITU Y.1731, May 2006.
[Y.1731]国际电信联盟-标准化，“基于以太网的网络的OAM功能和机制”，ITU Y.17312006年5月。
Contributors
贡献者
Elisa Bellagamba Ericsson Yaacov Weingarten Nokia Siemens Networks Dan Frost Cisco Nabil Bitar Verizon Raymond Zhang Alcatel Lucent Lei Wang Telenor Kam Lee Yap XO Communications John Drake Juniper Yaakov Stein RAD Anamaria Fulignoli Ericsson Italo Busi Alcatel Lucent Huub van Helvoort Huawei Thomas Nadeau Computer Associate Henry Yu TW Telecom Mach Chen Huawei Manuel Paul Deutsche Telekom
Elisa Bellagamba Ericsson Yaacov Weingarten Nokia Siemens Networks and Frost Cisco Nabil Bitar Verizon Raymond Zhang Alcatel Lucent Lei Wang Telenor Kam Lee Yap XO Communications John Drake Juniper Yaakov Stein RAD Anamaria Fulignoli Ericsson Italo Busi Alcatel Lucent Huub van Helvoort华为Thomas Nadeau计算机助理Henry Yu TW TelecomMach Chen华为Manuel Paul Deutsche Telekom
Authors' Addresses
作者地址
Nurit Sprecher Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon, 45241 Israel
Nurit Sprecher诺基亚西门子网络3号哈纳加圣内韦-内曼B Hod Hasharon，以色列45241
EMail: nurit.sprecher@nsn.com
EMail: nurit.sprecher@nsn.com
Luyuan Fang Cisco Systems 111 Wood Avenue South Iselin, NJ 08830 USA
卢元芳思科系统美国新泽西州伊塞林南伍德大道111号，邮编：08830
EMail: lufang@cisco.com
EMail: lufang@cisco.com