Internet Engineering Task Force (IETF) A. Takacs
Request for Comments: 7369 B. Gero
Category: Standards Track Ericsson
ISSN: 2070-1721 H. Long
Huawei
October 2014
Internet Engineering Task Force (IETF) A. Takacs
Request for Comments: 7369 B. Gero
Category: Standards Track Ericsson
ISSN: 2070-1721 H. Long
Huawei
October 2014
GMPLS RSVP-TE Extensions for Ethernet Operations, Administration, and Maintenance (OAM) Configuration
用于以太网操作、管理和维护（OAM）配置的GMPLS RSVP-TE扩展
Abstract
摘要
The work related to GMPLS Ethernet Label Switching (GELS) extended GMPLS RSVP-TE to support the establishment of Ethernet Label Switching Paths (LSPs). IEEE Ethernet Connectivity Fault Management (CFM) specifies an adjunct Operations, Administration, and Maintenance (OAM) flow to check connectivity in Ethernet networks. CFM can also be used with Ethernet LSPs for fault detection and triggering recovery mechanisms. The ITU-T Y.1731 specification builds on CFM and specifies additional OAM mechanisms, including Performance Monitoring, for Ethernet networks. This document specifies extensions of the GMPLS RSVP-TE protocol to support the setup of the associated Ethernet OAM entities of Ethernet LSPs and defines the Ethernet technology-specific TLVs based on the GMPLS OAM Configuration Framework. This document supports, but does not modify, the IEEE and ITU-T OAM mechanisms.
与GMPLS以太网标签交换（GELS）相关的工作扩展了GMPLS RSVP-TE，以支持建立以太网标签交换路径（LSP）。IEEE Ethernet Connectivity Fault Management（CFM）指定了一个辅助操作、管理和维护（OAM）流程，用于检查以太网中的连接。CFM还可以与以太网LSP一起用于故障检测和触发恢复机制。ITU-T Y.1731规范建立在CFM的基础上，并为以太网指定了额外的OAM机制，包括性能监控。本文件规定了GMPLS RSVP-TE协议的扩展，以支持以太网LSP相关以太网OAM实体的设置，并基于GMPLS OAM配置框架定义了以太网技术特定的TLV。本文档支持但不修改IEEE和ITU-T 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/rfc7369.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7369.
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. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Overview of Ethernet OAM Operation . . . . . . . . . . . . . 3
3. GMPLS RSVP-TE Extensions . . . . . . . . . . . . . . . . . . 5
3.1. Operation Overview . . . . . . . . . . . . . . . . . . . 5
3.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 7
3.3. Ethernet OAM Configuration Sub-TLV . . . . . . . . . . . 8
3.3.1. MD Name Sub-TLV . . . . . . . . . . . . . . . . . . . 9
3.3.2. Short MA Name Sub-TLV . . . . . . . . . . . . . . . . 10
3.3.3. MEP ID Sub-TLV . . . . . . . . . . . . . . . . . . . 11
3.3.4. Continuity Check (CC) Sub-TLV . . . . . . . . . . . . 12
3.4. Proactive Performance Monitoring . . . . . . . . . . . . 12
3.5. Summary of Ethernet OAM Configuration Errors . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
4.1. RSVP-TE OAM Configuration Registry . . . . . . . . . . . 14
4.2. Ethernet Sub-TLVs Sub-Registry . . . . . . . . . . . . . 15
4.3. RSVP Error Code . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Normative References . . . . . . . . . . . . . . . . . . 16
6.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Overview of Ethernet OAM Operation . . . . . . . . . . . . . 3
3. GMPLS RSVP-TE Extensions . . . . . . . . . . . . . . . . . . 5
3.1. Operation Overview . . . . . . . . . . . . . . . . . . . 5
3.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 7
3.3. Ethernet OAM Configuration Sub-TLV . . . . . . . . . . . 8
3.3.1. MD Name Sub-TLV . . . . . . . . . . . . . . . . . . . 9
3.3.2. Short MA Name Sub-TLV . . . . . . . . . . . . . . . . 10
3.3.3. MEP ID Sub-TLV . . . . . . . . . . . . . . . . . . . 11
3.3.4. Continuity Check (CC) Sub-TLV . . . . . . . . . . . . 12
3.4. Proactive Performance Monitoring . . . . . . . . . . . . 12
3.5. Summary of Ethernet OAM Configuration Errors . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
4.1. RSVP-TE OAM Configuration Registry . . . . . . . . . . . 14
4.2. Ethernet Sub-TLVs Sub-Registry . . . . . . . . . . . . . 15
4.3. RSVP Error Code . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Normative References . . . . . . . . . . . . . . . . . . 16
6.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
Provider Backbone Bridging - Traffic Engineering (PBB-TE) [IEEE.802.1Q-2011] decouples the Ethernet data and control planes and allows external control and management mechanisms to create explicitly routed Ethernet connections. In addition, PBB-TE defines mechanisms for protection switching of bidirectional Ethernet connections. Ethernet Connectivity Fault Management (CFM) defines an adjunct connectivity-monitoring OAM flow to check the liveliness of Ethernet networks [IEEE.802.1Q-2011], including the monitoring of specific explicitly routed Ethernet connections. The ITU-T Recommendation Y.1731 [ITU-T.G.8013-2013] extended CFM and specified additional OAM functionality.
提供商主干桥接-流量工程（PBB-TE）[IEEE.802.1Q-2011]将以太网数据和控制平面解耦，并允许外部控制和管理机制创建明确路由的以太网连接。此外，PBB-TE定义了双向以太网连接的保护交换机制。Ethernet Connectivity Fault Management（CFM）定义了一个附加连接监控OAM流，以检查以太网的活跃性[IEEE.802.1Q-2011]，包括监控特定的显式路由以太网连接。ITU-T建议Y.1731[ITU-T.G.8013-2013]扩展了CFM并规定了额外的OAM功能。
In the IETF, the work related to GMPLS Ethernet Label Switching (GELS) extended the GMPLS control plane to support the establishment of explicitly routed Ethernet connections [RFC5828] [RFC6060]. We refer to GMPLS-established Ethernet connections as "Ethernet LSPs". GELS enables the application of MPLS-TE and GMPLS provisioning and recovery features in Ethernet networks.
在IETF中，与GMPLS以太网标签交换（GELS）相关的工作扩展了GMPLS控制平面，以支持建立明确路由的以太网连接[RFC5828][RFC6060]。我们将GMPLS建立的以太网连接称为“以太网LSP”。GELS支持在以太网中应用MPLS-TE和GMPLS资源调配和恢复功能。
The use of GMPLS RSVP-TE to support the establishment and configuration of OAM entities with LSP signaling is defined in a technology-agnostic way in [RFC7260]. The purpose of this document is to specify the additional technology-specific OAM entities to support Ethernet connections.
使用GMPLS RSVP-TE支持使用LSP信令的OAM实体的建立和配置在[RFC7260]中以技术无关的方式定义。本文档的目的是指定支持以太网连接的其他特定于技术的OAM实体。
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]中所述进行解释。
For the purposes of this document, we only discuss Ethernet OAM aspects that are relevant for proactive connectivity monitoring of Ethernet LSPs and assume that on-demand OAM functions will be supported by management-plane operations.
在本文档中，我们仅讨论与以太网LSP的主动连接监控相关的以太网OAM方面，并假设管理平面操作将支持按需OAM功能。
PBB-TE defines point-to-point Ethernet Switched Paths (ESPs) as a provisioned, traffic-engineered, unidirectional connectivity, identified by the 3-tuple [ESP-MAC DA, ESP-MAC SA, ESP-VID], where the ESP-MAC DA is the destination address of the ESP, the ESP-MAC SA is the source address of the ESP, and the ESP-VID is a VLAN identifier allocated for explicitly routed connections. To form a bidirectional PBB-TE connection, two co-routed point-to-point ESPs are combined. The combined ESPs must have the same ESP-MAC addresses
PBB-TE将点对点以太网交换路径（ESP）定义为一种由三元组[ESP-MAC DA、ESP-MAC SA、ESP-VID]标识的供应、流量工程的单向连接，其中ESP-MAC DA是ESP的目标地址，ESP-MAC SA是ESP的源地址，ESP-VID是为显式路由连接分配的VLAN标识符。为了形成双向PBB-TE连接，组合了两个共同路由的点到点ESP。组合的ESP必须具有相同的ESP-MAC地址
but may have different ESP-VIDs. The formed co-routed bidirectional path is a path where the forward and backward directions follow the same route (links and nodes) across the network.
但可能有不同的ESP视频。形成的共路由双向路径是一条路径，其中向前和向后方向在网络上遵循相同的路由（链路和节点）。
Note that although it would be possible to use GMPLS to set up a single unidirectional ESP, the Ethernet OAM mechanisms are only fully functional when bidirectional connections are established with co-routed ESPs. Therefore, the scope of this document only covers bidirectional point-to-point PBB-TE connections.
请注意，尽管可以使用GMPLS设置单个单向ESP，但以太网OAM机制只有在与共路由ESP建立双向连接时才能完全发挥作用。因此，本文档的范围仅涵盖双向点对点PBB-TE连接。
At both ends of the bidirectional point-to-point PBB-TE connection, one Maintenance Entity Group End Point (MEP) is configured. The MEPs monitoring a PBB-TE connection must be configured with the same Maintenance Domain Level (MD Level) and Maintenance Association Identifier (MAID). Each MEP has a unique identifier, the MEP ID. Besides these identifiers, a MEP monitoring a PBB-TE connection must be provisioned with the 3-tuples [ESP-MAC DA, ESP-MAC SA, ESP-VID] of the two ESPs.
在双向点对点PBB-TE连接的两端，配置一个维护实体组端点（MEP）。监视PBB-TE连接的MEP必须配置相同的维护域级别（MD级别）和维护关联标识符（MAID）。每个MEP都有一个唯一的标识符，即MEP ID。除这些标识符外，监测PBB-TE连接的MEP必须配备两个ESP的3元组[ESP-MAC DA、ESP-MAC SA、ESP-VID]。
In the case of point-to-point VLAN connections, the connection may be identified with a single VLAN or with two VLANs, one for each direction. Therefore, instead of the 3-tuples of the PBB-TE ESPs, MEPs must be provisioned with the proper VLAN identifiers.
在点对点VLAN连接的情况下，可以使用单个VLAN或两个VLAN来标识连接，每个方向一个VLAN。因此，代替PBB-TE ESP的3元组，MEP必须配备适当的VLAN标识符。
MEPs exchange Connectivity Check Messages (CCMs) periodically with fixed intervals. Eight distinct intervals are defined in [IEEE.802.1Q-2011]:
MEP定期以固定的间隔交换连接检查消息（CCM）。[IEEE.802.1Q-2011]中定义了八个不同的间隔：
+---+--------------------+----------------+
| # | CCM Interval (CCI) | 3-Bit Encoding |
+---+--------------------+----------------+
| 0 | Reserved | 000 |
| | | |
| 1 | 3 1/3 ms | 001 |
| | | |
| 2 | 10 ms | 010 |
| | | |
| 3 | 100 ms | 011 |
| | | |
| 4 | 1 s | 100 |
| | | |
| 5 | 10 s | 101 |
| | | |
| 6 | 1 min | 110 |
| | | |
| 7 | 10 min | 111 |
+---+--------------------+----------------+
Table 1: CCM Interval Encoding
+---+--------------------+----------------+
| # | CCM Interval (CCI) | 3-Bit Encoding |
+---+--------------------+----------------+
| 0 | Reserved | 000 |
| | | |
| 1 | 3 1/3 ms | 001 |
| | | |
| 2 | 10 ms | 010 |
| | | |
| 3 | 100 ms | 011 |
| | | |
| 4 | 1 s | 100 |
| | | |
| 5 | 10 s | 101 |
| | | |
| 6 | 1 min | 110 |
| | | |
| 7 | 10 min | 111 |
+---+--------------------+----------------+
Table 1: CCM Interval Encoding
If three consecutive CCMs are lost, connectivity failure is declared. The MEP detecting the failure will signal the defect to the remote MEP in the subsequent CCMs it emits by setting the Remote Defect Indicator (RDI) bit in the CCM. If a MEP receives a CCM with the RDI bit set, it immediately declares failure. The detection of a failure may trigger protection switching mechanisms or may be signaled to a management system.
如果连续三个CCM丢失，则宣布连接失败。检测到故障的MEP将通过在CCM中设置远程缺陷指示器（RDI）位，在随后的CCM中向远程MEP发送缺陷信号。如果MEP接收到设置了RDI位的CCM，它会立即宣布失败。故障检测可触发保护切换机制，或向管理系统发送信号。
At each transit node, Maintenance Entity Group Intermediate Points (MIPs) may be established to help failure localization, e.g., using link trace and loopback functions. MIPs need to be provisioned with a subset of the MEP identification parameters described above.
在每个运输节点，可建立维护实体组中间点（MIP），以帮助故障定位，例如，使用链路跟踪和环回功能。MIPs需要配备上述MEP标识参数的子集。
To simplify the configuration of connectivity monitoring, the associated MEPs should be automatically established when an Ethernet LSP is signaled. To monitor an Ethernet LSP, a set of parameters must be provided to set up a Maintenance Association and related MEPs. Optionally, MIPs may be created at the transit nodes of the Ethernet LSP. The LSP Attribute Flags "OAM MEP entities desired" and "OAM MIP entities desired", as described in [RFC7260], are used to signal that the respective OAM entities must be established. An OAM Configuration TLV, as described in [RFC7260], is added to the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES objects specifying that Ethernet OAM is to be set up for the LSP. Information specific to Ethernet OAM, as described below, is carried in the new Ethernet OAM Configuration Sub-TLV (see Section 3.3) within the OAM Configuration TLV.
为了简化连接监控的配置，当以太网LSP发出信号时，应自动建立相关的MEP。要监视以太网LSP，必须提供一组参数以建立维护关联和相关MEP。可选地，可以在以太网LSP的传输节点处创建mip。如[RFC7260]中所述，LSP属性标志“需要OAM MEP实体”和“需要OAM MIP实体”用于表示必须建立相应的OAM实体。[RFC7260]中所述的OAM配置TLV添加到LSP_属性或LSP_REQUIRED_属性对象中，指定要为LSP设置以太网OAM。如下所述，特定于以太网OAM的信息载于OAM配置TLV内的新以太网OAM配置子TLV（见第3.3节）。
o A unique MAID must be allocated for the PBB-TE connection, and both MEPs must be configured with the same information. The MAID consists of an optional Maintenance Domain Name (MD Name) and a mandatory Short Maintenance Association Name (Short MA Name). Various formatting rules for these names have been defined in [IEEE.802.1Q-2011]. Since this information is also carried in all CCMs, the combined length of the MD Name and Short MA Name is limited to 44 bytes (see [IEEE.802.1Q-2011] for the details of the message format). How these parameters are determined is out of the scope of this document.
o 必须为PBB-TE连接分配唯一的MAID，并且两个MEP必须配置相同的信息。MAID由可选维护域名（MD名称）和必需的短维护关联名称（短MA名称）组成。[IEEE.802.1Q-2011]中定义了这些名称的各种格式规则。由于此信息也在所有CCM中传输，MD名称和短MA名称的组合长度限制为44字节（有关消息格式的详细信息，请参见[IEEE.802.1Q-2011]）。如何确定这些参数超出了本文件的范围。
o Each MEP must be provisioned with a MEP ID. The MEP ID uniquely identifies a given MEP within a Maintenance Association. That is, the combination of MAID and MEP ID must uniquely identify a MEP. How the value of the MEP ID is determined is out of the scope of this document.
o 每个MEP必须配置一个MEP ID。MEP ID在维护关联中唯一标识给定MEP。也就是说，MAID和MEP ID的组合必须唯一标识MEP。如何确定MEP ID的值超出了本文档的范围。
o The Maintenance Domain Level (MD Level) allows hierarchical separation of monitoring entities. [IEEE.802.1Q-2011] allows differentiation of eight levels. How the value of the MD Level is determined is out of the scope of this document. Note that probably for all Ethernet LSPs, a single (default) MD Level will be used within a network domain.
o 维护域级别（MD级别）允许监控实体的分层分离。[IEEE.802.1Q-2011]允许区分八个级别。如何确定MD级别的值超出了本文档的范围。请注意，对于所有以太网LSP，可能会在网络域中使用单个（默认）MD级别。
o The desired CCM Interval must be specified by the management system based on service requirements or operator policy. The same CCM Interval must be set in each of the MEPs monitoring a given Ethernet LSP. How the value of the CCM Interval is determined is out of the scope of this document.
o 管理系统必须根据服务要求或运营商政策规定所需的CCM间隔。必须在每个监测给定以太网LSP的MEP中设置相同的CCM间隔。如何确定CCM间隔的值超出了本文件的范围。
o The desired forwarding priority to be set by MEPs for the CCM frames may be specified. The same CCM priority must be set in each of the MEPs monitoring a given Ethernet LSP. How CCM priority is determined is out of the scope of this document. Note that the highest priority should be used as the default CCM priority.
o 可以指定由mep为CCM帧设置的期望转发优先级。必须在监测给定以太网LSP的每个MEP中设置相同的CCM优先级。如何确定CCM优先级超出了本文件的范围。请注意，最高优先级应用作默认CCM优先级。
o MEPs must be aware of their own reachability parameters and those of the remote MEP. In the case of bidirectional point-to-point PBB-TE connections, this requires that the 3-tuples [ESP-MAC A, ESP-MAC B, ESP-VID1] and [ESP-MAC B, ESP-MAC A, ESP-VID2] are configured in each MEP, where the ESP-MAC A is the same as the local MEP's Media Access Control (MAC) address and ESP-MAC B is the same as the remote MEP's MAC address. The GMPLS Ethernet Label format, as defined in [RFC6060], consists of the ESP-MAC DA and ESP-VID. Hence, the necessary reachability parameters for the MEPs can be obtained from the Ethernet Labels (i.e., carried in the downstream and upstream labels). In the case of point-to-point VLAN connections, MEPs need to be provisioned with the VLAN identifiers only, which can be derived similarly from the Ethernet Labels.
o MEP必须知道自己的可达性参数和远程MEP的可达性参数。在双向点对点PBB-TE连接的情况下，这要求在每个MEP中配置3元组[ESP-MAC A、ESP-MAC B、ESP-VID1]和[ESP-MAC B、ESP-MAC A、ESP-VID2]，其中ESP-MAC A与本地MEP的媒体访问控制（MAC）地址相同，ESP-MAC B与远程MEP的MAC地址相同。[RFC6060]中定义的GMPLS以太网标签格式由ESP-MAC DA和ESP-VID组成。因此，可以从以太网标签（即，携带在下游和上游标签中）获得MEP的必要可达性参数。在点对点VLAN连接的情况下，MEP只需要配置VLAN标识符，该标识符可以类似地从以太网标签派生。
Based on the procedures described in [RFC6060] for bidirectional PBB-TE Ethernet LSP establishment, the Ethernet OAM configuration procedures are as follows.
基于[RFC6060]中描述的双向PBB-TE以太网LSP建立过程，以太网OAM配置过程如下。
When the RSVP-TE signaling is initiated for the bidirectional Ethernet LSP, the local node generates a Path message and:
当双向以太网LSP的RSVP-TE信令启动时，本地节点生成路径消息并：
o Allocates an upstream label formed by combining its MAC address (ESP-MAC A) and locally selected VID (ESP-VID1), which will be used to receive traffic;
o 分配通过组合其MAC地址（ESP-MAC A）和本地选择的VID（ESP-VID1）形成的上游标签，该标签将用于接收流量；
o MUST include the OAM Configuration TLV with OAM Type set to Ethernet OAM in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES objects;
o 必须在LSP_属性或LSP_REQUIRED_属性对象中包含OAM类型设置为Ethernet OAM的OAM配置TLV；
o MUST include the OAM Function Flags Sub-TLV in the OAM Configuration TLV and set the OAM function flags as needed;
o 必须在OAM配置TLV中包含OAM功能标志子TLV，并根据需要设置OAM功能标志；
o MUST include an Ethernet OAM Configuration Sub-TLV in the OAM Configuration TLV that specifies the CCM Interval and MD Level;
o 必须在OAM配置TLV中包含以太网OAM配置子TLV，该TLV指定CCM间隔和MD级别；
o MAY add an MD Name Sub-TLV (optional) and MUST add a Short MA Name Sub-TLV (required) to the Ethernet OAM Configuration Sub-TLV, which will unambiguously identify a Maintenance Association for this specific PBB-TE connection. Note that values for these parameters may be derived from the GMPLS LSP identification parameters; and
o 可以添加MD名称子TLV（可选），并且必须将短MA名称子TLV（必需）添加到以太网OAM配置子TLV，这将明确标识此特定PBB-TE连接的维护关联。请注意，这些参数的值可以从GMPLS LSP标识参数中导出；和
o MUST include a MEP ID Sub-TLV in the Ethernet OAM Configuration Sub-TLV and select two distinct integer values to identify the local and remote MEPs within the Maintenance Association created for monitoring of the point-to-point PBB-TE connection.
o 必须在以太网OAM配置子TLV中包含MEP ID子TLV，并选择两个不同的整数值，以标识为监控点对点PBB-TE连接而创建的维护关联中的本地和远程MEP。
Once the remote node receives the Path message, it can use the UPSTREAM_LABEL to extract the reachability information of the initiator. Then, it allocates a Label by selecting a local MAC address (ESP-MAC B) and VID (ESP-VID2) that will be used to receive traffic. These parameters determine the reachability information of the local MEP. That is, the 3-tuples [ESP-MAC A, ESP-MAC B, ESP-VID1] and [ESP-MAC B, ESP-MAC A, ESP-VID2] are derived from the Ethernet Labels. In addition, the information received in the Ethernet OAM Configuration TLV is used to configure the local MEP.
一旦远程节点接收到路径消息，它就可以使用上游_标签提取启动器的可达性信息。然后，它通过选择用于接收流量的本地MAC地址（ESP-MAC B）和VID（ESP-VID2）来分配标签。这些参数决定了本地MEP的可达性信息。也就是说，3元组[ESP-MAC A、ESP-MAC B、ESP-VID1]和[ESP-MAC B、ESP-MAC A、ESP-VID2]是从以太网标签派生的。此外，以太网OAM配置TLV中接收的信息用于配置本地MEP。
Once the Resv message successfully arrives to the initiator, this end can extract the remote side's reachability information from the Label object and therefore has all the information needed to properly configure its local MEP.
一旦Resv消息成功到达启动器，该端可以从标签对象提取远程端的可达性信息，因此具有正确配置其本地MEP所需的所有信息。
This TLV is specified in [RFC7260] and is used to select which OAM technology/method should be used for the LSP. In this document, a new OAM Type, Ethernet OAM, is defined. IANA has allocated OAM Type 1 for Ethernet OAM in the "RSVP-TE OAM Configuration Registry".
该TLV在[RFC7260]中规定，用于选择LSP应使用哪种OAM技术/方法。在本文中，定义了一种新的OAM类型，以太网OAM。IANA已在“RSVP-TE OAM配置注册表”中为以太网OAM分配了OAM类型1。
RSVP-TE OAM Configuration Registry
RSVP-TE OAM配置注册表
OAM Type Description
------------ ------------------
1 Ethernet OAM
OAM Type Description
------------ ------------------
1 Ethernet OAM
When the Ethernet OAM Type is requested, the receiving node should look for the corresponding technology-specific Ethernet OAM Configuration Sub-TLV.
当请求以太网OAM类型时，接收节点应查找相应的特定于技术的以太网OAM配置子TLV。
The Ethernet OAM Configuration Sub-TLV (depicted below) is defined for configuration parameters specific to Ethernet OAM. The Ethernet OAM Configuration Sub-TLV, when used, MUST be carried in the OAM Configuration TLV. This new sub-TLV accommodates Ethernet OAM information and carries sub-TLVs.
以太网OAM配置子TLV（如下所示）是针对特定于以太网OAM的配置参数定义的。以太网OAM配置子TLV在使用时必须在OAM配置TLV中携带。这个新的子TLV容纳以太网OAM信息并承载子TLV。
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 32 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |MD L.| Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ 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 32 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |MD L.| Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Sub-TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Indicates a new type, the Ethernet OAM Configuration Sub-TLV. IANA has assigned the value 32 from the "OAM Sub-TLVs" space in the "RSVP-TE OAM Configuration Registry".
类型：表示一种新类型，以太网OAM配置子TLV。IANA已从“RSVP-TE OAM配置注册表”中的“OAM子TLV”空间分配了值32。
Length: Indicates the total length of the TLV including padding and including the Type and Length fields.
长度：表示TLV的总长度，包括填充以及类型和长度字段。
Version: Identifies the CFM protocol version according to [IEEE.802.1Q-2011]. If a node does not support a specific CFM version, an error MUST be generated: "OAM Problem/Unsupported OAM Version".
版本：根据[IEEE.802.1Q-2011]确定CFM协议版本。如果节点不支持特定的CFM版本，则必须生成错误：“OAM问题/不支持的OAM版本”。
MD L. (MD Level): Indicates the desired MD Level. Possible values are defined according to [IEEE.802.1Q-2011]. If a node does not support a specific MD Level, an error MUST be generated: "OAM Problem/Unsupported MD Level".
MD L.（MD级别）：表示所需的MD级别。根据[IEEE.802.1Q-2011]定义可能的值。如果节点不支持特定的MD级别，则必须生成错误：“OAM问题/不支持的MD级别”。
The optional MD Name Sub-TLV is depicted below. It MAY be used for MD naming.
可选MD名称子TLV如下所示。它可以用于MD命名。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Format | Name Length | Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MD Name ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Format | Name Length | Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MD Name ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1, MD Name Sub-TLV. IANA will maintain an Ethernet TLV Type space in the "RSVP-TE OAM Configuration Registry" for the sub-TLV types carried in the Ethernet OAM Configuration Sub-TLV.
类型：1，MD名称子TLV。IANA将在“RSVP-TE OAM配置注册表”中为以太网OAM配置子TLV中携带的子TLV类型维护以太网TLV类型空间。
Length: Indicates the total length of the TLV, including padding and the Type and Length fields.
长度：表示TLV的总长度，包括填充、类型和长度字段。
Format: According to [IEEE.802.1Q-2011].
格式：根据[IEEE.802.1Q-2011]。
Name Length: The length of the MD Name field in bytes. This is necessary to allow non-4-byte padded MD Name lengths.
名称长度：MD名称字段的长度（字节）。这是允许非4字节填充MD名称长度所必需的。
MD Name: Variable-length field, formatted according to the format specified in the Format field.
MD名称：可变长度字段，根据格式字段中指定的格式进行格式化。
If an undefined Format is specified, an error MUST be generated: "OAM Problem/Unknown MD Name Format". Also, the combined length of MD Name and Short MA Name MUST be less than or equal to 44 bytes. If this is violated, an error MUST be generated: "OAM Problem/Name Length Problem". Note that it is allowed to have no MD Name; therefore, the MD Name Sub-TLV is optional. In this case, the MA Name must uniquely identify a Maintenance Association.
如果指定了未定义的格式，则必须生成错误：“OAM问题/未知MD名称格式”。此外，MD名称和短MA名称的组合长度必须小于或等于44字节。如果违反了这一点，则必须生成一个错误：“OAM问题/名称长度问题”。注意，它不允许有MD名称；因此，MD名称子TLV是可选的。在这种情况下，MA名称必须唯一标识维护关联。
The Short MA Name Sub-TLV is depicted below. This sub-TLV MUST be present in the Ethernet OAM Configuration Sub-TLV.
下面描述了短MA名称子TLV。此子TLV必须存在于以太网OAM配置子TLV中。
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 (2) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Format | Name Length | Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Short MA Name ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (2) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Format | Name Length | Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Short MA Name ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 2, Short MA Name Sub-TLV. IANA will maintain an Ethernet TLV Type space in the "RSVP-TE OAM Configuration Registry" for the sub-TLV types carried in the Ethernet OAM Configuration Sub-TLV.
类型：2，短MA名称子TLV。IANA将在“RSVP-TE OAM配置注册表”中为以太网OAM配置子TLV中携带的子TLV类型维护以太网TLV类型空间。
Length: Indicates the total length of the TLV, including padding and the Type and Length fields.
长度：表示TLV的总长度，包括填充、类型和长度字段。
Format: According to [IEEE.802.1Q-2011].
格式：根据[IEEE.802.1Q-2011]。
Name Length: The length of the Short MA Name field in bytes. This is necessary to allow non-4-byte padded MA Name lengths.
名称长度：短MA名称字段的长度（字节）。这是允许非4字节填充MA名称长度所必需的。
Short MA Name: Variable-length field formatted according to the format specified in the Format field.
短MA名称：根据格式字段中指定的格式格式化的可变长度字段。
If an undefined Format is specified, an error MUST be generated: "OAM Problem/Unknown MA Name Format". Also, the combined length of MD Name and Short MA Name MUST be less than or equal to 44 bytes. If this is violated, an error MUST be generated: "OAM Problem/Name Length Problem". Note that it is allowed to have no MD Name; in this case, the MA Name MUST uniquely identify a Maintenance Association.
如果指定了未定义的格式，则必须生成错误：“OAM问题/未知MA名称格式”。此外，MD名称和短MA名称的组合长度必须小于或等于44字节。如果违反了这一点，则必须生成一个错误：“OAM问题/名称长度问题”。注意，它不允许有MD名称；在这种情况下，MA名称必须唯一标识维护关联。
The MEP ID Sub-TLV is depicted below. This sub-TLV MUST be present in the Ethernet OAM Configuration Sub-TLV.
MEP ID子TLV如下所示。此子TLV必须存在于以太网OAM配置子TLV中。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local MEP ID |T|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote MEP ID |T|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local MEP ID |T|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote MEP ID |T|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 3, MEP ID Sub-TLV. IANA will maintain an Ethernet TLV Type space in the "RSVP-TE OAM Configuration Registry" for the sub-TLV types carried in the Ethernet OAM Configuration Sub-TLV.
类型：3，MEP ID子TLV。IANA将在“RSVP-TE OAM配置注册表”中为以太网OAM配置子TLV中携带的子TLV类型维护以太网TLV类型空间。
Length: Indicates the total length of the TLV, including padding and the Type and Length fields.
长度：表示TLV的总长度，包括填充、类型和长度字段。
Local MEP ID: A 16-bit integer value in the range 1-8191 of the MEP ID on the initiator side.
本地MEP ID：启动器端MEP ID范围1-8191内的16位整数值。
Remote MEP ID: A 16-bit integer value in the range 1-8191 of the MEP ID to be set for the MEP established at the receiving side. This value is determined by the initiator node. This is possible since a new MAID is assigned to each PBB-TE connection, and MEP IDs must be only unique within the scope of the MAID.
远程MEP ID：为在接收端建立的MEP设置的MEP ID范围1-8191内的16位整数值。此值由启动器节点确定。这是可能的，因为为每个PBB-TE连接分配了一个新的MAID，并且MEP ID必须仅在MAID范围内唯一。
Two flags are defined: Transmit (T) and Receive (R). When T is set, the corresponding MEP MUST send OAM packets. When R is set, the corresponding MEP MUST expect to receive OAM packets. These flags are used to configure the role of MEPs.
定义了两个标志：发送（T）和接收（R）。当设置T时，相应的MEP必须发送OAM数据包。当设置R时，相应的MEP必须期望接收OAM分组。这些标志用于配置MEP的角色。
The Continuity Check (CC) Sub-TLV is depicted below. This sub-TLV MUST be present in the Ethernet OAM Configuration Sub-TLV.
连续性检查（CC）子TLV如下所示。此子TLV必须存在于以太网OAM配置子TLV中。
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 (4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prio | CCM I | Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prio | CCM I | Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 4, Continuity Check (CC) Sub-TLV. IANA will maintain an Ethernet TLV Type space in the "RSVP-TE OAM Configuration Registry" for the sub-TLV types carried in the Ethernet OAM Configuration Sub-TLV.
类型：4，连续性检查（CC）子TLV。IANA将在“RSVP-TE OAM配置注册表”中为以太网OAM配置子TLV中携带的子TLV类型维护以太网TLV类型空间。
Length: Indicates the total length of the TLV, including padding and the Type and Length fields.
长度：表示TLV的总长度，包括填充、类型和长度字段。
Prio: Indicates the priority to be set for CCM frames. In Ethernet, 3 bits carried in VLAN TAGs identify priority information. Setting the priority is optional. If the most significant bit is set to zero, the subsequent 3 priority bits will be ignored, and priority bits of the Ethernet CCM frame will be set based on default values specified in the Ethernet nodes. If the most significant bit is set to 1, the subsequent 3 bits will be used to set the priority bits of the Ethernet CCM frame.
Prio：表示要为CCM帧设置的优先级。在以太网中，VLAN标记中携带的3位标识优先级信息。设置优先级是可选的。如果最高有效位设置为零，则随后的3个优先级位将被忽略，以太网CCM帧的优先级位将基于以太网节点中指定的默认值进行设置。如果最高有效位设置为1，则随后的3位将用于设置以太网CCM帧的优先级位。
CCM I (CCM Interval): MUST be set according to the 3-bit encoding [IEEE.802.1Q-2011] shown in Table 1. As a consequence, the most significant bit will be set to 0. Four bits are allocated to support the configuration of CCM Intervals that may be specified in the future. If a node does not support the requested CCM Interval, an error MUST be generated: "OAM Problem/Unsupported CC Interval".
CCM I（CCM间隔）：必须根据表1所示的3位编码[IEEE.802.1Q-2011]进行设置。因此，最高有效位将设置为0。分配四位以支持将来可能指定的CCM间隔的配置。如果节点不支持请求的CCM间隔，则必须生成错误：“OAM问题/不支持的CC间隔”。
Ethernet OAM functions for Performance Monitoring (PM) allow measurements of different performance parameters including Frame Loss Ratio, Frame Delay, and Frame Delay Variation as defined in [ITU-T.G.8013-2013]. Only a subset of PM functions are operated in a proactive fashion to monitor the performance of the connection continuously. Proactive PM supports Fault Management functions by providing an indication of decreased service performance and therefore may provide triggers to initiate recovery procedures.
用于性能监控（PM）的以太网OAM功能允许测量不同的性能参数，包括[ITU-T.G.8013-2013]中定义的帧丢失率、帧延迟和帧延迟变化。只有一部分PM功能以主动方式运行，以持续监控连接的性能。主动预防性维护通过提供服务性能下降的指示来支持故障管理功能，因此可以提供启动恢复程序的触发器。
While on-demand PM functions are, for the purposes of this document, always initiated by management commands, for proactive PM, it may be desirable to utilize the control plane for configuration and activation together with Fault Management functions such as the Continuity Check.
尽管就本文件而言，按需PM功能始终由管理命令启动，用于主动PM，但可能需要利用控制平面进行配置和激活，以及故障管理功能，如连续性检查。
[ITU-T.G.8013-2013] defines dual-ended Loss Measurement as proactive OAM for Performance Monitoring and as a PM function applicable to Fault Management. For dual-ended Loss Measurement, each MEP piggybacks transmitted and received frame counters on CC messages to support and synchronize bidirectional Loss Measurements at the MEPs. Dual-ended Loss Measurement is supported by setting the Performance Monitoring/Loss OAM Function Flag and the Continuity Check Flag in the OAM Function Flags Sub-TLV [RFC7260] and configuring the Continuity Check functionality by including the Ethernet OAM Configuration Sub-TLV. No additional configuration is required for this type of Loss Measurement.
[ITU-T.G.8013-2013]将双端损耗测量定义为用于性能监控的主动式OAM和适用于故障管理的PM功能。对于双端损耗测量，每个MEP搭载CC消息上发送和接收的帧计数器，以支持和同步MEP上的双向损耗测量。通过在OAM功能标志子TLV[RFC7260]中设置性能监控/丢失OAM功能标志和连续性检查标志，并通过包括以太网OAM配置子TLV配置连续性检查功能，支持双端损耗测量。这种类型的损耗测量不需要额外的配置。
In addition to the error values specified in [RFC7260], this document defines the following values for the "OAM Problem" Error Code.
除了[RFC7260]中指定的错误值外，本文档还为“OAM问题”错误代码定义了以下值。
o If a node does not support a specific CFM version, an error MUST be generated: "OAM Problem/Unsupported OAM Version".
o 如果节点不支持特定的CFM版本，则必须生成错误：“OAM问题/不支持的OAM版本”。
o If a node does not support a specific MD Level, an error MUST be generated: "OAM Problem/Unsupported MD Level".
o 如果节点不支持特定的MD级别，则必须生成错误：“OAM问题/不支持的MD级别”。
o If an undefined MD name format is specified, an error MUST be generated: "OAM Problem/Unknown MD Name Format".
o 如果指定了未定义的MD名称格式，则必须生成错误：“OAM问题/未知MD名称格式”。
o If an undefined MA name format is specified, an error MUST be generated: "OAM Problem/Unknown MA Name Format".
o 如果指定了未定义的MA名称格式，则必须生成错误：“OAM问题/未知MA名称格式”。
o The combined length of MD Name and Short MA Name must be less than or equal to 44 bytes. If this is violated, an error MUST be generated: "OAM Problem/Name Length Problem".
o MD名称和短MA名称的组合长度必须小于或等于44字节。如果违反了这一点，则必须生成一个错误：“OAM问题/名称长度问题”。
o If a node does not support the requested CCM Interval, an error MUST be generated: "OAM Problem/Unsupported CC Interval".
o 如果节点不支持请求的CCM间隔，则必须生成错误：“OAM问题/不支持的CC间隔”。
IANA maintains the "RSVP-TE OAM Configuration Registry". IANA has assigned an "OAM Type" from this registry as follows:
IANA维护“RSVP-TE OAM配置注册表”。IANA已从此注册表中分配“OAM类型”，如下所示：
o "Ethernet OAM" has been allocated type 1 from the "OAM Types" sub-registry of the "RSVP-TE OAM Configuration Registry".
o 已从“RSVP-TE OAM配置注册表”的“OAM类型”子注册表中为“以太网OAM”分配了类型1。
o "Ethernet OAM Configuration Sub-TLV" has been allocated type 32 from the technology-specific range of the "OAM Sub-TLVs" sub-registry of the "RSVP-TE OAM Configuration Registry".
o “以太网OAM配置子TLV”已从“RSVP-TE OAM配置注册表”的“OAM子TLV”子注册表的技术特定范围中分配类型32。
RSVP-TE OAM Configuration Registry
RSVP-TE OAM配置注册表
OAM Types
OAM类型
OAM Type Number | Description | Reference
-------------------------------------------
1 | Ethernet OAM | [RFC7369]
OAM Type Number | Description | Reference
-------------------------------------------
1 | Ethernet OAM | [RFC7369]
OAM Sub-TLVs
OAM子TLV
Sub-TLV Type | Description | Ref.
-----------------------------------------------------------
32 |Ethernet OAM Configuration Sub-TLV| [RFC7369]
Sub-TLV Type | Description | Ref.
-----------------------------------------------------------
32 |Ethernet OAM Configuration Sub-TLV| [RFC7369]
IANA will maintain an "Ethernet Sub-TLVs Sub-Registry" in the "RSVP-TE OAM Configuration Registry" for the sub-TLV types carried in the Ethernet OAM Configuration Sub-TLV. This document defines the following types.
IANA将在“RSVP-TE OAM配置注册表”中为以太网OAM配置子TLV中携带的子TLV类型维护一个“以太网子TLV子注册表”。本文档定义了以下类型。
Ethernet Sub-TLVs Sub-Registry
以太网子TLVs子注册表
Range | Registration Procedures
------------+--------------------------
0-65534 | IETF Review
65535 | Experimental
Range | Registration Procedures
------------+--------------------------
0-65534 | IETF Review
65535 | Experimental
Sub-TLV Type | Description | Ref.
---------------------------------------------------------
0 | Reserved | [RFC7369]
1 | MD Name Sub-TLV | [RFC7369]
2 | Short MA Name Sub-TLV | [RFC7369]
3 | MEP ID Sub-TLV | [RFC7369]
4 | Continuity Check Sub-TLV | [RFC7369]
5-65534 | Unassigned | [RFC7369]
65535 | Reserved for Experimental Use | [RFC7369]
Sub-TLV Type | Description | Ref.
---------------------------------------------------------
0 | Reserved | [RFC7369]
1 | MD Name Sub-TLV | [RFC7369]
2 | Short MA Name Sub-TLV | [RFC7369]
3 | MEP ID Sub-TLV | [RFC7369]
4 | Continuity Check Sub-TLV | [RFC7369]
5-65534 | Unassigned | [RFC7369]
65535 | Reserved for Experimental Use | [RFC7369]
IANA maintains an Error Code, "OAM Problem", in the "Error Codes and Globally-Defined Error Value Sub-Codes" sub-registry of the "Resource Reservation Protocol (RSVP) Parameters" registry. [RFC7260] defines a set of Error Value sub-codes for the "OAM Problem" Error Code. This document defines additional Error Value sub-codes for the "OAM Problem" Error Code as summarized below.
IANA在“资源预留协议（RSVP）参数”注册表的“错误代码和全局定义的错误值子代码”子注册表中维护一个错误代码“OAM问题”。[RFC7260]为“OAM问题”错误代码定义一组错误值子代码。本文档定义了“OAM问题”错误代码的附加错误值子代码，总结如下。
Value | Description | Reference
-------+---------------------------+-----------
7 | Unsupported OAM Version | [RFC7369]
8 | Unsupported MD Level | [RFC7369]
9 | Unknown MD Name Format | [RFC7369]
10 | Unknown MA Name Format | [RFC7369]
11 | Name Length Problem | [RFC7369]
12 | Unsupported CC Interval | [RFC7369]
Value | Description | Reference
-------+---------------------------+-----------
7 | Unsupported OAM Version | [RFC7369]
8 | Unsupported MD Level | [RFC7369]
9 | Unknown MD Name Format | [RFC7369]
10 | Unknown MA Name Format | [RFC7369]
11 | Name Length Problem | [RFC7369]
12 | Unsupported CC Interval | [RFC7369]
This document does not introduce any additional security issues to those discussed in [RFC7260] and [RFC6060].
本文件不涉及[RFC7260]和[RFC6060]中讨论的任何其他安全问题。
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 "Security Framework for MPLS and GMPLS Networks" [RFC5920].
有关GMPLS安全和攻击缓解技术的更全面讨论，请参阅“MPLS和GMPLS网络的安全框架”[RFC5920]。
[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年。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[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, <http://www.rfc-editor.org/info/rfc6060>.
[RFC6060]Fedyk，D.，Shah，H.，Bitar，N.，和A.Takacs，“以太网提供商主干流量工程（PBB-TE）的通用多协议标签交换（GMPLS）控制”，RFC 6060，2011年3月<http://www.rfc-editor.org/info/rfc6060>.
[RFC7260] Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration", RFC 7260, June 2014, <http://www.rfc-editor.org/info/rfc7260>.
[RFC7260]Takacs，A.，Fedyk，D.，和J.He，“用于运行、管理和维护（OAM）配置的GMPLS RSVP-TE扩展”，RFC 72602014年6月<http://www.rfc-editor.org/info/rfc7260>.
[ITU-T.G.8013-2013] International Telecommunications Union, "OAM functions and mechanisms for Ethernet based networks", ITU-T Recommendation G.8013/Y.1731, November 2011.
[ITU-T.G.8013-2013]国际电信联盟，“基于以太网的网络的OAM功能和机制”，ITU-T建议G.8013/Y.17311911年11月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000, <http://www.rfc-editor.org/info/rfc2747>.
[RFC2747]Baker，F.，Lindell，B.和M.Talwar，“RSVP加密认证”，RFC 2747，2000年1月<http://www.rfc-editor.org/info/rfc2747>.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003, <http://www.rfc-editor.org/info/rfc3473>.
[RFC3473]Berger，L.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月<http://www.rfc-editor.org/info/rfc3473>.
[RFC5828] Fedyk, D., Berger, L., and L. Andersson, "Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework", RFC 5828, March 2010, <http://www.rfc-editor.org/info/rfc5828>.
[RFC5828]Fedyk，D.，Berger，L.，和L.Andersson，“通用多协议标签交换（GMPLS）以太网标签交换体系结构和框架”，RFC 58282010年3月<http://www.rfc-editor.org/info/rfc5828>.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010, <http://www.rfc-editor.org/info/rfc5920>.
[RFC5920]方，L，“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月<http://www.rfc-editor.org/info/rfc5920>.
Acknowledgements
致谢
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的有用评论。
Contributors
贡献者
Don Fedyk EMail: don.fedyk@hp.com
唐·费迪克：唐。fedyk@hp.com
Dinesh Mohan EMail: dinmohan@hotmail.com
Dinesh Mohan电子邮件：dinmohan@hotmail.com
Authors' Addresses
作者地址
Attila Takacs Ericsson Konyves Kalman krt. 11. Budapest 1097 Hungary
阿提拉·塔卡什·爱立信·柯尼夫·卡尔曼·克尔特。11布达佩斯1097匈牙利
EMail: attila.takacs@ericsson.com
EMail: attila.takacs@ericsson.com
Balazs Peter Gero Ericsson Konyves Kalman krt. 11. Budapest 1097 Hungary
巴拉兹·彼得·杰罗·爱立信·科尼维斯·卡尔曼·科特。11布达佩斯1097匈牙利
EMail: balazs.peter.gero@ericsson.com
EMail: balazs.peter.gero@ericsson.com
Hao Long Huawei China
郝龙华为中国有限公司
EMail: lonho@huawei.com
EMail: lonho@huawei.com