Internet Engineering Task Force (IETF) I. Busi, Ed.
Request for Comments: 6371 Alcatel-Lucent
Category: Informational D. Allan, Ed.
ISSN: 2070-1721 Ericsson
September 2011
Internet Engineering Task Force (IETF) I. Busi, Ed.
Request for Comments: 6371 Alcatel-Lucent
Category: Informational D. Allan, Ed.
ISSN: 2070-1721 Ericsson
September 2011
Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks
基于MPLS的传输网络的操作、管理和维护框架
Abstract
摘要
The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS Traffic Engineering (MPLS-TE) and pseudowire (PW) data-plane architectures.
多协议标签交换（MPLS-TP）传输模式是一种基于MPLS流量工程（MPLS-TE）和伪线（PW）数据平面架构的基于分组的传输技术。
This document describes a framework to support a comprehensive set of Operations, Administration, and Maintenance (OAM) procedures that fulfill the MPLS-TP OAM requirements for fault, performance, and protection-switching management and that do not rely on the presence of a control plane.
本文档描述了一个框架，用于支持一整套操作、管理和维护（OAM）程序，这些程序满足故障、性能和保护交换管理的MPLS-TP OAM要求，并且不依赖于控制平面的存在。
This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.
本文件是联合互联网工程任务组（IETF）/国际电信联盟电信标准化部门（ITU-T）努力的成果，旨在将MPLS传输配置文件纳入IETF MPLS和伪线仿真边到边（PWE3）中支持ITU-T定义的分组传输网络的能力和功能的体系结构。
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/rfc6371.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6371.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................5
2.1. Terminology ................................................5
2.2. Definitions ................................................7
3. Functional Components ..........................................10
3.1. Maintenance Entity and Maintenance Entity Group ...........10
3.2. MEG Nesting: SPMEs and Tandem Connection Monitoring .......13
3.3. MEG End Points (MEPs) .....................................14
3.4. MEG Intermediate Points (MIPs) ............................18
3.5. Server MEPs ...............................................20
3.6. Configuration Considerations ..............................21
3.7. P2MP Considerations .......................................21
3.8. Further Considerations of Enhanced Segment Monitoring .....22
4. Reference Model ................................................23
4.1. MPLS-TP Section Monitoring (SMEG) .........................26
4.2. MPLS-TP LSP End-to-End Monitoring Group (LMEG) ............27
4.3. MPLS-TP PW Monitoring (PMEG) ..............................27
4.4. MPLS-TP LSP SPME Monitoring (LSMEG) .......................28
4.5. MPLS-TP MS-PW SPME Monitoring (PSMEG) .....................30
4.6. Fate-Sharing Considerations for Multilink .................31
5. OAM Functions for Proactive Monitoring .........................32
5.1. Continuity Check and Connectivity Verification ............33
5.1.1. Defects Identified by CC-V .........................35
5.1.2. Consequent Action ..................................37
5.1.3. Configuration Considerations .......................38
5.2. Remote Defect Indication ..................................40
5.2.1. Configuration Considerations .......................40
5.3. Alarm Reporting ...........................................41
5.4. Lock Reporting ............................................42
5.5. Packet Loss Measurement ...................................44
5.5.1. Configuration Considerations .......................45
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................5
2.1. Terminology ................................................5
2.2. Definitions ................................................7
3. Functional Components ..........................................10
3.1. Maintenance Entity and Maintenance Entity Group ...........10
3.2. MEG Nesting: SPMEs and Tandem Connection Monitoring .......13
3.3. MEG End Points (MEPs) .....................................14
3.4. MEG Intermediate Points (MIPs) ............................18
3.5. Server MEPs ...............................................20
3.6. Configuration Considerations ..............................21
3.7. P2MP Considerations .......................................21
3.8. Further Considerations of Enhanced Segment Monitoring .....22
4. Reference Model ................................................23
4.1. MPLS-TP Section Monitoring (SMEG) .........................26
4.2. MPLS-TP LSP End-to-End Monitoring Group (LMEG) ............27
4.3. MPLS-TP PW Monitoring (PMEG) ..............................27
4.4. MPLS-TP LSP SPME Monitoring (LSMEG) .......................28
4.5. MPLS-TP MS-PW SPME Monitoring (PSMEG) .....................30
4.6. Fate-Sharing Considerations for Multilink .................31
5. OAM Functions for Proactive Monitoring .........................32
5.1. Continuity Check and Connectivity Verification ............33
5.1.1. Defects Identified by CC-V .........................35
5.1.2. Consequent Action ..................................37
5.1.3. Configuration Considerations .......................38
5.2. Remote Defect Indication ..................................40
5.2.1. Configuration Considerations .......................40
5.3. Alarm Reporting ...........................................41
5.4. Lock Reporting ............................................42
5.5. Packet Loss Measurement ...................................44
5.5.1. Configuration Considerations .......................45
5.5.2. Sampling Skew ......................................45
5.5.3. Multilink Issues ...................................45
5.6. Packet Delay Measurement ..................................46
5.6.1. Configuration Considerations .......................46
5.7. Client Failure Indication .................................47
5.7.1. Configuration Considerations .......................47
6. OAM Functions for On-Demand Monitoring .........................48
6.1. Connectivity Verification .................................48
6.1.1. Configuration Considerations .......................49
6.2. Packet Loss Measurement ...................................50
6.2.1. Configuration Considerations .......................50
6.2.2. Sampling Skew ......................................50
6.2.3. Multilink Issues ...................................50
6.3. Diagnostic Tests ..........................................50
6.3.1. Throughput Estimation ..............................51
6.3.2. Data-Plane Loopback ................................52
6.4. Route Tracing .............................................54
6.4.1. Configuration Considerations .......................54
6.5. Packet Delay Measurement ..................................54
6.5.1. Configuration Considerations .......................55
7. OAM Functions for Administration Control .......................55
7.1. Lock Instruct .............................................55
7.1.1. Locking a Transport Path ...........................56
7.1.2. Unlocking a Transport Path .........................56
8. Security Considerations ........................................57
9. Acknowledgments ................................................58
10. References ....................................................58
10.1. Normative References .....................................58
10.2. Informative References ...................................59
11. Contributing Authors ..........................................60
5.5.2. Sampling Skew ......................................45
5.5.3. Multilink Issues ...................................45
5.6. Packet Delay Measurement ..................................46
5.6.1. Configuration Considerations .......................46
5.7. Client Failure Indication .................................47
5.7.1. Configuration Considerations .......................47
6. OAM Functions for On-Demand Monitoring .........................48
6.1. Connectivity Verification .................................48
6.1.1. Configuration Considerations .......................49
6.2. Packet Loss Measurement ...................................50
6.2.1. Configuration Considerations .......................50
6.2.2. Sampling Skew ......................................50
6.2.3. Multilink Issues ...................................50
6.3. Diagnostic Tests ..........................................50
6.3.1. Throughput Estimation ..............................51
6.3.2. Data-Plane Loopback ................................52
6.4. Route Tracing .............................................54
6.4.1. Configuration Considerations .......................54
6.5. Packet Delay Measurement ..................................54
6.5.1. Configuration Considerations .......................55
7. OAM Functions for Administration Control .......................55
7.1. Lock Instruct .............................................55
7.1.1. Locking a Transport Path ...........................56
7.1.2. Unlocking a Transport Path .........................56
8. Security Considerations ........................................57
9. Acknowledgments ................................................58
10. References ....................................................58
10.1. Normative References .....................................58
10.2. Informative References ...................................59
11. Contributing Authors ..........................................60
As noted in the MPLS Transport Profile (MPLS-TP) framework RFCs (RFC 5921 [8] and RFC 6215 [9]), MPLS-TP is a packet-based transport technology based on the MPLS Traffic Engineering (MPLS-TE) and pseudowire (PW) data-plane architectures defined in RFC 3031 [1], RFC 3985 [2], and RFC 5659 [4].
如MPLS传输配置文件（MPLS-TP）框架RFCs（RFC 5921[8]和RFC 6215[9]）中所述，MPLS-TP是基于RFC 3031[1]、RFC 3985[2]和RFC 5659[4]中定义的MPLS流量工程（MPLS-TE）和伪线（PW）数据平面体系结构的分组传输技术。
MPLS-TP utilizes a comprehensive set of Operations, Administration, and Maintenance (OAM) procedures for fault, performance, and protection-switching management that do not rely on the presence of a control plane.
MPLS-TP利用一整套操作、管理和维护（OAM）程序进行故障、性能和保护切换管理，不依赖于控制平面的存在。
In line with [15], existing MPLS OAM mechanisms will be used wherever possible, and extensions or new OAM mechanisms will be defined only where existing mechanisms are not sufficient to meet the requirements. Some extensions discussed in this framework may end up
根据[15]，将尽可能使用现有的MPLS OAM机制，只有在现有机制不足以满足要求的情况下，才会定义扩展或新的OAM机制。在这个框架中讨论的一些扩展可能会结束
as aspirational capabilities and may be determined to be not tractably realizable in some implementations. Extensions do not deprecate support for existing MPLS OAM capabilities.
作为期望能力，在某些实现中可能被确定为不可跟踪实现。扩展不反对对现有MPLS OAM功能的支持。
The MPLS-TP OAM framework defined in this document provides a protocol-neutral description of the required OAM functions and of the data-plane OAM architecture to support a comprehensive set of OAM procedures that satisfy the MPLS-TP OAM requirements of RFC 5860 [11]. In this regard, it defines similar OAM functionality as for existing Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH) and Optical Transport Network (OTN) OAM mechanisms (e.g., [19]).
本文件中定义的MPLS-TP OAM框架提供了所需OAM功能和数据平面OAM体系结构的协议中立描述，以支持满足RFC 5860[11]中MPLS-TP OAM要求的一整套OAM程序。在这方面，它定义了与现有同步光网络/同步数字体系（SONET/SDH）和光传输网络（OTN）OAM机制（例如，[19]）类似的OAM功能。
The MPLS-TP OAM framework is applicable to Sections, Label Switched Paths (LSPs), Multi-Segment Pseudowires (MS-PWs), and Sub-Path Maintenance Elements (SPMEs). It supports co-routed and associated bidirectional P2P transport paths as well as unidirectional P2P and P2MP transport paths.
MPLS-TP OAM框架适用于区段、标签交换路径（LSP）、多段伪线（MS PW）和子路径维护元件（SPME）。它支持共路由和关联的双向P2P传输路径以及单向P2P和P2MP传输路径。
OAM packets that instrument a particular direction of a transport path are subject to the same forwarding treatment (i.e., fate-share) as the user data packets and in some cases, where Explicitly TC-encoded-PSC LSPs (E-LSPs) are employed, may be required to have common per-hop behavior (PHB) Scheduling Class (PSC) End-to-End (E2E) with the class of traffic monitored. In case of Label-Only-Inferred-PSC LSP (L-LSP), only one class of traffic needs to be monitored, and therefore the OAM packets have common PSC with the monitored traffic class.
指示传输路径的特定方向的OAM分组受到与用户数据分组相同的转发处理（即命运共享），并且在某些情况下，在使用显式TC编码的PSC lsp（e-lsp）的情况下，可能需要具有公共每跳行为（PHB）调度类（PSC）端到端（E2E）监控流量等级。在仅标签推断的PSC LSP（L-LSP）的情况下，只需要监控一类流量，因此OAM数据包具有与监控的流量类别相同的PSC。
OAM packets can be distinguished from the used data packets using the Generic Associated Channel Label (GAL) and Associated Channel Header (ACH) constructs of RFC 5586 [7] for LSP, SPME, and Section, or the ACH construct of RFC 5085 [3] and RFC 5586 [7] for (MS-)PW. OAM packets are never fragmented and are not combined with user data in the same packet payload.
对于LSP、SPME和Section，使用RFC 5586[7]的通用关联信道标签（GAL）和关联信道报头（ACH）构造，或者对于（MS-）PW，使用RFC 5085[3]和RFC 5586[7]的ACH构造，可以将OAM分组与所使用的数据分组区分开来。OAM数据包从不分段，也不会与同一数据包负载中的用户数据组合。
This framework makes certain assumptions as to the utility and frequency of different classes of measurement that naturally suggest different functions are implemented as distinct OAM flows or packets. This is dictated by the combination of the class of problem being detected and the need for timeliness of network response to the problem. For example, fault detection is expected to operate on an entirely different time base than performance monitoring, which is also expected to operate on an entirely different time base than in-band management transactions.
该框架对不同类别的度量的效用和频率做出了某些假设，这些假设自然表明不同的功能被实现为不同的OAM流或数据包。这取决于检测到的问题类别和网络对问题响应的及时性的需要。例如，故障检测预计在与性能监控完全不同的时基上运行，性能监控也预计在与带内管理事务完全不同的时基上运行。
The remainder of this memo is structured as follows:
本备忘录的其余部分结构如下：
Section 2 covers the definitions and terminology used in this memo.
第2节介绍了本备忘录中使用的定义和术语。
Section 3 describes the functional component that generates and processes OAM packets.
第3节描述了生成和处理OAM数据包的功能组件。
Section 4 describes the reference models for applying OAM functions to Sections, LSP, MS-PW, and their SPMEs.
第4节描述了将OAM功能应用于各节、LSP、MS-PW及其SPME的参考模型。
Sections 5, 6, and 7 provide a protocol-neutral description of the OAM functions, defined in RFC 5860 [11], aimed at clarifying how the OAM protocol solutions will behave to achieve their functional objectives.
第5、6和7节提供了RFC 5860[11]中定义的OAM功能的协议中立描述，旨在阐明OAM协议解决方案将如何实现其功能目标。
Section 8 discusses the security implications of OAM protocol design in the MPLS-TP context.
第8节讨论了MPLS-TP上下文中OAM协议设计的安全含义。
The OAM protocol solutions designed as a consequence of this document are expected to comply with the functional behavior described in Sections 5, 6, and 7. Alternative solutions to required functional behaviors may also be defined.
根据本文件设计的OAM协议解决方案应符合第5、6和7节所述的功能行为。还可以定义所需功能行为的替代解决方案。
OAM specifications following this OAM framework may be provided in different documents to cover distinct OAM functions.
遵循此OAM框架的OAM规范可以在不同的文档中提供，以涵盖不同的OAM功能。
This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.
本文件是联合互联网工程任务组（IETF）/国际电信联盟电信标准化部门（ITU-T）的产品努力在IETF MPLS和PWE3体系结构中包括MPLS传输配置文件，以支持ITU-T定义的分组传输网络的能力和功能。
AC Attachment Circuit
交流连接电路
AIS Alarm Indication Signal
AIS报警指示信号
CC Continuity Check
连续性检查
CC-V Continuity Check and Connectivity Verification
CC-V连续性检查和连接验证
CV Connectivity Verification
CV连通性验证
DBN Domain Border Node
域边界节点
E-LSP Explicitly TC-encoded-PSC LSP
E-LSP显式TC编码PSC LSP
ICC ITU Carrier Code
国际电信联盟载波代码
LER Label Edge Router
标签边缘路由器
LKR Lock Report
LKR锁报告
L-LSP Label-Only-Inferred-PSC LSP
L-LSP标签仅推断PSC LSP
LM Loss Measurement
LM损耗测量
LME LSP Maintenance Entity
LME LSP维护实体
LMEG LSP ME Group
LMEG LSP ME组
LSP Label Switched Path
标签交换路径
LSR Label Switching Router
标签交换路由器
LSME LSP SPME ME
LSME LSP SPME
LSMEG LSP SPME ME Group
LSMEG LSP SPME组
ME Maintenance Entity
ME维护实体
MEG Maintenance Entity Group
MEG维护实体组
MEP Maintenance Entity Group End Point
MEP维护实体组终点
MIP Maintenance Entity Group Intermediate Point
MIP维护实体组中间点
NMS Network Management System
网管系统
PE Provider Edge
PE提供商边缘
PHB Per-Hop Behavior
PHB每跳行为
PM Performance Monitoring
PM性能监测
PME PW Maintenance Entity
PME PW维护实体
PMEG PW ME Group
PMEG PW ME组
PSC PHB Scheduling Class
PSC PHB调度类
PSME PW SPME ME
PSME-PW-SPME-ME
PSMEG PW SPME ME Group
PSMEG PW SPME组
PW Pseudowire
伪线
SLA Service Level Agreement
SLA服务级别协议
SME Section Maintenance Entity
中小企业部门维护实体
SMEG Section ME Group
SMEG组
SPME Sub-Path Maintenance Element
子路径维护元件
S-PE Switching Provider Edge
S-PE交换提供程序边缘
TC Traffic Class
TC交通等级
T-PE Terminating Provider Edge
T-PE端接提供程序边缘
This document uses the terms defined in RFC 5654 [5].
本文件使用RFC 5654[5]中定义的术语。
This document uses the term 'per-hop behavior' as defined in RFC 2474 [16].
本文件使用RFC 2474[16]中定义的术语“每跳行为”。
This document uses the term 'LSP' to indicate either a service LSP or a transport LSP (as defined in RFC 5921 [8]).
本文件使用术语“LSP”表示服务LSP或传输LSP（如RFC 5921[8]中所定义）。
This document uses the term 'Section' exclusively to refer to the n=0 case of the term 'Section' defined in RFC 5960 [10].
本文件使用术语“节”专门指RFC 5960[10]中定义的术语“节”的n=0情况。
This document uses the term 'Sub-Path Maintenance Element (SPME)' as defined in RFC 5921 [8].
本文件使用RFC 5921[8]中定义的术语“子路径维护元素（SPME）”。
This document uses the term 'traffic profile' as defined in RFC 2475 [13].
本文件使用RFC 2475[13]中定义的术语“交通概况”。
Where appropriate, the following definitions are aligned with ITU-T recommendation Y.1731 [21] in order to have a common, unambiguous terminology. They do not however intend to imply a certain implementation but rather serve as a framework to describe the necessary OAM functions for MPLS-TP.
在适当情况下，以下定义与ITU-T建议Y.1731[21]一致，以便有一个通用的、明确的术语。然而，它们并不意味着某种实现，而是作为一个框架来描述MPLS-TP所需的OAM功能。
Adaptation function: The adaptation function is the interface between the client (sub-)layer and the server (sub-)layer.
适配功能：适配功能是客户端（子）层和服务器（子）层之间的接口。
Branch Node: A node along a point-to-multipoint transport path that is connected to more than one downstream node.
分支节点：沿点对多点传输路径连接到多个下游节点的节点。
Bud Node: A node along a point-to-multipoint transport path that is at the same time a branch node and a leaf node for this transport path.
Bud节点：沿点对多点传输路径的节点，同时是该传输路径的分支节点和叶节点。
Data-plane loopback: An out-of-service test where a transport path at either an intermediate or terminating node is placed into a data-plane loopback state, such that all traffic (including both payload and OAM) received on the looped back interface is sent on the reverse direction of the transport path.
数据平面环回：一种停止服务测试，其中中间或终止节点的传输路径处于数据平面环回状态，以便在环回接口上接收的所有通信量（包括有效负载和OAM）沿传输路径的相反方向发送。
Note: The only way to send an OAM packet to a node that has been put into data-plane loopback mode is via Time to Live (TTL) expiry, irrespective of whether the node is hosting MIPs or MEPs.
注意：向已进入数据平面环回模式的节点发送OAM数据包的唯一方法是通过生存时间（TTL）到期，而不管该节点是承载MIPs还是MEPs。
Domain Border Node (DBN): An intermediate node in an MPLS-TP LSP that is at the boundary between two MPLS-TP OAM domains. Such a node may be present on the edge of two domains or may be connected by a link to the DBN at the edge of another OAM domain.
域边界节点（DBN）：位于两个MPLS-TP OAM域之间边界的MPLS-TP LSP中的中间节点。这样的节点可以存在于两个域的边缘上，或者可以通过链路连接到另一个OAM域边缘的DBN。
Down MEP: A MEP that receives OAM packets from, and transmits them towards, the direction of a server layer.
下行MEP：从服务器层接收OAM数据包并向服务器层方向传输这些数据包的MEP。
Forwarding Engine: An abstract functional component, residing in an LSR, that forwards the packets from an ingress interface toward the egress interface(s).
转发引擎：驻留在LSR中的抽象功能组件，将数据包从入口接口转发到出口接口。
In-Service: The administrative status of a transport path when it is unlocked.
在用：传输路径解锁时的管理状态。
Interface: An interface is the attachment point to a server (sub-)layer, e.g., a MPLS-TP Section or MPLS-TP tunnel.
接口：接口是服务器（子）层的连接点，例如MPLS-TP节或MPLS-TP隧道。
Intermediate Node: An intermediate node transits traffic for an LSP or a PW. An intermediate node may originate OAM flows directed to downstream intermediate nodes or MEPs.
中间节点：中间节点传输LSP或PW的流量。中间节点可以发起指向下游中间节点或mep的OAM流。
Loopback: See data-plane loopback and OAM loopback definitions.
环回：请参阅数据平面环回和OAM环回定义。
Maintenance Entity (ME): Some portion of a transport path that requires management bounded by two points (called MEPs), and the relationship between those points to which maintenance and monitoring operations apply (details in Section 3.1).
维护实体（ME）：运输路径的某些部分，需要由两点（称为MEP）以及维护和监控操作适用的点之间的关系进行管理（详情见第3.1节）。
Maintenance Entity Group (MEG): The set of one or more maintenance entities that maintain and monitor a section or a transport path in an OAM domain.
维护实体组（MEG）：维护和监视OAM域中的节或传输路径的一个或多个维护实体的集合。
MEP: A MEG End Point (MEP) is capable of initiating (source MEP) and terminating (sink MEP) OAM packets for fault management and performance monitoring. MEPs define the boundaries of an ME (details in Section 3.3).
MEP：MEG端点（MEP）能够启动（源MEP）和终止（汇MEP）OAM数据包，用于故障管理和性能监控。MEP定义ME的边界（详见第3.3节）。
MIP: A MEG intermediate point (MIP) terminates and processes OAM packets that are sent to this particular MIP and may generate OAM packets in reaction to received OAM packets. It never generates unsolicited OAM packets itself. A MIP resides within a MEG between MEPs (details in Section 3.3).
MIP：MEG中间点（MIP）终止并处理发送到此特定MIP的OAM数据包，并可能生成OAM数据包以响应接收到的OAM数据包。它本身从不生成未经请求的OAM数据包。MIP位于MEP之间的MEG内（详情见第3.3节）。
OAM domain: A domain, as defined in [5], whose entities are grouped for the purpose of keeping the OAM confined within that domain. An OAM domain contains zero or more MEGs.
OAM域：如[5]中定义的一个域，其实体分组的目的是将OAM限制在该域内。OAM域包含零个或多个MEG。
Note: Within the rest of this document, the term "domain" is used to indicate an "OAM domain".
注意：在本文档的其余部分中，术语“域”用于表示“OAM域”。
OAM flow: The set of all OAM packets originating with a specific source MEP that instrument one direction of a MEG (or possibly both in the special case of data-plane loopback).
OAM流：由特定源MEP发起的所有OAM数据包的集合，该源MEP指示MEG的一个方向（或在数据平面环回的特殊情况下可能同时指示两个方向）。
OAM loopback: The capability of a node to be directed by a received OAM packet to generate a reply back to the sender. OAM loopback can work in-service and can support different OAM functions (e.g., bidirectional on-demand connectivity verification).
OAM环回：由接收到的OAM数据包引导节点生成回复给发送方的能力。OAM环回可以在服务中工作，并且可以支持不同的OAM功能（例如，双向按需连接验证）。
OAM Packet: A packet that carries OAM information between MEPs and/or MIPs in a MEG to perform some OAM functionality (e.g., connectivity verification).
OAM数据包：在MEG中的MEP和/或MIP之间承载OAM信息的数据包，用于执行某些OAM功能（例如，连接验证）。
Originating MEP: A MEP that originates an OAM transaction packet (toward a target MIP/MEP) and expects a reply, either in-band or out-of-band, from that target MIP/MEP. The originating MEP always generates the OAM request packets in-band and expects and processes only OAM reply packets returned by the target MIP/MEP.
发起MEP：发起OAM事务包（指向目标MIP/MEP）并期望从该目标MIP/MEP获得带内或带外回复的MEP。始发MEP始终在频带内生成OAM请求数据包，并仅期望和处理目标MIP/MEP返回的OAM应答数据包。
Out-of-Service: The administrative status of a transport path when it is locked. When a path is in a locked condition, it is blocked from carrying client traffic.
停止服务：传输路径锁定时的管理状态。当路径处于锁定状态时，它将被阻止承载客户端流量。
Path Segment: It is either a segment or a concatenated segment, as defined in RFC 5654 [5].
路径段：如RFC 5654[5]中所定义，它是一个段或一个连接段。
Signal Degrade: A condition declared by a MEP when the data forwarding capability associated with a transport path has deteriorated, as determined by performance monitoring (PM). See also ITU-T recommendation G.806 [14].
信号降级：当与传输路径相关的数据转发能力恶化时，MEP宣布的一种状态，由性能监视（PM）确定。另见ITU-T建议G.806[14]。
Signal Fail: A condition declared by a MEP when the data forwarding capability associated with a transport path has failed, e.g., loss of continuity. See also ITU-T recommendation G.806 [14].
信号失效：当与传输路径相关的数据转发能力失效时，MEP宣布的一种状态，例如，连续性丧失。另见ITU-T建议G.806[14]。
Sink MEP: A MEP acts as a sink MEP for an OAM packet when it terminates and processes the packets received from its associated MEG.
Sink-MEP：当MEP终止并处理从其相关MEG接收的数据包时，它充当OAM数据包的Sink-MEP。
Source MEP: A MEP acts as source MEP for an OAM packet when it originates and inserts the packet into the transport path for its associated MEG.
源MEP：MEP在发起OAM数据包并将该数据包插入其相关MEG的传输路径时，充当该数据包的源MEP。
Tandem Connection: A tandem connection is an arbitrary part of a transport path that can be monitored (via OAM) independent of the end-to-end monitoring (OAM). The tandem connection may also include the forwarding engine(s) of the node(s) at the boundaries of the tandem connection. Tandem connections may be nested but cannot overlap. See also ITU-T recommendation G.805 [20].
串联连接：串联连接是传输路径的任意部分，可以独立于端到端监控（OAM）进行监控（通过OAM）。串联连接还可以包括串联连接边界处的节点的转发引擎。串联连接可以嵌套，但不能重叠。另见ITU-T建议G.805[20]。
Target MEP/MIP: A MEP or a MIP that is targeted by OAM transaction packets and that replies to the originating MEP that initiated the OAM transactions. The target MEP or MIP can reply either in-band or out-of-band. The target sink MEP function always receives the OAM request packets in-band, while the target source MEP function only generates the OAM reply packets that are sent in-band.
目标MEP/MIP：OAM事务数据包所针对的MEP或MIP，它响应发起OAM事务的原始MEP。目标MEP或MIP可以带内或带外应答。目标接收器MEP函数始终在频带内接收OAM请求数据包，而目标源MEP函数仅生成在频带内发送的OAM应答数据包。
Up MEP: A MEP that transmits OAM packets towards, and receives them from, the direction of the forwarding engine.
Up MEP：向转发引擎的方向发送OAM数据包并从中接收这些数据包的MEP。
MPLS-TP is a packet-based transport technology based on the MPLS and PW data plane architectures ([1], [2], and [4]) and is capable of transporting service traffic where the characteristics of information transfer between the transport path end points can be demonstrated to comply with certain performance and quality guarantees.
MPLS-TP是一种基于MPLS和PW数据平面架构（[1]、[2]和[4]）的基于分组的传输技术，能够传输服务流量，其中传输路径端点之间的信息传输特性可以证明符合某些性能和质量保证。
In order to describe the required OAM functionality, this document introduces a set of functional components.
为了描述所需的OAM功能，本文档介绍了一组功能组件。
MPLS-TP OAM operates in the context of Maintenance Entities (MEs) that define a relationship between two points of a transport path to which maintenance and monitoring operations apply. The two points that define a maintenance entity are called Maintenance Entity Group End Points (MEPs). The collection of one or more MEs that belongs to the same transport path and that are maintained and monitored as a
MPLS-TP OAM在维护实体（MEs）的上下文中运行，这些维护实体定义了维护和监视操作适用的传输路径的两点之间的关系。定义维护实体的两点称为维护实体组端点（MEP）。属于同一传输路径的一个或多个MEs的集合，并作为一个整体进行维护和监控
group are known as a Maintenance Entity Group (MEG). In between MEPs, there are zero or more intermediate points, called Maintenance Entity Group Intermediate Points (MIPs). MEPs and MIPs are associated with the MEG and can be shared by more than one ME in a MEG.
组称为维护实体组（MEG）。在MEP之间，有零个或多个中间点，称为维护实体组中间点（MIP）。MEP和MIP与MEG关联，可由MEG中的多个ME共享。
An abstract reference model for an ME is illustrated in Figure 1 below.
ME的抽象参考模型如下图1所示。
+-+ +-+ +-+ +-+
|A|----|B|----|C|----|D|
+-+ +-+ +-+ +-+
+-+ +-+ +-+ +-+
|A|----|B|----|C|----|D|
+-+ +-+ +-+ +-+
Figure 1: ME Abstract Reference Model
图1:ME抽象参考模型
The instantiation of this abstract model to different MPLS-TP entities is described in Section 4. In Figure 1, nodes A and D can be Label Edge Routers (LERs) for an LSP or the Terminating Provider Edges (T-PEs) for an MS-PW, nodes B and C are LSRs for an LSP or Switching PEs (S-PEs) for an MS-PW. MEPs reside in nodes A and D, while MIPs reside in nodes B and C and may reside in A and D. The links connecting adjacent nodes can be physical links, (sub-)layer LSPs/SPMEs, or server-layer paths.
第4节描述了将此抽象模型实例化到不同MPLS-TP实体的过程。在图1中，节点A和D可以是LSP的标签边缘路由器（LER）或MS-PW的终端提供商边缘（T-PE），节点B和C是LSP的LSR或MS-PW的交换PE（S-PE）。MEP驻留在节点A和D中，而MIP驻留在节点B和C中，并且可以驻留在A和D中。连接相邻节点的链路可以是物理链路、（子）层LSP/SPME或服务器层路径。
This functional model defines the relationships between all OAM entities from a maintenance perspective and it allows each Maintenance Entity to provide monitoring and management for the (sub-)layer network under its responsibility and efficient localization of problems.
该功能模型从维护的角度定义了所有OAM实体之间的关系，它允许每个维护实体在其职责范围内为（子）层网络提供监控和管理，并有效地定位问题。
An MPLS-TP Maintenance Entity Group may be defined to monitor the transport path for fault and/or performance management.
MPLS-TP维护实体组可被定义为监控传输路径以进行故障和/或性能管理。
The MEPs that form a MEG bound the scope of an OAM flow to the MEG (i.e., within the domain of the transport path that is being monitored and managed). There are two exceptions to this:
构成MEG的MEP将OAM流的范围绑定到MEG（即，在被监视和管理的传输路径的域内）。这有两个例外：
1) A misbranching fault may cause OAM packets to be delivered to a MEP that is not in the MEG of origin.
1) 分支错误故障可能导致OAM数据包被传送到不在源MEG中的MEP。
2) An out-of-band return path may be used between a MIP or a MEP and the originating MEP.
2) 可以在MIP或MEP与原始MEP之间使用带外返回路径。
In case of a unidirectional point-to-point transport path, a single unidirectional Maintenance Entity is defined to monitor it.
如果是单向点到点传输路径，则定义单个单向维护实体对其进行监控。
In case of associated bidirectional point-to-point transport paths, two independent unidirectional Maintenance Entities are defined to independently monitor each direction. This has implications for transactions that terminate at or query a MIP, as a return path from MIP to the originating MEP does not necessarily exist in the MEG.
在相关联的双向点到点传输路径的情况下，定义两个独立的单向维护实体以独立地监视每个方向。这对终止于或查询MIP的交易有影响，因为MEG中不一定存在从MIP到原始MEP的返回路径。
In case of co-routed bidirectional point-to-point transport paths, a single bidirectional Maintenance Entity is defined to monitor both directions congruently.
在共路由双向点到点传输路径的情况下，定义单个双向维护实体以一致地监视两个方向。
In case of unidirectional point-to-multipoint transport paths, a single unidirectional Maintenance Entity for each leaf is defined to monitor the transport path from the root to that leaf.
对于单向点对多点传输路径，为每个叶定义一个单向维护实体，以监控从根到该叶的传输路径。
In all cases, portions of the transport path may be monitored by the instantiation of SPMEs (see Section 3.2).
在所有情况下，传输路径的部分可通过SPME的实例化进行监控（见第3.2节）。
The reference model for the P2MP MEG is represented in Figure 2.
P2MP MEG的参考模型如图2所示。
+-+
/--|D|
/ +-+
+-+
/--|C|
+-+ +-+/ +-+\ +-+
|A|----|B| \--|E|
+-+ +-+\ +-+ +-+
\--|F|
+-+
+-+
/--|D|
/ +-+
+-+
/--|C|
+-+ +-+/ +-+\ +-+
|A|----|B| \--|E|
+-+ +-+\ +-+ +-+
\--|F|
+-+
Figure 2: Reference Model for P2MP MEG
图2:P2MP MEG的参考模型
In the case of P2MP transport paths, the OAM measurements are independent for each ME (A-D, A-E, and A-F):
在P2MP传输路径的情况下，每个ME（A-D、A-E和A-F）的OAM测量是独立的：
o Fault conditions - some faults may impact more than one ME depending on where the failure is located;
o 故障条件-某些故障可能影响多个ME，具体取决于故障位置；
o Packet loss - packet dropping may impact more than one ME depending from where the packets are lost;
o 数据包丢失-数据包丢失可能影响多个ME，具体取决于数据包丢失的位置；
o Packet delay - will be unique per ME.
o 数据包延迟-每个ME都是唯一的。
Each leaf (i.e., D, E, and F) terminates OAM flows to monitor the ME between itself and the root while the root (i.e., A) generates OAM packets common to all the MEs of the P2MP MEG. All nodes may implement a MIP in the corresponding MEG.
每个叶（即，D、e和F）终止OAM流以监视其自身和根之间的ME，而根（即，A）生成P2MP MEG的所有ME共用的OAM包。所有节点都可以在相应的MEG中实现MIP。
In order to verify and maintain performance and quality guarantees, there is a need to apply OAM functionality not only on a transport path granularity (e.g., LSP or MS-PW), but also on arbitrary parts of transport paths, defined as tandem connections, between any two arbitrary points along a transport path.
为了验证和维护性能和质量保证，不仅需要在传输路径粒度（例如，LSP或MS-PW）上应用OAM功能，还需要在传输路径任意两点之间的传输路径的任意部分（定义为串联连接）上应用OAM功能。
Sub-Path Maintenance Elements (SPMEs), as defined in [8], are hierarchical LSPs instantiated to provide monitoring of a portion of a set of transport paths (LSPs or MS-PWs) that follow the same path between the ingress and the egress of the SPME. The operational aspects of instantiating SPMEs are out of scope of this memo.
如[8]中所定义的子路径维护元件（SPME）是分层LSP，其被实例化以提供对一组传输路径（LSP或MS PW）的一部分的监控，这些传输路径在SPME的入口和出口之间遵循相同的路径。实例化SPME的操作方面超出了本备忘录的范围。
SPMEs can also be employed to meet the requirement to provide tandem connection monitoring (TCM), as defined by ITU-T Recommendation G.805 [20].
SPME还可用于满足ITU-T建议G.805[20]中定义的提供串联连接监控（TCM）的要求。
TCM for a given path segment of a transport path is implemented by creating an SPME that has a 1:1 association with the path segment of the transport path that is to be monitored.
传输路径的给定路径段的TCM通过创建与要监控的传输路径的路径段具有1:1关联的SPME来实现。
In the TCM case, this means that the SPME used to provide TCM can carry one and only one transport path, thus allowing direct correlation between all fault management and performance monitoring information gathered for the SPME and the monitored path segment of the end-to-end transport path.
在TCM的情况下，这意味着用于提供TCM的SPME只能承载一条传输路径，从而允许为SPME收集的所有故障管理和性能监控信息与端到端传输路径的监控路径段直接相关。
There are a number of implications to this approach:
这种方法有许多含义：
1) The SPME would use the uniform model [23] of Traffic Class (TC) code point copying between sub-layers for Diffserv such that the E2E markings and PHB treatment for the transport path were preserved by the SPMEs.
1) SPME将使用区分服务子层之间的交通等级（TC）码点复制统一模型[23]，以便SPME保留传输路径的E2E标记和PHB处理。
2) The SPME normally would use the short-pipe model for TTL handling [6] (no TTL copying between sub-layers) such that the TTL distance to the MIPs for the E2E entity would not be impacted by the presence of the SPME, but it should be possible for an operator to specify use of the uniform model.
2) SPME通常会使用短管模型进行TTL处理[6]（子层之间无TTL复制），这样E2E实体到MIPs的TTL距离不会受到SPME的影响，但操作员可以指定使用统一模型。
Note that points 1 and 2 above assume that the TTL copying mode and TC copying modes are independently configurable for an LSP.
注意，上面的第1点和第2点假设TTL复制模式和TC复制模式对于LSP是可独立配置的。
The TTL distance to the MIPs plays a critical role for delivering packets to these MIPs as described in Section 3.4.
如第3.4节所述，到MIPs的TTL距离对于向这些MIPs传送数据包起着关键作用。
There are specific issues with the use of the uniform model of TTL copying for an SPME:
在SPME中使用TTL复制的统一模型时存在一些具体问题：
1. A MIP in the SPME sub-layer is not part of the transport-path MEG; hence, only an out-of-band return path for OAM originating in the transport-path MEG that addressed an SPME MIP might be available.
1. SPME子层中的MIP不是传输路径MEG的一部分；因此，可能只有来自于寻址SPME MIP的传输路径MEG的OAM的带外返回路径可用。
2. The instantiation of a lower-level MEG or protection-switching actions within a lower-level MEG may change the TTL distances to MIPs in the higher-level MEGs.
2. 低电平MEG的实例化或低电平MEG内的保护切换动作可能会改变高电平MEG中到MIPs的TTL距离。
The end points of the SPME are MEPs and limit the scope of an OAM flow within the MEG that the MEPs belong to (i.e., within the domain of the SPME that is being monitored and managed).
SPME的端点是MEP，并限制MEP所属MEG内的OAM流范围（即，在被监视和管理的SPME域内）。
When considering SPMEs, it is important to consider that the following properties apply to all MPLS-TP MEGs (regardless of whether they instrument LSPs, SPMEs, or MS-PWs):
在考虑SPMEs时，重要的是考虑以下属性适用于所有MPLS- TP MEG（不管它们是LSP、SPMES还是MS PWS）：
o They can be nested but not overlapped, e.g., a MEG may cover a path segment of another MEG and may also include the forwarding engine(s) of the node(s) at the edge(s) of the path segment. However, when MEGs are nested, the MEPs and MIPs in the SPME are no longer part of the encompassing MEG.
o 它们可以嵌套但不重叠，例如，一个MEG可以覆盖另一个MEG的路径段，并且还可以包括路径段边缘的节点的转发引擎。但是，当MEG嵌套时，SPME中的MEP和MIP不再是包含MEG的一部分。
o It is possible that MEPs of MEGs that are nested reside on a single node but again are implemented in such a way that they do not overlap.
o 嵌套的MEG的MEP可能驻留在单个节点上，但其实现方式也可能不会重叠。
o Each OAM flow is associated with a single MEG.
o 每个OAM流与单个MEG关联。
o When an SPME is instantiated after the transport path has been instantiated, the TTL distance to the MIPs may change for the short-pipe model of TTL copying, and may change for the uniform model if the SPME is not co-routed with the original path.
o 当在传输路径被实例化之后实例化SPME时，对于TTL复制的短管模型，到MIPs的TTL距离可能会改变，如果SPME没有与原始路径共同路由，则对于统一模型，可能会改变。
MEG End Points (MEPs) are the source and sink points of a MEG. In the context of an MPLS-TP LSP, only LERs can implement MEPs, while in the context of an SPME, any LSR of the MPLS-TP LSP can be an LER of SPMEs that contributes to the overall monitoring infrastructure of the transport path. Regarding PWs, only T-PEs can implement MEPs; while for SPMEs supporting one or more PWs, both T-PEs and S-PEs can implement SPME MEPs. Any MPLS-TP LSR can implement a MEP for an MPLS-TP Section.
MEG端点（MEP）是MEG的源点和汇点。在MPLS-TP LSP的上下文中，只有LER可以实现MEP，而在SPME的上下文中，MPLS-TP LSP的任何LSR都可以是SPME的LER，这有助于传输路径的整体监控基础设施。关于PWs，只有T-PEs可以实施MEP；而对于支持一个或多个PWs的SPME，T-PEs和S-PEs都可以实现SPME MEP。任何MPLS-TP LSR都可以为MPLS-TP段实现MEP。
MEPs are responsible for originating almost all of the proactive and on-demand monitoring OAM functionality for the MEG. There is a separate class of notifications (such as Lock Report (LKR) and Alarm Indication Signal (AIS)) that are originated by intermediate nodes and triggered by server-layer events. A MEP is capable of originating and terminating OAM packets for fault management and performance monitoring. These OAM packets are carried within the Generic Associated Channel (G-ACh) with the proper encapsulation and an appropriate channel type as defined in RFC 5586 [7]. A MEP terminates all the OAM packets it receives from the MEG it belongs to and silently discards those that do not. (Note that in the particular case of Connectivity Verification (CV) processing, a CV packet from an incorrect MEG will result in a mis-connectivity defect and there are further actions taken.) The MEG the OAM packet belongs to is associated with the MPLS or PW label, whether the label is used to infer the MEG or the content of the OAM packet is an implementation choice. In the case of an MPLS-TP Section, the MEG is inferred from the port on which an OAM packet was received with the GAL at the top of the label stack.
MEP负责发起MEG的几乎所有主动式和按需监测OAM功能。有一类单独的通知（如锁报告（LKR）和报警指示信号（AIS）），由中间节点发起并由服务器层事件触发。MEP能够发起和终止用于故障管理和性能监视的OAM数据包。这些OAM数据包在通用关联信道（G-ACh）中携带，具有RFC 5586[7]中定义的适当封装和适当信道类型。MEP终止它从它所属的MEG接收的所有OAM数据包，并默默地丢弃那些不属于它的数据包。（注意，在连接验证（CV）处理的特殊情况下，来自不正确MEG的CV数据包将导致错误连接缺陷，并采取进一步措施。）OAM数据包所属的MEG与MPLS或PW标签关联，标签是否用于推断MEG或OAM数据包的内容是一种实现选择。在MPLS-TP部分的情况下，MEG是从接收OAM数据包的端口推断出来的，GAL位于标签堆栈的顶部。
OAM packets may require the use of an available "out-of-band" return path (as defined in [8]). In such cases, sufficient information is required in the originating transaction such that the OAM reply packet can be constructed and properly forwarded to the originating MEP (e.g., IP address).
OAM数据包可能需要使用可用的“带外”返回路径（定义见[8]）。在这种情况下，发起事务中需要足够的信息，以便可以构造OAM应答分组并将其正确地转发到发起MEP（例如，IP地址）。
Each OAM solution document will further detail the applicability of the tools it defines as a proactive or on-demand mechanism as well as its usage when:
每个OAM解决方案文档将进一步详细说明其定义为主动或按需机制的工具的适用性，以及在以下情况下的使用：
o The "in-band" return path exists and it is used.
o “带内”返回路径存在并被使用。
o An "out-of-band" return path exists and it is used.
o 存在并使用“带外”返回路径。
o Any return path does not exist or is not used.
o 任何返回路径都不存在或未使用。
Once a MEG is configured, the operator can configure which proactive OAM functions to use on the MEG, but the MEPs are always enabled.
配置MEG后，操作员可以配置在MEG上使用哪些主动OAM功能，但MEP始终处于启用状态。
MEPs terminate all OAM packets received from the associated MEG. As the MEP corresponds to the termination of the forwarding path for a MEG at the given (sub-)layer, OAM packets never leak outside of a MEG in a properly configured fault-free implementation.
MEP终止从相关MEG接收的所有OAM数据包。由于MEP对应于MEG在给定（子）层的转发路径的终止，因此在正确配置的无故障实现中，OAM数据包永远不会泄漏到MEG之外。
A MEP of an MPLS-TP transport path coincides with transport path termination and monitors it for failures or performance degradation (e.g., based on packet counts) in an end-to-end scope. Note that both the source MEP and sink MEP coincide with transport paths' source and sink terminations.
MPLS-TP传输路径的MEP与传输路径终止一致，并在端到端范围内监测其故障或性能下降（例如，基于数据包计数）。请注意，源MEP和汇MEP都与传输路径的源和汇终端重合。
The MEPs of an SPME are not necessarily coincident with the termination of the MPLS-TP transport path. They are used to monitor a path segment of the transport path for failures or performance degradation (e.g., based on packet counts) only within the boundary of the MEG for the SPME.
SPME的MEP不一定与MPLS-TP传输路径的终止一致。它们用于仅在SPME的MEG边界内监测传输路径的路径段是否出现故障或性能下降（例如，基于数据包计数）。
An MPLS-TP sink MEP passes a fault indication to its client (sub-)layer network as a consequent action of fault detection. When the client layer is not MPLS-TP, the consequent actions in the client layer (e.g., ignore or generate client-layer-specific OAM notifications) are outside the scope of this document.
MPLS-TP接收器MEP将故障指示传递给其客户端（子）层网络，作为故障检测的后续动作。当客户端层不是MPLS-TP时，客户端层中的后续操作（例如，忽略或生成特定于客户端层的OAM通知）不在本文档的范围内。
A node hosting a MEP can either support per-node MEP or per-interface MEP(s). A per-node MEP resides in an unspecified location within the node, while a per-interface MEP resides on a specific side of the forwarding engine. In particular, a per-interface MEP is called an "Up MEP" or a "Down MEP" depending on its location relative to the forwarding engine. An "Up MEP" transmits OAM packets towards, and receives them from, the direction of the forwarding engine, while a "Down MEP" receives OAM packets from, and transmits them towards, the direction of a server layer.
承载MEP的节点可以支持每个节点MEP或每个接口MEP。每节点MEP位于节点内的未指定位置，而每接口MEP位于转发引擎的特定一侧。具体而言，每个接口MEP被称为“Up-MEP”或“Down-MEP”，这取决于其相对于转发引擎的位置。“上行MEP”向转发引擎的方向发送OAM数据包，并从转发引擎的方向接收OAM数据包，而“下行MEP”从服务器层的方向接收OAM数据包，并向服务器层的方向发送OAM数据包。
Source node Up MEP Destination node Up MEP
------------------------ ------------------------
| | | |
|----- -----| |----- -----|
| MEP | | | | | | MEP |
| | ---- | | | | ---- | |
| In |->-| FW |->-| Out |->- ->-| In |->-| FW |->-| Out |
| i/f | ---- | i/f | | i/f | ---- | i/f |
|----- -----| |----- -----|
| | | |
------------------------ ------------------------
(1) (2)
Source node Up MEP Destination node Up MEP
------------------------ ------------------------
| | | |
|----- -----| |----- -----|
| MEP | | | | | | MEP |
| | ---- | | | | ---- | |
| In |->-| FW |->-| Out |->- ->-| In |->-| FW |->-| Out |
| i/f | ---- | i/f | | i/f | ---- | i/f |
|----- -----| |----- -----|
| | | |
------------------------ ------------------------
(1) (2)
Source node Down MEP Destination node Down MEP
------------------------ ------------------------
| | | |
|----- -----| |----- -----|
| | | MEP | | MEP | | |
| | ---- | | | | ---- | |
| In |->-| FW |->-| Out |->- ->-| In |->-| FW |->-| Out |
| i/f | ---- | i/f | | i/f | ---- | i/f |
|----- -----| |----- -----|
| | | |
------------------------ ------------------------
(3) (4)
Source node Down MEP Destination node Down MEP
------------------------ ------------------------
| | | |
|----- -----| |----- -----|
| | | MEP | | MEP | | |
| | ---- | | | | ---- | |
| In |->-| FW |->-| Out |->- ->-| In |->-| FW |->-| Out |
| i/f | ---- | i/f | | i/f | ---- | i/f |
|----- -----| |----- -----|
| | | |
------------------------ ------------------------
(3) (4)
Figure 3: Examples of Per-Interface MEPs
图3：每个接口MEP的示例
Figure 3 describes four examples of per-interface Up MEPs: an Up Source MEP in a source node (case 1), an Up Sink MEP in a destination node (case 2), a Down Source MEP in a source node (case 3), and a Down Sink MEP in a destination node (case 4).
图3描述了每个接口向上MEP的四个示例：源节点中的向上源MEP（案例1）、目标节点中的向上汇MEP（案例2）、源节点中的向下源MEP（案例3）和目标节点中的向下汇MEP（案例4）。
The usage of per-interface Up MEPs extends the coverage of the ME for both fault and performance monitoring closer to the edge of the domain and determines that the location of a failure or performance degradation is within a node or on a link between two adjacent nodes.
每个接口Up MEP的使用扩展了ME的覆盖范围，使故障和性能监控更接近域边缘，并确定故障或性能降级的位置在节点内或两个相邻节点之间的链路上。
Each OAM solution document will further detail the implications of the tools it defines when used with per-interface or per-node MEPs, if necessary.
如有必要，每个OAM解决方案文档将进一步详细说明它定义的工具在与每个接口或每个节点MEP一起使用时的含义。
It may occur that multiple MEPs for the same MEG are on the same node, and are all Up MEPs, each on one side of the forwarding engine, such that the MEG is entirely internal to the node.
可能会出现相同MEG的多个MEP位于同一节点上，并且都是Up MEP，每个MEP位于转发引擎的一侧，因此MEG完全位于节点内部。
It should be noted that an ME may span nodes that implement per-node MEPs and per-interface MEPs. This guarantees backward compatibility with most of the existing LSRs that can implement only a per-node MEP. In fact, in many current implementations, label operations are largely performed on the ingress interface; hence, the exposure of the GAL as top label will occur at the ingress interface.
应该注意，ME可以跨越实现每个节点MEP和每个接口MEP的节点。这保证了与大多数只能实现每节点MEP的现有LSR的向后兼容性。事实上，在许多当前实现中，标签操作主要在入口接口上执行；因此，GAL作为顶部标签的暴露将发生在入口接口处。
Note that a MEP can only exist at the beginning and end of a (sub-)layer in MPLS-TP. If there is a need to monitor some portion of that LSP or PW, a new sub-layer (in the form of an SPME) must be created that permits MEPs and associated MEGs to be created.
注意，在MPLS-TP中，MEP只能存在于（子）层的开始和结束处。如果需要监控LSP或PW的某些部分，则必须创建新的子层（以SPME的形式），以允许创建MEP和相关MEG。
In the case where an intermediate node sends an OAM packet to a MEP, it uses the top label of the stack at that point.
在中间节点向MEP发送OAM数据包的情况下，它在该点使用堆栈的顶部标签。
A MEG Intermediate Point (MIP) is a function located at a point between the MEPs of a MEG for a PW, LSP, or SPME.
MEG中间点（MIP）是位于PW、LSP或SPME的MEG的MEP之间的点上的函数。
A MIP is capable of reacting to some OAM packets and forwarding all the other OAM packets while ensuring fate-sharing with user data packets. However, a MIP does not initiate unsolicited OAM packets, but may be addressed by OAM packets initiated by one of the MEPs of the MEG. A MIP can generate OAM packets only in response to OAM packets that it receives from the MEG it belongs to. The OAM packets generated by the MIP are sent to the originating MEP.
MIP能够对一些OAM分组作出反应并转发所有其他OAM分组，同时确保与用户数据分组共享命运。然而，MIP不发起未经请求的OAM分组，而是可以由MEG的一个mep发起的OAM分组来寻址。MIP只能响应从其所属MEG接收的OAM数据包生成OAM数据包。由MIP生成的OAM分组被发送到发起MEP。
An intermediate node within a MEG can either:
MEG内的中间节点可以：
o support per-node MIPs (i.e., a single MIP per node in an unspecified location within the node); or
o 支持每个节点的MIP（即，节点内未指定位置的每个节点的单个MIP）；或
o support per-interface MIPs (i.e., two or more MIPs per node on both sides of the forwarding engine).
o 支持每个接口的MIPs（即，转发引擎两侧的每个节点有两个或多个MIPs）。
Support of per-interface or per-node MIPs is an implementation choice. It is also possible that a node could support per-interface MIPs on some MEGs and per-node MIPs on other MEGs for which it is a transit node.
支持每接口或每节点MIPs是一种实现选择。节点也可能支持某些MEG上的每个接口MIPs，以及作为传输节点的其他MEG上的每个节点MIPs。
Intermediate node
------------------------
| |
|----- -----|
| MIP | | MIP |
| | ---- | |
->-| In |->-| FW |->-| Out |->-
| i/f | ---- | i/f |
|----- -----|
| |
------------------------
Intermediate node
------------------------
| |
|----- -----|
| MIP | | MIP |
| | ---- | |
->-| In |->-| FW |->-| Out |->-
| i/f | ---- | i/f |
|----- -----|
| |
------------------------
Figure 4: Example of Per-Interface MIPs
图4：每个接口MIPs的示例
Figure 4 describes an example of two per-interface MIPs at an intermediate node of a point-to-point MEG.
图4描述了点到点MEG中间节点上两个每个接口MIP的示例。
Using per-interface MIPs allows the network operator to determine that the location of a failure or performance degradation is within a node or on a link between two adjacent nodes.
使用每个接口MIPs允许网络运营商确定故障或性能下降的位置在节点内或两个相邻节点之间的链路上。
When sending an OAM packet to a MIP, the source MEP should set the TTL field to indicate the number of hops necessary to reach the node where the MIP resides.
向MIP发送OAM数据包时，源MEP应设置TTL字段，以指示到达MIP所在节点所需的跳数。
The source MEP should also include target MIP information in the OAM packets sent to a MIP to allow proper identification of the MIP within the node. The MEG the OAM packet belongs to is associated with the MPLS label, whether the label is used to infer the MEG or the content of the OAM packet is an implementation choice. In the latter case, the MPLS label is checked to be the expected one.
源MEP还应在发送给MIP的OAM分组中包括目标MIP信息，以允许在节点内正确识别MIP。OAM分组所属的MEG与MPLS标签相关联，标签是用于推断MEG还是OAM分组的内容是一种实现选择。在后一种情况下，MPLS标签被检查为预期标签。
The use of TTL expiry to deliver OAM packets to a specific MIP is not a fully reliable delivery mechanism because the TTL distance of a MIP from a MEP can change. Any MPLS-TP node silently discards any OAM packet that is received with an expired TTL and that is not addressed to any of its MIPs or MEPs. An MPLS-TP node that does not support OAM is also expected to silently discard any received OAM packet.
使用TTL到期将OAM数据包传送到特定MIP并不是一种完全可靠的传送机制，因为MIP与MEP之间的TTL距离可能会改变。任何MPLS-TP节点都会以静默方式丢弃任何使用过期TTL接收的OAM数据包，并且该数据包不会发送到其任何MIP或MEP。不支持OAM的MPLS-TP节点也将静默地丢弃任何接收到的OAM数据包。
Packets directed to a MIP may not necessarily carry specific MIP identification information beyond that of TTL distance. In this case, a MIP would promiscuously respond to all MEP queries on its MEG. This capability could be used for discovery functions (e.g., route tracing as defined in Section 6.4) or when it is desirable to leave to the originating MEP the job of correlating TTL and MIP identifiers and noting changes or irregularities (via comparison with information previously extracted from the network).
定向到MIP的分组不一定携带超出TTL距离的特定MIP标识信息。在这种情况下，MIP将杂乱地响应MEP对其MEG的所有查询。该功能可用于发现功能（例如，第6.4节中定义的路由跟踪），或当需要将TTL和MIP标识符的相关工作留给始发MEP并记录更改或异常情况（通过与先前从网络中提取的信息进行比较）时。
MIPs are associated to the MEG they belong to, and their identity is unique within the MEG. However, their identity is not necessarily unique to the MEG, e.g., all nodal MIPs in a node can have a common identity.
MIP与它们所属的MEG关联，并且它们的身份在MEG中是唯一的。然而，它们的身份不一定是MEG独有的，例如，一个节点中的所有节点MIP都可以有一个共同的身份。
A node hosting a MEP can also support per-interface Up MEPs and per-interface MIPs on either side of the forwarding engine.
承载MEP的节点还可以在转发引擎的任一侧支持每个接口Up MEP和每个接口MIP。
Once a MEG is configured, the operator can enable/disable the MIPs on the nodes within the MEG. All the intermediate nodes and possibly the end nodes host MIP(s). Local policy allows them to be enabled per function and per MEG. The local policy is controlled by the management system, which may delegate it to the control plane. A disabled MIP silently discards any received OAM packets.
配置MEG后，操作员可以启用/禁用MEG内节点上的MIPs。所有中间节点和可能的终端节点承载MIP。本地策略允许每个功能和每个MEG启用它们。本地策略由管理系统控制，管理系统可将其委托给控制平面。禁用的MIP会自动丢弃任何接收到的OAM数据包。
A server MEP is a MEP of a MEG that is either:
服务器MEP是MEG的MEP，它是：
o defined in a layer network that is "below", which is to say encapsulates and transports the MPLS-TP layer network being referenced; or
o 在“以下”的层网络中定义，即封装和传输被引用的MPLS-TP层网络；或
o defined in a sub-layer of the MPLS-TP layer network that is "below", which is to say encapsulates and transports the sub-layer being referenced.
o 在MPLS-TP层网络的子层中定义，该子层位于“下方”，即封装和传输被引用的子层。
A server MEP can coincide with a MIP or a MEP in the client (MPLS-TP) (sub-)layer network.
服务器MEP可以与客户端（MPLS-TP）（子）层网络中的MIP或MEP一致。
A server MEP also provides server-layer OAM indications to the client/server adaptation function between the client (MPLS-TP) (sub-)layer network and the server (sub-)layer network. The adaptation function maintains state on the mapping of MPLS-TP transport paths that are set up over that server (sub-)layer's transport path.
服务器MEP还向客户机（MPLS-TP）（子）层网络和服务器（子）层网络之间的客户机/服务器适配功能提供服务器层OAM指示。自适应功能维护在该服务器（子）层传输路径上设置的MPLS-TP传输路径映射的状态。
For example, a server MEP can be:
例如，服务器MEP可以是：
o a non-MPLS MEP at a termination point of a physical link (e.g., 802.3, an SDH Virtual Circuit, or OTN Optical Data Unit (ODU)), for the MPLS-TP Section layer network, defined in Section 4.1;
o 物理链路（例如802.3、SDH虚拟电路或OTN光数据单元（ODU））终端点处的非MPLS MEP，用于MPLS-TP节层网络，如第4.1节所定义；
o an MPLS-TP Section MEP for MPLS-TP LSPs, defined in Section 4.2;
o 第4.2节中定义的MPLS-TP LSP的MPLS-TP段MEP；
o an MPLS-TP LSP MEP for MPLS-TP PWs, defined in Section 4.3;
o 第4.3节中定义的MPLS-TP PWs的MPLS-TP LSP MEP；
o an MPLS-TP SPME MEP used for LSP path segment monitoring, as defined in Section 4.4, for MPLS-TP LSPs or higher-level SPMEs providing LSP path segment monitoring; or
o 用于LSP路径段监控的MPLS-TP SPME MEP，如第4.4节所定义，用于提供LSP路径段监控的MPLS-TP LSP或更高级别的SPME；或
o an MPLS-TP SPME MEP used for PW path segment monitoring, as defined in Section 4.5, for MPLS-TP PWs or higher-level SPMEs providing PW path segment monitoring.
o 用于PW路径段监控的MPLS-TP SPME MEP，如第4.5节所定义，用于提供PW路径段监控的MPLS-TP PWs或更高级别的SPME。
The server MEP can run appropriate OAM functions for fault detection within the server (sub-)layer network and provides a fault indication to its client MPLS-TP layer network via the client/server adaptation function. When the server layer is not MPLS-TP, server MEP OAM functions are simply assumed to exist but are outside the scope of this document.
服务器MEP可以在服务器（子）层网络内运行适当的OAM功能进行故障检测，并通过客户机/服务器适配功能向其客户机MPLS-TP层网络提供故障指示。当服务器层不是MPLS-TP时，服务器MEP OAM功能只是假设存在，但不在本文档的范围内。
When a control plane is not present, the management plane configures these functional components. Otherwise, they can be configured by either the management plane or the control plane.
当控制平面不存在时，管理平面配置这些功能组件。否则，它们可以由管理平面或控制平面进行配置。
Local policy allows disabling the usage of any available "out-of-band" return path, as defined in [8], irrespective of what is requested by the node originating the OAM packet.
本地策略允许禁用[8]中定义的任何可用“带外”返回路径的使用，而不管发起OAM数据包的节点请求什么。
SPMEs are usually instantiated when the transport path is created by either the management plane or the control plane (if present). Sometimes an SPME can be instantiated after the transport path is initially created.
当管理平面或控制平面（如果存在）创建传输路径时，通常会实例化SPME。有时，可以在最初创建传输路径后实例化SPME。
All the traffic sent over a P2MP transport path, including OAM packets generated by a MEP, is sent (multicast) from the root to all the leaves. As a consequence:
通过P2MP传输路径发送的所有流量，包括MEP生成的OAM数据包，都从根节点发送（多播）到所有叶节点。因此：
o To send an OAM packet to all leaves, the source MEP can send a single OAM packet that will be delivered by the forwarding plane to all the leaves and processed by all the leaves. Hence, a single OAM packet can simultaneously instrument all the MEs in a P2MP MEG.
o 为了向所有叶发送OAM分组，源MEP可以发送单个OAM分组，该OAM分组将由转发平面传送到所有叶并由所有叶处理。因此，单个OAM数据包可以同时为P2MP MEG中的所有MEs提供仪表。
o To send an OAM packet to a single leaf, the source MEP sends a single OAM packet that will be delivered by the forwarding plane to all the leaves but contains sufficient information to identify a target leaf, and therefore is processed only by the target leaf and can be silently discarded by the other leaves.
o 为了将OAM分组发送到单个叶，源MEP发送单个OAM分组，该OAM分组将由转发平面发送到所有叶，但是包含足够的信息以识别目标叶，因此仅由目标叶处理，并且可以由其他叶无声地丢弃。
o To send an OAM packet to a single MIP, the source MEP sends a single OAM packet with the TTL field indicating the number of hops necessary to reach the node where the MIP resides. This packet will be delivered by the forwarding plane to all intermediate nodes at the same TTL distance of the target MIP and to any leaf that is located at a shorter distance. The OAM packet must contain sufficient information to identify the target MIP and therefore is processed only by the target MIP and can be silently discarded by the others.
o 为了向单个MIP发送OAM分组，源MEP发送单个OAM分组，其中TTL字段指示到达MIP驻留的节点所需的跳数。该分组将由转发平面传送到与目标MIP具有相同TTL距离的所有中间节点以及位于较短距离的任何叶。OAM数据包必须包含足够的信息来识别目标MIP，因此只能由目标MIP处理，并且可以被其他MIP默默地丢弃。
o In order to send an OAM packet to M leaves (i.e., a subset of all the leaves), the source MEP sends M different OAM packets targeted to each individual leaf in the group of M leaves. Aggregating or subsetting mechanisms are outside the scope of this document.
o 为了向M个叶（即，所有叶的子集）发送OAM分组，源MEP向M个叶组中的每个单独叶发送M个不同的OAM分组。聚合或子集机制不在本文档范围内。
A bud node with a Down MEP or a per-node MEP will both terminate and relay OAM packets. Similar to how fault coverage is maximized by the explicit utilization of Up MEPs, the same is true for MEPs on a bud node.
具有Down MEP或per node MEP的bud节点将终止并中继OAM数据包。与通过显式利用Up MEP使故障覆盖率最大化类似，bud节点上的MEP也是如此。
P2MP paths are unidirectional; therefore, any return path to an originating MEP for on-demand transactions will be out-of-band. A mechanism to target "on-demand" transactions to a single MEP or MIP is required as it relieves the originating MEP of an arbitrarily large processing load and of the requirement to filter and discard undesired responses. This is because normally TTL exhaustion will address all MIPs at a given distance from the source, and failure to exhaust TTL will address all MEPs.
P2MP路径是单向的；因此，对于按需事务，任何到原始MEP的返回路径都将是带外的。需要一种针对单个MEP或MIP的“按需”事务的机制，因为它减轻了原始MEP任意大的处理负载以及过滤和丢弃不需要的响应的要求。这是因为正常情况下，TTL耗尽将解决距源给定距离处的所有MIP，而未能耗尽TTL将解决所有MEP。
Segment monitoring, like any in-service monitoring, in a transport network should meet the following network objectives:
与任何在用监控一样，传输网络中的段监控应满足以下网络目标：
1. The monitoring and maintenance of existing transport paths has to be conducted in service without traffic disruption.
1. 现有运输路径的监测和维护必须在不中断交通的情况下进行。
2. Segment monitoring must not modify the forwarding of the segment portion of the transport path.
2. 段监控不得修改传输路径段部分的转发。
SPMEs defined in Section 3.2 meet the above two objectives, when they are pre-configured or pre-instantiated as exemplified in Section 3.6. However, sometimes pre-design and pre-configuration of all the considered patterns of SPME are not preferable in real operation due to the burden of design works, a number of header consumptions, bandwidth consumption, and so on.
第3.2节中定义的SPME在按照第3.6节中的示例进行预配置或预实例化时满足上述两个目标。然而，在实际操作中，由于设计工作的负担、大量的报头消耗、带宽消耗等原因，有时所有考虑的SPME模式的预设计和预配置并不可取。
When SPMEs are configured or instantiated after the transport path has been created, network objective (1) can be met: application and removal of SPME to a faultless monitored transport entity can be performed in such a way as not to introduce any loss of traffic, e.g., by using a non-disruptive "make before break" technique.
当在创建传输路径后配置或实例化SPME时，可以满足网络目标（1）：可以通过使用无中断的“先通后断”技术等方式，将SPME应用到无故障受监控的传输实体并将其移除，从而不会造成任何流量损失。
However, network objective (2) cannot be met due to new assignment of MPLS labels. As a consequence, generally speaking, the results of SPME monitoring are not necessarily correlated with the behavior of traffic in the monitored entity when it does not use SPME. For example, application of SPME to a problematic/faulty monitoring entity might "fix" the problem encountered by the latter -- for as long as SPME is applied. And vice versa, application of SPME to a faultless monitored entity may result in making it faulty -- again, as long as SPME is applied.
然而，由于MPLS标签的新分配，无法满足网络目标（2）。因此，一般来说，SPME监控的结果不一定与不使用SPME的被监控实体中的流量行为相关。例如，将SPME应用于有问题/有故障的监视实体可能“修复”后者遇到的问题——只要应用了SPME。反之亦然，将SPME应用于一个无故障的受监控实体可能会导致它出错——同样，只要应用了SPME。
Support for a more sophisticated segment-monitoring mechanism (temporal and hitless segment monitoring) to efficiently meet the two network objectives may be necessary.
可能需要支持更复杂的网段监控机制（临时和无故障网段监控），以有效满足两个网络目标。
One possible option to instantiate non-intrusive segment monitoring without the use of SPMEs would require the MIPs selected as monitoring end points to implement enhanced functionality and state for the monitored transport path.
在不使用SPME的情况下实例化非侵入性段监控的一个可能选项将要求选择MIP作为监控端点，以实现受监控传输路径的增强功能和状态。
For example, the MIPs need to be configured with the TTL distance to the peer or with the address of the peer, when out-of-band return paths are used.
例如，当使用带外返回路径时，MIPs需要配置到对等方的TTL距离或对等方的地址。
A further issue that would need to be considered is events that result in changing the TTL distance to the peer monitoring entity, such as protection events that may temporarily invalidate OAM information gleaned from the use of this technique.
需要考虑的另一个问题是导致改变到对等监视实体的TTL距离的事件，例如可能使通过使用该技术收集的OAM信息暂时失效的保护事件。
Further considerations on this technique are outside the scope of this document.
关于这项技术的进一步考虑超出了本文件的范围。
The reference model for the MPLS-TP OAM framework builds upon the concept of a MEG, and its associated MEPs and MIPs, to support the functional requirements specified in RFC 5860 [11].
MPLS-TP OAM框架的参考模型基于MEG及其相关MEP和MIP的概念，以支持RFC 5860[11]中规定的功能需求。
The following MPLS-TP MEGs are specified in this document:
本文件规定了以下MPLS-TP MEG：
o A Section Maintenance Entity Group (SMEG), allowing monitoring and management of MPLS-TP Sections (between MPLS LSRs).
o 段维护实体组（SMEG），允许监控和管理MPLS-TP段（MPLS LSR之间）。
o An LSP Maintenance Entity Group (LMEG), allowing monitoring and management of an end-to-end LSP (between LERs).
o LSP维护实体组（LMEG），允许监控和管理端到端LSP（LER之间）。
o A PW Maintenance Entity Group (PMEG), allowing monitoring and management of an end-to-end Single-Segment Pseudowire (SS-PW) or MS-PW (between T-PEs).
o PW维护实体组（PMEG），允许监控和管理端到端单段伪线（SS-PW）或MS-PW（T-PE之间）。
o An LSP SPME ME Group (LSMEG), allowing monitoring and management of an SPME (between a given pair of LERs and/or LSRs along an LSP).
o LSP SPME组（LSMEG），允许监控和管理SPME（在LSP上给定的一对LER和/或LSR之间）。
o A PW SPME ME Group (PSMEG), allowing monitoring and management of an SPME (between a given pair of T-PEs and/or S-PEs along an (MS-)PW).
o PW SPME组（PSMEG），允许监测和管理SPME（沿（MS-）PW的给定T-PE和/或S-PE对之间）。
The MEGs specified in this MPLS-TP OAM framework are compliant with the architecture framework for MPLS-TP [8] that includes both MS-PWs [4] and LSPs [1].
此MPLS-TP OAM框架中指定的MEG符合MPLS-TP[8]的体系结构框架，该框架包括MS PWs[4]和LSP[1]。
Hierarchical LSPs are also supported in the form of SPMEs. In this case, each LSP in the hierarchy is a different sub-layer network that can be monitored, independently from higher- and lower-level LSPs in the hierarchy, on an end-to-end basis (from LER to LER) by an SPME. It is possible to monitor a portion of a hierarchical LSP by instantiating a hierarchical SPME between any LERs/LSRs along the hierarchical LSP.
还以SPME的形式支持分层LSP。在这种情况下，层次结构中的每个LSP是一个不同的子层网络，可以由SPME在端到端的基础上（从LER到LER）独立于层次结构中的较高和较低级别LSP进行监控。通过实例化沿分层LSP的任何LER/LSR之间的分层SPME，可以监控分层LSP的一部分。
Native |<------------------ MS-PW1Z ---------------->| Native
Layer | | Layer
Service | |<LSP13>| |<-LSP3X->| |<LSPXZ>| | Service
(AC1) V V V V V V V V (AC2)
+----+ +---+ +----+ +----+ +---+ +----+
+----+ |T-PE| |LSR| |S-PE| |S-PE| |LSR| |T-PE| +----+
| | | 1 | | 2 | | 3 | | X | | Y | | Z | | |
| | | |=======| |=========| |=======| | | |
| CE1|--|.......PW13......|...PW3X..|......PWXZ.......|---|CE2 |
| | | |=======| |=========| |=======| | | |
| | | | | | | | | | | | | | | |
+----+ | | | | | | | | | | | | +----+
+----+ +---+ +----+ +----+ +---+ +----+
. . . .
| | | |
|<--- Domain 1 -->| |<--- Domain Z -->|
^----------------- PW1Z PMEG ----------------^
^--- PW13 PSMEG --^ ^--- PWXZ PSMEG --^
^-------^ ^-------^
LSP13 LMEG LSPXZ LMEG
^--^ ^--^ ^---------^ ^--^ ^--^
Sec12 Sec23 Sec3X SecXY SecYZ
SMEG SMEG SMEG SMEG SMEG
Native |<------------------ MS-PW1Z ---------------->| Native
Layer | | Layer
Service | |<LSP13>| |<-LSP3X->| |<LSPXZ>| | Service
(AC1) V V V V V V V V (AC2)
+----+ +---+ +----+ +----+ +---+ +----+
+----+ |T-PE| |LSR| |S-PE| |S-PE| |LSR| |T-PE| +----+
| | | 1 | | 2 | | 3 | | X | | Y | | Z | | |
| | | |=======| |=========| |=======| | | |
| CE1|--|.......PW13......|...PW3X..|......PWXZ.......|---|CE2 |
| | | |=======| |=========| |=======| | | |
| | | | | | | | | | | | | | | |
+----+ | | | | | | | | | | | | +----+
+----+ +---+ +----+ +----+ +---+ +----+
. . . .
| | | |
|<--- Domain 1 -->| |<--- Domain Z -->|
^----------------- PW1Z PMEG ----------------^
^--- PW13 PSMEG --^ ^--- PWXZ PSMEG --^
^-------^ ^-------^
LSP13 LMEG LSPXZ LMEG
^--^ ^--^ ^---------^ ^--^ ^--^
Sec12 Sec23 Sec3X SecXY SecYZ
SMEG SMEG SMEG SMEG SMEG
^---^ ME
^ MEP
==== LSP
.... PW
^---^ ME
^ MEP
==== LSP
.... PW
T-PE 1: Terminating Provider Edge 1 LSR 2: Label Switching Router 2 S-PE 3: Switching Provider Edge 3 S-PE X: Switching Provider Edge X LSR Y: Label Switching Router Y T-PE Z: Terminating Provider Edge Z
T-PE 1:端接提供程序边缘1 LSR 2:标签交换路由器2 S-PE 3:交换提供程序边缘3 S-PE X:交换提供程序边缘X LSR Y:标签交换路由器Y T-PE Z:端接提供程序边缘Z
Figure 5: Reference Model for the MPLS-TP OAM Framework
图5:MPLS-TP OAM框架的参考模型
Figure 5 depicts a high-level reference model for the MPLS-TP OAM framework. The figure depicts portions of two MPLS-TP-enabled network domains, Domain 1 and Domain Z. In Domain 1, T-PE 1 is adjacent to LSR 2 via the MPLS-TP Section Sec12, and LSR 2 is adjacent to S-PE 3 via the MPLS-TP Section Sec23. Similarly, in Domain Z, S-PE X is adjacent to LSR Y via the MPLS-TP Section SecXY, and LSR Y is adjacent to T-PE Z via the MPLS-TP Section SecYZ. In addition, S-PE 3 is adjacent to S-PE X via the MPLS-TP Section Sec3X.
图5描述了MPLS-TP OAM框架的高级参考模型。该图描述了两个启用MPLS TP的网络域（域1和域Z）的部分。在域1中，T-PE 1通过MPLS-TP部分Sec12与LSR 2相邻，LSR 2通过MPLS-TP部分Sec23与S-PE 3相邻。类似地，在域Z中，S-PE X通过MPLS-TP部分SecXY与LSR Y相邻，并且LSR Y通过MPLS-TP部分SecYZ与T-PE Z相邻。此外，S-PE 3通过MPLS-TP段Sec3X与S-PE X相邻。
Figure 5 also shows a bidirectional MS-PW (MS-PW1Z) between AC1 on T-PE1 and AC2 on T-PE Z. The MS-PW consists of three bidirectional PW path segments: 1) PW13 path segment between T-PE 1 and S-PE 3 via the bidirectional LSP13 LSP, 2) PW3X path segment between S-PE 3 and S-PE X via the bidirectional LSP3X LSP, and 3) PWXZ path segment between S-PE X and T-PE Z via the bidirectional LSPXZ LSP.
图5还显示了T-PE1上的AC1和T-PE Z上的AC2之间的双向MS-PW（MS-PW1Z）。MS-PW由三个双向PW路径段组成：1）T-PE 1和S-PE 3之间通过双向LSP13 LSP的PW13路径段，2）S-PE 3和S-PE X之间通过双向LSP3X LSP的PW3X路径段，以及3）通过双向LSPXZ LSP在S-PE X和T-PE Z之间的PWXZ路径段。
The MPLS-TP OAM procedures that apply to a MEG are expected to operate independently from procedures on other MEGs. Yet, this does not preclude that multiple MEGs may be affected simultaneously by the same network condition -- for example, a fiber cut event.
适用于MEG的MPLS-TP OAM程序预计将独立于其他MEG上的程序运行。然而，这并不排除多个MEG可能同时受到相同网络条件的影响——例如，光纤切断事件。
Note that there are no constraints imposed by this OAM framework on the number or type (P2P, P2MP, LSP, or PW), of MEGs that may be instantiated on a particular node. In particular, when looking at Figure 5, it should be possible to configure one or more MEPs on the same node if that node is the end point of one or more MEGs.
请注意，此OAM框架对可能在特定节点上实例化的MEG的数量或类型（P2P、P2MP、LSP或PW）没有任何限制。特别是，当查看图5时，如果同一节点是一个或多个MEG的端点，则应该可以在该节点上配置一个或多个MEP。
Figure 5 does not describe a PW3X PSMEG because typically SPMEs are used to monitor an OAM domain (like PW13 and PWXZ PSMEGs) rather than the segment between two OAM domains. However, the OAM framework does not pose any constraints on the way SPMEs are instantiated as long as they are not overlapping.
图5没有描述PW3X PSMEG，因为SPME通常用于监视OAM域（如PW13和PWXZ PSMEG），而不是两个OAM域之间的段。但是，OAM框架不会对SPME的实例化方式造成任何限制，只要它们不重叠。
The subsections below define the MEGs specified in this MPLS-TP OAM architecture framework document. Unless otherwise stated, all references to domains, LSRs, MPLS-TP Sections, LSPs, pseudowires, and MEGs in this section are made in relation to those shown in Figure 5.
下面的小节定义了本MPLS-TP OAM体系结构框架文档中指定的MEG。除非另有说明，本节中对域、LSR、MPLS-TP部分、LSP、伪线和MEG的所有引用均与图5中所示内容相关。
An MPLS-TP Section MEG (SMEG) is an MPLS-TP maintenance entity intended to monitor an MPLS-TP Section. An SMEG may be configured on any MPLS-TP section. SMEG OAM packets must fate-share with the user data packets sent over the monitored MPLS-TP Section.
MPLS-TP段MEG（SMEG）是一个MPLS-TP维护实体，用于监控MPLS-TP段。SMEG可以配置在任何MPLS-TP部分上。SMEG OAM数据包必须与通过受监控的MPLS-TP部分发送的用户数据包共享。
An SMEG is intended to be deployed for applications where it is preferable to monitor the link between topologically adjacent (next hop in this layer network) MPLS-TP LSRs rather than monitoring the individual LSP or PW path segments traversing the MPLS-TP Section and where the server-layer technology does not provide adequate OAM capabilities.
SMEG旨在部署在以下应用中：最好监视拓扑相邻（该层网络中的下一跳）MPLS-TP LSR之间的链路，而不是监视穿过MPLS-TP部分的单个LSP或PW路径段，并且服务器层技术不提供足够的OAM能力。
Figure 5 shows five Section MEGs configured in the network between AC1 and AC2:
图5显示了AC1和AC2之间网络中配置的五段MEG：
1. Sec12 MEG associated with the MPLS-TP Section between T-PE 1 and LSR 2,
1. Sec12 MEG与T-PE 1和LSR 2之间的MPLS-TP段相关，
2. Sec23 MEG associated with the MPLS-TP Section between LSR 2 and S-PE 3,
2. 与LSR 2和S-PE 3之间的MPLS-TP段相关的Sec23 MEG，
3. Sec3X MEG associated with the MPLS-TP Section between S-PE 3 and S-PE X,
3. 与S-PE 3和S-PE X之间的MPLS-TP段相关的Sec3X MEG，
4. SecXY MEG associated with the MPLS-TP Section between S-PE X and LSR Y, and
4. 与S-PE X和LSR Y之间的MPLS-TP段相关的SecXY MEG，以及
5. SecYZ MEG associated with the MPLS-TP Section between LSR Y and T-PE Z
5. 与LSR Y和T-PE Z之间的MPLS-TP段相关的SecYZ MEG
An MPLS-TP LSP MEG (LMEG) is an MPLS-TP maintenance entity group intended to monitor an end-to-end LSP between its LERs. An LMEG may be configured on any MPLS LSP. LMEG OAM packets must fate-share with user data packets sent over the monitored MPLS-TP LSP.
MPLS-TP LSP MEG（LMEG）是一个MPLS-TP维护实体组，旨在监控其LER之间的端到端LSP。可以在任何MPLS LSP上配置LMEG。LMEG OAM数据包必须与通过受监控的MPLS-TP LSP发送的用户数据包共享。
An LMEG is intended to be deployed in scenarios where it is desirable to monitor an entire LSP between its LERs, rather than, say, monitoring individual PWs.
LMEG旨在部署在需要监控其LER之间的整个LSP的场景中，而不是监控单个PW。
Figure 5 depicts two LMEGs configured in the network between AC1 and AC2: 1) the LSP13 LMEG between T-PE 1 and S-PE 3, and 2) the LSPXZ LMEG between S-PE X and T-PE Z. Note that the presence of a LSP3X LMEG in such a configuration is optional, and hence, not precluded by this framework. For instance, the network operator may prefer to monitor the MPLS-TP Section between the two LSRs rather than the individual LSPs.
图5描述了在AC1和AC2之间的网络中配置的两个LMEG:1）T-PE 1和S-PE 3之间的LSP13 LMEG，以及2）S-PE X和T-PE Z之间的LSPXZ LMEG。请注意，在这种配置中存在LSP3X LMEG是可选的，因此本框架不排除。例如，网络运营商可能更愿意监视两个lsr之间的MPLS-TP部分，而不是单个lsp。
An MPLS-TP PW MEG (PMEG) is an MPLS-TP maintenance entity intended to monitor a SS-PW or MS-PW between its T-PEs. A PMEG can be configured on any SS-PW or MS-PW. PMEG OAM packets must fate-share with the user data packets sent over the monitored PW.
MPLS-TP PW MEG（PMEG）是一个MPLS-TP维护实体，旨在监控其T-PE之间的SS-PW或MS-PW。可在任何SS-PW或MS-PW上配置PMEG。PMEG OAM数据包必须与通过受监控PW发送的用户数据包共享。
A PMEG is intended to be deployed in scenarios where it is desirable to monitor an entire PW between a pair of MPLS-TP-enabled T-PEs rather than monitoring the LSP that aggregates multiple PWs between PEs.
PMEG旨在部署在需要监控一对启用MPLS TP的T-PE之间的整个PW的场景中，而不是监控在PE之间聚合多个PW的LSP。
Figure 5 depicts an MS-PW (MS-PW1Z) consisting of three path segments (PW13, PW3X, and PWXZ) and its associated end-to-end PMEG (PW1Z PMEG).
图5描述了由三个路径段（PW13、PW3X和PWXZ）组成的MS-PW（MS-PW1Z）及其相关端到端PMEG（PW1Z PMEG）。
An MPLS-TP LSP SPME MEG (LSMEG) is an MPLS-TP SPME with an associated maintenance entity group intended to monitor an arbitrary part of an LSP between the MEPs instantiated for the SPME, independent from the end-to-end monitoring (LMEG). An LSMEG can monitor an LSP path segment, and it may also include the forwarding engine(s) of the node(s) at the edge(s) of the path segment.
MPLS-TP LSP SPME MEG（LSMEG）是一种MPLS-TP SPME，具有关联的维护实体组，用于监控为SPME实例化的MEP之间LSP的任意部分，独立于端到端监控（LMEG）。LSMEG可以监视LSP路径段，并且它还可以包括路径段边缘处的节点的转发引擎。
When an SPME is established between non-adjacent LSRs, the edges of the SPME become adjacent at the LSP sub-layer network and any LSR that was previously in between becomes an LSR for the SPME.
当在非相邻的LSR之间建立SPME时，SPME的边缘在LSP子层网络处变得相邻，并且先前处于其间的任何LSR成为SPME的LSR。
Multiple hierarchical LSMEGs can be configured on any LSP. LSMEG OAM packets must fate-share with the user data packets sent over the monitored LSP path segment.
可以在任何LSP上配置多个分层LSMEG。LSMEG OAM数据包必须与通过受监控LSP路径段发送的用户数据包共享。
A LSME can be defined between the following entities:
可以在以下实体之间定义LSME：
o The LER and LSR of a given LSP.
o 给定LSP的LER和LSR。
o Any two LSRs of a given LSP.
o 给定LSP的任意两个LSR。
An LSMEG is intended to be deployed in scenarios where it is preferable to monitor the behavior of a part of an LSP or set of LSPs rather than the entire LSP itself, for example, when there is a need to monitor a part of an LSP that extends beyond the administrative boundaries of an MPLS-TP-enabled administrative domain.
LSMEG旨在部署在以下场景中：例如，当需要监视扩展到启用MPLS TP的管理域的管理边界之外的LSP部分时，最好监视LSP的一部分或一组LSP的行为，而不是整个LSP本身。
|<-------------------- PW1Z ------------------->|
| |
| |<-------------LSP1Z LSP------------->| |
| |<-LSP13->| |<LSP3X>| |<-LSPXZ->| |
V V V V V V V V
+----+ +---+ +----+ +----+ +---+ +----+
+----+ | PE | |LSR| |DBN | |DBN | |LSR| | PE | +----+
| | | 1 | | 2 | | 3 | | X | | Y | | Z | | |
| |AC1| |=====================================| |AC2| |
| CE1|---|.....................PW1Z......................|---|CE2 |
| | | |=====================================| | | |
| | | | | | | | | | | | | | | |
+----+ | | | | | | | | | | | | +----+
+----+ +---+ +----+ +----+ +---+ +----+
. . . .
| | | |
|<---- Domain 1 --->| |<---- Domain Z --->|
|<-------------------- PW1Z ------------------->|
| |
| |<-------------LSP1Z LSP------------->| |
| |<-LSP13->| |<LSP3X>| |<-LSPXZ->| |
V V V V V V V V
+----+ +---+ +----+ +----+ +---+ +----+
+----+ | PE | |LSR| |DBN | |DBN | |LSR| | PE | +----+
| | | 1 | | 2 | | 3 | | X | | Y | | Z | | |
| |AC1| |=====================================| |AC2| |
| CE1|---|.....................PW1Z......................|---|CE2 |
| | | |=====================================| | | |
| | | | | | | | | | | | | | | |
+----+ | | | | | | | | | | | | +----+
+----+ +---+ +----+ +----+ +---+ +----+
. . . .
| | | |
|<---- Domain 1 --->| |<---- Domain Z --->|
^---------^ ^---------^
LSP13 LSMEG LSPXZ LSMEG
^-------------------------------------^
LSP1Z LMEG
^---------^ ^---------^
LSP13 LSMEG LSPXZ LSMEG
^-------------------------------------^
LSP1Z LMEG
DBN: Domain Border Node
域边界节点
PE 1: Provider Edge 1 LSR 2: Label Switching Router 2 DBN 3: Domain Border Node 3 DBN X: Domain Border Node X LSR Y: Label Switching Router Y PE Z: Provider Edge Z
PE 1:提供程序边缘1 LSR 2:标签交换路由器2 DBN 3:域边界节点3 DBN X:域边界节点X LSR Y:标签交换路由器Y PE Z:提供程序边缘Z
Figure 6: MPLS-TP LSP SPME MEG (LSMEG)
图6:MPLS-TP LSP SPME MEG（LSMEG）
Figure 6 depicts a variation of the reference model in Figure 5 where there is an end-to-end LSP (LSP1Z) between PE 1 and PE Z. LSP1Z consists of, at least, three LSP Concatenated Segments: LSP13, LSP3X, and LSPXZ. In this scenario, there are two separate LSMEGs configured to monitor the LSP1Z: 1) a LSMEG monitoring the LSP13 Concatenated Segment on Domain 1 (LSP13 LSMEG), and 2) a LSMEG monitoring the LSPXZ Concatenated Segment on Domain Z (LSPXZ LSMEG).
图6描述了图5中参考模型的变化，其中PE 1和PE Z之间存在端到端LSP（LSP1Z）。LSP1Z至少由三个LSP连接段组成：LSP13、LSP3X和LSPXZ。在此场景中，有两个单独的LSMEG配置用于监控LSP1Z：1）一个LSMEG监控域1上的LSP13连接段（LSP13 LSMEG），以及2）一个LSMEG监控域Z上的LSPXZ连接段（LSPXZ LSMEG）。
It is worth noticing that LSMEGs can coexist with the LMEG monitoring the end-to-end LSP and that LSMEG MEPs and LMEG MEPs can be coincident in the same node (e.g., PE 1 node supports both the LSP1Z LMEG MEP and the LSP13 LSMEG MEP).
值得注意的是，LSMEG可以与监控端到端LSP的LMEG共存，并且LSMEG MEP和LMEG MEP可以在同一节点中重合（例如，PE 1节点同时支持LSP1Z LMEG MEP和LSP13 LSMEG MEP）。
An MPLS-TP MS-PW SPME Monitoring MEG (PSMEG) is an MPLS-TP SPME with an associated maintenance entity group intended to monitor an arbitrary part of an MS-PW between the MEPs instantiated for the SPME, independently of the end-to-end monitoring (PMEG). A PSMEG can monitor a PW path segment, and it may also include the forwarding engine(s) of the node(s) at the edge(s) of the path segment. A PSMEG is no different than an SPME; it is simply named as such to discuss SPMEs specifically in a PW context.
MPLS-TP MS-PW SPME监控MEG（PSMEG）是一种MPLS-TP SPME，具有相关的维护实体组，用于监控为SPME实例化的MEP之间MS-PW的任意部分，独立于端到端监控（PMEG）。PSMEG可以监视PW路径段，并且它还可以包括路径段边缘处的节点的转发引擎。PSMEG与SPME没有区别；在PW上下文中专门讨论SPME就是这样命名的。
When SPME is established between non-adjacent S-PEs, the edges of the SPME become adjacent at the MS-PW sub-layer network, and any S-PE that was previously in between becomes an LSR for the SPME.
当在非相邻的S-PE之间建立SPME时，SPME的边缘在MS-PW子层网络处变得相邻，并且先前处于其间的任何S-PE成为SPME的LSR。
S-PE placement is typically dictated by considerations other than OAM. S-PEs will frequently reside at operational boundaries such as the transition from distributed control plane (CP) to centralized Network Management System (NMS) control or at a routing area boundary. As such, the architecture would appear not to have the flexibility that arbitrary placement of SPME segments would imply. Support for an arbitrary placement of PSMEG would require the definition of additional PW sub-layering. Multiple hierarchical PSMEGs can be configured on any MS-PW. PSMEG OAM packets fate-share with the user data packets sent over the monitored PW path Segment.
S-PE安置通常由OAM以外的考虑因素决定。S-PEs通常位于操作边界，如从分布式控制平面（CP）到集中式网络管理系统（NMS）控制的过渡，或位于路由区域边界。因此，架构似乎没有SPME段的任意放置所暗示的灵活性。支持PSMEG的任意放置需要定义额外的PW子层。可在任何MS-PW上配置多个分层PSMEG。PSMEG OAM数据包命运与通过受监控PW路径段发送的用户数据包共享。
A PSMEG does not add hierarchical components to the MPLS architecture; it defines the role of existing components for the purposes of discussing OAM functionality.
PSMEG不向MPLS体系结构添加分层组件；为了讨论OAM功能，它定义了现有组件的角色。
A PSME can be defined between the following entities:
PSME可以在以下实体之间定义：
o The T-PE and any S-PE of a given MS-PW.
o 给定MS-PW的T-PE和任何S-PE。
o Any two S-PEs of a given MS-PW.
o 给定MS-PW的任意两个S-PE。
Note that, in line with the SPME description in Section 3.2, when a PW SPME is instantiated after the MS-PW has been instantiated, the TTL distance of the MIPs may change and MIPs in the PW SPME are no longer part of the encompassing MEG. This means that the S-PE nodes hosting these MIPs are no longer S-PEs but P nodes at the SPME LSP level. The consequences are that the S-PEs hosting the PSMEG MEPs become adjacent S-PEs. This is no different than the operation of SPMEs in general.
注意，根据第3.2节中的SPME描述，当在MS-PW实例化后实例化PW SPME时，MIP的TTL距离可能会改变，PW SPME中的MIP不再是包围MEG的一部分。这意味着承载这些MIP的S-PE节点不再是S-PE，而是SPME LSP级别的P节点。其结果是，承载PSMEG MEP的S-PE成为相邻的S-PE。这与一般SPME的操作没有什么不同。
A PSMEG is intended to be deployed in scenarios where it is preferable to monitor the behavior of a part of an MS-PW rather than the entire end-to-end PW itself, for example, when monitoring an MS-
PSMEG旨在部署在以下场景中：例如，当监控MS时，最好监控MS-PW的一部分而不是整个端到端PW本身的行为-
PW path segment within a given network domain of an inter-domain MS-PW.
域间MS-PW的给定网络域内的PW路径段。
Figure 5 depicts an MS-PW (MS-PW1Z) consisting of three path segments: PW13, PW3X, and PWXZ with two separate PSMEGs: 1) a PSMEG monitoring the PW13 MS-PW path segment on Domain 1 (PW13 PSMEG) and 2) a PSMEG monitoring the PWXZ MS-PW path segment on Domain Z with (PWXZ PSMEG).
图5描述了一个MS-PW（MS-PW1Z）由三个路径段组成：PW13、PW3X和PWXZ，带有两个单独的PSMEG：1）一个PSMEG监测域1上的PW13 MS-PW路径段（PW13 PSMEG），2）一个PSMEG监测域Z上的PWXZ MS-PW路径段（PWXZ PSMEG）。
It is worth noticing that PSMEGs can coexist with the PMEG monitoring the end-to-end MS-PW and that PSMEG MEPs and PMEG MEPs can be coincident in the same node (e.g., T-PE 1 node supports both the PW1Z PMEG MEP and the PW13 PSMEG MEP).
值得注意的是，PSMEG可以与监控端到端MS-PW的PMEG共存，并且PSMEG MEP和PMEG MEP可以在同一节点中重合（例如，T-PE 1节点同时支持PW1Z PMEG MEP和PW13 PSMEG MEP）。
Multilink techniques are in use today and are expected to continue to be used in future deployments. These techniques include Ethernet link aggregation [22] and the use of link bundling for MPLS [18] where the option to spread traffic over component links is supported and enabled. While the use of link bundling can be controlled at the MPLS-TP layer, use of link aggregation (or any server-layer-specific multilink) is not necessarily under the control of the MPLS-TP layer. Other techniques may emerge in the future. These techniques frequently share the characteristic that an LSP may be spread over a set of component links and therefore be reordered, but no flow within the LSP is reordered (except when very infrequent and minimally disruptive load rebalancing occurs).
目前正在使用多链路技术，并有望在未来的部署中继续使用。这些技术包括以太网链路聚合[22]和MPLS链路捆绑的使用[18]，其中支持并启用了在组件链路上分散流量的选项。虽然可以在MPLS-TP层控制链路捆绑的使用，但链路聚合（或任何特定于服务器层的多链路）的使用不一定受MPLS-TP层的控制。未来可能会出现其他技术。这些技术通常具有这样的特征：LSP可以分布在一组组件链路上，因此可以重新排序，但LSP内的流不会重新排序（除非发生极不频繁且破坏性最小的负载重新平衡）。
The use of multilink techniques may be prohibited or permitted in any particular deployment. If multilink techniques are used, the deployment can be considered to be only partially MPLS-TP compliant; however, this is unlikely to prevent their use.
在任何特定部署中都可能禁止或允许使用多链路技术。如果使用多链路技术，则可以认为部署仅部分符合MPLS-TP；然而，这不太可能阻止它们的使用。
The implications for OAM are that not all components of a multilink will be exercised, independent server-layer OAM being required to exercise the aggregated link components. This has further implications for MIP and MEP placement, as per-interface MIPs or Down MEPs on a multilink interface are akin to a layer violation, as they instrument at the granularity of the server layer. The implications for reduced OAM loss measurement functionality are documented in Sections 5.5.3 and 6.2.3.
OAM的含义是，不会执行多链路的所有组件，需要独立的服务器层OAM来执行聚合链路组件。这对MIP和MEP的放置有进一步的影响，因为多链路接口上的MIP或Down MEP类似于层冲突，因为它们在服务器层的粒度上起作用。第5.5.3节和第6.2.3节记录了降低OAM损耗测量功能的影响。
In this document, proactive monitoring refers to OAM operations that are either configured to be carried out periodically and continuously or preconfigured to act on certain events such as alarm signals.
在本文档中，主动式监视指的是OAM操作，这些操作被配置为定期、连续地执行，或者预配置为对某些事件（如报警信号）采取行动。
Proactive monitoring is usually performed "in-service". Such transactions are universally MEP to MEP in operation, while notifications can be node to node (e.g., some MS-PW transactions) or node to MEPs (e.g., AIS). The control and measurement considerations are:
主动监控通常在“服务中”执行。此类事务普遍为运行中的MEP对MEP，而通知可以是节点对节点（例如，一些MS-PW事务）或节点对MEP（例如，AIS）。控制和测量注意事项包括：
1. Proactive monitoring for a MEG is typically configured at the creation time of the transport path.
1. MEG的主动监控通常在传输路径创建时配置。
2. The operational characteristics of in-band measurement transactions (e.g., CV, Loss Measurement (LM), etc.) are configured at the MEPs.
2. 带内测量事务（例如CV、损耗测量（LM）等）的操作特征在MEP中配置。
3. Server-layer events are reported by OAM packets originating at intermediate nodes.
3. 服务器层事件由源自中间节点的OAM数据包报告。
4. The measurements resulting from proactive monitoring are typically reported outside of the MEG (e.g., to a management system) as notification events such as faults or indications of performance degradations (such as signal degrade conditions).
4. 主动监测产生的测量通常作为通知事件报告在MEG外部（例如，报告给管理系统），如故障或性能下降指示（如信号下降条件）。
5. The measurements resulting from proactive monitoring may be periodically harvested by an NMS.
5. 主动监测产生的测量值可由NMS定期采集。
Proactive fault reporting is assumed to be subject to unreliable delivery and soft-state, and it needs to operate in cases where a return path is not available or faulty. Therefore, periodic repetition is assumed to be used for reliability, instead of handshaking.
主动故障报告被认为是不可靠的交付和软状态，它需要在返回路径不可用或出现故障的情况下运行。因此，假设周期性重复用于可靠性，而不是握手。
Delay measurement also requires periodic repetition to allow estimation of the packet delay variation for the MEG.
延迟测量还需要周期性重复，以允许估计MEG的分组延迟变化。
For statically provisioned transport paths, the above information is statically configured; for dynamically established transport paths, the configuration information is signaled via the control plane or configured via the management plane.
对于静态配置的传输路径，静态配置上述信息；对于动态建立的传输路径，配置信息通过控制平面发出信号或通过管理平面进行配置。
The operator may enable/disable some of the consequent actions defined in Section 5.1.2.
操作员可启用/禁用第5.1.2节中定义的某些后续操作。
Proactive Continuity Check functions, as required in Section 2.2.2 of RFC 5860 [11], are used to detect a loss of continuity (LOC) defect between two MEPs in a MEG.
RFC 5860[11]第2.2.2节要求的主动连续性检查功能用于检测MEG中两个MEP之间的连续性丧失（LOC）缺陷。
Proactive Connectivity Verification functions, as required in Section 2.2.3 of RFC 5860 [11], are used to detect an unexpected connectivity defect between two MEGs (e.g., mismerging or misconnection), as well as unexpected connectivity within the MEG with an unexpected MEP.
RFC 5860[11]第2.2.3节中要求的主动连接验证功能用于检测两个MEG之间的意外连接缺陷（例如，错误合并或错误连接），以及具有意外MEP的MEG内的意外连接。
Both functions are based on the (proactive) generation, at the same rate, of OAM packets by the source MEP that are processed by the peer sink MEP(s). As a consequence, in order to save OAM bandwidth consumption, CV, when used, is linked with CC into Continuity Check and Connectivity Verification (CC-V) OAM packets.
这两个功能都基于源MEP以相同速率（主动）生成由对等接收器MEP处理的OAM数据包。因此，为了节省OAM带宽消耗，CV在使用时与CC链接到连续性检查和连接验证（CC-V）OAM数据包中。
In order to perform proactive Connectivity Verification, each CC-V OAM packet also includes a globally unique Source MEP identifier, whose value needs to be configured on the source MEP and on the peer sink MEP(s). In some cases, to avoid the need to configure the globally unique Source MEP identifier, it is preferable to perform only proactive Continuity Check. In this case, the CC-V OAM packet does not need to include any globally unique Source MEP identifier. Therefore, a MEG can be monitored only for CC or for both CC and CV. CC-V OAM packets used for CC-only monitoring are called CC OAM packets, while CC-V OAM packets used for both CC and CV are called CV OAM packets.
为了执行主动连接验证，每个CC-V OAM数据包还包括一个全局唯一的源MEP标识符，需要在源MEP和对等接收器MEP上配置其值。在某些情况下，为了避免需要配置全局唯一的源MEP标识符，最好只执行主动连续性检查。在这种情况下，CC-voam分组不需要包括任何全局唯一的源MEP标识符。因此，MEG只能监测CC或CC和CV。仅用于CC监控的CC-V OAM数据包称为CC OAM数据包，而同时用于CC和CV的CC-V OAM数据包称为CV OAM数据包。
As a consequence, it is not possible to detect misconnections between two MEGs monitored only for continuity as neither the OAM packet type nor the OAM packet content provides sufficient information to disambiguate an invalid source. To expand:
因此，由于OAM数据包类型和OAM数据包内容均未提供足够的信息来消除无效源的歧义，因此无法检测仅为连续性而监控的两个MEG之间的错误连接。要扩展：
o For a CC OAM packet leaking into a CC monitored MEG - undetectable.
o 对于CC OAM数据包泄漏到CC监控的MEG-不可检测。
o For a CV OAM packet leaking into a CC monitored MEG - reception of CV OAM packets instead of a CC OAM packets (e.g., with the additional Source MEP identifier) allows detecting the fault.
o 对于泄漏到CC监控MEG中的CV OAM数据包，接收CV OAM数据包而不是CC OAM数据包（例如，使用附加源MEP标识符）可检测故障。
o For a CC OAM packet leaking into a CV monitored MEG - reception of CC OAM packets instead of CV OAM packets (e.g., lack of additional Source MEP identifier) allows detecting the fault.
o 对于泄漏到CV监控MEG中的CC OAM数据包，接收CC OAM数据包而不是CV OAM数据包（例如，缺少额外的源MEP标识符）允许检测故障。
o For a CV OAM packet leaking into a CV monitored MEG - reception of CV OAM packets with different Source MEP identifier permits fault to be identified.
o 对于泄漏到CV监控MEG中的CV OAM数据包，接收具有不同源MEP标识符的CV OAM数据包允许识别故障。
Having a common packet format for CC-V OAM packets would simplify parsing in a sink MEP to properly detect all the misconfiguration cases described above.
为CC-voam数据包提供一种通用的数据包格式将简化sink-MEP中的解析，从而正确地检测上述所有错误配置情况。
MPLS-TP OAM supports different formats of MEP identifiers to address different environments. When an alternative to IP addressing is desired (e.g., MPLS-TP is deployed in transport network environments where consistent operations with other transport technologies defined by the ITU-T are required), the ITU Carrier Code (ICC)-based format for MEP identification is used: this format is under definition in [25]. When MPLS-TP is deployed in an environment where IP capabilities are available and desired for OAM, the IP-based MEP identification is used: this format is described in [24].
MPLS-TP OAM支持不同格式的MEP标识符，以解决不同的环境。当需要IP寻址的替代方案时（例如，MPLS-TP部署在需要与ITU-T定义的其他传输技术一致操作的传输网络环境中），使用基于ITU载波代码（ICC）的MEP识别格式：该格式在[25]中定义。当MPLS-TP部署在IP能力可用且OAM需要的环境中时，使用基于IP的MEP标识：该格式在[24]中描述。
CC-V OAM packets are transmitted at a regular, operator-configurable rate. The default CC-V transmission periods are application dependent (see Section 5.1.3).
CC-V OAM数据包以常规的、操作员可配置的速率传输。默认CC-V传输周期取决于应用（见第5.1.3节）。
Proactive CC-V OAM packets are transmitted with the "minimum loss probability PHB" within the transport path (LSP, PW) they are monitoring. For E-LSPs, this PHB is configurable on the network operator's basis, while for L-LSPs this is determined as per RFC 3270 [23]. PHBs can be translated at the network borders by the same function that translates them for user data traffic. The implication is that CC-V fate-shares with much of the forwarding implementation, but not all aspects of PHB processing are exercised. Either on-demand tools are used for finer-grained fault finding or an implementation may utilize a CC-V flow per PHB to ensure a CC-V flow fate-shares with each individual PHB.
主动CC-V OAM数据包在其监视的传输路径（LSP、PW）内以“最小丢失概率PHB”进行传输。对于E-LSP，该PHB可在网络运营商的基础上进行配置，而对于L-LSP，则根据RFC 3270[23]确定。PHB可以通过为用户数据流量转换PHB的相同功能在网络边界进行转换。这意味着CC-V命运与大部分转发实现共享，但并非PHB处理的所有方面都被执行。按需工具用于更细粒度的故障查找，或者实现可以利用每个PHB的CC-V流，以确保CC-V流命运与每个PHB共享。
In a co-routed or associated, bidirectional point-to-point transport path, when a MEP is enabled to generate proactive CC-V OAM packets with a configured transmission rate, it also expects to receive proactive CC-V OAM packets from its peer MEP at the same transmission rate. This is because a common SLA applies to all components of the transport path. In a unidirectional transport path (either point-to-point or point-to-multipoint), the source MEP is enabled only to generate CC-V OAM packets, while each sink MEP is configured to expect these packets at the configured rate.
在共同路由或相关联的双向点到点传输路径中，当MEP能够以配置的传输速率生成主动CC-V OAM分组时，它还期望以相同的传输速率从其对等MEP接收主动CC-V OAM分组。这是因为公共SLA适用于传输路径的所有组件。在单向传输路径（点对点或点对多点）中，源MEP仅被启用以生成CC-V OAM数据包，而每个接收器MEP被配置为以配置的速率期望这些数据包。
MIPs, as well as intermediate nodes not supporting MPLS-TP OAM, are transparent to the proactive CC-V information and forward these proactive CC-V OAM packets as regular data packets.
MIPs以及不支持MPLS-TP OAM的中间节点对主动CC-V信息是透明的，并将这些主动CC-V OAM数据包作为常规数据包转发。
During path setup and tear down, situations arise where CC-V checks would give rise to alarms, as the path is not fully instantiated. In order to avoid these spurious alarms, the following procedures are recommended. At initialization, the source MEP function (generating
在路径设置和拆除过程中，由于路径未完全实例化，出现CC-V检查会引起警报的情况。为了避免这些虚假警报，建议采用以下步骤。初始化时，源MEP函数（生成
proactive CC-V packets) should be enabled prior to the corresponding sink MEP function (detecting continuity and connectivity defects). When disabling the CC-V proactive functionality, the sink MEP function should be disabled prior to the corresponding source MEP function.
主动CC-V数据包）应在相应的接收器MEP功能（检测连续性和连接缺陷）之前启用。禁用CC-V主动功能时，应先禁用接收器MEP功能，然后再禁用相应的源MEP功能。
It should be noted that different encapsulations are possible for CC-V packets, and therefore it is possible that in case of misconfigurations or mis-connectivity, CC-V packets are received with an unexpected encapsulation.
应该注意的是，对于CC-V分组可能有不同的封装，因此，在配置错误或连接错误的情况下，接收CC-V分组时可能会出现意外的封装。
There are practical limitations to detecting unexpected encapsulation. It is possible that there are misconfiguration or mis-connectivity scenarios where OAM packets can alias as payload, e.g., when a transport path can carry an arbitrary payload without a pseudowire.
检测意外封装存在实际限制。可能存在配置错误或连接错误的情况，其中OAM数据包可以别名为有效负载，例如，当传输路径可以在没有伪线的情况下承载任意有效负载时。
When CC-V packets are received with an unexpected encapsulation that can be parsed by a sink MEP, the CC-V packet is processed as if it were received with the correct encapsulation. If it is not a manifestation of a mis-connectivity defect, a warning is raised (see Section 5.1.1.4). Otherwise, the CC-V packet may be silently discarded as unrecognized and a LOC defect may be detected (see Section 5.1.1.1).
当接收到的CC-V数据包具有可由接收器MEP解析的意外封装时，CC-V数据包将被处理为具有正确封装的数据包。如果不是mis连接缺陷的表现，则发出警告（见第5.1.1.4节）。否则，CC-V数据包可能会被视为未被识别而悄悄丢弃，并且可能会检测到LOC缺陷（见第5.1.1.1节）。
The defect conditions are described in no specific order.
缺陷条件未按特定顺序描述。
Proactive CC-V functions allow a sink MEP to detect the defect conditions described in the following subsections. For all of the described defect cases, a sink MEP should notify the equipment fault management process of the detected defect.
主动CC-V功能允许接收器MEP检测以下小节中描述的缺陷条件。对于所有描述的缺陷情况，接收器MEP应将检测到的缺陷通知设备故障管理流程。
Sequential consecutive loss of CC-V packets is considered indicative of an actual break and not of congestive loss or physical-layer degradation. The loss of 3 packets in a row (implying a detection interval that is 3.5 times the insertion time) is interpreted as a true break and a condition that will not clear by itself.
CC-V数据包的连续丢失被认为是实际中断的指示，而不是拥塞性丢失或物理层退化的指示。一行丢失3个数据包（意味着检测间隔是插入时间的3.5倍）被解释为真正的中断和自身无法清除的情况。
A CC-V OAM packet is considered to carry an unexpected globally unique Source MEP identifier if it is a CC OAM packet received by a sink MEP monitoring the MEG for CV; it is a CV OAM packet received by a sink MEP monitoring the MEG for CC, or it is a CV OAM packet received by a sink MEP monitoring the MEG for CV but carrying a unique Source MEP identifier that is different that the expected one. Conversely, the CC-V packet is considered to have an expected globally unique Source MEP identifier; it is a CC OAM packet received
如果CC-V OAM分组是由监视MEG的CV的接收器MEP接收的CC-OAM分组，则认为该CC-V OAM分组携带意外的全局唯一源MEP标识符；它是由监控MEG for CC的接收器MEP接收的CV OAM数据包，或者是由监控MEG for CV的接收器MEP接收的CV OAM数据包，但带有与预期不同的唯一源MEP标识符。相反，CC-V分组被认为具有期望的全局唯一源MEP标识符；它是接收到的CC OAM数据包
by a sink MEP monitoring the MEG for CC, or it is a CV OAM packet received by a sink MEP monitoring the MEG for CV and carrying a unique Source MEP identifier that is equal to the expected one.
由监控MEG for CC的接收端MEP接收，或者是由监控MEG for CV的接收端MEP接收的CV OAM数据包，该数据包带有与预期相同的唯一源MEP标识符。
When proactive CC-V is enabled, a sink MEP detects a loss of continuity (LOC) defect when it fails to receive proactive CC-V OAM packets from the source MEP.
启用主动CC-V时，当接收端MEP无法从源MEP接收主动CC-V OAM数据包时，接收端MEP会检测到连续性丢失（LOC）缺陷。
o Entry criteria: If no proactive CC-V OAM packets from the source MEP (and in the case of CV, this includes the requirement to have the expected globally unique Source MEP identifier) are received within the interval equal to 3.5 times the receiving MEP's configured CC-V reception period.
o 进入标准：如果在等于接收MEP配置的CC-V接收周期3.5倍的间隔内，未收到来自源MEP的主动CC-V OAM数据包（对于CV，这包括要求具有预期的全局唯一源MEP标识符）。
o Exit criteria: A proactive CC-V OAM packet from the source MEP (and again in the case of CV, with the expected globally unique Source MEP identifier) is received.
o 退出标准：从源MEP接收到主动CC-V OAM数据包（对于CV，同样具有预期的全局唯一源MEP标识符）。
When a proactive CC-V OAM packet is received, a sink MEP identifies a mis-connectivity defect (e.g., mismerge, misconnection, or unintended looping) when the received packet carries an unexpected globally unique Source MEP identifier.
当接收到主动CC-V OAM数据包时，当接收到的数据包携带意外的全局唯一源MEP标识符时，接收器MEP识别错误连接缺陷（例如，错误合并、错误连接或意外循环）。
o Entry criteria: The sink MEP receives a proactive CC-V OAM packet with an unexpected globally unique Source MEP identifier or with an unexpected encapsulation.
o 进入条件：接收器MEP接收具有意外全局唯一源MEP标识符或具有意外封装的主动CC-V OAM数据包。
o Exit criteria: The sink MEP does not receive any proactive CC-V OAM packet with an unexpected globally unique Source MEP identifier for an interval equal at least to 3.5 times the longest transmission period of the proactive CC-V OAM packets received with an unexpected globally unique Source MEP identifier since this defect has been raised. This requires the OAM packet to self-identify the CC-V periodicity, as not all MEPs can be expected to have knowledge of all MEGs.
o 退出标准：自出现此缺陷以来，接收器MEP在至少等于使用意外全局唯一源MEP标识符接收的主动CC-V OAM数据包的最长传输周期3.5倍的时间间隔内，未接收到任何具有意外全局唯一源MEP标识符的主动CC-V OAM数据包。这要求OAM数据包自识别CC-V周期性，因为并非所有MEP都知道所有MEG。
If proactive CC-V OAM packets are received with the expected globally unique Source MEP identifier but with a transmission period different than the locally configured reception period, then a CC-V period misconfiguration defect is detected.
如果接收到具有预期全局唯一源MEP标识符但传输周期不同于本地配置的接收周期的主动CC-V OAM分组，则检测到CC-V周期错误配置缺陷。
o Entry criteria: A MEP receives a CC-V proactive packet with the expected globally unique Source MEP identifier but with a transmission period different than its own CC-V-configured transmission period.
o 进入标准：MEP接收具有预期全局唯一源MEP标识符但传输周期不同于其自己的CC-V配置传输周期的CC-V主动数据包。
o Exit criteria: The sink MEP does not receive any proactive CC-V OAM packet with the expected globally unique Source MEP identifier and an incorrect transmission period for an interval equal at least to 3.5 times the longest transmission period of the proactive CC-V OAM packets received with the expected globally unique Source MEP identifier and an incorrect transmission period since this defect has been raised.
o 退出标准：接收器MEP不接收任何具有预期全局唯一源MEP标识符和错误传输周期的主动CC-V OAM数据包，其间隔至少等于使用预期全局唯一源MEP标识符和错误消息接收的主动CC-V OAM数据包的最长传输周期的3.5倍出现此缺陷后，传输周期不正确。
If proactive CC-V OAM packets are received with the expected globally unique Source MEP identifier but with an unexpected encapsulation, then a CC-V unexpected encapsulation defect is detected.
如果接收到具有预期全局唯一源MEP标识符但具有意外封装的主动CC-V OAM数据包，则检测到CC-V意外封装缺陷。
It should be noted that there are practical limitations to detecting unexpected encapsulation (see Section 5.1.1).
应注意，检测意外封装存在实际限制（见第5.1.1节）。
o Entry criteria: A MEP receives a CC-V proactive packet with the expected globally unique Source MEP identifier but with an unexpected encapsulation.
o 进入条件：MEP接收具有预期全局唯一源MEP标识符但具有意外封装的CC-V主动数据包。
o Exit criteria: The sink MEP does not receive any proactive CC-V OAM packet with the expected globally unique Source MEP identifier and an unexpected encapsulation for an interval equal at least to 3.5 times the longest transmission period of the proactive CC-V OAM packets received with the expected globally unique Source MEP identifier and an unexpected encapsulation since this defect has been raised.
o 退出标准：接收器MEP不接收任何具有预期全局唯一源MEP标识符和意外封装的主动CC-V OAM数据包，其间隔至少等于使用预期全局唯一源MEP标识符接收的主动CC-V OAM数据包的最长传输周期的3.5倍出现此缺陷后出现意外的封装。
A sink MEP that detects any of the defect conditions defined in Section 5.1.1 declares a defect condition and performs the following consequent actions.
检测到第5.1.1节中定义的任何缺陷条件的接收器MEP宣布缺陷条件并执行以下后续操作。
If a MEP detects a mis-connectivity defect, it blocks all the traffic (including also the user data packets) that it receives from the misconnected transport path.
如果MEP检测到错误连接缺陷，它将阻止从错误连接的传输路径接收的所有流量（还包括用户数据包）。
If a MEP detects a LOC defect that is not caused by a period misconfiguration, it should block all the traffic (including also the user data packets) that it receives from the transport path, if this consequent action has been enabled by the operator.
如果MEP检测到不是由周期配置错误引起的LOC缺陷，则如果操作员已启用此后续操作，则MEP应阻止其从传输路径接收的所有通信量（也包括用户数据包）。
It is worth noticing that the OAM requirements document [11] recommends that CC-V proactive monitoring be enabled on every MEG in order to reliably detect connectivity defects. However, CC-V proactive monitoring can be disabled by an operator for a MEG. In the event of a misconnection between a transport path that is proactively monitored for CC-V and a transport path that is not, the MEP of the former transport path will detect a LOC defect representing a connectivity problem (e.g., a misconnection with a transport path where CC-V proactive monitoring is not enabled) instead of a continuity problem, with a consequence of delivery of traffic to an incorrect destination. For these reasons, the traffic block consequent action is applied even when a LOC condition occurs. This block consequent action can be disabled through configuration. This deactivation of the block action may be used for activating or deactivating the monitoring when it is not possible to synchronize the function activation of the two peer MEPs.
值得注意的是，OAM需求文件[11]建议在每个MEG上启用CC-V主动监控，以便可靠地检测连接缺陷。但是，操作员可以对MEG禁用CC-V主动监测。如果在主动监控CC-V的传输路径和未监控CC-V的传输路径之间发生错误连接，则前一传输路径的MEP将检测表示连接问题的LOC缺陷（例如，与未启用CC-V主动监控的传输路径的错误连接）而不是连续性问题，其结果是将流量传递到错误的目的地。由于这些原因，即使发生LOC情况，也会应用交通阻塞后续行动。可以通过配置禁用此块后续操作。当无法同步两个对等mep的功能激活时，该块动作的停用可用于激活或停用监控。
If a MEP detects a LOC defect (Section 5.1.1.1) or a mis-connectivity defect (Section 5.1.1.2), it declares a signal fail condition of the ME.
如果MEP检测到LOC缺陷（第5.1.1.1节）或mis连接缺陷（第5.1.1.2节），则宣布ME出现信号故障情况。
It is a matter of local policy whether or not a MEP that detects a period misconfiguration defect (Section 5.1.1.3) declares a signal fail condition of the ME.
检测到周期错误配置缺陷（第5.1.1.3节）的MEP是否宣布ME的信号故障状态，这是当地政策的问题。
The detection of an unexpected encapsulation defect does not have any consequent action: it is just a warning for the network operator. An implementation able to detect an unexpected encapsulation but not able to verify the source MEP ID may choose to declare a mis-connectivity defect.
意外封装缺陷的检测没有任何后续操作：它只是对网络运营商的警告。能够检测到意外封装但无法验证源MEP ID的实现可以选择声明mis连接缺陷。
At all MEPs inside a MEG, the following configuration information needs to be configured when a proactive CC-V function is enabled:
在MEG内的所有MEP中，启用主动CC-V功能时，需要配置以下配置信息：
o MEG-ID: the MEG identifier to which the MEP belongs.
o MEG-ID：MEP所属的MEG标识符。
o MEP-ID: the MEP's own identity inside the MEG.
o MEP-ID：MEG中MEP自己的身份。
o list of the other MEPs in the MEG. For a point-to-point MEG, the list would consist of the single MEP ID from which the OAM packets are expected. In case of the root MEP of a P2MP MEG, the list is composed of all the leaf MEP IDs inside the MEG. In case of the leaf MEP of a P2MP MEG, the list is composed of the root MEP ID (i.e., each leaf needs to know the root MEP ID from which it expects to receive the CC-V OAM packets).
o MEG中其他MEP的列表。对于点对点MEG，该列表将由期望OAM数据包来自的单个MEP ID组成。对于P2MP MEG的根MEP，该列表由MEG内的所有叶MEP ID组成。对于P2MP MEG的叶MEP，该列表由根MEP ID组成（即，每个叶需要知道它期望从中接收CC-V OAM分组的根MEP ID）。
o PHB for E-LSPs. It identifies the per-hop behavior of a CC-V packet. Proactive CC-V packets are transmitted with the "minimum loss probability PHB" previously configured within a single network operator. This PHB is configurable on network operator's basis. PHBs can be translated at the network borders.
o 电子LSP的PHB。它标识CC-V数据包的每跳行为。主动CC-V数据包以先前在单个网络运营商内配置的“最小丢失概率PHB”进行传输。该PHB可根据网络运营商进行配置。PHB可以在网络边界处转换。
o transmission rate. The default CC-V transmission periods are application dependent (depending on whether they are used to support fault management, performance monitoring, or protection-switching applications):
o 传输速率。默认CC-V传输周期取决于应用程序（取决于它们是否用于支持故障管理、性能监控或保护切换应用程序）：
* Fault Management: default transmission period is 1 s (i.e., transmission rate of 1 packet/second).
* 故障管理：默认传输周期为1秒（即传输速率为1包/秒）。
* Performance Management: default transmission period is 100 ms (i.e., transmission rate of 10 packets/second). CC-V contributes to the accuracy of performance monitoring statistics by permitting the defect-free periods to be properly distinguished as described in Sections 5.5.1 and 5.6.1.
* 性能管理：默认传输周期为100毫秒（即10个数据包/秒的传输速率）。CC-V通过允许按照第5.5.1节和第5.6.1节所述正确区分无缺陷期，有助于性能监测统计数据的准确性。
* Protection Switching: If protection switching with CC-V, defect entry criteria of 12 ms is required (for example, in conjunction with the requirement to support 50 ms recovery time as indicated in RFC 5654 [5]), then an implementation should use a default transmission period of 3.33 ms (i.e., transmission rate of 300 packets/second). Sometimes, the requirement of 50 ms recovery time is associated with the requirement for a CC-V defect entry criteria period of 35 ms; in these cases a transmission period of 10 ms (i.e., transmission rate of 100 packets/second) can be used. Furthermore, when there is no need for so small CC-V defect entry criteria periods, a larger transmission period can be used.
* 保护切换：如果使用CC-V进行保护切换，则需要12毫秒的缺陷输入标准（例如，结合RFC 5654[5]中规定的支持50毫秒恢复时间的要求），则实现应使用默认传输周期3.33毫秒（即300包/秒的传输速率）。有时，50 ms恢复时间的要求与35 ms的CC-V缺陷进入标准期的要求相关；在这些情况下，可以使用10ms的传输周期（即，100个分组/秒的传输速率）。此外，当不需要如此小的CC-V缺陷进入标准周期时，可以使用更大的传输周期。
It should be possible for the operator to configure these transmission rates for all applications, to satisfy specific network requirements.
运营商应能够为所有应用配置这些传输速率，以满足特定的网络要求。
Note that the reception period is the same as the configured transmission rate.
注意，接收周期与配置的传输速率相同。
For management-provisioned transport paths, the above parameters are statically configured; for dynamically signaled transport paths, the configuration information is distributed via the control plane.
对于管理配置的传输路径，静态配置上述参数；对于动态信号传输路径，配置信息通过控制平面分布。
The operator should be able to enable/disable some of the consequent actions. Which consequent actions can be enabled/disabled is described in Section 5.1.2.
操作员应能够启用/禁用某些后续操作。第5.1.2节描述了可启用/禁用的后续行动。
The Remote Defect Indication (RDI) function, as required in Section 2.2.9 of RFC 5860 [11], is an indicator that is transmitted by a sink MEP to communicate to its source MEP that a signal fail condition exists. In case of co-routed and associated bidirectional transport paths, RDI is associated with proactive CC-V, and the RDI indicator can be piggy-backed onto the CC-V packet. In case of unidirectional transport paths, the RDI indicator can be sent only using an out-of-band return path if it exists and its usage is enabled by policy actions.
RFC 5860[11]第2.2.9节要求的远程缺陷指示（RDI）功能是一个指示器，由接收器MEP发送，以向其源MEP传达存在信号故障条件。在共路由和相关联的双向传输路径的情况下，RDI与主动CC-V相关联，并且RDI指示符可以背驮到CC-V数据包上。在单向传输路径的情况下，RDI指示符只能使用带外返回路径发送，前提是该路径存在且其使用由策略操作启用。
When a MEP detects a signal fail condition (e.g., in case of a continuity or connectivity defect), it should begin transmitting an RDI indicator to its peer MEP. When incorporated into CC-V, the RDI information will be included in all proactive CC-V packets that it generates for the duration of the signal fail condition's existence.
当MEP检测到信号故障条件时（例如，在连续性或连接缺陷的情况下），应开始向其对等MEP发送RDI指示器。当合并到CC-V中时，RDI信息将包含在其在信号失败条件存在期间生成的所有主动CC-V数据包中。
A MEP that receives packets from a peer MEP with the RDI information should determine that its peer MEP has encountered a defect condition associated with a signal fail condition.
从具有RDI信息的对等MEP接收数据包的MEP应确定其对等MEP遇到了与信号失败条件相关联的缺陷条件。
MIPs as well as intermediate nodes not supporting MPLS-TP OAM are transparent to the RDI indicator and forward OAM packets that include the RDI indicator as regular data packets, i.e., the MIP should not perform any actions nor examine the indicator.
MIP以及不支持MPLS-TP OAM的中间节点对RDI指示符是透明的，并将包含RDI指示符的OAM包作为常规数据包转发，即MIP不应执行任何操作，也不应检查指示符。
When the signal fail condition clears, the MEP should stop transmitting the RDI indicator to its peer MEP. When incorporated into CC-V, the RDI indicator will not be set for subsequent transmission of proactive CC-V packets. A MEP should clear the RDI defect upon reception of an RDI indicator cleared.
当信号故障条件清除时，MEP应停止向其对等MEP发送RDI指示器。当合并到CC-V中时，RDI指示符将不会为主动CC-V数据包的后续传输设置。MEP应在收到已清除的RDI指示器后清除RDI缺陷。
In order to support RDI, the indication may be carried in a unique OAM packet or may be embedded in a CC-V packet. The in-band RDI transmission rate and PHB of the OAM packets carrying RDIs should be the same as that configured for CC-V to allow both far-end and near-end defect conditions being resolved in a timeframe that has the same order of magnitude. This timeframe is application specific as described in Section 5.1.3. Methods of the out-of-band return paths will dictate how out-of-band RDIs are transmitted.
为了支持RDI，该指示可以在唯一OAM分组中携带，或者可以嵌入到CC-V分组中。携带RDI的OAM分组的带内RDI传输速率和PHB应与为CC-V配置的相同，以允许在具有相同数量级的时间帧中解决远端和近端缺陷条件。如第5.1.3节所述，此时间范围是特定于应用的。带外返回路径的方法将决定如何传输带外RDI。
The Alarm Reporting function, as required in Section 2.2.8 of RFC 5860 [11], relies upon an Alarm Indication Signal (AIS) packet to suppress alarms following detection of defect conditions at the server (sub-)layer.
根据RFC 5860[11]第2.2.8节的要求，报警报告功能依赖于报警指示信号（AIS）包，以在服务器（子）层检测到缺陷条件后抑制报警。
When a server MEP asserts a signal fail condition, it notifies that to the co-located MPLS-TP client/server adaptation function that then generates OAM packets with AIS information in the downstream direction to allow the suppression of secondary alarms at the MPLS-TP MEP in the client (sub-)layer.
当服务器MEP断言信号失败条件时，它通知位于同一位置的MPLS-TP客户机/服务器适配功能，该功能随后在下游方向生成带有AIS信息的OAM包，以允许在客户机（子）层的MPLS-TP MEP处抑制二次警报。
The generation of packets with AIS information starts immediately when the server MEP asserts a signal fail condition. These periodic OAM packets, with AIS information, continue to be transmitted until the signal fail condition is cleared.
当服务器MEP断言信号失败条件时，立即开始生成包含AIS信息的数据包。这些带有AIS信息的周期性OAM数据包将继续传输，直到清除信号失败条件。
It is assumed that to avoid spurious alarm generation a MEP detecting a loss of continuity defect (see Section 5.1.1.1) will wait for a hold-off interval prior to asserting an alarm to the management system. Therefore, upon receiving an OAM packet with AIS information, an MPLS-TP MEP enters an AIS defect condition and suppresses reporting of alarms to the NMS on the loss of continuity with its peer MEP, but it does not block traffic received from the transport path. A MEP resumes loss of continuity alarm generation upon detecting loss of continuity defect conditions in the absence of AIS condition.
假设为避免产生虚假警报，检测到连续性缺失缺陷的MEP（见第5.1.1.1节）将在向管理系统发出警报之前等待一段延迟时间。因此，在接收到带有AIS信息的OAM分组时，MPLS-TP MEP进入AIS缺陷状态，并禁止向NMS报告其对等MEP的连续性丢失警报，但它不会阻止从传输路径接收的流量。在没有AIS条件的情况下，MEP在检测到连续性丧失缺陷条件时恢复连续性丧失报警的生成。
MIPs, as well as intermediate nodes, do not process AIS information and forward these AIS OAM packets as regular data packets.
MIPs以及中间节点不处理AIS信息并将这些AIS OAM数据包作为常规数据包转发。
For example, let's consider a fiber cut between T-PE 1 and LSR 2 in the reference network of Figure 5. Assuming that all of the MEGs described in Figure 5 have proactive CC-V enabled, a LOC defect is detected by the MEPs of Sec12 SMEG, LSP13 LMEG, PW1 PSMEG, and PW1Z PMEG; however, in a transport network, only the alarm associated to the fiber cut needs to be reported to an NMS, while all secondary alarms should be suppressed (i.e., not reported to the NMS or reported as secondary alarms).
例如，让我们考虑在图5的参考网络中的T-PE 1和LSR 2之间的光纤切割。假设图5中描述的所有MEG都启用了主动CC-V，则Sec12 SMEG、LSP13 LMEG、PW1 PSMEG和PW1Z PMEG的MEP检测到LOC缺陷；但是，在传输网络中，只需向NMS报告与光纤切断相关的警报，而应抑制所有辅助警报（即，不向NMS报告或作为辅助警报报告）。
If the fiber cut is detected by the MEP in the physical layer (in LSR 2), LSR 2 can generate the proper alarm in the physical layer and suppress the secondary alarm associated with the LOC defect detected on Sec12 SMEG. As both MEPs reside within the same node, this process does not involve any external protocol exchange. Otherwise,
如果MEP在物理层（LSR 2中）检测到光纤切割，LSR 2可以在物理层生成适当的警报，并抑制与Sec12 SMEG上检测到的LOC缺陷相关的二次警报。由于两个MEP位于同一节点内，因此该过程不涉及任何外部协议交换。否则
if the physical layer does not have enough OAM capabilities to detect the fiber cut, the MEP of Sec12 SMEG in LSR 2 will report a LOC alarm.
如果物理层没有足够的OAM能力来检测光纤切断，LSR 2中Sec12 SMEG的MEP将报告LOC警报。
In both cases, the MEP of Sec12 SMEG in LSR 2 notifies the adaptation function for LSP13 LMEG that then generates AIS packets on the LSP13 LMEG in order to allow its MEP in S-PE 3 to suppress the LOC alarm. S-PE 3 can also suppress the secondary alarm on PW13 PSMEG because the MEP of PW13 PSMEG resides within the same node as the MEP of LSP13 LMEG. The MEP of PW13 PSMEG in S-PE 3 also notifies the adaptation function for PW1Z PMEG that then generates AIS packets on PW1Z PMEG in order to allow its MEP in T-PE Z to suppress the LOC alarm.
在这两种情况下，LSR 2中Sec12 SMEG的MEP通知LSP13 LMEG的自适应功能，该功能随后在LSP13 LMEG上生成AIS数据包，以允许其在S-PE 3中的MEP抑制LOC报警。S-PE 3还可以抑制PW13 PSMEG上的二次报警，因为PW13 PSMEG的MEP与LSP13 LMEG的MEP位于同一节点内。S-PE 3中PW13 PSMEG的MEP还通知PW1Z PMEG的自适应功能，该功能随后在PW1Z PMEG上生成AIS数据包，以允许其T-PE Z中的MEP抑制LOC报警。
The generation of AIS packets for each MEG in the MPLS-TP client (sub-)layer is configurable (i.e., the operator can enable/disable the AIS generation).
MPLS-TP客户端（子）层中每个MEG的AIS数据包生成是可配置的（即，操作员可以启用/禁用AIS生成）。
The AIS condition is cleared if no AIS packet has been received in 3.5 times the AIS transmission period.
如果在AIS传输周期的3.5倍内未收到AIS数据包，则清除AIS条件。
The AIS transmission period is traditionally one per second, but an option to configure longer periods would be also desirable. As a consequence, OAM packets need to self-identify the transmission period such that proper exit criteria can be established.
AIS传输周期通常为每秒一次，但也需要配置更长周期的选项。因此，OAM分组需要自识别传输周期，以便可以建立适当的退出标准。
AIS packets are transmitted with the "minimum loss probability PHB" within a single network operator. For E-LSPs, this PHB is configurable on network operator's basis, while for L-LSPs, this is determined as per RFC 3270 [23].
AIS数据包在单个网络运营商内以“最小丢失概率PHB”进行传输。对于E-LSP，该PHB可根据网络运营商进行配置，而对于L-LSP，则根据RFC 3270[23]确定。
The Lock Reporting function, as required in Section 2.2.7 of RFC 5860 [11], relies upon a Lock Report (LKR) packet used to suppress alarms following administrative locking action in the server (sub-)layer.
RFC 5860[11]第2.2.7节要求的锁定报告功能依赖于锁定报告（LKR）数据包，用于在服务器（子）层中的管理锁定操作后抑制报警。
When a server MEP is locked, the MPLS-TP client (sub-)layer adaptation function generates packets with LKR information to allow the suppression of secondary alarms at the MEPs in the client (sub-)layer. Again, it is assumed that there is a hold-off for any loss of continuity alarms in the client-layer MEPs downstream of the node originating the Lock Report. In case of client (sub-)layer co-routed bidirectional transport paths, the LKR information is sent on both directions. In case of client (sub-)layer unidirectional transport paths, the LKR information is sent only in the downstream direction. As a consequence, in case of client (sub-)layer point-to-multipoint transport paths, the LKR information is sent only to the
当服务器MEP被锁定时，MPLS-TP客户端（子）层适配功能生成包含LKR信息的数据包，以允许在客户端（子）层的MEP处抑制二次报警。同样，假设在发起锁报告的节点下游的客户端层MEP中存在任何连续性丢失警报的延迟。在客户端（子）层共路由双向传输路径的情况下，在两个方向上发送LKR信息。在客户端（子）层单向传输路径的情况下，仅在下游方向发送LKR信息。因此，在客户端（子）层点到多点传输路径的情况下，LKR信息仅发送到客户端
MEPs that are downstream from the server (sub-)layer that has been administratively locked. Client (sub-)layer associated bidirectional transport paths behave like co-routed bidirectional transport paths if the server (sub-)layer that has been administratively locked is used by both directions; otherwise, they behave like unidirectional transport paths.
已被管理锁定的服务器（子）层下游的MEP。如果已被管理锁定的服务器（子）层被两个方向使用，则与客户端（子）层相关联的双向传输路径的行为类似于共同路由的双向传输路径；否则，它们的行为就像单向传输路径。
The generation of packets with LKR information starts immediately when the server MEP is locked. These periodic packets, with LKR information, continue to be transmitted until the locked condition is cleared.
当服务器MEP被锁定时，立即开始生成具有LKR信息的数据包。这些带有LKR信息的周期性数据包将继续传输，直到锁定条件被清除。
Upon receiving a packet with LKR information, an MPLS-TP MEP enters an LKR defect condition and suppresses the loss of continuity alarm associated with its peer MEP but does not block traffic received from the transport path. A MEP resumes loss of continuity alarm generation upon detecting loss of continuity defect conditions in the absence of the LKR condition.
在接收到具有LKR信息的分组时，MPLS-TP MEP进入LKR缺陷状态并抑制与其对等MEP相关联的连续性丢失报警，但不阻止从传输路径接收的通信量。在没有LKR条件的情况下，MEP在检测到连续性丧失缺陷条件时恢复连续性丧失报警的生成。
MIPs, as well as intermediate nodes, do not process the LKR information; they forward these LKR OAM packets as regular data packets.
MIPs以及中间节点不处理LKR信息；它们将这些LKR OAM数据包作为常规数据包转发。
For example, let's consider the case where the MPLS-TP Section between T-PE 1 and LSR 2 in the reference network of Figure 5 is administratively locked at LSR 2 (in both directions).
例如，让我们考虑在图5的参考网络中的T-PE 1和LSR 2之间的MPLS-TP部分在LSR 2（在两个方向）上被行政地锁定的情况。
Assuming that all the MEGs described in Figure 5 have proactive CC-V enabled, a LOC defect is detected by the MEPs of LSP13 LMEG, PW1 PSMEG, and PW1Z PMEG; however, in a transport network all these secondary alarms should be suppressed (i.e., not reported to the NMS or reported as secondary alarms).
假设图5中描述的所有MEG都启用了主动CC-V，LSP13 LMEG、PW1 PSMEG和PW1Z PMEG的MEP检测到LOC缺陷；但是，在传输网络中，应抑制所有这些次要警报（即，不向NMS报告或作为次要警报报告）。
The MEP of Sec12 SMEG in LSR 2 notifies the adaptation function for LSP13 LMEG that then generates LKR packets on the LSP13 LMEG in order to allow its MEPs in T-PE 1 and S-PE 3 to suppress the LOC alarm. S-PE 3 can also suppress the secondary alarm on PW13 PSMEG because the MEP of PW13 PSMEG resides within the same node as the MEP of LSP13 LMEG. The MEP of PW13 PSMEG in S-PE 3 also notifies the adaptation function for PW1Z PMEG that then generates AIS packets on PW1Z PMEG in order to allow its MEP in T-PE Z to suppress the LOC alarm.
LSR 2中Sec12 SMEG的MEP通知LSP13 LMEG的自适应功能，该功能随后在LSP13 LMEG上生成LKR数据包，以允许T-PE 1和S-PE 3中的MEP抑制LOC报警。S-PE 3还可以抑制PW13 PSMEG上的二次报警，因为PW13 PSMEG的MEP与LSP13 LMEG的MEP位于同一节点内。S-PE 3中PW13 PSMEG的MEP还通知PW1Z PMEG的自适应功能，该功能随后在PW1Z PMEG上生成AIS数据包，以允许其T-PE Z中的MEP抑制LOC报警。
The generation of LKR packets for each MEG in the MPLS-TP client (sub-)layer is configurable (i.e., the operator can enable/disable the LKR generation).
MPLS-TP客户端（子）层中每个MEG的LKR数据包的生成是可配置的（即，操作员可以启用/禁用LKR生成）。
The locked condition is cleared if no LKR packet has been received for 3.5 times the transmission period.
如果在传输周期的3.5倍内未收到LKR数据包，则锁定条件被清除。
The LKR transmission period is traditionally one per second, but an option to configure longer periods would be also desirable. As a consequence, OAM packets need to self-identify the transmission period such that proper exit criteria can be established.
LKR传输周期传统上为每秒一个，但是配置更长周期的选项也是可取的。因此，OAM分组需要自识别传输周期，以便可以建立适当的退出标准。
LKR packets are transmitted with the "minimum loss probability PHB" within a single network operator. For E-LSPs, this PHB is configurable on network operator's basis, while for L-LSPs, this is determined as per RFC 3270 [23].
LKR分组在单个网络运营商内以“最小丢失概率PHB”传输。对于E-LSP，该PHB可根据网络运营商进行配置，而对于L-LSP，则根据RFC 3270[23]确定。
Packet Loss Measurement (LM) is one of the capabilities supported by the MPLS-TP Performance Monitoring (PM) function in order to facilitate reporting of Quality of Service (QoS) information for a transport path as required in Section 2.2.11 of RFC 5860 [11]. LM is used to exchange counter values for the number of ingress and egress packets transmitted and received by the transport path monitored by a pair of MEPs.
丢包测量（LM）是MPLS-TP性能监视（PM）功能支持的功能之一，以便于报告RFC 5860[11]第2.2.11节要求的传输路径的服务质量（QoS）信息。LM用于交换由一对MEP监控的传输路径发送和接收的入口和出口数据包数量的计数器值。
Proactive LM is performed by periodically sending LM OAM packets from a MEP to a peer MEP and by receiving LM OAM packets from the peer MEP (if a co-routed or associated bidirectional transport path) during the lifetime of the transport path. Each MEP performs measurements of its transmitted and received user data packets. These measurements are then correlated in real time with the peer MEP in the ME to derive the impact of packet loss on a number of performance metrics for the ME in the MEG. The LM transactions are issued such that the OAM packets will experience the same PHB scheduling class as the measured traffic while transiting between the MEPs in the ME.
主动LM是通过在传输路径的生存期内周期性地从MEP向对等MEP发送LM-OAM分组和从对等MEP接收LM-OAM分组（如果是共同路由的或相关联的双向传输路径）来执行的。每个MEP对其发送和接收的用户数据包执行测量。然后将这些测量值与ME中的对等MEP实时关联，以得出数据包丢失对MEG中ME的许多性能指标的影响。LM事务的发布使得OAM包在ME中的mep之间传输时将经历与测量的流量相同的PHB调度类。
For a MEP, near-end packet loss refers to packet loss associated with incoming data packets (from the far-end MEP), while far-end packet loss refers to packet loss associated with egress data packets (towards the far-end MEP).
对于MEP，近端分组丢失指与传入数据分组（来自远端MEP）相关联的分组丢失，而远端分组丢失指与出口数据分组（朝向远端MEP）相关联的分组丢失。
Proactive LM can be operated in two ways:
主动式LM可通过两种方式进行操作：
o One-way: a MEP sends an LM OAM packet to its peer MEP containing all the required information to facilitate near-end packet loss measurements at the peer MEP.
o 单向：MEP向其对等MEP发送一个LM OAM数据包，其中包含所有必需的信息，以便于在对等MEP进行近端数据包丢失测量。
o Two-way: a MEP sends an LM OAM packet with an LM request to its peer MEP, which replies with an LM OAM packet as an LM response. The request/response LM OAM packets contain all the required
o 双向：MEP向对等MEP发送带有LM请求的LM OAM数据包，对等MEP以LM OAM数据包作为LM响应进行响应。请求/响应LM OAM数据包包含所有必需的
information to facilitate both near-end and far-end packet loss measurements from the viewpoint of the originating MEP.
从始发MEP的角度促进近端和远端分组丢失测量的信息。
One-way LM is applicable to both unidirectional and bidirectional (co-routed or associated) transport paths, while two-way LM is applicable only to bidirectional (co-routed or associated) transport paths.
单向LM适用于单向和双向（共路由或关联）传输路径，而双向LM仅适用于双向（共路由或关联）传输路径。
MIPs, as well as intermediate nodes, do not process the LM information; they forward these proactive LM OAM packets as regular data packets.
MIPs以及中间节点不处理LM信息；它们将这些主动LM OAM数据包作为常规数据包转发。
In order to support proactive LM, the transmission rate and, for E-LSPs, the PHB class (associated with the LM OAM packets originating from a MEP) need to be configured as part of the LM provisioning. LM OAM packets should be transmitted with the PHB that yields the lowest drop precedence within the measured PHB Scheduling Class (see RFC 3260 [17]), in order to maximize reliability of measurement within the traffic class.
为了支持主动LM，需要将传输速率和PHB类（与源自MEP的LM OAM数据包相关联）配置为LM配置的一部分。LM OAM数据包应与PHB一起传输，该PHB在所测量的PHB调度类中产生最低的丢弃优先级（参见RFC 3260[17]），以便最大限度地提高流量类中测量的可靠性。
If that PHB class is not an ordered aggregate where the ordering constraint is all packets with the PHB class being delivered in order, LM can produce inconsistent results.
如果该PHB类不是有序聚合，其中排序约束是PHB类按顺序交付的所有数据包，则LM可能会产生不一致的结果。
Performance monitoring (e.g., LM) is only relevant when the transport path is defect free. CC-V contributes to the accuracy of PM statistics by permitting the defect-free periods to be properly distinguished. Therefore, support of proactive LM has implications on the CC-V transmission period (see Section 5.1.3).
性能监控（如LM）仅在传输路径无缺陷时相关。CC-V允许正确区分无缺陷期，从而有助于PM统计的准确性。因此，主动LM的支持对CC-V传输周期有影响（见第5.1.3节）。
If an implementation makes use of a hardware forwarding path that operates in parallel with an OAM processing path, whether hardware or software based, the packet and byte counts may be skewed if one or more packets can be processed before the OAM processing samples counters. If OAM is implemented in software, this error can be quite large.
如果实现使用与OAM处理路径并行操作的硬件转发路径，无论是基于硬件还是基于软件的，如果可以在OAM处理样本计数器之前处理一个或多个分组，则分组和字节计数可能会发生偏移。如果OAM是在软件中实现的，那么这个错误可能非常大。
If multilink is used at the ingress or egress of a transport path, there may not be a single packet-processing engine where an LM packet can be injected or extracted as an atomic operation while having accurate packet and byte counts associated with the packet.
如果在传输路径的入口或出口处使用多链路，则可能不存在单个分组处理引擎，其中LM分组可以作为原子操作注入或提取，同时具有与分组相关联的准确分组和字节计数。
In the case where multilink is encountered along the route of the transport path, the reordering of packets within the transport path can cause inaccurate LM results.
在沿着传输路径的路由遇到多链路的情况下，传输路径内的分组重新排序可能导致不准确的LM结果。
Packet Delay Measurement (DM) is one of the capabilities supported by the MPLS-TP PM function in order to facilitate reporting of QoS information for a transport path as required in Section 2.2.12 of RFC 5860 [11]. Specifically, proactive DM is used to measure the long-term packet delay and packet delay variation in the transport path monitored by a pair of MEPs.
数据包延迟测量（DM）是MPLS-TP PM功能支持的功能之一，以便于按照RFC 5860[11]第2.2.12节的要求报告传输路径的QoS信息。具体地说，主动DM用于测量由一对mep监控的传输路径中的长期分组延迟和分组延迟变化。
Proactive DM is performed by sending periodic DM OAM packets from a MEP to a peer MEP and by receiving DM OAM packets from the peer MEP (if a co-routed or associated bidirectional transport path) during a configurable time interval.
通过在可配置的时间间隔内从MEP向对等MEP发送周期性DM-OAM分组，并通过从对等MEP接收DM-OAM分组（如果是共同路由的或相关联的双向传输路径）来执行主动DM。
Proactive DM can be operated in two ways:
主动式DM可通过两种方式进行操作：
o One-way: a MEP sends a DM OAM packet to its peer MEP containing all the required information to facilitate one-way packet delay and/or one-way packet delay variation measurements at the peer MEP. Note that this requires precise time synchronization at either MEP by means outside the scope of this framework.
o 单向：MEP向其对等MEP发送DM-OAM分组，该分组包含所有所需信息，以促进对等MEP处的单向分组延迟和/或单向分组延迟变化测量。请注意，这需要通过本框架范围之外的方式在任一MEP进行精确的时间同步。
o Two-way: a MEP sends a DM OAM packet with a DM request to its peer MEP, which replies with a DM OAM packet as a DM response. The request/response DM OAM packets contain all the required information to facilitate two-way packet delay and/or two-way packet delay variation measurements from the viewpoint of the originating MEP.
o 双向：MEP向其对等MEP发送带有DM请求的DM OAM数据包，对等MEP以DM OAM数据包作为DM响应进行响应。请求/响应DM OAM分组包含从发起MEP的观点促进双向分组延迟和/或双向分组延迟变化测量的所有所需信息。
One-way DM is applicable to both unidirectional and bidirectional (co-routed or associated) transport paths, while two-way DM is applicable only to bidirectional (co-routed or associated) transport paths.
单向DM适用于单向和双向（共路由或关联）传输路径，而双向DM仅适用于双向（共路由或关联）传输路径。
MIPs, as well as intermediate nodes, do not process the DM information; they forward these proactive DM OAM packets as regular data packets.
MIPs以及中间节点不处理DM信息；它们将这些主动DM OAM数据包作为常规数据包转发。
In order to support proactive DM, the transmission rate and, for E-LSPs, the PHB (associated with the DM OAM packets originating from a MEP) need to be configured as part of the DM provisioning. DM OAM packets should be transmitted with the PHB that yields the lowest
为了支持主动DM，传输速率以及对于E-lsp，PHB（与源自MEP的DM OAM分组相关联）需要配置为DM供应的一部分。DM OAM数据包应与产生最低性能的PHB一起传输
drop precedence within the measured PHB Scheduling Class (see RFC 3260 [17]).
在测量的PHB调度类中删除优先级（参见RFC 3260[17]）。
Performance monitoring (e.g., DM) is only relevant when the transport path is defect free. CC-V contributes to the accuracy of PM statistics by permitting the defect-free periods to be properly distinguished. Therefore, support of proactive DM has implications on the CC-V transmission period (see Section 5.1.3).
性能监控（例如，DM）仅在传输路径无缺陷时才相关。CC-V允许正确区分无缺陷期，从而有助于PM统计的准确性。因此，支持主动DM对CC-V传输周期有影响（见第5.1.3节）。
The Client Failure Indication (CFI) function, as required in Section 2.2.10 of RFC 5860 [11], is used to help process client defects and propagate a client signal defect condition from the process associated with the local attachment circuit where the defect was detected (typically the source adaptation function for the local client interface). It is propagated to the process associated with the far-end attachment circuit (typically the source adaptation function for the far-end client interface) for the same transmission path, in case the client of the transport path does not support a native defect/alarm indication mechanism, e.g., AIS.
RFC 5860[11]第2.2.10节要求的客户机故障指示（CFI）功能用于帮助处理客户机缺陷，并从与检测到缺陷的本地连接电路相关的过程传播客户机信号缺陷条件（通常是本地客户机接口的源适配功能）。如果传输路径的客户端不支持本机缺陷/报警指示机制，例如AIS，则它被传播到与同一传输路径的远端连接电路（通常是远端客户端接口的源适配功能）相关联的进程。
A source MEP starts transmitting a CFI to its peer MEP when it receives a local client signal defect notification via its local client signal fail indication. Mechanisms to detect local client signal fail defects are technology specific. Similarly, mechanisms to determine when to cease originating client signal fail indication are also technology specific.
当源MEP通过其本地客户端信号失败指示接收到本地客户端信号缺陷通知时，它开始向其对等MEP发送CFI。检测本地客户端信号故障缺陷的机制是特定于技术的。类似地，用于确定何时停止发起客户端信号失败指示的机制也是特定于技术的。
A sink MEP that has received a CFI reports this condition to its associated client process via its local CFI function. Consequent actions toward the client attachment circuit are technology specific.
接收到CFI的接收器MEP通过其本地CFI功能向其关联的客户端进程报告此情况。针对客户端连接电路的后续操作是特定于技术的。
There needs to be a 1:1 correspondence between the client and the MEG; otherwise, when multiple clients are multiplexed over a transport path, the CFI packet requires additional information to permit the client instance to be identified.
客户和MEG之间需要1:1的通信；否则，当在传输路径上多路复用多个客户端时，CFI分组需要额外的信息以允许识别客户端实例。
MIPs, as well as intermediate nodes, do not process the CFI information; they forward these proactive CFI OAM packets as regular data packets.
MIPs以及中间节点不处理CFI信息；它们将这些主动CFI OAM数据包作为常规数据包转发。
In order to support CFI indication, the CFI transmission rate and, for E-LSPs, the PHB of the CFI OAM packets should be configured as part of the CFI configuration.
为了支持CFI指示，CFI传输速率以及对于E-lsp，CFI OAM分组的PHB应作为CFI配置的一部分进行配置。
In contrast to proactive monitoring, on-demand monitoring is initiated manually and for a limited amount of time, usually for operations such as diagnostics to investigate a defect condition.
与主动式监控不同，按需监控是手动启动的，时间有限，通常用于调查缺陷状况的诊断等操作。
On-demand monitoring covers a combination of "in-service" and "out-of-service" monitoring functions. The control and measurement implications are:
按需监控包括“在用”和“停用”监控功能的组合。控制和测量的含义如下：
1. A MEG can be directed to perform an "on-demand" functions at arbitrary times in the lifetime of a transport path.
1. 可以指示MEG在传输路径生命周期内的任意时间执行“按需”功能。
2. "Out-of-service" monitoring functions may require a priori configuration of both MEPs and intermediate nodes in the MEG (e.g., data-plane loopback) and the issuance of notifications into client layers of the transport path being removed from service (e.g., lock reporting)
2. “停止服务”监控功能可能需要事先配置MEG中的MEP和中间节点（例如，数据平面环回），并向正在从服务中删除的传输路径的客户端层发出通知（例如，锁报告）
3. The measurements resulting from "on-demand" monitoring are typically harvested in real time, as they are frequently initiated manually. These do not necessarily require different harvesting mechanisms than for harvesting proactive monitoring telemetry.
3. “按需”监控产生的测量通常是实时采集的，因为它们通常是手动启动的。这些不一定需要与采集主动监测遥测不同的采集机制。
The functions that are exclusively out-of-service are those described in Section 6.3. The remainder are applicable to both in-service and out-of-service transport paths.
专门停止使用的功能如第6.3节所述。其余部分适用于服务中和服务外的传输路径。
The on-demand connectivity verification function, as required in Section 2.2.3 of RFC 5860 [11], is a transaction that flows from the originating MEP to a target MIP or MEP to verify the connectivity between these points.
RFC 5860[11]第2.2.3节中要求的按需连接验证功能是一种从原始MEP流向目标MIP或MEP的事务，用于验证这些点之间的连接。
Use of on-demand CV is dependent on the existence of a bidirectional ME or an associated return ME, or the availability of an out-of-band return path, because it requires the ability for target MIPs and MEPs to direct responses to the originating MEPs.
按需CV的使用取决于双向ME或相关返回ME的存在，或带外返回路径的可用性，因为它要求目标MIP和MEP能够直接响应原始MEP。
One possible use of on-demand CV would be to perform fault management without using proactive CC-V, in order to preserve network resources, e.g., bandwidth, processing time at switches. In this case, network management periodically invokes on-demand CV.
按需CV的一种可能用途是在不使用主动CC-V的情况下执行故障管理，以保留网络资源，例如带宽、交换机的处理时间。在这种情况下，网络管理会定期调用按需CV。
An additional use of on-demand CV would be to detect and locate a problem of connectivity when a problem is suspected or known to be based on other tools. In this case, the functionality will be triggered by the network management in response to a status signal or alarm indication.
按需CV的另一个用途是，当怀疑或已知问题基于其他工具时，检测并定位连接问题。在这种情况下，网络管理将根据状态信号或报警指示触发该功能。
On-demand CV is based upon generation of on-demand CV packets that should uniquely identify the MEG that is being checked. The on-demand functionality may be used to check either an entire MEG (end-to-end) or between the originating MEP and a specific MIP. This functionality may not be available for associated bidirectional transport paths or unidirectional paths, as the MIP may not have a return path to the originating MEP for the on-demand CV transaction.
按需CV基于按需CV数据包的生成，该数据包应唯一标识正在检查的MEG。按需功能可用于检查整个MEG（端到端）或原始MEP和特定MIP之间的情况。此功能可能不适用于相关联的双向传输路径或单向路径，因为MIP可能没有到按需CV事务的原始MEP的返回路径。
When on-demand CV is invoked, the originating MEP issues a sequence of on-demand CV packets that uniquely identifies the MEG being verified. The number of packets and their transmission rate should be pre-configured at the originating MEP to take into account normal packet-loss conditions. The source MEP should use the mechanisms defined in Sections 3.3 and 3.4 when sending an on-demand CV packet to a target MEP or target MIP, respectively. The target MEP/MIP shall return a reply on-demand CV packet for each packet received. If the expected number of on-demand CV reply packets is not received at the originating MEP, this is an indication that a connectivity problem may exist.
当调用按需CV时，原始MEP发出一系列按需CV数据包，该数据包唯一标识正在验证的MEG。数据包的数量及其传输速率应在原始MEP处预先配置，以考虑正常的数据包丢失情况。当分别向目标MEP或目标MIP发送按需CV数据包时，源MEP应使用第3.3节和第3.4节中定义的机制。目标MEP/MIP应为收到的每个数据包返回按需回复CV数据包。如果始发MEP未接收到预期数量的按需CV回复数据包，则表明可能存在连接问题。
On-demand CV should have the ability to carry padding such that a variety of MTU sizes can be originated to verify the MTU transport capability of the transport path.
按需CV应具有承载填充的能力，以便可以生成各种MTU大小，以验证传输路径的MTU传输能力。
MIPs that are not targeted by on-demand CV packets, as well as intermediate nodes, do not process the CV information; they forward these on-demand CV OAM packets as regular data packets.
非按需CV数据包目标的MIP以及中间节点不处理CV信息；它们将这些按需CV OAM数据包作为常规数据包转发。
For on-demand CV, the originating MEP should support the configuration of the number of packets to be transmitted/received in each sequence of transmissions and their packet size.
对于按需CV，发起MEP应支持在每个传输序列中发送/接收的分组数量及其分组大小的配置。
In addition, when the CV packet is used to check connectivity toward a target MIP, the number of hops to reach the target MIP should be configured.
此外，当CV数据包用于检查与目标MIP的连接时，应配置到达目标MIP的跳数。
For E-LSPs, the PHB of the on-demand CV packets should be configured as well. This permits the verification of correct operation of QoS queuing as well as connectivity.
对于E-LSP，还应配置按需CV数据包的PHB。这允许验证QoS队列和连接的正确操作。
On-demand Packet Loss Measurement (LM) is one of the capabilities supported by the MPLS-TP Performance Monitoring function in order to facilitate the diagnosis of QoS performance for a transport path, as required in Section 2.2.11 of RFC 5860 [11].
按需丢包测量（LM）是MPLS-TP性能监控功能支持的功能之一，以便于根据RFC 5860[11]第2.2.11节的要求诊断传输路径的QoS性能。
On-demand LM is very similar to proactive LM described in Section 5.5. This section focuses on the differences between on-demand and proactive LM.
按需LM与第5.5节中描述的主动LM非常相似。本节重点介绍随需应变和主动式LM之间的区别。
On-demand LM is performed by periodically sending LM OAM packets from a MEP to a peer MEP and by receiving LM OAM packets from the peer MEP (if a co-routed or associated bidirectional transport path) during a pre-defined monitoring period. Each MEP performs measurements of its transmitted and received user data packets. These measurements are then correlated to evaluate the packet-loss performance metrics of the transport path.
按需LM是通过周期性地从MEP向对等MEP发送LM-OAM分组，并通过在预定义的监视期间从对等MEP（如果是共同路由的或相关联的双向传输路径）接收LM-OAM分组来执行的。每个MEP对其发送和接收的用户数据包执行测量。然后将这些测量值关联起来，以评估传输路径的分组丢失性能度量。
Use of packet loss measurement in an out-of-service transport path requires a traffic source such as a test device that can inject synthetic traffic.
在服务中断传输路径中使用丢包测量需要一个流量源，例如可以注入合成流量的测试设备。
In order to support on-demand LM, the beginning and duration of the LM procedures, the transmission rate, and, for E-LSPs, the PHB class (associated with the LM OAM packets originating from a MEP) must be configured as part of the on-demand LM provisioning. LM OAM packets should be transmitted with the PHB that yields the lowest drop precedence as described in Section 5.5.1.
为了支持按需LM，LM过程的开始和持续时间、传输速率，以及对于E-LSP，PHB类（与源自MEP的LM OAM数据包关联）必须配置为按需LM供应的一部分。LM OAM数据包应与PHB一起传输，PHB产生第5.5.1节所述的最低丢弃优先级。
The same considerations described in Section 5.5.2 for the proactive LM are also applicable to on-demand LM implementations.
第5.5.2节中所述的主动式LM注意事项同样适用于按需LM实施。
Multilink issues are as described in Section 5.5.3.
多链路问题如第5.5.3节所述。
Diagnostic tests are tests performed on a MEG that has been taken out of service.
诊断测试是对停止使用的MEG进行的测试。
Throughput estimation is an on-demand out-of-service function, as required in Section 2.2.5 of RFC 5860 [11], that allows verifying the bandwidth/throughput of an MPLS-TP transport path (LSP or PW) before it is put in service.
根据RFC 5860[11]第2.2.5节的要求，吞吐量估计是一种按需服务外功能，允许在MPLS-TP传输路径（LSP或PW）投入服务之前验证其带宽/吞吐量。
Throughput estimation is performed between MEPs and between a MEP and a MIP. It can be performed in one-way or two-way modes.
吞吐量估计在MEP之间以及在MEP和MIP之间执行。它可以在单向或双向模式下执行。
According to RFC 2544 [12], this test is performed by sending OAM test packets at increasing rates (up to the theoretical maximum), computing the percentage of OAM test packets received, and reporting the rate at which OAM test packets begin to drop. In general, this rate is dependent on the OAM test packet size.
根据RFC 2544[12]，该测试通过以递增速率（达到理论最大值）发送OAM测试数据包，计算接收到的OAM测试数据包的百分比，并报告OAM测试数据包开始下降的速率来执行。通常，此速率取决于OAM测试数据包的大小。
When configured to perform such tests, a source MEP inserts OAM test packets with a specified packet size and transmission pattern at a rate to exercise the throughput.
当配置为执行此类测试时，源MEP以一定速率插入具有指定分组大小和传输模式的OAM测试分组，以实现吞吐量。
The throughput test can create congestion within the network, thus impacting other transport paths. However, the test traffic should comply with the traffic profile of the transport path under test, so the impact of the test will not be worse than the impact caused by the customers, whose traffic would be sent over that transport path, sending the traffic at the maximum rate allowed by their traffic profiles. Therefore, throughput tests are not applicable to transport paths that do not have a defined traffic profile, such as LSPs in a context where statistical multiplexing is leveraged for network capacity dimensioning.
吞吐量测试会在网络中造成拥塞，从而影响其他传输路径。但是，测试流量应符合被测试传输路径的流量配置文件，因此测试的影响不会比客户造成的影响更严重，客户的流量将通过该传输路径发送，并以其流量配置文件允许的最大速率发送流量。因此，吞吐量测试不适用于没有定义的流量配置文件的传输路径，例如在利用统计多路复用来确定网络容量的上下文中的lsp。
For a one-way test, the remote sink MEP receives the OAM test packets and calculates the packet loss. For a two-way test, the remote MEP loops the OAM test packets back to the original MEP, and the local sink MEP calculates the packet loss.
对于单向测试，远程接收器MEP接收OAM测试数据包并计算数据包丢失。对于双向测试，远程MEP将OAM测试数据包循环回原始MEP，本地接收器MEP计算数据包丢失。
It is worth noting that two-way throughput estimation is only applicable to bidirectional (co-routed or associated) transport paths and can only evaluate the minimum of available throughput of the two directions. In order to estimate the throughput of each direction uniquely, two one-way throughput estimation sessions have to be set up. One-way throughput estimation requires coordination between the transmitting and receiving test devices as described in Section 6 of RFC 2544 [12].
值得注意的是，双向吞吐量估计仅适用于双向（共路由或关联）传输路径，并且只能评估两个方向的最小可用吞吐量。为了唯一地估计每个方向的吞吐量，必须设置两个单向吞吐量估计会话。单向吞吐量估计需要发送和接收测试设备之间的协调，如RFC 2544[12]第6节所述。
It is also worth noting that if throughput estimation is performed on transport paths that transit oversubscribed links, the test may not produce comprehensive results if viewed in isolation because the
还值得注意的是，如果在传输超额订阅链路的传输路径上执行吞吐量估计，则如果单独查看，测试可能不会产生全面的结果，因为
impact of the test on the surrounding traffic needs to also be considered. Moreover, the estimation will only reflect the bandwidth available at the moment when the measure is made.
还需要考虑测试对周围交通的影响。此外，估计将仅反映在进行测量时可用的带宽。
MIPs that are not targeted by on-demand test OAM packets, as well as intermediate nodes, do not process the throughput test information; they forward these on-demand test OAM packets as regular data packets.
非按需测试OAM包目标的MIP以及中间节点不处理吞吐量测试信息；它们将这些按需测试OAM数据包作为常规数据包转发。
Throughput estimation is an out-of-service tool. The diagnosed MEG should be put into a locked state before the diagnostic test is started.
吞吐量估计是一种停止使用的工具。诊断测试开始前，应将诊断的MEG置于锁定状态。
A MEG can be put into a locked state either via an NMS action or using the Lock Instruct OAM tool as defined in Section 7.
可以通过NMS操作或使用第7节中定义的锁定指令OAM工具将MEG置于锁定状态。
At the transmitting MEP, provisioning is required for a test signal generator that is associated with the MEP. At a receiving MEP, provisioning is required for a test signal detector that is associated with the MEP.
在发送MEP时，需要为与MEP相关联的测试信号发生器进行配置。在接收MEP时，需要对与MEP相关联的测试信号检测器进行配置。
In order to ensure accurate measurement, care needs to be taken to enable throughput estimation only if all the MEPs within the MEG can process OAM test packets at the same rate as the payload data rates (see Section 6.3.1.2).
为了确保准确测量，只有当MEG内的所有MEP能够以与有效负载数据速率相同的速率处理OAM测试数据包时，才需要注意启用吞吐量估计（见第6.3.1.2节）。
If an implementation is able to process payload at much higher data rates than OAM test packets, then accurate measurement of throughput using OAM test packets is not achievable. Whether OAM packets can be processed at the same rate as payload is implementation dependent.
如果一个实现能够以比OAM测试数据包高得多的数据速率处理有效负载，那么使用OAM测试数据包精确测量吞吐量是不可能的。OAM数据包能否以与有效负载相同的速率处理取决于实现。
If multilink is used, then it may not be possible to perform throughput measurement, as the throughput test may not have a mechanism for utilizing more than one component link of the aggregated link.
如果使用多链路，则可能无法执行吞吐量测量，因为吞吐量测试可能没有利用聚合链路的多个组件链路的机制。
Data-plane loopback is an out-of-service function, as required in Section 2.2.5 of RFC 5860 [11]. This function consists in placing a transport path, at either an intermediate or terminating node, into a data-plane loopback state, such that all traffic (including both
根据RFC 5860[11]第2.2.5节的要求，数据平面环回是一项停用功能。此功能包括将中间或终止节点处的传输路径置于数据平面环回状态，以便所有通信量（包括两者
payload and OAM) received on the looped back interface is sent on the reverse direction of the transport path. The traffic is looped back unmodified except for normal per-hop processing such as TTL decrement.
在环回接口上接收的有效负载（payload and OAM）在传输路径的相反方向上发送。除了正常的每跳处理（如TTL减量）之外，通信量是不加修改地环回的。
The data-plane loopback function requires that the MEG is locked such that user data traffic is prevented from entering/exiting that MEG. Instead, test traffic is inserted at the ingress of the MEG. This test traffic can be generated from an internal process residing within the ingress node or injected by external test equipment connected to the ingress node.
数据平面环回功能要求锁定MEG，以防止用户数据流量进入/退出该MEG。相反，在MEG入口插入测试流量。该测试流量可由驻留在入口节点内的内部进程生成，或由连接到入口节点的外部测试设备注入。
It is also normal to disable proactive monitoring of the path as the MEP located upstream with respect to the node set in the data-plane loopback mode will see all the OAM packets originated by itself, and this may interfere with other measurements.
禁用对路径的主动监视也是正常的，因为相对于在数据平面环回模式中设置的节点，位于上游的MEP将看到由其自身发起的所有OAM分组，并且这可能会干扰其他测量。
The only way to send an OAM packet (e.g., to remove the data-plane loopback state) to the MIPs or MEPs hosted by a node set in the data-plane loopback mode is via TTL expiry. It should also be noted that MIPs can be addressed with more than one TTL value on a co-routed bidirectional path set into data-plane loopback.
将OAM数据包（例如，移除数据平面环回状态）发送到由数据平面环回模式中的节点集托管的MIPs或MEP的唯一方法是通过TTL到期。还应注意，MIPs可以在设置为数据平面环回的共路由双向路径上使用多个TTL值进行寻址。
If the loopback function is to be performed at an intermediate node, it is only applicable to co-routed bidirectional paths. If the loopback is to be performed end to end, it is applicable to both co-routed bidirectional and associated bidirectional paths.
如果要在中间节点上执行环回功能，则它仅适用于共同路由的双向路径。如果要端到端执行环回，则它适用于共同路由的双向路径和相关联的双向路径。
It should be noted that data-plane loopback function itself is applied to data-plane loopback points that can reside on different interfaces from MIPs/MEPs. Where a node implements data-plane loopback capability and whether it implements it in more than one point is implementation dependent.
应该注意的是，数据平面环回功能本身应用于数据平面环回点，这些点可以位于MIPs/MEPs的不同接口上。节点实现数据平面环回功能的位置，以及它是否在多个点实现它取决于实现。
Data-plane loopback is an out-of-service tool. The MEG that defines a diagnosed transport path should be put into a locked state before the diagnostic test is started. However, a means is required to permit the originated test traffic to be inserted at the ingress MEP when data-plane loopback is performed.
数据平面环回是一种停止使用的工具。在开始诊断测试之前，定义诊断传输路径的MEG应处于锁定状态。然而，当执行数据平面环回时，需要一种方法来允许在入口MEP处插入原始测试通信量。
A transport path, at either an intermediate or terminating node, can be put into data-plane loopback state via an NMS action or using an OAM tool for data-plane loopback configuration.
可以通过NMS操作或使用用于数据平面环回配置的OAM工具将中间节点或终端节点处的传输路径置于数据平面环回状态。
If the data-plane loopback point is set somewhere at an intermediate point of a co-routed bidirectional transport path, the side of the loopback function (east/west side or both sides) needs to be configured.
如果数据平面环回点设置在共同路由的双向传输路径的中间点的某处，则需要配置环回功能的一侧（东/西侧或两侧）。
It is often necessary to trace a route covered by a MEG from an originating MEP to the peer MEP(s) including all the MIPs in between. This may be conducted after provisioning an MPLS-TP transport path for, e.g., troubleshooting purposes such as fault localization.
通常有必要跟踪MEG覆盖的路由，从原始MEP到对等MEP，包括中间的所有MIP。这可以在提供MPLS-TP传输路径以用于故障定位等故障排除目的后进行。
The route tracing function, as required in Section 2.2.4 of RFC 5860 [11], is providing this functionality. Based on the fate-sharing requirement of OAM flows, i.e., OAM packets receive the same forwarding treatment as data packets, route tracing is a basic means to perform connectivity verification and, to a much lesser degree, continuity check. For this function to work properly, a return path must be present.
RFC 5860[11]第2.2.4节要求的路线跟踪功能提供了该功能。基于OAM流的命运共享需求，即OAM分组接收与数据分组相同的转发处理，路由跟踪是执行连接性验证以及（在较小程度上）连续性检查的基本手段。要使此函数正常工作，必须存在返回路径。
Route tracing might be implemented in different ways, and this document does not preclude any of them.
路由跟踪可能以不同的方式实现，本文档不排除任何方式。
Route tracing should always discover the full list of MIPs and of peer MEPs. In case a defect exists, the route tracing function will only be able to trace up to the defect, and it needs to be able to return the incomplete list of OAM entities that it was able to trace so that the fault can be localized.
路由跟踪应始终发现MIP和对等MEP的完整列表。如果存在缺陷，路由跟踪功能将只能跟踪到缺陷，并且它需要能够返回能够跟踪的OAM实体的不完整列表，以便可以定位故障。
The configuration of the route tracing function must at least support the setting of the number of trace attempts before it gives up.
路由跟踪功能的配置必须至少支持在放弃之前设置跟踪尝试次数。
Packet Delay Measurement (DM) is one of the capabilities supported by the MPLS-TP PM function in order to facilitate reporting of QoS information for a transport path, as required in Section 2.2.12 of RFC 5860 [11]. Specifically, on-demand DM is used to measure packet delay and packet delay variation in the transport path monitored by a pair of MEPs during a pre-defined monitoring period.
根据RFC 5860[11]第2.2.12节的要求，数据包延迟测量（DM）是MPLS-TP PM功能支持的功能之一，以便于报告传输路径的QoS信息。具体地说，按需DM用于在预定义的监视周期期间测量由一对mep监视的传输路径中的分组延迟和分组延迟变化。
On-demand DM is performed by sending periodic DM OAM packets from a MEP to a peer MEP and by receiving DM OAM packets from the peer MEP (if a co-routed or associated bidirectional transport path) during a configurable time interval.
按需DM是通过在可配置的时间间隔内从MEP向对等MEP发送周期性DM-OAM分组以及通过从对等MEP（如果是共同路由的或相关联的双向传输路径）接收DM-OAM分组来执行的。
On-demand DM can be operated in two modes:
按需DM可在两种模式下运行：
o One-way: a MEP sends a DM OAM packet to its peer MEP containing all the required information to facilitate one-way packet delay and/or one-way packet delay variation measurements at the peer MEP. Note that this requires precise time synchronization at either MEP by means outside the scope of this framework.
o 单向：MEP向其对等MEP发送DM-OAM分组，该分组包含所有所需信息，以促进对等MEP处的单向分组延迟和/或单向分组延迟变化测量。请注意，这需要通过本框架范围之外的方式在任一MEP进行精确的时间同步。
o Two-way: a MEP sends a DM OAM packet with a DM request to its peer MEP, which replies with a DM OAM packet as a DM response. The request/response DM OAM packets contain all the required information to facilitate two-way packet delay and/or two-way packet delay variation measurements from the viewpoint of the originating MEP.
o 双向：MEP向其对等MEP发送带有DM请求的DM OAM数据包，对等MEP以DM OAM数据包作为DM响应进行响应。请求/响应DM OAM分组包含从发起MEP的观点促进双向分组延迟和/或双向分组延迟变化测量的所有所需信息。
MIPs, as well as intermediate nodes, do not process the DM information; they forward these on-demand DM OAM packets as regular data packets.
MIPs以及中间节点不处理DM信息；它们将这些按需DM-OAM数据包作为常规数据包转发。
In order to support on-demand DM, the beginning and duration of the DM procedures, the transmission rate and, for E-LSPs, the PHB (associated with the DM OAM packets originating from a MEP) need to be configured as part of the DM provisioning. DM OAM packets should be transmitted with the PHB that yields the lowest drop precedence within the measured PHB Scheduling Class (see RFC 3260 [17]).
为了支持按需DM，DM过程的开始和持续时间、传输速率以及对于E-lsp，PHB（与源自MEP的DM OAM分组相关联）需要配置为DM供应的一部分。DM OAM数据包应与PHB一起传输，该PHB在测量的PHB调度类中产生最低的丢弃优先级（参见RFC 3260[17]）。
In order to verify different performances between long and short packets (e.g., due to the processing time), it should be possible for the operator to configure the packet size of the on-demand OAM DM packet.
为了验证长分组和短分组之间的不同性能（例如，由于处理时间），运营商应该能够配置按需OAM-DM分组的分组大小。
The Lock Instruct (LKI) function, as required in Section 2.2.6 of RFC 5860 [11], is a command allowing a MEP to instruct the peer MEP(s) to put the MPLS-TP transport path into a locked condition.
RFC 5860[11]第2.2.6节要求的锁定指令（LKI）功能是一个允许MEP指令对等MEP将MPLS-TP传输路径置于锁定状态的命令。
This function allows single-side provisioning for administratively locking (and unlocking) an MPLS-TP transport path.
此功能允许为管理锁定（和解锁）MPLS-TP传输路径进行单边设置。
Note that it is also possible to administratively lock (and unlock) an MPLS-TP transport path using two-side provisioning, where the NMS administratively puts both MEPs into an administrative lock condition. In this case, the LKI function is not required/used.
注意，还可以使用双边供应来管理性地锁定（和解锁）MPLS-TP传输路径，其中NMS管理性地将两个MEP置于管理性锁定条件。在这种情况下，不需要/使用LKI功能。
MIPs, as well as intermediate nodes, do not process the Lock Instruct information; they forward these on-demand LKI OAM packets as regular data packets.
MIPs以及中间节点不处理锁指令信息；它们将这些按需lkioam分组作为常规数据分组转发。
A MEP, upon receiving a single-side administrative lock command from an NMS, sends an LKI request OAM packet to its peer MEP(s). It also puts the MPLS-TP transport path into a locked state and notifies its client (sub-)layer adaptation function upon the locked condition.
MEP在从NMS接收到单边管理锁命令时，向其对等MEP发送LKI请求OAM数据包。它还将MPLS-TP传输路径置于锁定状态，并在锁定状态下通知其客户端（子）层适配功能。
A MEP, upon receiving an LKI request from its peer MEP, can either accept or reject the instruction and replies to the peer MEP with an LKI reply OAM packet indicating whether or not it has accepted the instruction. This requires either an in-band or out-of-band return path. The LKI reply is needed to allow the MEP to properly report to the NMS the actual result of the single-side administrative lock command.
MEP在接收到来自其对等MEP的LKI请求时，可以接受或拒绝该指令，并使用指示其是否已接受该指令的LKI reply OAM包回复对等MEP。这需要带内或带外返回路径。需要LKI回复，以允许MEP向NMS正确报告单边管理锁命令的实际结果。
If the lock instruction has been accepted, it also puts the MPLS-TP transport path into a locked state and notifies its client (sub-)layer adaptation function upon the locked condition.
如果已接受lock指令，它还将MPLS-TP传输路径置于锁定状态，并在锁定条件下通知其客户端（子）层适配功能。
Note that if the client (sub-)layer is also MPLS-TP, Lock Report (LKR) generation at the client MPLS-TP (sub-)layer is started, as described in Section 5.4.
请注意，如果客户端（子）层也是MPLS-TP，则会在客户端MPLS-TP（子）层启动锁报告（LKR）生成，如第5.4节所述。
A MEP, upon receiving a single-side administrative unlock command from NMS, sends an LKI removal request OAM packet to its peer MEP(s).
MEP从NMS接收到单侧管理解锁命令后，向其对等MEP发送LKI删除请求OAM数据包。
The peer MEP, upon receiving an LKI removal request, can either accept or reject the removal instruction and replies with an LK removal reply OAM packet indicating whether or not it has accepted the instruction. The LKI removal reply is needed to allow the MEP to properly report to the NMS the actual result of the single-side administrative unlock command.
对等MEP在接收到LKI移除请求时，可以接受或拒绝移除指令，并使用指示其是否已接受该指令的LK移除应答OAM分组进行应答。需要LKI移除回复，以允许MEP向NMS正确报告单侧管理解锁命令的实际结果。
If the lock removal instruction has been accepted, it also clears the locked condition on the MPLS-TP transport path and notifies its client (sub-)layer adaptation function of this event.
如果已接受锁移除指令，它还将清除MPLS-TP传输路径上的锁定条件，并将此事件通知其客户端（子）层适配功能。
The MEP that has initiated the LKI clear procedure, upon receiving a positive LKI removal reply, also clears the locked condition on the MPLS-TP transport path and notifies this event to its client (sub-)layer adaptation function.
已启动LKI清除过程的MEP在收到肯定的LKI移除回复后，也会清除MPLS-TP传输路径上的锁定条件，并将此事件通知其客户端（子）层适配功能。
Note that if the client (sub-)layer is also MPLS-TP, Lock Report (LKR) generation at the client MPLS-TP (sub-)layer is terminated, as described in Section 5.4.
请注意，如果客户端（子）层也是MPLS-TP，则客户端MPLS-TP（子）层的锁报告（LKR）生成将终止，如第5.4节所述。
A number of security considerations are important in the context of OAM applications.
在OAM应用程序的上下文中，许多安全注意事项非常重要。
OAM traffic can reveal sensitive information, such as performance data and details, about the current state of the network. Insertion or modification of OAM transactions can mask the true operational state of the network, and in the case of transactions for administration control, such as lock or data-plane loopback instructions, these can be used for explicit denial-of-service attacks. The effect of such attacks is mitigated only by the fact that, for in-band messaging, the managed entities whose state can be masked is limited to those that transit the point of malicious access to the network internals due to the fate-sharing nature of OAM messaging. This is not true when an out-of-band return path is employed.
OAM流量可以揭示有关网络当前状态的敏感信息，如性能数据和详细信息。插入或修改OAM事务可能会掩盖网络的真实操作状态，对于用于管理控制的事务（如锁或数据平面环回指令），这些事务可用于明确的拒绝服务攻击。对于带内消息传递，由于OAM消息传递的命运共享性质，可以屏蔽其状态的受管实体仅限于那些将恶意访问点转移到网络内部的实体，这一事实才减轻了此类攻击的影响。当采用带外返回路径时，情况并非如此。
The sensitivity of OAM data therefore suggests that one solution is that some form of authentication, authorization, and encryption is in place. This will prevent unauthorized access to vital equipment, and it will prevent third parties from learning about sensitive information about the transport network. However, it should be observed that the combination of the frequency of some OAM transactions, the need for timeliness of OAM transaction exchange, and all permutations of unique MEP to MEP, MEP to MIP, and intermediate-system-originated transactions mitigates against the practical establishment and maintenance of a large number of security associations per MEG either in advance or as required.
因此，OAM数据的敏感性表明，一种解决方案是采用某种形式的身份验证、授权和加密。这将防止未经授权访问重要设备，并防止第三方了解有关传输网络的敏感信息。但是，应注意的是，某些OAM交易的频率、OAM交易交换的及时性需求以及唯一MEP到MEP、MEP到MIP的所有排列组合，中间系统发起的交易缓解了提前或按要求为每个MEG建立和维护大量安全关联的实际困难。
For this reason, it is assumed that the internal links of the network are physically secured from malicious access such that OAM transactions scoped to fault and performance management of individual MEGs are not encumbered with additional security. Further, it is assumed in multi-provider cases where OAM transactions originate outside of an individual provider's trusted domain that filtering mechanisms or further encapsulation will need to constrain the potential impact of malicious transactions. Mechanisms that the framework does not specify might be subject to additional security considerations.
因此，假设网络的内部链路在物理上受到保护，不受恶意访问的影响，从而使各个MEG的故障和性能管理范围内的OAM事务不会受到额外安全性的影响。此外，假设在多提供商情况下，OAM事务起源于单个提供商的受信任域之外，过滤机制或进一步封装将需要限制恶意事务的潜在影响。框架未指定的机制可能需要额外的安全考虑。
In case of misconfiguration, some nodes can receive OAM packets that they cannot recognize. In such a case, these OAM packets should be silently discarded in order to avoid malfunctions whose effects may
在配置错误的情况下，一些节点可以接收它们无法识别的OAM数据包。在这种情况下，这些OAM数据包应该被悄悄地丢弃，以避免可能产生影响的故障
be similar to malicious attacks (e.g., degraded performance or even failure). Further considerations about data-plane attacks via G-ACh are provided in RFC 5921 [8].
类似于恶意攻击（例如，性能下降甚至失败）。RFC 5921[8]中提供了关于通过G-ACh进行数据平面攻击的进一步考虑。
The authors would like to thank all members of the teams (the Joint Working Team, the MPLS Interoperability Design Team in IETF, and the Ad Hoc Group on MPLS-TP in ITU-T) involved in the definition and specification of the MPLS Transport Profile.
作者要感谢参与MPLS传输概要定义和规范的所有团队成员（联合工作团队、IETF中的MPLS互操作性设计团队和ITU-T中的MPLS-TP特设小组）。
The editors gratefully acknowledge the contributions of Adrian Farrel, Yoshinori Koike, Luca Martini, Yuji Tochio, and Manuel Paul for the definition of per-interface MIPs and MEPs.
编辑们感谢Adrian Farrel、Yoshinori Koike、Luca Martini、Yuji Tochio和Manuel Paul对每接口MIPs和MEP定义的贡献。
The editors gratefully acknowledge the contributions of Malcolm Betts, Yoshinori Koike, Xiao Min, and Maarten Vissers for the Lock Report and Lock Instruct descriptions.
编辑们衷心感谢马尔科姆·贝茨、小池吉诺里、肖敏和马丁·维瑟斯对锁报告和锁说明的贡献。
The authors would also like to thank Alessandro D'Alessandro, Loa Andersson, Malcolm Betts, Dave Black, Stewart Bryant, Rui Costa, Xuehui Dai, John Drake, Adrian Farrel, Dan Frost, Xia Liang, Liu Gouman, Peng He, Russ Housley, Feng Huang, Su Hui, Yoshionori Koike, Thomas Morin, George Swallow, Yuji Tochio, Curtis Villamizar, Maarten Vissers, and Xuequin Wei for their comments and enhancements to the text.
作者还要感谢亚历山德罗·德亚历山德罗、洛亚·安德森、马尔科姆·贝茨、戴夫·布莱克、斯图尔特·布莱恩特、芮·科斯塔、戴学慧、约翰·德雷克、阿德里安·法雷尔、丹·弗罗斯特、夏亮、刘古曼、彭和、罗斯·霍斯利、凤凰、苏晖、小池吉奥尼、托马斯·莫林、乔治·斯沃洛、托奇奥、柯蒂斯·维拉米扎、马尔滕·维瑟斯、，以及魏雪昆对文本的评论和改进。
[1] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[1] Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[2] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[2] Bryant，S.，Ed.，和P.Pate，Ed.，“伪线仿真边到边（PWE3）架构”，RFC 3985，2005年3月。
[3] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[3] Nadeau，T.，Ed.，和C.Pignataro，Ed.，“伪线虚拟电路连接验证（VCCV）：伪线的控制通道”，RFC 5085，2007年12月。
[4] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009.
[4] Bocci，M.和S.Bryant，“多段伪线边到边仿真的体系结构”，RFC 5659，2009年10月。
[5] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[5] Niven Jenkins，B.，Ed.，Brungard，D.，Ed.，Betts，M.，Ed.，Sprecher，N.，和S.Ueno，“MPLS传输配置文件的要求”，RFC 56542009年9月。
[6] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003.
[6] Agarwal，P.和B.Akyol，“多协议标签交换（MPLS）网络中的生存时间（TTL）处理”，RFC 3443，2003年1月。
[7] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
[7] Bocci，M.，Ed.，Vigoureux，M.，Ed.，和S.Bryant，Ed.，“MPLS通用关联信道”，RFC 55862009年6月。
[8] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
[8] Bocci，M.，Ed.，Bryant，S.，Ed.，Frost，D.，Ed.，Levrau，L.，和L.Berger，“传输网络中MPLS的框架”，RFC 59212010年7月。
[9] Bocci, M., Levrau, L., and D. Frost, "MPLS Transport Profile User-to-Network and Network-to-Network Interfaces", RFC 6215, April 2011.
[9] Bocci，M.，Levrau，L.，和D.Frost，“MPLS传输配置文件用户到网络和网络到网络接口”，RFC 6215，2011年4月。
[10] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS Transport Profile Data Plane Architecture", RFC 5960, August 2010.
[10] Frost，D.，Ed.，Bryant，S.，Ed.，和M.Bocci，Ed.，“MPLS传输配置文件数据平面架构”，RFC 59602010年8月。
[11] 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.
[11] Vigoureux，M.，Ed.，Ward，D.，Ed.，和M.Betts，Ed.，“MPLS传输网络中的操作、管理和维护（OAM）要求”，RFC 5860，2010年5月。
[12] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
[12] Bradner，S.和J.McQuaid，“网络互连设备的基准测试方法”，RFC 25441999年3月。
[13] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[13] Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[14] ITU-T Recommendation G.806 (01/09), "Characteristics of transport equipment - Description methodology and generic functionality", January 2009.
[14] ITU-T建议G.806（01/09），“运输设备的特性——描述方法和通用功能”，2009年1月。
[15] Sprecher, N. and L. Fang, "An Overview of the OAM Tool Set for MPLS based Transport Networks", Work in Progress, June 2011.
[15] Sprecher，N.和L.Fang，“基于MPLS的传输网络的OAM工具集概述”，正在进行的工作，2011年6月。
[16] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[16] Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[17] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[17] Grossman，D.“区分服务的新术语和澄清”，RFC3260，2002年4月。
[18] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[18] Kompella，K.，Rekhter，Y.，和L.Berger，“MPLS流量工程（TE）中的链路捆绑”，RFC 42012005年10月。
[19] ITU-T Recommendation G.707/Y.1322 (01/07), "Network node interface for the synchronous digital hierarchy (SDH)", January 2007.
[19] ITU-T建议G.707/Y.1322（01/07），“同步数字体系（SDH）的网络节点接口”，2007年1月。
[20] ITU-T Recommendation G.805 (03/00), "Generic functional architecture of transport networks", March 2000.
[20] ITU-T建议G.805（03/00），“传输网络的通用功能架构”，2000年3月。
[21] ITU-T Recommendation Y.1731 (02/08), "OAM functions and mechanisms for Ethernet based networks", February 2008.
[21] ITU-T建议Y.1731（02/08），“基于以太网的网络的OAM功能和机制”，2008年2月。
[22] IEEE Standard 802.1AX-2008, "IEEE Standard for Local and Metropolitan Area Networks - Link Aggregation", November 2008.
[22] IEEE标准802.1AX-2008，“局域网和城域网IEEE标准-链路聚合”，2008年11月。
[23] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[23] Le Faucheur，F.，Wu，L.，Davie，B.，Davari，S.，Vaananen，P.，Krishnan，R.，Cheval，P.，和J.Heinanen，“区分服务的多协议标签交换（MPLS）支持”，RFC 32702002年5月。
[24] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
[24] Bocci，M.，Swallow，G.和E.Gray，“MPLS传输配置文件（MPLS-TP）标识符”，RFC 63702011年9月。
[25] Winter, R., Ed., van Helvoort, H., and M. Betts, "MPLS-TP Identifiers Following ITU-T Conventions", Work in Progress, July 2011.
[25] Winter，R.，Ed.，van Helvoort，H.和M.Betts，“遵循ITU-T公约的MPLS-TP标识符”，正在进行的工作，2011年7月。
Ben Niven-Jenkins Velocix
Ben Niven Jenkins Velocix
EMail: ben@niven-jenkins.co.uk
EMail: ben@niven-jenkins.co.uk
Annamaria Fulignoli Ericsson
安娜玛丽亚·富利诺利·爱立信
EMail: annamaria.fulignoli@ericsson.com
EMail: annamaria.fulignoli@ericsson.com
Enrique Hernandez-Valencia Alcatel-Lucent
恩里克·埃尔南德斯·巴伦西亚阿尔卡特·朗讯
EMail: Enrique.Hernandez@alcatel-lucent.com
EMail: Enrique.Hernandez@alcatel-lucent.com
Lieven Levrau Alcatel-Lucent
利文·莱夫劳·阿尔卡特·朗讯
EMail: Lieven.Levrau@alcatel-lucent.com
EMail: Lieven.Levrau@alcatel-lucent.com
Vincenzo Sestito Alcatel-Lucent
阿尔卡特朗讯公司
EMail: Vincenzo.Sestito@alcatel-lucent.com
EMail: Vincenzo.Sestito@alcatel-lucent.com
Nurit Sprecher Nokia Siemens Networks
诺基亚西门子网络公司
EMail: nurit.sprecher@nsn.com
EMail: nurit.sprecher@nsn.com
Huub van Helvoort Huawei Technologies
Huub van Helvoort华为技术有限公司
EMail: hhelvoort@huawei.com
EMail: hhelvoort@huawei.com
Martin Vigoureux Alcatel-Lucent
马丁·维古鲁·阿尔卡特·朗讯
EMail: Martin.Vigoureux@alcatel-lucent.com
EMail: Martin.Vigoureux@alcatel-lucent.com
Yaacov Weingarten Nokia Siemens Networks
雅科夫·韦恩加滕诺基亚西门子网络公司
EMail: yaacov.weingarten@nsn.com
EMail: yaacov.weingarten@nsn.com
Rolf Winter NEC
罗尔夫冬季NEC
EMail: Rolf.Winter@nw.neclab.eu
EMail: Rolf.Winter@nw.neclab.eu
Authors' Addresses
作者地址
Dave Allan Ericsson
戴夫·艾伦·爱立信
EMail: david.i.allan@ericsson.com
EMail: david.i.allan@ericsson.com
Italo Busi Alcatel-Lucent
伊塔洛-巴西阿尔卡特-朗讯
EMail: Italo.Busi@alcatel-lucent.com
EMail: Italo.Busi@alcatel-lucent.com