Internet Engineering Task Force (IETF) T. Nadeau
Request for Comments: 7708 Brocade
Category: Standards Track L. Martini
ISSN: 2070-1721 S. Bryant
Cisco Systems
November 2015
Internet Engineering Task Force (IETF) T. Nadeau
Request for Comments: 7708 Brocade
Category: Standards Track L. Martini
ISSN: 2070-1721 S. Bryant
Cisco Systems
November 2015
Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator
使用通用关联通道标签作为虚拟电路连接验证通道指示器
Abstract
摘要
The Virtual Circuit Connectivity Verification (VCCV) protocol specified in RFC 5085 provides a control channel (CC) that is associated with a pseudowire (PW). This document specifies an additional VCCV control channel type to be used with pseudowires that do not use the PW Control Word and that are carried over an MPLS network. This new VCCV CC type uses the Generic Associated Channel Label defined in RFC 5586 to distinguish VCCV packets from packets carrying user data. This new VCCV CC type introduces compatibility with the method of MPLS Label Switched Path Operations, Administration, and Maintenance (OAM) identification, particularly in MPLS Transport Profile (MPLS-TP) networks (RFC 5921).
RFC 5085中规定的虚拟电路连接验证（VCCV）协议提供了与伪线（PW）相关联的控制信道（CC）。本文件规定了一种额外的VCCV控制信道类型，用于不使用PW控制字且通过MPLS网络传输的伪线。这种新的VCCV CC类型使用RFC 5586中定义的通用关联通道标签来区分VCCV数据包和承载用户数据的数据包。这种新的VCCV CC类型引入了与MPLS标签交换路径操作、管理和维护（OAM）标识方法的兼容性，特别是在MPLS传输配置文件（MPLS-TP）网络（RFC 5921）中。
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/rfc7708.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7708.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Type 4 MPLS VCCV Control Channel Type . . . . . . . . . . . . 3
4. FAT PWs . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Multi-Segment Pseudowires . . . . . . . . . . . . . . . . . . 5
6. VCCV Capability Advertisement . . . . . . . . . . . . . . . . 5
7. Manageability Considerations . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9.1. MPLS VCCV Control Channel (CC) Type 4 . . . . . . . . . . 7
9.2. LDP Status Code . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Type 4 MPLS VCCV Control Channel Type . . . . . . . . . . . . 3
4. FAT PWs . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Multi-Segment Pseudowires . . . . . . . . . . . . . . . . . . 5
6. VCCV Capability Advertisement . . . . . . . . . . . . . . . . 5
7. Manageability Considerations . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9.1. MPLS VCCV Control Channel (CC) Type 4 . . . . . . . . . . 7
9.2. LDP Status Code . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
The Virtual Circuit Connectivity Verification (VCCV) protocol is specified in RFC 5085 [RFC5085]. This document specifies a new VCCV control channel (VCCV CC) type to be used with pseudowires (PWs) carried over an MPLS network that do not use the PW Control Word (CW) [RFC4385]. This new VCCV CC type uses the Generic Associated Channel Label (GAL) [RFC5586] to distinguish VCCV packets from packets carrying user data. This new VCCV CC type provides compatibility with the method of MPLS Label Switched Path (LSP) Operations, Administration, and Maintenance (OAM) message identification, as used in MPLS Transport Profile (MPLS-TP) networks [RFC5921].
RFC 5085[RFC5085]中规定了虚拟电路连接验证（VCCV）协议。本文件规定了一种新的VCCV控制信道（VCCV CC）类型，用于通过不使用PW控制字（CW）的MPLS网络传输的伪线（PW）[RFC4385]。这种新的VCCV CC类型使用通用关联信道标签（GAL）[RFC5586]来区分VCCV数据包和承载用户数据的数据包。这种新的VCCV CC类型提供了与MPLS传输配置文件（MPLS-TP）网络中使用的MPLS标签交换路径（LSP）操作、管理和维护（OAM）消息识别方法的兼容性[RFC5921]。
VCCV currently specifies three CC types. VCCV CC Type 1 uses the PW Control Word (CW) to distinguish VCCV packets from packets carrying user data. VCCV CC Types 2 and 3 require IP encapsulation for OAM packets. This was not an issue when [RFC5085] was designed, but it is in conflict with the design goals of MPLS-TP [RFC5921], which do not otherwise require the availability of IP. VCCV CC Type 2 is not applicable to Multi-Segment PWs (MS-PWs) [RFC6073]. A MS-PW operating without the CW therefore has to use VCCV CC Type 3, which identifies VCCV packets on the basis of Time to Live (TTL) expiry. Whilst less of an issue with a single segment PW (SS-PW), on an MS-PW this requires accurately setting the TTL for expiry at the egress Terminating Provider Edge (T-PE) [RFC6073]. In the event of an error in the setting of the PW Label Stack Entry (LSE) TTL, VCCV packets will not be received by the Terminating Provider Edge (T-PE) and may leak into the attachment circuit [RFC6073]. The new VCCV CC type defined in this specification addresses these problems for PWs that do not use the CW.
VCCV目前指定了三种CC类型。VCCV CC Type 1使用PW控制字（CW）区分VCCV数据包和携带用户数据的数据包。VCCV CC类型2和3需要对OAM数据包进行IP封装。在设计[RFC5085]时，这不是一个问题，但它与MPLS-TP[RFC5921]的设计目标相冲突，后者不需要IP的可用性。VCCV CC类型2不适用于多段PWs（MS PWs）[RFC6073]。因此，在没有CW的情况下运行的MS-PW必须使用VCCV CC类型3，它根据生存时间（TTL）到期来识别VCCV数据包。虽然单段PW（SS-PW）的问题较少，但在MS-PW上，这需要准确设置出口端接提供商边缘（T-PE）处到期的TTL[RFC6073]。如果PW标签堆栈项（LSE）TTL的设置出现错误，则端接提供商边缘（T-PE）将不会接收VCCV数据包，并可能泄漏到连接电路[RFC6073]。本规范中定义的新VCCV CC类型解决了不使用CW的PW的这些问题。
Note that mandating that PWs use the PW CW is not a viable way to address this issue. This is because:
请注意，强制PWs使用PW CW不是解决此问题的可行方法。这是因为：
o PWs without the CW are already widely deployed.
o 没有CW的PWs已经广泛部署。
o There is a significant deployment of existing hardware that does not support usage of the PW CW for some PW types.
o 现有硬件的大量部署不支持对某些PW类型使用PW CW。
o Some operators are concerned that the inclusion of the PW CW will increase the PW packet size.
o 一些运营商担心加入PW CW会增加PW数据包的大小。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
When the PW CW is not used, the Type 4 MPLS VCCV Control Channel (CC) type defined in this section MAY be used. This is referred to as VCCV CC Type 4 throughout the rest of this of this document. VCCV CC Type 4 uses the encapsulation shown in Figure 1 in which the presence of a GAL at the end of the MPLS label stack indicates that the packet carries a VCCV message.
未使用PW CW时，可使用本节中定义的4类MPLS VCCV控制信道（CC）类型。本文件其余部分将其称为VCCV CC类型4。VCCV CC Type 4使用如图1所示的封装，其中MPLS标签堆栈末端的GAL表示数据包携带VCCV消息。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW LSE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL LSE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ VCCV Message Body ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW LSE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL LSE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ VCCV Message Body ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
图1
The VCCV message body is preceded by a Generic Associated Channel Header, as defined in [RFC5586], in which the Channel Type identifies the type and format of the OAM message carried in the VCCV message body.
VCCV消息体前面有一个通用的相关信道头，如[RFC5586]中所定义，其中信道类型标识VCCV消息体中承载的OAM消息的类型和格式。
The GAL LSE MUST contain the GAL reserved label as defined in [RFC5586].
GAL LSE必须包含[RFC5586]中定义的GAL保留标签。
The PW LSE is constructed according to the existing procedures that apply to the type of pseudowire that is in use.
PW LSE根据适用于正在使用的伪导线类型的现有程序构建。
Where the LSP used by the PW is subject to Equal-Cost Multipath (ECMP) load balancing, a problem arises if any LSR on that LSP treats special-purpose labels as ordinary labels in its ECMP selection method. In these circumstances, the inclusion of a GAL following the PW LSE can cause the OAM packet to take a different path through the network than the corresponding PW data packets. If the LSP traverses such equipment and this behaviour is not acceptable, then an alternative VCCV type needs to be used. The requirement to not include special-purpose labels in the load-balancing decision is described in "MPLS Forwarding Compliance and Performance Requirements" [RFC7325]. For equipment that conforms to this, the VCCV type 4 traffic will follow the corresponding PW data packets.
当PW使用的LSP受到等成本多路径（ECMP）负载平衡的影响时，如果该LSP上的任何LSR在其ECMP选择方法中将专用标签视为普通标签，则会出现问题。在这些情况下，在PW LSE之后包含GAL可导致OAM分组在网络中采取与相应PW数据分组不同的路径。如果LSP穿过此类设备，且该行为不可接受，则需要使用替代VCCV类型。“MPLS转发遵从性和性能要求”[RFC7325]中描述了在负载平衡决策中不包括专用标签的要求。对于符合此要求的设备，VCCV类型4通信将遵循相应的PW数据包。
[RFC6391] specifies that when the flow-aware transport (FAT) of pseudowires over an MPLS packet switched network has been signalled or configured, the Flow LSE MUST be present. It further specifies that "the flow label MUST NOT be an MPLS reserved label (values in the range 0..15) [RFC3032]", and that "If a flow LSE is present, it MUST be checked to determine whether it carries a reserved label. If
[RFC6391]指定，当MPLS分组交换网络上的伪线的流感知传输（FAT）已通过信号发送或配置时，流LSE必须存在。它进一步规定“流标签不得为MPLS保留标签（值范围为0..15）[RFC3032]”，并且“如果存在流LSE，则必须对其进行检查以确定其是否携带保留标签。如果
it is a reserved label, the packet is processed according to the rules associated with that reserved label; otherwise, the LSE is discarded."
它是保留标签，分组根据与该保留标签相关联的规则进行处理；否则，LSE将被丢弃。”
This document specifies that if the flow-aware transport of pseudowires over an MPLS packet switched network has been signalled or configured, then the presence of VCCV message is indicated by the use of a GAL in place of the flow LSE.
本文件规定，如果MPLS分组交换网络上的伪线流感知传输已通过信号发送或配置，则VCCV消息的存在通过使用GAL代替流LSE来指示。
This is consistent with [RFC6391], and the packet structure is identical to that shown in Figure 1.
这与[RFC6391]一致，并且数据包结构与图1所示的相同。
Flow LSEs are inserted into a PW label stack in order to enable the distribution of the PW traffic among multiple equal-cost MPLS paths. The use of GAL in place of the flow label will cause all OAM packets to take exactly one of the possible paths through the network. As noted in Section 3, the ECMP selection method may result in the path taken by the OAM packets being different from the path taken by any of the actual traffic flows. If this is not acceptable, then an alternative VCCV type needs be used.
流LSE被插入到PW标签堆栈中，以便能够在多个等成本MPLS路径之间分配PW流量。使用GAL代替流标签将导致所有OAM数据包恰好通过网络的一条可能路径。如第3节中所述，ECMP选择方法可导致OAM分组所采用的路径不同于任何实际业务流所采用的路径。如果这是不可接受的，则需要使用替代VCCV类型。
When using VCCV CC Type 4 for MS-PWs, a PE transmitting the VCCV packet to a Switching PE (S-PE) MUST set the TTL to the appropriate value to expire at that S-PE. An S-PE that supports this specification MUST inspect PW packets that are received as a result of TTL expiry, and determine whether a GAL follows the PW LSE. If a GAL is present, the S-PE then processes the VCCV packet.
将VCCV CC Type 4用于MS PWs时，将VCCV数据包传输至交换PE（S-PE）的PE必须将TTL设置为适当的值，以在该S-PE处过期。支持此规范的S-PE必须检查由于TTL到期而接收的PW数据包，并确定GAL是否遵循PW LSE。如果存在GAL，则S-PE处理VCCV数据包。
An S-PE that does not support this specification would be expected to reject as malformed a VCCV CC Type 4 packet that was received. This is because the S-PE would expect the PW LSE to be the bottom of stack (the non-FAT case) and for the LSE at the bottom of stack not to be a reserved label (both the FAT and the non-FAT cases). An S-PE that did not make this reserved label check would then find that the first nibble following the label stack was 0x1 and not the expected start of an IP packet. Thus, it would be expected to also reject the packet. This update to the behaviour of S-PEs is therefore backwards compatible.
不支持此规范的S-PE将被视为接收到格式错误的VCCV CC类型4数据包而拒绝。这是因为S-PE希望PW LSE是堆栈底部（非FAT情况），而堆栈底部的LSE不是保留标签（FAT和非FAT情况）。未进行此保留标签检查的S-PE将发现标签堆栈后面的第一个半字节是0x1，而不是IP数据包的预期开始。因此，期望它也拒绝该分组。因此，对S-PEs行为的更新是向后兼容的。
The VCCV capability advertisement MUST match the C-bit setting that is advertised in the PW FEC element [RFC4447]. If the C-bit is set, indicating the use of the PW CW, then VCCV CC Type 4 MUST NOT be advertised. If the C-bit is not set, indicating that the PW CW is not in use, then equipment supporting this specification MUST
VCCV能力播发必须与PW FEC元素[RFC4447]中播发的C位设置相匹配。如果设置了C位，表示使用PW CW，则不得公布VCCV CC类型4。如果未设置C位，表示未使用PW CW，则必须安装支持本规范的设备
advertise VCCV CC Type 4. Advertisement of VCCV CC Type 1 and advertisement of VCCV CC Type 4 are therefore mutually exclusive.
宣传VCCV CC类型4。因此，VCCV CC类型1的广告和VCCV CC类型4的广告是相互排斥的。
A PE supporting VCCV CC Type 4 MAY advertise other VCCV CC types as defined in [RFC5085] .
支持VCCV CC类型4的PE可公布[RFC5085]中定义的其他VCCV CC类型。
If the remote PE supports VCCV CC Type 4, and the PW CW is not in use, then for cases where multiple CC Types are advertised, the following precedence rules apply when choosing which CC Type to use:
如果远程PE支持VCCV CC类型4，且PW CW未在使用，则对于播发多个CC类型的情况，在选择要使用的CC类型时，以下优先规则适用：
1. Type 4: GAL VCCV Control Channel.
1. 类型4：GAL VCCV控制通道。
2. Type 2: MPLS Router Alert Label.
2. 类型2:MPLS路由器警报标签。
3. Type 3: MPLS PW Label with TTL == 1.
3. 类型3:TTL==1的MPLS PW标签。
If the remote PE finds that VCCV CC Types 1 and 4 are both advertised, or that C-bit is set and VCCV CC Type 4 is advertised, then it should report the error to the operator through the management interface in use, and send a Label Release Message with a status code "VCCV Type Error".
如果远程PE发现VCCV CC类型1和4均已播发，或设置了C位且VCCV CC类型4已播发，则应通过正在使用的管理界面向操作员报告错误，并发送状态代码为“VCCV类型错误”的标签发布消息。
Whilst the introduction of this additional VCCV CC type increases the number of VCCV CC types that the operator needs to manage, it addresses the issues with VCCV CC Types 2 and 3 described in Section 1.
虽然这种额外VCCV CC类型的引入增加了运营商需要管理的VCCV CC类型的数量，但它解决了第1节中描述的VCCV CC类型2和3的问题。
In the event of a misconfiguration of this VCCV CC type, the PW is taken out of service and the operator advised as described in Section 6.
如果该VCCV CC类型配置错误，PW将停止运行，并按照第6节所述通知操作员。
Attention is drawn to the possible absence of fate sharing between PW data packets and VCCV CC Type 4 packets described in Section 3 and Section 4.
请注意第3节和第4节中描述的PW数据包和VCCV CC类型4包之间可能没有命运共享。
This document does not by itself raise any new security considerations beyond those described in [RFC5085] and [RFC6073]. [RFC6073] provides detailed operational procedures that can be used to verify the MS-PW connectivity. In addition, the procedure specified in this document eliminates the possibility of packet leaking that can occur with VCCV Type 3.
除[RFC5085]和[RFC6073]中所述的安全注意事项外，本文件本身并未提出任何新的安全注意事项。[RFC6073]提供了可用于验证MS-PW连接的详细操作程序。此外，本文件中规定的程序消除了VCCV类型3可能发生的数据包泄漏的可能性。
IANA has assigned a new bit from the MPLS VCCV Control Channel (CC) Types registry in the "Pseudowire Name Spaces (PWE3)" registry in order to identify VCCV type 4.
IANA已从“伪线名称空间（PWE3）”注册表中的MPLS VCCV控制通道（CC）类型注册表中分配了一个新位，以识别VCCV类型4。
MPLS VCCV Control Channel (CC) Types
MPLS VCCV控制通道（CC）类型
Bit (Value) Description Reference
============ =========== ==================
Bit 3 (0x08) Type 4: GAL RFC 7708
Bit (Value) Description Reference
============ =========== ==================
Bit 3 (0x08) Type 4: GAL RFC 7708
IANA has assigned a new Status Code from the "Label Distribution Protocol (LDP) Parameters" registry:
IANA已从“标签分发协议（LDP）参数”注册表中分配了一个新的状态代码：
Status Code Name Space
Range/Value E Description Reference
=========== = =============== =========
0x00000035 0 VCCV Type Error RFC 7708
Status Code Name Space
Range/Value E Description Reference
=========== = =============== =========
0x00000035 0 VCCV Type Error RFC 7708
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[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, DOI 10.17487/RFC4385, February 2006, <http://www.rfc-editor.org/info/rfc4385>.
[RFC4385]Bryant，S.，Swallow，G.，Martini，L.，和D.McPherson，“用于MPLS PSN的伪线仿真边到边（PWE3）控制字”，RFC 4385，DOI 10.17487/RFC4385，2006年2月<http://www.rfc-editor.org/info/rfc4385>.
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, DOI 10.17487/RFC4447, April 2006, <http://www.rfc-editor.org/info/rfc4447>.
[RFC4447]Martini，L.，Ed.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，DOI 10.17487/RFC4447，2006年4月<http://www.rfc-editor.org/info/rfc4447>.
[RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December 2007, <http://www.rfc-editor.org/info/rfc5085>.
[RFC5085]Nadeau，T.，Ed.和C.Pignataro，Ed.，“伪线虚拟电路连接验证（VCCV）：伪线的控制通道”，RFC 5085，DOI 10.17487/RFC5085，2007年12月<http://www.rfc-editor.org/info/rfc5085>.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, June 2009, <http://www.rfc-editor.org/info/rfc5586>.
[RFC5586]Bocci，M.，Ed.，Vigoureux，M.，Ed.，和S.Bryant，Ed.，“MPLS通用关联信道”，RFC 5586，DOI 10.17487/RFC55862009年6月<http://www.rfc-editor.org/info/rfc5586>.
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, "Segmented Pseudowire", RFC 6073, DOI 10.17487/RFC6073, January 2011, <http://www.rfc-editor.org/info/rfc6073>.
[RFC6073]Martini，L.，Metz，C.，Nadeau，T.，Bocci，M.和M.Aissaoui，“分段伪线”，RFC 6073，DOI 10.17487/RFC6073，2011年1月<http://www.rfc-editor.org/info/rfc6073>.
[RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, "Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network", RFC 6391, DOI 10.17487/RFC6391, November 2011, <http://www.rfc-editor.org/info/rfc6391>.
[RFC6391]Bryant，S.，Ed.，Filsfils，C.，Drafz，U.，Kompella，V.，Regan，J.，和S.Amante，“MPLS分组交换网络上伪线的流感知传输”，RFC 6391，DOI 10.17487/RFC63911911<http://www.rfc-editor.org/info/rfc6391>.
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, <http://www.rfc-editor.org/info/rfc5921>.
[RFC5921]Bocci，M.，Ed.，Bryant，S.，Ed.，Frost，D.，Ed.，Levrau，L.，和L.Berger，“传输网络中MPLS的框架”，RFC 5921，DOI 10.17487/RFC59212010年7月<http://www.rfc-editor.org/info/rfc5921>.
[RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., and C. Pignataro, "MPLS Forwarding Compliance and Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, August 2014, <http://www.rfc-editor.org/info/rfc7325>.
[RFC7325]Villamizar，C.，Ed.，Kompella，K.，Amante，S.，Malis，A.，和C.Pignataro，“MPLS转发合规性和性能要求”，RFC 7325，DOI 10.17487/RFC73252014年8月<http://www.rfc-editor.org/info/rfc7325>.
Acknowledgments
致谢
The authors wish to thank Alexander (Sasha) Vainshtein for his proposal to make the GAL and Flow labels mutually exclusive. This proposal led to a significant simplification of this design. The authors also thank Sasha, Matthew Bocci, Loa Andersson, and Deborah Brungard for their review comments.
作者希望感谢Alexander（Sasha）Vainstein提出的使GAL和Flow标签相互排斥的建议。这一提议大大简化了这一设计。作者还感谢萨沙、马修·博奇、洛亚·安德森和黛博拉·布伦加德的评论。
Authors' Addresses
作者地址
Thomas D. Nadeau Brocade
托马斯·纳多·博科
Email: tnadeau@lucidvision.com
Email: tnadeau@lucidvision.com
Luca Martini Cisco Systems
卢卡·马蒂尼思科系统公司
Email: lmartini@cisco.com
Email: lmartini@cisco.com
Stewart Bryant Cisco Systems
思科系统公司
Email: stewart.bryant@gmail.com
Email: stewart.bryant@gmail.com