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)
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.
这个文件描述在VCCV（虚电路连接验证）上使用BFD的CV（连通性验证）类型。VCCV提供关联PW的控制通道，并且提供一致性操作和管理功能，比如用在控制平面上的CV。
Status of This Memo
本备忘录的状态
This is an Internet Standards Track document.
这是一个internet标准跟踪文件。
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.
更多有效信息在RFC 5741的第二部分。
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.
当前备忘录状态信息，勘误表和如何反馈，通过上述网址获得。
Copyright Notice
版权
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
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.
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.
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
- Introduction
介绍
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.
这个文件描述在VCCV（虚电路连接验证）上的使用BFD的CV（连通性验证）类型。VCCV[RFC5085]提供关联PW的控制平面，并且提供一致性操作和管理功能，比如用在控制通道上的连通性/故障验证。
|
primarily as a |
|
pseudowire fault detection mechanism |
|
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被用在VCCV控制通道上，它主要作为PW故障检测机制，用来检测数据平面失效。此外，很多BFD CV类型可以在PW端点间传递故障状态。这些状态随后可以翻译到本地OAM状态码中应用于本地接入技术，比如：ATM，Frame Relay 或者Ethernet.这些状态的协作细节不在本文件讨论范围内，提到这些细节只是为了在这里举例说明一些VCCV BFD的实用目的。这些细节可以在[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和L2TPv3 PW分配器。本文件关注BFD VCCV在单段PW（SS-PWs）上的运作。规则描述的程序只用于BFD异步模式。
- Specification of Requirements
需求项说明
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].
The reader is expected to be familiar with the terminology and abbreviations defined in [RFC5085].
- Bidirectional Forwarding Detection Connectivity Verification
双向转发检测连通性验证
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支持多种连通性验证类型，这部分定义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) | | |
| | |
| | |
| +----------------------------+--------------+-----------------------+ | ||||||
Table 1: Bitmask Values for BFD CV Types
-
- BFD CV Type Operation
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提供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).
对于静态供应的PW，两端都需要静态配置来使用相同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，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]).
BFD控制包被发送在VCCV控制通道上。由于会话标识值不可更改，使用VCCV控制通道提供的上下文环境需要绑定并引导BFD会话；伪线分配域（比如，MPLS PW标签或者L2TPv3 Session ID）提供上下文环境来区分第一个BFD控制报文，并因此伴随着单跳BFD初始化过程（见[RFC5881]第三部分和[RFC5882]第六部分）。
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.
每条PW上存在单独的BFD会话。PW的两端都采用主动方式发送Your Discriminator为0的初始BFD控制包，被接收的Your Discriminator为0的 BFD控制包被关联到绑定PW的BFD会话上。
o BFD MUST be run in asynchronous mode (see [RFC5880]).
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.
PW的BFD VCCV运作是对称的。双向PW的两端必须在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状态机的细节在[BFD5880]6.2部分。以下方案为其运行给出例子：当特定数字的时间间隔内（一个操作者提供的数字，称作”Detect Mult” 或者检测时间乘子[RFC5880]），下游PE（D-PE）没有从上游对等PE（U-PE）收到BFD控制信息，D-PE宣布PW在其接收方向down。换句话说，D-PE为这个PW进入”PW receive defect”状态。在计算的检测时间过后（见[RFC5880]6.8.4部分）D_PE宣布会话Down，并通过诊断码Control Detection Time Expired）告知远端其状态。相应的U-PE宣布PW在它的发送方向down。发送诊断码3（Neighbor signaled session dow）给D-PE。U-PE为P进入”PW transmit defect”状态。它再如何处理这个错误情况和潜在地传送状态给相连电路不在此说明书范围内。它被定义在[OAM-MSG-MAP]。
-
- BFD Encapsulation
BFD 封装
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控制包。一个BFD连接验证包有两种通过VCCV
控制通道封装的形式。本文件规定了四种BFD CV类型（见第3部分），从封装角度来看，它们可以分为两对BFD CV类型。见第三部分表1中的BFD CV类型总结。
o IP/UDP BFD Encapsulation (BFD with IP/UDP Headers)
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
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).
在这第一种方法中,BFD的VCCV封装包含定义在[RFC5881]的第4部分的IP/UDP头部.BFD控制包因此传递在UDP目的端口3784源端口49152和65535之间。用IP协议数和UDP端口数区分可能在VCCV上的负载（即，区分 ICMP Ping与定义在RFC[5085]中的LSP Ping 和BFD）。
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 or IPv6)版本必须配备用于发信令以动态建立PW的IP版本或者必须被静态提供的PW所配置。源IP地址是发送者的一个地址。目的IP地址（随机选择）是一个从127/8中随机选择的IPv4，或者从0:0:0:0:0:FFFF:7F00/104中随机选择得IPv6。基本原理在[RFC4379]的2.1部分被解释。时间活性/跳数限制和在RFC5881的第5部分中的普通TTL安全机制（GTSM）程序被应用于此封装，因此TTL/Hop Limit被设为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)
PW—ACH BFD封装 （BFD 不带IP/UDP头部）
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控制报文包(格式定义在RFC[5880]第4部分)被直接封装在VCCV控制通道（见[RFC5882]第6部分和第8部分）
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.
在这种封装中， 一个“raw（未加工）” BFD控制报文（即，一个[RFC5880]第4.1部分中定义的，不含IP/UDP头的控制包）直接跟随 PW-ACH。PW-ACH 通道类型表明关联的通道运输“raw”BFD。 PW关联通道（PWAC）定义在[RFC4385]第5部分。它的chanel type字段被用于区别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.
不同VCCV CC 类型的PW-ACH使用方法规定，对于 CC 类型1 CC类型2 CC类型3分别在RFC[5085]的5.1.1 5.1.2 5.1.3 部分，并且在所用需要用CW的情况中（见[RFC4385]第7部分）。当VCCV 运输PW-ACH 封装的BFD（即， “raw”BFD），PW-ACH（伪线 CW的或者L2SS的）的Channel而来Type必须被设置为 0x0007来表明“BFD 控制，PW-ACH-封装”（即，BFD 不带IP/UDP 头，见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 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封装，如果一个 PW关联的通道头被使用，通道类型必须被表明为IPv4（0x0021）或者IPv6（0x0057）。对于BFD的PW-ACH封装（BFD不带IP/UDP头），PW关联的通道头必须被使用而且通道类型必须被表明为BFD控制包（0x0007）。
-
- CV Types for BFD
对于BFD的CV类型
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类型被定义在一个位标域用以表明特定CV或可能被VCCV控制通道发送的VCCV包的类型（即， 没有，一个，或多个）。CV类型见下表，这些类型已定义在[RFC5085]中。括号中的值代表的数值和CV Type 位字段的真实置位情况是一致的。
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
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类型通过两种封装类型和两种功能结合，第三部分表一
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的双向性质，在选择用于动态建立PW的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类型的规则，限制和说明：
|
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].
当控制协议比如LDP[RFC4447]或者L@TPV3[RFC3931]能传送AC/PW状态到PW远端节点时，用于故障检测和状态传输的BFD CV类型（即， 0x08 0x20）不应该被使用.
更多细节可以在[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.
仅用于故障检测 的BFD CV 类型（即，CV类型0x04,0x10）无论是协议发送AC/PW状态是否可行都可以使用。这包括静态提供的和动态建立的PW。
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]).
这种情况，仅使用 BFD检查PW故障；如果它被要求运输AC/PW 故障状态，将有其他的非BFD方法被使用。比如当使用MPLS作为运输机时使用LDP状态信息(见[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).
使用CW的PW或者使用ACH的L2SS不可使用BFD CV类型 0x10 或0x20（即，不带IP/UDP头的BFD的PW-ACH 封装）。
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.
当使用PW-ACH时（在[RFC5085]的5.1.2和5.1.3中规定）PW包括CC type1、（对于MPLS和L2SS的定义在[RFC5085]的5.1.1和6.1中）和MPLS cc type2 ，CC type3（使用控制字的方式）。这种限制源自在PW-ACH中封装使用通道类型。
注：cc2和cc3可不使用控制字。
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]).
不使用PW-ACH的PW可以使用带IP/UDP的VCCVBFD封装，作为唯一的VCCV BFD 支持的封装。使用IP/UDP封装的BFD CV类型允许同时使用使用IP 头封装的其他VCCV CV类型。（例如，ICMP Ping或者定义在[RFC5085]中的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.
只用一个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.
一但一个PE已经选择一个BFD CV类型来使用，它必须继续使用它直到当PW被重置时。为了改变以协商和选择的BFD CV类型，PW必须断开并重建。
- Capability Selection
性能选择
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
选择CC和CV类型的优先规则在[RFC5085]第7部分被清楚地列出。这部分讨论了三个规则用于当本文中的BFD CV类型被支持时。使用四种定义的CV类型之外的特定BFD CV类型被绑定在多种因素下，如3.3中所描述的那样。
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中的规则，PW两端的设置被确定。如果两端有多于一个BFD CV类型，从以下列表中选择最小数字的类型使用
- 0x20 - BFD PW-ACH-encapsulated (without IP/UDP headers), for PW Fault Detection and AC/PW Fault Status Signaling
2. 0x10 - BFD PW-ACH-encapsulated (without IP/UDP headers), for PW Fault Detection only
3. 0x08 - BFD IP/UDP-encapsulated, for PW Fault Detection and AC/PW Fault Status Signaling
4. 0x04 - BFD IP/UDP-encapsulated, for PW Fault Detection only
5. IANA Considerations
5.1. MPLS CV Types for the VCCV Interface Parameters Sub-TLV
MPLS CV 类型对于VCCV的接口参数 Sub-TLV
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接口参数Sub-TLV定义在[RFC4446],VCCV CV类型注册在[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.
MPLS Connectivity Verification (CV) Types: 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
5.2. PW Associated Channel Type
PW 关联通道类型
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关联通道类型依赖于早先[RFC4385]中提供的PW关联通道类型数字，它在PW 名称空间中可以从[IANA]获得。
IANA has reserved a new Pseudowire Associated Channel Type value as follows:
IANA 已经保留了新的PW关联通道类型值
Registry:
注册：
TLV
Value Description Follows Reference
------ ---------------------------------- ------- ---------------
0x0007 BFD Control, PW-ACH encapsulation No [This document]
(without IP/UDP Headers)
5.3. L2TPv3 CV Types for the VCCV Capability AVP
VCCV性能AVP的L2TPv3 CV类型
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].
新的BFD CV类型被加到现存的被注册在L2TP名称空间的"VCCV Capability AVP"中。二层通道协议“L2TP”名称空间可以从IANA中获得。
IANA has reserved the following L2TPv3 Connectivity Verification (CV) Types in the VCCV Capability AVP Values registry.
VCCV Capability AVP (Attribute Type 96) Values
VCCV Capability AVP值
----------------------------------------------
L2TPv3 Connectivity Verification (CV) Types: 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
- Congestion Considerations
阻塞情况
The congestion considerations that apply to [RFC5085] apply to this mode of operation as well. This section describes explicitly how they apply.
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配置的最大比特率与PW关联的通道比特率相比是极小的。如果在高变化比特率或者拥塞响应PW时，PW比特率不能保证最小。BFD需要运行适当阻塞控制机制（比如阻塞检测上的节流传送，shutdown后的对于阻塞的慢启动直到基本连接被验证）。
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互相影响的阻塞控制环。这里没有附加阻塞情况。
- Security Considerations
安全情况考虑
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使用TTL/HOP限制程序,定义在[RFC5881]中，包括GTSM的使用作为安全机制。
8. Acknowledgements
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.
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.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding
Detection", RFC 5880, June 2010.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010.
[RFC5882] Katz, D. and D. Ward, "Generic Application of Bidirectional Forwarding Detection (BFD)", RFC 5882, June 2010.
9.2. Informative References
[IANA] Internet Assigned Numbers Authority, "Protocol
Registries", <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.
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to
Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[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.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009.
Authors’ Addresses
Thomas D. Nadeau (editor) BT
BT Centre
81 Newgate Street
London EC1A 7AJ
United Kingdom
Carlos Pignataro (editor) Cisco Systems, Inc.
7200 Kit Creek Road
PO Box 14987
Research Triangle Park, NC 27709
USA
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
