Internet Engineering Task Force (IETF) A. Takacs
Request for Comments: 7260 Ericsson
Category: Standards Track D. Fedyk
ISSN: 2070-1721 Hewlett-Packard Company
J. He
Huawei
June 2014
Internet Engineering Task Force (IETF) A. Takacs
Request for Comments: 7260 Ericsson
Category: Standards Track D. Fedyk
ISSN: 2070-1721 Hewlett-Packard Company
J. He
Huawei
June 2014
GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration
用于操作、管理和维护（OAM）配置的GMPLS RSVP-TE扩展
Abstract
摘要
Operations, Administration, and Maintenance (OAM) is an integral part of transport connections; hence, it is required that OAM functions be activated/deactivated in sync with connection commissioning/ decommissioning, in order to avoid spurious alarms and ensure consistent operation. In certain technologies, OAM entities are inherently established once the connection is set up, while other technologies require extra configuration to establish and configure OAM entities. This document specifies extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) to support the establishment and configuration of OAM entities along with Label Switched Path signaling.
运营、管理和维护（OAM）是传输连接的组成部分；因此，需要与连接调试/停用同步激活/停用OAM功能，以避免虚假警报并确保一致运行。在某些技术中，一旦建立了连接，OAM实体就固有地建立起来，而其他技术则需要额外的配置来建立和配置OAM实体。本文档规定了对资源预留协议-流量工程（RSVP-TE）的扩展，以支持OAM实体的建立和配置以及标签交换路径信令。
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/rfc7260.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7260.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
2. Technology-Specific OAM Requirements ............................4
3. RSVP-TE-Based OAM Configuration .................................6
3.1. Establishment of OAM Entities and Functions ................8
3.2. Adjustment of OAM Parameters ..............................10
3.3. Deleting OAM Entities .....................................11
4. RSVP-TE Extensions .............................................11
4.1. LSP Attribute Flags .......................................11
4.2. OAM Configuration TLV .....................................13
4.2.1. OAM Function Flags Sub-TLV .........................14
4.2.2. Technology-Specific Sub-TLVs .......................15
4.3. Administrative Status Information .........................15
4.4. Handling OAM Configuration Errors .........................16
4.5. Considerations on Point-to-Multipoint OAM Configuration ...16
5. IANA Considerations ............................................18
5.1. Admin_Status Object Bit Flags .............................18
5.2. LSP Attribute Flags .......................................18
5.3. New LSP Attributes ........................................19
5.4. RSVP Error Code ...........................................19
5.5. RSVP-TE OAM Configuration Registry ........................20
5.5.1. OAM Types Sub-Registry .............................20
5.5.2. OAM Sub-TLVs Sub-Registry ..........................20
5.5.3. OAM Function Flags Sub-Registry ....................21
6. Security Considerations ........................................21
7. Acknowledgements ...............................................21
8. References .....................................................22
8.1. Normative References ......................................22
8.2. Informative References ....................................22
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
2. Technology-Specific OAM Requirements ............................4
3. RSVP-TE-Based OAM Configuration .................................6
3.1. Establishment of OAM Entities and Functions ................8
3.2. Adjustment of OAM Parameters ..............................10
3.3. Deleting OAM Entities .....................................11
4. RSVP-TE Extensions .............................................11
4.1. LSP Attribute Flags .......................................11
4.2. OAM Configuration TLV .....................................13
4.2.1. OAM Function Flags Sub-TLV .........................14
4.2.2. Technology-Specific Sub-TLVs .......................15
4.3. Administrative Status Information .........................15
4.4. Handling OAM Configuration Errors .........................16
4.5. Considerations on Point-to-Multipoint OAM Configuration ...16
5. IANA Considerations ............................................18
5.1. Admin_Status Object Bit Flags .............................18
5.2. LSP Attribute Flags .......................................18
5.3. New LSP Attributes ........................................19
5.4. RSVP Error Code ...........................................19
5.5. RSVP-TE OAM Configuration Registry ........................20
5.5.1. OAM Types Sub-Registry .............................20
5.5.2. OAM Sub-TLVs Sub-Registry ..........................20
5.5.3. OAM Function Flags Sub-Registry ....................21
6. Security Considerations ........................................21
7. Acknowledgements ...............................................21
8. References .....................................................22
8.1. Normative References ......................................22
8.2. Informative References ....................................22
GMPLS is designed as an out-of-band control plane supporting dynamic connection provisioning for any suitable data-plane technology, including spatial switching (e.g., incoming port or fiber to outgoing port or fiber); wavelength-division multiplexing (e.g., Dense Wavelength Division Multiplexing (DWDM)); time-division multiplexing (e.g., Synchronous Optical Networking and Synchronous Digital Hierarchy (SONET/SDH), G.709); and Ethernet Provider Backbone Bridging - Traffic Engineering (PBB-TE) and MPLS. In most of these technologies, there are Operations, Administration, and Maintenance (OAM) functions employed to monitor the health and performance of the connections and to trigger data plane (DP) recovery mechanisms. Similar to connection provisioning, OAM functions follow general principles but also have some technology-specific characteristics.
GMPLS设计为带外控制平面，支持任何合适数据平面技术的动态连接供应，包括空间交换（例如，输入端口或光纤到输出端口或光纤）；波分复用（例如密集波分复用（DWDM））；时分复用（例如，同步光网络和同步数字体系（SONET/SDH），g.709）；以太网提供商主干桥接-流量工程（PBB-TE）和MPLS。在大多数这些技术中，有操作、管理和维护（OAM）功能用于监控连接的运行状况和性能，并触发数据平面（DP）恢复机制。与连接供应类似，OAM功能遵循一般原则，但也具有一些特定于技术的特征。
OAM is an integral part of transport connections. Therefore, it is required that OAM functions be activated/deactivated in sync with connection commissioning/decommissioning, in order to avoid spurious alarms and ensure consistent operation. In certain technologies, OAM entities are inherently established once the connection is set up, while other technologies require extra configuration to establish and configure OAM entities. In some situations, the use of OAM functions, such as Fault Management (FM) and Performance Management (PM), may be optional (based on network management policies). Hence, the network operator must be able to choose which set of OAM functions to apply to specific connections and which parameters should be configured and activated. To achieve this objective, OAM entities and specific functions must be selectively configurable.
OAM是传输连接的一个组成部分。因此，要求OAM功能与连接调试/停用同步激活/停用，以避免虚假警报并确保一致运行。在某些技术中，一旦建立了连接，OAM实体就固有地建立起来，而其他技术则需要额外的配置来建立和配置OAM实体。在某些情况下，OAM功能（如故障管理（FM）和性能管理（PM））的使用可能是可选的（基于网络管理策略）。因此，网络运营商必须能够选择应用于特定连接的OAM功能集，以及应配置和激活的参数。为了实现这一目标，必须有选择地配置OAM实体和特定功能。
In general, it is required that the management-plane and control-plane connection establishment mechanisms be synchronized with OAM establishment and activation. In particular, if the GMPLS control plane is employed, it is desirable to bind OAM setup and configuration to connection establishment signaling to avoid two separate management/configuration steps (connection setup followed by OAM configuration), as these separate steps increase delay and processing time; more importantly, they may be prone to misconfiguration errors. Once OAM entities are set up and configured, proactive as well as on-demand OAM functions can be activated via the management plane. On the other hand, it should be possible to activate/deactivate proactive OAM functions via the GMPLS control plane as well. In some situations, it may be possible to use the GMPLS control plane to control on-demand OAM functions too.
通常，要求管理平面和控制平面连接建立机制与OAM建立和激活同步。特别地，如果使用GMPLS控制平面，则希望将OAM设置和配置绑定到连接建立信令，以避免两个单独的管理/配置步骤（连接设置之后是OAM配置），因为这些单独的步骤增加了延迟和处理时间；更重要的是，它们可能容易出现错误配置错误。设置和配置OAM实体后，可以通过管理平面激活主动式和按需式OAM功能。另一方面，也可以通过GMPLS控制平面激活/停用主动OAM功能。在某些情况下，也可以使用GMPLS控制平面来控制按需OAM功能。
This document describes requirements for OAM configuration and control via Resource Reservation Protocol - Traffic Engineering (RSVP-TE). Extensions to the RSVP-TE protocol are specified, providing a framework to configure and control OAM entities along with the capability to carry technology-specific information. Extensions can be grouped into generic elements that are applicable to any OAM solution and technology-specific elements that provide additional configuration parameters that may only be needed for a specific OAM technology. This document specifies the technology-agnostic elements and specifies the way that additional technology-specific OAM parameters are provided. This document addresses end-to-end OAM configuration, that is, the setup of OAM entities bound to an end-to-end Label Switched Path (LSP), and configuration and control of OAM functions running end-to-end in the LSP. Configuration of OAM entities for LSP segments and tandem connections is outside the scope of this document.
本文档描述了通过资源预留协议-流量工程（RSVP-TE）进行OAM配置和控制的要求。指定了对RSVP-TE协议的扩展，提供了一个配置和控制OAM实体的框架，以及承载特定于技术的信息的能力。扩展可以分为适用于任何OAM解决方案的通用元素和提供仅特定OAM技术可能需要的附加配置参数的特定于技术的元素。本文档指定了与技术无关的元素，并指定了提供其他特定于技术的OAM参数的方式。本文档介绍端到端OAM配置，即，设置绑定到端到端标签交换路径（LSP）的OAM实体，以及配置和控制在LSP中端到端运行的OAM功能。LSP段和串联连接的OAM实体配置不在本文档范围内。
The mechanisms described in this document provide an additional option for bootstrapping OAM that is not intended to replace or deprecate the use of other technology-specific OAM bootstrapping techniques, e.g., LSP ping [RFC4379] for MPLS networks. The procedures specified in this document are intended only for use in environments where RSVP-TE signaling is used to set up the LSPs that are to be monitored using OAM.
本文档中描述的机制为引导OAM提供了一个附加选项，该选项无意取代或拒绝使用其他特定于技术的OAM引导技术，例如用于MPLS网络的LSP ping[RFC4379]。本文件中规定的程序仅适用于使用RSVP-TE信令设置要使用OAM监控的LSP的环境。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This section summarizes various technology-specific OAM requirements that can be used as a basis for an OAM configuration framework.
本节总结了各种特定于技术的OAM需求，这些需求可作为OAM配置框架的基础。
MPLS OAM requirements are described in [RFC4377], which provides requirements to create consistent OAM functionality for MPLS networks. The following list is an excerpt of MPLS OAM requirements documented in [RFC4377] that bear direct relevance to the discussion set forth in this document:
[RFC4377]中描述了MPLS OAM需求，它提供了为MPLS网络创建一致OAM功能的需求。以下列表是[RFC4377]中记录的MPLS OAM要求的摘录，与本文件中的讨论直接相关：
o It is desired that the automation of LSP defect detection be supported. It is especially important in cases where large numbers of LSPs might be tested.
o 希望支持LSP缺陷检测的自动化。在可能测试大量LSP的情况下，这一点尤为重要。
o In particular, some LSPs may require automated testing functionality from the ingress LSR (Label Switching Router) to the egress LSR, while others may not.
o 特别地，一些lsp可能需要从入口LSR（标签交换路由器）到出口LSR的自动测试功能，而其他lsp可能不需要。
o Mechanisms are required to coordinate network responses to defects. Such mechanisms may include alarm suppression, translating defect signals at technology boundaries, and synchronizing defect detection times by setting appropriately bounded detection time frames.
o 需要机制来协调网络对缺陷的响应。此类机制可包括报警抑制、在技术边界处转换缺陷信号以及通过设置适当的有界检测时间帧来同步缺陷检测时间。
The MPLS Transport Profile (MPLS-TP) defines a profile of MPLS targeted at transport applications [RFC5921]. This profile specifies the specific MPLS characteristics and extensions required to meet transport requirements, including providing additional OAM, survivability, and other maintenance functions not currently supported by MPLS. Specific OAM requirements for MPLS-TP are specified in [RFC5654] and [RFC5860]. MPLS-TP poses the following requirements on the control plane to configure and control OAM entities:
MPLS传输配置文件（MPLS-TP）定义了针对传输应用程序的MPLS配置文件[RFC5921]。此概要文件指定了满足传输需求所需的特定MPLS特性和扩展，包括提供额外的OAM、生存能力和MPLS当前不支持的其他维护功能。[RFC5654]和[RFC5860]中规定了MPLS-TP的特定OAM要求。MPLS-TP在控制平面上提出以下要求，以配置和控制OAM实体：
o From [RFC5860]: OAM functions MUST operate and be configurable even in the absence of a control plane. Conversely, it SHOULD be possible to configure as well as enable/disable the capability to operate OAM functions as part of connectivity management, and it SHOULD also be possible to configure as well as enable/disable the capability to operate OAM functions after connectivity has been established.
o 来自[RFC5860]：即使在没有控制平面的情况下，OAM功能也必须运行并可配置。相反，作为连接管理的一部分，应该可以配置以及启用/禁用操作OAM功能的能力，并且还应该可以配置以及启用/禁用在建立连接后操作OAM功能的能力。
o From [RFC5654]: The MPLS-TP control plane MUST support the configuration and modification of OAM maintenance points as well as the activation/deactivation of OAM when the transport path or transport service is established or modified.
o 从[RFC5654]：MPLS-TP控制平面必须支持OAM维护点的配置和修改，以及在建立或修改传输路径或传输服务时激活/停用OAM。
Ethernet Connectivity Fault Management (CFM) defines an adjunct OAM flow that monitors connectivity in order to check the liveliness of Ethernet networks [IEEE.802.1Q-2011]. With PBB-TE [IEEE.802.1Q-2011], Ethernet networks support explicitly routed Ethernet connections. CFM can be used to track the liveliness of PBB-TE connections and detect data-plane failures. In the IETF, the GMPLS Ethernet Label Switching (GELS) (see [RFC5828] and [RFC6060]) work extended the GMPLS control plane to support the establishment of PBB-TE data-plane connections. Without control-plane support, separate management commands would be needed to configure and start CFM.
Ethernet Connectivity Fault Management（CFM）定义了一个辅助OAM流，用于监控连接，以检查Ethernet网络的活跃性[IEEE.802.1Q-2011]。使用PBB-TE[IEEE.802.1Q-2011]，以太网网络支持明确路由的以太网连接。CFM可用于跟踪PBB-TE连接的活跃性并检测数据平面故障。在IETF中，GMPLS以太网标签交换（GELS）（参见[RFC5828]和[RFC6060]）工作扩展了GMPLS控制平面，以支持PBB-TE数据平面连接的建立。如果没有控制平面支持，则需要单独的管理命令来配置和启动CFM。
GMPLS-based OAM configuration and control need to provide a general framework to be applicable to a wide range of data-plane technologies and OAM solutions. There are three typical data-plane technologies
基于GMPLS的OAM配置和控制需要提供一个通用框架，以适用于广泛的数据平面技术和OAM解决方案。有三种典型的数据平面技术
used for transport applications: wavelength based, such as Wavelength Switched Optical Networks (WSON); Time-Division Multiplexing (TDM) based, such as Synchronous Digital Hierarchy (SDH) and Synchronous Optical Networking (SONET); and packet based, such as MPLS-TP [RFC5921] and Ethernet PBB-TE [IEEE.802.1Q-2011]. For all these data planes, the operator MUST be able to configure and control the following OAM functions:
用于传输应用：基于波长，如波长交换光网络（WSON）；基于时分复用（TDM），如同步数字体系（SDH）和同步光网络（SONET）；和基于分组的，如MPLS-TP[RFC5921]和以太网PBB-TE[IEEE.802.1Q-2011]。对于所有这些数据平面，操作员必须能够配置和控制以下OAM功能：
o It MUST be possible to explicitly request the setup of OAM entities for the signaled LSP and provide specific information for the setup if this is required by the technology.
o 如果技术需要，必须能够明确请求为信号LSP设置OAM实体，并为设置提供特定信息。
o Control of alarms is important to avoid false alarm indications and reporting to the management system. It MUST be possible to enable/disable alarms generated by OAM functions. In some cases, selective alarm control may be desirable when, for instance, the operator is only concerned about critical alarms. Therefore, alarms that do not affect service should be inhibited.
o 警报控制对于避免错误警报指示和向管理系统报告非常重要。必须能够启用/禁用OAM功能生成的警报。在某些情况下，当操作员仅关注关键报警时，可能需要选择报警控制。因此，应禁止不影响服务的警报。
o When periodic messages are used for liveliness checks (Continuity Checks (CCs)) of LSPs, it MUST be possible to set the frequency of messages. This allows proper configuration for fulfilling the requirements of the service and/or meeting the detection time boundaries posed by possible congruent connectivity-check operations of higher-layer applications. For a network operator to be able to balance the trade-off between fast failure detection and data overhead, it is beneficial to configure the frequency of CC messages on a per-LSP basis.
o 当定期消息用于LSP的活动性检查（连续性检查（CCs））时，必须能够设置消息的频率。这允许进行适当的配置，以满足服务的要求和/或满足更高层应用程序的可能一致连接检查操作造成的检测时间边界。为了使网络运营商能够平衡快速故障检测和数据开销之间的平衡，在每个LSP的基础上配置CC消息的频率是有益的。
o Proactive Performance Monitoring (PM) functions are used to continuously collect information about specific characteristics of the connection. For consistent measurement of Service Level Agreements (SLAs), it MUST be possible to set common configuration parameters for the LSP.
o 主动性能监视（PM）功能用于持续收集有关连接特定特征的信息。为了一致地度量服务级别协议（SLA），必须能够为LSP设置公共配置参数。
o The extensions MUST allow the operator to use only a minimal set of OAM configuration and control features if supported by the OAM solution or network management policy. Generic OAM parameters, as well as parameters specific to data-plane technology or OAM technology, MUST be supported.
o 如果OAM解决方案或网络管理策略支持，扩展必须允许运营商仅使用一组最小的OAM配置和控制功能。必须支持通用OAM参数以及特定于数据平面技术或OAM技术的参数。
In general, two types of maintenance points can be distinguished: Maintenance Entity Group End Points (MEPs) and Maintenance Entity Group Intermediate Points (MIPs). MEPs reside at the ends of an LSP and are capable of initiating and terminating OAM messages for Fault Management (FM) and Performance Monitoring (PM). MIPs, on the other
通常，可以区分两种类型的维护点：维护实体组端点（MEP）和维护实体组中间点（MIP）。MEP位于LSP的末端，能够启动和终止用于故障管理（FM）和性能监视（PM）的OAM消息。另一方面，MIPs
hand, are located at transit nodes of an LSP and are capable of reacting to some OAM messages but otherwise do not initiate messages. "Maintenance Entity" (ME) refers to an association of MEPs and MIPs that are provisioned to monitor an LSP.
另一方面，它们位于LSP的传输节点上，能够对某些OAM消息做出反应，但在其他方面不会启动消息。“维护实体”（ME）是指为监控LSP而设置的MEP和MIP的关联。
When an LSP is signaled, a forwarding association is established between endpoints and transit nodes via label bindings. This association creates a context for the OAM entities monitoring the LSP. On top of this association, OAM entities may be configured to unambiguously identify MEs.
当发送LSP信号时，通过标签绑定在端点和传输节点之间建立转发关联。此关联为监视LSP的OAM实体创建上下文。在此关联之上，OAM实体可以被配置为明确标识MEs。
In addition to ME identification parameters, proactive OAM functions (e.g., CC and PM) may have additional parameters that require configuration as well. In particular, the frequency of periodic CC packets, and the measurement interval for loss and delay measurements, may need to be configured.
除了ME标识参数外，主动式OAM功能（例如CC和PM）可能还有其他需要配置的参数。具体而言，可能需要配置周期性CC分组的频率以及用于丢失和延迟测量的测量间隔。
The above parameters may be derived from information related to LSP provisioning; alternatively, pre-configured default values can be used. In the simplest case, the control plane MAY provide information on whether or not OAM entities need to be set up for the signaled LSP. If OAM entities are created, control-plane signaling MUST also provide a means to activate/deactivate OAM message flows and associated alarms.
上述参数可从与LSP供应相关的信息导出；或者，可以使用预先配置的默认值。在最简单的情况下，控制平面可以提供关于是否需要为发信号的LSP设置OAM实体的信息。如果创建了OAM实体，控制平面信令还必须提供激活/停用OAM消息流和相关警报的方法。
OAM identifiers, as well as the configuration of OAM functions, are technology specific (i.e., they vary, depending on the data-plane technology and the chosen OAM solution). In addition, for any given data-plane technology, a set of OAM solutions may be applicable. Therefore, the OAM configuration framework allows selecting a specific OAM solution to be used for the signaled LSP and provides means to carry detailed OAM configuration information in technology-specific TLVs.
OAM标识符以及OAM功能的配置是特定于技术的（即，根据数据平面技术和选择的OAM解决方案，它们会有所不同）。此外，对于任何给定的数据平面技术，一组OAM解决方案可能是适用的。因此，OAM配置框架允许选择用于信令LSP的特定OAM解决方案，并提供在特定于技术的tlv中承载详细OAM配置信息的方法。
Administrative Status Information is carried in the Admin_Status object. Administrative Status Information is described in [RFC3471], and the Admin_Status object is specified for RSVP-TE in [RFC3473]. Two bits are allocated for the administrative control of OAM monitoring: the "OAM Flows Enabled" (M) and "OAM Alarms Enabled" (O) bits. When the "OAM Flows Enabled" bit is set, OAM mechanisms MUST be enabled; if it is cleared, OAM mechanisms MUST be disabled. When the "OAM Alarms Enabled" bit is set, OAM-triggered alarms are enabled and associated consequent actions MUST be executed, including the notification to the management system. When this bit is cleared, alarms are suppressed and no action SHOULD be executed, and the management system SHOULD NOT be notified.
管理状态信息包含在Admin_Status对象中。[RFC3471]中描述了管理状态信息，并且[RFC3473]中为RSVP-TE指定了管理状态对象。为OAM监控的管理控制分配了两个位：“已启用OAM流”（M）和“已启用OAM报警”（O）位。设置“OAM流启用”位时，必须启用OAM机制；如果清除，则必须禁用OAM机制。当设置“OAM警报已启用”位时，OAM触发的警报将启用，并且必须执行相关的后续操作，包括向管理系统发出通知。当清除该位时，报警被抑制，不应执行任何操作，并且不应通知管理系统。
The LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects are defined in [RFC5420] to provide means to signal LSP attributes and options in the form of TLVs. Options and attributes signaled in the LSP_ATTRIBUTES object can be passed transparently through LSRs not supporting a particular option or attribute, while the contents of the LSP_REQUIRED_ATTRIBUTES object MUST be examined and processed by each LSR. The "OAM MEP entities desired" bit is allocated in the Attribute Flags TLV [RFC5420] to be used in the LSP_ATTRIBUTES object. If the "OAM MEP entities desired" bit is set, it indicates that the establishment of OAM MEP entities is required at the endpoints of the signaled LSP. The "OAM MIP entities desired" bit is allocated in the Attribute Flags TLV to be used in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES objects. If the "OAM MIP entities desired" bit is set in the Attribute Flags TLV in the LSP_REQUIRED_ATTRIBUTES object, it indicates that the establishment of OAM MIP entities is required at every transit node of the signaled LSP.
[RFC5420]中定义了LSP_属性和LSP_所需_属性对象，以提供以TLV形式向LSP属性和选项发送信号的方法。LSP_attributes对象中发出信号的选项和属性可以通过不支持特定选项或属性的LSR透明地传递，而LSP_REQUIRED_attributes对象的内容必须由每个LSR检查和处理。“所需OAM MEP实体”位在属性标志TLV[RFC5420]中分配，以在LSP_属性对象中使用。如果设置了“所需OAM MEP实体”位，则表示需要在发信号的LSP的端点处建立OAM MEP实体。“OAM MIP entities desired”位在属性标志TLV中分配，以用于LSP_属性或LSP_REQUIRED_属性对象。如果在LSP_REQUIRED_ATTRIBUTES对象的属性标志TLV中设置了“OAM MIP entities desired”位，则表示需要在发信号的LSP的每个传输节点上建立OAM MIP entities。
In order to avoid spurious alarms, OAM functions should be set up and enabled in the appropriate order. When using the GMPLS control plane for both LSP establishment and enabling OAM functions on the LSPs, the control of both processes is bound to RSVP-TE message exchanges.
为了避免虚假警报，应按适当顺序设置和启用OAM功能。当使用GMPLS控制平面建立LSP和在LSP上启用OAM功能时，两个进程的控制都绑定到RSVP-TE消息交换。
An LSP may be signaled and established without OAM configuration first, and OAM entities may be added later with a subsequent re-signaling of the LSP. Alternatively, the LSP may be set up with OAM entities with the first signaling of the LSP. The procedures below apply to both cases.
LSP可以首先在没有OAM配置的情况下被发信号和建立，并且OAM实体可以在随后通过LSP的重新发信号被添加。或者，LSP可以通过LSP的第一信令与OAM实体建立。以下程序适用于这两种情况。
Before initiating a Path message with OAM configuration information, an initiating node MUST establish and configure the corresponding OAM entities locally. But until the LSP is established, OAM source functions MUST NOT start sending any OAM messages. In the case of bidirectional connections, in addition to the OAM source function, the initiator node MUST set up the OAM sink function and prepare it to receive OAM messages. During this time the OAM alarms MUST be suppressed (e.g., due to missing or unidentified OAM messages). To achieve OAM alarm suppression, Path messages MUST be sent with the "OAM Alarms Enabled" Admin_Status flag cleared.
在使用OAM配置信息启动Path消息之前，启动节点必须在本地建立和配置相应的OAM实体。但在LSP建立之前，OAM源函数不得开始发送任何OAM消息。在双向连接的情况下，除了OAM源功能外，发起方节点还必须设置OAM接收器功能，并准备接收OAM消息。在此期间，必须抑制OAM警报（例如，由于丢失或未识别的OAM消息）。要实现OAM警报抑制，必须在清除“OAM警报已启用”管理状态标志的情况下发送路径消息。
When the Path message arrives at the receiver, the remote end MUST establish and configure OAM entities according to the OAM information provided in the Path message. If this is not possible, a PathErr message SHOULD be sent, and neither the OAM entities nor the LSP SHOULD be established. If OAM entities are established successfully, the OAM sink function MUST be prepared to receive OAM messages but
当Path消息到达接收方时，远端必须根据Path消息中提供的OAM信息建立和配置OAM实体。如果不可能，则应发送PathErr消息，并且不应建立OAM实体或LSP。如果OAM实体成功建立，OAM接收器功能必须准备好接收OAM消息，但
MUST NOT generate any OAM alarms (e.g., due to missing or unidentified OAM messages). In the case of bidirectional connections, in addition to the OAM sink function, an OAM source function MUST be set up and, according to the requested configuration, the OAM source function MUST start sending OAM messages. A Resv message MUST then be sent back, including the Attribute Flags TLV, with the appropriate setting of the "OAM MEP entities desired" and "OAM MIP entities desired" flags, and the OAM Configuration TLV that corresponds to the established and configured OAM entities and functions. Depending on the OAM technology, some elements of the OAM Configuration TLV MAY be updated/changed, i.e., if the remote end does not support a certain OAM configuration it may suggest an alternative setting, which may or may not be accepted by the initiator of the Path message. If it is accepted, the initiator will reconfigure its OAM functions according to the information received in the Resv message. If the alternate setting is not acceptable, a ResvErr message MAY be sent, tearing down the LSP. Details of this operation are technology specific and should be described in accompanying technology-specific documents.
不得产生任何OAM警报（例如，由于丢失或未识别的OAM消息）。在双向连接的情况下，除了OAM接收器功能外，还必须设置OAM源功能，并且根据请求的配置，OAM源功能必须开始发送OAM消息。然后，必须发回Resv消息，包括属性标志TLV，并适当设置“所需OAM MEP实体”和“所需OAM MIP实体”标志，以及与已建立和配置的OAM实体和功能相对应的OAM配置TLV。根据OAM技术，OAM配置TLV的一些元素可以被更新/改变，即，如果远程端不支持某个OAM配置，则它可以建议替代设置，路径消息的发起方可以接受，也可以不接受。如果接受，发起方将根据在Resv消息中接收到的信息重新配置其OAM功能。如果备用设置不可接受，则可能会发送一条ResvErr消息，撕毁LSP。此操作的详细信息是特定于技术的，应在随附的特定于技术的文档中描述。
When the initiating side receives the Resv message, it completes any pending OAM configuration and enables the OAM source function to send OAM messages.
当发起端接收到Resv消息时，它完成任何挂起的OAM配置，并启用OAM源功能来发送OAM消息。
After this exchange, OAM entities are established and configured for the LSP, and OAM messages are exchanged. OAM alarms can now be enabled. During the period when OAM alarms are disabled, the initiator sends a Path message with the "OAM Alarms Enabled" Admin_Status flag set. The receiving node enables OAM alarms after processing the Path message. The initiator enables OAM alarms after it receives the Resv message. Data-plane OAM is now fully functional.
在此交换之后，为LSP建立和配置OAM实体，并交换OAM消息。现在可以启用OAM警报。在禁用OAM警报期间，启动器发送设置了“OAM警报已启用”管理状态标志的路径消息。接收节点在处理路径消息后启用OAM警报。启动器在收到Resv消息后启用OAM警报。数据平面OAM现在功能齐全。
If an egress LSR does not support the extensions defined in this document, according to [RFC5420], it will silently ignore the new LSP attribute flags as well as the TLVs carrying additional OAM configuration information, and therefore no error will be raised that would notify the ingress LSR about the missing OAM configuration actions on the egress side. However, as described above, an egress LSR conformant to the specification of this document will set the LSP attribute flags and include the OAM Configuration TLV in the Resv message indicating the configuration of the OAM mechanisms; therefore, by detecting the missing information in the Resv message, an ingress LSR will be able to recognize that the remote end does not support the OAM configuration functionality, and therefore it SHOULD tear down the LSP and, if appropriate, signal the LSP without any OAM configuration information.
根据[RFC5420]，如果出口LSR不支持本文档中定义的扩展，它将自动忽略新的LSP属性标志以及携带额外OAM配置信息的TLV，因此，不会出现将通知入口LSR关于出口侧丢失的OAM配置操作的错误。然而，如上所述，符合本文档的规范的出口LSR将设置LSP属性标志，并在指示OAM机制的配置的Resv消息中包括OAM配置TLV；因此，通过检测Resv消息中丢失的信息，入口LSR将能够识别远程端不支持OAM配置功能，因此它应该拆除LSP，并且在适当的情况下，在没有任何OAM配置信息的情况下向LSP发送信号。
There may be a need to change the parameters of an already-established and configured OAM function during the lifetime of the LSP. To do so, the LSP needs to be re-signaled with the updated parameters. OAM parameters influence the content and timing of OAM messages and also identify the way that OAM defects and alarms are derived and generated. Hence, to avoid spurious alarms, it is important that both sides -- OAM sink and source -- are updated in a synchronized way. First, the alarms of the OAM sink function should be suppressed and only then should expected OAM parameters be adjusted. Subsequently, the parameters of the OAM source function can be updated. Finally, the alarms of the OAM sink side can be enabled again.
在LSP的生存期内，可能需要更改已经建立和配置的OAM功能的参数。为此，LSP需要用更新的参数重新发送信号。OAM参数影响OAM消息的内容和时间，还确定了OAM缺陷和警报的产生和生成方式。因此，为了避免虚假警报，以同步方式更新双方（OAM接收器和源）是很重要的。首先，应该抑制OAM接收器功能的警报，然后才应该调整预期的OAM参数。随后，可以更新OAM源函数的参数。最后，可以再次启用OAM接收器端的警报。
In accordance with the above operation, the LSP MUST first be re-signaled with the "OAM Alarms Enabled" Admin_Status flag cleared, including the updated OAM Configuration TLV corresponding to the new parameter settings. The initiator MUST keep its OAM sink and source functions running unmodified, but it MUST suppress OAM alarms after the updated Path message is sent. The receiver MUST first disable all OAM alarms and then update the OAM parameters according to the information in the Path message and reply with a Resv message acknowledging the changes by including the OAM Configuration TLV. Note that the receiving side can adjust the requested OAM configuration parameters and reply with an updated OAM Configuration TLV in the Resv message, reflecting the values that are actually configured. However, in order to avoid an extensive negotiation phase, in the case of adjusting already-configured OAM functions, the receiving side SHOULD NOT update the parameters requested in the Path message to an extent that would provide lower performance (e.g., lower frequency of monitoring packets) than what had previously been in place.
根据上述操作，必须首先在清除“OAM Alarms Enabled”（OAM Alarms Enabled）管理单元状态标志的情况下，向LSP重新发送信号，包括与新参数设置相对应的更新的OAM配置TLV。启动器必须保持其OAM接收器和源函数未经修改地运行，但必须在发送更新的路径消息后抑制OAM警报。接收器必须首先禁用所有OAM警报，然后根据Path消息中的信息更新OAM参数，并通过包括OAM配置TLV来回复Resv消息，确认更改。注意，接收方可以调整请求的OAM配置参数，并在Resv消息中使用更新的OAM配置TLV进行回复，以反映实际配置的值。然而，为了避免广泛的协商阶段，在调整已经配置的OAM功能的情况下，接收方不应更新路径消息中请求的参数，以提供比先前更低的性能（例如，较低的监视分组频率）。
The initiator MUST only update its OAM sink and source functions after it receives the Resv message. After this Path/Resv message exchange (in both unidirectional and bidirectional LSP cases), the OAM parameters are updated, and OAM is running according to the new parameter settings. However, OAM alarms are still disabled. A subsequent Path/Resv message exchange with the "OAM Alarms Enabled" Admin_Status flag set is needed to enable OAM alarms again.
启动器必须仅在收到Resv消息后更新其OAM接收器和源函数。在该Path/Resv消息交换之后（在单向和双向LSP情况下），OAM参数将更新，并且OAM将根据新的参数设置运行。但是，OAM警报仍处于禁用状态。要再次启用OAM警报，需要使用“OAM警报已启用”管理状态标志集进行后续路径/Resv消息交换。
In some cases, it may be useful to remove some or all OAM entities and functions from an LSP without actually tearing down the connection.
在某些情况下，从LSP中删除一些或所有OAM实体和功能而不实际断开连接可能是有用的。
To avoid any spurious alarms, first the LSP MUST be re-signaled with the "OAM Alarms Enabled" Admin_Status flag cleared but with OAM configuration unchanged. Subsequently, the LSP is re-signaled with "OAM MEP entities desired" and "OAM MIP entities desired" LSP attribute flags cleared, and without the OAM Configuration TLV, this MUST result in the deletion of all OAM entities associated with the LSP. All control-plane and data-plane resources in use by the OAM entities and functions SHOULD be freed up. Alternatively, if only some OAM functions need to be removed, the LSP is re-signaled with the updated OAM Configuration TLV. Changes between the contents of the previously signaled OAM Configuration TLV and the currently received TLV represent which functions MUST be removed/added.
为了避免任何虚假警报，首先必须在清除“OAM警报已启用”管理_状态标志但OAM配置不变的情况下，重新向LSP发送信号。随后，用清除的“OAM MEP实体所需”和“OAM MIP实体所需”LSP属性标志重新通知LSP，并且在没有OAM配置TLV的情况下，这必须导致删除与LSP关联的所有OAM实体。应该释放OAM实体和函数使用的所有控制平面和数据平面资源。或者，如果只需要删除一些OAM功能，则使用更新的OAM配置TLV重新通知LSP。先前发出信号的OAM配置TLV和当前接收的TLV的内容之间的更改表示必须删除/添加哪些功能。
OAM source functions MUST be deleted first, and only after the "OAM Alarms Disabled" can the associated OAM sink functions be removed; this will ensure that OAM messages do not leak outside the LSP. To this end, the initiator, before sending the Path message, MUST remove the OAM source, hence terminating the OAM message flow associated to the downstream direction. In the case of a bidirectional connection, it MUST leave in place the OAM sink functions associated to the upstream direction. The remote end, after receiving the Path message, MUST remove all associated OAM entities and functions and reply with a Resv message without an OAM Configuration TLV. The initiator completely removes OAM entities and functions after the Resv message arrives.
必须先删除OAM源功能，只有在“OAM报警禁用”后才能删除关联的OAM接收器功能；这将确保OAM消息不会泄漏到LSP之外。为此，发起方在发送Path消息之前必须删除OAM源，从而终止与下游方向相关联的OAM消息流。在双向连接的情况下，它必须保留与上行方向相关联的OAM接收器功能。远程端在收到Path消息后，必须删除所有关联的OAM实体和功能，并使用不带OAM配置TLV的Resv消息进行回复。在Resv消息到达后，启动器将完全删除OAM实体和功能。
In RSVP-TE, the Flags field of the SESSION_ATTRIBUTE object is used to indicate options and attributes of the LSP. The Flags field has 8 bits and hence is limited to differentiate only 8 options. [RFC5420] defines new objects for RSVP-TE messages to allow the signaling of arbitrary attribute parameters, making RSVP-TE easily extensible to support new applications. Furthermore, [RFC5420] allows options and attributes that do not need to be acted on by all Label Switching Routers (LSRs) along the path of the LSP. In particular, these options and attributes may apply only to key LSRs on the path, such as the ingress LSR and egress LSR. Options and attributes can be signaled transparently and only examined at those points that need to act on them. The LSP_ATTRIBUTES and
在RSVP-TE中，会话_属性对象的标志字段用于指示LSP的选项和属性。标志字段有8位，因此仅限于区分8个选项。[RFC5420]为RSVP-TE消息定义新对象，以允许发送任意属性参数的信号，使RSVP-TE易于扩展以支持新的应用程序。此外，[RFC5420]允许不需要由沿着LSP路径的所有标签交换路由器（LSR）操作的选项和属性。具体地，这些选项和属性可以仅应用于路径上的密钥LSR，例如入口LSR和出口LSR。选项和属性可以透明地发出信号，并且只在需要对其采取行动的点进行检查。LSP_属性和
LSP_REQUIRED_ATTRIBUTES objects are defined in [RFC5420] to provide means to signal LSP attributes and options in the form of TLVs. Options and attributes signaled in the LSP_ATTRIBUTES object can be passed transparently through LSRs not supporting a particular option or attribute, while the contents of the LSP_REQUIRED_ATTRIBUTES object MUST be examined and processed by each LSR. One TLV is defined in [RFC5420]: the Attribute Flags TLV.
[RFC5420]中定义了LSP_REQUIRED_ATTRIBUTES对象，以提供以TLV形式向LSP属性和选项发送信号的方法。LSP_attributes对象中发出信号的选项和属性可以通过不支持特定选项或属性的LSR透明地传递，而LSP_REQUIRED_attributes对象的内容必须由每个LSR检查和处理。[RFC5420]中定义了一个TLV：属性标志TLV。
One bit (bit number 10): "OAM MEP entities desired" is allocated in the Attribute Flags TLV to be used in the LSP_ATTRIBUTES object. If the "OAM MEP entities desired" bit is set, it indicates that the establishment of OAM MEP entities is required at the endpoints of the signaled LSP. If the establishment of MEPs is not supported, an error MUST be generated: "OAM Problem/MEP establishment not supported".
一位（位号10）：“所需的OAM MEP实体”在要在LSP_ATTRIBUTES对象中使用的属性标志TLV中分配。如果设置了“所需OAM MEP实体”位，则表示需要在发信号的LSP的端点处建立OAM MEP实体。如果不支持建立MEP，则必须生成错误：“OAM问题/MEP建立不受支持”。
If the "OAM MEP entities desired" bit is set and additional parameters need to be configured, an OAM Configuration TLV MAY be included in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object.
如果设置了“OAM MEP entities desired”（所需OAM MEP实体）位并且需要配置额外的参数，则可以在LSP_属性或LSP_REQUIRED_属性对象中包括OAM配置TLV。
One bit (bit number 11): "OAM MIP entities desired" is allocated in the Attribute Flags TLV to be used in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES objects. If the "OAM MEP entities desired" bit is not set, then this bit MUST NOT be set. If the "OAM MIP entities desired" bit is set in the Attribute Flags TLV in the LSP_REQUIRED_ATTRIBUTES object, it indicates that the establishment of OAM MIP entities is required at every transit node of the signaled LSP. If the establishment of a MIP is not supported, an error MUST be generated: "OAM Problem/MIP establishment not supported". If an intermediate LSR does not support the extensions defined in this document, it will not recognize the "OAM MIP entities desired" flag and, although the LSP_REQUIRED_ATTRIBUTES object was used, it will not configure MIP entities and will not raise any errors. If LSRs that do not support the extensions defined in this document are to be assumed as present in the network, the ingress LSR SHOULD collect per-hop information about the LSP attributes utilizing the LSP Attributes sub-object of the Record Route object (RRO) as defined in [RFC5420]. When the Record Route object is received, the ingress SHOULD check whether all intermediate LSRs set the "OAM MIP entities desired" flag indicating support of the function; if not, depending on operator policy, the LSP MAY need to be torn down.
一位（位编号11）：“所需OAM MIP实体”分配在属性标志TLV中，以用于LSP_属性或LSP_必需_属性对象。如果未设置“OAM MEP实体所需”位，则不得设置该位。如果在LSP_REQUIRED_ATTRIBUTES对象的属性标志TLV中设置了“OAM MIP entities desired”位，则表示需要在发信号的LSP的每个传输节点上建立OAM MIP entities。如果不支持建立MIP，则必须生成错误：“OAM问题/MIP建立不受支持”。如果中间LSR不支持本文档中定义的扩展，它将无法识别“OAM MIP entities desired”标志，并且尽管使用了LSP_REQUIRED_ATTRIBUTES对象，但它不会配置MIP entities，也不会引发任何错误。如果假定网络中存在不支持本文档中定义的扩展的LSR，则入口LSR应利用[RFC5420]中定义的记录路由对象（RRO）的LSP attributes子对象收集关于LSP属性的每跳信息。当接收到记录路由对象时，入口应检查所有中间LSR是否设置了表示支持该功能的“OAM MIP entities desired”标志；否则，根据运营商的政策，可能需要拆除LSP。
This TLV provides information about which OAM technology/method should be used and carries sub-TLVs for any additional OAM configuration information. One OAM Configuration TLV MAY be carried in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path and Resv messages. When carried in the LSP_REQUIRED_ATTRIBUTES object, it indicates that intermediate nodes MUST recognize and react on the OAM configuration information.
此TLV提供有关应使用哪种OAM技术/方法的信息，并携带子TLV以获取任何其他OAM配置信息。Path和Resv消息中的LSP_ATTRIBUTES或LSP_REQUIRED_ATTRIBUTES对象中可能携带一个OAM配置TLV。当在LSP_REQUIRED_ATTRIBUTES对象中携带时，它表示中间节点必须识别OAM配置信息并对其作出反应。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (3) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ sub-TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (3) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ sub-TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: indicates a new type: the OAM Configuration TLV (3).
类型：表示一种新类型：OAM配置TLV（3）。
OAM Type: specifies the technology-specific OAM method. When carried in the LSP_REQUIRED_ATTRIBUTES object, if the requested OAM method is not supported at any given node an error MUST be generated: "OAM Problem/Unsupported OAM Type". When carried in the LSP_ATTRIBUTES object, intermediate nodes not supporting the OAM Type pass the object forward unchanged as specified in [RFC5420]. Ingress and egress nodes that support the OAM Configuration TLV but that do not support a specific OAM Type MUST respond with an error indicating "OAM Problem/Unsupported OAM Type".
OAM类型：指定特定于技术的OAM方法。在LSP_REQUIRED_ATTRIBUTES对象中携带时，如果任何给定节点都不支持请求的OAM方法，则必须生成错误：“OAM问题/不支持的OAM类型”。当在LSP_ATTRIBUTES对象中携带时，不支持OAM类型的中间节点会按照[RFC5420]中的规定将对象向前传递，但不会改变。支持OAM配置TLV但不支持特定OAM类型的入口和出口节点必须以指示“OAM问题/不支持的OAM类型”的错误进行响应。
OAM Type Description
------------ --------------------
0-255 Reserved
OAM Type Description
------------ --------------------
0-255 Reserved
This document defines no types. IANA maintains the values in a new "RSVP-TE OAM Configuration Registry".
本文档未定义任何类型。IANA在新的“RSVP-TE OAM配置注册表”中维护这些值。
Length: indicates the total length of the TLV in octets. The TLV MUST be zero-padded so that the TLV is 4-octet aligned.
长度：表示TLV的总长度（以八位字节为单位）。TLV必须为零填充，以便TLV为4-八位组对齐。
Two groups of TLVs are defined: generic sub-TLVs and technology-specific sub-TLVs. Generic sub-TLVs carry information that is applicable independent of the actual OAM technology, while technology-specific sub-TLVs are providing configuration parameters
定义了两组TLV：通用子TLV和技术特定子TLV。通用子TLV携带独立于实际OAM技术的适用信息，而特定于技术的子TLV提供配置参数
for specific OAM technologies. This document defines one generic sub-TLV (see Section 4.2.1), while it is foreseen that technology-specific sub-TLVs will be defined by separate documents.
针对特定的OAM技术。本文件定义了一个通用子TLV（见第4.2.1节），而预计技术特定子TLV将由单独的文件定义。
The receiving node, based on the OAM Type, will check to see if a corresponding technology-specific OAM configuration sub-TLV is included in the OAM Configuration TLV. If the included technology-specific OAM configuration sub-TLV is different from what is specified in the OAM Type, an error MUST be generated: "OAM Problem/ OAM Type Mismatch". IANA maintains the sub-TLV space in the new "RSVP-TE OAM Configuration Registry".
接收节点将基于OAM类型检查OAM配置TLV中是否包括相应的特定于技术的OAM配置子TLV。如果包含的特定于技术的OAM配置子TLV与OAM类型中指定的不同，则必须生成错误：“OAM问题/OAM类型不匹配”。IANA在新的“RSVP-TE OAM配置注册表”中维护子TLV空间。
Note that there is a hierarchical dependency between the OAM configuration elements. First, the "OAM MEP entities desired" flag needs to be set. Only when that flag is set MAY an OAM Configuration TLV be included in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object. When this TLV is present, based on the "OAM Type" field, it MAY carry a technology-specific OAM configuration sub-TLV. If this hierarchy is broken (e.g., "OAM MEP entities desired" flag is not set but an OAM Configuration TLV is present), an error MUST be generated: "OAM Problem/Configuration Error".
请注意，OAM配置元素之间存在分层依赖关系。首先，需要设置“OAM MEP实体所需”标志。只有设置了该标志，OAM配置TLV才能包含在LSP_属性或LSP_必需的_属性对象中。当此TLV存在时，基于“OAM类型”字段，它可能携带特定于技术的OAM配置子TLV。如果此层次结构被破坏（例如，未设置“OAM MEP entities desired”标志，但存在OAM配置TLV），则必须生成错误：“OAM问题/配置错误”。
The OAM Configuration TLV MUST always include a single instance of the OAM Function Flags Sub-TLV, and it MUST always be the first sub-TLV. "OAM Function Flags" specifies which proactive OAM functions (e.g., connectivity monitoring, loss and delay measurement) and which fault management signals MUST be established and configured. If the selected OAM Function or Functions are not supported, an error MUST be generated: "OAM Problem/Unsupported OAM Function".
OAM配置TLV必须始终包含OAM功能标志子TLV的单个实例，并且必须始终是第一个子TLV。“OAM功能标志”指定必须建立和配置哪些主动OAM功能（例如，连接监控、丢失和延迟测量）以及哪些故障管理信号。如果不支持所选的一个或多个OAM函数，则必须生成错误：“OAM问题/不支持的OAM函数”。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ OAM Function Flags ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ OAM Function Flags ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OAM Function Flags is a bitmap with extensible length based on the Length field of the TLV. Bits are numbered from left to right. The TLV is padded to 4-octet alignment. The Length field indicates the size of the padded TLV in octets. IANA maintains the OAM Function Flags in the new "RSVP-TE OAM Configuration Registry". This document defines the following flags:
OAM函数标志是基于TLV的长度字段具有可扩展长度的位图。位从左到右编号。TLV填充为4-octet对齐。长度字段以八位字节表示填充TLV的大小。IANA在新的“RSVP-TE OAM配置注册表”中维护OAM功能标志。本文件定义了以下标志：
OAM Function Flag bit # Description
----------------------- ---------------------------------------------
0 Continuity Check (CC)
1 Connectivity Verification (CV)
2 Fault Management Signal (FMS)
3 Performance Monitoring/Loss (PM/Loss)
4 Performance Monitoring/Delay (PM/Delay)
5 Performance Monitoring/Throughput Measurement
(PM/Throughput)
OAM Function Flag bit # Description
----------------------- ---------------------------------------------
0 Continuity Check (CC)
1 Connectivity Verification (CV)
2 Fault Management Signal (FMS)
3 Performance Monitoring/Loss (PM/Loss)
4 Performance Monitoring/Delay (PM/Delay)
5 Performance Monitoring/Throughput Measurement
(PM/Throughput)
If technology-specific configuration information is needed for a specific "OAM Type", then this information is carried in a technology-specific sub-TLV. Such sub-TLVs are OPTIONAL, and an OAM Configuration TLV MUST NOT contain more than one technology-specific sub-TLV. IANA maintains the OAM technology-specific sub-TLV space in the new "RSVP-TE OAM Configuration Registry".
如果特定的“OAM类型”需要特定于技术的配置信息，则该信息将携带在特定于技术的子TLV中。此类子TLV是可选的，OAM配置TLV不得包含多个特定于技术的子TLV。IANA在新的“RSVP-TE OAM配置注册表”中维护OAM技术特定的子TLV空间。
Administrative Status Information is carried in the Admin_Status object, which is specified for RSVP-TE in [RFC3473]. Administrative Status Information is described in [RFC3471].
管理状态信息包含在Admin_Status对象中，该对象在[RFC3473]中为RSVP-TE指定。[RFC3471]中描述了管理状态信息。
Two bits (bit numbers 23 and 24) are allocated by this document for the administrative control of OAM monitoring: the "OAM Flows Enabled" (M) and "OAM Alarms Enabled" (O) bits. When the "OAM Flows Enabled" bit is set, OAM mechanisms MUST be enabled; if it is cleared, OAM mechanisms MUST be disabled. When the "OAM Alarms Enabled" bit is set, OAM-triggered alarms are enabled and associated consequent actions MUST be executed, including the notification to the management system. When this bit is cleared, alarms are suppressed, and no action SHOULD be executed; additionally, the management system SHOULD NOT be notified. For a detailed description of the use of these flags, see Section 3.
本文件为OAM监控的管理控制分配了两个位（位号23和24）：“已启用OAM流”（M）和“已启用OAM报警”（O）位。设置“OAM流启用”位时，必须启用OAM机制；如果清除，则必须禁用OAM机制。当设置“OAM警报已启用”位时，OAM触发的警报将启用，并且必须执行相关的后续操作，包括向管理系统发出通知。当该位被清除时，报警被抑制，不应执行任何操作；此外，不应通知管理系统。有关这些标志使用的详细说明，请参见第3节。
To handle OAM configuration errors, a new Error Code "OAM Problem" (40) is introduced. To refer to specific problems, a set of Error Values are defined under the "OAM Problem" error code.
为了处理OAM配置错误，引入了一个新的错误代码“OAM问题”（40）。为了表示特定的问题，在“OAM问题”错误代码下定义了一组错误值。
If a node does not support the establishment of OAM MEP or MIP entities it MUST use the error value "MEP establishment not supported" or "MIP establishment not supported", respectively, in the PathErr message.
如果节点不支持建立OAM MEP或MIP实体，则必须在PathErr消息中分别使用错误值“MEP建立不受支持”或“MIP建立不受支持”。
If a node does not support a specific OAM technology/solution, it MUST use the error value "Unsupported OAM Type" in the PathErr message.
如果节点不支持特定的OAM技术/解决方案，则必须在PathErr消息中使用错误值“Unsupported OAM Type”。
If a different technology-specific OAM Configuration TLV is included than what was specified in the OAM Type, an error MUST be generated with error value "OAM Type Mismatch" in the PathErr message.
如果包含的特定于技术的OAM配置TLV与OAM类型中指定的不同，则必须在PathErr消息中生成错误值为“OAM类型不匹配”。
There is a hierarchy between the OAM configuration elements. If this hierarchy is broken, the error value "Configuration Error" MUST be used in the PathErr message.
OAM配置元素之间存在层次结构。如果此层次结构被破坏，则必须在PathErr消息中使用错误值“Configuration error”。
If a node does not support a specific OAM Function, it MUST use the error value "Unsupported OAM Function" in the PathErr message.
如果节点不支持特定的OAM函数，则必须在PathErr消息中使用错误值“Unsupported OAM Function”。
RSVP-TE extensions for the establishment of point-to-multipoint (P2MP) LSPs are specified in [RFC4875]. A P2MP LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set up between the ingress and egress LSRs and are appropriately combined by the branch LSRs using RSVP semantics to result in a P2MP TE LSP. One Path message may signal one or multiple S2L sub-LSPs for a single P2MP LSP. Hence, the S2L sub-LSPs belonging to a P2MP LSP can be signaled using one Path message or split across multiple Path messages.
[RFC4875]中规定了用于建立点对多点（P2MP）LSP的RSVP-TE扩展。P2MP LSP由多个源到叶（S2L）子LSP组成。这些S2L子LSP设置在入口和出口lsr之间，并由分支lsr使用RSVP语义适当组合，以产生P2MP TE LSP。一条路径消息可以向单个P2MP LSP的一个或多个S2L子LSP发送信号。因此，属于P2MP LSP的S2L子LSP可以使用一条路径消息来发信号，或者在多条路径消息之间分割。
P2MP OAM mechanisms are very specific to the data-plane technology; therefore, in this document we only highlight the basic principles of P2MP OAM configuration. We consider only the root-to-leaf OAM flows, and as such, aspects of the configuration of return paths are outside the scope of our discussions. We also limit our consideration to the case where all leaves must successfully establish OAM entities with identical configuration in order for the P2MP OAM to be successfully established. In any case, the discussion set forth below provides
P2MP OAM机制非常特定于数据平面技术；因此，在本文中，我们仅强调P2MP OAM配置的基本原则。我们只考虑根到叶OAM流，因此，返回路径的配置方面不在我们讨论的范围之内。我们还将我们的考虑限制在这样的情况下：为了成功地建立P2MP OAM，所有的叶子必须成功地建立具有相同配置的OAM实体。在任何情况下，以下讨论提供了
only guidelines for P2MP OAM configuration. However, at a minimum, the procedures below SHOULD be specified for P2MP OAM configuration in a technology-specific document.
仅适用于P2MP OAM配置的指南。但是，至少应在技术特定文档中为P2MP OAM配置指定以下步骤。
The root node may use a single Path message or multiple Path messages to set up the whole P2MP tree. In the case when multiple Path messages are used, the root node is responsible for keeping the OAM configuration information consistent in each of the sent Path messages, i.e., the same information MUST be included in all Path messages used to construct the multicast tree. Each branching node will propagate the Path message downstream on each of the branches; when constructing a Path message, the OAM configuration information MUST be copied unchanged from the received Path message, including the related Admin_Status bits, LSP attribute flags, and OAM Configuration TLV. The latter two also imply that the LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects MUST be copied for the upstream Path message to the subsequent downstream Path messages.
根节点可以使用单路径消息或多路径消息来建立整个P2MP树。在使用多个路径消息的情况下，根节点负责在每个发送的路径消息中保持OAM配置信息的一致性，即，用于构造多播树的所有路径消息中必须包括相同的信息。每个分支节点将在每个分支上向下游传播路径消息；构造路径消息时，必须从接收到的路径消息中复制OAM配置信息（包括相关的Admin_状态位、LSP属性标志和OAM配置TLV），而不做任何更改。后两者还意味着上游路径消息必须将LSP_属性和LSP_REQUIRED_属性对象复制到后续下游路径消息。
Leaves MUST create and configure OAM sink functions according to the parameters received in the Path message; for P2MP OAM configuration, there is no possibility for parameter negotiation on a per-leaf basis. This is due to the fact that the OAM source function, residing in the root of the tree, will operate with a single configuration, which then must be obeyed by all leaves. If a leaf cannot accept the OAM parameters, it MUST use the RRO Attributes sub-object [RFC5420] to notify the root about the problem. In particular, if the OAM configuration was successful, the leaf would set the "OAM MEP entities desired" flag in the RRO Attributes sub-object in the Resv message. On the other hand, if OAM entities could not be established, the Resv message should be sent with the "OAM MEP entities desired" bit cleared in the RRO Attributes sub-object. Branching nodes should collect and merge the received RROs according to the procedures described in [RFC4875]. This way, the root, when receiving the Resv message (or messages if multiple Path messages were used to set up the tree), will have clear information about which of the leaves could establish the OAM functions. If all leaves established OAM entities successfully, the root can enable the OAM message flow. On the other hand, if at some leaves the establishment was unsuccessful, additional actions will be needed before the OAM message flow can be enabled. Such action could be to set up two independent P2MP LSPs:
叶子必须根据路径消息中接收的参数创建和配置OAM接收器功能；对于P2MP OAM配置，不可能基于每个叶进行参数协商。这是因为驻留在树根中的OAM源函数将使用单个配置进行操作，所有叶都必须遵守该配置。如果叶不能接受OAM参数，则必须使用RRO Attributes子对象[RFC5420]将问题通知根。特别是，如果OAM配置成功，则叶将在Resv消息中的RRO Attributes子对象中设置“OAM MEP entities desired”标志。另一方面，如果无法建立OAM实体，则发送Resv消息时应清除RRO Attributes子对象中的“OAM MEP entities desired”位。分支节点应根据[RFC4875]中描述的过程收集和合并接收到的RRO。这样，根用户在接收Resv消息（或者如果使用多路径消息来建立树，则为消息）时，将有关于哪些叶可以建立OAM功能的明确信息。如果所有已建立的OAM实体都成功离开，则根用户可以启用OAM消息流。另一方面，如果在某些假期建立不成功，则在启用OAM消息流之前，需要执行其他操作。此类行动可设置两个独立的P2MP LSP：
o One LSP with OAM configuration information towards leaves that can support the OAM function. This can be done by pruning from the previously signaled P2MP LSP the leaves that failed to set up OAM.
o 一个带有OAM配置信息的LSP，指向可以支持OAM功能的叶子。这可以通过从先前发出信号的P2MP LSP中修剪未能设置OAM的叶子来实现。
o The other P2MP LSP could be constructed for leaves without OAM entities.
o 另一个P2MP LSP可以为没有OAM实体的叶子构造。
The exact procedures will be described in technology-specific documents.
具体程序将在技术特定文件中描述。
IANA maintains a registry called "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" with a sub-registry called "Administrative Status Information Flags".
IANA维护一个名为“通用多协议标签交换（GMPLS）信令参数”的注册表和一个名为“管理状态信息标志”的子注册表。
IANA has allocated two new flags as follows:
IANA分配了两个新标志，如下所示：
Bit Number | Hex Value | Name | Reference
-----------+------------+--------------------------+-----------
23 | 0x00000100 | OAM Flows Enabled (M) | [RFC7260]
24 | 0x00000080 | OAM Alarms Enabled (O) | [RFC7260]
Bit Number | Hex Value | Name | Reference
-----------+------------+--------------------------+-----------
23 | 0x00000100 | OAM Flows Enabled (M) | [RFC7260]
24 | 0x00000080 | OAM Alarms Enabled (O) | [RFC7260]
IANA maintains a registry called "Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" with a sub-registry called "Attribute Flags".
IANA维护一个名为“资源预留协议流量工程（RSVP-TE）参数”的注册表和一个名为“属性标志”的子注册表。
IANA has allocated two new flags as follows:
IANA分配了两个新标志，如下所示：
Bit | | Attribute | Attribute | |
No. | Name | Flags Path | Flags Resv | RRO | Reference
----+------------------+------------+------------+-----+----------
10 | OAM MEP | | | |
| entities desired | Yes | Yes | Yes | [RFC7260]
| | | | |
11 | OAM MIP | | | |
| entities desired | Yes | Yes | Yes | [RFC7260]
Bit | | Attribute | Attribute | |
No. | Name | Flags Path | Flags Resv | RRO | Reference
----+------------------+------------+------------+-----+----------
10 | OAM MEP | | | |
| entities desired | Yes | Yes | Yes | [RFC7260]
| | | | |
11 | OAM MIP | | | |
| entities desired | Yes | Yes | Yes | [RFC7260]
IANA maintains a registry called "Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" with a sub-registry called "Attributes TLV Space".
IANA维护一个名为“资源预留协议流量工程（RSVP-TE）参数”的注册表和一个名为“属性TLV空间”的子注册表。
IANA has allocated one new TLV type as follows:
IANA已分配一种新的TLV类型，如下所示：
| | |Allowed on |
| |Allowed on |LSP_REQUIRED_|
Type| Name |LSP_ATTRIBUTES|ATTRIBUTES |Reference
----+----------------------+--------------+-------------+---------
3 | OAM Configuration TLV| Yes | Yes |[RFC7260]
| | |Allowed on |
| |Allowed on |LSP_REQUIRED_|
Type| Name |LSP_ATTRIBUTES|ATTRIBUTES |Reference
----+----------------------+--------------+-------------+---------
3 | OAM Configuration TLV| Yes | Yes |[RFC7260]
IANA maintains a registry called "Resource Reservation Protocol (RSVP) Parameters" with a sub-registry called "Error Codes and Globally-Defined Error Value Sub-Codes".
IANA维护一个名为“资源保留协议（RSVP）参数”的注册表，其中包含一个名为“错误代码和全局定义的错误值子代码”的子注册表。
IANA has allocated one new Error Code as follows:
IANA分配了一个新的错误代码，如下所示：
Error Code | Meaning | Reference
-----------+-------------+-------------
40 | OAM Problem | [RFC7260]
Error Code | Meaning | Reference
-----------+-------------+-------------
40 | OAM Problem | [RFC7260]
The following Error Value sub-codes are defined for this new Error Code:
为此新错误代码定义了以下错误值子代码：
Value | Description | Reference
-----------+---------------------------------+--------------
0 | Reserved | [RFC7260]
1 | MEP establishment not supported | [RFC7260]
2 | MIP establishment not supported | [RFC7260]
3 | Unsupported OAM Type | [RFC7260]
4 | Configuration Error | [RFC7260]
5 | OAM Type Mismatch | [RFC7260]
6 | Unsupported OAM Function | [RFC7260]
7-32767 | Unassigned |
32768-65535| Reserved for Private Use | [RFC7260]
Value | Description | Reference
-----------+---------------------------------+--------------
0 | Reserved | [RFC7260]
1 | MEP establishment not supported | [RFC7260]
2 | MIP establishment not supported | [RFC7260]
3 | Unsupported OAM Type | [RFC7260]
4 | Configuration Error | [RFC7260]
5 | OAM Type Mismatch | [RFC7260]
6 | Unsupported OAM Function | [RFC7260]
7-32767 | Unassigned |
32768-65535| Reserved for Private Use | [RFC7260]
IANA has created a new registry called "RSVP-TE OAM Configuration Registry".
IANA创建了一个名为“RSVP-TE OAM配置注册表”的新注册表。
IANA has created sub-registries as defined in the following subsections. The registration procedures specified are as defined in [RFC5226].
IANA已创建了以下小节中定义的子注册表。规定的注册程序如[RFC5226]所述。
IANA has created the "OAM Types" sub-registry of the "RSVP-TE OAM Configuration Registry" as follows:
IANA已创建“RSVP-TE OAM配置注册表”的“OAM类型”子注册表，如下所示：
Range | Registration Procedures
-------+-------------------------
0-255 | IETF Review
Range | Registration Procedures
-------+-------------------------
0-255 | IETF Review
There are no initial values in this registry. IANA shows the registry as follows:
此注册表中没有初始值。IANA将注册表显示如下：
OAM Type Number | OAM Type Description | Reference
----------------+----------------------+--------------
0-255 | Unassigned |
OAM Type Number | OAM Type Description | Reference
----------------+----------------------+--------------
0-255 | Unassigned |
IANA has created the "OAM Sub-TLVs" sub-registry of the "RSVP-TE OAM Configuration Registry" as follows:
IANA已创建“RSVP-TE OAM配置注册表”的“OAM子TLV”子注册表，如下所示：
Range | Note | Registration Procedures
------------+------------------------------|------------------------
0-31 | Generic Sub-TLVs | IETF Review
32-65534 | Technology-specific Sub-TLVs | IETF Review
65535-65536 | Experimental Sub-TLVs | Reserved for
| Experimental Use
Range | Note | Registration Procedures
------------+------------------------------|------------------------
0-31 | Generic Sub-TLVs | IETF Review
32-65534 | Technology-specific Sub-TLVs | IETF Review
65535-65536 | Experimental Sub-TLVs | Reserved for
| Experimental Use
IANA has populated the registry as follows:
IANA已填充注册表，如下所示：
Sub-TLV Type | Description | Reference
-------------+-------------------------------+----------
0 | Reserved | [RFC7260]
1 | OAM Function Flags Sub-TLV | [RFC7260]
2-65534 | Unassigned |
65535-65536 | Reserved for Experimental Use | [RFC7260]
Sub-TLV Type | Description | Reference
-------------+-------------------------------+----------
0 | Reserved | [RFC7260]
1 | OAM Function Flags Sub-TLV | [RFC7260]
2-65534 | Unassigned |
65535-65536 | Reserved for Experimental Use | [RFC7260]
IANA has created the "OAM Function Flags Sub-Registry" sub-registry of the "RSVP-TE OAM Configuration Registry".
IANA已经创建了“RSVP-TE OAM配置注册表”的“OAM功能标志子注册表”子注册表。
New values in the registry are allocated by IETF Review [RFC5226]. There is no top value to the range. Bits are counted from bit 0 as the first bit transmitted.
注册表中的新值由IETF Review[RFC5226]分配。该范围没有最高值。位从位0开始计数，作为传输的第一位。
IANA has populated the registry as follows:
IANA已填充注册表，如下所示：
OAM Function Flag | Description
Bit Number |
------------------+----------------------------------------------
0 | Continuity Check (CC)
1 | Connectivity Verification (CV)
2 | Fault Management Signal (FMS)
3 | Performance Monitoring/Loss (PM/Loss)
4 | Performance Monitoring/Delay (PM/Delay)
5 | Performance Monitoring/Throughput Measurement
| (PM/Throughput)
>=6 | Unassigned
OAM Function Flag | Description
Bit Number |
------------------+----------------------------------------------
0 | Continuity Check (CC)
1 | Connectivity Verification (CV)
2 | Fault Management Signal (FMS)
3 | Performance Monitoring/Loss (PM/Loss)
4 | Performance Monitoring/Delay (PM/Delay)
5 | Performance Monitoring/Throughput Measurement
| (PM/Throughput)
>=6 | Unassigned
The signaling of OAM-related parameters and the automatic establishment of OAM entities based on RSVP-TE messages add a new aspect to the security considerations discussed in [RFC3473]. In particular, a network element could be overloaded if a remote attacker targeted that element by sending frequent periodic messages requesting liveliness monitoring of a high number of LSPs. Such an attack can efficiently be prevented when mechanisms for message integrity and node authentication are deployed. Since the OAM configuration extensions rely on the hop-by-hop exchange of exiting RSVP-TE messages, procedures specified for RSVP message security in [RFC2747] can be used to mitigate possible attacks.
OAM相关参数的信令和基于RSVP-TE消息的OAM实体的自动建立为[RFC3473]中讨论的安全注意事项增加了一个新的方面。特别是，如果远程攻击者通过发送频繁的周期性消息，请求对大量LSP进行活动性监视，从而锁定网元，则网元可能会过载。当部署消息完整性和节点身份验证机制时，可以有效地防止此类攻击。由于OAM配置扩展依赖于现有RSVP-TE消息的逐跳交换，因此可以使用[RFC2747]中为RSVP消息安全性指定的过程来减轻可能的攻击。
For a more comprehensive discussion of GMPLS security and attack mitigation techniques, please see the Security Framework for MPLS and GMPLS Networks [RFC5920].
有关GMPLS安全和攻击缓解技术的更全面的讨论，请参阅MPLS和GMPLS网络的安全框架[RFC5920]。
The authors would like to thank Francesco Fondelli, Adrian Farrel, Loa Andersson, Eric Gray, and Dimitri Papadimitriou for their useful comments.
作者要感谢Francesco Fondelli、Adrian Farrel、Loa Andersson、Eric Gray和Dimitri Papadimitriou的有用评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, February 2009.
[RFC5420]Farrel，A.，Papadimitriou，D.，Vasseur，JP.，和A.Ayyangarps，“使用资源预留协议流量工程（RSVP-TE）对MPLS LSP建立的属性进行编码”，RFC 5420，2009年2月。
[IEEE.802.1Q-2011] IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Std 802.1Q, 2011.
[IEEE.802.1Q-2011]IEEE，“局域网和城域网的IEEE标准——媒体访问控制（MAC）网桥和虚拟桥接局域网”，IEEE标准802.1Q，2011年。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]Baker，F.，Lindell，B.和M.Talwar，“RSVP加密认证”，RFC 2747，2000年1月。
[RFC4377] 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.
[RFC4377]Nadeau，T.，Morrow，M.，Swallow，G.，Allan，D.，和S.Matsushima，“多协议标签交换（MPLS）网络的运营和管理（OAM）要求”，RFC 4377，2006年2月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379]Kompella，K.和G.Swallow，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，2006年2月。
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4875]Aggarwal，R.，Papadimitriou，D.，和S.Yasukawa，“资源预留协议的扩展-点对多点TE标签交换路径（LSP）的流量工程（RSVP-TE）”，RFC 4875，2007年5月。
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[RFC5654]Niven Jenkins，B.，Brungard，D.，Betts，M.，Sprecher，N.，和S.Ueno，“MPLS传输配置文件的要求”，RFC 56542009年9月。
[RFC5828] Fedyk, D., Berger, L., and L. Andersson, "Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework", RFC 5828, March 2010.
[RFC5828]Fedyk，D.，Berger，L.，和L.Andersson，“通用多协议标签交换（GMPLS）以太网标签交换体系结构和框架”，RFC 58282010年3月。
[RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010.
[RFC5860]Vigoureux，M.，Ward，D.，和M.Betts，“MPLS传输网络中的操作、管理和维护（OAM）要求”，RFC 5860，2010年5月。
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]方，L，“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月。
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
[RFC5921]Bocci，M.，Bryant，S.，Frost，D.，Levrau，L.，和L.Berger，“传输网络中MPLS的框架”，RFC 59212010年7月。
[RFC6060] Fedyk, D., Shah, H., Bitar, N., and A. Takacs, "Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE)", RFC 6060, March 2011.
[RFC6060]Fedyk，D.，Shah，H.，Bitar，N.，和A.Takacs，“以太网提供商主干流量工程（PBB-TE）的通用多协议标签交换（GMPLS）控制”，RFC 6060，2011年3月。
Authors' Addresses
作者地址
Attila Takacs Ericsson Konyves Kalman krt. 11. Budapest 1097 Hungary
阿提拉·塔卡什·爱立信·柯尼夫·卡尔曼·克尔特。11布达佩斯1097匈牙利
EMail: attila.takacs@ericsson.com
EMail: attila.takacs@ericsson.com
Don Fedyk Hewlett-Packard Company 153 Taylor Street Littleton, MA 01460 USA
Don Fedyk Hewlett-Packard Company美国马萨诸塞州利特尔顿泰勒街153号01460
EMail: don.fedyk@hp.com
EMail: don.fedyk@hp.com
Jia He Huawei PR China
华为公关中国有限公司
EMail: hejia@huawei.com
EMail: hejia@huawei.com