Internet Engineering Task Force (IETF) S. Boutros, Ed.
Request for Comments: 6435 S. Sivabalan, Ed.
Updates: 6371 Cisco Systems, Inc.
Category: Standards Track R. Aggarwal, Ed.
ISSN: 2070-1721 Arktan, Inc.
M. Vigoureux, Ed.
Alcatel-Lucent
X. Dai, Ed.
ZTE Corporation
November 2011
Internet Engineering Task Force (IETF) S. Boutros, Ed.
Request for Comments: 6435 S. Sivabalan, Ed.
Updates: 6371 Cisco Systems, Inc.
Category: Standards Track R. Aggarwal, Ed.
ISSN: 2070-1721 Arktan, Inc.
M. Vigoureux, Ed.
Alcatel-Lucent
X. Dai, Ed.
ZTE Corporation
November 2011
MPLS Transport Profile Lock Instruct and Loopback Functions
MPLS传输配置文件锁定指令和环回功能
Abstract
摘要
Two useful Operations, Administration, and Maintenance (OAM) functions in a transport network are "lock" and "loopback". The lock function enables an operator to lock a transport path such that it does not carry client traffic, but can continue to carry OAM messages and may carry test traffic. The loopback function allows an operator to set a specific node on the transport path into loopback mode such that it returns all received data.
传输网络中两个有用的操作、管理和维护（OAM）功能是“锁定”和“环回”。锁定功能使操作员能够锁定传输路径，使其不承载客户端流量，但可以继续承载OAM消息，并可能承载测试流量。环回功能允许操作员将传输路径上的特定节点设置为环回模式，以便返回所有接收到的数据。
This document specifies the lock function for MPLS networks and describes how the loopback function operates in MPLS networks.
本文档规定了MPLS网络的锁定功能，并描述了环回功能在MPLS网络中的运行方式。
This document updates Sections 7.1.1 and 7.1.2 of RFC 6371.
本文件更新了RFC 6371第7.1.1节和第7.1.2节。
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/rfc6435.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6435.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Two useful Operations, Administration, and Maintenance (OAM) functions in a transport network are "lock" and "loopback". This document discusses these functions in the context of MPLS networks.
传输网络中两个有用的操作、管理和维护（OAM）功能是“锁定”和“环回”。本文档将在MPLS网络环境中讨论这些功能。
- The lock function enables an operator to lock a transport path such that it does not carry client traffic. As per RFC 5860 [1], lock is an administrative state in which it is expected that no client traffic may be carried. However, test traffic and OAM messages can still be mapped onto the locked transport path. The lock function may be applied to the Label Switched Paths (LSPs), Pseudowires (PWs) (including multi-segment Pseudowires) (MS-PWs), and bidirectional MPLS Sections as defined in RFC 5960 [9]).
- 锁定功能使操作员能够锁定传输路径，使其不承载客户端流量。根据RFC 5860[1]，锁是一种管理状态，在这种状态下，预期不会承载任何客户端流量。但是，测试流量和OAM消息仍然可以映射到锁定的传输路径上。锁定功能可应用于RFC 5960[9]中定义的标签交换路径（LSP）、伪线（PW）（包括多段伪线）（MS PWs）和双向MPLS部分。
- The loopback function allows an operator to set a specific node on a transport path into loopback mode such that it returns all received data. Loopback can be applied at a Maintenance Entity Group End Point (MEP) or a Maintenance Entity Group Intermediate Point (MIP) on a co-routed bidirectional LSP, on a PW, or on a bidirectional MPLS Section. It can also be applied at a MEP on an associated bidirectional LSP.
- 环回功能允许操作员将传输路径上的特定节点设置为环回模式，以便返回所有接收到的数据。环回可应用于共同路由的双向LSP、PW或双向MPLS部分上的维护实体组端点（MEP）或维护实体组中间点（MIP）。它还可以应用于相关联的双向LSP上的MEP。
Loopback is used to test the integrity of the transport path to and from the node that is performing loopback. It requires that the transport path be locked and that a MEP on the transport path send test data that it also validates on receipt.
环回用于测试往返于执行环回的节点的传输路径的完整性。它要求锁定传输路径，并且传输路径上的MEP发送测试数据，并在接收时进行验证。
This document specifies the lock function for MPLS networks and describes how the loopback function operates in MPLS networks.
本文档规定了MPLS网络的锁定功能，并描述了环回功能在MPLS网络中的运行方式。
This document updates Sections 7.1.1 and 7.1.2 of RFC 6371 [6].
本文件更新了RFC 6371[6]第7.1.1节和第7.1.2节。
The framework in RFC 6371 makes the assumption that the Lock Instruct message is used to independently enable locking and requires a response message.
RFC6371中的框架假设Lock指令消息用于独立启用锁定，并且需要响应消息。
The mechanism defined in this document requires that when a lock instruction is sent by management to both ends of the locked transport path, the Lock Instruct message does not require a response.
本文档中定义的机制要求，当管理层向锁定传输路径的两端发送锁定指令时，锁定指令消息不需要响应。
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 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2]中所述进行解释。
ACH: Associated Channel Header
ACH：关联通道头
LI: Lock Instruct
李：锁指示
MEG: Maintenance Entity Group
MEG：维护实体组
MEP: Maintenance Entity Group End Point
MEP：维护实体组终点
MIP: Maintenance Entity Group Intermediate Point
MIP：维护实体组中间点
MPLS-TP: MPLS Transport Profile
MPLS-TP:MPLS传输配置文件
NMS: Network Management System
网络管理系统
TLV: Type Length Value
TLV：类型长度值
Transport path: MPLS-TP LSP or PW
传输路径：MPLS-TP LSP或PW
TTL: Time To Live
TTL：生命的时刻
Lock is used to request that a MEP take a transport path out of service for administrative reasons. For example, Lock can be used to allow some form of maintenance to be done for a transport path. Lock
锁用于请求MEP出于管理原因使传输路径停止服务。例如，可以使用锁来允许对传输路径进行某种形式的维护。锁
is also a prerequisite of the loopback function described in Section 4. The NMS or a management process initiates a Lock by sending a Lock command to a MEP. The MEP takes the transport path out of service, that is, it stops injecting or forwarding traffic onto the transport path.
也是第4节中描述的环回功能的先决条件。NMS或管理进程通过向MEP发送锁定命令来启动锁定。MEP使传输路径停止服务，即停止向传输路径注入或转发流量。
To properly lock a transport path (for example, to ensure that a loopback test can be performed), both directions of the transport path must be taken out of service; therefore, a Lock command is sent to the MEPs at both ends of the path. This ensures that no traffic is sent in either direction. Thus, the lock function can be realized entirely using the management plane.
要正确锁定传输路径（例如，确保可以执行环回测试），传输路径的两个方向都必须停止服务；因此，将向路径两端的MEP发送锁定命令。这样可以确保两个方向都不会发送通信量。因此，可以使用管理平面完全实现锁定功能。
However, dispatch of messages in the management plane to the two MEPs may present coordination challenges. It is desirable that the lock be achieved in a coordinated way within a tight window, and this may be difficult with a busy management plane. In order to provide additional coordination, an LI OAM message can also be sent. A MEP locks a transport path when it receives a command from a management process or when it receives an LI message as described in Section 6.
但是，将管理平面中的消息发送给两个MEP可能会带来协调方面的挑战。在一个紧凑的窗口内以协调的方式实现锁定是可取的，而这对于繁忙的管理平面来说可能是困难的。为了提供额外的协调，还可以发送LI-OAM消息。MEP在接收到来自管理进程的命令或接收到第6节所述的LI消息时锁定传输路径。
This document defines an LI message for MPLS OAM. The LI message is based on a new ACH Type as well as an existing TLV. This is a common mechanism applicable to lock LSPs, PWs, and bidirectional MPLS Sections.
本文档定义了MPLS OAM的LI消息。LI消息基于新的ACH类型以及现有的TLV。这是一种常见的机制，适用于锁定LSP、PWs和双向MPLS部分。
This section provides a description of the loopback function within an MPLS network. This function is achieved through management commands, so there is no protocol specification necessary. However, the loopback function is dependent on the lock function, so it is appropriate to describe it in this document.
本节介绍MPLS网络中的环回功能。此功能是通过管理命令实现的，因此不需要协议规范。但是，环回功能依赖于锁定功能，因此在本文档中对其进行描述是合适的。
The loopback function is used to test the integrity of a transport path from a MEP up any other node in the same MEG. This is achieved by setting the target node into loopback mode, and transmitting a pattern of test data from the MEP. The target node loops all received data back toward the originator, and the MEP extracts the test data and compares it with what it sent.
环回功能用于测试从MEP到同一MEG中任何其他节点的传输路径的完整性。这是通过将目标节点设置为环回模式，并从MEP传输测试数据模式来实现的。目标节点将所有接收到的数据循环回发起方，MEP提取测试数据并将其与发送的数据进行比较。
Loopback is a function that enables a receiving MEP or MIP to return traffic to the sending MEP when in the loopback state. This state corresponds to the situation where, at a given node, a forwarding plane loop is configured, and the incoming direction of a transport path is cross-connected to the outgoing reverse direction. Therefore, except in the case of early TTL expiry, traffic sent by the source will be received by that source.
环回是一种功能，允许接收MEP或MIP在处于环回状态时将流量返回给发送MEP。该状态对应于在给定节点处配置转发平面环路，并且传输路径的传入方向与传出反向交叉连接的情况。因此，除非TTL提前到期，否则源发送的流量将由该源接收。
Data-plane loopback is an out-of-service function, as required in Section 2.2.5 of RFC 5860 [1]. This function loops back all traffic (including user data and OAM). The traffic can be originated from one internal point at the ingress of a transport path within an interface or inserted from an input port of an interface using external test equipment. The traffic is looped back unmodified (other than normal per-hop processing such as TTL decrement) in the direction of the point of origin by an interface at either an intermediate node or a terminating node.
根据RFC 5860[1]第2.2.5节的要求，数据平面环回是一项停用功能。此函数循环所有流量（包括用户数据和OAM）。通信量可以来自接口内传输路径入口的一个内部点，也可以使用外部测试设备从接口的输入端口插入。通过中间节点或终止节点处的接口，在原点方向上未经修改（除了正常的每跳处理，例如TTL减量）地环回通信量。
It should be noted that the data-plane loopback function itself is applied to data-plane loopback points residing on different interfaces from MIPs/MEPs. All traffic (including both payload and OAM) received on the looped back interface is sent on the reverse direction of the transport path.
应注意的是，数据平面环回功能本身适用于驻留在MIPs/MEPs不同接口上的数据平面环回点。在环回接口上接收的所有通信量（包括有效负载和OAM）在传输路径的相反方向上发送。
For data-plane loopback at an intermediate point in a transport path, the loopback needs to be configured to occur at either the ingress or egress interface. This is done using management.
对于传输路径中间点处的数据平面环回，需要将环回配置为发生在入口或出口接口处。这是使用管理来完成的。
The management plane can be used to configure the loopback function. The management plane must ensure that the two MEPs are locked before it requests setting MEP or MIP in the loopback state.
管理平面可用于配置环回功能。管理平面在请求将MEP或MIP设置为环回状态之前，必须确保两个MEP已锁定。
The nature of test data and the use of loopback traffic to measure packet loss, delay, and delay variation are outside the scope of this document.
测试数据的性质和使用环回通信量测量数据包丢失、延迟和延迟变化不在本文件的范围内。
Obviously, for the loopback function to operate, there are several prerequisites:
显然，要运行环回功能，有几个先决条件：
- There must be a return path, so the transport path under test must be bidirectional.
- 必须有一个返回路径，因此测试中的传输路径必须是双向的。
- The node in loopback mode must be on both the forward and return paths. This is possible for all MEPs and MIPs on a co-routed bidirectional LSP, on a PW, or on a bidirectional MPLS Section, but it is only possible for MEPs on associated bidirectional LSPs.
- 处于环回模式的节点必须同时位于正向路径和返回路径上。这对于共同路由的双向LSP、PW或双向MPLS部分上的所有MEP和MIP都是可能的，但仅对相关双向LSP上的MEP是可能的。
- The transport path cannot deliver client data when one of its nodes is in loopback mode, so it is important that the transport path be locked before loopback is enabled.
- 当传输路径的一个节点处于环回模式时，传输路径无法传递客户端数据，因此在启用环回之前锁定传输路径非常重要。
- Management-plane coordination between the node in loopback mode and the MEP sending test data is required. The MEP must not send test data until loopback has been properly configured because this would result in the test data continuing toward the destination.
- 需要在环回模式下的节点和发送测试数据的MEP之间进行管理平面协调。在正确配置环回之前，MEP不得发送测试数据，因为这将导致测试数据继续朝向目标。
- The TTL of the test packets must be set sufficiently large to account for both directions of the transport path under test; otherwise, the packets will not be returned to the originating MEP.
- 测试包的TTL必须设置得足够大，以考虑测试中传输路径的两个方向；否则，数据包将不会返回到原始MEP。
- OAM messages intended for delivery to nodes along the transport path under test can be delivered by correct TTL expiry. However, OAM messages cannot be delivered to points beyond the loopback node until the loopback condition is lifted.
- 用于沿着测试中的传输路径传递到节点的OAM消息可以通过正确的TTL到期来传递。但是，在环回条件解除之前，OAM消息无法传递到环回节点以外的点。
The Lock Instruct message is carried in the Generic ACH described in [4]. It is identified by a new PW ACH Type of 0x0026.
锁定指令消息在[4]中描述的通用ACH中携带。它由新的PW ACH类型0x0026标识。
The format of an LI message is shown below.
LI消息的格式如下所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Reserved | Refresh Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MEP Source ID 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Reserved | Refresh Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MEP Source ID TLV |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: MPLS Lock Instruct Message Format
图1:MPLS锁指令消息格式
Version: The Version number is currently 1. (Note: the version number is to be incremented whenever a change is made that affects the ability of an implementation to correctly parse or process the message. These changes include any syntactic or semantic changes made to any of the fixed fields, or to any Type-Length-Value (TLV) or sub- TLV assignment or format that is defined at a certain version number. The version number may not need to be changed if an optional TLV or sub-TLV is added.)
版本：版本号当前为1。（注意：每当更改影响实现正确解析或处理消息的能力时，版本号将增加。这些更改包括对任何固定字段或任何类型长度值（TLV）所做的任何语法或语义更改或在特定版本号上定义的子TLV分配或格式。如果添加可选TLV或子TLV，则可能不需要更改版本号。）
Reserved: The Reserved field MUST be set to zero on transmission and SHOULD be ignored on receipt.
保留：传输时必须将保留字段设置为零，接收时应忽略该字段。
Refresh Timer: The Refresh Timer is the maximum time between successive LI messages specified in seconds. The default value is 1. The value 0 is not permitted. When a lock is applied, a refresh timer is chosen. This value MUST NOT be changed for the duration of that lock. A node receiving an LI message with a changed refresh timer MAY ignore the new value and continue to apply the old value.
刷新计时器：刷新计时器是以秒为单位指定的连续LI消息之间的最长时间。默认值为1。不允许使用值0。应用锁时，将选择刷新计时器。在该锁定期间，不得更改此值。接收具有更改的刷新计时器的LI消息的节点可以忽略新值并继续应用旧值。
MEP Source ID TLV: This is one of the three MEP Source ID TLVs defined in [3] and identifies the MEP that originated the LI message.
MEP源ID TLV：这是[3]中定义的三个MEP源ID TLV之一，用于标识发起LI消息的MEP。
When a MEP receives a Lock command from an NMS or through some other management process, it MUST take the transport path out of service. That is, it MUST stop injecting or forwarding traffic onto the LSP, PW, or bidirectional Section that has been locked.
当MEP从NMS或通过某些其他管理过程接收到锁定命令时，它必须使传输路径停止服务。也就是说，它必须停止向已锁定的LSP、PW或双向部分注入或转发流量。
If rapid coordination of lock state is to be achieved (as described in Section 3) then as soon as the transport path has been locked, the MEP MUST send an LI message targeting the MEP at the other end of the locked transport path. In this case, the source MEP MUST set the Refresh Timer value in the LI message and MUST retransmit the LI message at the frequency indicated by the value set.
如果要实现锁定状态的快速协调（如第3节所述），则一旦传输路径被锁定，MEP必须发送一条LI消息，以锁定传输路径另一端的MEP为目标。在这种情况下，源MEP必须在LI消息中设置刷新计时器值，并且必须以设置的值指示的频率重新传输LI消息。
When locking a transport path, the NMS or management process is required to send a Lock command to both ends of the transport path. Thus, a MEP may receive either the management command or an LI message first. A MEP MUST take the transport path out of service immediately in either case, but sends LI messages itself after it has received a management Lock command. Thus, a MEP is locked if either Lock was requested by management (and, as a result, the MEP is sending LI messages) or it is receiving LI messages from the remote MEP.
锁定传输路径时，需要NMS或管理进程向传输路径的两端发送锁定命令。因此，MEP可以首先接收管理命令或LI消息。在任何一种情况下，MEP都必须立即使传输路径停止服务，但在收到管理锁命令后，它会自行发送LI消息。因此，如果管理层请求了锁（因此，MEP正在发送LI消息）或它正在从远程MEP接收LI消息，则MEP被锁定。
Note that a MEP that receives an LI message MUST identify the correct transport path and validate the message. The label stack on the received message is used to identify the transport path to be locked:
请注意，接收LI消息的MEP必须标识正确的传输路径并验证消息。接收到的消息上的标签堆栈用于标识要锁定的传输路径：
- If no matching label binding exists, then there is no corresponding transport path and the received LI message is in error.
- 如果不存在匹配的标签绑定，则没有相应的传输路径，并且接收到的LI消息出错。
- If the transport path can be identified, but there is no return path (for example, the transport path was unidirectional) then (obviously) the receiving MEP cannot apply a lock to the return path.
- 如果可以识别传输路径，但没有返回路径（例如，传输路径是单向的），则（显然）接收MEP无法对返回路径应用锁。
- If the transport path is suitable for locking but the Source MEP-ID identifies an unexpected MEP for the MEG to which the receiving MEP belongs, the received LI message is in error.
- 如果传输路径适合锁定，但源MEP-ID为接收MEP所属的MEG识别出意外的MEP，则接收到的LI消息出错。
When an errored LI message is received, the receiving MEP MUST NOT apply a lock. A MEP receiving errored LI messages SHOULD perform local diagnostic actions (such as counting the messages) and MAY log the messages.
当接收到错误的LI消息时，接收MEP不得应用锁定。接收错误LI消息的MEP应执行本地诊断操作（如统计消息）并记录消息。
A MEP keeps a transport path locked as long as it is either receiving the periodic LI messages or has an in-force Lock command from management (see Section 6.2 for an explanation of unlocking a MEP). Note that in some scenarios (such as the use of loopback as described in Section 4), LI messages will not continue to be delivered on a locked transport path. This is why a transport path is considered locked while there is an in-force Lock command from a management process regardless of whether LI messages are being received.
只要MEP正在接收定期LI消息或具有来自管理层的有效锁定命令，MEP就会保持传输路径锁定（有关解锁MEP的说明，请参阅第6.2节）。请注意，在某些情况下（如第4节所述使用环回），LI消息将不会继续在锁定的传输路径上传递。这就是为什么在管理进程发出有效锁定命令时，无论是否接收到LI消息，传输路径都被视为锁定。
Unlock is used to request that a MEP bring the previously locked transport path back in service.
解锁用于请求MEP将先前锁定的传输路径恢复使用。
When a MEP receives an Unlock command from a management process, it MUST cease sending LI messages. However, as described in Section 6.1, if the MEP is still receiving LI messages, the transport path MUST remain out of service. Thus, to unlock a transport path, the management process has to send an Unlock command to the MEPs at both ends.
当MEP从管理进程接收到解锁命令时，它必须停止发送LI消息。但是，如第6.1节所述，如果MEP仍在接收LI消息，则传输路径必须保持停止服务。因此，要解锁传输路径，管理过程必须向两端的MEP发送解锁命令。
When a MEP has been unlocked and has not received an LI message for a multiple of 3.5 times the Refresh Timer on the LI message (or has never received an LI message), the MEP unlocks the transport path and puts it back into service.
当MEP已解锁且在LI消息刷新计时器的3.5倍时间内未收到LI消息（或从未收到LI消息）时，MEP将解锁传输路径并将其重新投入使用。
MPLS-TP is a subset of MPLS and builds upon many of the aspects of the security model of MPLS. MPLS networks make the assumption that it is very hard to inject traffic into a network, and it is equally hard to cause traffic to be directed outside the network. For more information on the generic aspects of MPLS security, see [7].
MPLS-TP是MPLS的一个子集，建立在MPLS安全模型的许多方面之上。MPLS网络假设很难将流量注入网络，也很难将流量定向到网络外部。有关MPLS安全性的一般方面的更多信息，请参见[7]。
This document describes a protocol carried in the G-ACh [4], so it is dependent on the security of the G-ACh, itself. The G-ACh is a generalization of the Pseudowire Associated Channel defined in [8]. Thus, this document relies heavily on the security mechanisms provided for the Associated Channel as described in [4] and [8].
本文档描述了G-ACh[4]中的一个协议，因此它依赖于G-ACh本身的安全性。G-ACh是[8]中定义的伪线相关信道的推广。因此，本文档在很大程度上依赖于为相关通道提供的安全机制，如[4]和[8]所述。
A specific concern for the G-ACh is that is can be used to provide a covert channel. This problem is wider than the scope of this document and does not need to be addressed here, but it should be noted that the channel provides end-to-end connectivity and SHOULD NOT be policed by transit nodes. Thus, there is no simple way to prevent traffic from being carried in the G-ACh between consenting nodes.
G-ACh的一个特别关注点是，它可以用来提供隐蔽通道。此问题超出了本文档的范围，此处不需要解决，但应注意，通道提供端到端连接，不应由传输节点进行监控。因此，没有简单的方法可以防止在同意节点之间的G-ACh中承载流量。
A good discussion of the data-plane security of an associated channel may be found in [5]. That document also describes some mitigation techniques.
有关相关信道的数据平面安全性的详细讨论，请参见[5]。该文件还描述了一些缓解技术。
It should be noted that the G-ACh is essentially connection-oriented, so injection or modification of control messages specified in this document requires the subversion of a transit node. Such subversion is generally considered hard in MPLS networks, and impossible to protect against at the protocol level. Management-level techniques are more appropriate.
应该注意的是，G-ACh本质上是面向连接的，因此本文档中指定的控制消息的注入或修改需要对传输节点进行颠覆。在MPLS网络中，这种颠覆通常被认为是很难实现的，并且不可能在协议级别进行保护。管理层技术更合适。
LI OAM requires a unique Associated Channel Type that has been assigned by IANA in the "Pseudowire Associated Channel Types" registry.
LI OAM需要IANA在“伪线关联通道类型”注册表中分配的唯一关联通道类型。
Registry:
Value Description TLV Follows Reference
----------- ----------------------- ----------- ---------
0x0026 LI No [RFC6435]
Registry:
Value Description TLV Follows Reference
----------- ----------------------- ----------- ---------
0x0026 LI No [RFC6435]
The authors would like to thank Loa Andersson, Yoshinori Koike, Alessandro D'Alessandro Gerardo, Shahram Davari, Greg Mirsky, Yaacov Weingarten, Liu Guoman, Matthew Bocci, Adrian Farrel, and Jia He for their valuable comments.
作者感谢Loa Andersson、Yoshinori Koike、Alessandro D’Alessandro Gerardo、Shahram Davari、Greg Mirsky、Yaacov Weingarten、刘国曼、Matthew Bocci、Adrian Farrel和Jia He的宝贵评论。
[1] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010.
[1] Vigoureux，M.，Ed.，Ward，D.，Ed.，和M.Betts，Ed.，“MPLS传输网络中的操作、管理和维护（OAM）要求”，RFC 5860，2010年5月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Allan, D., Ed., Swallow, G., Ed., and J. Drake, Ed., "Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile", RFC 6428, November 2011.
[3] Allan，D.，Ed.，Swallow，G.，Ed.，和J.Drake，Ed.，“MPLS传输配置文件的主动连接验证、连续性检查和远程缺陷指示”，RFC 64282011年11月。
[4] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
[4] Bocci，M.，Ed.，Vigoureux，M.，Ed.，和S.Bryant，Ed.，“MPLS通用关联信道”，RFC 55862009年6月。
[5] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[5] Nadeau，T.，Ed.，和C.Pignataro，Ed.，“伪线虚拟电路连接验证（VCCV）：伪线的控制通道”，RFC 5085，2007年12月。
[6] Busi, I., Ed., and D. Allan, Ed., "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011.
[6] Busi，I.，Ed.，和D.Allan，Ed.，“基于MPLS的传输网络的操作、管理和维护框架”，RFC 6371，2011年9月。
[7] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[7] Fang，L.，Ed.“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月。
[8] 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.
[8] Bryant，S.，Swallow，G.，Martini，L.，和D.McPherson，“用于MPLS PSN的伪线仿真边到边（PWE3）控制字”，RFC 4385，2006年2月。
[9] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS Transport Profile Data Plane Architecture", RFC 5960, August 2010.
[9] Frost，D.，Ed.，Bryant，S.，Ed.，和M.Bocci，Ed.，“MPLS传输配置文件数据平面架构”，RFC 59602010年8月。
Contributing Authors
撰稿人
George Swallow Cisco Systems, Inc. EMail: swallow@cisco.com
George Swallow Cisco Systems，Inc.电子邮件：swallow@cisco.com
David Ward Juniper Networks. EMail: dward@juniper.net
David Ward Juniper Networks。电邮：dward@juniper.net
Stewart Bryant Cisco Systems, Inc. EMail: stbryant@cisco.com
Stewart Bryant Cisco Systems，Inc.电子邮件：stbryant@cisco.com
Carlos Pignataro Cisco Systems, Inc. EMail: cpignata@cisco.com
Carlos Pignataro Cisco Systems，Inc.电子邮件：cpignata@cisco.com
Eric Osborne Cisco Systems, Inc. EMail: eosborne@cisco.com
Eric Osborne Cisco Systems，Inc.电子邮件：eosborne@cisco.com
Nabil Bitar Verizon. EMail: nabil.bitar@verizon.com
纳比尔·比塔·威瑞森。电子邮件：纳比尔。bitar@verizon.com
Italo Busi Alcatel-Lucent. EMail: italo.busi@alcatel-lucent.com
Italo Busi Alcatel-Lucent。电子邮件：italo。busi@alcatel-朗讯网
Lieven Levrau Alcatel-Lucent. EMail: lieven.levrau@alcatel-lucent.com
列文·列夫罗·阿尔卡特·朗讯。电子邮件：列文。levrau@alcatel-朗讯网
Laurent Ciavaglia Alcatel-Lucent. EMail: laurent.ciavaglia@alcatel-lucent.com
劳伦特·查瓦利亚·阿尔卡特·朗讯。电子邮件：劳伦特。ciavaglia@alcatel-朗讯网
Bo Wu ZTE Corporation. EMail: wu.bo@zte.com.cn
博乌中兴通讯公司。电邮：吴。bo@zte.com.cn
Jian Yang ZTE Corporation. EMail: yang_jian@zte.com.cn
建阳中兴通讯股份有限公司。电邮：杨_jian@zte.com.cn
Editors' Addresses
编辑地址
Sami Boutros Cisco Systems, Inc. EMail: sboutros@cisco.com
Sami Boutros Cisco Systems，Inc.电子邮件：sboutros@cisco.com
Siva Sivabalan Cisco Systems, Inc. EMail: msiva@cisco.com
Siva Sivabalan Cisco Systems，Inc.电子邮件：msiva@cisco.com
Rahul Aggarwal Arktan, Inc EMail: raggarwa_1@yahoo.com
Rahul Aggarwal Arktan公司电子邮件：raggarwa_1@yahoo.com
Martin Vigoureux Alcatel-Lucent. EMail: martin.vigoureux@alcatel-lucent.com
马丁·维古鲁·阿尔卡特·朗讯。电子邮件：马丁。vigoureux@alcatel-朗讯网
Xuehui Dai ZTE Corporation. EMail: dai.xuehui@zte.com.cn
学汇戴中兴通讯股份有限公司。电子邮件：戴。xuehui@zte.com.cn