Internet Engineering Task Force (IETF) T. Nadeau, Ed.
Request for Comments: 5885 BT
Category: Standards Track C. Pignataro, Ed.
ISSN: 2070-1721 Cisco Systems, Inc.
June 2010
Internet Engineering Task Force (IETF) T. Nadeau, Ed.
Request for Comments: 5885 BT
Category: Standards Track C. Pignataro, Ed.
ISSN: 2070-1721 Cisco Systems, Inc.
June 2010
Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)
用于虚拟电路连接验证（VCCV）的双向转发检测（BFD）
Abstract
摘要
This document describes Connectivity Verification (CV) Types using Bidirectional Forwarding Detection (BFD) with Virtual Circuit Connectivity Verification (VCCV). VCCV provides a control channel that is associated with a pseudowire (PW), as well as the corresponding operations and management functions such as connectivity verification to be used over that control channel.
本文档描述了使用双向转发检测（BFD）和虚拟电路连接验证（VCCV）的连接验证（CV）类型。VCCV提供与伪线（PW）相关联的控制通道，以及相应的操作和管理功能，如通过该控制通道使用的连接验证。
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/rfc5885.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5885.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Specification of Requirements . . . . . . . . . . . . . . . . 3
3. Bidirectional Forwarding Detection Connectivity
Verification . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. BFD CV Type Operation . . . . . . . . . . . . . . . . . . 4
3.2. BFD Encapsulation . . . . . . . . . . . . . . . . . . . . 5
3.3. CV Types for BFD . . . . . . . . . . . . . . . . . . . . . 7
4. Capability Selection . . . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5.1. MPLS CV Types for the VCCV Interface Parameters Sub-TLV . 10
5.2. PW Associated Channel Type . . . . . . . . . . . . . . . . 10
5.3. L2TPv3 CV Types for the VCCV Capability AVP . . . . . . . 11
6. Congestion Considerations . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Specification of Requirements . . . . . . . . . . . . . . . . 3
3. Bidirectional Forwarding Detection Connectivity
Verification . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. BFD CV Type Operation . . . . . . . . . . . . . . . . . . 4
3.2. BFD Encapsulation . . . . . . . . . . . . . . . . . . . . 5
3.3. CV Types for BFD . . . . . . . . . . . . . . . . . . . . . 7
4. Capability Selection . . . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5.1. MPLS CV Types for the VCCV Interface Parameters Sub-TLV . 10
5.2. PW Associated Channel Type . . . . . . . . . . . . . . . . 10
5.3. L2TPv3 CV Types for the VCCV Capability AVP . . . . . . . 11
6. Congestion Considerations . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 13
This document describes Connectivity Verification (CV) Types using Bidirectional Forwarding Detection (BFD) with Virtual Circuit Connectivity Verification (VCCV). VCCV [RFC5085] provides a control channel that is associated with a pseudowire (PW), as well as the corresponding operations and management functions such as connectivity/fault verification to be used over that control channel.
本文档描述了使用双向转发检测（BFD）和虚拟电路连接验证（VCCV）的连接验证（CV）类型。VCCV[RFC5085]提供与伪线（PW）相关联的控制通道，以及相应的操作和管理功能，如通过该控制通道使用的连接/故障验证。
BFD [RFC5880] is used over the VCCV control channel primarily as a pseudowire fault detection mechanism, for detecting data-plane failures. Some BFD CV Types can additionally carry fault status between the endpoints of the pseudowire. Furthermore, this information can then be translated into the native Operations, Administration, and Maintenance (OAM) status codes used by the native access technologies, such as ATM, Frame Relay, or Ethernet. The specific details of such status interworking are out of the scope of this document, and are only noted here to illustrate the utility of BFD over VCCV for such purposes. Those details can be found in [OAM-MSG-MAP].
BFD[RFC5880]主要作为伪线故障检测机制在VCCV控制通道上使用，用于检测数据平面故障。某些BFD CV类型还可以在伪导线端点之间传输故障状态。此外，该信息随后可转换为本机接入技术（如ATM、帧中继或以太网）使用的本机操作、管理和维护（OAM）状态码。此类状态互通的具体细节不在本文件范围内，此处仅说明BFD对VCCV的用途。这些详细信息可在[OAM-MSG-MAP]中找到。
The new BFD CV Types are PW demultiplexer-agnostic, and hence applicable for both MPLS and Layer Two Tunneling Protocol version 3 (L2TPv3) pseudowire demultiplexers. This document concerns itself with the BFD VCCV operation over single-segment pseudowires (SS-PWs). This specification describes procedures only for BFD asynchronous mode.
新的BFD CV类型与PW解复用器无关，因此适用于MPLS和第二层隧道协议版本3（L2TPv3）伪线解复用器。本文件涉及单段伪导线（SS PWs）上的BFD VCCV操作。本规范仅描述BFD异步模式的程序。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The reader is expected to be familiar with the terminology and abbreviations defined in [RFC5085].
读者应熟悉[RFC5085]中定义的术语和缩写。
VCCV can support several Connectivity Verification (CV) Types. This section defines new CV Types for use when BFD is used as the VCCV payload.
VCCV可以支持多种连接验证（CV）类型。本节定义了BFD用作VCCV有效载荷时使用的新CV类型。
Four CV Types are defined for BFD. Table 1 summarizes the BFD CV Types, grouping them by encapsulation (i.e., with versus without IP/ UDP headers) and by functionality (i.e., fault detection only versus fault detection and status signaling).
为BFD定义了四种CV类型。表1总结了BFD CV类型，按封装（即有无IP/UDP头）和功能（即仅故障检测与故障检测和状态信令）对其进行分组。
+----------------------------+--------------+-----------------------+
| | Fault | Fault Detection and |
| | Detection | Status Signaling |
| | Only | |
+----------------------------+--------------+-----------------------+
| BFD, IP/UDP Encapsulation | 0x04 | 0x08 |
| (with IP/UDP Headers) | | |
| | | |
| BFD, PW-ACH Encapsulation | 0x10 | 0x20 |
| (without IP/UDP Headers) | | |
+----------------------------+--------------+-----------------------+
+----------------------------+--------------+-----------------------+
| | Fault | Fault Detection and |
| | Detection | Status Signaling |
| | Only | |
+----------------------------+--------------+-----------------------+
| BFD, IP/UDP Encapsulation | 0x04 | 0x08 |
| (with IP/UDP Headers) | | |
| | | |
| BFD, PW-ACH Encapsulation | 0x10 | 0x20 |
| (without IP/UDP Headers) | | |
+----------------------------+--------------+-----------------------+
Table 1: Bitmask Values for BFD CV Types
表1:BFD CV类型的位掩码值
When heart-beat indication is necessary for one or more PWs, the Bidirectional Forwarding Detection (BFD) [RFC5880] provides a means of continuous monitoring of the PW data path and, in some operational modes, propagation of PW receive and transmit defect state indications.
当一个或多个PW需要心跳指示时，双向转发检测（BFD）[RFC5880]提供了一种连续监测PW数据路径的方法，并且在某些操作模式下，传播PW接收和发送缺陷状态指示。
In order to use BFD, both ends of the PW connection need to agree on the BFD CV Type to use:
为了使用BFD，PW连接的两端需要就要使用的BFD CV类型达成一致：
For statically provisioned pseudowires, both ends need to be statically configured to use the same BFD CV Type (in addition to being statically configured for VCCV with the same CC Type).
对于静态配置的伪导线，两端需要静态配置为使用相同的BFD CV类型（除了静态配置为具有相同CC类型的VCCV）。
For dynamically established pseudowires, both ends of the PW must have signaled the existence of a control channel and the ability to run BFD on it (see Sections 3.3 and 4).
对于动态建立的伪线，PW的两端必须发出信号，表明存在控制通道，并能够在其上运行BFD（见第3.3和4节）。
Once a node has selected a valid BFD CV Type to use (either statically provisioned or selected dynamically after the node has both signaled and received signaling from its peer of these capabilities), it begins sending BFD Control packets:
一旦节点选择了要使用的有效BFD CV类型（静态配置或在节点发出信号并从这些功能的对等方接收信号后动态选择），它就开始发送BFD控制数据包：
o The BFD Control packets are sent on the VCCV control channel. The use of the VCCV control channel provides the context required to bind and bootstrap the BFD session, since discriminator values are not exchanged; the pseudowire demultiplexer field (e.g., MPLS PW Label or L2TPv3 Session ID) provides the context to demultiplex the first BFD Control packet, and thus single-hop BFD initialization procedures are followed (see Section 3 of [RFC5881] and Section 6 of [RFC5882]).
o BFD控制数据包在VCCV控制信道上发送。VCCV控制通道的使用提供了绑定和引导BFD会话所需的上下文，因为不交换鉴别器值；伪线解复用器字段（例如，MPLS PW标签或L2TPv3会话ID）提供用于解复用第一个BFD控制数据包的上下文，因此遵循单跳BFD初始化过程（参见[RFC5881]第3节和[RFC5882]第6节）。
o A single BFD session exists per pseudowire. Both PW endpoints take the Active role sending initial BFD Control packets with a Your Discriminator field of zero, and BFD Control packets received with a Your Discriminator field of zero are associated to the BFD session bound to the PW.
o 每个伪线存在一个BFD会话。两个PW端点都扮演主动角色，发送初始BFD控制数据包时，您的鉴别器字段为零，接收到的BFD控制数据包时，您的鉴别器字段为零，这些数据包与绑定到PW的BFD会话相关联。
o BFD MUST be run in asynchronous mode (see [RFC5880]).
o BFD必须在异步模式下运行（参见[RFC5880]）。
The operation of BFD VCCV for PWs is therefore symmetrical. Both endpoints of the bidirectional pseudowire MUST send BFD messages on the VCCV control channel.
因此，用于PWs的BFD VCCV的操作是对称的。双向伪线的两个端点必须在VCCV控制通道上发送BFD消息。
The details of the BFD state machine are as per Section 6.2 of [RFC5880]. The following scenario exemplifies the operation: when the downstream PE (D-PE) does not receive BFD Control messages from its upstream peer PE (U-PE) during a certain number of transmission intervals (a number provisioned by the operator as "Detect Mult" or detection time multiplier [RFC5880]), D-PE declares that the PW in its receive direction is down. In other words, D-PE enters the "PW receive defect" state for this PW. After this calculated Detection Time (see Section 6.8.4 of [RFC5880]), D-PE declares the session Down, and signals this to the remote end via the State (Sta) with Diagnostic code 1 (Control Detection Time Expired). In turn, U-PE declares the PW is down in its transmit direction, setting the State to Down with Diagnostic code 3 (Neighbor signaled session down) in its control messages to D-PE. U-PE enters the "PW transmit defect" state for this PW. How it further processes this error condition, and potentially conveys this status to the attachment circuits, is out of the scope of this specification, and is defined in [OAM-MSG-MAP].
BFD状态机的详细信息参见[RFC5880]第6.2节。以下场景举例说明了该操作：当下游PE（D-PE）在一定数量的传输间隔期间（由操作员设置为“Detect Mult”或检测时间乘数[RFC5880]）没有从其上游对等PE（U-PE）接收BFD控制消息时，D-PE声明接收方向的PW向下。换句话说，D-PE为此PW进入“PW接收缺陷”状态。在计算出的检测时间（见[RFC5880]第6.8.4节）之后，D-PE宣布会话关闭，并通过状态（Sta）向远程端发送信号，诊断代码为1（控制检测时间已过期）。反过来，U-PE声明PW在其传输方向下降，将状态设置为下降，并在其发送给D-PE的控制消息中显示诊断代码3（邻居信号会话下降）。U-PE为此PW进入“PW传输缺陷”状态。它如何进一步处理此错误条件，并可能将此状态传递给连接电路，不在本规范的范围内，并在[OAM-MSG-MAP]中定义。
The VCCV message comprises a BFD Control packet [RFC5880] encapsulated as specified by the CV Type. There are two ways in which a BFD connectivity verification packet may be encapsulated over the VCCV control channel. This document defines four BFD CV Types (see Section 3), which can be grouped into two pairs of BFD CV Types from an encapsulation point of view. See Table 1 in Section 3, which summarizes the BFD CV Types.
VCCV消息包括按CV类型规定封装的BFD控制包[RFC5880]。有两种方法可以通过VCCV控制信道封装BFD连接验证数据包。本文档定义了四种BFD CV类型（参见第3节），从封装的角度来看，这些类型可分为两对BFD CV类型。参见第3节中的表1，其中总结了BFD CV类型。
o IP/UDP BFD Encapsulation (BFD with IP/UDP Headers)
o IP/UDP BFD封装（带IP/UDP头的BFD）
In the first method, the VCCV encapsulation of BFD includes the IP/UDP headers as defined in Section 4 of [RFC5881]. BFD Control packets are therefore transmitted in UDP with destination port 3784 and source port within the range 49152 through 65535. The IP
在第一种方法中，BFD的VCCV封装包括[RFC5881]第4节中定义的IP/UDP报头。因此，BFD控制数据包在UDP中传输，目标端口3784和源端口的范围在49152到65535之间。知识产权
Protocol Number and UDP Port numbers discriminate among the possible VCCV payloads (i.e., differentiate among ICMP Ping and LSP Ping defined in [RFC5085] and BFD).
协议号和UDP端口号区分可能的VCCV有效负载（即区分[RFC5085]和BFD中定义的ICMP Ping和LSP Ping）。
The IP version (IPv4 or IPv6) MUST match the IP version used for signaling for dynamically established pseudowires or MUST be configured for statically provisioned pseudowires. The source IP address is an address of the sender. The destination IP address is a (randomly chosen) IPv4 address from the range 127/8 or IPv6 address from the range 0:0:0:0:0:FFFF:127.0.0.0/104. The rationale is explained in Section 2.1 of [RFC4379]. The Time to Live/Hop Limit and Generalized TTL Security Mechanism (GTSM) procedures from Section 5 of [RFC5881] apply to this encapsulation, and hence the TTL/Hop Limit is set to 255.
IP版本（IPv4或IPv6）必须与用于为动态建立的伪线发送信号的IP版本相匹配，或者必须为静态配置的伪线进行配置。源IP地址是发件人的地址。目标IP地址是127/8范围内的（随机选择的）IPv4地址或0:0:0:0:FFFF:127.0.0.0/104范围内的IPv6地址。[RFC4379]第2.1节解释了基本原理。[RFC5881]第5节中的生存时间/跃点限制和通用TTL安全机制（GTSM）过程适用于此封装，因此TTL/跃点限制设置为255。
If the PW is established by signaling, then the BFD CV Type used for this encapsulation is either 0x04 or 0x08.
如果通过信令建立PW，则用于此封装的BFD CV类型为0x04或0x08。
o PW-ACH BFD Encapsulation (BFD without IP/UDP Headers)
o PW-ACH BFD封装（不带IP/UDP头的BFD）
In the second method, a BFD Control packet (format defined in Section 4 of [RFC5880]) is encapsulated directly in the VCCV control channel (see Sections 6 and 8 of [RFC5882]) and the IP/UDP headers are omitted from the BFD encapsulation. Therefore, to utilize this encapsulation, a pseudowire MUST use the PW Associated Channel Header (PW-ACH) Control Word format (see [RFC5586]) for its Control Word (CW) or L2-Specific Sublayer (L2SS, used in L2TPv3).
在第二种方法中，BFD控制包（在[RFC5880]第4节中定义的格式）直接封装在VCCV控制信道中（参见[RFC5882]第6节和第8节），并且从BFD封装中省略IP/UDP报头。因此，为了利用这种封装，伪线必须将PW相关信道头（PW-ACH）控制字格式（参见[RFC5586]）用于其控制字（CW）或L2特定子层（L2SS，用于L2TPv3）。
In this encapsulation, a "raw" BFD Control packet (i.e., a BFD Control packet as defined in Section 4.1 of [RFC5880] without IP/ UDP headers) follows directly the PW-ACH. The PW-ACH Channel Type indicates that the Associated Channel carries "raw" BFD. The PW Associated Channel (PWAC) is defined in Section 5 of [RFC4385], and its Channel Type field is used to discriminate the VCCV payload types.
在此封装中，“原始”BFD控制数据包（即，[RFC5880]第4.1节中定义的无IP/UDP报头的BFD控制数据包）直接跟随PW-ACH。PW-ACH信道类型指示相关信道承载“原始”BFD。[RFC4385]第5节定义了PW相关信道（PWAC），其信道类型字段用于区分VCCV有效负载类型。
The usage of the PW-ACH on different VCCV CC Types is specified for CC Type 1, Type 2, and Type 3 respectively in Sections 5.1.1, 5.1.2, and 5.1.3 of [RFC5085], and in all cases requires the use of a CW (see Section 7 of [RFC4385]). When VCCV carries PW-ACH-encapsulated BFD (i.e., "raw" BFD), the PW-ACH (pseudowire CW's or L2SS') Channel Type MUST be set to 0x0007 to indicate "BFD Control, PW-ACH-encapsulated" (i.e., BFD without IP/UDP headers; see Section 5.2). This is to allow the identification of the encased BFD payload when demultiplexing the VCCV control channel.
[RFC5085]第5.1.1、5.1.2和5.1.3节分别规定了在不同VCCV CC类型上使用PW-ACH用于CC类型1、类型2和类型3，并且在所有情况下都需要使用CW（见[RFC4385]第7节）。当VCCV携带PW-ACH封装BFD（即“原始”BFD）时，PW-ACH（伪线CW或L2SS）信道类型必须设置为0x0007，以指示“BFD控制，PW-ACH封装”（即没有IP/UDP报头的BFD；见第5.2节）。这是为了在解复用VCCV控制信道时识别封装的BFD有效负载。
If the PW is established by signaling, then the BFD CV Type used for this encapsulation is either 0x10 or 0x20.
如果通过信令建立PW，则用于此封装的BFD CV类型为0x10或0x20。
In summary, for the IP/UDP encapsulation of BFD (BFD with IP/UDP headers), if a PW Associated Channel Header is used, the Channel Type MUST indicate either IPv4 (0x0021) or IPv6 (0x0057). For the PW-ACH encapsulation of BFD (BFD without IP/UDP headers), the PW Associated Channel Header MUST be used and the Channel Type MUST indicate BFD Control packet (0x0007).
总之，对于BFD的IP/UDP封装（带有IP/UDP头的BFD），如果使用PW关联的通道头，则通道类型必须指示IPv4（0x0021）或IPv6（0x0057）。对于BFD的PW-ACH封装（没有IP/UDP头的BFD），必须使用PW关联的通道头，通道类型必须指示BFD控制数据包（0x0007）。
The CV Type is defined as a bitmask field used to indicate the specific CV Type or Types (i.e., none, one, or more) of VCCV packets that may be sent on the VCCV control channel. The CV Types shown in the table below augment those already defined in [RFC5085]. Their values shown in parentheses represent the numerical value corresponding to the actual bit being set in the CV Type bitfield.
CV类型定义为位掩码字段，用于指示可能在VCCV控制信道上发送的VCCV数据包的特定CV类型（即无、一个或多个）。下表所示的CV类型补充了[RFC5085]中已经定义的CV类型。括号中显示的值表示与CV类型位字段中设置的实际位相对应的数值。
BFD CV Types:
BFD CV类型：
The defined values for the different BFD CV Types for MPLS and L2TPv3 PWs are:
MPLS和L2TPv3 PWs的不同BFD CV类型的定义值为：
Bit (Value) Description
============ ====================================================
Bit 2 (0x04) BFD IP/UDP-encapsulated, for PW Fault Detection only
Bit 3 (0x08) BFD IP/UDP-encapsulated, for PW Fault Detection and
AC/PW Fault Status Signaling
Bit 4 (0x10) BFD PW-ACH-encapsulated, for PW Fault Detection only
Bit 5 (0x20) BFD PW-ACH-encapsulated, for PW Fault Detection and
AC/PW Fault Status Signaling
Bit (Value) Description
============ ====================================================
Bit 2 (0x04) BFD IP/UDP-encapsulated, for PW Fault Detection only
Bit 3 (0x08) BFD IP/UDP-encapsulated, for PW Fault Detection and
AC/PW Fault Status Signaling
Bit 4 (0x10) BFD PW-ACH-encapsulated, for PW Fault Detection only
Bit 5 (0x20) BFD PW-ACH-encapsulated, for PW Fault Detection and
AC/PW Fault Status Signaling
It should be noted that four BFD CV Types have been defined by combining two types of encapsulation with two types of functionality; see Table 1 in Section 3.
应该注意的是，通过结合两种封装类型和两种功能类型，定义了四种BFD CV类型；见第3节表1。
Given the bidirectional nature of BFD, before selecting a given BFD CV Type capability to be used in dynamically established pseudowires, there MUST be common CV Types in the VCCV capability advertised and received. That is, only BFD CV Types that were both advertised and received are available to be selected. Additionally, only one BFD CV Type can be used (selecting a BFD CV Type excludes all the remaining BFD CV Types).
鉴于BFD的双向性，在选择要在动态建立的伪线中使用的给定BFD CV类型功能之前，在公布和接收的VCCV功能中必须有公共CV类型。也就是说，只有已发布和接收的BFD CV类型可供选择。此外，只能使用一种BFD CV类型（选择BFD CV类型将排除所有剩余的BFD CV类型）。
The following list enumerates rules, restrictions, and clarifications on the usage of BFD CV Types:
下表列举了有关BFD CV类型使用的规则、限制和说明：
1. BFD CV Types used for fault detection and status signaling (i.e., CV Types 0x08 and 0x20) SHOULD NOT be used when a control protocol such as LDP [RFC4447] or L2TPV3 [RFC3931] is available that can signal the AC/PW status to the remote endpoint of the PW. More details can be found in [OAM-MSG-MAP].
1. 当LDP[RFC4447]或L2TPV3[RFC3931]等控制协议可用时，不应使用用于故障检测和状态信令的BFD CV类型（即，CV类型0x08和0x20），该控制协议可向PW的远程端点发送AC/PW状态信号。更多详细信息请参见[OAM-MSG-MAP]。
2. BFD CV Types used for fault detection only (i.e., CV Types 0x04 and 0x10) can be used whether or not a protocol that can signal AC/PW status is available. This includes both statically provisioned and dynamically signaled pseudowires.
2. 无论是否存在可发出AC/PW状态信号的协议，仅用于故障检测的BFD CV类型（即CV类型0x04和0x10）均可使用。这包括静态配置和动态信号伪线。
2.1. In this case, BFD is used exclusively to detect faults on the PW; if it is desired to convey AC/PW fault status, some means other than BFD are to be used. Examples include using LDP status messages when using MPLS as a transport (see Section 5.4 of [RFC4447]), and the Circuit Status Attribute Value Pair (AVP) in an L2TPv3 SLI message for L2TPv3 (see Section 5.4.5 of [RFC3931]).
2.1. 在这种情况下，BFD专门用于检测PW上的故障；如果需要传达AC/PW故障状态，则应使用除BFD以外的其他方式。示例包括在使用MPLS作为传输时使用LDP状态消息（参见[RFC4447]第5.4节），以及L2TPv3的L2TPv3 SLI消息中的电路状态属性值对（AVP）（参见[RFC3931]第5.4.5节）。
3. Pseudowires that do not use a CW or L2SS using the PW Associated Channel Header MUST NOT use the BFD CV Types 0x10 or 0x20 (i.e., PW-ACH encapsulation of BFD, without IP/UDP headers).
3. 不使用CW或L2SS（使用PW相关信道头）的伪线不得使用BFD CV类型0x10或0x20（即BFD的PW-ACH封装，无IP/UDP头）。
3.1. PWs that use a PW-ACH include CC Type 1 (for both MPLS and L2TPv3 as defined in Sections 5.1.1 and 6.1 of [RFC5085]), and MPLS CC Types 2 and 3 when using a Control Word (as specified in Sections 5.1.2 and 5.1.3 of [RFC5085]). This restriction stems from the fact that the encapsulation uses the Channel Type in the PW-ACH.
3.1. 使用PW-ACH的PW包括CC类型1（对于[RFC5085]第5.1.1节和第6.1节中定义的MPLS和L2TPv3），以及使用控制字时的MPLS CC类型2和3（如[RFC5085]第5.1.2节和第5.1.3节中的规定）。此限制源于封装使用PW-ACH中的通道类型这一事实。
3.2. PWs that do not use a PW-ACH can use the VCCV BFD encapsulation with IP/UDP headers, as the only VCCV BFD encapsulation supported. Using the IP/UDP encapsulated BFD CV Types allows for the concurrent use of other VCCV CV Types that use an encapsulation with IP headers (e.g., ICMP Ping or LSP Ping defined in [RFC5085]).
3.2. 不使用PW-ACH的PWs可以使用带有IP/UDP头的VCCV BFD封装，这是唯一受支持的VCCV BFD封装。使用IP/UDP封装的BFD CV类型允许同时使用使用IP头封装的其他VCCV类型（例如，[RFC5085]中定义的ICMP Ping或LSP Ping）。
4. Only a single BFD CV Type can be selected and used. All BFD CV Types are mutually exclusive. After selecting a BFD CV Type, a node MUST NOT use any of the other three BFD CV Types.
4. 只能选择和使用单个BFD CV类型。所有BFD CV类型都是互斥的。选择BFD CV类型后，节点不得使用其他三种BFD CV类型中的任何一种。
5. Once a PE has chosen a single BFD CV Type to use, it MUST continue using it until when the PW is re-signaled. In order to change the negotiated and selected BFD CV Type, the PW must be torn down and re-established.
5. 一旦PE选择使用单个BFD CV类型，则必须继续使用该类型，直到PW重新发出信号。为了更改协商和选择的BFD CV类型，必须拆除并重新建立PW。
The precedence rules for selection of various CC and CV Types is clearly outlined in Section 7 of [RFC5085]. This section augments these rules when the BFD CV Types defined herein are supported. The selection of a specific BFD CV Type to use out of the four available CV Types defined is tied to multiple factors, as described in Section 3.3. Given that BFD is bidirectional in nature, only CV Types that are both received and sent in VCCV capability signaling advertisement can be selected.
[RFC5085]第7节中明确概述了选择各种CC和CV类型的优先规则。当支持本文定义的BFD CV类型时，本节将扩充这些规则。如第3.3节所述，从定义的四种可用CV类型中选择要使用的特定BFD CV类型与多个因素有关。鉴于BFD本质上是双向的，只能选择在VCCV能力信令广告中接收和发送的CV类型。
When multiple BFD CV Types are advertised, and after applying the rules in Section 3.3, the set that both ends of the pseudowire have in common is determined. If the two ends have more than one BFD CV Type in common, the following list of BFD CV Types is considered in the order of the lowest list number CV Type to the highest list number CV Type, and the CV Type with the lowest list number is used:
当公布多个BFD CV类型时，并在应用第3.3节中的规则后，确定伪导线两端具有共同点的集合。如果两端共有一个以上的BFD CV类型，则按照列表编号最低的CV类型到列表编号最高的CV类型的顺序考虑以下BFD CV类型列表，并使用列表编号最低的CV类型：
1. 0x20 - BFD PW-ACH-encapsulated (without IP/UDP headers), for PW Fault Detection and AC/PW Fault Status Signaling
1. 0x20-BFD PW ACH封装（无IP/UDP报头），用于PW故障检测和AC/PW故障状态信令
2. 0x10 - BFD PW-ACH-encapsulated (without IP/UDP headers), for PW Fault Detection only
2. 0x10-BFD PW ACH封装（无IP/UDP头），仅用于PW故障检测
3. 0x08 - BFD IP/UDP-encapsulated, for PW Fault Detection and AC/PW Fault Status Signaling
3. 0x08-BFD IP/UDP封装，用于PW故障检测和AC/PW故障状态信令
4. 0x04 - BFD IP/UDP-encapsulated, for PW Fault Detection only
4. 0x04-BFD IP/UDP封装，仅用于PW故障检测
The VCCV Interface Parameters Sub-TLV codepoint is defined in [RFC4446], and the VCCV CV Types registry is defined in [RFC5085]. This section lists the new BFD CV Types.
VCCV接口参数子TLV代码点在[RFC4446]中定义，VCCV类型注册表在[RFC5085]中定义。本节列出了新的BFD CV类型。
IANA has augmented the "VCCV Connectivity Verification (CV) Types" registry in the Pseudowire Name Spaces reachable from [IANA]. These are bitfield values. CV Type values 0x04, 0x08, 0x10, and 0x20 are specified in Section 3 of this document.
IANA在可从[IANA]访问的伪线名称空间中扩充了“VCCV连接验证（CV）类型”注册表。这些是位字段值。本文件第3节规定了CV类型值0x04、0x08、0x10和0x20。
MPLS Connectivity Verification (CV) Types:
MPLS连接验证（CV）类型：
Bit (Value) Description
============ ====================================================
Bit 2 (0x04) BFD IP/UDP-encapsulated, for PW Fault Detection only
Bit 3 (0x08) BFD IP/UDP-encapsulated, for PW Fault Detection and
AC/PW Fault Status Signaling
Bit 4 (0x10) BFD PW-ACH-encapsulated, for PW Fault Detection only
Bit 5 (0x20) BFD PW-ACH-encapsulated, for PW Fault Detection and
AC/PW Fault Status Signaling
Bit (Value) Description
============ ====================================================
Bit 2 (0x04) BFD IP/UDP-encapsulated, for PW Fault Detection only
Bit 3 (0x08) BFD IP/UDP-encapsulated, for PW Fault Detection and
AC/PW Fault Status Signaling
Bit 4 (0x10) BFD PW-ACH-encapsulated, for PW Fault Detection only
Bit 5 (0x20) BFD PW-ACH-encapsulated, for PW Fault Detection and
AC/PW Fault Status Signaling
The PW Associated Channel Types used by VCCV rely on previously allocated numbers from the Pseudowire Associated Channel Types Registry [RFC4385] in the Pseudowire Name Spaces reachable from [IANA].
VCCV使用的PW关联信道类型依赖于先前从[IANA]可访问的伪线名称空间中的伪线关联信道类型注册表[RFC4385]分配的数字。
IANA has reserved a new Pseudowire Associated Channel Type value as follows:
IANA已保留一个新的伪线关联通道类型值，如下所示：
Registry:
TLV
Value Description Follows Reference
------ ---------------------------------- ------- ---------------
0x0007 BFD Control, PW-ACH encapsulation No [This document]
(without IP/UDP Headers)
Registry:
TLV
Value Description Follows Reference
------ ---------------------------------- ------- ---------------
0x0007 BFD Control, PW-ACH encapsulation No [This document]
(without IP/UDP Headers)
This section lists the new BFD CV Types to be added to the existing "VCCV Capability AVP" registry in the L2TP name spaces. The Layer Two Tunneling Protocol "L2TP" Name Spaces are reachable from [IANA].
本节列出了要添加到L2TP名称空间中现有“VCCV Capability AVP”注册表的新BFD CV类型。第二层隧道协议“L2TP”名称空间可从[IANA]访问。
IANA has reserved the following L2TPv3 Connectivity Verification (CV) Types in the VCCV Capability AVP Values registry.
IANA已在VCCV能力AVP值注册表中保留以下L2TPv3连接验证（CV）类型。
VCCV Capability AVP (Attribute Type 96) Values
----------------------------------------------
VCCV Capability AVP (Attribute Type 96) Values
----------------------------------------------
L2TPv3 Connectivity Verification (CV) Types:
L2TPv3连接验证（CV）类型：
Bit (Value) Description
============ ====================================================
Bit 2 (0x04) BFD IP/UDP-encapsulated, for PW Fault Detection only
Bit 3 (0x08) BFD IP/UDP-encapsulated, for PW Fault Detection and
AC/PW Fault Status Signaling
Bit 4 (0x10) BFD PW-ACH-encapsulated, for PW Fault Detection only
Bit 5 (0x20) BFD PW-ACH-encapsulated, for PW Fault Detection and
AC/PW Fault Status Signaling
Bit (Value) Description
============ ====================================================
Bit 2 (0x04) BFD IP/UDP-encapsulated, for PW Fault Detection only
Bit 3 (0x08) BFD IP/UDP-encapsulated, for PW Fault Detection and
AC/PW Fault Status Signaling
Bit 4 (0x10) BFD PW-ACH-encapsulated, for PW Fault Detection only
Bit 5 (0x20) BFD PW-ACH-encapsulated, for PW Fault Detection and
AC/PW Fault Status Signaling
The congestion considerations that apply to [RFC5085] apply to this mode of operation as well. This section describes explicitly how they apply.
适用于[RFC5085]的拥塞注意事项也适用于此操作模式。本节明确描述了它们的应用方式。
BFD as a VCCV application is required to provide details on congestion and bandwidth considerations. BFD provides with a desired minimum transmit interval and a required minimum receive interval, negotiates the transmission interval using these configurable fields, and has a packet of fixed size (setting the transmission rate). Therefore, it results in a configuration limited bandwidth utilization. As stated in [RFC5085], this is sufficient protection against congestion as long as BFD's configured maximum bit-rate is minimal compared to the bit-rate of the pseudowire the VCCV channel is associated with. If the pseudowire bit-rate can't be guaranteed to be minimal, like potentially for highly variable bit-rate and/or congestion responsive pseudowires, BFD will be required to operate using an adaptive congestion control mechanism (for example, including a throttled transmission rate on "congestion detected" situations, and a slow-start after shutdown due to congestion and until basic connectivity is verified).
BFD作为VCCV应用程序需要提供有关拥塞和带宽考虑的详细信息。BFD提供所需的最小发送间隔和所需的最小接收间隔，使用这些可配置字段协商传输间隔，并具有固定大小的数据包（设置传输速率）。因此，它会导致配置有限的带宽利用率。如[RFC5085]所述，只要BFD配置的最大比特率与VCCV信道相关的伪线比特率相比最小，这就足以防止拥塞。如果无法保证伪线比特率最小，如高度可变比特率和/或拥塞响应伪线，则需要BFD使用自适应拥塞控制机制运行（例如，包括“检测到拥塞”时的节流传输速率）情况，以及由于拥塞导致停机后缓慢启动，直到验证基本连接）。
Since the bandwidth utilized by BFD is configuration-limited, the VCCV channel MUST NOT be rate-limited below this maximum configurable bandwidth or BFD will not operate correctly. The VCCV channel could provide rate-limiting above the maximum BFD rate, to protect from a misbehaving BFD application, so that it does not conflict and can coexist. Additionally, the VCCV channel SHOULD NOT use any additional congestion control loop that would interfere or negatively interact with that of BFD. There are no additional congestion considerations.
由于BFD使用的带宽是配置限制的，VCCV信道的速率不得限制在该最大可配置带宽以下，否则BFD将无法正常工作。VCCV通道可以提供高于最大BFD速率的速率限制，以防止BFD应用程序出现错误行为，从而使其不会冲突并可以共存。此外，VCCV信道不应使用任何会干扰BFD拥塞控制环路或与BFD拥塞控制环路产生负面影响的额外拥塞控制环路。没有额外的拥塞考虑。
Routers that implement the additional CV Types defined herein are subject to the same security considerations as defined in [RFC5085], [RFC5880], and [RFC5881]. This specification does not raise any additional security issues beyond these. The IP/UDP-encapsulated BFD makes use of the TTL/Hop Limit procedures described in Section 5 of [RFC5881], including the use of the Generalized TTL Security Mechanism (GTSM) as a security mechanism.
实现本文定义的附加CV类型的路由器受到与[RFC5085]、[RFC5880]和[RFC5881]中定义的相同安全考虑的约束。除此之外，本规范不会提出任何其他安全问题。IP/UDP封装BFD使用[RFC5881]第5节中描述的TTL/Hop限制程序，包括使用通用TTL安全机制（GTSM）作为安全机制。
This work forks from a previous revision of the PWE3 WG document that resulted in [RFC5085], to which a number of people contributed, including Rahul Aggarwal, Peter B. Busschbach, Yuichi Ikejiri, Kenji Kumaki, Luca Martini, Monique Morrow, George Swallow, and others.
这项工作源自先前修订的PWE3工作组文件，该文件产生了[RFC5085]，许多人对此做出了贡献，包括Rahul Aggarwal、Peter B.Busschbach、Yuichi Ikejiri、Kenji Kumaki、Luca Martini、Monique Morrow、George Swallow和其他人。
Mustapha Aissaoui, Sam Aldrin, Stewart Bryant, Peter B. Busschbach, Annamaria Fulignoli, Vishwas Manral, Luca Martini, Dave McDysan, Ben Niven-Jenkins, Pankil Shah, Yaakov Stein, and George Swallow provided useful feedback and valuable comments and suggestions improving newer versions of this document.
Mustapha Aissaoui、Sam Aldrin、Stewart Bryant、Peter B.Buschbach、Annama Fulignoli、Vishwas Manral、Luca Martini、Dave McDysan、Ben Niven Jenkins、Pankil Shah、Yaakov Stein和George Swallow提供了有用的反馈和宝贵的意见和建议，以改进本文件的新版本。
[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月。
[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月。
[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月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", RFC 5880, June 2010.
[RFC5880]Katz，D.和D.Ward，“双向转发检测”，RFC 58802010年6月。
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010.
[RFC5881]Katz，D.和D.Ward，“IPv4和IPv6（单跳）的双向转发检测（BFD）”，RFC 58812010年6月。
[RFC5882] Katz, D. and D. Ward, "Generic Application of Bidirectional Forwarding Detection (BFD)", RFC 5882, June 2010.
[RFC5882]Katz，D.和D.Ward，“双向转发检测（BFD）的一般应用”，RFC 5882，2010年6月。
[IANA] Internet Assigned Numbers Authority, "Protocol Registries", <http://www.iana.org>.
[IANA]互联网分配号码管理局，“协议注册处”<http://www.iana.org>.
[OAM-MSG-MAP] Aissaoui, M., Busschbach, P., Morrow, M., Martini, L., Stein, Y., Allan, D., and T. Nadeau, "Pseudowire (PW) OAM Message Mapping", Work in Progress, March 2010.
[OAM-MSG-MAP]Aissaoui，M.，Busschbach，P.，Morrow，M.，Martini，L.，Stein，Y.，Allan，D.，和T.Nadeau，“伪线（PW）OAM消息映射”，正在进行的工作，2010年3月。
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931]Lau，J.，Townsley，M.，和I.Goyret，“第二层隧道协议-版本3（L2TPv3）”，RFC 39312005年3月。
[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月。
[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月。
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447]Martini，L.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，2006年4月。
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5586]Bocci，M.，Vigoureux，M.，和S.Bryant，“MPLS通用关联信道”，RFC 55862009年6月。
Authors' Addresses
作者地址
Thomas D. Nadeau (editor) BT BT Centre 81 Newgate Street London EC1A 7AJ United Kingdom
Thomas D.Nadeau（编辑）英国电信中心伦敦纽盖特街81号EC1A 7AJ英国电信中心
EMail: tom.nadeau@bt.com
EMail: tom.nadeau@bt.com
Carlos Pignataro (editor) Cisco Systems, Inc. 7200 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709 USA
卡洛斯·皮格纳塔罗（编辑）思科系统公司，地址：美国北卡罗来纳州三角研究公园Kit Creek路7200号邮政信箱14987，邮编：27709
EMail: cpignata@cisco.com
EMail: cpignata@cisco.com