Network Working Group M. Bocci, Ed.
Request for Comments: 5586 M. Vigoureux, Ed.
Updates: 3032, 4385, 5085 Alcatel-Lucent
Category: Standards Track S. Bryant, Ed.
Cisco Systems
June 2009
Network Working Group M. Bocci, Ed.
Request for Comments: 5586 M. Vigoureux, Ed.
Updates: 3032, 4385, 5085 Alcatel-Lucent
Category: Standards Track S. Bryant, Ed.
Cisco Systems
June 2009
MPLS Generic Associated Channel
通用关联信道
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
This document generalizes the applicability of the pseudowire (PW) Associated Channel Header (ACH), enabling the realization of a control channel associated to MPLS Label Switched Paths (LSPs) and MPLS Sections in addition to MPLS pseudowires. In order to identify the presence of this Associated Channel Header in the label stack, this document also assigns one of the reserved MPLS label values to the Generic Associated Channel Label (GAL), to be used as a label based exception mechanism.
本文件概括了伪线（PW）相关信道报头（ACH）的适用性，使得除了MPLS伪线之外，还能够实现与MPLS标签交换路径（LSP）和MPLS部分相关的控制信道。为了识别标签堆栈中是否存在此关联的通道头，本文档还将保留的MPLS标签值之一分配给通用关联通道标签（GAL），以用作基于标签的异常机制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements Language and Terminology . . . . . . . . . . 5
2. Generic Associated Channel Header . . . . . . . . . . . . . . 5
2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Allocation of Channel Types . . . . . . . . . . . . . . . 6
3. ACH TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. ACH TLV Payload Structure . . . . . . . . . . . . . . . . 7
3.2. ACH TLV Header . . . . . . . . . . . . . . . . . . . . . . 8
3.3. ACH TLV Object . . . . . . . . . . . . . . . . . . . . . . 8
4. Generalized Exception Mechanism . . . . . . . . . . . . . . . 9
4.1. Relationship with Existing MPLS OAM Alert Mechanisms . . . 9
4.2. GAL Applicability and Usage . . . . . . . . . . . . . . . 10
4.2.1. GAL Processing . . . . . . . . . . . . . . . . . . . . 10
4.3. Relationship with RFC 3429 . . . . . . . . . . . . . . . . 13
5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Congestion Considerations . . . . . . . . . . . . . . . . . . 15
7. Major Contributing Authors . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements Language and Terminology . . . . . . . . . . 5
2. Generic Associated Channel Header . . . . . . . . . . . . . . 5
2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Allocation of Channel Types . . . . . . . . . . . . . . . 6
3. ACH TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. ACH TLV Payload Structure . . . . . . . . . . . . . . . . 7
3.2. ACH TLV Header . . . . . . . . . . . . . . . . . . . . . . 8
3.3. ACH TLV Object . . . . . . . . . . . . . . . . . . . . . . 8
4. Generalized Exception Mechanism . . . . . . . . . . . . . . . 9
4.1. Relationship with Existing MPLS OAM Alert Mechanisms . . . 9
4.2. GAL Applicability and Usage . . . . . . . . . . . . . . . 10
4.2.1. GAL Processing . . . . . . . . . . . . . . . . . . . . 10
4.3. Relationship with RFC 3429 . . . . . . . . . . . . . . . . 13
5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Congestion Considerations . . . . . . . . . . . . . . . . . . 15
7. Major Contributing Authors . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 18
There is a need for Operations, Administration, and Maintenance (OAM) mechanisms that can be used for fault detection, diagnostics, maintenance, and other functions on a pseudowire (PW) and a Label Switched Path (LSP). These functions can be used between any two Label Edge Routers (LERs)/Label Switching Router (LSRs) or Terminating Provider Edge routers (T-PEs)/Switching Provider Edge routers (S-PEs) along the path of an LSP or PW, respectively [MPLS-TP]. Some of these functions can be supported using existing tools such as Virtual Circuit Connectivity Verification (VCCV) [RFC5085], Bidirectional Forwarding Detection for MPLS LSPs (BFD-MPLS) [BFD-MPLS], LSP-Ping [RFC4379], or BFD-VCCV [BFD-VCCV]. However, a requirement has been indicated to augment this set of maintenance functions, in particular when MPLS networks are used for packet transport services and transport network operations [OAM-REQ]. Examples of these functions include performance monitoring, automatic protection switching, and support for management and signaling communication channels. These tools MUST be applicable to, and function in essentially the same manner (from an operational point of view) on MPLS PWs, MPLS LSPs, and MPLS Sections. They MUST also operate in-band on the PW or LSP such that they do not depend on Packet Switched Network (PSN) routing or on user traffic, and MUST NOT depend on dynamic control plane functions.
需要操作、管理和维护（OAM）机制，这些机制可用于伪线（PW）和标签交换路径（LSP）上的故障检测、诊断、维护和其他功能。这些功能可分别在沿着LSP或PW路径的任意两个标签边缘路由器（LER）/标签交换路由器（LSR）或终端提供商边缘路由器（T-PE）/交换提供商边缘路由器（S-PE）之间使用[MPLS-TP]。可以使用现有工具支持其中一些功能，如虚拟电路连接验证（VCCV）[RFC5085]、MPLS LSP的双向转发检测（BFD-MPLS）[BFD-MPLS]、LSP Ping[RFC4379]或BFD-VCCV[BFD-VCCV]。然而，已经指出了增强这组维护功能的要求，特别是当MPLS网络用于分组传输服务和传输网络操作[OAM-REQ]时。这些功能的示例包括性能监控、自动保护切换以及对管理和信令通信信道的支持。这些工具必须适用于MPLS PWs、MPLS LSP和MPLS部分，并以基本相同的方式（从操作角度）运行。它们还必须在PW或LSP上的频带内运行，以便它们不依赖于分组交换网络（PSN）路由或用户流量，并且不依赖于动态控制平面功能。
VCCV [RFC5085] can use an Associated Channel Header (ACH) to provide a PW associated control channel between a PW's endpoints, over which OAM and other control messages can be exchanged. This document generalizes the applicability of the ACH to enable the same associated control channel mechanism to be used for Sections, LSPs, and PWs. The associated control channel thus generalized is known as the Generic Associated Channel (G-ACh). The ACH, specified in RFC 4385 [RFC4385], may be used with additional code points to support additional MPLS maintenance functions on the G-ACh.
VCCV[RFC5085]可以使用关联的通道头（ACH）在PW的端点之间提供PW关联的控制通道，通过该通道可以交换OAM和其他控制消息。本文件概括了ACH的适用性，以使相同的相关控制通道机制能够用于区段、LSP和PWs。由此广义化的相关控制信道称为通用相关信道（G-ACh）。RFC 4385[RFC4385]中规定的ACH可与其他代码点一起使用，以支持G-ACH上的其他MPLS维护功能。
Generalizing the applicability of the ACH to LSPs and Sections also requires a method to identify that a packet contains an ACH followed by a non-service payload. Therefore, this document also defines a label-based exception mechanism that serves to inform an LSR (or LER) that a packet it receives on an LSP or Section belongs to an associated control channel. The label used for that purpose is one of the MPLS reserved labels and is referred to as the GAL (G-ACh Label). The GAL mechanism is defined to work together with the ACH for LSPs and MPLS Sections.
要将ACH的适用性推广到LSP和部分，还需要一种方法来识别一个数据包包含ACH，后跟一个非服务负载。因此，本文档还定义了一种基于标签的异常机制，用于通知LSR（或LER）它在LSP或部分上接收的分组属于相关联的控制信道。用于该目的的标签是MPLS保留标签之一，称为GAL（G-ACh标签）。GAL机制被定义为与LSP和MPLS部分的ACH一起工作。
RFC 4379 [RFC4379] and BFD-MPLS [BFD-MPLS] define alert mechanisms that enable an MPLS LSR to identify and process MPLS OAM packets when these are encapsulated in an IP header. These alert mechanisms are
RFC 4379[RFC4379]和BFD-MPLS[BFD-MPLS]定义了警报机制，使MPLS LSR能够识别和处理封装在IP报头中的MPLS OAM数据包。这些警报机制是
based, for example, on Time To Live (TTL) expiration and/or on the use of an IP destination address in the range of 127.0.0.0/8 or 0:0: 0:0:0:FFFF:127.0.0.0/104 for IPv4 and IPv6, respectively. These mechanisms are the default mechanisms for identifying MPLS OAM packets when encapsulated in an IP header. However, it may not always be possible to use these mechanisms in some MPLS applications, e.g., MPLS Transport Profile (MPLS-TP) [MPLS-TP], particularly when IP-based demultiplexing cannot be used. This document defines a mechanism that is RECOMMENDED for identifying and encapsulating MPLS OAM and other maintenance messages when IP based mechanisms such as those used in [RFC4379] and [BFD-MPLS] are not available. Yet, this mechanism MAY be used in addition to IP-based mechanisms.
例如，基于生存时间（TTL）到期和/或分别针对IPv4和IPv6使用127.0.0.0/8或0:0:0:0:0:FFFF:127.0.0.0/104范围内的IP目标地址。当封装在IP报头中时，这些机制是识别MPLS OAM数据包的默认机制。然而，在一些MPLS应用中，例如MPLS传输配置文件（MPLS-TP）[MPLS-TP]，可能并不总是能够使用这些机制，尤其是在无法使用基于IP的解复用时。当[RFC4379]和[BFD-MPLS]中使用的基于IP的机制不可用时，本文档定义了一种建议用于识别和封装MPLS OAM和其他维护消息的机制。然而，除了基于IP的机制之外，还可以使用该机制。
Note that, in this document, maintenance functions and packets should be understood in the broad sense. That is, a set of maintenance and management mechanisms that include OAM, Automatic Protection Switching (APS), Signaling Communication Channel (SCC), and Management Communication Channel (MCC) messages.
注意，在本文件中，维护功能和数据包应理解为广义的。即，一组维护和管理机制，包括OAM、自动保护切换（APS）、信令通信信道（SCC）和管理通信信道（MCC）消息。
Also note that the GAL and ACH are applicable to MPLS and PWs in general. This document specifies general mechanism and uses MPLS-TP as an example application. The application of the GAL and ACH to other specific MPLS uses is outside the scope of this document.
还要注意，GAL和ACH通常适用于MPLS和PWs。本文档指定了一般机制，并使用MPLS-TP作为示例应用程序。GAL和ACH在其他特定MPLS使用中的应用超出了本文档的范围。
This document defines a mechanism that provides a solution to the extended maintenance needs of emerging applications for MPLS. It creates a generic control channel mechanism that may be applied to MPLS LSPs and Sections, while maintaining compatibility with the PW associated channel. It also normalizes the use of the ACH for PWs in a transport context, and defines a label-based exception mechanism to alert LERs/LSRs of the presence of an ACH after the bottom of the label stack.
本文档定义了一种机制，为MPLS新兴应用程序的扩展维护需求提供了解决方案。它创建了一种通用控制信道机制，可应用于MPLS LSP和段，同时保持与PW相关信道的兼容性。它还规范了在传输上下文中为PWs使用ACH，并定义了基于标签的异常机制，以在标签堆栈底部之后向LER/LSR发出ACH存在的警报。
This document defines the encapsulation header for Section, LSP, and PW associated control channel messages.
本文档定义了节、LSP和PW相关控制通道消息的封装头。
This document does not define how associated control channel capabilities are signaled or negotiated between LERs/LSRs or between PEs, nor does it define the operation of various OAM functions.
本文件未定义LER/LSR之间或PEs之间的相关控制信道能力的信号发送或协商方式，也未定义各种OAM功能的操作。
This document does not deprecate existing MPLS and PW OAM mechanisms.
本文档不反对现有的MPLS和PW 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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This document uses the following additional terminology:
本文件使用以下附加术语：
ACH: Associated Channel Header
ACH：关联通道头
G-ACh: Generic Associated Channel
G-ACh：通用关联信道
GAL: G-ACh Label
GAL:G-ACh标签
G-ACh packet: Any packet containing a message belonging to a protocol that is carried on a PW, LSP, or MPLS Section associated control channel. Examples include maintenance protocols such as OAM functions, signaling communications, or management communications.
G-ACh数据包：包含属于PW、LSP或MPLS段相关控制信道上承载的协议的消息的任何数据包。示例包括维护协议，例如OAM功能、信令通信或管理通信。
The terms "Section" and "Concatenated Segment" are defined in [TP-REQ] as follows (note that the terms "Section" and "Section Layer Network" are synonymous):
术语“区段”和“连接段”在[TP-REQ]中定义如下（注意术语“区段”和“区段层网络”同义）：
Section Layer Network: A section layer is a server layer (which may be MPLS-TP or a different technology) that provides for the transfer of the section layer client information between adjacent nodes in the transport path layer or transport service layer. Note that G.805 [G805] defines the section layer as one of the two layer networks in a transmission media layer network. The other layer network is the physical media layer network.
节层网络：节层是服务器层（可能是MPLS-TP或其他技术），用于在传输路径层或传输服务层的相邻节点之间传输节层客户端信息。注意，G.805[G805]将部分层定义为传输媒体层网络中的两层网络之一。另一层网络是物理媒体层网络。
Concatenated Segment: A serial-compound link connection as defined in [G805]. A concatenated segment is a contiguous part of an LSP or multi-segment PW that comprises a set of segments and their interconnecting nodes in sequence.
串联段：如[G805]中所定义的串行复合链路连接。连接段是LSP或多段PW的一个连续部分，由一组段及其顺序互连节点组成。
VCCV [RFC5085] defines three Control Channel (CC) Types that may be used to exchange OAM messages through a PW. CC Type 1 uses an ACH and is referred to as "In-band VCCV"; CC Type 2 uses the MPLS Router Alert Label to indicate VCCV packets and is referred to as "Out-of-Band VCCV"; CC Type 3 uses the TTL to force the packet to be processed by the targeted router control plane and is referred to as "MPLS PW Label with TTL == 1".
VCCV[RFC5085]定义了三种控制通道（CC）类型，可用于通过PW交换OAM消息。CC类型1使用ACH，称为“带内VCCV”；CC类型2使用MPLS路由器警报标签指示VCCV数据包，称为“带外VCCV”；CC类型3使用TTL强制目标路由器控制平面处理数据包，称为“TTL==1的MPLS PW标签”。
The use of the ACH, previously limited to PWs, is here generalized to also apply to LSPs and to Sections. Note that for PWs, the PWE3 control word [RFC4385] MUST be present in the encapsulation of user packets when the ACH is used to realize the associated control channel.
之前仅限于PWs的ACH的使用在这里被推广应用于LSP和截面。注意，对于PWs，当ACH用于实现相关联的控制信道时，PWE3控制字[RFC4385]必须存在于用户分组的封装中。
The ACH used by CC Type 1 is depicted in figure below:
CC类型1使用的ACH如下图所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Associated Channel Header
图1：关联的通道头
In the above figure, the first nibble is set to 0001b to indicate a control channel associated with a PW, LSP, or Section. The Version field is set to 0, as specified in RFC 4385 [RFC4385]. Bits 8 to 15 of the ACH are reserved and MUST be set to 0 and ignored on reception. Bits 16 to 31 are used to encode the possible Channel Types. This 16-bit field is in network byte order.
在上图中，第一个半字节设置为0001b，以指示与PW、LSP或区段相关联的控制信道。版本字段设置为0，如RFC 4385[RFC4385]中所述。ACH的位8到15是保留的，必须设置为0，并在接收时忽略。位16至31用于编码可能的信道类型。此16位字段按网络字节顺序排列。
Note that VCCV [RFC5085] also includes mechanisms for negotiating the Control Channel and Connectivity Verification (i.e., OAM function) Types between PEs. It is anticipated that similar mechanisms will be applied to LSPs. Such application will require further specification. However, such specification is beyond the scope of this document.
注意，VCCV[RFC5085]还包括用于在PEs之间协商控制通道和连接验证（即OAM功能）类型的机制。预计类似机制将应用于LSP。此类应用需要进一步规范。然而，此类规范超出了本文件的范围。
The G-ACh MUST NOT be used to transport user traffic.
G-ACh不得用于传输用户流量。
The Channel Type field indicates the type of message carried on the associated control channel, e.g., IPv4 or IPv6 if IP demultiplexing is used for messages sent on the associated control channel, or OAM or other maintenance function if IP demultiplexing is not used. For associated control channel packets where IP is not used as the multiplexer, the Channel Type indicates the specific protocol carried in the associated control channel.
Channel Type（通道类型）字段指示相关控制通道上承载的消息类型，例如，如果IP解复用用于在相关控制通道上发送的消息，则为IPv4或IPv6；如果未使用IP解复用，则为OAM或其他维护功能。对于IP未用作多路复用器的关联控制信道分组，信道类型指示关联控制信道中承载的特定协议。
Values for the Channel Type field currently used for VCCV are specified elsewhere, e.g., in RFC 4446 [RFC4446] and RFC 4385 [RFC4385]. Additional Channel Type values and the associated
当前用于VCCV的信道类型字段的值在其他地方指定，例如RFC 4446[RFC4446]和RFC 4385[RFC4385]中。其他通道类型值和关联的
maintenance functionality will be defined in other documents. Each document, specifying a protocol solution relying on the ACH, MUST also specify the applicable Channel Type field value.
维护功能将在其他文件中定义。每个文档（指定依赖于ACH的协议解决方案）还必须指定适用的通道类型字段值。
Note that these values are allocated from the PW Associated Channel Type registry [RFC4446], but this document modifies the existing policy to accommodate a level of experimentation. See Section 10 for further details.
请注意，这些值是从PW关联通道类型注册表[RFC4446]分配的，但本文档修改了现有策略以适应一定程度的试验。详见第10节。
In some applications of the generalized associated control channel, it is necessary to include one or more ACH TLVs to provide additional context information to the G-ACh packet. One use of these ACH TLVs might be to identify the source and/or intended destination of the associated channel message. However, the use of this construct is not limited to providing addressing information nor is the applicability restricted to transport network applications.
在广义关联控制信道的一些应用中，有必要包括一个或多个ACH tlv以向G-ACH分组提供额外的上下文信息。这些ACH TLV的一个用途可能是识别相关信道消息的源和/或预期目的地。然而，这种结构的使用不仅限于提供寻址信息，其适用性也不限于传输网络应用。
If the G-ACh message MAY be preceded by one or more ACH TLVs, then this MUST be explicitly specified in the definition of an ACH Channel Type. If the ACH Channel Type definition does state that one or more ACH TLVs MAY precede the G-ACh message, an ACH TLV Header MUST follow the ACH. If no ACH TLVs are required in a specific associated channel packet, but the Channel Type nevertheless defines that ACH TLVs MAY be used, an ACH TLV Header MUST be present but with a length field set to zero to indicate that no ACH TLV follow this header.
如果G-ACh消息前面可能有一个或多个ACh TLV，则必须在ACh通道类型的定义中明确指定。如果ACH通道类型定义确实说明一个或多个ACH TLV可能位于G-ACH消息之前，则ACH TLV头必须位于ACH之后。如果特定关联信道分组中不需要ACH TLV，但信道类型仍定义可以使用ACH TLV，则必须存在ACH TLV报头，但长度字段设置为零，以指示此报头后面没有ACH TLV。
If an ACH Channel Type specification does not explicitly specify that ACH TLVs MAY be used, then the ACH TLV Header MUST NOT be used.
如果ACH通道类型规范未明确指定可以使用ACH TLV，则不得使用ACH TLV标头。
This section defines and describes the structure of an ACH payload when an ACH TLV Header is present.
本节定义并描述存在ACH TLV报头时ACH有效负载的结构。
The following figure (Figure 2) shows the structure of a G-ACh packet payload.
下图（图2）显示了G-ACh数据包有效负载的结构。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLV Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ zero or more ACH TLVs ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ G-ACh Message ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLV Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ zero or more ACH TLVs ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ G-ACh Message ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: G-ACh Packet Payload
图2:G-ACh数据包有效负载
The ACH TLV Header defines the length of the set of ACH TLVs that follow.
ACH TLV头定义后面的ACH 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ACH TLV Header
图3:ACH TLV头
The Length field specifies the length in octets of the complete set of TLVs including sub-TLVs that follow the ACH TLV Header. A length of zero indicates that no ACH TLV follow this header. Note that no padding is required for the set of ACH TLVs.
长度字段指定完整TLV集的长度（以八位字节为单位），包括ACH TLV标头后面的子TLV。长度为零表示此标头后面没有ACH TLV。请注意，ACH TLV集不需要填充。
The Reserved field is for future use and MUST be set to zero on transmission and ignored on reception.
保留字段供将来使用，传输时必须设置为零，接收时忽略。
ACH TLVs MAY follow an ACH TLV Header. The structure of ACH TLVs is defined and described in this section.
ACH TLV可跟随ACH TLV标头。本节定义并描述了ACH TLV的结构。
An ACH TLV consists of a 16-bit Type field, followed by a 16-bit Length field that specifies the number of octets of the Value field, which follows the Length field. This 32-bit word is followed by zero or more octets of Value information. The format and semantics of the Value information are defined by the TLV Type as recorded in the TLV
ACH TLV由一个16位类型字段和一个16位长度字段组成，该字段指定值字段的八位字节数，值字段位于长度字段之后。这个32位字后面跟有零个或多个八位字节的值信息。值信息的格式和语义由TLV中记录的TLV类型定义
Type registry. See Section 10 for further details. Note that the Value field of ACH TLVs MAY contain sub-TLVs. Note that no padding is required for individual TLVs or sub-TLVs.
输入注册表。详见第10节。请注意，每个TLV的值字段可能包含子TLV。请注意，单个TLV或子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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ Value ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ Value ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: ACH TLV Format
图4:ACH TLV格式
Generalizing the associated control channel mechanism to LSPs and Sections also requires a method to identify that a packet contains an ACH followed by a non-service payload. This document specifies that a label is used for that purpose and calls this special label the G-ACh Label (GAL). One of the reserved label values defined in RFC 3032 [RFC3032] is assigned for this purpose. IANA assigned the value 13 to the GAL.
将相关联的控制信道机制推广到lsp和部分还需要一种方法来识别一个分组包含一个ACH，后跟一个非服务负载。本文件规定标签用于此目的，并将此特殊标签称为G-ACh标签（GAL）。为此，在RFC 3032[RFC3032]中定义的一个保留标签值被分配。IANA将值13分配给GAL。
The GAL provides an alert based exception mechanism to:
GAL提供了基于警报的异常机制，用于：
o differentiate specific packets (i.e., G-ACh packets) from others, such as user-plane ones.
o 将特定数据包（即G-ACh数据包）与其他数据包（如用户平面数据包）区分开来。
o indicate that the ACH appears immediately after the bottom of the label stack.
o 指示ACH立即出现在标签堆栈底部之后。
The GAL MUST only be used where both these purposes apply.
GAL只能在上述两个目的都适用的情况下使用。
RFC 4379 [RFC4379] and BFD-MPLS [BFD-MPLS] define alert mechanisms that enable an MPLS LSR to identify and process MPLS OAM packets when these are encapsulated in an IP header. These alert mechanisms are based, for example, on Time To Live (TTL) expiration and/or on the use of an IP destination address in the range of 127.0.0.0/8 or 0:0: 0:0:0:FFFF:127.0.0.0/104 for IPv4 and IPv6, respectively.
RFC 4379[RFC4379]和BFD-MPLS[BFD-MPLS]定义了警报机制，使MPLS LSR能够识别和处理封装在IP报头中的MPLS OAM数据包。例如，这些警报机制基于生存时间（TTL）到期和/或分别针对IPv4和IPv6使用127.0.0.0/8或0:0:0:0:0:0:FFFF:127.0.0/104范围内的IP目标地址。
These mechanisms are the default mechanisms for identifying MPLS OAM packets when encapsulated in an IP header although the mechanism defined in this document MAY also be used.
这些机制是在封装在IP报头中时识别MPLS OAM数据包的默认机制，尽管也可以使用本文档中定义的机制。
In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. Where the GAL is at the bottom of the label stack (i.e., S bit set to 1), then it MUST always be followed by an ACH.
在MPLS-TP中，GAL必须与LSP上G-ACh上的数据包、LSP的连接段和段一起使用，并且不得与PWs一起使用。它必须始终位于标签堆栈的底部（即S位设置为1）。但是，在其他MPLS环境中，本文档对GAL可能出现在标签堆栈中的位置或与PWs一起使用没有任何限制。如果GAL位于标签堆栈的底部（即，S位设置为1），则必须始终后跟ACH。
The GAL MUST NOT appear in the label stack when transporting normal user-plane packets. Furthermore, when present, the GAL MUST NOT appear more than once in the label stack.
传输正常用户平面数据包时，GAL不得出现在标签堆栈中。此外，当GAL存在时，GAL在标签堆栈中不得出现多次。
A receiving LSR, LER, or PE MUST NOT forward a G-ACh packet to another node based on the GAL label.
接收LSR、LER或PE不得基于GAL标签将G-ACh数据包转发到另一个节点。
The Traffic Class (TC) field (formerly known as the EXP field) of the Label Stack Entry (LSE) containing the GAL follows the definition and processing rules specified and referenced in [RFC5462].
包含GAL的标签堆栈项（LSE）的流量类（TC）字段（以前称为EXP字段）遵循[RFC5462]中指定和引用的定义和处理规则。
The Time-To-Live (TTL) field of the LSE that contains the GAL follows the definition and processing rules specified in [RFC3443].
包含GAL的LSE的生存时间（TTL）字段遵循[RFC3443]中指定的定义和处理规则。
The following figure (Figure 5) depicts two LERs (A and D) and two LSRs (B and C) for a given LSP that is established from A to D and switched in B and C.
下图（图5）描述了从A到D建立并在B和C中切换的给定LSP的两个LER（A和D）和两个LSR（B和C）。
+---+ +---+ +---+ +---+
| A |-------------| B |-------------| C |-------------| D |
+---+ +---+ +---+ +---+
+---+ +---+ +---+ +---+
| A |-------------| B |-------------| C |-------------| D |
+---+ +---+ +---+ +---+
Figure 5: Maintenance over an LSP
图5：LSP上的维护
In this example, a G-ACh exists on the LSP that extends between LERs A and D, via LSRs B and C. Only A and D may initiate new G-ACh packets. A, B, C, and D may process and respond to G-ACh packets.
在此示例中，通过LSR B和C，在LER a和D之间延伸的LSP上存在G-ACh。只有a和D可以发起新的G-ACh数据包。A、 B、C和D可以处理和响应G-ACh分组。
The following figure (Figure 6) depicts the format of an MPLS-TP G-ACh packet when used for an LSP.
下图（图6）描述了用于LSP时MPLS-TP G-ACh数据包的格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLV Header (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ Zero or more ACH TLVs ~
~ (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ G-ACh Message ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLV Header (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ Zero or more ACH TLVs ~
~ (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ G-ACh Message ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: G-ACh Packet Format for an LSP
图6:LSP的G-ACh数据包格式
Note that it is possible that the LSP may be tunneled in another LSP (e.g., if an MPLS Tunnel exists between B and C), and as such other LSEs may be present in the label stack.
注意，LSP可能在另一LSP中被隧道化（例如，如果MPLS隧道存在于B和C之间），并且因此其他lse可能存在于标签堆栈中。
To send a G-ACh message on the LSP associated control channel, the LER (A) generates a G-ACh message, to which it MAY prepend an ACH TLV Header and appropriate ACH TLVs. It then adds an ACH, onto which it pushes a GAL LSE. Finally, the LSP Label LSE is pushed onto the resulting packet.
为了在与LSP相关联的控制信道上发送G-ACh消息，LER（a）生成G-ACh消息，它可以将ACh TLV报头和适当的ACh TLV预先发送到该消息。然后，它添加一个ACH，并将一个GAL LSE推到该ACH上。最后，LSP标签LSE被推送到结果包上。
o The TTL field of the GAL LSE MUST be set to at least 1. The exact value of the TTL is application specific. See Section 4.2.1 for definition and processing rules.
o GAL LSE的TTL字段必须至少设置为1。TTL的准确值取决于具体应用。定义和处理规则见第4.2.1节。
o The S bit of the GAL MUST be set according to its position in the label stack (see Section 4.2).
o GAL的S位必须根据其在标签堆栈中的位置进行设置（参见第4.2节）。
o The setting of the TC field of the GAL is application specific. See Section 4.2.1 for definition and processing rules.
o GAL的TC字段的设置是特定于应用程序的。定义和处理规则见第4.2.1节。
LSRs MUST NOT modify the G-ACh message, the ACH or the GAL towards the targeted destination.
LSR不得向目标目的地修改G-ACh消息、ACh或GAL。
Note: This is because once a G-ACh packet has been sent on an LSP, no node has visibility of it unless the LSP label TTL expires or the GAL is exposed when the LSP label is popped. If this is at the targeted destination, for example, indicated by an address in an ACH TLV, then processing can proceed as specified below. If this is not the targeted destination, but the node has agreed to process packets on that ACH channel, then the processing applied to the packet is out of scope of this document.
注意：这是因为一旦在LSP上发送了G-ACh数据包，除非LSP标签TTL过期或当LSP标签弹出时GAL暴露，否则没有节点可以看到它。如果这是在目标目的地，例如，由ACH TLV中的地址指示，则处理可以按照以下指定进行。如果这不是目标目的地，但节点已同意在该ACH信道上处理数据包，则应用于该数据包的处理超出本文档的范围。
Upon reception of the labeled packet, the targeted destination, after having checked both the LSP Label and GAL LSEs fields, SHOULD pass the whole packet to the appropriate processing entity.
在接收到标记的分组后，目标目的地在检查了LSP Label和GAL LSEs字段之后，应将整个分组传递给适当的处理实体。
The following figure (Figure 7) depicts an example of an MPLS Section.
下图（图7）描述了MPLS部分的示例。
+---+ +---+
| A |-------------| Z |
+---+ +---+
+---+ +---+
| A |-------------| Z |
+---+ +---+
Figure 7: Maintenance over an MPLS Section
图7:MPLS部分的维护
With regard to the MPLS Section, a G-ACh exists between A and Z. Only A and Z can insert, extract, or process packets on this G-ACh.
关于MPLS部分，G-ACh存在于a和Z之间。只有a和Z可以在此G-ACh上插入、提取或处理数据包。
The following figure (Figure 8) depicts the format of a G-ACh packet when used for an MPLS Section. The GAL MAY provide the exception mechanism for a control channel in its own right without being associated with a specific LSP, thus providing maintenance-related communications across a specific link interconnecting two LSRs. In this case, the GAL is the only label in the stack.
下图（图8）描述了用于MPLS部分时G-ACh数据包的格式。GAL可自行为控制信道提供异常机制，而不与特定LSP相关联，从而在互连两个lsr的特定链路上提供与维护相关的通信。在这种情况下，GAL是堆栈中唯一的标签。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLV Header (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ Zero or more ACH TLVs ~
~ (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ G-ACh message ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLV Header (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ Zero or more ACH TLVs ~
~ (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ G-ACh message ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: G-ACh Packet Format for an MPLS Section
图8:MPLS部分的G-ACh数据包格式
To send a G-ACh message on a control channel associated to the Section, the head-end LSR (A) of the Section generates a G-ACh message, to which it MAY prepend an ACH TLV Header and appropriate ACH TLVs. Next, the LSR adds an ACH. Finally, it pushes a GAL LSE.
为了在与该区段相关联的控制信道上发送G-ACh消息，该区段的前端LSR（a）生成G-ACh消息，它可以向该消息预先发送ACh TLV报头和适当的ACh TLV。接下来，LSR添加一个ACH。最后，它推出了一个GAL LSE。
o The TTL field of the GAL MUST be set to at least 1. The exact value of the TTL is application specific. See Section 4.2.1 for definition and processing rules.
o GAL的TTL字段必须至少设置为1。TTL的准确值取决于具体应用。定义和处理规则见第4.2.1节。
o The S bit of the GAL MUST be set according to its position in the label stack. (see Section 4.2).
o GAL的S位必须根据其在标签堆栈中的位置进行设置。（见第4.2节）。
o The setting of the TC field of the GAL is application specific. See Section 4.2.1 for definition and processing rules.
o GAL的TC字段的设置是特定于应用程序的。定义和处理规则见第4.2.1节。
Intermediate nodes of the MPLS Section MUST NOT modify the G-ACh message, the ACH and the GAL towards the tail-end LSR (Z). Upon reception of the G-ACh packet, the tail-end LSR (Z), after having checked the GAL LSE fields, SHOULD pass the whole packet to the appropriate processing entity.
MPLS部分的中间节点不得向后端LSR（Z）修改G-ACh消息、ACh和GAL。在接收到G-ACh分组后，在检查了GAL LSE字段之后，尾端LSR（Z）应将整个分组传递给适当的处理实体。
RFC 3429 [RFC3429] describes the assignment of one of the reserved label values, defined in RFC 3032 [RFC3032], to the "OAM Alert Label" that is used by user-plane MPLS OAM functions for the identification of MPLS OAM packets. The value of 14 is used for that purpose.
RFC 3429[RFC3429]描述了将RFC 3032[RFC3032]中定义的一个保留标签值分配给“OAM警报标签”，该标签由用户平面MPLS OAM函数用于识别MPLS OAM数据包。14的值用于此目的。
Both this document and RFC 3429 [RFC3429] therefore describe the assignment of reserved label values for similar purposes. The rationale for the assignment of a new reserved label can be summarized as follows:
因此，本文件和RFC 3429[RFC3429]都描述了保留标签值的分配，用于类似目的。分配新保留标签的理由可总结如下：
o Unlike the mechanisms described and referenced in RFC 3429 [RFC3429], G-ACh messages will not reside immediately after the GAL but instead behind the ACH, which itself resides after the bottom of the label stack.
o 与RFC 3429[RFC3429]中描述和引用的机制不同，G-ACh消息不会立即位于GAL之后，而是位于ACh之后，ACh本身位于标签堆栈底部之后。
o The set of maintenance functions potentially operated in the context of the G-ACh is wider than the set of OAM functions referenced in RFC 3429 [RFC3429].
o 在G-ACh环境中可能运行的维护功能集比RFC 3429[RFC3429]中引用的OAM功能集更广泛。
o It has been reported that there are existing implementations and running deployments using the "OAM Alert Label" as described in RFC 3429 [RFC3429]. It is therefore not possible to modify the "OAM Alert Label" allocation, purpose, or usage. Nevertheless, it is RECOMMENDED that no further OAM extensions based on "OAM Alert Label" (Label 14) usage be specified or developed.
o 据报告，如RFC 3429[RFC3429]所述，存在使用“OAM警报标签”的现有实施和正在运行的部署。因此，无法修改“OAM警报标签”的分配、用途或用法。然而，建议不要指定或开发基于“OAM警报标签”（标签14）用法的进一步OAM扩展。
Procedures for handling a packet received with an invalid incoming label are specified in RFC 3031 [RFC3031].
RFC 3031[RFC3031]中规定了处理接收到的带有无效传入标签的数据包的程序。
An LER, LSR, or PE MUST discard received associated channel packets on which all of the MPLS or PW labels have been popped if any one of the following conditions is true:
如果以下任一条件为真，则LER、LSR或PE必须丢弃已弹出所有MPL或PW标签的已接收关联信道数据包：
o It is not capable of processing packets on the Channel Type indicated by the ACH of the received packet.
o 它不能在接收到的分组的ACH所指示的信道类型上处理分组。
o It has not, through means outside the scope of this document, indicated to the sending LSR, LER, or PE that it will process associated channel packets on the Channel Type indicated by the ACH of the received packet.
o 它没有通过本文件范围之外的方式向发送LSR、LER或PE指示它将在接收到的分组的ACH指示的信道类型上处理相关信道分组。
o The packet is received on an Experimental Channel Type that is locally disabled.
o 在本地禁用的实验信道类型上接收数据包。
o If the ACH was indicated by the presence of a GAL, and the first nibble of the ACH of the received packet is not 0001b.
o 如果ACH由GAL的存在表示，并且接收到的数据包的ACH的第一个半字节不是0001b。
o The ACH version is not recognized.
o 无法识别ACH版本。
In addition, the LER, LSR, or PE MAY increment an error counter and MAY also issue a system and/or Simple Network Management Protocol (SNMP) notification.
此外，LER、LSR或PE可以增加错误计数器，还可以发出系统和/或简单网络管理协议（SNMP）通知。
The congestion considerations detailed in RFC 5085 [RFC5085] apply.
RFC 5085[RFC5085]中详述的拥塞注意事项适用。
The editors would like to thank George Swallow, David Ward, and Rahul Aggarwal who made a major contribution to the development of this document.
编辑们要感谢乔治·斯沃恩、大卫·沃德和拉胡尔·阿加瓦尔，他们为本文件的编写做出了重大贡献。
George Swallow Cisco Systems Email: swallow@cisco.com
George Swallow Cisco Systems电子邮件：swallow@cisco.com
David Ward Cisco Systems Email: dward@cisco.com
David Ward Cisco Systems电子邮件：dward@cisco.com
Rahul Aggarwal Juniper Networks Email: rahul@juniper.net
Rahul Aggarwal Juniper Networks电子邮件：rahul@juniper.net
The editors gratefully acknowledge the contributions of Sami Boutros, Italo Busi, Marc Lasserre, Lieven Levrau, and Siva Sivabalan.
编辑们衷心感谢萨米·布特罗斯、伊塔洛·布西、马克·拉萨雷、列文·列夫劳和湿婆·西瓦巴兰的贡献。
The authors would also like to thank Malcolm Betts, ITU-T Study Group 15, and all members of the teams (the Joint Working Team, the MPLS Interoperability Design Team in IETF and the MPLS-TP Ad Hoc Team in ITU-T) involved in the definition and specification of the MPLS Transport Profile.
作者还要感谢Malcolm Betts、ITU-T研究组15以及参与MPLS传输概要定义和规范的所有团队成员（联合工作组、IETF中的MPLS互操作性设计团队和ITU-T中的MPLS-TP特设团队）。
The security considerations for the associated control channel are described in RFC 4385 [RFC4385]. Further security considerations MUST be described in the relevant associated channel type specification.
RFC 4385[RFC4385]中描述了相关控制通道的安全注意事项。相关信道类型规范中必须说明进一步的安全注意事项。
RFC 5085 [RFC5085] provides data plane related security considerations. These also apply to a G-ACh, whether the alert mechanism uses a GAL or only an ACH.
RFC 5085[RFC5085]提供了与数据平面相关的安全注意事项。这些也适用于G-ACh，无论警报机制使用GAL还是仅使用ACh。
IANA allocated label value 13 to the GAL from the pool of reserved labels in the "Multiprotocol Label Switching Architecture (MPLS) Label Values" registry.
IANA从“多协议标签交换体系结构（MPLS）标签值”注册表中的保留标签池中将标签值13分配给GAL。
Channel Types for the Associated Channel Header are allocated from the IANA "PW Associated Channel Type" registry [RFC4446]. The PW Associated Channel Type registry is currently allocated based on the IETF consensus process (termed "IETF Review" in [RFC5226]). This allocation process was chosen based on the consensus reached in the PWE3 working group that pseudowire associated channel mechanisms should be reviewed by the IETF and only those that are consistent with the PWE3 architecture and requirements should be allocated a code point.
关联信道头的信道类型从IANA“PW关联信道类型”注册表[RFC4446]分配。PW相关信道类型注册表目前是基于IETF共识过程（在[RFC5226]中称为“IETF审查”）分配的。该分配过程是根据PWE3工作组达成的共识选择的，即伪线相关信道机制应由IETF审查，并且只有符合PWE3架构和要求的机制才应分配代码点。
However, a requirement has emerged (see [OAM-REQ]) to allow for optimizations or extensions to OAM and other control protocols running in an associated channel to be experimented without resorting to the IETF standards process, by supporting experimental code points. This would prevent code points used for such functions from being used from the range allocated through the IETF standards and thus protects an installed base of equipment from potential inadvertent overloading of code points. In order to support this requirement, IANA has changed the code point allocation scheme for the PW Associated Channel Type be changed as follows:
然而，出现了一项要求（见[OAM-REQ]），允许通过支持实验代码点，对运行在相关通道中的OAM和其他控制协议进行优化或扩展，而无需求助于IETF标准过程。这将防止用于此类功能的代码点在通过IETF标准分配的范围内使用，从而保护设备的安装基础免受潜在的代码点意外过载的影响。为了支持这一要求，IANA已将PW相关信道类型的码点分配方案更改如下：
0 - 32751 : IETF Review
0-32751：IETF审查
32760 - 32767 : Experimental
32760-32767：实验性
Code points in the experimental range MUST be used according to the guidelines of RFC 3692 [RFC3692]. Functions using experimental G-ACh code points MUST be disabled by default. The Channel Type value used for a given experimental OAM function MUST be configurable, and care MUST be taken to ensure that different OAM functions that are not inter-operable are configured to use different Channel Type values.
必须根据RFC 3692[RFC3692]指南使用实验范围内的代码点。默认情况下，必须禁用使用实验性G-ACh代码点的函数。用于给定实验OAM功能的信道类型值必须是可配置的，并且必须注意确保不可互操作的不同OAM功能被配置为使用不同的信道类型值。
The PW Associated Channel Type registry has been updated to include a column indicating whether the ACH is followed by a ACH TLV header (Yes/No). There are two ACH Channel Type code-points currently assigned and in both cases no ACH TLV header is used. Thus, the new format of the PW Channel Type registry is:
PW关联通道类型注册表已更新，以包含一列，指示ACH后面是否跟有ACH TLV标头（是/否）。当前分配了两个ACH通道类型代码点，在这两种情况下均未使用ACH TLV标头。因此，PW通道类型注册表的新格式为：
Registry:
Value Description TLV Follows Reference
----- ---------------------------- ----------- ---------
0x21 ACH carries an IPv4 packet No [RFC4385]
0x57 ACH carries an IPv6 packet No [RFC4385]
Registry:
Value Description TLV Follows Reference
----- ---------------------------- ----------- ---------
0x21 ACH carries an IPv4 packet No [RFC4385]
0x57 ACH carries an IPv6 packet No [RFC4385]
Figure 9: PW Channel Type Registry
图9:PW通道类型注册表
IANA created a new registry called the Associated Channel Header TLV Registry. The allocation policy for this registry is IETF review. This registry MUST record the following information. There are no initial entries.
IANA创建了一个名为关联通道头TLV注册表的新注册表。此注册表的分配策略为IETF review。此注册表必须记录以下信息。没有初始条目。
Name Type Length Description Reference (octets)
名称类型长度描述引用（八位字节）
Figure 10: ACH TLV Registry
图10:ACHTLV注册表
[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月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003.
[RFC3443]Agarwal，P.和B.Akyol，“多协议标签交换（MPLS）网络中的生存时间（TTL）处理”，RFC 3443，2003年1月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692]Narten，T.，“分配被认为有用的实验和测试数字”，BCP 82，RFC 3692，2004年1月。
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.
[RFC4385]Bryant，S.，Swallow，G.，Martini，L.，和D.McPherson，“用于MPLS PSN的伪线仿真边到边（PWE3）控制字”，RFC 43852006年2月。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4446]Martini，L.，“伪线边到边仿真（PWE3）的IANA分配”，BCP 116，RFC 4446，2006年4月。
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5085]Nadeau，T.和C.Pignataro，“伪线虚拟电路连接验证（VCCV）：伪线的控制通道”，RFC 5085，2007年12月。
[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月。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5462]Andersson，L.和R.Asati，“多协议标签交换（MPLS）标签堆栈条目：“EXP”字段重命名为“流量类”字段”，RFC 5462，2009年2月。
[BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD For MPLS LSPs", Work in Progress, June 2008.
[BFD-MPLS]Aggarwal，R.，Kompella，K.，Nadeau，T.，和G.Swallow，“MPLS LSP的BFD”，正在进行的工作，2008年6月。
[BFD-VCCV] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", Work in Progress, May 2009.
[BFD-VCCV]Nadeau，T.和C.Pignataro，“伪线虚拟电路连接验证（VCCV）的双向转发检测（BFD）”，正在进行的工作，2009年5月。
[G805] International Telecommunication Union, "Generic Functional Architecture of Transport Networks", ITU-T G.805, March 2000.
[G805]国际电信联盟，“传输网络的通用功能架构”，ITU-T G.805，2000年3月。
[MPLS-TP] Bocci, M., Bryant, S., and L. Levrau, "A Framework for MPLS in Transport Networks", Work in Progress, November 2008.
[MPLS-TP]Bocci，M.，Bryant，S.，和L.Levrau，“传输网络中MPLS的框架”，正在进行的工作，2008年11月。
[OAM-REQ] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., "Requirements for OAM in MPLS Transport Networks", Work in Progress, March 2009.
[OAM-REQ]Vigoureux，M.，Ed.，Ward，D.，Ed.，和M.Betts，Ed.，“MPLS传输网络中的OAM要求”，正在进行的工作，2009年3月。
[RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions", RFC 3429, November 2002.
[RFC3429]Ohta，H.，“多协议标签交换体系结构（MPLS）操作和维护（OAM）功能的‘OAM警报标签’分配”，RFC 34292002年11月。
[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月。
[TP-REQ] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "MPLS-TP Requirements", Work in Progress, May 2009.
[TP-REQ]Niven Jenkins，B.，Ed.，Brungard，D.，Ed.，Betts，M.，Ed.，Sprecher，N.，和S.Ueno，“MPLS-TP要求”，正在进行的工作，2009年5月。
Authors' Addresses
作者地址
Matthew Bocci (editor) Alcatel-Lucent Voyager Place, Shoppenhangers Road Maidenhead, Berks SL6 2PJ UK
Matthew Bocci（编辑）阿尔卡特朗讯航行者广场，英国伯克斯梅登黑德Shoppenighers路SL6 2PJ
EMail: matthew.bocci@alcatel-lucent.com
EMail: matthew.bocci@alcatel-lucent.com
Martin Vigoureux (editor) Alcatel-Lucent Route de Villejust Nozay, 91620 France
Martin Vigoureux（编辑）阿尔卡特-朗讯维勒赫斯特-诺扎伊路线，91620法国
EMail: martin.vigoureux@alcatel-lucent.com
EMail: martin.vigoureux@alcatel-lucent.com
Stewart Bryant (editor) Cisco Systems
斯图尔特·布莱恩特（编辑）思科系统
EMail: stbryant@cisco.com
EMail: stbryant@cisco.com