Internet Engineering Task Force (IETF) T. Mizrahi
Request for Comments: 7276 Marvell
Category: Informational N. Sprecher
ISSN: 2070-1721 Nokia Solutions and Networks
E. Bellagamba
Ericsson
Y. Weingarten
June 2014
Internet Engineering Task Force (IETF) T. Mizrahi
Request for Comments: 7276 Marvell
Category: Informational N. Sprecher
ISSN: 2070-1721 Nokia Solutions and Networks
E. Bellagamba
Ericsson
Y. Weingarten
June 2014
An Overview of Operations, Administration, and Maintenance (OAM) Tools
操作、管理和维护（OAM）工具概述
Abstract
摘要
Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset for fault detection and isolation, and for performance measurement. Over the years, various OAM tools have been defined for various layers in the protocol stack.
操作、管理和维护（OAM）是一个通用术语，指用于故障检测和隔离以及性能度量的工具集。多年来，已经为协议栈中的各个层定义了各种OAM工具。
This document summarizes some of the OAM tools defined in the IETF in the context of IP unicast, MPLS, MPLS Transport Profile (MPLS-TP), pseudowires, and Transparent Interconnection of Lots of Links (TRILL). This document focuses on tools for detecting and isolating failures in networks and for performance monitoring. Control and management aspects of OAM are outside the scope of this document. Network repair functions such as Fast Reroute (FRR) and protection switching, which are often triggered by OAM protocols, are also out of the scope of this document.
本文档总结了IETF在IP单播、MPLS、MPLS传输配置文件（MPLS-TP）、伪线和大量链路的透明互连（TRILL）环境中定义的一些OAM工具。本文档重点介绍用于检测和隔离网络故障以及性能监控的工具。OAM的控制和管理方面不在本文件的范围内。通常由OAM协议触发的快速重路由（FRR）和保护交换等网络修复功能也不在本文档的范围内。
The target audience of this document includes network equipment vendors, network operators, and standards development organizations. This document can be used as an index to some of the main OAM tools defined in the IETF. At the end of the document, a list of the OAM toolsets and a list of the OAM functions are presented as a summary.
本文档的目标受众包括网络设备供应商、网络运营商和标准开发组织。本文档可用作IETF中定义的一些主要OAM工具的索引。在文档的末尾，OAM工具集的列表和OAM功能的列表以摘要的形式呈现。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7276.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7276.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must 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. Background .................................................5
1.2. Target Audience ............................................6
1.3. OAM-Related Work in the IETF ...............................6
1.4. Focusing on the Data Plane .................................7
2. Terminology .....................................................8
2.1. Abbreviations ..............................................8
2.2. Terminology Used in OAM Standards .........................10
2.2.1. General Terms ......................................10
2.2.2. Operations, Administration, and Maintenance ........10
2.2.3. Functions, Tools, and Protocols ....................11
2.2.4. Data Plane, Control Plane, and Management Plane ....11
2.2.5. The Players ........................................12
2.2.6. Proactive and On-Demand Activation .................13
2.2.7. Connectivity Verification and Continuity Checks ....14
2.2.8. Connection-Oriented vs. Connectionless
Communication ......................................15
2.2.9. Point-to-Point vs. Point-to-Multipoint Services ....16
2.2.10. Failures ..........................................16
3. OAM Functions ..................................................17
4. OAM Tools in the IETF - A Detailed Description .................18
4.1. IP Ping ...................................................18
4.2. IP Traceroute .............................................19
4.3. Bidirectional Forwarding Detection (BFD) ..................20
4.3.1. Overview ...........................................20
4.3.2. Terminology ........................................20
4.3.3. BFD Control ........................................20
4.3.4. BFD Echo ...........................................21
4.4. MPLS OAM ..................................................21
4.4.1. LSP Ping ...........................................21
4.4.2. BFD for MPLS .......................................22
4.4.3. OAM for Virtual Private Networks (VPNs) over MPLS ..23
4.5. MPLS-TP OAM ...............................................23
4.5.1. Overview ...........................................23
4.5.2. Terminology ........................................24
4.5.3. Generic Associated Channel .........................25
4.5.4. MPLS-TP OAM Toolset ................................25
4.5.4.1. Continuity Check and Connectivity
Verification ..............................26
4.5.4.2. Route Tracing .............................26
4.5.4.3. Lock Instruct .............................27
4.5.4.4. Lock Reporting ............................27
4.5.4.5. Alarm Reporting ...........................27
4.5.4.6. Remote Defect Indication ..................27
4.5.4.7. Client Failure Indication .................27
1. Introduction ....................................................4
1.1. Background .................................................5
1.2. Target Audience ............................................6
1.3. OAM-Related Work in the IETF ...............................6
1.4. Focusing on the Data Plane .................................7
2. Terminology .....................................................8
2.1. Abbreviations ..............................................8
2.2. Terminology Used in OAM Standards .........................10
2.2.1. General Terms ......................................10
2.2.2. Operations, Administration, and Maintenance ........10
2.2.3. Functions, Tools, and Protocols ....................11
2.2.4. Data Plane, Control Plane, and Management Plane ....11
2.2.5. The Players ........................................12
2.2.6. Proactive and On-Demand Activation .................13
2.2.7. Connectivity Verification and Continuity Checks ....14
2.2.8. Connection-Oriented vs. Connectionless
Communication ......................................15
2.2.9. Point-to-Point vs. Point-to-Multipoint Services ....16
2.2.10. Failures ..........................................16
3. OAM Functions ..................................................17
4. OAM Tools in the IETF - A Detailed Description .................18
4.1. IP Ping ...................................................18
4.2. IP Traceroute .............................................19
4.3. Bidirectional Forwarding Detection (BFD) ..................20
4.3.1. Overview ...........................................20
4.3.2. Terminology ........................................20
4.3.3. BFD Control ........................................20
4.3.4. BFD Echo ...........................................21
4.4. MPLS OAM ..................................................21
4.4.1. LSP Ping ...........................................21
4.4.2. BFD for MPLS .......................................22
4.4.3. OAM for Virtual Private Networks (VPNs) over MPLS ..23
4.5. MPLS-TP OAM ...............................................23
4.5.1. Overview ...........................................23
4.5.2. Terminology ........................................24
4.5.3. Generic Associated Channel .........................25
4.5.4. MPLS-TP OAM Toolset ................................25
4.5.4.1. Continuity Check and Connectivity
Verification ..............................26
4.5.4.2. Route Tracing .............................26
4.5.4.3. Lock Instruct .............................27
4.5.4.4. Lock Reporting ............................27
4.5.4.5. Alarm Reporting ...........................27
4.5.4.6. Remote Defect Indication ..................27
4.5.4.7. Client Failure Indication .................27
4.5.4.8. Performance Monitoring ....................28
4.5.4.8.1. Packet Loss Measurement (LM) ...28
4.5.4.8.2. Packet Delay Measurement (DM) ..28
4.6. Pseudowire OAM ............................................29
4.6.1. Pseudowire OAM Using Virtual Circuit
Connectivity Verification (VCCV) ...................29
4.6.2. Pseudowire OAM Using G-ACh .........................30
4.6.3. Attachment Circuit - Pseudowire Mapping ............30
4.7. OWAMP and TWAMP ...........................................31
4.7.1. Overview ...........................................31
4.7.2. Control and Test Protocols .........................32
4.7.3. OWAMP ..............................................32
4.7.4. TWAMP ..............................................33
4.8. TRILL .....................................................33
5. Summary ........................................................34
5.1. Summary of OAM Tools ......................................34
5.2. Summary of OAM Functions ..................................37
5.3. Guidance to Network Equipment Vendors .....................38
6. Security Considerations ........................................38
7. Acknowledgments ................................................39
8. References .....................................................39
8.1. Normative References ......................................39
8.2. Informative References ....................................39
Appendix A. List of OAM Documents ................................ 46
A.1. List of IETF OAM Documents ............................... 46
A.2. List of Selected Non-IETF OAM Documents .................. 50
4.5.4.8. Performance Monitoring ....................28
4.5.4.8.1. Packet Loss Measurement (LM) ...28
4.5.4.8.2. Packet Delay Measurement (DM) ..28
4.6. Pseudowire OAM ............................................29
4.6.1. Pseudowire OAM Using Virtual Circuit
Connectivity Verification (VCCV) ...................29
4.6.2. Pseudowire OAM Using G-ACh .........................30
4.6.3. Attachment Circuit - Pseudowire Mapping ............30
4.7. OWAMP and TWAMP ...........................................31
4.7.1. Overview ...........................................31
4.7.2. Control and Test Protocols .........................32
4.7.3. OWAMP ..............................................32
4.7.4. TWAMP ..............................................33
4.8. TRILL .....................................................33
5. Summary ........................................................34
5.1. Summary of OAM Tools ......................................34
5.2. Summary of OAM Functions ..................................37
5.3. Guidance to Network Equipment Vendors .....................38
6. Security Considerations ........................................38
7. Acknowledgments ................................................39
8. References .....................................................39
8.1. Normative References ......................................39
8.2. Informative References ....................................39
Appendix A. List of OAM Documents ................................ 46
A.1. List of IETF OAM Documents ............................... 46
A.2. List of Selected Non-IETF OAM Documents .................. 50
"OAM" is a general term that refers to a toolset for detecting, isolating, and reporting failures, and for monitoring network performance.
“OAM”是一个通用术语，指用于检测、隔离和报告故障以及监视网络性能的工具集。
There are several different interpretations of the "OAM" acronym. This document refers to Operations, Administration, and Maintenance, as recommended in Section 3 of [OAM-Def].
“OAM”首字母缩略词有几种不同的解释。本文件涉及[OAM Def]第3节中建议的操作、管理和维护。
This document summarizes some of the OAM tools defined in the IETF in the context of IP unicast, MPLS, MPLS Transport Profile (MPLS-TP), pseudowires, and TRILL.
本文档总结了IETF在IP单播、MPLS、MPLS传输配置文件（MPLS-TP）、伪线和TRILL上下文中定义的一些OAM工具。
This document focuses on tools for detecting and isolating failures and for performance monitoring. Hence, this document focuses on the tools used for monitoring and measuring the data plane; control and management aspects of OAM are outside the scope of this document. Network repair functions such as Fast Reroute (FRR) and protection switching, which are often triggered by OAM protocols, are also out of the scope of this document.
本文档重点介绍用于检测和隔离故障以及性能监控的工具。因此，本文件重点介绍用于监视和测量数据平面的工具；OAM的控制和管理方面不在本文件的范围内。通常由OAM协议触发的快速重路由（FRR）和保护交换等网络修复功能也不在本文档的范围内。
OAM was originally used in traditional communication technologies such as E1 and T1, evolving into Plesiochronous Digital Hierarchy (PDH) and then later into Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH). ATM was probably the first technology to include inherent OAM support from day one, while in other technologies OAM was typically defined in an ad hoc manner after the technology was already defined and deployed. Packet-based networks were traditionally considered unreliable and best effort. As packet-based networks evolved, they have become the common transport for both data and telephony, replacing traditional transport protocols. Consequently, packet-based networks were expected to provide a similar "carrier grade" experience, and specifically to support more advanced OAM functions, beyond ICMP and router hellos, that were traditionally used for fault detection.
OAM最初用于E1和T1等传统通信技术，后来发展为准同步数字体系（PDH），然后发展为同步光网络/同步数字体系（SONET/SDH）。ATM可能是从第一天起就包含固有OAM支持的第一种技术，而在其他技术中，OAM通常是在该技术已经定义和部署之后以临时方式定义的。传统上，基于分组的网络被认为是不可靠的，而且是尽力而为的。随着基于分组的网络的发展，它们已经成为数据和电话的通用传输，取代了传统的传输协议。因此，基于分组的网络有望提供类似的“载波级”体验，特别是支持更高级的OAM功能，而不是传统上用于故障检测的ICMP和路由器hellos。
As typical networks have a multi-layer architecture, the set of OAM protocols similarly take a multi-layer structure; each layer has its own OAM protocols. Moreover, OAM can be used at different levels of hierarchy in the network to form a multi-layer OAM solution, as shown in the example in Figure 1.
由于典型网络具有多层架构，OAM协议集同样采用多层结构；每一层都有自己的OAM协议。此外，OAM可以在网络的不同层次上使用，以形成多层OAM解决方案，如图1中的示例所示。
Figure 1 illustrates a network in which IP traffic between two customer edges is transported over an MPLS provider network. MPLS OAM is used at the provider level for monitoring the connection between the two provider edges, while IP OAM is used at the customer level for monitoring the end-to-end connection between the two customer edges.
图1显示了一个网络，其中两个客户边缘之间的IP流量通过MPLS提供商网络传输。MPLS OAM在提供商级别用于监视两个提供商边缘之间的连接，而IP OAM在客户级别用于监视两个客户边缘之间的端到端连接。
|<-------------- Customer-level OAM -------------->|
IP OAM (Ping, Traceroute, OWAMP, TWAMP)
|<-------------- Customer-level OAM -------------->|
IP OAM (Ping, Traceroute, OWAMP, TWAMP)
|<- Provider-level OAM ->| MPLS OAM (LSP Ping)
|<-提供商级OAM->MPLS OAM（LSP Ping）
+-----+ +----+ +----+ +-----+
| | | |========================| | | |
| |-------| | MPLS | |-------| |
| | IP | | | | IP | |
+-----+ +----+ +----+ +-----+
Customer Provider Provider Customer
Edge Edge Edge Edge
+-----+ +----+ +----+ +-----+
| | | |========================| | | |
| |-------| | MPLS | |-------| |
| | IP | | | | IP | |
+-----+ +----+ +----+ +-----+
Customer Provider Provider Customer
Edge Edge Edge Edge
Figure 1: Example of Multi-layer OAM
图1：多层OAM示例
The target audience of this document includes:
本文件的目标受众包括：
o Standards development organizations - Both IETF working groups and non-IETF organizations can benefit from this document when designing new OAM protocols, or when looking to reuse existing OAM tools for new technologies.
o 标准开发组织-IETF工作组和非IETF组织在设计新的OAM协议时，或在寻求将现有OAM工具用于新技术时，都可以从本文档中获益。
o Network equipment vendors and network operators can use this document as an index to some of the common IETF OAM tools.
o 网络设备供应商和网络运营商可以使用本文档作为一些常见IETF OAM工具的索引。
It should be noted that some background in OAM is necessary in order to understand and benefit from this document. Specifically, the reader is assumed to be familiar with the term "OAM" [OAM-Def], the motivation for using OAM, and the distinction between OAM and network management [OAM-Mng].
应该注意的是，为了理解本文档并从中受益，必须具备OAM方面的一些背景知识。具体地说，假定读者熟悉术语“OAM”[OAM Def]、使用OAM的动机以及OAM和网络管理[OAM Mng]之间的区别。
This memo provides an overview of the different sets of OAM tools defined by the IETF. The set of OAM tools described in this memo are applicable to IP unicast, MPLS, pseudowires, MPLS Transport Profile (MPLS-TP), and TRILL. While OAM tools that are applicable to other technologies exist, they are beyond the scope of this memo.
本备忘录概述了IETF定义的不同OAM工具集。本备忘录中描述的OAM工具集适用于IP单播、MPLS、伪线、MPLS传输配置文件（MPLS-TP）和TRILL。虽然存在适用于其他技术的OAM工具，但它们超出了本备忘录的范围。
This document focuses on IETF documents that have been published as RFCs, while other ongoing OAM-related work is outside the scope.
本文档重点介绍已作为RFC发布的IETF文档，而其他正在进行的OAM相关工作不在本文档范围内。
The IETF has defined OAM protocols and tools in several different contexts. We roughly categorize these efforts into a few sets of OAM-related RFCs, listed in Table 1. Each set defines a logically coupled set of RFCs, although the sets are in some cases intertwined by common tools and protocols.
IETF在几个不同的上下文中定义了OAM协议和工具。我们将这些工作大致归类为几组与OAM相关的RFC，如表1所示。每个集合定义了一组逻辑耦合的RFC，尽管这些集合在某些情况下是由公共工具和协议交织在一起的。
The discussion in this document is ordered according to these sets (the acronyms and abbreviations are listed in Section 2.1).
本文件中的讨论按这些集合排序（首字母缩写和缩写在第2.1节中列出）。
+--------------+------------+
| Toolset | Transport |
| | Technology |
+--------------+------------+
|IP Ping | IPv4/IPv6 |
+--------------+------------+
|IP Traceroute | IPv4/IPv6 |
+--------------+------------+
|BFD | generic |
+--------------+------------+
|MPLS OAM | MPLS |
+--------------+------------+
|MPLS-TP OAM | MPLS-TP |
+--------------+------------+
|Pseudowire OAM| Pseudowires|
+--------------+------------+
|OWAMP and | IPv4/IPv6 |
|TWAMP | |
+--------------+------------+
|TRILL OAM | TRILL |
+--------------+------------+
+--------------+------------+
| Toolset | Transport |
| | Technology |
+--------------+------------+
|IP Ping | IPv4/IPv6 |
+--------------+------------+
|IP Traceroute | IPv4/IPv6 |
+--------------+------------+
|BFD | generic |
+--------------+------------+
|MPLS OAM | MPLS |
+--------------+------------+
|MPLS-TP OAM | MPLS-TP |
+--------------+------------+
|Pseudowire OAM| Pseudowires|
+--------------+------------+
|OWAMP and | IPv4/IPv6 |
|TWAMP | |
+--------------+------------+
|TRILL OAM | TRILL |
+--------------+------------+
Table 1: OAM Toolset Packages in the IETF Documents
表1:IETF文档中的OAM工具集包
This document focuses on OAM tools that have been developed in the IETF. A short summary of some of the significant OAM standards that have been developed in other standard organizations is presented in Appendix A.2.
本文档重点介绍IETF中开发的OAM工具。附录A.2简要总结了其他标准组织制定的一些重要OAM标准。
OAM tools may, and quite often do, work in conjunction with a control plane and/or management plane. OAM provides instrumentation tools for measuring and monitoring the data plane. OAM tools often use control-plane functions, e.g., to initialize OAM sessions and to exchange various parameters. The OAM tools communicate with the management plane to raise alarms, and often OAM tools may be activated by the management plane (as well as by the control plane), e.g., to locate and localize problems.
OAM工具可以并且经常与控制平面和/或管理平面一起工作。OAM提供用于测量和监视数据平面的仪器工具。OAM工具通常使用控制平面函数，例如初始化OAM会话和交换各种参数。OAM工具与管理平面通信以发出警报，并且通常OAM工具可由管理平面（以及控制平面）激活，例如，用于定位和定位问题。
The considerations of the control-plane maintenance tools and the functionality of the management plane are out of scope for this document, which concentrates on presenting the data-plane tools that are used for OAM. Network repair functions such as Fast Reroute (FRR) and protection switching, which are often triggered by OAM protocols, are also out of the scope of this document.
控制平面维护工具和管理平面功能的考虑超出了本文档的范围，本文档重点介绍用于OAM的数据平面工具。通常由OAM协议触发的快速重路由（FRR）和保护交换等网络修复功能也不在本文档的范围内。
Since OAM protocols are used for monitoring the data plane, it is imperative for OAM tools to be capable of testing the actual data plane with as much accuracy as possible. Thus, it is important to enforce fate-sharing between OAM traffic that monitors the data plane and the data-plane traffic it monitors.
由于OAM协议用于监视数据平面，所以OAM工具必须能够以尽可能高的精度测试实际数据平面。因此，在监视数据平面的OAM通信量与其监视的数据平面通信量之间实施命运共享非常重要。
ACH Associated Channel Header
ACH相关信道头
AIS Alarm Indication Signal
AIS报警指示信号
ATM Asynchronous Transfer Mode
异步传输模式
BFD Bidirectional Forwarding Detection
双向转发检测
CC Continuity Check
连续性检查
CC-V Continuity Check and Connectivity Verification
CC-V连续性检查和连接验证
CV Connectivity Verification
CV连通性验证
DM Delay Measurement
DM延迟测量
ECMP Equal-Cost Multipath
等成本多路径
FEC Forwarding Equivalence Class
转发等价类
FRR Fast Reroute
快速重路由
G-ACh Generic Associated Channel
G-ACh通用关联信道
GAL Generic Associated Channel Label
GAL通用关联通道标签
ICMP Internet Control Message Protocol
网际控制信息协议
L2TP Layer 2 Tunneling Protocol
L2TP第二层隧道协议
L2VPN Layer 2 Virtual Private Network
L2VPN第二层虚拟专用网
L3VPN Layer 3 Virtual Private Network
L3VPN第3层虚拟专用网
LCCE L2TP Control Connection Endpoint
LCCE L2TP控制连接端点
LDP Label Distribution Protocol
LDP标签分发协议
LER Label Edge Router
标签边缘路由器
LM Loss Measurement
LM损耗测量
LSP Label Switched Path
标签交换路径
LSR Label Switching Router
标签交换路由器
ME Maintenance Entity
ME维护实体
MEG Maintenance Entity Group
MEG维护实体组
MEP MEG End Point
MEP MEG终点
MIP MEG Intermediate Point
MIP-MEG中间点
MP Maintenance Point
MP维修点
MPLS Multiprotocol Label Switching
多协议标签交换
MPLS-TP MPLS Transport Profile
MPLS-TP MPLS传输配置文件
MTU Maximum Transmission Unit
最大传输单元
OAM Operations, Administration, and Maintenance
OAM操作、管理和维护
OWAMP One-Way Active Measurement Protocol
OWAMP单向主动测量协议
PDH Plesiochronous Digital Hierarchy
准同步数字体系
PE Provider Edge
PE提供商边缘
PSN Public Switched Network
公共交换网
PW Pseudowire
伪线
PWE3 Pseudowire Emulation Edge-to-Edge
PWE3伪线仿真边到边
RBridge Routing Bridge
RBridge路由桥
RDI Remote Defect Indication
远程缺陷指示
SDH Synchronous Digital Hierarchy
同步数字序列
SONET Synchronous Optical Network
SONET同步光网络
TRILL Transparent Interconnection of Lots of Links
大量链路的TRILL透明互连
TTL Time To Live
TTL生存时间
TWAMP Two-Way Active Measurement Protocol
双向主动测量协议
VCCV Virtual Circuit Connectivity Verification
虚拟电路连通性验证
VPN Virtual Private Network
虚拟私有网
A wide variety of terms is used in various OAM standards. This section presents a comparison of the terms used in various OAM standards, without fully quoting the definition of each term.
各种OAM标准中使用了各种各样的术语。本节对各种OAM标准中使用的术语进行了比较，但没有完全引用每个术语的定义。
An interesting overview of the term "OAM" and its derivatives is presented in [OAM-Def]. A thesaurus of terminology for MPLS-TP terms is presented in [TP-Term], which provides a good summary of some of the OAM-related terminology.
[OAM Def]中介绍了术语“OAM”及其衍生物的有趣概述。[TP Term]中介绍了MPLS-TP术语的术语词典，它很好地总结了一些与OAM相关的术语。
The following definition of OAM is quoted from [OAM-Def]:
以下OAM定义引用自[OAM Def]：
The components of the "OAM" acronym (and provisioning) are defined as follows:
“OAM”首字母缩略词（和资源调配）的组成部分定义如下：
o Operations - Operation activities are undertaken to keep the network (and the services that the network provides) up and running. It includes monitoring the network and finding problems. Ideally these problems should be found before users are affected.
o 运营-运营活动旨在保持网络（以及网络提供的服务）正常运行。它包括监控网络和发现问题。理想情况下，应该在用户受到影响之前发现这些问题。
o Administration - Administration activities involve keeping track of resources in the network and how they are used. It includes all the bookkeeping that is necessary to track networking resources and the network under control.
o 管理-管理活动包括跟踪网络中的资源及其使用方式。它包括跟踪网络资源和受控网络所需的所有簿记。
o Maintenance - Maintenance activities are focused on facilitating repairs and upgrades -- for example, when equipment must be replaced, when a router needs a patch for an operating system image, or when a new switch is added to a network. Maintenance also involves corrective and preventive measures to make the managed network run more effectively, e.g., adjusting device configuration and parameters.
o 维护-维护活动的重点是促进维修和升级——例如，当设备必须更换时，当路由器需要操作系统映像补丁时，或当新交换机添加到网络时。维护还包括纠正和预防措施，以使受管网络更有效地运行，例如调整设备配置和参数。
OAM Function
OAM功能
An OAM function is an instrumentation measurement type or diagnostic.
OAM功能是一种仪器测量类型或诊断功能。
OAM functions are the atomic building blocks of OAM, where each function defines an OAM capability.
OAM函数是OAM的原子构建块，其中每个函数定义一个OAM功能。
Typical examples of OAM functions are presented in Section 3.
第3节介绍了OAM功能的典型示例。
OAM Protocol
OAM协议
An OAM protocol is a protocol used for implementing one or more OAM functions.
OAM协议是用于实现一个或多个OAM功能的协议。
The OWAMP-Test [OWAMP] is an example of an OAM protocol.
OWAMP测试[OWAMP]是OAM协议的一个示例。
OAM Tool
OAM工具
An OAM tool is a specific means of applying one or more OAM functions.
OAM工具是应用一个或多个OAM功能的特定方法。
In some cases, an OAM protocol *is* an OAM tool, e.g., OWAMP-Test. In other cases, an OAM tool uses a set of protocols that are not strictly OAM related; for example, Traceroute (Section 4.2) can be implemented using UDP and ICMP messages, without using an OAM protocol per se.
在某些情况下，OAM协议*是一种OAM工具，例如OWAMP测试。在其他情况下，OAM工具使用一组与OAM无关的协议；例如，Traceroute（第4.2节）可以使用UDP和ICMP消息实现，而不使用OAM协议本身。
Data Plane
数据平面
The data plane is the set of functions used to transfer data in the stratum or layer under consideration [ITU-Terms].
数据平面是用于在考虑中的地层或层中传输数据的一组函数[ITU术语]。
The data plane is also known as the forwarding plane or the user plane.
数据平面也称为转发平面或用户平面。
Control Plane
控制平面
The control plane is the set of protocols and mechanisms that enable routers to efficiently learn how to forward packets towards their final destination (based on [Comp]).
控制平面是一组协议和机制，使路由器能够有效地学习如何将数据包转发到其最终目的地（基于[Comp]）。
Management Plane
管理层
The term "Management Plane", as described in [Mng], is used to describe the exchange of management messages through management protocols (often transported by IP and by IP transport protocols) between management applications and the managed entities such as network nodes.
术语“管理平面”（如[Mng]中所述）用于描述管理应用程序和被管理实体（如网络节点）之间通过管理协议（通常通过IP和IP传输协议传输）的管理消息交换。
Data Plane vs. Control Plane vs. Management Plane
数据平面vs.控制平面vs.管理平面
The distinction between the planes is at times a bit vague. For example, the definition of "Control Plane" above may imply that OAM tools such as ping, BFD, and others are in fact in the control plane.
飞机之间的区别有时有点模糊。例如，上面“控制平面”的定义可能意味着诸如ping、BFD等OAM工具实际上在控制平面中。
This document focuses on tools used for monitoring the data plane. While these tools could arguably be considered to be in the control plane, these tools monitor the data plane, and hence it is imperative to have fate-sharing between OAM traffic that monitors the data plane and the data-plane traffic it monitors.
本文档重点介绍用于监视数据平面的工具。虽然这些工具可以被认为是在控制平面中，但这些工具监视数据平面，因此必须在监视数据平面的OAM通信量与其监视的数据平面通信量之间共享命运。
Another potentially vague distinction is between the management plane and control plane. The management plane should be seen as separate from, but possibly overlapping with, the control plane (based on [Mng]).
另一个潜在的模糊区别是管理平面和控制平面之间的区别。管理平面应视为与控制平面分开，但可能重叠（基于[Mng]）。
An OAM tool is used between two (or more) peers. Various terms are used in IETF documents to refer to the players that take part in OAM. Table 2 summarizes the terms used in each of the toolsets discussed in this document.
OAM工具在两个（或多个）对等方之间使用。IETF文档中使用了各种术语来指代参与OAM的参与者。表2总结了本文档中讨论的每个工具集中使用的术语。
+--------------------------+---------------------------+
| Toolset | Terms |
+--------------------------+---------------------------+
| Ping / Traceroute |- Host |
| ([ICMPv4], [ICMPv6], |- Node |
| [TCPIP-Tools]) |- Interface |
| |- Gateway |
+ ------------------------ + ------------------------- +
| BFD [BFD] |- System |
+ ------------------------ + ------------------------- +
| MPLS OAM [MPLS-OAM-FW] |- LSR |
+ ------------------------ + ------------------------- +
| MPLS-TP OAM [TP-OAM-FW] |- End Point - MEP |
| |- Intermediate Point - MIP |
+ ------------------------ + ------------------------- +
| Pseudowire OAM [VCCV] |- PE |
| |- LCCE |
+ ------------------------ + ------------------------- +
| OWAMP and TWAMP |- Host |
| ([OWAMP], [TWAMP]) |- End system |
+ ------------------------ + ------------------------- +
| TRILL OAM [TRILL-OAM] |- RBridge |
+--------------------------+---------------------------+
+--------------------------+---------------------------+
| Toolset | Terms |
+--------------------------+---------------------------+
| Ping / Traceroute |- Host |
| ([ICMPv4], [ICMPv6], |- Node |
| [TCPIP-Tools]) |- Interface |
| |- Gateway |
+ ------------------------ + ------------------------- +
| BFD [BFD] |- System |
+ ------------------------ + ------------------------- +
| MPLS OAM [MPLS-OAM-FW] |- LSR |
+ ------------------------ + ------------------------- +
| MPLS-TP OAM [TP-OAM-FW] |- End Point - MEP |
| |- Intermediate Point - MIP |
+ ------------------------ + ------------------------- +
| Pseudowire OAM [VCCV] |- PE |
| |- LCCE |
+ ------------------------ + ------------------------- +
| OWAMP and TWAMP |- Host |
| ([OWAMP], [TWAMP]) |- End system |
+ ------------------------ + ------------------------- +
| TRILL OAM [TRILL-OAM] |- RBridge |
+--------------------------+---------------------------+
Table 2: Maintenance Point Terminology
表2：维修点术语
The different OAM tools may be used in one of two basic types of activation:
不同的OAM工具可用于两种基本激活类型之一：
Proactive
积极主动的
Proactive activation - indicates that the tool is activated on a continual basis, where messages are sent periodically, and errors are detected when a certain number of expected messages are not received.
主动激活-表示工具连续激活，定期发送消息，当未收到一定数量的预期消息时检测到错误。
On-demand
随需应变
On-demand activation - indicates that the tool is activated "manually" to detect a specific anomaly.
按需激活-表示工具“手动”激活以检测特定异常。
Two distinct classes of failure management functions are used in OAM protocols: Connectivity Verification and Continuity Checks. The distinction between these terms is defined in [MPLS-TP-OAM] and is used similarly in this document.
OAM协议中使用了两类不同的故障管理功能：连接验证和连续性检查。这些术语之间的区别在[MPLS-TP-OAM]中定义，并在本文件中类似使用。
Continuity Check
连续性检查
Continuity Checks are used to verify that a destination is reachable, and are typically sent proactively, though they can be invoked on-demand as well.
连续性检查用于验证目的地是否可到达，通常会主动发送，但也可以按需调用。
Connectivity Verification
连通性验证
A Connectivity Verification function allows Alice to check whether she is connected to Bob or not. It is noted that while the CV function is performed in the data plane, the "expected path" is predetermined in either the control plane or the management plane. A Connectivity Verification (CV) protocol typically uses a CV message, followed by a CV reply that is sent back to the originator. A CV function can be applied proactively or on-demand.
连接验证功能允许Alice检查她是否连接到Bob。注意，当在数据平面中执行CV功能时，在控制平面或管理平面中预先确定“预期路径”。连接性验证（CV）协议通常使用CV消息，然后是发送回发起人的CV回复。CV功能可以主动或按需应用。
Connectivity Verification tools often perform path verification as well, allowing Alice to verify that messages from Bob are received through the correct path, thereby verifying not only that the two MPs are connected, but also that they are connected through the expected path, allowing detection of unexpected topology changes.
连接验证工具通常也执行路径验证，允许Alice验证来自Bob的消息是否通过正确的路径接收，从而不仅验证两个MPs是否连接，还验证它们是否通过预期路径连接，从而允许检测意外的拓扑更改。
Connectivity Verification functions can also be used for checking the MTU of the path between the two peers.
连接验证功能还可用于检查两个对等点之间路径的MTU。
Connectivity Verification and Continuity Checks are considered complementary mechanisms and are often used in conjunction with each other.
连通性验证和连续性检查被认为是互补机制，通常相互结合使用。
Connection-Oriented
面向连接
In connection-oriented technologies, an end-to-end connection is established (by a control protocol or provisioned by a management system) prior to the transmission of data.
在面向连接的技术中，在数据传输之前（通过控制协议或管理系统提供）建立端到端连接。
Typically a connection identifier is used to identify the connection. In connection-oriented technologies, it is often the case (although not always) that all packets belonging to a specific connection use the same route through the network.
通常，连接标识符用于标识连接。在面向连接的技术中，属于特定连接的所有数据包在网络中通常使用相同的路由（尽管并非总是如此）。
Connectionless
无连接
In connectionless technologies, data is typically sent between end points without prior arrangement. Packets are routed independently based on their destination address, and hence different packets may be routed in a different way across the network.
在无连接技术中，数据通常在端点之间发送，无需事先安排。数据包根据其目的地地址独立路由，因此不同的数据包可以在网络上以不同的方式路由。
Discussion
讨论
The OAM tools described in this document include tools that support connection-oriented technologies, as well as tools for connectionless technologies.
本文档中描述的OAM工具包括支持面向连接技术的工具，以及用于无连接技术的工具。
In connection-oriented technologies, OAM is used to monitor a *specific* connection; OAM packets are forwarded through the same route as the data traffic and receive the same treatment. In connectionless technologies, OAM is used between a source and destination pair without defining a specific connection. Moreover, in some cases, the route of OAM packets may differ from the one of the data traffic. For example, the connectionless IP Ping (Section 4.1) tests the reachability from a source to a given destination, while the connection-oriented LSP Ping (Section 4.4.1) is used for monitoring a specific LSP (connection) and provides the capability to monitor all the available paths used by an LSP.
在面向连接的技术中，OAM用于监视*特定*连接；OAM数据包通过与数据通信相同的路由转发，并接受相同的处理。在无连接技术中，OAM在源和目标对之间使用，而不定义特定的连接。此外，在某些情况下，OAM分组的路由可能不同于数据业务的路由。例如，无连接IP Ping（第4.1节）测试从源到给定目标的可达性，而面向连接的LSP Ping（第4.4.1节）用于监控特定LSP（连接），并提供监控LSP使用的所有可用路径的能力。
It should be noted that in some cases connectionless protocols are monitored by connection-oriented OAM protocols. For example, while IP is a connectionless protocol, it can be monitored by BFD (Section 4.3), which is connection oriented.
应该注意，在某些情况下，无连接协议由面向连接的OAM协议监控。例如，虽然IP是无连接协议，但它可以由面向连接的BFD（第4.3节）进行监控。
Point-to-point (P2P)
点对点（P2P）
A P2P service delivers data from a single source to a single destination.
P2P服务将数据从单一来源传送到单一目的地。
Point-to-multipoint (P2MP)
点对多点（P2MP）
A P2MP service delivers data from a single source to a one or more destinations (based on [Signal]).
P2MP服务将数据从单一来源传送到一个或多个目的地（基于[信号]）。
An MP2MP service is a service that delivers data from more than one source to one or more receivers (based on [Signal]).
MP2MP服务是一种将数据从多个源传送到一个或多个接收器（基于[信号]）的服务。
Note: the two definitions for P2MP and MP2MP are quoted from [Signal]. Although [Signal] describes a specific case of P2MP and MP2MP that is MPLS-specific, these two definitions also apply to non-MPLS cases.
注：P2MP和MP2MP的两个定义引用自[信号]。虽然[Signal]描述了MPLS特定的P2MP和MP2MP的特定情况，但这两个定义也适用于非MPLS情况。
Discussion
讨论
The OAM tools described in this document include tools for P2P services, as well as tools for P2MP services.
本文档中描述的OAM工具包括用于P2P服务的工具以及用于P2MP服务的工具。
The distinction between P2P services and P2MP services affects the corresponding OAM tools. A P2P service is typically simpler to monitor, as it consists of a single pair of endpoints. P2MP and MP2MP services present several challenges. For example, in a P2MP service, the OAM mechanism not only verifies that each of the destinations is reachable from the source but also verifies that the P2MP distribution tree is intact and loop-free.
P2P服务和P2MP服务之间的区别会影响相应的OAM工具。P2P服务通常更易于监控，因为它由一对端点组成。P2MP和MP2MP服务面临若干挑战。例如，在P2MP服务中，OAM机制不仅验证每个目的地是否可以从源访问，而且还验证P2MP分发树是否完整且无循环。
The terms "Failure", "Fault", and "Defect" are used interchangeably in the standards, referring to a malfunction that can be detected by a Connectivity Verification or a Continuity Check. In some standards, such as 802.1ag [IEEE802.1Q], there is no distinction between these terms, while in other standards each of these terms refers to a different type of malfunction.
术语“故障”、“故障”和“缺陷”在标准中互换使用，指的是可通过连接验证或连续性检查检测到的故障。在一些标准中，如802.1ag[IEEE802.1Q]，这些术语之间没有区别，而在其他标准中，这些术语中的每一个都指不同类型的故障。
The terminology used in IETF MPLS-TP OAM is based on the ITU-T terminology, which distinguishes between these three terms in [ITU-T-G.806] as follows:
IETF MPLS-TP OAM中使用的术语基于ITU-T术语，该术语在[ITU-T-G.806]中对这三个术语的区别如下：
Fault
过错
The term "Fault" refers to an inability to perform a required action, e.g., an unsuccessful attempt to deliver a packet.
术语“故障”是指无法执行所需的操作，例如，发送数据包的尝试不成功。
Defect
缺点
The term "Defect" refers to an interruption in the normal operation, such as a consecutive period of time where no packets are delivered successfully.
术语“缺陷”是指正常操作中的中断，例如没有成功传送分组的连续时间段。
Failure
失败
The term "Failure" refers to the termination of the required function. While a Defect typically refers to a limited period of time, a failure refers to a long period of time.
术语“故障”指所需功能的终止。虽然缺陷通常指的是有限的时间段，但故障指的是较长的时间段。
This subsection provides a brief summary of the common OAM functions used in OAM-related standards. These functions are used as building blocks in the OAM standards described in this document.
本小节简要概述了OAM相关标准中使用的常见OAM功能。这些功能在本文档中描述的OAM标准中用作构建块。
o Connectivity Verification (CV), Path Verification, and Continuity Check (CC): As defined in Section 2.2.7.
o 连通性验证（CV）、路径验证和连续性检查（CC）：如第2.2.7节所述。
o Path Discovery / Fault Localization: This function can be used to trace the route to a destination, i.e., to identify the nodes along the route to the destination. When more than one route is available to a specific destination, this function traces one of the available routes. When a failure occurs, this function attempts to detect the location of the failure. Note that the term "route tracing" (or "Traceroute"), which is used in the context of IP and MPLS, is sometimes referred to as "path tracing" in the context of other protocols, such as TRILL.
o 路径发现/故障定位：此功能可用于跟踪到目的地的路由，即识别到目的地的路由沿线的节点。当一个特定目的地有多条路由可用时，此函数跟踪其中一条可用路由。发生故障时，此函数尝试检测故障的位置。注意，在IP和MPLS的上下文中使用的术语“路由跟踪”（或“Traceroute”）有时在其他协议（例如TRILL）的上下文中被称为“路径跟踪”。
o Performance Monitoring: Typically refers to:
o 性能监控：通常指：
* Loss Measurement (LM) - monitors the packet loss rate.
* 丢失测量（LM）-监控数据包丢失率。
* Delay Measurement (DM) - monitors the delay and delay variation (jitter).
* 延迟测量（DM）-监控延迟和延迟变化（抖动）。
This section presents a detailed description of the sets of OAM-related tools in each of the toolsets in Table 1.
本节详细描述了表1中每个工具集中与OAM相关的工具集。
Ping is a common network diagnostic application for IP networks that use ICMP. According to [NetTerms], 'Ping' is an abbreviation for Packet internet groper, although the term has been so commonly used that it stands on its own. As defined in [NetTerms], it is a program used to test reachability of destinations by sending them an ICMP Echo request and waiting for a reply.
Ping是使用ICMP的IP网络的常见网络诊断应用程序。根据[NetTerms]，“Ping”是分组互联网groper的缩写，尽管这个词已经被广泛使用，以至于它本身就存在。如[NetTerms]中所定义，它是一个程序，用于通过向目的地发送ICMP回显请求并等待回复来测试目的地的可达性。
The ICMP Echo request/reply exchange in Ping is used as a Continuity Check function for the Internet Protocol. The originator transmits an ICMP Echo request packet, and the receiver replies with an Echo reply. ICMP Ping is defined in two variants: [ICMPv4] is used for IPv4, and [ICMPv6] is used for IPv6.
Ping中的ICMP回显请求/应答交换用作Internet协议的连续性检查功能。发端发送ICMP回显请求数据包，接收方回复回显回复。ICMP Ping在两个变体中定义：[ICMPv4]用于IPv4，而[ICMPv6]用于IPv6。
Ping can be invoked to either a unicast destination or a multicast destination. In the latter case, all members of the multicast group send an Echo reply back to the originator.
Ping可以调用到单播目的地或多播目的地。在后一种情况下，多播组的所有成员都向发端发送回显回复。
Ping implementations typically use ICMP messages. UDP Ping is a variant that uses UDP messages instead of ICMP Echo messages.
Ping实现通常使用ICMP消息。UDP Ping是一种使用UDP消息而不是ICMP回显消息的变体。
Ping is a single-ended Continuity Check, i.e., it allows the *initiator* of the Echo request to test the reachability. If it is desirable for both ends to test the reachability, both ends have to invoke Ping independently.
Ping是单端连续性检查，即它允许Echo请求的*启动器*测试可达性。如果希望两端都测试可达性，那么两端都必须独立地调用Ping。
Note that since ICMP filtering is deployed in some routers and firewalls, the usefulness of Ping is sometimes limited in the wider Internet. This limitation is equally relevant to Traceroute.
请注意，由于ICMP过滤部署在某些路由器和防火墙中，Ping的用途有时在更广泛的Internet中受到限制。该限制与跟踪路由同样相关。
Traceroute ([TCPIP-Tools], [NetTools]) is an application that allows users to discover a path between an IP source and an IP destination.
Traceroute（[TCPIP工具]，[NetTools]）是一个应用程序，允许用户发现IP源和IP目标之间的路径。
The most common way to implement Traceroute [TCPIP-Tools] is described as follows. Traceroute sends a sequence of UDP packets to UDP port 33434 at the destination. By default, Traceroute begins by sending three packets (the number of packets is configurable in most Traceroute implementations), each with an IP Time-To-Live (or Hop Limit in IPv6) value of one, to the destination. These packets expire as soon as they reach the first router in the path. Consequently, that router sends three ICMP Time Exceeded Messages back to the Traceroute application. Traceroute now sends another three UDP packets, each with the TTL value of 2. These messages cause the second router to return ICMP messages. This process continues, with ever-increasing values for the TTL field, until the packets actually reach the destination. Because no application listens to port 33434 at the destination, the destination returns ICMP Destination Unreachable Messages indicating an unreachable port. This event indicates to the Traceroute application that it is finished. The Traceroute program displays the round-trip delay associated with each of the attempts.
实现Traceroute[TCPIP工具]最常用的方法如下所述。跟踪路由将UDP数据包序列发送到目标的UDP端口33434。默认情况下，跟踪路由首先向目标发送三个数据包（在大多数跟踪路由实现中，数据包的数量是可配置的），每个数据包的IP生存时间（或IPv6中的跃点限制）值为1。这些数据包一到达路径中的第一个路由器就过期。因此，该路由器将三条超过ICMP时间的消息发送回跟踪路由应用程序。Traceroute现在发送另外三个UDP数据包，每个数据包的TTL值为2。这些消息导致第二个路由器返回ICMP消息。这个过程继续进行，TTL字段的值不断增加，直到数据包实际到达目的地。由于没有应用程序在目标上侦听端口33434，因此目标返回指示无法访问端口的ICMP destination Unreachable消息。此事件向跟踪路由应用程序指示它已完成。Traceroute程序显示与每次尝试相关的往返延迟。
While Traceroute is a tool that finds *a* path from A to B, it should be noted that traffic from A to B is often forwarded through Equal-Cost Multipaths (ECMPs). Paris Traceroute [PARIS] is an extension to Traceroute that attempts to discovers all the available paths from A to B by scanning different values of header fields (such as UDP ports) in the probe packets.
虽然Traceroute是一种查找从a到B的*a*路径的工具，但应该注意的是，从a到B的流量通常通过等成本多路径（ECMP）转发。Paris Traceroute[Paris]是Traceroute的一个扩展，它试图通过扫描探测数据包中不同值的报头字段（如UDP端口）来发现从A到B的所有可用路径。
It is noted that Traceroute is an application, and not a protocol. As such, it has various different implementations. One of the most common ones uses UDP probe packets, as described above. Other implementations exist that use other types of probe messages, such as ICMP or TCP.
需要注意的是，Traceroute是一个应用程序，而不是一个协议。因此，它有各种不同的实现。最常见的一种使用UDP探测数据包，如上所述。存在使用其他类型的探测消息（如ICMP或TCP）的其他实现。
Note that IP routing may be asymmetric. While Traceroute discovers a path between a source and destination, it does not reveal the reverse path.
请注意，IP路由可能是不对称的。虽然Traceroute发现源和目标之间的路径，但它不会显示反向路径。
A few ICMP extensions ([ICMP-MP], [ICMP-Int]) have been defined in the context of Traceroute. These documents define several extensions, including extensions to the ICMP Destination Unreachable message, that can be used by Traceroute applications.
在Traceroute的上下文中定义了一些ICMP扩展（[ICMP-MP]、[ICMP Int]）。这些文档定义了几个扩展，包括跟踪路由应用程序可以使用的ICMP目标不可访问消息的扩展。
Traceroute allows path discovery to *unicast* destination addresses. A similar tool [mtrace] was defined for multicast destination addresses; it allows tracing the route that a multicast IP packet takes from a source to a particular receiver.
跟踪路由允许到*单播*目标地址的路径发现。为多播目标地址定义了类似的工具[mtrace]；它允许跟踪多播IP数据包从源到特定接收器的路由。
While multiple OAM tools have been defined for various protocols in the protocol stack, Bidirectional Forwarding Detection [BFD], defined by the IETF BFD working group, is a generic OAM tool that can be deployed over various encapsulating protocols, and in various medium types. The IETF has defined variants of the protocol for IP ([BFD-IP], [BFD-Multi]), for MPLS LSPs [BFD-LSP], and for pseudowires [BFD-VCCV]. The usage of BFD in MPLS-TP is defined in [TP-CC-CV].
虽然已经为协议栈中的各种协议定义了多个OAM工具，但由IETF BFD工作组定义的双向转发检测[BFD]是一个通用的OAM工具，可以部署在各种封装协议和各种介质类型上。IETF定义了IP（[BFD-IP]、[BFD Multi]）、MPLS LSP[BFD-LSP]和伪线[BFD-VCCV]的协议变体。MPLS-TP中BFD的使用定义见[TP-CC-CV]。
BFD includes two main OAM functions, using two types of BFD packets: BFD Control packets and BFD Echo packets.
BFD包括两个主要的OAM功能，使用两种类型的BFD数据包：BFD控制数据包和BFD回送数据包。
BFD operates between *systems*. The BFD protocol is run between two or more systems after establishing a *session*.
BFD在*系统*之间运行。BFD协议在建立*会话*后在两个或多个系统之间运行。
BFD supports a bidirectional Continuity Check, using BFD Control packets that are exchanged within a BFD session. BFD sessions operate in one of two modes:
BFD支持双向连续性检查，使用BFD会话中交换的BFD控制数据包。BFD会话以两种模式之一运行：
o Asynchronous mode (i.e., proactive): in this mode, BFD Control packets are sent periodically. When the receiver detects that no BFD Control packets have been received during a predetermined period of time, a failure is reported.
o 异步模式（即主动）：在此模式下，定期发送BFD控制数据包。当接收机检测到在预定时间段内没有接收到BFD控制分组时，报告故障。
o Demand mode: in this mode, BFD Control packets are sent on demand. Upon need, a system initiates a series of BFD Control packets to check the continuity of the session. BFD Control packets are sent independently in each direction.
o 需求模式：在此模式下，BFD控制数据包按需发送。根据需要，系统启动一系列BFD控制数据包以检查会话的连续性。BFD控制数据包在每个方向上独立发送。
Each of the endpoints (referred to as systems) of the monitored path maintains its own session identification, called a Discriminator; both Discriminators are included in the BFD Control Packets that are exchanged between the endpoints. At the time of session establishment, the Discriminators are exchanged between the two endpoints. In addition, the transmission (and reception) rate is
被监视路径的每个端点（称为系统）维护其自己的会话标识，称为鉴别器；这两个鉴别器都包含在端点之间交换的BFD控制数据包中。在会话建立时，鉴别器在两个端点之间交换。此外，发送（和接收）速率为
negotiated between the two endpoints, based on information included in the control packets. These transmission rates may be renegotiated during the session.
根据控制数据包中包含的信息在两个端点之间协商。这些传输速率可以在会话期间重新协商。
During normal operation of the session, i.e., when no failures have been detected, the BFD session is in the Up state. If no BFD Control packets are received during a period of time called the Detection Time, the session is declared to be Down. The detection time is a function of the pre-configured or negotiated transmission rate and a parameter called Detect Mult. Detect Mult determines the number of missing BFD Control packets that cause the session to be declared as Down. This parameter is included in the BFD Control packet.
会话正常运行期间，即未检测到故障时，BFD会话处于启动状态。如果在一段称为检测时间的时间内没有收到BFD控制数据包，则会话被声明为关闭。检测时间是预先配置或协商的传输速率和称为Detect Mult的参数的函数。Detect Mult确定导致会话声明为关闭的丢失BFD控制数据包的数量。此参数包含在BFD控制数据包中。
A BFD Echo packet is sent to a peer system and is looped back to the originator. The echo function can be used proactively or on demand.
BFD回显数据包被发送到对等系统，并被循环回发起人。可主动或按需使用回显功能。
The BFD Echo function has been defined in BFD for IPv4 and IPv6 ([BFD-IP]), but it is not used in BFD for MPLS LSPs or PWs, or in BFD for MPLS-TP.
BFD Echo函数已在IPv4和IPv6的BFD（[BFD-IP]）中定义，但未在MPLS LSP或PWs的BFD中使用，也未在MPLS-TP的BFD中使用。
The IETF MPLS working group has defined OAM for MPLS LSPs. The requirements and framework of this effort are defined in [MPLS-OAM-FW] and [MPLS-OAM], respectively. The corresponding OAM tool defined, in this context, is LSP Ping [LSP-Ping]. OAM for P2MP services is defined in [MPLS-P2MP].
IETF MPLS工作组为MPLS LSP定义了OAM。这项工作的要求和框架分别在[MPLS-OAM-FW]和[MPLS-OAM]中定义。在此上下文中定义的相应OAM工具是LSP Ping[LSP Ping]。P2MP服务的OAM在[MPLS-P2MP]中定义。
BFD for MPLS [BFD-LSP] is an alternative means for detecting data-plane failures, as described below.
用于MPLS的BFD[BFD-LSP]是检测数据平面故障的替代方法，如下所述。
LSP Ping is modeled after the Ping/Traceroute paradigm, and thus it may be used in one of two modes:
LSP Ping是按照Ping/Traceroute范式建模的，因此可以在以下两种模式之一中使用：
o "Ping" mode: In this mode, LSP Ping is used for end-to-end Connectivity Verification between two LERs.
o “Ping”模式：在此模式下，LSP Ping用于验证两个LER之间的端到端连接。
o "Traceroute" mode: This mode is used for hop-by-hop fault isolation.
o “跟踪路由”模式：该模式用于逐跳故障隔离。
LSP Ping is based on the ICMP Ping operation (of data-plane Connectivity Verification) with additional functionality to verify data-plane vs. control-plane consistency for a Forwarding Equivalence Class (FEC) and also to identify Maximum Transmission Unit (MTU) problems.
LSP Ping基于（数据平面连接验证的）ICMP Ping操作，具有验证转发等价类（FEC）的数据平面与控制平面一致性的附加功能，还可以识别最大传输单元（MTU）问题。
The Traceroute functionality may be used to isolate and localize MPLS faults, using the Time-To-Live (TTL) indicator to incrementally identify the sub-path of the LSP that is successfully traversed before the faulty link or node.
跟踪路由功能可用于隔离和定位MPLS故障，使用生存时间（TTL）指示符递增地标识在故障链路或节点之前成功穿越的LSP子路径。
The challenge in MPLS networks is that the traffic of a given LSP may be load-balanced across Equal-Cost Multipaths (ECMPs). LSP Ping monitors all the available paths of an LSP by monitoring its different FECs. Note that MPLS-TP does not use ECMP, and thus does not require OAM over multiple paths.
MPLS网络面临的挑战是，给定LSP的流量可能在等成本多路径（ECMPs）上实现负载平衡。LSP Ping通过监视LSP的不同FEC来监视LSP的所有可用路径。请注意，MPLS-TP不使用ECMP，因此不需要通过多条路径进行OAM。
Another challenge is that an MPLS LSP does not necessarily have a return path; traffic that is sent back from the egress LSR to the ingress LSR is not necessarily sent over an MPLS LSP, but it can be sent through a different route, such as an IP route. Thus, responding to an LSP Ping message is not necessarily as trivial as in IP Ping, where the responder just swaps the source and destination IP addresses. Note that this challenge is not applicable to MPLS-TP, where a return path is always available.
另一个挑战是MPLS LSP不一定具有返回路径；从出口LSR发送回入口LSR的通信量不一定通过MPLS LSP发送，但可以通过不同的路由（例如IP路由）发送。因此，响应LSP Ping消息不一定像在IP Ping中那样简单，在IP Ping中，响应者只是交换源和目标IP地址。请注意，此挑战不适用于MPLS-TP，因为在MPLS-TP中，返回路径始终可用。
It should be noted that LSP Ping supports unique identification of the LSP within an addressing domain. The identification is checked using the full FEC identification. LSP Ping is extensible to include additional information needed to support new functionality, by use of Type-Length-Value (TLV) constructs. The usage of TLVs is typically handled by the control plane, as it is not easy to implement in hardware.
应该注意的是，LSP Ping支持在寻址域中唯一标识LSP。使用完整的FEC标识检查标识。通过使用类型长度值（TLV）构造，LSP Ping可扩展为包括支持新功能所需的附加信息。TLV的使用通常由控制平面处理，因为它不容易在硬件中实现。
LSP Ping supports both asynchronous and on-demand activation.
LSP Ping支持异步和按需激活。
BFD [BFD-LSP] can be used to detect MPLS LSP data-plane failures.
BFD[BFD-LSP]可用于检测MPLS LSP数据平面故障。
A BFD session is established for each MPLS LSP that is being monitored. BFD Control packets must be sent along the same path as the monitored LSP. If the LSP is associated with multiple FECs, a BFD session is established for each FEC.
为被监视的每个MPLS LSP建立BFD会话。BFD控制数据包必须沿着与受监控LSP相同的路径发送。如果LSP与多个FEC相关联，则为每个FEC建立BFD会话。
While LSP Ping can be used for detecting MPLS data-plane failures and for verifying the MPLS LSP data plane against the control plane, BFD can only be used for the former. BFD can be used in conjunction with LSP Ping, as is the case in MPLS-TP (see Section 4.5.4).
虽然LSP Ping可用于检测MPLS数据平面故障并根据控制平面验证MPLS LSP数据平面，但BFD只能用于前者。BFD可与LSP Ping结合使用，如MPLS-TP中的情况（见第4.5.4节）。
The IETF has defined two classes of VPNs: Layer 2 VPNs (L2VPNs) and Layer 3 VPNs (L3VPNs). [L2VPN-OAM] provides the requirements and framework for OAM in the context of L2VPNs, and specifically it also defines the OAM layering of L2VPNs over MPLS. [L3VPN-OAM] provides a framework for the operation and management of L3VPNs.
IETF定义了两类VPN：第2层VPN（L2VPN）和第3层VPN（L3VPN）。[L2VPN-OAM]提供了L2VPN上下文中OAM的要求和框架，特别是它还定义了基于MPLS的L2VPN的OAM分层。[L3VPN-OAM]为L3VPN的运营和管理提供了一个框架。
The MPLS working group has defined the OAM toolset that fulfills the requirements for MPLS-TP OAM. The full set of requirements for MPLS-TP OAM are defined in [MPLS-TP-OAM] and include both general requirements for the behavior of the OAM tools and a set of operations that should be supported by the OAM toolset. The set of mechanisms required are further elaborated in [TP-OAM-FW], which describes the general architecture of the OAM system and also gives overviews of the functionality of the OAM toolset.
MPLS工作组定义了满足MPLS-TP OAM要求的OAM工具集。MPLS-TP OAM的全套要求在[MPLS-TP-OAM]中定义，包括OAM工具行为的一般要求和OAM工具集应支持的一套操作。[TP-OAM-FW]进一步阐述了所需的机制集，其中描述了OAM系统的一般架构，并概述了OAM工具集的功能。
Some of the basic requirements for the OAM toolset for MPLS-TP are:
MPLS-TP的OAM工具集的一些基本要求是：
o MPLS-TP OAM must be able to support both an IP-based environment and a non-IP-based environment. If the network is IP based, i.e., IP routing and forwarding are available, then the MPLS-TP OAM toolset should rely on the IP routing and forwarding capabilities. On the other hand, in environments where IP functionality is not available, the OAM tools must still be able to operate without dependence on IP forwarding and routing.
o MPLS-TP OAM必须能够同时支持基于IP的环境和非基于IP的环境。如果网络基于IP，即IP路由和转发可用，则MPLS-TP OAM工具集应依赖于IP路由和转发功能。另一方面，在IP功能不可用的环境中，OAM工具必须仍然能够在不依赖IP转发和路由的情况下运行。
o OAM packets and the user traffic are required to be congruent (i.e., OAM packets are transmitted in-band), and there is a need to differentiate OAM packets from ordinary user packets in the data plane. Inherent in this requirement is the principle that MPLS-TP OAM be independent of any existing control plane, although it should not preclude use of the control-plane functionality. OAM packets are identified by the Generic Associated Channel Label (GAL), which is a reserved MPLS label value (13).
o OAM分组和用户业务需要是一致的（即，OAM分组在频带中传输），并且需要在数据平面中将OAM分组与普通用户分组区分开来。该要求固有的原则是MPLS-TP OAM独立于任何现有的控制平面，尽管它不应排除控制平面功能的使用。OAM分组由通用关联信道标签（GAL）标识，GAL是保留的MPLS标签值（13）。
Maintenance Entity (ME)
维护实体（ME）
The MPLS-TP OAM tools are designed to monitor and manage a Maintenance Entity (ME). An ME, as defined in [TP-OAM-FW], defines a relationship between two points of a transport path to which maintenance and monitoring operations apply.
MPLS-TP OAM工具设计用于监视和管理维护实体（ME）。[TP-OAM-FW]中定义的ME定义了维护和监控操作适用的传输路径两点之间的关系。
The term "Maintenance Entity (ME)" is used in ITU-T Recommendations (e.g., [ITU-T-Y1731]), as well as in the MPLS-TP terminology ([TP-OAM-FW]).
术语“维护实体（ME）”用于ITU-T建议（例如，[ITU-T-Y1731]）以及MPLS-TP术语（[TP-OAM-FW]）。
Maintenance Entity Group (MEG)
维护实体组（MEG）
The collection of one or more MEs that belong to the same transport path and that are maintained and monitored as a group are known as a Maintenance Entity Group (based on [TP-OAM-FW]).
属于同一传输路径并作为一个组进行维护和监控的一个或多个MEs的集合称为维护实体组（基于[TP-OAM-FW]）。
Maintenance Point (MP)
维修点（MP）
A Maintenance Point (MP) is a functional entity that is defined at a node in the network and can initiate and/or react to OAM messages. This document focuses on the data-plane functionality of MPs, while MPs interact with the control plane and with the management plane as well.
维护点（MP）是在网络中的节点上定义的功能实体，可以启动和/或响应OAM消息。本文档重点介绍MPs的数据平面功能，同时MPs与控制平面以及管理平面进行交互。
The term "MP" is used in IEEE 802.1ag and was similarly adopted in MPLS-TP ([TP-OAM-FW]).
术语“MP”在IEEE 802.1ag中使用，在MPLS-TP（[TP-OAM-FW]）中也同样采用。
MEG End Point (MEP)
MEG终点（MEP）
A MEG End Point (MEP) is one of the endpoints of an ME, and can initiate OAM messages and respond to them (based on [TP-OAM-FW]).
MEG端点（MEP）是ME的端点之一，可以启动OAM消息并响应它们（基于[TP-OAM-FW]）。
MEG Intermediate Point (MIP)
MEG中间点（MIP）
In between MEPs, there are zero or more intermediate points, called MEG Intermediate Points (based on [TP-OAM-FW]).
在MEP之间，有零个或多个中间点，称为MEG中间点（基于[TP-OAM-FW]）。
A MEG Intermediate Point (MIP) is an intermediate point that does not generally initiate OAM frames (one exception to this is the use of AIS notifications) but is able to respond to OAM frames that are destined to it. A MIP in MPLS-TP identifies OAM packets destined to it by the expiration of the TTL field in the OAM packet. The term "Maintenance Point" is a general term for MEPs and MIPs.
MEG中间点（MIP）是一个中间点，通常不启动OAM帧（AIS通知的使用是一个例外），但能够响应发送给它的OAM帧。MPLS-TP中的MIP通过OAM数据包中的TTL字段过期来识别目的地为其的OAM数据包。术语“维护点”是MEP和MIP的通用术语。
Up and Down MEPs
上下欧洲议会议员
IEEE 802.1ag [IEEE802.1Q] defines a distinction between Up MEPs and Down MEPs. A MEP monitors traffic in either the direction facing the network or the direction facing the bridge. A Down MEP is a MEP that receives OAM packets from and transmits them to the direction of the network. An Up MEP receives OAM packets from and transmits them to the direction of the bridging entity. MPLS-TP ([TP-OAM-FW]) uses a similar distinction on the placement of the MEP -- at either the ingress, egress, or forwarding function of the node (Down / Up MEPs). This placement is important for localization of a failure.
IEEE 802.1ag[IEEE802.1Q]定义了上行MEP和下行MEP之间的区别。MEP监测面向网络或面向网桥方向的流量。下行MEP是从网络接收OAM数据包并将其发送到网络方向的MEP。Up-MEP从桥接实体接收OAM分组并将其发送到桥接实体的方向。MPLS-TP（[TP-OAM-FW]）在MEP的位置上使用了类似的区别——在节点的入口、出口或转发功能处（向下/向上MEP）。该位置对于故障定位非常重要。
Note that the terms "Up MEP" and "Down MEP" are entirely unrelated to the conventional "Up"/"Down" terminology, where "Down" means faulty and "Up" means not faulty.
请注意，术语“向上MEP”和“向下MEP”与传统的“向上”/“向下”术语完全无关，其中“向下”表示故障，“向上”表示无故障。
The distinction between Up and Down MEPs was defined in [TP-OAM-FW], but has not been used in other MPLS-TP RFCs, as of the writing of this document.
[TP-OAM-FW]中定义了上行和下行MEP之间的区别，但截至本文件编写时，其他MPLS-TP RFC中尚未使用。
In order to address the requirement for in-band transmission of MPLS-TP OAM traffic, MPLS-TP uses a Generic Associated Channel (G-ACh), defined in [G-ACh] for LSP-based OAM traffic. This mechanism is based on the same concepts as the PWE3 ACH [PW-ACH] and VCCV [VCCV] mechanisms. However, to address the needs of LSPs as differentiated from PW, the following concepts were defined for [G-ACh]:
为了满足MPLS-TP OAM业务带内传输的要求，MPLS-TP使用[G-ACh]中为基于LSP的OAM业务定义的通用关联信道（G-ACh）。该机制基于与PWE3 ACH[PW-ACH]和VCCV[VCCV]机制相同的概念。然而，为了满足LSP不同于PW的需求，为[G-ACh]定义了以下概念：
o An Associated Channel Header (ACH), which uses a format similar to the PW Control Word [PW-ACH], is a 4-byte header that is prepended to OAM packets.
o 使用类似于PW控制字[PW-ACH]的格式的关联信道报头（ACH）是一个4字节报头，在OAM数据包之前。
o A Generic Associated Channel Label (GAL). The GAL is a reserved MPLS label value (13) that indicates that the packet is an ACH packet and the payload follows immediately after the label stack.
o 通用关联通道标签（GAL）。GAL是保留的MPLS标签值（13），它指示该分组是ACH分组，并且有效负载紧跟在标签堆栈之后。
It should be noted that while the G-ACh was defined as part of the MPLS-TP definition effort, the G-ACh is a generic tool that can be used in MPLS in general, and not only in MPLS-TP.
应该注意的是，虽然G-ACh被定义为MPLS-TP定义工作的一部分，但G-ACh是一种通用工具，通常可以在MPLS中使用，而不仅仅是在MPLS-TP中使用。
To address the functionality that is required of the OAM toolset, the MPLS WG conducted an analysis of the existing IETF and ITU-T OAM tools and their ability to fulfill the required functionality. The
为了解决OAM工具集所需的功能，MPLS工作组对现有IETF和ITU-T OAM工具及其实现所需功能的能力进行了分析。这个
conclusions of this analysis are documented in [OAM-Analys]. MPLS-TP uses a mixture of OAM tools that are based on previous standards and adapted to the requirements of [MPLS-TP-OAM]. Some of the main building blocks of this solution are based on:
该分析的结论记录在[OAM分析]中。MPLS-TP使用基于先前标准并适应[MPLS-TP-OAM]要求的混合OAM工具。此解决方案的一些主要构建块基于：
o Bidirectional Forwarding Detection ([BFD], [BFD-LSP]) for proactive Continuity Check and Connectivity Verification.
o 双向转发检测（[BFD]，[BFD-LSP]），用于主动连续性检查和连接验证。
o LSP Ping as defined in [LSP-Ping] for on-demand Connectivity Verification.
o [LSP Ping]中定义的LSP Ping，用于按需连接验证。
o New protocol packets, using G-ACH, to address different functionality.
o 新的协议包，使用G-ACH，以解决不同的功能。
o Performance measurement protocols.
o 性能测量协议。
The following subsections describe the OAM tools defined for MPLS-TP as described in [TP-OAM-FW].
以下小节描述了为MPLS-TP定义的OAM工具，如[TP-OAM-FW]中所述。
Continuity Checks and Connectivity Verification are presented in Section 2.2.7 of this document. As presented there, these tools may be used either proactively or on demand. When using these tools proactively, they are generally used in tandem.
本文件第2.2.7节介绍了连续性检查和连通性验证。如图所示，这些工具可以主动使用，也可以按需使用。当主动使用这些工具时，它们通常会同时使用。
For MPLS-TP there are two distinct tools: the proactive tool is defined in [TP-CC-CV], while the on-demand tool is defined in [OnDemand-CV]. In on-demand mode, this function should support monitoring between the MEPs and, in addition, between a MEP and MIP. [TP-OAM-FW] highlights, when performing Connectivity Verification, the need for the CC-V messages to include unique identification of the MEG that is being monitored and the MEP that originated the message.
对于MPLS-TP，有两种不同的工具：主动工具在[TP-CC-CV]中定义，而按需工具在[OnDemand CV]中定义。在按需模式下，此功能应支持MEP之间以及MEP和MIP之间的监控。[TP-OAM-FW]强调，在执行连接验证时，CC-V消息需要包括被监控MEG和发起消息的MEP的唯一标识。
The proactive tool [TP-CC-CV] is based on extensions to BFD (see Section 4.3) with the additional limitation that the transmission and receiving rates are based on configuration by the operator. The on-demand tool [OnDemand-CV] is an adaptation of LSP Ping (see Section 4.4.1) for the required behavior of MPLS-TP.
主动工具[TP-CC-CV]基于BFD的扩展（见第4.3节），附加限制是传输和接收速率基于操作员的配置。按需工具[OnDemand CV]是LSP Ping（见第4.4.1节）的一种改编，用于MPLS-TP的所需行为。
[MPLS-TP-OAM] defines that there is a need for functionality that would allow a path endpoint to identify the intermediate and endpoints of the path. This function would be used in on-demand mode. Normally, this path will be used for bidirectional PW, LSP,
[MPLS-TP-OAM]定义需要允许路径端点识别路径的中间和端点的功能。此功能将在按需模式下使用。通常，该路径将用于双向PW、LSP、，
and Sections; however, unidirectional paths may be supported only if a return path exists. The tool for this is based on the LSP Ping (see Section 4.4.1) functionality and is described in [OnDemand-CV].
和部门；但是，仅当存在返回路径时，才支持单向路径。此工具基于LSP Ping（见第4.4.1节）功能，并在[OnDemand CV]中进行了描述。
The Lock Instruct function [Lock-Loop] is used to notify a transport-path endpoint of an administrative need to disable the transport path. This functionality will generally be used in conjunction with some intrusive OAM function, e.g., performance measurement or diagnostic testing, to minimize the side-effect on user data traffic.
锁定指令函数[Lock Loop]用于通知传输路径端点禁用传输路径的管理需要。此功能通常与一些侵入式OAM功能（例如，性能测量或诊断测试）结合使用，以最大限度地减少对用户数据流量的副作用。
Lock Reporting is a function used by an endpoint of a path to report to its far-end endpoint that a lock condition has been affected on the path.
锁定报告是一个函数，路径的端点使用该函数向其远端端点报告路径上的锁定条件已受到影响。
Alarm reporting [TP-Fault] provides the means to suppress alarms following detection of defect conditions at the server sub-layer. Alarm reporting is used by an intermediate point of a path, that becomes aware of a fault on the path, to report to the endpoints of the path. [TP-OAM-FW] states that this may occur as a result of a defect condition discovered at a server sub-layer. This generates an Alarm Indication Signal (AIS) that continues until the fault is cleared. The consequent action of this function is detailed in [TP-OAM-FW].
报警报告[TP Fault]提供了在服务器子层检测到缺陷条件后抑制报警的方法。报警报告由路径的中间点使用，该中间点意识到路径上的故障，并向路径的端点报告。[TP-OAM-FW]指出，这可能是由于在服务器子层发现的缺陷状况而导致的。这将生成一个报警指示信号（AIS），该信号将持续到故障清除为止。[TP-OAM-FW]中详细说明了此功能的后续操作。
Remote Defect Indication (RDI) is used proactively by a path endpoint to report to its peer endpoint that a defect is detected on a bidirectional connection between them. [MPLS-TP-OAM] points out that this function may be applied to a unidirectional LSP only if a return path exists. [TP-OAM-FW] points out that this function is associated with the proactive CC-V function.
远程缺陷指示（RDI）由路径端点主动使用，以向其对等端点报告在它们之间的双向连接上检测到的缺陷。[MPLS-TP-OAM]指出，仅当存在返回路径时，此功能才可应用于单向LSP。[TP-OAM-FW]指出该功能与主动CC-V功能相关。
Client Failure Indication (CFI) is defined in [MPLS-TP-OAM] to allow the propagation information from one edge of the network to the other. The information concerns a defect to a client, in the case that the client does not support alarm notification.
[MPLS-TP-OAM]中定义了客户端故障指示（CFI），以允许将信息从网络的一个边缘传播到另一个边缘。如果客户端不支持报警通知，则该信息与客户端的缺陷有关。
The definition of MPLS performance monitoring was motivated by the MPLS-TP requirements [MPLS-TP-OAM] but was defined generically for MPLS in [MPLS-LM-DM]. An additional document [TP-LM-DM] defines a performance monitoring profile for MPLS-TP.
MPLS性能监控的定义受MPLS-TP要求[MPLS-TP-OAM]的推动，但在[MPLS-LM-DM]中对MPLS进行了一般性定义。另一个文档[TP-LM-DM]定义了MPLS-TP的性能监控配置文件。
Packet Loss Measurement is a function used to verify the quality of the service. Packet loss, as defined in [IPPM-1LM] and [MPLS-TP-OAM], indicates the ratio of the number of user packets lost to the total number of user packets sent during a defined time interval.
包丢失测量是用于验证服务质量的功能。[IPPM-1LM]和[MPLS-TP-OAM]中定义的数据包丢失表示在定义的时间间隔内丢失的用户数据包数量与发送的用户数据包总数的比率。
There are two possible ways of determining this measurement:
有两种可能的方法确定该测量值：
o Using OAM packets, it is possible to compute the statistics based on a series of OAM packets. This, however, has the disadvantage of being artificial and may not be representative since part of the packet loss may be dependent upon packet sizes and upon the implementation of the MEPs that take part in the protocol.
o 使用OAM包，可以基于一系列OAM包计算统计信息。然而，这具有人为的缺点并且可能不具有代表性，因为分组丢失的一部分可能取决于分组大小和参与协议的mep的实现。
o Delimiting messages can be sent at the start and end of a measurement period during which the source and sink of the path count the packets transmitted and received. After the end delimiter, the ratio would be calculated by the path OAM entity.
o 可以在测量周期的开始和结束时发送定界消息，在此期间，路径的源和汇对发送和接收的数据包进行计数。在结束分隔符之后，比率将由路径OAM实体计算。
Packet Delay Measurement is a function that is used to measure one-way or two-way delay of a packet transmission between a pair of the endpoints of a path (PW, LSP, or Section). Where:
包延迟测量是用于测量路径（PW、LSP或段）的一对端点之间的包传输的单向或双向延迟的功能。哪里：
o One-way packet delay, as defined in [IPPM-1DM], 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. Note that one-way delay measurement requires the clocks of the two endpoints to be synchronized.
o [IPPM-1DM]中定义的单向数据包延迟是从源节点开始传输数据包的第一位到目标节点接收该数据包的最后一位所经过的时间。请注意，单向延迟测量要求两个端点的时钟同步。
o Two-way packet delay, as defined in [IPPM-2DM], 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 looped-back packet by the same source node, when the loopback is performed at the packet's destination node. Note that due to possible path asymmetry, the one-way packet delay from one endpoint to another is not necessarily equal to half of the
o [IPPM-2DM]中定义的双向数据包延迟是从源节点开始传输数据包的第一位到同一源节点接收到回送数据包的最后一位所经过的时间，此时在数据包的目的节点执行回送。注意，由于可能的路径不对称，从一个端点到另一个端点的单向数据包延迟不一定等于
two-way packet delay. As opposed to one-way delay measurement, two-way delay measurement does not require the two endpoints to be synchronized.
双向数据包延迟。与单向延迟测量相反，双向延迟测量不需要同步两个端点。
For each of these two metrics, the DM function allows the MEP to measure the delay, as well as the delay variation. Delay measurement is performed by exchanging timestamped OAM packets between the participating MEPs.
对于这两个指标中的每一个，DM功能允许MEP测量延迟以及延迟变化。延迟测量通过在参与的mep之间交换带时间戳的OAM分组来执行。
4.6.1. Pseudowire OAM Using Virtual Circuit Connectivity Verification (VCCV)
4.6.1. 使用虚拟电路连接验证（VCCV）的伪线OAM
VCCV, as defined in [VCCV], provides a means for end-to-end fault detection and diagnostic tools to be used for PWs (regardless of the underlying tunneling technology). The VCCV switching function provides a Control Channel associated with each PW. [VCCV] defines three Control Channel (CC) types, i.e., three possible methods for transmitting and identifying OAM messages:
[VCCV]中定义的VCCV提供了用于PWs的端到端故障检测和诊断工具的方法（无论底层隧道技术如何）。VCCV开关功能提供与每个PW相关的控制通道。[VCCV]定义了三种控制信道（CC）类型，即传输和识别OAM消息的三种可能方法：
o Control Channel Type 1: In-band VCCV, as described in [VCCV], is also referred to as "PWE3 Control Word with 0001b as first nibble". It uses the PW Associated Channel Header [PW-ACH].
o 控制通道类型1:[VCCV]中所述的带内VCCV也称为“第一半字节为0001b的PWE3控制字”。它使用PW关联的信道头[PW-ACH]。
o Control Channel Type 2: Out-of-band VCCV, as described in [VCCV], is also referred to as "MPLS Router Alert Label". In this case, the Control Channel is created by using the MPLS router alert label [MPLS-ENCAPS] immediately above the PW label.
o 控制信道类型2：带外VCCV，如[VCCV]中所述，也称为“MPLS路由器警报标签”。在这种情况下，通过使用PW标签正上方的MPLS路由器警报标签[MPLS-ENCAPS]创建控制通道。
o Control Channel Type 3: TTL expiry VCCV, as described in [VCCV], is also referred to as "MPLS PW Label with TTL == 1", i.e., the Control Channel is identified when the value of the TTL field in the PW label is set to 1.
o 控制信道类型3:TTL到期VCCV，如[VCCV]中所述，也称为“TTL==1的MPLS PW标签”，即当PW标签中的TTL字段的值设置为1时，识别控制信道。
VCCV currently supports the following OAM tools: ICMP Ping, LSP Ping, and BFD. ICMP and LSP Ping are IP encapsulated before being sent over the PW ACH. BFD for VCCV [BFD-VCCV] supports two modes of encapsulation -- either IP/UDP encapsulated (with IP/UDP header) or PW-ACH encapsulated (with no IP/UDP header) -- and provides support to signal the AC status. The use of the VCCV Control Channel provides the context, based on the MPLS-PW label, required to bind and bootstrap the BFD session to a particular pseudowire (FEC), eliminating the need to exchange Discriminator values.
VCCV目前支持以下OAM工具：ICMP Ping、LSP Ping和BFD。ICMP和LSP Ping在通过PW ACH发送之前是IP封装的。BFD for VCCV[BFD-VCCV]支持两种封装模式——IP/UDP封装（带IP/UDP标头）或PW-ACH封装（不带IP/UDP标头）——并提供对AC状态信号的支持。VCCV控制通道的使用基于MPLS-PW标签提供了将BFD会话绑定和引导到特定伪线（FEC）所需的上下文，从而消除了交换鉴别器值的需要。
VCCV consists of two components: (1) the signaled component to communicate VCCV capabilities as part of the VC label, and (2) the switching component to cause the PW payload to be treated as a control packet.
VCCV由两个组件组成：（1）作为VC标签的一部分传递VCCV功能的信号组件，以及（2）使PW有效负载被视为控制数据包的交换组件。
VCCV is not directly dependent upon the presence of a control plane. The VCCV capability advertisement may be performed as part of the PW signaling when LDP is used. In case of manual configuration of the PW, it is the responsibility of the operator to set consistent options at both ends. The manual option was created specifically to handle MPLS-TP use cases where no control plane was a requirement. However, new use cases such as pure mobile backhaul find this functionality useful too.
VCCV不直接依赖于控制平面的存在。当使用LDP时，VCCV能力广告可以作为PW信令的一部分来执行。对于PW的手动配置，操作员有责任在两端设置一致的选项。手动选项专门用于处理不需要控制平面的MPLS-TP用例。然而，像纯移动回程这样的新用例发现这个功能也很有用。
The PWE3 working group has conducted an implementation survey of VCCV [VCCV-SURVEY] that analyzes which VCCV mechanisms are used in practice.
PWE3工作组对VCCV[VCCV-survey]进行了实施调查，分析了在实践中使用的VCCV机制。
As mentioned above, VCCV enables OAM for PWs by using a Control Channel for OAM packets. When PWs are used in MPLS-TP networks, rather than the Control Channels defined in VCCV, the G-ACh can be used as an alternative Control Channel. The usage of the G-ACh for PWs is defined in [PW-G-ACh].
如上所述，VCCV通过使用OAM数据包的控制通道来启用PWs的OAM。当在MPLS-TP网络中使用PWs而不是VCCV中定义的控制信道时，G-ACh可以用作替代控制信道。[PW-G-ACh]中定义了PWs的G-ACh用法。
The PWE3 working group has defined a mapping and notification of defect states between a pseudowire (PW) and the Attachment Circuits (ACs) of the end-to-end emulated service. This mapping is of key importance to the end-to-end functionality. Specifically, the mapping is provided by [PW-MAP], by [L2TP-EC] for L2TPv3 pseudowires, and by Section 5.3 of [ATM-L2] for ATM.
The PWE3 working group has defined a mapping and notification of defect states between a pseudowire (PW) and the Attachment Circuits (ACs) of the end-to-end emulated service. This mapping is of key importance to the end-to-end functionality. Specifically, the mapping is provided by [PW-MAP], by [L2TP-EC] for L2TPv3 pseudowires, and by Section 5.3 of [ATM-L2] for ATM.translate error, please retry
[L2VPN-OAM] provides the requirements and framework for OAM in the context of Layer 2 Virtual Private Networks (L2VPNs), and specifically it also defines the OAM layering of L2VPNs over pseudowires.
[L2VPN-OAM]在第2层虚拟专用网络（L2VPN）的上下文中提供OAM的要求和框架，特别是它还定义了L2VPN在伪线上的OAM分层。
The mapping defined in [Eth-Int] allows an end-to-end emulated Ethernet service over pseudowires.
[Eth Int]中定义的映射允许通过伪线提供端到端模拟以太网服务。
The IPPM working group in the IETF defines common criteria and metrics for measuring performance of IP traffic ([IPPM-FW]). Some of the key RFCs published by this working group have defined metrics for measuring connectivity [IPPM-Con], delay ([IPPM-1DM], [IPPM-2DM]), and packet loss [IPPM-1LM]. It should be noted that the work of the IETF in the context of performance metrics is not limited to IP networks; [PM-CONS] presents general guidelines for considering new performance metrics.
IETF中的IPPM工作组定义了测量IP流量性能的通用标准和量度（[IPPM-FW]）。该工作组发布的一些关键RFC定义了测量连接性[IPPM-Con]、延迟（[IPPM-1DM]、[IPPM-2DM]）和数据包丢失[IPPM-1LM]的指标。应注意的是，IETF在性能指标方面的工作不限于IP网络；[PM-CONS]提供了考虑新性能指标的一般指南。
The IPPM working group has defined not only metrics for performance measurement but also protocols that define how the measurement is carried out. The One-Way Active Measurement Protocol [OWAMP] and the Two-Way Active Measurement Protocol [TWAMP] each define a method and protocol for measuring performance metrics in IP networks.
IPPM工作组不仅定义了性能测量的指标，还定义了如何进行测量的协议。单向主动测量协议[OWAMP]和双向主动测量协议[TWAMP]各自定义了用于测量IP网络中性能指标的方法和协议。
OWAMP [OWAMP] enables measurement of one-way characteristics of IP networks, such as one-way packet loss and one-way delay. For its proper operation, OWAMP requires accurate time-of-day setting at its endpoints.
OWAMP[OWAMP]能够测量IP网络的单向特性，例如单向数据包丢失和单向延迟。为了正确运行，OWAMP需要在其端点设置准确的时间。
TWAMP [TWAMP] is a similar protocol that enables measurement of both one-way and two-way (round-trip) characteristics.
TWAMP[TWAMP]是一种类似的协议，可以同时测量单向和双向（往返）特性。
OWAMP and TWAMP are each comprised of two separate protocols:
OWAMP和TWAMP分别由两个单独的协议组成：
o OWAMP-Control/TWAMP-Control: used to initiate, start, and stop test sessions and to fetch their results. Continuity Check and Connectivity Verification are tested and confirmed by establishing the OWAMP/TWAMP Control Protocol TCP connection.
o OWAMP控件/TWAMP控件：用于启动、启动和停止测试会话，并获取其结果。通过建立OWAMP/TWAMP控制协议TCP连接来测试和确认连续性检查和连接验证。
o OWAMP-Test/TWAMP-Test: used to exchange test packets between two measurement nodes. Enables the loss and delay measurement functions, as well as detection of other anomalies, such as packet duplication and packet reordering.
o OWAMP测试/TWAMP测试：用于在两个测量节点之间交换测试数据包。启用丢失和延迟测量功能，以及检测其他异常，如数据包复制和数据包重新排序。
It should be noted that while [OWAMP] and [TWAMP] define tools for performance measurement, they do not define the accuracy of these tools. The accuracy depends on scale, implementation, and network configurations.
应该注意的是，虽然[OWAMP]和[TWAMP]定义了性能度量工具，但它们并没有定义这些工具的准确性。精度取决于规模、实施和网络配置。
Alternative protocols for performance monitoring are defined, for example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]) and in Ethernet OAM [ITU-T-Y1731].
例如，在MPLS-TP OAM（[MPLS-LM-DM]、[TP-LM-DM]）和以太网OAM[ITU-T-Y1731]中定义了用于性能监控的替代协议。
OWAMP and TWAMP control protocols run over TCP, while the test protocols run over UDP. The purpose of the control protocols is to initiate, start, and stop test sessions, and for OWAMP to fetch results. The test protocols introduce test packets (which contain sequence numbers and timestamps) along the IP path under test according to a schedule, and they record statistics of packet arrival. Multiple sessions may be simultaneously defined, each with a session identifier, and defining the number of packets to be sent, the amount of padding to be added (and thus the packet size), the start time, and the send schedule (which can be either a constant time between test packets or exponentially distributed pseudorandomly). Statistics recorded conform to the relevant IPPM RFCs.
OWAMP和TWAMP控制协议通过TCP运行，而测试协议通过UDP运行。控制协议的目的是启动、启动和停止测试会话，并让OWAMP获取结果。测试协议根据时间表沿被测IP路径引入测试数据包（包含序列号和时间戳），并记录数据包到达的统计信息。可以同时定义多个会话，每个会话具有会话标识符，并且定义要发送的分组的数量、要添加的填充量（以及因此的分组大小）、开始时间和发送调度（可以是测试分组之间的恒定时间，也可以是指数分布的伪随机）。记录的统计数据符合相关IPPM RFC。
From a security perspective, OWAMP and TWAMP test packets are hard to detect because they are simply UDP streams between negotiated port numbers, with potentially nothing static in the packets. OWAMP and TWAMP also include optional authentication and encryption for both control and test packets.
从安全角度来看，OWAMP和TWAMP测试数据包很难检测，因为它们只是协商端口号之间的UDP流，数据包中可能没有任何静态内容。OWAMP和TWAMP还包括用于控制和测试数据包的可选身份验证和加密。
OWAMP defines the following logical roles: Session-Sender, Session-Receiver, Server, Control-Client, and Fetch-Client. The Session-Sender originates test traffic that is received by the Session-Receiver. The Server configures and manages the session, as well as returning the results. The Control-Client initiates requests for test sessions, triggers their start, and may trigger their termination. The Fetch-Client requests the results of a completed session. Multiple roles may be combined in a single host -- for example, one host may play the roles of Control-Client, Fetch-Client, and Session-Sender, and a second may play the roles of Server and Session-Receiver.
OWAMP定义以下逻辑角色：会话发送方、会话接收方、服务器、控制客户端和获取客户端。会话发送方发起由会话接收方接收的测试通信量。服务器配置和管理会话，并返回结果。控制客户端启动测试会话请求，触发其启动，并可能触发其终止。获取客户端请求已完成会话的结果。多个角色可以组合在一台主机中——例如，一台主机可以扮演控制客户端、获取客户端和会话发送方的角色，另一台主机可以扮演服务器和会话接收方的角色。
In a typical OWAMP session, the Control-Client establishes a TCP connection to port 861 of the Server, which responds with a Server greeting message indicating supported security/integrity modes. The Control-Client responds with the chosen communications mode, and the Server accepts the mode. The Control-Client then requests and fully describes a test session to which the Server responds with its acceptance and supporting information. More than one test session may be requested with additional messages. The Control-Client then starts a test session; the Server acknowledges and then instructs the Session-Sender to start the test. The Session-Sender then sends test packets with pseudorandom padding to the Session-Receiver until the session is complete or until the Control-Client stops the session.
在典型的OWAMP会话中，控制客户端与服务器的端口861建立TCP连接，该端口以服务器问候消息响应，该消息指示支持的安全/完整性模式。控制客户端使用所选的通信模式进行响应，服务器接受该模式。然后，控制客户端请求并完整描述一个测试会话，服务器用其接受和支持信息响应该会话。可以使用附加消息请求多个测试会话。然后，控制客户端启动测试会话；服务器确认，然后指示会话发送方启动测试。然后，会话发送方向会话接收方发送带有伪随机填充的测试数据包，直到会话完成或控制客户端停止会话为止。
Once finished, the Session-Sender reports to the Server, which recovers data from the Session-Receiver. The Fetch-Client can then send a fetch request to the Server, which responds with an acknowledgement and, immediately thereafter, the result data.
完成后，会话发送方向服务器报告，服务器从会话接收方恢复数据。然后，Fetch客户机可以向服务器发送一个Fetch请求，服务器以确认和随后的结果数据作为响应。
TWAMP defines the following logical roles: Session-Sender, Session-Reflector, Server, and Control-Client. These are similar to the OWAMP roles, except that the Session-Reflector does not collect any packet information, and there is no need for a Fetch-Client.
TWAMP定义了以下逻辑角色：会话发送方、会话反射方、服务器和控制客户端。这些与OWAMP角色类似，只是会话反射器不收集任何数据包信息，并且不需要获取客户端。
In a typical TWAMP session, the Control-Client establishes a TCP connection to port 862 of the Server, and the mode is negotiated as in OWAMP. The Control-Client then requests sessions and starts them. The Session-Sender sends test packets with pseudorandom padding to the Session-Reflector, which returns them with timestamps inserted.
在典型的TWAMP会话中，控制客户端与服务器的端口862建立TCP连接，并按照OWAMP中的方式协商模式。然后，控制客户端请求会话并启动它们。会话发送方向会话反射器发送带有伪随机填充的测试数据包，会话反射器返回这些数据包并插入时间戳。
The requirements of OAM in TRILL are defined in [TRILL-OAM]. The challenge in TRILL OAM, much like in MPLS networks, is that traffic between RBridges RB1 and RB2 may be forwarded through more than one path. Thus, an OAM protocol between RBridges RB1 and RB2 must be able to monitor all the available paths between the two RBridges.
TRILL中的OAM要求在[TRILL-OAM]中定义。TRILL OAM中的挑战与MPLS网络中的挑战非常相似，RB1和RB2之间的流量可能通过多条路径转发。因此，rbridge RB1和RB2之间的OAM协议必须能够监视两个rbridge之间的所有可用路径。
During the writing of this document, the detailed definition of the TRILL OAM tools is still work in progress. This subsection presents the main requirements of TRILL OAM.
在编写本文档期间，TRILL OAM工具的详细定义仍在进行中。本小节介绍TRILL OAM的主要要求。
The main requirements defined in [TRILL-OAM] are:
[TRILL-OAM]中定义的主要要求是：
o Continuity Checking (CC) - the TRILL OAM protocol must support a function for CC between any two RBridges RB1 and RB2.
o 连续性检查（CC）-TRILL OAM协议必须支持任意两个RB1和RB2之间的CC功能。
o Connectivity Verification (CV) - connectivity between two RBridges RB1 and RB2 can be verified on a per-flow basis.
o 连接性验证（CV）-两个RB1和RB2之间的连接性可以基于每个流进行验证。
o Path Tracing - allows an RBridge to trace all the available paths to a peer RBridge.
o 路径跟踪-允许RBridge跟踪到对等RBridge的所有可用路径。
o Performance monitoring - allows an RBridge to monitor the packet loss and packet delay to a peer RBridge.
o 性能监视-允许RBridge监视对等RBridge的数据包丢失和数据包延迟。
This section summarizes the OAM tools and functions presented in this document. This summary is an index to some of the main OAM tools defined in the IETF. This compact index can be useful to all readers from network operators to standards development organizations. The summary includes a short subsection that presents some guidance to network equipment vendors.
本节总结了本文档中介绍的OAM工具和功能。本摘要是IETF中定义的一些主要OAM工具的索引。这个紧凑的索引对从网络运营商到标准开发组织的所有读者都很有用。摘要包括一小段，为网络设备供应商提供了一些指导。
This subsection provides a short summary of each of the OAM toolsets described in this document.
本小节简要概述了本文档中描述的每个OAM工具集。
A detailed list of the RFCs related to each toolset is given in Appendix A.1.
附录A.1中给出了与每个工具集相关的RFC的详细列表。
+-----------+------------------------------------------+------------+
| Toolset | Description | Transport |
| | | Technology |
+-----------+------------------------------------------+------------+
|IP Ping | Ping ([IntHost], [NetTerms]) is a simple | IPv4/IPv6 |
| | application for testing reachability that| |
| | uses ICMP Echo messages ([ICMPv4], | |
| | [ICMPv6]). | |
+-----------+------------------------------------------+------------+
|IP | Traceroute ([TCPIP-Tools], [NetTools]) is| IPv4/IPv6 |
|Traceroute | an application that allows users to trace| |
| | the path between an IP source and an IP | |
| | destination, i.e., to identify the nodes | |
| | along the path. If more than one path | |
| | exists between the source and | |
| | destination, Traceroute traces *a* path. | |
| | The most common implementation of | |
| | Traceroute uses UDP probe messages, | |
| | although there are other implementations | |
| | that use different probes, such as ICMP | |
| | or TCP. Paris Traceroute [PARIS] is an | |
| | extension that attempts to discover all | |
| | the available paths from A to B by | |
| | scanning different values of header | |
| | fields. | |
+-----------+------------------------------------------+------------+
|BFD | Bidirectional Forwarding Detection (BFD) | generic |
| | is defined in [BFD] as a framework for a | |
| | lightweight generic OAM tool. The | |
| | intention is to define a base tool | |
| | that can be used with various | |
| | encapsulation types, network | |
| | environments, and various medium | |
| | types. | |
+-----------+------------------------------------------+------------+
|MPLS OAM | MPLS LSP Ping, as defined in [MPLS-OAM], | MPLS |
| | [MPLS-OAM-FW], and [LSP-Ping], is an OAM | |
| | tool for point-to-point and | |
| | point-to-multipoint MPLS LSPs. | |
| | It includes two main functions: Ping and | |
| | Traceroute. | |
| | BFD [BFD-LSP] is an alternative means for| |
| | detecting MPLS LSP data-plane failures. | |
+-----------+------------------------------------------+------------+
| Toolset | Description | Transport |
| | | Technology |
+-----------+------------------------------------------+------------+
|IP Ping | Ping ([IntHost], [NetTerms]) is a simple | IPv4/IPv6 |
| | application for testing reachability that| |
| | uses ICMP Echo messages ([ICMPv4], | |
| | [ICMPv6]). | |
+-----------+------------------------------------------+------------+
|IP | Traceroute ([TCPIP-Tools], [NetTools]) is| IPv4/IPv6 |
|Traceroute | an application that allows users to trace| |
| | the path between an IP source and an IP | |
| | destination, i.e., to identify the nodes | |
| | along the path. If more than one path | |
| | exists between the source and | |
| | destination, Traceroute traces *a* path. | |
| | The most common implementation of | |
| | Traceroute uses UDP probe messages, | |
| | although there are other implementations | |
| | that use different probes, such as ICMP | |
| | or TCP. Paris Traceroute [PARIS] is an | |
| | extension that attempts to discover all | |
| | the available paths from A to B by | |
| | scanning different values of header | |
| | fields. | |
+-----------+------------------------------------------+------------+
|BFD | Bidirectional Forwarding Detection (BFD) | generic |
| | is defined in [BFD] as a framework for a | |
| | lightweight generic OAM tool. The | |
| | intention is to define a base tool | |
| | that can be used with various | |
| | encapsulation types, network | |
| | environments, and various medium | |
| | types. | |
+-----------+------------------------------------------+------------+
|MPLS OAM | MPLS LSP Ping, as defined in [MPLS-OAM], | MPLS |
| | [MPLS-OAM-FW], and [LSP-Ping], is an OAM | |
| | tool for point-to-point and | |
| | point-to-multipoint MPLS LSPs. | |
| | It includes two main functions: Ping and | |
| | Traceroute. | |
| | BFD [BFD-LSP] is an alternative means for| |
| | detecting MPLS LSP data-plane failures. | |
+-----------+------------------------------------------+------------+
|MPLS-TP OAM| MPLS-TP OAM is defined in a set of RFCs. | MPLS-TP |
| | The OAM requirements for MPLS Transport | |
| | Profile (MPLS-TP) are defined in | |
| | [MPLS-TP-OAM]. Each of the tools in the | |
| | OAM toolset is defined in its own RFC, as| |
| | specified in Appendix A.1. | |
+-----------+------------------------------------------+------------+
|Pseudowire | The PWE3 OAM architecture defines Control| Pseudowire |
|OAM | Channels that support the use of existing| |
| | IETF OAM tools to be used for a pseudo- | |
| | wire (PW). The Control Channels that are| |
| | defined in [VCCV] and [PW-G-ACh] may be | |
| | used in conjunction with ICMP Ping, LSP | |
| | Ping, and BFD to perform CC and CV | |
| | functionality. In addition, the channels| |
| | support use of any of the MPLS-TP-based | |
| | OAM tools for completing their respective| |
| | OAM functionality for a PW. | |
+-----------+------------------------------------------+------------+
|OWAMP and | The One-Way Active Measurement Protocol | IPv4/IPv6 |
|TWAMP | [OWAMP] and the Two-Way Active Measure- | |
| | ment Protocol [TWAMP] are two protocols | |
| | defined in the IP Performance Metrics | |
| | (IPPM) working group in the IETF. These | |
| | protocols allow various performance | |
| | metrics to be measured, such as packet | |
| | loss, delay, delay variation, | |
| | duplication, and reordering. | |
+-----------+------------------------------------------+------------+
|TRILL OAM | The requirements of OAM in TRILL are | TRILL |
| | defined in [TRILL-OAM]. These | |
| | requirements include Continuity Checking,| |
| | Connectivity Verification, path tracing, | |
| | and performance monitoring. During the | |
| | writing of this document, the detailed | |
| | definition of the TRILL OAM tools | |
| | is work in progress. | |
+-----------+------------------------------------------+------------+
+-----------+------------------------------------------+------------+
|MPLS-TP OAM| MPLS-TP OAM is defined in a set of RFCs. | MPLS-TP |
| | The OAM requirements for MPLS Transport | |
| | Profile (MPLS-TP) are defined in | |
| | [MPLS-TP-OAM]. Each of the tools in the | |
| | OAM toolset is defined in its own RFC, as| |
| | specified in Appendix A.1. | |
+-----------+------------------------------------------+------------+
|Pseudowire | The PWE3 OAM architecture defines Control| Pseudowire |
|OAM | Channels that support the use of existing| |
| | IETF OAM tools to be used for a pseudo- | |
| | wire (PW). The Control Channels that are| |
| | defined in [VCCV] and [PW-G-ACh] may be | |
| | used in conjunction with ICMP Ping, LSP | |
| | Ping, and BFD to perform CC and CV | |
| | functionality. In addition, the channels| |
| | support use of any of the MPLS-TP-based | |
| | OAM tools for completing their respective| |
| | OAM functionality for a PW. | |
+-----------+------------------------------------------+------------+
|OWAMP and | The One-Way Active Measurement Protocol | IPv4/IPv6 |
|TWAMP | [OWAMP] and the Two-Way Active Measure- | |
| | ment Protocol [TWAMP] are two protocols | |
| | defined in the IP Performance Metrics | |
| | (IPPM) working group in the IETF. These | |
| | protocols allow various performance | |
| | metrics to be measured, such as packet | |
| | loss, delay, delay variation, | |
| | duplication, and reordering. | |
+-----------+------------------------------------------+------------+
|TRILL OAM | The requirements of OAM in TRILL are | TRILL |
| | defined in [TRILL-OAM]. These | |
| | requirements include Continuity Checking,| |
| | Connectivity Verification, path tracing, | |
| | and performance monitoring. During the | |
| | writing of this document, the detailed | |
| | definition of the TRILL OAM tools | |
| | is work in progress. | |
+-----------+------------------------------------------+------------+
Table 3: Summary of OAM-Related IETF Tools
表3：与OAM相关的IETF工具汇总
Table 4 summarizes the OAM functions that are supported in each of the toolsets that were analyzed in this section. The columns of this table are the typical OAM functions described in Section 1.3.
表4总结了本节分析的每个工具集中支持的OAM功能。本表各列为第1.3节中描述的典型OAM功能。
+-----------+----------+-------------+----------+----------+-----------+
| |Continuity|Connectivity |Path |Perf. |Other |
| Toolset |Check |Verification |Discovery |Monitoring|Functions |
| | | | | | |
+-----------+----------+-------------+----------+----------+-----------+
|IP Ping |Echo | | | | |
+-----------+----------+-------------+----------+----------+-----------+
|IP | | |Traceroute| | |
|Traceroute | | | | | |
+-----------+----------+-------------+----------+----------+-----------+
|BFD |BFD |BFD Control | | |RDI using |
| |Control/ | | | |BFD Control|
| |Echo | | | | |
+-----------+----------+-------------+----------+----------+-----------+
|MPLS OAM | |"Ping" mode |"Trace- | | |
|(LSP Ping) | | |route" | | |
| | | |mode | | |
+-----------+----------+-------------+----------+----------+-----------+
|MPLS-TP |CC |CV/proactive |Route |-LM |-Diagnostic|
|OAM | |or on demand |Tracing |-DM | Test |
| | | | | |-Lock |
| | | | | |-Alarm |
| | | | | | Reporting |
| | | | | |-Client |
| | | | | | Failure |
| | | | | | Indication|
| | | | | |-RDI |
+-----------+----------+-------------+----------+----------+-----------+
|Pseudowire |BFD |-BFD |LSP Ping | | |
|OAM | |-ICMP Ping | | | |
| | |-LSP Ping | | | |
+-----------+----------+-------------+----------+----------+-----------+
|OWAMP and | - control | |-DM | |
|TWAMP | protocol | |-LM | |
+-----------+----------+-------------+----------+----------+-----------+
|TRILL OAM |CC |CV |Path |-DM | |
| | | |tracing |-LM | |
+-----------+----------+-------------+----------+----------+-----------+
+-----------+----------+-------------+----------+----------+-----------+
| |Continuity|Connectivity |Path |Perf. |Other |
| Toolset |Check |Verification |Discovery |Monitoring|Functions |
| | | | | | |
+-----------+----------+-------------+----------+----------+-----------+
|IP Ping |Echo | | | | |
+-----------+----------+-------------+----------+----------+-----------+
|IP | | |Traceroute| | |
|Traceroute | | | | | |
+-----------+----------+-------------+----------+----------+-----------+
|BFD |BFD |BFD Control | | |RDI using |
| |Control/ | | | |BFD Control|
| |Echo | | | | |
+-----------+----------+-------------+----------+----------+-----------+
|MPLS OAM | |"Ping" mode |"Trace- | | |
|(LSP Ping) | | |route" | | |
| | | |mode | | |
+-----------+----------+-------------+----------+----------+-----------+
|MPLS-TP |CC |CV/proactive |Route |-LM |-Diagnostic|
|OAM | |or on demand |Tracing |-DM | Test |
| | | | | |-Lock |
| | | | | |-Alarm |
| | | | | | Reporting |
| | | | | |-Client |
| | | | | | Failure |
| | | | | | Indication|
| | | | | |-RDI |
+-----------+----------+-------------+----------+----------+-----------+
|Pseudowire |BFD |-BFD |LSP Ping | | |
|OAM | |-ICMP Ping | | | |
| | |-LSP Ping | | | |
+-----------+----------+-------------+----------+----------+-----------+
|OWAMP and | - control | |-DM | |
|TWAMP | protocol | |-LM | |
+-----------+----------+-------------+----------+----------+-----------+
|TRILL OAM |CC |CV |Path |-DM | |
| | | |tracing |-LM | |
+-----------+----------+-------------+----------+----------+-----------+
Table 4: Summary of the OAM Functionality in IETF OAM Tools
表4:IETF OAM工具中的OAM功能摘要
As mentioned in Section 1.4, it is imperative for OAM tools to be capable of testing the actual data plane with as much accuracy as possible. While this guideline may appear obvious, it is worthwhile to emphasize the key importance of enforcing fate-sharing between OAM traffic that monitors the data plane and the data-plane traffic it monitors.
如第1.4节所述，OAM工具必须能够以尽可能高的精度测试实际数据平面。虽然这条指导原则看起来很明显，但值得强调的是，在监视数据平面的OAM通信量与其监视的数据平面通信量之间实施命运共享的关键重要性。
OAM is tightly coupled with the stability of the network. A successful attack on an OAM protocol can create a false illusion of nonexistent failures or prevent the detection of actual ones. In both cases, the attack may result in denial of service.
OAM与网络的稳定性紧密耦合。对OAM协议的成功攻击可能会造成不存在故障的假象，或阻止对实际故障的检测。在这两种情况下，攻击都可能导致拒绝服务。
Some of the OAM tools presented in this document include security mechanisms that provide integrity protection, thereby preventing attackers from forging or tampering with OAM packets. For example, [BFD] includes an optional authentication mechanism for BFD Control packets, using either SHA1, MD5, or a simple password. [OWAMP] and [TWAMP] have three modes of security: unauthenticated, authenticated, and encrypted. The authentication uses SHA1 as the HMAC algorithm, and the encrypted mode uses AES encryption.
本文档中介绍的一些OAM工具包括提供完整性保护的安全机制，从而防止攻击者伪造或篡改OAM数据包。例如，[BFD]包括BFD控制数据包的可选身份验证机制，使用SHA1、MD5或简单密码。[OWAMP]和[TWAMP]有三种安全模式：未经身份验证、验证和加密。身份验证使用SHA1作为HMAC算法，加密模式使用AES加密。
Confidentiality is typically not considered a requirement for OAM protocols. However, the use of encryption (e.g., [OWAMP] and [TWAMP]) can make it difficult for attackers to identify OAM packets, thus making it more difficult to attack the OAM protocol.
OAM协议通常不要求保密。然而，使用加密（例如[OWAMP]和[TWAMP]）会使攻击者难以识别OAM数据包，从而使攻击OAM协议更加困难。
OAM can also be used as a means for network reconnaissance; information about addresses, port numbers, and the network topology and performance can be gathered by either passively eavesdropping on OAM packets or actively sending OAM packets and gathering information from the respective responses. This information can then be used maliciously to attack the network. Note that some of this information, e.g., addresses and port numbers, can be gathered even when encryption is used ([OWAMP], [TWAMP]).
OAM也可用作网络侦察的手段；有关地址、端口号以及网络拓扑和性能的信息可以通过被动窃听OAM数据包或主动发送OAM数据包并从相应的响应中收集信息来收集。然后，这些信息可以被恶意地用来攻击网络。请注意，即使使用加密（[OWAMP]、[TWAMP]），也可以收集其中一些信息，例如地址和端口号。
For further details about the security considerations of each OAM protocol, the reader is encouraged to review the Security Considerations section of each document referenced by this memo.
有关每个OAM协议的安全注意事项的更多详细信息，鼓励读者查看本备忘录引用的每个文档的安全注意事项部分。
The authors gratefully acknowledge Sasha Vainshtein, Carlos Pignataro, David Harrington, Dan Romascanu, Ron Bonica, Benoit Claise, Stewart Bryant, Tom Nadeau, Elwyn Davies, Al Morton, Sam Aldrin, Thomas Narten, and other members of the OPSA WG for their helpful comments on the mailing list.
作者感谢萨沙·范斯坦、卡洛斯·皮格纳塔罗、大卫·哈林顿、丹·罗马斯坎努、罗恩·博尼卡、贝诺特·克莱斯、斯图尔特·布莱恩特、汤姆·纳多、埃尔温·戴维斯、艾尔·莫顿、萨姆·奥尔德林、托马斯·纳滕以及OPSA工作组其他成员在邮件列表上的有益评论。
This document was originally prepared using 2-Word-v2.0.template.dot.
本文件最初使用2-Word-v2.0.template.dot编制。
[OAM-Def] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, June 2011.
[OAM Def]Andersson，L.，van Helvoort，H.，Bonica，R.，Romascanu，D.，和S.Mansfield，“IETF中使用“OAM”首字母缩写的指南”，BCP 161，RFC 62912011年6月。
[ATM-L2] Singh, S., Townsley, M., and C. Pignataro, "Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3)", RFC 4454, May 2006.
[ATM-L2]Singh，S.，Townsley，M.，和C.Pignataro，“第2层隧道协议第3版（L2TPv3）上的异步传输模式（ATM）”，RFC 4454，2006年5月。
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[BFD]Katz，D.和D.Ward，“双向转发检测（BFD）”，RFC 58802010年6月。
[BFD-Gen] Katz, D. and D. Ward, "Generic Application of Bidirectional Forwarding Detection (BFD)", RFC 5882, June 2010.
[BFD Gen]Katz，D.和D.Ward，“双向转发检测（BFD）的一般应用”，RFC 58822010年6月。
[BFD-IP] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010.
[BFD-IP]Katz，D.和D.Ward，“IPv4和IPv6（单跳）的双向转发检测（BFD）”，RFC 58812010年6月。
[BFD-LSP] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010.
[BFD-LSP]Aggarwal，R.，Kompella，K.，Nadeau，T.，和G.Swallow，“MPLS标签交换路径（LSP）的双向转发检测（BFD）”，RFC 58842010年6月。
[BFD-Multi] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, June 2010.
[BFD Multi]Katz，D.和D.Ward，“多跳路径的双向转发检测（BFD）”，RFC 5883，2010年6月。
[BFD-VCCV] Nadeau, T., Ed., and C. Pignataro, Ed., "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, June 2010.
[BFD-VCCV]Nadeau，T.，Ed.，和C.Pignataro，Ed.，“用于伪线虚拟电路连接验证（VCCV）的双向转发检测（BFD）”，RFC 58852010年6月。
[Comp] Bonaventure, O., "Computer Networking: Principles, Protocols and Practice", 2008.
[Comp]Bonaventure，O.，“计算机网络：原理、协议和实践”，2008年。
[Dup] Uijterwaal, H., "A One-Way Packet Duplication Metric", RFC 5560, May 2009.
[Dup]Uijterwaal，H.，“单向数据包复制度量”，RFC5560，2009年5月。
[Eth-Int] Mohan, D., Ed., Bitar, N., Ed., Sajassi, A., Ed., DeLord, S., Niger, P., and R. Qiu, "MPLS and Ethernet Operations, Administration, and Maintenance (OAM) Interworking", RFC 7023, October 2013.
[Eth Int]Mohan，D.，Ed.，Bitar，N.，Ed.，Sajassi，A.，Ed.，DeLord，S.，Niger，P.，和R.Qiu，“MPLS和以太网操作、管理和维护（OAM）互通”，RFC 70232013年10月。
[G-ACh] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
[G-ACh]Bocci，M.，Ed.，Vigoureux，M.，Ed.，和S.Bryant，Ed.，“MPLS通用关联信道”，RFC 55862009年6月。
[ICMP-Ext] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP Extensions for Multiprotocol Label Switching", RFC 4950, August 2007.
[ICMP Ext]Bonica，R.，Gan，D.，Tappan，D.，和C.Pignataro，“多协议标签交换的ICMP扩展”，RFC 49502007年8月。
[ICMP-Int] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen, N., and JR. Rivers, "Extending ICMP for Interface and Next-Hop Identification", RFC 5837, April 2010.
[ICMP Int]Atlas，A.，Ed.，Bonica，R.，Ed.，Pignataro，C.，Ed.，Shen，N.，和JR.Rivers，“为接口和下一跳识别扩展ICMP”，RFC 5837，2010年4月。
[ICMP-MP] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, April 2007.
[ICMP-MP]Bonica，R.，Gan，D.，Tappan，D.，和C.Pignataro，“扩展ICMP以支持多部分消息”，RFC 4884，2007年4月。
[ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[ICMPv4]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[ICMPv6] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[ICMPv6]Conta，A.，Deering，S.，和M.Gupta，Ed.，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年3月。
[IEEE802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE 802.1Q, October 2012.
[IEEE802.1Q]IEEE，“局域网和城域网的IEEE标准-媒体访问控制（MAC）网桥和虚拟桥接局域网”，IEEE 802.1Q，2012年10月。
[IEEE802.3ah] IEEE, "IEEE Standard for Information technology - Local and metropolitan area networks - Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", IEEE 802.3ah, clause 57, December 2008.
[IEEE802.3ah]IEEE，“IEEE信息技术标准-局域网和城域网-带冲突检测的载波侦听多址接入（CSMA/CD）接入方法和物理层规范”，IEEE 802.3ah，第57条，2008年12月。
[IntHost] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[IntHost]Braden，R.，Ed.“互联网主机的要求-通信层”，STD 3，RFC 1122，1989年10月。
[IPPM-1DM] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[IPPM-1DM]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的单向延迟度量”，RFC 2679，1999年9月。
[IPPM-1LM] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
[IPPM-1LM]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的单向数据包丢失度量”，RFC 26801999年9月。
[IPPM-2DM] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999.
[IPPM-2DM]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的往返延迟度量”，RFC 2681，1999年9月。
[IPPM-Con] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring Connectivity", RFC 2678, September 1999.
[IPPM Con]Mahdavi，J.和V.Paxson，“测量连接性的IPPM度量”，RFC 2678，1999年9月。
[IPPM-FW] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[IPPM-FW]Paxson，V.，Almes，G.，Mahdavi，J.，和M.Mathis，“IP性能度量框架”，RFC 2330，1998年5月。
[ITU-G8113.1] ITU-T, "Operations, Administration and Maintenance mechanism for MPLS-TP in Packet Transport Network (PTN)", ITU-T Recommendation G.8113.1/Y.1372.1, November 2012.
[ITU-G8113.1]ITU-T，“分组传输网络（PTN）中MPLS-TP的操作、管理和维护机制”，ITU-T建议G.8113.1/Y.1372.11912年11月。
[ITU-G8113.2] ITU-T, "Operations, administration and maintenance mechanisms for MPLS-TP networks using the tools defined for MPLS", ITU-T Recommendation G.8113.2/Y.1372.2, November 2012.
[ITU-G8113.2]ITU-T，“使用为MPLS定义的工具的MPLS-TP网络的操作、管理和维护机制”，ITU-T建议G.8113.2/Y.1372.22012年11月。
[ITU-T-CT] Betts, M., "Allocation of a Generic Associated Channel Type for ITU-T MPLS Transport Profile Operation, Maintenance, and Administration (MPLS-TP OAM)", RFC 6671, November 2012.
[ITU-T-CT]Betts，M.，“ITU-T MPLS传输配置文件操作、维护和管理（MPLS-TP OAM）的通用相关信道类型分配”，RFC 66712012年11月。
[ITU-T-G.806] ITU-T, "Characteristics of transport equipment - Description methodology and generic functionality", ITU-T Recommendation G.806, January 2009.
[ITU-T-G.806]ITU-T，“运输设备的特性——描述方法和通用功能”，ITU-T建议G.806，2009年1月。
[ITU-T-Y1711] ITU-T, "Operation & Maintenance mechanism for MPLS networks", ITU-T Recommendation Y.1711, February 2004.
[ITU-T-Y1711]ITU-T，“MPLS网络的运行和维护机制”，ITU-T建议Y.1711，2004年2月。
[ITU-T-Y1731] ITU-T, "OAM Functions and Mechanisms for Ethernet-based Networks", ITU-T Recommendation G.8013/Y.1731, July 2011.
[ITU-T-Y1731]ITU-T，“基于以太网的网络的OAM功能和机制”，ITU-T建议G.8013/Y.17311911年7月。
[ITU-Terms] ITU-R/ITU-T, "ITU-R/ITU-T Terms and Definitions", 2013, <http://www.itu.int/pub/R-TER-DB>.
[ITU术语]ITU-R/ITU-T，“ITU-R/ITU-T术语和定义”，2013年<http://www.itu.int/pub/R-TER-DB>.
[L2TP-EC] McGill, N. and C. Pignataro, "Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values", RFC 5641, August 2009.
[L2TP-EC]McGill，N.和C.Pignataro，“第2层隧道协议版本3（L2TPv3）扩展电路状态值”，RFC 56412009年8月。
[L2VPN-OAM] Sajassi, A., Ed., and D. Mohan, Ed., "Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework", RFC 6136, March 2011.
[L2VPN-OAM]Sajassi，A.，Ed.，和D.Mohan，Ed.“第二层虚拟专用网络（L2VPN）运营、管理和维护（OAM）要求和框架”，RFC 61362011年3月。
[L3VPN-OAM] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., and A. Gonguet, "Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management", RFC 4176, October 2005.
[L3VPN-OAM]El Mghazli，Y.，Ed.，Nadeau，T.，Boucadair，M.，Chan，K.，和A.Gonguet，“第三层虚拟专用网络（L3VPN）运营和管理框架”，RFC 41762005年10月。
[Lock-Loop] 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.
[Lock Loop]Boutros，S.，Ed.，Sivabalan，S.，Ed.，Aggarwal，R.，Ed.，Vigoureux，M.，Ed.，和X.Dai，Ed.，“MPLS传输配置文件锁定指令和环回功能”，RFC 64352011年11月。
[LSP-Ping] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[LSP Ping]Kompella，K.和G.Swallow，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，2006年2月。
[Mng] Farrel, A., "Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts", RFC 6123, February 2011.
[Mng]Farrel，A.“在路径计算元素（PCE）工作组草案中纳入可管理性部分”，RFC 61232011年2月。
[MPLS-ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[MPLS-ENCAPS]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[MPLS-LM-DM] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, September 2011.
[MPLS-LM-DM]Frost，D.和S.Bryant，“MPLS网络的数据包丢失和延迟测量”，RFC 63742011年9月。
[MPLS-OAM] 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.
[MPLS-OAM]Nadeau，T.，Morrow，M.，Swallow，G.，Allan，D.，和S.Matsushima，“多协议标签交换（MPLS）网络的运营和管理（OAM）要求”，RFC 4377，2006年2月。
[MPLS-OAM-FW] Allan, D., Ed., and T. Nadeau, Ed., "A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM)", RFC 4378, February 2006.
[MPLS-OAM-FW]Allan，D.，Ed.，和T.Nadeau，Ed.，“多协议标签交换（MPLS）操作和管理（OAM）框架”，RFC 4378，2006年2月。
[MPLS-P2MP] Yasukawa, S., Farrel, A., King, D., and T. Nadeau, "Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks", RFC 4687, September 2006.
[MPLS-P2MP]Yasukawa，S.，Farrel，A.，King，D.，和T.Nadeau，“点对多点MPLS网络的运营和管理（OAM）要求”，RFC 4687，2006年9月。
[MPLS-TP-OAM] 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.
[MPLS-TP-OAM]Vigoureux，M.，Ed.，Ward，D.，Ed.，和M.Betts，Ed.，“MPLS传输网络中的操作、管理和维护（OAM）要求”，RFC 58602010年5月。
[mtrace] Fenner, W. and S. Casner, "A "traceroute" facility for IP Multicast", Work in Progress, July 2000.
[mtrace]Fenner，W.和S.Casner，“用于IP多播的“追踪路由”设施”，正在进行的工作，2000年7月。
[NetTerms] Jacobsen, O. and D. Lynch, "A Glossary of Networking Terms", RFC 1208, March 1991.
[NetTerms]Jacobsen，O.和D.Lynch，“网络术语表”，RFC 12081991年3月。
[NetTools] Enger, R. and J. Reynolds, "FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices", FYI 2, RFC 1470, June 1993.
[NetTools]Enger，R.和J.Reynolds，“网络管理工具目录的FYI：监控和调试TCP/IP互联网和互连设备的工具”，FYI 2，RFC 1470，1993年6月。
[OAM-Analys] Sprecher, N. and L. Fang, "An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks", RFC 6669, July 2012.
[OAM分析]Sprecher，N.和L.Fang，“基于MPLS的传输网络的运营、管理和维护（OAM）工具集概述”，RFC 6669，2012年7月。
[OAM-Label] Ohta, H., "Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions", RFC 3429, November 2002.
[OAM标签]Ohta，H.，“多协议标签交换体系结构（MPLS）操作和维护（OAM）功能的‘OAM警报标签’分配”，RFC 34292002年11月。
[OAM-Mng] Ersue, M., Ed., and B. Claise, "An Overview of the IETF Network Management Standards", RFC 6632, June 2012.
[OAM Mng]Ersue，M.，Ed.，和B.Claise，“IETF网络管理标准概述”，RFC 6632，2012年6月。
[OnDemand-CV] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS On-Demand Connectivity Verification and Route Tracing", RFC 6426, November 2011.
[OnDemand CV]Gray，E.，Bahadur，N.，Boutros，S.，和R.Aggarwal，“MPLS按需连接验证和路由跟踪”，RFC 64262011年11月。
[OWAMP] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, September 2006.
[OWAMP]Shalunov，S.，Teitelbaum，B.，Karp，A.，Boote，J.，和M.Zekauskas，“单向主动测量协议（OWAMP）”，RFC 46562006年9月。
[PARIS] Augustin, B., Friedman, T., and R. Teixeira, "Measuring Load-balanced Paths in the Internet", IMC '07 Proceedings of the 7th ACM SIGCOMM conference on Internet measurement, 2007.
[PARIS]Augustin，B.，Friedman，T.，和R.Teixeira，“测量互联网中的负载平衡路径”，IMC'07第七届ACM SIGCOMM互联网测量会议记录，2007年。
[PM-CONS] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, October 2011.
[PM-CONS]Clark，A.和B.Claise，“考虑新绩效指标开发的指南”，BCP 170，RFC 63902011年10月。
[PW-ACH] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.
[PW-ACH]Bryant，S.，Swallow，G.，Martini，L.，和D.McPherson，“用于MPLS PSN的伪线仿真边到边（PWE3）控制字”，RFC 43852006年2月。
[PW-G-ACh] Li, H., Martini, L., He, J., and F. Huang, "Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP)", RFC 6423, November 2011.
[PW-G-ACh]Li，H.，Martini，L.，He，J.，和F.Huang，“在MPLS传输配置文件（MPLS-TP）中使用伪线的通用相关信道标签”，RFC 64232011年11月。
[PW-MAP] Aissaoui, M., Busschbach, P., Martini, L., Morrow, M., Nadeau, T., and Y(J). Stein, "Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping", RFC 6310, July 2011.
[PW-MAP]Aissaoui，M.，Busschbach，P.，Martini，L.，Morrow，M.，Nadeau，T.，和Y（J）。Stein，“伪线（PW）操作、管理和维护（OAM）消息映射”，RFC63102011年7月。
[Reorder] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, "Packet Reordering Metrics", RFC 4737, November 2006.
[再订购]Morton，A.，Ciavattone，L.，Ramachandran，G.，Shalunov，S.，和J.Perser，“数据包再订购度量”，RFC 4737，2006年11月。
[Signal] Yasukawa, S., Ed., "Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006.
[Signal]Yasukawa，S.，Ed.“点对多点流量工程MPLS标签交换路径（LSP）的信令要求”，RFC 4461，2006年4月。
[TCPIP-Tools] Kessler, G. and S. Shepard, "A Primer On Internet and TCP/IP Tools and Utilities", FYI 30, RFC 2151, June 1997.
[TCPIP工具]Kessler，G.和S.Shepard，“互联网和TCP/IP工具及实用程序入门”，FYI 30，RFC 2151，1997年6月。
[TP-CC-CV] 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.
[TP-CC-CV]Allan，D.，Ed.，Swallow Ed.，G.，和J.Drake Ed.“MPLS传输配置文件的主动连接验证、连续性检查和远程缺陷指示”，RFC 6428，2011年11月。
[TP-Fault] 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.
[TP Fault]Swallow，G.，Ed.，Fulignoli，A.，Ed.，Vigoureux，M.，Ed.，Boutros，S.，和D.Ward，“MPLS故障管理操作、管理和维护（OAM）”，RFC 6427，2011年11月。
[TP-LM-DM] Frost, D., Ed., and S. Bryant, Ed., "A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks", RFC 6375, September 2011.
[TP-LM-DM]Frost，D.，Ed.，和S.Bryant，Ed.“基于MPLS的传输网络的数据包丢失和延迟测量模式”，RFC 63752011年9月。
[TP-OAM-FW] Busi, I., Ed., and D. Allan, Ed., "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011.
[TP-OAM-FW]Busi，I.，Ed.，和D.Allan，Ed.“基于MPLS的传输网络的运营、管理和维护框架”，RFC 63712011年9月。
[TP-Term] van Helvoort, H., Ed., Andersson, L., Ed., and N. Sprecher, Ed., "A Thesaurus for the Interpretation of Terminology Used in MPLS Transport Profile (MPLS-TP) Internet-Drafts and RFCs in the Context of the ITU-T's Transport Network Recommendations", RFC 7087, December 2013.
[TP术语]van Helvoort，H.，Ed.，Andersson，L.，Ed.，和N.Sprecher，Ed.，“在ITU-T的传输网络建议的背景下，解释MPLS传输配置文件（MPLS-TP）互联网草案和RFC中使用的术语的词典”，RFC 7087，2013年12月。
[TRILL-OAM] Senevirathne, T., Bond, D., Aldrin, S., Li, Y., and R. Watve, "Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL)", RFC 6905, March 2013.
[TRILL-OAM]Senevirathne，T.，Bond，D.，Aldrin，S.，Li，Y.，和R.Watve，“大量链路透明互连（TRILL）中的运行、管理和维护（OAM）要求”，RFC 69052013年3月。
[TWAMP] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, October 2008.
[TWAMP]Hedayat，K.，Krzanowski，R.，Morton，A.，Yum，K.，和J.Babiarz，“双向主动测量协议（TWAMP）”，RFC 5357，2008年10月。
[VCCV] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[VCCV]Nadeau，T.，Ed.，和C.Pignataro，Ed.，“伪线虚拟电路连接验证（VCCV）：伪线的控制通道”，RFC 5085，2007年12月。
[VCCV-SURVEY] Del Regno, N., Ed., and A. Malis, Ed., "The Pseudowire (PW) and Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results", RFC 7079, November 2013.
[VCCV-SURVEY]Del Regno，N.，Ed.，和A.Malis，Ed.，“伪线（PW）和虚拟电路连接验证（VCCV）实施调查结果”，RFC 7079，2013年11月。
Table 5 summarizes the OAM-related RFCs produced by the IETF.
表5总结了IETF产生的与OAM相关的RFC。
It is important to note that the table lists various RFCs that are different by nature. For example, some of these documents define OAM tools or OAM protocols (or both), while others define protocols that are not strictly OAM related, but are used by OAM tools. The table also includes RFCs that define the requirements or the framework of OAM in a specific context (e.g., MPLS-TP).
需要注意的是，该表列出了性质不同的各种RFC。例如，其中一些文档定义了OAM工具或OAM协议（或两者），而另一些文档定义了与OAM无关但由OAM工具使用的协议。该表还包括在特定上下文（例如MPLS-TP）中定义OAM需求或框架的RFC。
The RFCs in the table are categorized in a few sets as defined in Section 1.3.
表中的RFC按照第1.3节中的定义分为几组。
+-----------+--------------------------------------+----------+
| Toolset | Title | RFC |
+-----------+--------------------------------------+----------+
|IP Ping | Requirements for Internet Hosts -- | RFC 1122 |
| | Communication Layers [IntHost] | |
| +--------------------------------------+----------+
| | A Glossary of Networking Terms | RFC 1208 |
| | [NetTerms] | |
| +--------------------------------------+----------+
| | Internet Control Message Protocol | RFC 792 |
| | [ICMPv4] | |
| +--------------------------------------+----------+
| | Internet Control Message Protocol | RFC 4443 |
| | (ICMPv6) for the Internet Protocol | |
| | Version 6 (IPv6) Specification | |
| | [ICMPv6] | |
+-----------+--------------------------------------+----------+
|IP | A Primer On Internet and TCP/IP | RFC 2151 |
|Traceroute | Tools and Utilities [TCPIP-Tools] | |
| +--------------------------------------+----------+
| | FYI on a Network Management Tool | RFC 1470 |
| | Catalog: Tools for Monitoring and | |
| | Debugging TCP/IP Internets and | |
| | Interconnected Devices [NetTools] | |
| +--------------------------------------+----------+
| | Internet Control Message Protocol | RFC 792 |
| | [ICMPv4] | |
| +--------------------------------------+----------+
| | Internet Control Message Protocol | RFC 4443 |
| | (ICMPv6) for the Internet Protocol | |
| | Version 6 (IPv6) Specification | |
| | [ICMPv6] | |
+-----------+--------------------------------------+----------+
| Toolset | Title | RFC |
+-----------+--------------------------------------+----------+
|IP Ping | Requirements for Internet Hosts -- | RFC 1122 |
| | Communication Layers [IntHost] | |
| +--------------------------------------+----------+
| | A Glossary of Networking Terms | RFC 1208 |
| | [NetTerms] | |
| +--------------------------------------+----------+
| | Internet Control Message Protocol | RFC 792 |
| | [ICMPv4] | |
| +--------------------------------------+----------+
| | Internet Control Message Protocol | RFC 4443 |
| | (ICMPv6) for the Internet Protocol | |
| | Version 6 (IPv6) Specification | |
| | [ICMPv6] | |
+-----------+--------------------------------------+----------+
|IP | A Primer On Internet and TCP/IP | RFC 2151 |
|Traceroute | Tools and Utilities [TCPIP-Tools] | |
| +--------------------------------------+----------+
| | FYI on a Network Management Tool | RFC 1470 |
| | Catalog: Tools for Monitoring and | |
| | Debugging TCP/IP Internets and | |
| | Interconnected Devices [NetTools] | |
| +--------------------------------------+----------+
| | Internet Control Message Protocol | RFC 792 |
| | [ICMPv4] | |
| +--------------------------------------+----------+
| | Internet Control Message Protocol | RFC 4443 |
| | (ICMPv6) for the Internet Protocol | |
| | Version 6 (IPv6) Specification | |
| | [ICMPv6] | |
| +--------------------------------------+----------+
| | Extended ICMP to Support Multi-Part | RFC 4884 |
| | Messages [ICMP-MP] | |
| +--------------------------------------+----------+
| | Extending ICMP for Interface and | RFC 5837 |
| | Next-Hop Identification [ICMP-Int] | |
+-----------+--------------------------------------+----------+
|BFD | Bidirectional Forwarding Detection | RFC 5880 |
| | (BFD) [BFD] | |
| +--------------------------------------+----------+
| | Bidirectional Forwarding Detection | RFC 5881 |
| | (BFD) for IPv4 and IPv6 (Single Hop) | |
| | [BFD-IP] | |
| +--------------------------------------+----------+
| | Generic Application of Bidirectional | RFC 5882 |
| | Forwarding Detection (BFD)[BFD-Gen] | |
| +--------------------------------------+----------+
| | Bidirectional Forwarding Detection | RFC 5883 |
| | (BFD) for Multihop Paths [BFD-Multi] | |
| +--------------------------------------+----------+
| | Bidirectional Forwarding Detection | RFC 5884 |
| | (BFD) for MPLS Label Switched Paths | |
| | (LSPs) [BFD-LSP] | |
| +--------------------------------------+----------+
| | Bidirectional Forwarding Detection | RFC 5885 |
| | for the Pseudowire Virtual Circuit | |
| | Connectivity Verification (VCCV) | |
| | [BFD-VCCV] | |
+-----------+--------------------------------------+----------+
|MPLS OAM | Operations and Management (OAM) | RFC 4377 |
| | Requirements for Multi-Protocol Label| |
| | Switched (MPLS) Networks [MPLS-OAM] | |
| +--------------------------------------+----------+
| | A Framework for Multi-Protocol | RFC 4378 |
| | Label Switching (MPLS) Operations | |
| | and Management (OAM) [MPLS-OAM-FW] | |
| +--------------------------------------+----------+
| | Detecting Multi-Protocol Label | RFC 4379 |
| | Switched (MPLS) Data Plane Failures | |
| | [LSP-Ping] | |
| +--------------------------------------+----------+
| | Operations and Management (OAM) | RFC 4687 |
| | Requirements for Point-to-Multipoint | |
| | MPLS Networks [MPLS-P2MP] | |
| +--------------------------------------+----------+
| | ICMP Extensions for Multiprotocol | RFC 4950 |
| | Label Switching [ICMP-Ext] | |
| +--------------------------------------+----------+
| | Extended ICMP to Support Multi-Part | RFC 4884 |
| | Messages [ICMP-MP] | |
| +--------------------------------------+----------+
| | Extending ICMP for Interface and | RFC 5837 |
| | Next-Hop Identification [ICMP-Int] | |
+-----------+--------------------------------------+----------+
|BFD | Bidirectional Forwarding Detection | RFC 5880 |
| | (BFD) [BFD] | |
| +--------------------------------------+----------+
| | Bidirectional Forwarding Detection | RFC 5881 |
| | (BFD) for IPv4 and IPv6 (Single Hop) | |
| | [BFD-IP] | |
| +--------------------------------------+----------+
| | Generic Application of Bidirectional | RFC 5882 |
| | Forwarding Detection (BFD)[BFD-Gen] | |
| +--------------------------------------+----------+
| | Bidirectional Forwarding Detection | RFC 5883 |
| | (BFD) for Multihop Paths [BFD-Multi] | |
| +--------------------------------------+----------+
| | Bidirectional Forwarding Detection | RFC 5884 |
| | (BFD) for MPLS Label Switched Paths | |
| | (LSPs) [BFD-LSP] | |
| +--------------------------------------+----------+
| | Bidirectional Forwarding Detection | RFC 5885 |
| | for the Pseudowire Virtual Circuit | |
| | Connectivity Verification (VCCV) | |
| | [BFD-VCCV] | |
+-----------+--------------------------------------+----------+
|MPLS OAM | Operations and Management (OAM) | RFC 4377 |
| | Requirements for Multi-Protocol Label| |
| | Switched (MPLS) Networks [MPLS-OAM] | |
| +--------------------------------------+----------+
| | A Framework for Multi-Protocol | RFC 4378 |
| | Label Switching (MPLS) Operations | |
| | and Management (OAM) [MPLS-OAM-FW] | |
| +--------------------------------------+----------+
| | Detecting Multi-Protocol Label | RFC 4379 |
| | Switched (MPLS) Data Plane Failures | |
| | [LSP-Ping] | |
| +--------------------------------------+----------+
| | Operations and Management (OAM) | RFC 4687 |
| | Requirements for Point-to-Multipoint | |
| | MPLS Networks [MPLS-P2MP] | |
| +--------------------------------------+----------+
| | ICMP Extensions for Multiprotocol | RFC 4950 |
| | Label Switching [ICMP-Ext] | |
| +--------------------------------------+----------+
| | Bidirectional Forwarding Detection | RFC 5884 |
| | for MPLS Label Switched Paths (LSPs) | |
| | [BFD-LSP] | |
+-----------+--------------------------------------+----------+
|MPLS-TP | Requirements for Operations, | RFC 5860 |
|OAM | Administration, and Maintenance (OAM)| |
| | in MPLS Transport Networks | |
| | [MPLS-TP-OAM] | |
| +--------------------------------------+----------+
| | MPLS Generic Associated Channel | RFC 5586 |
| | [G-ACh] | |
| +--------------------------------------+----------+
| | Operations, Administration, and | RFC 6371 |
| | Maintenance Framework for MPLS-Based | |
| | Transport Networks [TP-OAM-FW] | |
| +--------------------------------------+----------+
| | Proactive Connectivity Verification, | RFC 6428 |
| | Continuity Check, and Remote Defect | |
| | Indication for the MPLS Transport | |
| | Profile [TP-CC-CV] | |
| +--------------------------------------+----------+
| | MPLS On-Demand Connectivity | RFC 6426 |
| | Verification and Route Tracing | |
| | [OnDemand-CV] | |
| +--------------------------------------+----------+
| | MPLS Fault Management Operations, | RFC 6427 |
| | Administration, and Maintenance (OAM)| |
| | [TP-Fault] | |
| +--------------------------------------+----------+
| | MPLS Transport Profile Lock Instruct | RFC 6435 |
| | and Loopback Functions [Lock-Loop] | |
| +--------------------------------------+----------+
| | Packet Loss and Delay Measurement for| RFC 6374 |
| | MPLS Networks [MPLS-LM-DM] | |
| +--------------------------------------+----------+
| | A Packet Loss and Delay Measurement | RFC 6375 |
| | Profile for MPLS-Based Transport | |
| | Networks [TP-LM-DM] | |
+-----------+--------------------------------------+----------+
|Pseudowire | Pseudowire Virtual Circuit | RFC 5085 |
|OAM | Connectivity Verification (VCCV): | |
| | A Control Channel for Pseudowires | |
| | [VCCV] | |
| +--------------------------------------+----------+
| | Bidirectional Forwarding Detection | RFC 5884 |
| | for MPLS Label Switched Paths (LSPs) | |
| | [BFD-LSP] | |
+-----------+--------------------------------------+----------+
|MPLS-TP | Requirements for Operations, | RFC 5860 |
|OAM | Administration, and Maintenance (OAM)| |
| | in MPLS Transport Networks | |
| | [MPLS-TP-OAM] | |
| +--------------------------------------+----------+
| | MPLS Generic Associated Channel | RFC 5586 |
| | [G-ACh] | |
| +--------------------------------------+----------+
| | Operations, Administration, and | RFC 6371 |
| | Maintenance Framework for MPLS-Based | |
| | Transport Networks [TP-OAM-FW] | |
| +--------------------------------------+----------+
| | Proactive Connectivity Verification, | RFC 6428 |
| | Continuity Check, and Remote Defect | |
| | Indication for the MPLS Transport | |
| | Profile [TP-CC-CV] | |
| +--------------------------------------+----------+
| | MPLS On-Demand Connectivity | RFC 6426 |
| | Verification and Route Tracing | |
| | [OnDemand-CV] | |
| +--------------------------------------+----------+
| | MPLS Fault Management Operations, | RFC 6427 |
| | Administration, and Maintenance (OAM)| |
| | [TP-Fault] | |
| +--------------------------------------+----------+
| | MPLS Transport Profile Lock Instruct | RFC 6435 |
| | and Loopback Functions [Lock-Loop] | |
| +--------------------------------------+----------+
| | Packet Loss and Delay Measurement for| RFC 6374 |
| | MPLS Networks [MPLS-LM-DM] | |
| +--------------------------------------+----------+
| | A Packet Loss and Delay Measurement | RFC 6375 |
| | Profile for MPLS-Based Transport | |
| | Networks [TP-LM-DM] | |
+-----------+--------------------------------------+----------+
|Pseudowire | Pseudowire Virtual Circuit | RFC 5085 |
|OAM | Connectivity Verification (VCCV): | |
| | A Control Channel for Pseudowires | |
| | [VCCV] | |
| +--------------------------------------+----------+
| | Bidirectional Forwarding Detection | RFC 5885 |
| | for the Pseudowire Virtual Circuit | |
| | Connectivity Verification (VCCV) | |
| | [BFD-VCCV] | |
| +--------------------------------------+----------+
| | Using the Generic Associated Channel | RFC 6423 |
| | Label for Pseudowire in the MPLS | |
| | Transport Profile (MPLS-TP) | |
| | [PW-G-ACh] | |
| +--------------------------------------+----------+
| | Pseudowire (PW) Operations, | RFC 6310 |
| | Administration, and Maintenance (OAM)| |
| | Message Mapping [PW-MAP] | |
| +--------------------------------------+----------+
| | MPLS and Ethernet Operations, | RFC 7023 |
| | Administration, and Maintenance (OAM)| |
| | Interworking [Eth-Int] | |
+-----------+--------------------------------------+----------+
|OWAMP and | A One-way Active Measurement Protocol| RFC 4656 |
|TWAMP | (OWAMP) [OWAMP] | |
| +--------------------------------------+----------+
| | A Two-Way Active Measurement Protocol| RFC 5357 |
| | (TWAMP) [TWAMP] | |
| +--------------------------------------+----------+
| | Framework for IP Performance Metrics | RFC 2330 |
| | [IPPM-FW] | |
| +--------------------------------------+----------+
| | IPPM Metrics for Measuring | RFC 2678 |
| | Connectivity [IPPM-Con] | |
| +--------------------------------------+----------+
| | A One-way Delay Metric for IPPM | RFC 2679 |
| | [IPPM-1DM] | |
| +--------------------------------------+----------+
| | A One-way Packet Loss Metric for IPPM| RFC 2680 |
| | [IPPM-1LM] | |
| +--------------------------------------+----------+
| | A Round-trip Delay Metric for IPPM | RFC 2681 |
| | [IPPM-2DM] | |
| +--------------------------------------+----------+
| | Packet Reordering Metrics | RFC 4737 |
| | [Reorder] | |
| +--------------------------------------+----------+
| | A One-Way Packet Duplication Metric | RFC 5560 |
| | [Dup] | |
| +--------------------------------------+----------+
| | Bidirectional Forwarding Detection | RFC 5885 |
| | for the Pseudowire Virtual Circuit | |
| | Connectivity Verification (VCCV) | |
| | [BFD-VCCV] | |
| +--------------------------------------+----------+
| | Using the Generic Associated Channel | RFC 6423 |
| | Label for Pseudowire in the MPLS | |
| | Transport Profile (MPLS-TP) | |
| | [PW-G-ACh] | |
| +--------------------------------------+----------+
| | Pseudowire (PW) Operations, | RFC 6310 |
| | Administration, and Maintenance (OAM)| |
| | Message Mapping [PW-MAP] | |
| +--------------------------------------+----------+
| | MPLS and Ethernet Operations, | RFC 7023 |
| | Administration, and Maintenance (OAM)| |
| | Interworking [Eth-Int] | |
+-----------+--------------------------------------+----------+
|OWAMP and | A One-way Active Measurement Protocol| RFC 4656 |
|TWAMP | (OWAMP) [OWAMP] | |
| +--------------------------------------+----------+
| | A Two-Way Active Measurement Protocol| RFC 5357 |
| | (TWAMP) [TWAMP] | |
| +--------------------------------------+----------+
| | Framework for IP Performance Metrics | RFC 2330 |
| | [IPPM-FW] | |
| +--------------------------------------+----------+
| | IPPM Metrics for Measuring | RFC 2678 |
| | Connectivity [IPPM-Con] | |
| +--------------------------------------+----------+
| | A One-way Delay Metric for IPPM | RFC 2679 |
| | [IPPM-1DM] | |
| +--------------------------------------+----------+
| | A One-way Packet Loss Metric for IPPM| RFC 2680 |
| | [IPPM-1LM] | |
| +--------------------------------------+----------+
| | A Round-trip Delay Metric for IPPM | RFC 2681 |
| | [IPPM-2DM] | |
| +--------------------------------------+----------+
| | Packet Reordering Metrics | RFC 4737 |
| | [Reorder] | |
| +--------------------------------------+----------+
| | A One-Way Packet Duplication Metric | RFC 5560 |
| | [Dup] | |
+-----------+--------------------------------------+----------+
|TRILL OAM | Requirements for Operations, | RFC 6905 |
| | Administration, and Maintenance (OAM)| |
| | in Transparent Interconnection of | |
| | Lots of Links (TRILL) | |
+-----------+--------------------------------------+----------+
+-----------+--------------------------------------+----------+
|TRILL OAM | Requirements for Operations, | RFC 6905 |
| | Administration, and Maintenance (OAM)| |
| | in Transparent Interconnection of | |
| | Lots of Links (TRILL) | |
+-----------+--------------------------------------+----------+
Table 5: Summary of IETF OAM-Related RFCs
表5:IETF OAM相关RFC汇总
In addition to the OAM tools defined by the IETF, the IEEE and ITU-T have also defined various OAM tools that focus on Ethernet and various other transport-network environments. These various tools, defined by the three standard organizations, are often tightly coupled and have had a mutual effect on each other. The ITU-T and IETF have both defined OAM tools for MPLS LSPs, [ITU-T-Y1711], and [LSP-Ping]. The following OAM standards by the IEEE and ITU-T are to some extent linked to the IETF OAM tools listed above and are mentioned here only as reference material.
除了IETF定义的OAM工具外，IEEE和ITU-T还定义了各种OAM工具，重点关注以太网和各种其他传输网络环境。这三个标准组织定义的各种工具通常紧密耦合，相互影响。ITU-T和IETF都为MPLS LSP、[ITU-T-Y1711]和[LSP Ping]定义了OAM工具。IEEE和ITU-T的以下OAM标准在某种程度上与上述IETF OAM工具相关，此处仅作为参考资料提及。
o OAM tools for Layer 2 have been defined by the ITU-T in [ITU-T-Y1731] and by the IEEE in 802.1ag [IEEE802.1Q]. The IEEE 802.3 standard defines OAM for one-hop Ethernet links [IEEE802.3ah].
o 第2层的OAM工具由ITU-T在[ITU-T-Y1731]中定义，IEEE在802.1ag[IEEE802.1Q]中定义。IEEE 802.3标准为单跳以太网链路定义了OAM[IEEE802.3ah]。
o The ITU-T has defined OAM for MPLS LSPs in [ITU-T-Y1711] and for MPLS-TP OAM in [ITU-G8113.1] and [ITU-G8113.2].
o ITU-T在[ITU-T-Y1711]中为MPLS LSP定义了OAM，在[ITU-G8113.1]和[ITU-G8113.2]中为MPLS-TP OAM定义了OAM。
It should be noted that these non-IETF documents deal in many cases with OAM functions below the IP layer (Layer 2, Layer 2.5) and that in some cases operators use a multi-layered OAM approach, which is a function of the way their networks are designed.
应注意的是，这些非IETF文件在许多情况下涉及IP层（第2层，第2.5层）以下的OAM功能，在某些情况下，运营商使用多层OAM方法，这是其网络设计方式的一种功能。
Table 6 summarizes some of the main OAM standards published by non-IETF standard organizations. This document focuses on IETF OAM standards, but these non-IETF standards are referenced in this document where relevant.
表6总结了非IETF标准组织发布的一些主要OAM标准。本文件主要关注IETF OAM标准，但本文件在相关情况下引用了这些非IETF标准。
+-----------+--------------------------------------+---------------+
| | Title | Document |
+-----------+--------------------------------------+---------------+
|ITU-T | Operation & Maintenance mechanism | ITU-T Y.1711 |
|MPLS OAM | for MPLS networks [ITU-T-Y1711] | |
| +--------------------------------------+---------------+
| | Assignment of the 'OAM Alert Label' | RFC 3429 |
| | for Multiprotocol Label Switching | |
| | Architecture (MPLS) Operation and | |
| | Maintenance (OAM) Functions | |
| | [OAM-Label] | |
| | | |
| | Note: although this is an IETF | |
| | document, it is listed as one of the| |
| | non-IETF OAM standards, since it | |
| | was defined as a complementary part | |
| | of ITU-T Y.1711. | |
+-----------+--------------------------------------+---------------+
|ITU-T | Operations, administration and |ITU-T G.8113.2 |
|MPLS-TP OAM| Maintenance mechanisms for MPLS-TP | |
| | networks using the tools defined for | |
| | MPLS [ITU-G8113.2] | |
| | | |
| | Note: this document describes the | |
| | OAM toolset defined by the IETF for | |
| | MPLS-TP, whereas ITU-T G.8113.1 | |
| | describes the OAM toolset defined | |
| | by the ITU-T. | |
| +--------------------------------------+---------------+
| | Operations, Administration and |ITU-T G.8113.1 |
| | Maintenance mechanism for MPLS-TP in | |
| | Packet Transport Network (PTN) | |
+-----------+--------------------------------------+---------------+
| | Title | Document |
+-----------+--------------------------------------+---------------+
|ITU-T | Operation & Maintenance mechanism | ITU-T Y.1711 |
|MPLS OAM | for MPLS networks [ITU-T-Y1711] | |
| +--------------------------------------+---------------+
| | Assignment of the 'OAM Alert Label' | RFC 3429 |
| | for Multiprotocol Label Switching | |
| | Architecture (MPLS) Operation and | |
| | Maintenance (OAM) Functions | |
| | [OAM-Label] | |
| | | |
| | Note: although this is an IETF | |
| | document, it is listed as one of the| |
| | non-IETF OAM standards, since it | |
| | was defined as a complementary part | |
| | of ITU-T Y.1711. | |
+-----------+--------------------------------------+---------------+
|ITU-T | Operations, administration and |ITU-T G.8113.2 |
|MPLS-TP OAM| Maintenance mechanisms for MPLS-TP | |
| | networks using the tools defined for | |
| | MPLS [ITU-G8113.2] | |
| | | |
| | Note: this document describes the | |
| | OAM toolset defined by the IETF for | |
| | MPLS-TP, whereas ITU-T G.8113.1 | |
| | describes the OAM toolset defined | |
| | by the ITU-T. | |
| +--------------------------------------+---------------+
| | Operations, Administration and |ITU-T G.8113.1 |
| | Maintenance mechanism for MPLS-TP in | |
| | Packet Transport Network (PTN) | |
| +--------------------------------------+---------------+
| | Allocation of a Generic Associated | RFC 6671 |
| | Channel Type for ITU-T MPLS Transport| |
| | Profile Operation, Maintenance, and | |
| | Administration (MPLS-TP OAM) | |
| | [ITU-T-CT] | |
| | | |
| | Note: although this is an IETF | |
| | document, it is listed as one of the| |
| | non-IETF OAM standards, since it | |
| | was defined as a complementary part | |
| | of ITU-T G.8113.1. | |
+-----------+--------------------------------------+---------------+
|ITU-T | OAM Functions and Mechanisms for | ITU-T Y.1731 |
|Ethernet | Ethernet-based Networks | |
|OAM | [ITU-T-Y1731] | |
+-----------+--------------------------------------+---------------+
|IEEE | Connectivity Fault Management | IEEE 802.1ag |
|CFM | [IEEE802.1Q] | |
| | | |
| | Note: CFM was originally published | |
| | as IEEE 802.1ag but is now | |
| | incorporated in the 802.1Q standard.| |
+-----------+--------------------------------------+---------------+
|IEEE | Management of Data Driven and Data | IEEE 802.1ag |
|DDCFM | Dependent Connectivity Faults | |
| | [IEEE802.1Q] | |
| | | |
| | Note: DDCFM was originally published| |
| | as IEEE 802.1Qaw but is now | |
| | incorporated in the 802.1Q standard.| |
+-----------+--------------------------------------+---------------+
|IEEE | Media Access Control Parameters, | IEEE 802.3ah |
|802.3 | Physical Layers, and Management | |
|link level | Parameters for Subscriber Access | |
|OAM | Networks [IEEE802.3ah] | |
| | | |
| | Note: link level OAM was originally | |
| | defined in IEEE 802.3ah and is now | |
| | incorporated in the 802.3 standard. | |
+-----------+--------------------------------------+---------------+
| +--------------------------------------+---------------+
| | Allocation of a Generic Associated | RFC 6671 |
| | Channel Type for ITU-T MPLS Transport| |
| | Profile Operation, Maintenance, and | |
| | Administration (MPLS-TP OAM) | |
| | [ITU-T-CT] | |
| | | |
| | Note: although this is an IETF | |
| | document, it is listed as one of the| |
| | non-IETF OAM standards, since it | |
| | was defined as a complementary part | |
| | of ITU-T G.8113.1. | |
+-----------+--------------------------------------+---------------+
|ITU-T | OAM Functions and Mechanisms for | ITU-T Y.1731 |
|Ethernet | Ethernet-based Networks | |
|OAM | [ITU-T-Y1731] | |
+-----------+--------------------------------------+---------------+
|IEEE | Connectivity Fault Management | IEEE 802.1ag |
|CFM | [IEEE802.1Q] | |
| | | |
| | Note: CFM was originally published | |
| | as IEEE 802.1ag but is now | |
| | incorporated in the 802.1Q standard.| |
+-----------+--------------------------------------+---------------+
|IEEE | Management of Data Driven and Data | IEEE 802.1ag |
|DDCFM | Dependent Connectivity Faults | |
| | [IEEE802.1Q] | |
| | | |
| | Note: DDCFM was originally published| |
| | as IEEE 802.1Qaw but is now | |
| | incorporated in the 802.1Q standard.| |
+-----------+--------------------------------------+---------------+
|IEEE | Media Access Control Parameters, | IEEE 802.3ah |
|802.3 | Physical Layers, and Management | |
|link level | Parameters for Subscriber Access | |
|OAM | Networks [IEEE802.3ah] | |
| | | |
| | Note: link level OAM was originally | |
| | defined in IEEE 802.3ah and is now | |
| | incorporated in the 802.3 standard. | |
+-----------+--------------------------------------+---------------+
Table 6: Non-IETF OAM Standards Mentioned in This Document
表6：本文件中提到的非IETF OAM标准
Authors' Addresses
作者地址
Tal Mizrahi Marvell 6 Hamada St. Yokneam 20692 Israel
Tal Mizrahi Marvell 6 Hamada St.Yokneam以色列20692
EMail: talmi@marvell.com
EMail: talmi@marvell.com
Nurit Sprecher Nokia Solutions and 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
Elisa Bellagamba Ericsson 6 Farogatan St. Stockholm 164 40 Sweden
Elisa Bellagamba Ericsson 6 Farogatan St.斯德哥尔摩164 40瑞典
Phone: +46 761440785
EMail: elisa.bellagamba@ericsson.com
Phone: +46 761440785
EMail: elisa.bellagamba@ericsson.com
Yaacov Weingarten 34 Hagefen St. Karnei Shomron 4485500 Israel
Yaacov Weingarten 34 Hagefen St.Karnei Shomron以色列4485500
EMail: wyaacov@gmail.com
EMail: wyaacov@gmail.com