Internet Engineering Task Force (IETF) K. Lam
Request for Comments: 5951 Alcatel-Lucent
Category: Standards Track S. Mansfield
ISSN: 2070-1721 E. Gray
Ericsson
September 2010
Internet Engineering Task Force (IETF) K. Lam
Request for Comments: 5951 Alcatel-Lucent
Category: Standards Track S. Mansfield
ISSN: 2070-1721 E. Gray
Ericsson
September 2010
Network Management Requirements for MPLS-based Transport Networks
基于MPLS的传输网络的网络管理要求
Abstract
摘要
This document specifies the requirements for the management of equipment used in networks supporting an MPLS Transport Profile (MPLS-TP). The requirements are defined for specification of network management aspects of protocol mechanisms and procedures that constitute the building blocks out of which the MPLS Transport Profile is constructed. That is, these requirements indicate what management capabilities need to be available in MPLS for use in managing the MPLS-TP. This document is intended to identify essential network management capabilities, not to specify what functions any particular MPLS implementation supports.
本文件规定了支持MPLS传输配置文件（MPLS-TP）的网络中所用设备的管理要求。这些要求是为协议机制和程序的网络管理方面的规范而定义的，这些协议机制和程序构成构建MPLS传输配置文件的构建块。也就是说，这些需求指示了MPLS中需要哪些管理功能，以用于管理MPLS-TP。本文档旨在确定基本的网络管理功能，而不是指定任何特定MPLS实现支持的功能。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5951.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5951.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Terminology ................................................5
2. Management Interface Requirements ...............................7
3. Management Communication Channel (MCC) Requirements .............7
4. Management Communication Network (MCN) Requirements .............7
5. Fault Management Requirements ...................................9
5.1. Supervision Function .......................................9
5.2. Validation Function .......................................10
5.3. Alarm Handling Function ...................................11
5.3.1. Alarm Severity Assignment ..........................11
5.3.2. Alarm Suppression ..................................11
5.3.3. Alarm Reporting ....................................11
5.3.4. Alarm Reporting Control ............................12
6. Configuration Management Requirements ..........................12
6.1. System Configuration ......................................12
6.2. Control Plane Configuration ...............................13
6.3. Path Configuration ........................................13
6.4. Protection Configuration ..................................14
6.5. OAM Configuration .........................................14
7. Performance Management Requirements ............................15
7.1. Path Characterization Performance Metrics .................15
7.2. Performance Measurement Instrumentation ...................16
7.2.1. Measurement Frequency ..............................16
7.2.2. Measurement Scope ..................................17
8. Security Management Requirements ...............................17
8.1. Management Communication Channel Security .................17
8.2. Signaling Communication Channel Security ..................18
8.3. Distributed Denial of Service .............................18
9. Security Considerations ........................................19
10. Acknowledgments ...............................................19
11. References ....................................................19
11.1. Normative References .....................................19
12.2. Informative References ...................................20
Appendix A. Communication Channel (CCh) Examples..................22
Contributor's Address .............................................24
1. Introduction ....................................................4
1.1. Terminology ................................................5
2. Management Interface Requirements ...............................7
3. Management Communication Channel (MCC) Requirements .............7
4. Management Communication Network (MCN) Requirements .............7
5. Fault Management Requirements ...................................9
5.1. Supervision Function .......................................9
5.2. Validation Function .......................................10
5.3. Alarm Handling Function ...................................11
5.3.1. Alarm Severity Assignment ..........................11
5.3.2. Alarm Suppression ..................................11
5.3.3. Alarm Reporting ....................................11
5.3.4. Alarm Reporting Control ............................12
6. Configuration Management Requirements ..........................12
6.1. System Configuration ......................................12
6.2. Control Plane Configuration ...............................13
6.3. Path Configuration ........................................13
6.4. Protection Configuration ..................................14
6.5. OAM Configuration .........................................14
7. Performance Management Requirements ............................15
7.1. Path Characterization Performance Metrics .................15
7.2. Performance Measurement Instrumentation ...................16
7.2.1. Measurement Frequency ..............................16
7.2.2. Measurement Scope ..................................17
8. Security Management Requirements ...............................17
8.1. Management Communication Channel Security .................17
8.2. Signaling Communication Channel Security ..................18
8.3. Distributed Denial of Service .............................18
9. Security Considerations ........................................19
10. Acknowledgments ...............................................19
11. References ....................................................19
11.1. Normative References .....................................19
12.2. Informative References ...................................20
Appendix A. Communication Channel (CCh) Examples..................22
Contributor's Address .............................................24
This document specifies the requirements for the management of equipment used in networks supporting an MPLS Transport Profile (MPLS-TP). The requirements are defined for specification of network management aspects of protocol mechanisms and procedures that constitute the building blocks out of which the MPLS Transport Profile is constructed. That is, these requirements indicate what management capabilities need to be available in MPLS for use in managing the MPLS-TP. This document is intended to identify essential network management capabilities, not to specify what functions any particular MPLS implementation supports.
本文件规定了支持MPLS传输配置文件（MPLS-TP）的网络中所用设备的管理要求。这些要求是为协议机制和程序的网络管理方面的规范而定义的，这些协议机制和程序构成构建MPLS传输配置文件的构建块。也就是说，这些需求指示了MPLS中需要哪些管理功能，以用于管理MPLS-TP。本文档旨在确定基本的网络管理功能，而不是指定任何特定MPLS实现支持的功能。
This document also leverages management requirements specified in ITU-T G.7710/Y.1701 [1] and RFC 4377 [2], and attempts to comply with the guidelines defined in RFC 5706 [15].
本文件还利用了ITU-T G.7710/Y.1701[1]和RFC 4377[2]中规定的管理要求，并试图遵守RFC 5706[15]中定义的指南。
ITU-T G.7710/Y.1701 defines generic management requirements for transport networks. RFC 4377 specifies the operations and management requirements, including operations-and-management-related network management requirements, for MPLS networks.
ITU-T G.7710/Y.1701定义了传输网络的通用管理要求。RFC 4377规定了MPLS网络的运营和管理要求，包括运营和管理相关的网络管理要求。
This document is a product of a joint ITU-T and IETF effort to include an MPLS Transport Profile (MPLS-TP) within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support capabilities and functionality of a transport network as defined by the ITU-T.
本文件是ITU-T和IETF联合努力的产物，旨在将MPLS传输配置文件（MPLS-TP）纳入IETF MPLS和伪线仿真边到边（PWE3）体系结构中，以支持ITU-T定义的传输网络的能力和功能。
The requirements in this document derive from two sources:
本文件中的要求来自两个来源：
1) MPLS and PWE3 architectures as defined by the IETF, and
1) IETF定义的MPLS和PWE3体系结构，以及
2) packet transport networks as defined by the ITU-T.
2) ITU-T定义的分组传输网络。
Requirements for management of equipment in MPLS-TP networks are defined herein. Related functions of MPLS and PWE3 are defined elsewhere (and are out of scope in this document).
本文定义了MPLS-TP网络中设备的管理要求。MPLS和PWE3的相关功能在其他地方定义（不在本文档范围内）。
This document expands on the requirements in ITU-T G.7710/Y.1701 [1] and RFC 4377 [2] to cover fault, configuration, performance, and security management for MPLS-TP networks, and the requirements for object and information models needed to manage MPLS-TP networks and network elements.
本文件扩展了ITU-T G.7710/Y.1701[1]和RFC 4377[2]中的要求，以涵盖MPLS-TP网络的故障、配置、性能和安全管理，以及管理MPLS-TP网络和网元所需的对象和信息模型的要求。
In writing this document, the authors assume the reader is familiar with RFCs 5921 [8] and 5950 [9].
在编写本文件时，作者假设读者熟悉RFCs 5921[8]和5950[9]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [5]. Although this document is not a protocol specification, the use of this language clarifies the instructions to protocol designers producing solutions that satisfy the requirements set out in this document.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[5]中所述进行解释。尽管本文件不是协议规范，但本语言的使用澄清了协议设计师的指示，以生产满足本文件规定要求的解决方案。
Anomaly: The smallest discrepancy that can be observed between actual and desired characteristics of an item. The occurrence of a single anomaly does not constitute an interruption in ability to perform a required function. Anomalies are used as the input for the Performance Monitoring (PM) process and for detection of defects (from [21], Section 3.7).
异常：在一个项目的实际特征和期望特征之间可以观察到的最小差异。单一异常的发生并不构成执行所需功能能力的中断。异常情况用作性能监测（PM）过程和缺陷检测的输入（见[21]，第3.7节）。
Communication Channel (CCh): A logical channel between network elements (NEs) that can be used (for example) for management or control plane applications. The physical channel supporting the CCh is technology specific. See Appendix A.
通信信道（CCh）：网元（NE）之间的逻辑信道，可用于（例如）管理或控制平面应用。支持CCh的物理通道是特定于技术的。见附录A。
Data Communication Network (DCN): A network that supports Layer 1 (physical layer), Layer 2 (data-link layer), and Layer 3 (network layer) functionality for distributed management communications related to the management plane, for distributed signaling communications related to the control plane, and other operations communications (e.g., order-wire/voice communications, software downloads, etc.).
数据通信网络（DCN）：支持第1层（物理层）、第2层（数据链路层）和第3层（网络层）功能的网络，用于与管理平面相关的分布式管理通信、与控制平面相关的分布式信令通信和其他操作通信（例如，订购有线/语音通信、软件下载等）。
Defect: The density of anomalies has reached a level where the ability to perform a required function has been interrupted. Defects are used as input for performance monitoring, the control of consequent actions, and the determination of fault cause (from [21], Section 3.24).
缺陷：异常密度已达到执行所需功能的能力中断的水平。缺陷被用作性能监控、后续行动控制和故障原因确定的输入（见[21]，第3.24节）。
Failure: The fault cause persisted long enough to consider the ability of an item to perform a required function to be terminated. The item may be considered as failed; a fault has now been detected (from [21], Section 3.25).
失败：故障原因持续时间足够长，以考虑项执行所需函数终止的能力。该项目可能被视为失败；现已检测到故障（见[21]，第3.25节）。
Fault: A fault is the inability of a function to perform a required action. This does not include an inability due to preventive maintenance, lack of external resources, or planned actions (from [21], Section 3.26).
故障：故障是指功能无法执行所需操作。这不包括由于预防性维护、缺乏外部资源或计划的行动（见[21]，第3.26节）而导致的无能力。
Fault Cause: A single disturbance or fault may lead to the detection of multiple defects. A fault cause is the result of a correlation process that is intended to identify the defect that is representative of the disturbance or fault that is causing the problem (from [21], Section 3.27).
故障原因：单个干扰或故障可能导致检测到多个缺陷。故障原因是相关过程的结果，旨在识别代表导致问题的干扰或故障的缺陷（见[21]，第3.27节）。
Fault Cause Indication (FCI): An indication of a fault cause.
故障原因指示（FCI）：故障原因指示。
Management Communication Channel (MCC): A CCh dedicated for management plane communications.
管理通信信道（MCC）：专用于管理平面通信的CCh。
Management Communication Network (MCN): A DCN supporting management plane communication is referred to as a Management Communication Network (MCN).
管理通信网络（MCN）：支持管理平面通信的DCN称为管理通信网络（MCN）。
MPLS-TP NE: A network element (NE) that supports the functions of MPLS necessary to participate in an MPLS-TP based transport service. See RFC 5645 [7] for further information on functionality required to support MPLS-TP.
MPLS-TP网元：支持参与基于MPLS-TP的传输服务所需的MPLS功能的网元。有关支持MPLS-TP所需功能的更多信息，请参阅RFC 5645[7]。
MPLS-TP network: a network in which MPLS-TP NEs are deployed.
MPLS-TP网络：部署MPLS-TP网元的网络。
Operations, Administration and Maintenance (OAM), On-Demand and Proactive: One feature of OAM that is largely a management issue is control of OAM; on-demand and proactive are modes of OAM mechanism operation defined in (for example) Y.1731 ([22] - Sections 3.45 and 3.44, respectively) as:
操作、管理和维护（OAM）、按需和主动：OAM的一个主要是管理问题的特性是对OAM的控制；按需和主动是（例如）Y.1731（分别为[22]-第3.45和3.44节）中定义的OAM机制操作模式，如下所示：
o On-demand OAM - OAM actions that are initiated via manual intervention for a limited time to carry out diagnostics. On-demand OAM can result in singular or periodic OAM actions during the diagnostic time interval.
o 按需OAM—在有限的时间内通过手动干预启动以执行诊断的OAM操作。按需OAM可能会在诊断时间间隔内导致单一或周期性OAM操作。
o Proactive OAM - OAM actions that are carried on continuously to permit timely reporting of fault and/or performance status.
o 主动式OAM—持续进行的OAM行动，允许及时报告故障和/或性能状态。
(Note that it is possible for specific OAM mechanisms to only have a sensible use in either on-demand or proactive mode.)
（请注意，特定的OAM机制可能仅在按需或主动模式下合理使用。）
Operations System (OS): A system that performs the functions that support processing of information related to operations, administration, maintenance, and provisioning (OAM&P) for the networks, including surveillance and testing functions to support customer access maintenance.
操作系统（OS）：执行支持处理与网络操作、管理、维护和供应（OAM&P）相关信息的功能的系统，包括支持客户访问维护的监视和测试功能。
Signaling Communication Channel (SCC): A CCh dedicated for control plane communications. The SCC can be used for GMPLS/ASON signaling and/or other control plane messages (e.g., routing messages).
信令通信信道（SCC）：专用于控制平面通信的CCh。SCC可用于GMPLS/ASON信令和/或其他控制平面消息（例如，路由消息）。
Signaling Communication Network (SCN): A DCN supporting control plane communication is referred to as a Signaling Communication Network (SCN).
信令通信网络（SCN）：支持控制平面通信的DCN称为信令通信网络（SCN）。
This document does not specify a preferred management interface protocol to be used as the standard protocol for managing MPLS-TP networks. Managing an end-to-end connection across multiple operator domains where one domain is managed (for example) via NETCONF [16] or SNMP [17], and another domain via CORBA [18], is allowed.
本文件未指定用作管理MPLS-TP网络的标准协议的首选管理接口协议。允许跨多个运营商域管理端到端连接，其中一个域通过NETCONF[16]或SNMP[17]进行管理（例如），另一个域通过CORBA[18]进行管理。
1) For the management interface to the management system, an MPLS-TP NE MAY actively support more than one management protocol in any given deployment.
1) 对于管理系统的管理接口，MPLS-TP NE可以在任何给定部署中主动支持多个管理协议。
For example, an operator can use one protocol for configuration of an MPLS-TP NE and another for monitoring. The protocols to be supported are at the discretion of the operator.
例如，运营商可以使用一种协议配置MPLS-TP网元，使用另一种协议进行监控。待支持的协议由运营商自行决定。
1) Specifications SHOULD define support for management connectivity with remote MPLS-TP domains and NEs, as well as with termination points located in NEs under the control of a third party network operator. See ITU-T G.8601 [23] for example scenarios in multi-carrier, multi-transport technology environments.
1) 规范应定义对与远程MPLS-TP域和网元以及位于第三方网络运营商控制下的网元中的端点的管理连接的支持。参见ITU-T G.8601[23]，了解多载波、多传输技术环境中的示例场景。
2) For management purposes, every MPLS-TP NE MUST connect to an OS. The connection MAY be direct (e.g., via a software, hardware, or proprietary protocol connection) or indirect (via another MPLS-TP NE). In this document, any management connection that is not via another MPLS-TP NE is a direct management connection. When an MPLS-TP NE is connected indirectly to an OS, an MCC MUST be supported between that MPLS-TP NE and any MPLS-TP NE(s) used to provide the connection to an OS.
2) 出于管理目的，每个MPLS-TP网元必须连接到操作系统。连接可以是直接的（例如，通过软件、硬件或专有协议连接）或间接的（通过另一个MPLS-tpne）。在本文档中，不通过另一个MPLS-TP网元的任何管理连接都是直接管理连接。当MPLS-TP NE间接连接到操作系统时，该MPLS-TP NE和用于提供到操作系统的连接的任何MPLS-TP NE之间必须支持MCC。
Entities of the MPLS-TP management plane communicate via a DCN, or more specifically via the MCN. The MCN connects management systems with management systems, management systems with MPLS-TP NEs, and (in the indirect connectivity case discussed in section 3) MPLS-TP NEs with MPLS-TP NEs.
MPLS-TP管理平面的实体经由DCN通信，或者更具体地经由MCN通信。MCN将管理系统与管理系统、管理系统与MPLS-TP网元以及（在第3节讨论的间接连接情况下）MPLS-TP网元与MPLS-TP网元连接起来。
RFC 5586 [14] defines a Generic Associated Channel (G-ACh) to enable the realization of a communication channel (CCh) between adjacent MPLS-TP NEs for management and control. RFC 5718 [10] describes how the G-ACh can be used to provide infrastructure that forms part of the MCN and SCN. It also explains how MCN and SCN messages are encapsulated, carried on the G-ACh, and decapsulated for delivery to management or signaling/routing control plane components on a label switching router (LSR).
RFC 5586[14]定义了通用关联信道（G-ACh），以实现相邻MPLS-TP网元之间的通信信道（CCh），用于管理和控制。RFC 5718[10]描述了G-ACh如何用于提供构成MCN和SCN一部分的基础设施。它还解释了MCN和SCN消息如何被封装、携带在G-ACh上，以及如何被解封以交付给标签交换路由器（LSR）上的管理或信令/路由控制平面组件。
Section 7 of ITU-T G.7712/Y.1703 [6] describes the transport DCN architecture and requirements as follows:
ITU-T G.7712/Y.1703[6]第7节描述了传输DCN架构和要求，如下所示：
1) The MPLS-TP MCN MUST support the requirements for:
1) MPLS-TP MCN必须支持以下要求：
a) CCh access functions specified in Section 7.1.1;
a) 第7.1.1节规定的CCh访问功能；
b) MPLS-TP SCC data-link layer termination functions specified in Section 7.1.2.3;
b) 第7.1.2.3节规定的MPLS-TP SCC数据链路层终端功能；
c) MPLS-TP MCC data-link layer termination functions specified in Section 7.1.2.4;
c) 第7.1.2.4节规定的MPLS-TP MCC数据链路层终端功能；
d) Network layer PDU into CCh data-link frame encapsulation functions specified in Section 7.1.3;
d) 第7.1.3节规定的网络层PDU到CCh数据链路帧封装功能；
e) Network layer PDU forwarding (Section 7.1.6), interworking (Section 7.1.7), and encapsulation (Section 7.1.8) functions, as well as tunneling (Section 7.1.9) and routing (Section 7.1.10) functions.
e) 网络层PDU转发（第7.1.6节）、互通（第7.1.7节）和封装（第7.1.8节）功能，以及隧道（第7.1.9节）和路由（第7.1.10节）功能。
As a practical matter, MCN connections will typically have addresses. See the section on Identifiers in RFC 5921 [8] for further information.
实际上，MCN连接通常具有地址。有关更多信息，请参阅RFC 5921[8]中关于标识符的部分。
In order to have the MCN operate properly, a number of management functions for the MCN are needed, including:
为了使MCN正常运行，需要MCN的许多管理功能，包括：
o Retrieval of DCN network parameters to ensure compatible functioning, e.g., packet size, timeouts, quality of service, window size, etc.;
o 检索DCN网络参数，以确保兼容功能，例如数据包大小、超时、服务质量、窗口大小等。；
o Establishment of message routing between DCN nodes;
o 在DCN节点之间建立消息路由；
o Management of DCN network addresses;
o 管理DCN网络地址；
o Retrieval of operational status of the DCN at a given node;
o 检索给定节点上DCN的运行状态；
o Capability to enable/disable access by an NE to the DCN. Note that this is to allow the isolation of a malfunctioning NE to keep it from impacting the rest of the network.
o 能够启用/禁用网元对DCN的访问。请注意，这是为了隔离发生故障的网元，防止其影响网络的其余部分。
The Fault Management functions within an MPLS-TP NE enable the supervision, detection, validation, isolation, correction, and reporting of abnormal operation of the MPLS-TP network and its environment.
MPLS-TP网元内的故障管理功能能够对MPLS-TP网络及其环境的异常运行进行监视、检测、验证、隔离、纠正和报告。
The supervision function analyzes the actual occurrence of a disturbance or fault for the purpose of providing an appropriate indication of performance and/or detected fault condition to maintenance personnel and operations systems.
监控功能分析干扰或故障的实际发生情况，以便向维护人员和操作系统提供性能和/或检测到的故障状况的适当指示。
1) The MPLS-TP NE MUST support supervision of the OAM mechanisms that are deployed for supporting the OAM requirements defined in RFC 5860 [3].
1) MPLS-TP网元必须支持对为支持RFC 5860[3]中定义的OAM需求而部署的OAM机制的监督。
2) The MPLS-TP NE MUST support the following data-plane forwarding path supervision functions:
2) MPLS-TP网元必须支持以下数据平面转发路径监控功能：
a) Supervision of loop-checking functions used to detect loops in the data-plane forwarding path (which result in non-delivery of traffic, wasting of forwarding resources, and unintended self-replication of traffic);
a) 监督循环检查功能，用于检测数据平面转发路径中的循环（这会导致未交付流量、浪费转发资源和意外的流量自复制）；
b) Supervision of failure detection;
b) 故障检测的监督；
3) The MPLS-TP NE MUST support the capability to configure data-plane forwarding path related supervision mechanisms to perform on-demand or proactively.
3) MPLS-TP网元必须支持配置数据平面转发路径相关监控机制的能力，以按需或主动执行。
4) The MPLS-TP NE MUST support supervision for software processing -- e.g., processing faults, storage capacity, version mismatch, corrupted data, and out of memory problems, etc.
4) MPLS-TP网元必须支持对软件处理的监控——例如，处理故障、存储容量、版本不匹配、数据损坏和内存不足问题等。
5) The MPLS-TP NE MUST support hardware-related supervision for interchangeable and non-interchangeable unit, cable, and power problems.
5) MPLS-TP网元必须支持针对可互换和不可互换单元、电缆和电源问题的硬件相关监控。
6) The MPLS-TP NE SHOULD support environment-related supervision for temperature, humidity, etc.
6) MPLS-TP网元应支持与环境相关的温度、湿度等监控。
Validation is the process of integrating Fault Cause indications into Failures. A Fault Cause Indication (FCI) indicates a limited interruption of the required transport function. A Fault Cause is not reported to maintenance personnel because it might exist only for a very short period of time. Note that some of these events are summed up in the Performance Monitoring process (see Section 7), and when this sum exceeds a configured value, a threshold crossing alert (report) can be generated.
验证是将故障原因指示集成到故障中的过程。故障原因指示（FCI）表示所需传输功能的有限中断。故障原因不会报告给维护人员，因为它可能只存在很短的时间。请注意，其中一些事件在性能监控过程中汇总（请参阅第7节），当此汇总超过配置值时，可以生成阈值交叉警报（报告）。
When the Fault Cause lasts long enough, an inability to perform the required transport function arises. This failure condition is subject to reporting to maintenance personnel and/or an OS because corrective action might be required. Conversely, when the Fault Cause ceases after a certain time, clearing of the Failure condition is also subject to reporting.
当故障原因持续时间足够长时，会出现无法执行所需传输功能的情况。由于可能需要采取纠正措施，因此应向维护人员和/或操作系统报告此故障情况。相反，当故障原因在一段时间后停止时，故障条件的清除也需要报告。
1) The MPLS-TP NE MUST perform persistency checks on fault causes before it declares a fault cause a failure.
1) MPLS-TP网元在声明故障原因为故障之前，必须对故障原因执行持久性检查。
2) The MPLS-TP NE SHOULD provide a configuration capability for control parameters associated with performing the persistency checks described above.
2) MPLS-TP网元应提供与执行上述持久性检查相关联的控制参数的配置能力。
3) An MPLS-TP NE MAY provide configuration parameters to control reporting and clearing of failure conditions.
3) MPLS-TP网元可以提供配置参数来控制故障条件的报告和清除。
4) A data-plane forwarding path failure MUST be declared if the fault cause persists continuously for a configurable time (Time-D). The failure MUST be cleared if the fault cause is absent continuously for a configurable time (Time-C).
4) 如果故障原因持续存在一段可配置时间（time-D），则必须声明数据平面转发路径故障。如果故障原因在可配置的时间（time-C）内持续不存在，则必须清除故障。
Note: As an example, the default time values might be as follows:
注意：例如，默认时间值可能如下所示：
Time-D = 2.5 +/- 0.5 seconds
Time-D = 2.5 +/- 0.5 seconds
Time-C = 10 +/- 0.5 seconds
Time-C = 10 +/- 0.5 seconds
These time values are as defined in G.7710 [1].
这些时间值如G.7710[1]所定义。
5) MIBs - or other object management semantics specifications - defined to enable configuration of these timers SHOULD explicitly provide default values and MAY provide guidelines on ranges and value determination methods for scenarios where the default value chosen might be inadequate. In addition, such specifications SHOULD define the level of granularity at which tables of these values are to be defined.
5) 定义用于启用这些计时器配置的MIB（或其他对象管理语义规范）应明确提供默认值，并可为选择的默认值可能不足的场景提供范围和值确定方法的指南。此外，此类规范应定义定义这些值表的粒度级别。
6) Implementations MUST provide the ability to configure the preceding set of timers and SHOULD provide default values to enable rapid configuration. Suitable default values, timer ranges, and level of granularity are out of scope in this document and form part of the specification of fault management details. Timers SHOULD be configurable per NE for broad categories (for example, defects and/or fault causes), and MAY be configurable per-interface on an NE and/or per individual defect/fault cause.
6) 实现必须提供配置前一组计时器的能力，并应提供默认值以启用快速配置。适当的默认值、计时器范围和粒度级别超出了本文档的范围，并构成故障管理详细信息规范的一部分。定时器应针对广泛的类别（例如，缺陷和/或故障原因）针对每个网元进行配置，并且可以针对每个网元接口和/或每个单独的缺陷/故障原因进行配置。
7) The failure declaration and clearing MUST be time stamped. The time-stamp MUST indicate the time at which the fault cause is activated at the input of the fault cause persistency (i.e., defect-to-failure integration) function, and the time at which the fault cause is deactivated at the input of the fault cause persistency function.
7) 故障声明和清除必须有时间戳。时间戳必须指示在故障原因持续性（即，缺陷-故障集成）功能输入时激活故障原因的时间，以及在故障原因持续性功能输入时停用故障原因的时间。
Failures can be categorized to indicate the severity or urgency of the fault.
可以对故障进行分类，以指示故障的严重性或紧急性。
1) An MPLS-TP NE SHOULD support the ability to assign severity (e.g., Critical, Major, Minor, Warning) to alarm conditions via configuration.
1) MPLS-TP网元应支持通过配置将严重性（例如，严重、严重、轻微、警告）分配给报警条件的能力。
See G.7710 [1], Section 7.2.2 for more detail on alarm severity assignment. For additional discussion of Alarm Severity management, see discussion of alarm severity in RFC 3877 [11].
有关警报严重性分配的更多详情，请参见G.7710[1]，第7.2.2节。有关警报严重性管理的更多讨论，请参阅RFC 3877[11]中的警报严重性讨论。
Alarms can be generated from many sources, including OAM, device status, etc.
警报可以从许多来源生成，包括OAM、设备状态等。
1) An MPLS-TP NE MUST support suppression of alarms based on configuration.
1) MPLS-TP网元必须支持基于配置的报警抑制。
Alarm Reporting is concerned with the reporting of relevant events and conditions, which occur in the network (including the NE, incoming signal, and external environment).
报警报告涉及报告网络（包括网元、传入信号和外部环境）中发生的相关事件和条件。
Local reporting is concerned with automatic alarming by means of audible and visual indicators near the failed equipment.
本地报告涉及通过故障设备附近的声光指示器进行自动报警。
1) An MPLS-TP NE MUST support local reporting of alarms.
1) MPLS-TP网元必须支持本地报警报告。
2) The MPLS-TP NE MUST support reporting of alarms to an OS. These reports are either autonomous reports (notifications) or reports on request by maintenance personnel. The MPLS-TP NE SHOULD report local (environmental) alarms to a network management system.
2) MPLS-TP网元必须支持向操作系统报告警报。这些报告是自主报告（通知）或维修人员要求的报告。MPLS-TP网元应向网络管理系统报告本地（环境）警报。
3) An MPLS-TP NE supporting one or more other networking technologies (e.g., Ethernet, SDH/SONET, MPLS) over MPLS-TP MUST be capable of translating MPLS-TP defects into failure conditions that are meaningful to the client layer, as described in RFC 4377 [2], Section 4.7.
3) 如RFC 4377[2]第4.7节所述，通过MPLS-TP支持一种或多种其他联网技术（如以太网、SDH/SONET、MPLS）的MPLS-TP网元必须能够将MPLS-TP缺陷转化为对客户端层有意义的故障情况。
Alarm Reporting Control (ARC) supports an automatic in-service provisioning capability. Alarm reporting can be turned off on a per-managed entity basis (e.g., LSP) to allow sufficient time for customer service testing and other maintenance activities in an "alarm free" state. Once a managed entity is ready, alarm reporting is automatically turned on.
报警报告控制（ARC）支持自动在用供应功能。报警报告可以按每个管理实体（如LSP）关闭，以便在“无报警”状态下有足够的时间进行客户服务测试和其他维护活动。一旦托管实体就绪，报警报告将自动打开。
1) An MPLS-TP NE SHOULD support the Alarm Reporting Control function for controlling the reporting of alarm conditions.
1) MPLS-TP网元应支持报警报告控制功能，以控制报警条件的报告。
See G.7710 [1] (Section 7.1.3.2) and RFC 3878 [24] for more information about ARC.
有关ARC的更多信息，请参见G.7710[1]（第7.1.3.2节）和RFC 3878[24]。
Configuration Management provides functions to identify, collect data from, provide data to, and control NEs. Specific configuration tasks requiring network management support include hardware and software configuration, configuration of NEs to support transport paths (including required working and protection paths), and configuration of required path integrity/connectivity and performance monitoring (i.e., OAM).
配置管理提供了识别、从网元收集数据、向网元提供数据和控制网元的功能。需要网络管理支持的特定配置任务包括硬件和软件配置、支持传输路径（包括所需的工作和保护路径）的网元配置，以及所需路径完整性/连接性和性能监控（即OAM）的配置。
1) The MPLS-TP NE MUST support the configuration requirements specified in G.7710 [1], Section 8.1 for hardware.
1) MPLS-TP网元必须支持G.7710[1]第8.1节中规定的硬件配置要求。
2) The MPLS-TP NE MUST support the configuration requirements specified in G.7710 [1], Section 8.2 for software.
2) MPLS-TP网元必须支持G.7710[1]第8.2节中规定的软件配置要求。
3) The MPLS-TP NE MUST support the configuration requirements specified in G.7710 [1], Section 8.13.2.1 for local real-time clock functions.
3) MPLS-TP网元必须支持G.7710[1]第8.13.2.1节中规定的本地实时时钟功能的配置要求。
4) The MPLS-TP NE MUST support the configuration requirements specified in G.7710 [1], Section 8.13.2.2 for local real-time clock alignment with external time reference.
4) MPLS-TP网元必须支持G.7710[1]第8.13.2.2节中规定的配置要求，以便与外部时间基准进行本地实时时钟校准。
5) The MPLS-TP NE MUST support the configuration requirements specified in G.7710 [1], Section 8.13.2.3 for performance monitoring of the clock function.
5) MPLS-TP网元必须支持G.7710[1]第8.13.2.3节中规定的时钟功能性能监控配置要求。
1) If a control plane is supported in an implementation of MPLS-TP, the MPLS-TP NE MUST support the configuration of MPLS-TP control plane functions by the management plane. Further detailed requirements will be provided along with progress in defining the MPLS-TP control plane in appropriate specifications.
1) 如果在MPLS-TP的实现中支持控制平面，则MPLS-TP网元必须支持管理平面对MPLS-TP控制平面功能的配置。随着在适当规范中定义MPLS-TP控制平面的进展，将提供进一步的详细要求。
1) In addition to the requirement to support static provisioning of transport paths (defined in RFC 5645 [7], Section 2.1 -- General Requirements, requirement 18), an MPLS-TP NE MUST support the configuration of required path performance characteristic thresholds (e.g., Loss Measurement <LM>, Delay Measurement <DM> thresholds) necessary to support performance monitoring of the MPLS-TP service(s).
1) 除了支持传输路径静态供应的要求（在RFC 5645[7]第2.1节——一般要求，要求18中定义），MPLS-TP网元必须支持所需路径性能特征阈值的配置（例如，损耗测量<LM>，延迟测量<DM>阈值）支持MPLS-TP服务的性能监视所必需的。
2) In order to accomplish this, an MPLS-TP NE MUST support configuration of LSP information (such as an LSP identifier of some kind) and/or any other information needed to retrieve LSP status information, performance attributes, etc.
2) 为了实现这一点，MPLS-TP NE必须支持LSP信息（例如某种LSP标识符）和/或检索LSP状态信息、性能属性等所需的任何其他信息的配置。
3) If a control plane is supported, and that control plane includes support for control-plane/management-plane hand-off for LSP setup/maintenance, the MPLS-TP NE MUST support management of the hand-off of Path control. For example, see RFCs 5943 [19] and 5852 [20].
3) 如果支持控制平面，并且该控制平面包括对用于LSP设置/维护的控制平面/管理平面切换的支持，则MPLS-TP NE必须支持对路径控制切换的管理。例如，参见RFCs 5943[19]和5852[20]。
4) Further detailed requirements SHALL be provided along with progress in defining the MPLS-TP control plane in appropriate specifications.
4) 在适当规范中定义MPLS-TP控制平面的过程中，应提供进一步的详细要求。
5) If MPLS-TP transport paths cannot be statically provisioned using MPLS LSP and pseudowire management tools (either already defined in standards or under development), further management specifications MUST be provided as needed.
5) 如果无法使用MPLS LSP和伪线管理工具（已在标准中定义或正在开发中）静态配置MPLS-TP传输路径，则必须根据需要提供进一步的管理规范。
1) The MPLS-TP NE MUST support configuration of required path protection information as follows:
1) MPLS-TP网元必须支持配置所需的路径保护信息，如下所示：
o designate specifically identified LSPs as working or protecting LSPs;
o 指定专门标识的LSP为工作或保护LSP；
o define associations of working and protecting paths;
o 定义工作和保护路径的关联；
o operate/release manual protection switching;
o 操作/释放手动保护开关；
o operate/release force protection switching;
o 操作/释放力保护开关；
o operate/release protection lockout;
o 操作/释放保护锁定；
o set/retrieve Automatic Protection Switching (APS) parameters, including
o 设置/检索自动保护切换（APS）参数，包括
o Wait to Restore time,
o 等待恢复时间，
o Protection Switching threshold information.
o 保护开关阈值信息。
1) The MPLS-TP NE MUST support configuration of the OAM entities and functions specified in RFC 5860 [3].
1) MPLS-TP网元必须支持RFC 5860[3]中指定的OAM实体和功能的配置。
2) The MPLS-TP NE MUST support the capability to choose which OAM functions are enabled.
2) MPLS-TP网元必须支持选择启用哪些OAM功能的能力。
3) For enabled OAM functions, the MPLS-TP NE MUST support the ability to associate OAM functions with specific maintenance entities.
3) 对于启用的OAM功能，MPLS-TP网元必须支持将OAM功能与特定维护实体关联的能力。
4) The MPLS-TP NE MUST support the capability to configure the OAM entities/functions as part of LSP setup and tear-down, including co-routed bidirectional point-to-point, associated bidirectional point-to-point, and uni-directional (both point-to-point and point-to-multipoint) connections.
4) MPLS-TP网元必须支持将OAM实体/功能配置为LSP设置和拆除的一部分的能力，包括共路由的双向点到点、关联的双向点到点和单向（点到点和点到多点）连接。
5) The MPLS-TP NE MUST support the configuration of maintenance entity identifiers (e.g., MEP ID and MIP ID) for the purpose of LSP connectivity checking.
5) MPLS-TP网元必须支持维护实体标识符（例如，MEP ID和MIP ID）的配置，以便进行LSP连接检查。
6) The MPLS-TP NE MUST support configuration of OAM parameters to meet their specific operational requirements, such as
6) MPLS-TP网元必须支持OAM参数的配置，以满足其特定的操作需求，例如
a) one-time on-demand immediately or
a) 一次性按需立即或
b) one-time on-demand pre-scheduled or
b) 一次性按需预定或
c) on-demand periodically based on a specified schedule or
c) 根据指定的时间表或
d) proactive on-going.
d) 积极的、持续的。
7) The MPLS-TP NE MUST support the enabling/disabling of the connectivity check processing. The connectivity check process of the MPLS-TP NE MUST support provisioning of the identifiers to be transmitted and the expected identifiers.
7) MPLS-TP网元必须支持连接检查处理的启用/禁用。MPLS-TP NE的连接性检查过程必须支持提供要传输的标识符和预期标识符。
Performance Management provides functions for the purpose of maintenance, bring-into-service, quality of service, and statistics gathering.
绩效管理提供了维护、投入使用、服务质量和统计数据收集等功能。
This information could be used, for example, to compare behavior of the equipment, MPLS-TP NE, or network at different moments in time to evaluate changes in network performance.
例如，该信息可用于比较设备、MPLS-TP网元或网络在不同时刻的行为，以评估网络性能的变化。
ITU-T Recommendation G.7710 [1] provides transport performance monitoring requirements for packet-switched and circuit-switched transport networks with the objective of providing a coherent and consistent interpretation of the network behavior in a multi-technology environment. The performance management requirements specified in this document are driven by such an objective.
ITU-T建议G.7710[1]规定了分组交换和电路交换传输网络的传输性能监控要求，目的是为多技术环境中的网络行为提供一致的解释。本文件中规定的绩效管理要求由该目标驱动。
1) It MUST be possible to determine when an MPLS-TP-based transport service is available and when it is unavailable.
1) 必须能够确定基于MPLS TP的传输服务何时可用以及何时不可用。
From a performance perspective, a service is unavailable if there is an indication that performance has degraded to the extent that a configurable performance threshold has been crossed and the degradation persists long enough (i.e., the indication persists for some amount of time, which is either configurable or well-known) to be certain it is not a measurement anomaly.
从性能角度来看，如果有迹象表明性能已降级到超过可配置性能阈值的程度，并且降级持续时间足够长（即，该迹象持续一段时间，可配置或众所周知），则服务不可用可以肯定的是，这不是测量异常。
Methods, mechanisms, and algorithms for exactly how unavailability is to be determined -- based on collection of raw performance data -- are out of scope for this document.
基于原始性能数据的收集，如何准确确定不可用性的方法、机制和算法超出了本文档的范围。
2) The MPLS-TP NE MUST support collection and reporting of raw performance data that MAY be used in determining the unavailability of a transport service.
2) MPLS-TP网元必须支持原始性能数据的收集和报告，这些数据可用于确定传输服务的不可用性。
3) MPLS-TP MUST support the determination of the unavailability of the transport service. The result of this determination MUST be available via the MPLS-TP NE (at service termination points), and determination of unavailability MAY be supported by the MPLS-TP NE directly. To support this requirement, the MPLS-TP NE management information model MUST include objects corresponding to the availability-state of services.
3) MPLS-TP必须支持确定传输服务的不可用性。此确定的结果必须通过MPLS-TP NE（在服务终止点）可用，并且MPLS-TP NE可以直接支持不可用性的确定。为了支持这一需求，MPLS-TP网元管理信息模型必须包括与服务的可用性状态相对应的对象。
Transport network unavailability is based on Severely Errored Seconds (SES) and Unavailable Seconds (UAS). The ITU-T is establishing definitions of unavailability that are generically applicable to packet transport technologies, including MPLS-TP, based on SES and UAS. Note that SES and UAS are already defined for Ethernet transport networks in ITU-T Recommendation Y.1563 [25].
传输网络不可用性基于严重错误秒（SES）和不可用秒（UAS）。ITU-T正在建立一般适用于分组传输技术的不可用性定义，包括基于SES和UAS的MPLS-TP。请注意，在ITU-T建议Y.1563[25]中，已经为以太网传输网络定义了SES和UAS。
4) The MPLS-TP NE MUST support collection of loss measurement (LM) statistics.
4) MPLS-TP网元必须支持损失测量（LM）统计数据的收集。
5) The MPLS-TP NE MUST support collection of delay measurement (DM) statistics.
5) MPLS-TP网元必须支持延迟测量（DM）统计数据的收集。
6) The MPLS-TP NE MUST support reporting of performance degradation via fault management for corrective actions.
6) MPLS-TP网元必须支持通过故障管理报告性能下降，以便采取纠正措施。
"Reporting" in this context could mean:
在这方面，“报告”可能意味着：
o reporting to an autonomous protection component to trigger protection switching,
o 向自主保护组件报告，以触发保护切换，
o reporting via a craft interface to allow replacement of a faulty component (or similar manual intervention),
o 通过工艺界面进行报告，以允许更换故障部件（或类似的手动干预），
o etc.
o 等
7) The MPLS-TP NE MUST support reporting of performance statistics on request from a management system.
7) MPLS-TP网元必须支持根据管理系统的请求报告性能统计数据。
1) For performance measurement mechanisms that support both proactive and on-demand modes, the MPLS-TP NE MUST support the capability to be configured to operate on-demand or proactively.
1) 对于同时支持主动模式和按需模式的性能测量机制，MPLS-TP网元必须支持配置为按需或主动操作的能力。
On measurement of packet loss and loss ratio:
关于包丢失和丢失率的测量：
1) For bidirectional (both co-routed and associated) point-to-point (P2P) connections
1) 用于双向（共路由和关联）点到点（P2P）连接
a) on-demand measurement of single-ended packet loss and loss ratio measurement is REQUIRED;
a) 需要单端丢包按需测量和丢包率测量；
b) proactive measurement of packet loss and loss ratio measurement for each direction is REQUIRED.
b) 需要对每个方向的数据包丢失和丢失率进行主动测量。
2) For unidirectional (P2P and point-to-multipoint (P2MP)) connection, proactive measurement of packet loss and loss ratio is REQUIRED.
2) 对于单向（P2P和点对多点（P2MP））连接，需要主动测量数据包丢失和丢失率。
On Delay measurement:
关于延迟测量：
3) For a unidirectional (P2P and P2MP) connection, on-demand measurement of delay measurement is REQUIRED.
3) 对于单向（P2P和P2MP）连接，需要按需测量延迟测量。
4) For a co-routed bidirectional (P2P) connection, on-demand measurement of one-way and two-way delay is REQUIRED.
4) 对于共路由双向（P2P）连接，需要按需测量单向和双向延迟。
5) For an associated bidirectional (P2P) connection, on-demand measurement of one-way delay is REQUIRED.
5) 对于相关的双向（P2P）连接，需要按需测量单向延迟。
1) The MPLS-TP NE MUST support secure management and control planes.
1) MPLS-TP网元必须支持安全的管理和控制平面。
1) Secure communication channels MUST be supported for all network traffic and protocols used to support management functions. This MUST include, at least, protocols used for configuration, monitoring, configuration backup, logging, time synchronization, authentication, and routing.
1) 所有用于支持管理功能的网络流量和协议必须支持安全通信通道。这必须至少包括用于配置、监视、配置备份、日志记录、时间同步、身份验证和路由的协议。
2) The MCC MUST support application protocols that provide confidentiality and data-integrity protection.
2) MCC必须支持提供机密性和数据完整性保护的应用程序协议。
3) The MPLS-TP NE MUST support the following:
3) MPLS-TP网元必须支持以下功能：
a) Use of open cryptographic algorithms (see RFC 3871 [4]).
a) 使用开放加密算法（见RFC 3871[4]）。
b) Authentication - allow management connectivity only from authenticated entities.
b) 身份验证-仅允许来自已验证实体的管理连接。
c) Authorization - allow management activity originated by an authorized entity, using (for example) an Access Control List (ACL).
c) 授权-允许由授权实体发起的管理活动，使用（例如）访问控制列表（ACL）。
d) Port Access Control - allow management activity received on an authorized (management) port.
d) 端口访问控制-允许在授权（管理）端口上接收管理活动。
Security requirements for the SCC are driven by considerations similar to MCC requirements described in Section 8.1.
SCC的安全要求由与第8.1节所述MCC要求类似的考虑因素驱动。
Security Requirements for the control plane are out of scope for this document and are expected to be defined in the appropriate control plane specifications.
控制平面的安全要求不在本文件范围内，预计将在适当的控制平面规范中定义。
1) Management of control plane security MUST be defined in the appropriate control plane specifications.
1) 控制平面安全管理必须在相应的控制平面规范中定义。
A denial-of-service (DoS) attack is an attack that tries to prevent a target from performing an assigned task, or providing its intended service(s), through any means. A Distributed DoS (DDoS) can multiply attack severity (possibly by an arbitrary amount) by using multiple (potentially compromised) systems to act as topologically (and potentially geographically) distributed attack sources. It is possible to lessen the impact and potential for DoS and DDoS by using secure protocols, turning off unnecessary processes, logging and monitoring, and ingress filtering. RFC 4732 [26] provides background on DoS in the context of the Internet.
拒绝服务（DoS）攻击是一种试图通过任何方式阻止目标执行指定任务或提供其预期服务的攻击。分布式拒绝服务（DDoS）可以通过使用多个（可能受到危害的）系统作为拓扑（可能在地理上）分布式攻击源，使攻击严重性成倍增加（可能增加任意数量）。通过使用安全协议、关闭不必要的进程、日志记录和监视以及入口过滤，可以减少DoS和DDoS的影响和可能性。RFC 4732[26]提供了互联网环境下DoS的背景信息。
1) An MPLS-TP NE MUST support secure management protocols and SHOULD do so in a manner that reduces potential impact of a DoS attack.
1) MPLS-TP网元必须支持安全管理协议，并应以减少DoS攻击潜在影响的方式支持。
2) An MPLS-TP NE SHOULD support additional mechanisms that mitigate a DoS (or DDoS) attack against the management component while allowing the NE to continue to meet its primary functions.
2) MPLS-TP网元应支持其他机制，以减轻针对管理组件的DoS（或DDoS）攻击，同时允许网元继续满足其主要功能。
Section 8 includes a set of security requirements that apply to MPLS-TP network management.
第8节包括一组适用于MPLS-TP网络管理的安全要求。
1) Solutions MUST provide mechanisms to prevent unauthorized and/or unauthenticated access to management capabilities and private information by network elements, systems, or users.
1) 解决方案必须提供防止网元、系统或用户未经授权和/或未经授权访问管理功能和私人信息的机制。
Performance of diagnostic functions and path characterization involves extracting a significant amount of information about network construction that the network operator might consider private.
诊断功能和路径特性的性能包括提取网络运营商可能认为私有的关于网络构建的大量信息。
The authors/editors gratefully acknowledge the thoughtful review, comments, and explanations provided by Adrian Farrel, Alexander Vainshtein, Andrea Maria Mazzini, Ben Niven-Jenkins, Bernd Zeuner, Dan Romascanu, Daniele Ceccarelli, Diego Caviglia, Dieter Beller, He Jia, Leo Xiao, Maarten Vissers, Neil Harrison, Rolf Winter, Yoav Cohen, and Yu Liang.
作者/编辑感谢Adrian Farrel、Alexander Vainstein、Andrea Maria Mazzini、Ben Niven Jenkins、Bernd Zeuner、Dan Romascanu、Daniele Ceccarelli、Diego Caviglia、Dieter Beller、何佳、Leo Xiao、Maarten Vissers、Neil Harrison、Rolf Winter、Yoav Cohen、，还有余亮。
[1] ITU-T Recommendation G.7710/Y.1701, "Common equipment management function requirements", July, 2007.
[1] ITU-T建议G.7710/Y.1701，“通用设备管理功能要求”，2007年7月。
[2] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. Matsushima, "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006.
[2] Nadeau，T.，Morrow，M.，Swallow，G.，Allan，D.，和S.Matsushima，“多协议标签交换（MPLS）网络的运营和管理（OAM）要求”，RFC 4377，2006年2月。
[3] 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.
[3] Vigoureux，M.，Ed.，Ward，D.，Ed.，和M.Betts，Ed.，“MPLS传输网络中的操作、管理和维护（OAM）要求”，RFC 5860，2010年5月。
[4] Jones, G., Ed., "Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure", RFC 3871, September 2004.
[4] Jones，G.，Ed.“大型互联网服务提供商（ISP）IP网络基础设施的运营安全要求”，RFC 3871，2004年9月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[6] ITU-T Recommendation G.7712/Y.1703, "Architecture and specification of data communication network", June 2008.
[6] ITU-T建议G.7712/Y.1703，“数据通信网络的体系结构和规范”，2008年6月。
[7] 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.
[7] Niven Jenkins，B.，Ed.，Brungard，D.，Ed.，Betts，M.，Ed.，Sprecher，N.，和S.Ueno，“MPLS传输配置文件的要求”，RFC 56542009年9月。
[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] Mansfield, S. Ed., Gray, E., Ed., and K. Lam, Ed., "Network Management Framework for MPLS-based Transport Networks", RFC 5950, September 2010.
[9] Mansfield，S.Ed.，Gray，E.Ed.，和K.Lam，Ed.，“基于MPLS的传输网络的网络管理框架”，RFC 59502010年9月。
[10] Beller, D. and A. Farrel, "An In-Band Data Communication Network For the MPLS Transport Profile", RFC 5718, January 2010.
[10] Beller，D.和A.Farrel，“MPLS传输模式的带内数据通信网络”，RFC 5718，2010年1月。
[11] Chisholm, S. and D. Romascanu, "Alarm Management Information Base (MIB)", RFC 3877, September 2004.
[11] Chisholm，S.和D.Romascanu，“报警管理信息库（MIB）”，RFC 3877，2004年9月。
[12] ITU-T Recommendation M.20, "Maintenance philosophy for telecommunication networks", October 1992.
[12] ITU-T建议M.20，“电信网络的维护理念”，1992年10月。
[13] Telcordia, "Network Maintenance: Network Element and Transport Surveillance Messages" (GR-833-CORE), Issue 5, August 2004.
[13] Telcordia，“网络维护：网元和传输监视消息”（GR-833-CORE），第5期，2004年8月。
[14] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
[14] Bocci，M.，Ed.，Vigoureux，M.，Ed.，和S.Bryant，Ed.，“MPLS通用关联信道”，RFC 55862009年6月。
[15] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, November 2009.
[15] Harrington，D.“考虑新协议和协议扩展的操作和管理指南”，RFC 5706，2009年11月。
[16] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", Work in Progress, July 2010.
[16] Enns，R.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.，“网络配置协议（NETCONF）”，正在进行的工作，2010年7月。
[17] Presuhn, R., Ed., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
[17] Presohn，R.，Ed.“简单网络管理协议（SNMP）的协议操作第2版”，STD 62，RFC 3416，2002年12月。
[18] OMG Document formal/04-03-12, "The Common Object Request Broker: Architecture and Specification", Revision 3.0.3. March 12, 2004.
[18] OMG文件formal/04-03-12，“公共对象请求代理：架构和规范”，版本3.0.3。2004年3月12日。
[19] Caviglia, D., Bramanti, D., Li, D., and D. McDysan, "Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network", RFC 5493, April 2009.
[19] Caviglia，D.，Bramanti，D.，Li，D.，和D.McDysan，“通用多协议标签交换（GMPLS）网络中永久连接和交换连接之间转换的要求”，RFC 5493，2009年4月。
[20] Caviglia, D., Ceccarelli, D., Bramanti, D., Li, D., and S. Bardalai, "RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network", RFC 5852, April 2010.
[20] Caviglia，D.，Ceccarelli，D.，Bramanti，D.，Li，D.，和S.Bardalai，“在启用GMPLS的传输网络中，用于LSP从管理平面切换到控制平面的RSVP-TE信令扩展”，RFC 5852，2010年4月。
[21] ITU-T Recommendation G.806, "Characteristics of transport equipment - Description methodology and generic functionality", January, 2009.
[21] ITU-T建议G.806，“运输设备的特性——描述方法和通用功能”，2009年1月。
[22] ITU-T Recommendation Y.1731, "OAM functions and mechanisms for Ethernet based networks", February, 2008.
[22] ITU-T建议Y.1731，“基于以太网的网络的OAM功能和机制”，2008年2月。
[23] ITU-T Recommendation G.8601, "Architecture of service management in multi bearer, multi carrier environment", June 2006.
[23] ITU-T建议G.8601，“多承载、多载波环境中的服务管理体系结构”，2006年6月。
[24] Lam, H., Huynh, A., and D. Perkins, "Alarm Reporting Control Management Information Base (MIB)", RFC 3878, September 2004.
[24] Lam，H.，Huynh，A.，和D.Perkins，“报警报告控制管理信息库（MIB）”，RFC 3878，2004年9月。
[25] ITU-T Recommendation Y.1563, "Ethernet frame transfer and availability performance", January 2009.
[25] ITU-T建议Y.1563，“以太网帧传输和可用性性能”，2009年1月。
[26] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[26] Handley，M.，Ed.，Rescorla，E.，Ed.，和IAB，“互联网拒绝服务注意事项”，RFC 47322006年12月。
Appendix A. Communication Channel (CCh) Examples
附录A.通信信道（CCh）示例
A CCh can be realized in a number of ways.
CCh可以通过多种方式实现。
1. The CCh can be provided by a link in a physically distinct network, that is, a link that is not part of the transport network that is being managed. For example, the nodes in the transport network can be interconnected in two distinct physical networks: the transport network and the DCN.
1. CCh可以由物理上不同的网络中的链路提供，即，不属于正在管理的传输网络的一部分的链路。例如，传输网络中的节点可以在两个不同的物理网络中互连：传输网络和DCN。
This is a "physically distinct out-of-band CCh".
这是一个“物理上不同的带外CCh”。
2. The CCh can be provided by a link in the transport network that is terminated at the ends of the DCC and that is capable of encapsulating and terminating packets of the management protocols. For example, in MPLS-TP, a single-hop LSP might be established between two adjacent nodes, and that LSP might be capable of carrying IP traffic. Management traffic can then be inserted into the link in an LSP parallel to the LSPs that carry user traffic.
2. CCh可以由传输网络中的链路提供，该链路在DCC的端部终止，并且能够封装和终止管理协议的分组。例如，在MPLS-TP中，可以在两个相邻节点之间建立单跳LSP，并且该LSP可以承载IP业务。然后，可以将管理流量插入到与承载用户流量的LSP平行的LSP中的链路中。
This is a "physically shared out-of-band CCh."
这是一个“物理共享带外CCh”
3. The CCh can be supported as its native protocol on the interface alongside the transported traffic. For example, if an interface is capable of sending and receiving both MPLS-TP and IP, the IP-based management traffic can be sent as native IP packets on the interface.
3. CCh可以作为其本机协议在传输流量旁边的接口上得到支持。例如，如果接口能够发送和接收MPLS-TP和IP，则基于IP的管理流量可以作为接口上的本机IP数据包发送。
This is a "shared interface out-of-band CCh".
这是一个“带外CCh共享接口”。
4. The CCh can use overhead bytes available on a transport connection. For example, in TDM networks there are overhead bytes associated with a data channel, and these can be used to provide a CCh. It is important to note that the use of overhead bytes does not reduce the capacity of the associated data channel.
4. CCh可以使用传输连接上可用的开销字节。例如，在TDM网络中，存在与数据信道相关联的开销字节，这些字节可用于提供CCh。需要注意的是，开销字节的使用不会降低相关数据通道的容量。
This is an "overhead-based CCh".
这是一个“基于开销的CCh”。
This alternative is not available in MPLS-TP because there is no overhead available.
此替代方案在MPLS-TP中不可用，因为没有可用的开销。
5. The CCh can be provided by a dedicated channel associated with the data link. For example, the generic associated label (GAL) [14] can be used to label DCC traffic being exchanged on a data link between adjacent transport nodes, potentially in the absence of any data LSP between those nodes.
5. CCh可由与数据链路相关联的专用信道提供。例如，通用关联标签（GAL）[14]可用于标记在相邻传输节点之间的数据链路上交换的DCC业务，可能是在这些节点之间没有任何数据LSP的情况下。
This is a "data link associated CCh".
这是一个“与CCh相关的数据链路”。
It is very similar to case 2, and by its nature can only span a single hop in the transport network.
它与情况2非常相似，本质上只能跨越传输网络中的单个跃点。
6. The CCh can be provided by a dedicated channel associated with a data channel. For example, in MPLS-TP, the GAL [14] can be imposed under the top label in the label stack for an MPLS-TP LSP to create a channel associated with the LSP that can carry management traffic. This CCh requires the receiver to be capable of demultiplexing management traffic from user traffic carried on the same LSP by use of the GAL.
6. CCh可以由与数据信道相关联的专用信道提供。例如，在MPLS-TP中，可以将GAL[14]施加在MPLS-TP LSP的标签栈中的顶部标签下，以创建与LSP相关联的可以承载管理业务的信道。该CCh要求接收器能够通过使用GAL将管理通信量从同一LSP上承载的用户通信量解复用。
This is a "data channel associated CCh".
这是一个“与CCh相关的数据通道”。
7. The CCh can be provided by mixing the management traffic with the user traffic such that is indistinguishable on the link without deep-packet inspection. In MPLS-TP, this could arise if there is a data-carrying LSP between two nodes, and management traffic is inserted into that LSP. This approach requires that the termination point of the LSP be able to demultiplex the management and user traffic. This might be possible in MPLS-TP if the MPLS-TP LSP is carrying IP user traffic.
7. CCh可以通过混合管理通信量和用户通信量来提供，使得在没有深度分组检查的情况下在链路上不可区分。在MPLS-TP中，如果两个节点之间有一个承载数据的LSP，并且将管理流量插入该LSP，则可能会出现这种情况。这种方法要求LSP的终止点能够将管理和用户流量解复用。如果MPLS-TP LSP承载IP用户流量，则在MPLS-TP中这可能是可能的。
This is an "in-band CCh".
这是一个“带内CCh”。
These realizations can be categorized as:
这些实现可分为以下几类：
A. Out-of-fiber, out-of-band (types 1 and 2) B. In-fiber, out-of-band (types 2, 3, 4, and 5) C. In-band (types 6 and 7)
A.光纤外、带外（类型1和2）B.光纤内、带外（类型2、3、4和5）C.带内（类型6和7）
The MCN and SCN are logically separate networks and can be realized by the same DCN or as separate networks. In practice, that means that, between any pair of nodes, the MCC and SCC can be the same link or separate links.
MCN和SCN是逻辑上独立的网络，可以通过相同的DCN或作为独立的网络来实现。实际上，这意味着，在任何一对节点之间，MCC和SCC可以是相同的链路或单独的链路。
It is also important to note that the MCN and SCN do not need to be categorised as in-band, out-of-band, etc. This definition only applies to the individual links, and it is possible for some nodes to be connected in the MCN or SCN by one type of link, and other nodes by other types of link. Furthermore, a pair of adjacent nodes can be connected by multiple links of different types.
还需要注意的是，MCN和SCN不需要分类为带内、带外等。该定义仅适用于单个链路，并且一些节点可能通过一种链路类型连接到MCN或SCN中，而其他节点通过其他链路类型连接。此外，一对相邻节点可以通过不同类型的多个链路连接。
Lastly, note that the division of DCN traffic between links between a pair of adjacent nodes is purely an implementation choice. Parallel links can be deployed for DCN resilience or load sharing. Links can be designated for specific use. For example, so that some links
最后，请注意，在一对相邻节点之间的链路之间划分DCN流量纯粹是一种实现选择。可以部署并行链路以实现DCN弹性或负载共享。链接可以指定为特定用途。例如，使某些链接
carry management traffic and some carry control plane traffic, or so that some links carry signaling protocol traffic while others carry routing protocol traffic.
承载管理流量和一些承载控制平面流量，或者某些链路承载信令协议流量，而其他链路承载路由协议流量。
It is important to note that the DCN can be a routed network with forwarding capabilities, but that this is not a requirement. The ability to support forwarding of management or control traffic within the DCN can substantially simplify the topology of the DCN and improve its resilience, but does increase the complexity of operating the DCN.
需要注意的是，DCN可以是具有转发功能的路由网络，但这不是一项要求。支持在DCN内转发管理或控制通信量的能力可以大大简化DCN的拓扑结构并提高其弹性，但确实增加了操作DCN的复杂性。
See also RFC 3877 [11], ITU-T M.20 [12], and Telcordia document GR-833-CORE [13] for further information.
更多信息，请参见RFC 3877[11]、ITU-T M.20[12]和Telcordia文件GR-833-CORE[13]。
Contributor's Address
投稿人地址
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
Adrian Farrel老狗咨询电子邮件：adrian@olddog.co.uk
Authors' Addresses
作者地址
Eric Gray Ericsson 900 Chelmsford Street Lowell, MA, 01851 Phone: +1 978 275 7470 EMail: Eric.Gray@Ericsson.com
Eric Gray Ericsson 900 Chelmsford Street Lowell，MA，01851电话：+1 978 275 7470电子邮件：Eric。Gray@Ericsson.com
Scott Mansfield Ericsson 250 Holger Way San Jose CA, 95134 +1 724 931 9316 EMail: Scott.Mansfield@Ericsson.com
斯科特·曼斯菲尔德·爱立信加利福尼亚州圣何塞霍尔格大道250号，95134+1 724 931 9316电子邮件：斯科特。Mansfield@Ericsson.com
Hing-Kam (Kam) Lam Alcatel-Lucent 600-700 Mountain Ave Murray Hill, NJ, 07974 Phone: +1 908 582 0672 EMail: Kam.Lam@Alcatel-Lucent.com
兴锦（Kam）林阿尔卡特朗讯，新泽西州默里山山路600-700号，邮编07974电话：+1908 582 0672电子邮件：Kam。Lam@Alcatel-朗讯网