Network Working Group T. Nadeau, Ed.
Request for Comments: 5085 C. Pignataro, Ed.
Category: Standards Track Cisco Systems, Inc.
December 2007
Network Working Group T. Nadeau, Ed.
Request for Comments: 5085 C. Pignataro, Ed.
Category: Standards Track Cisco Systems, Inc.
December 2007
Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires
伪线虚拟电路连通性验证（VCCV）：伪线的控制通道
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This document describes Virtual Circuit Connectivity Verification (VCCV), which 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 applies to all supported access circuit and transport types currently defined for PWs.
本文档描述了虚拟电路连接验证（VCCV），它提供了与伪线（PW）相关联的控制通道，以及在该控制通道上使用的相应操作和管理功能（如连接验证）。VCCV适用于当前为PWs定义的所有受支持的接入电路和传输类型。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . . 5
2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of VCCV . . . . . . . . . . . . . . . . . . . . . . . 6
4. CC Types and CV Types . . . . . . . . . . . . . . . . . . . . 8
5. VCCV Control Channel for MPLS PWs . . . . . . . . . . . . . . 10
5.1. VCCV Control Channel Types for MPLS . . . . . . . . . . . 10
5.1.1. In-Band VCCV (Type 1) . . . . . . . . . . . . . . . . 11
5.1.2. Out-of-Band VCCV (Type 2) . . . . . . . . . . . . . . 12
5.1.3. TTL Expiry VCCV (Type 3) . . . . . . . . . . . . . . . 12
5.2. VCCV Connectivity Verification Types for MPLS . . . . . . 13
5.2.1. ICMP Ping . . . . . . . . . . . . . . . . . . . . . . 13
5.2.2. MPLS LSP Ping . . . . . . . . . . . . . . . . . . . . 13
5.3. VCCV Capability Advertisement for MPLS PWs . . . . . . . . 13
5.3.1. VCCV Capability Advertisement LDP Sub-TLV . . . . . . 14
6. VCCV Control Channel for L2TPv3/IP PWs . . . . . . . . . . . . 15
6.1. VCCV Control Channel Type for L2TPv3 . . . . . . . . . . . 16
6.2. VCCV Connectivity Verification Type for L2TPv3 . . . . . . 17
6.2.1. L2TPv3 VCCV using ICMP Ping . . . . . . . . . . . . . 17
6.3. L2TPv3 VCCV Capability Advertisement for L2TPv3 . . . . . 17
6.3.1. L2TPv3 VCCV Capability AVP . . . . . . . . . . . . . . 17
7. Capability Advertisement Selection . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8.1. VCCV Interface Parameters Sub-TLV . . . . . . . . . . . . 19
8.1.1. MPLS VCCV Control Channel (CC) Types . . . . . . . . . 19
8.1.2. MPLS VCCV Connectivity Verification (CV) Types . . . . 20
8.2. PW Associated Channel Type . . . . . . . . . . . . . . . . 21
8.3. L2TPv3 Assignments . . . . . . . . . . . . . . . . . . . . 21
8.3.1. Control Message Attribute Value Pairs (AVPs) . . . . . 21
8.3.2. Default L2-Specific Sublayer Bits . . . . . . . . . . 21
8.3.3. ATM-Specific Sublayer Bits . . . . . . . . . . . . . . 21
8.3.4. VCCV Capability AVP Values . . . . . . . . . . . . . . 22
9. Congestion Considerations . . . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . . 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . . 5
2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of VCCV . . . . . . . . . . . . . . . . . . . . . . . 6
4. CC Types and CV Types . . . . . . . . . . . . . . . . . . . . 8
5. VCCV Control Channel for MPLS PWs . . . . . . . . . . . . . . 10
5.1. VCCV Control Channel Types for MPLS . . . . . . . . . . . 10
5.1.1. In-Band VCCV (Type 1) . . . . . . . . . . . . . . . . 11
5.1.2. Out-of-Band VCCV (Type 2) . . . . . . . . . . . . . . 12
5.1.3. TTL Expiry VCCV (Type 3) . . . . . . . . . . . . . . . 12
5.2. VCCV Connectivity Verification Types for MPLS . . . . . . 13
5.2.1. ICMP Ping . . . . . . . . . . . . . . . . . . . . . . 13
5.2.2. MPLS LSP Ping . . . . . . . . . . . . . . . . . . . . 13
5.3. VCCV Capability Advertisement for MPLS PWs . . . . . . . . 13
5.3.1. VCCV Capability Advertisement LDP Sub-TLV . . . . . . 14
6. VCCV Control Channel for L2TPv3/IP PWs . . . . . . . . . . . . 15
6.1. VCCV Control Channel Type for L2TPv3 . . . . . . . . . . . 16
6.2. VCCV Connectivity Verification Type for L2TPv3 . . . . . . 17
6.2.1. L2TPv3 VCCV using ICMP Ping . . . . . . . . . . . . . 17
6.3. L2TPv3 VCCV Capability Advertisement for L2TPv3 . . . . . 17
6.3.1. L2TPv3 VCCV Capability AVP . . . . . . . . . . . . . . 17
7. Capability Advertisement Selection . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8.1. VCCV Interface Parameters Sub-TLV . . . . . . . . . . . . 19
8.1.1. MPLS VCCV Control Channel (CC) Types . . . . . . . . . 19
8.1.2. MPLS VCCV Connectivity Verification (CV) Types . . . . 20
8.2. PW Associated Channel Type . . . . . . . . . . . . . . . . 21
8.3. L2TPv3 Assignments . . . . . . . . . . . . . . . . . . . . 21
8.3.1. Control Message Attribute Value Pairs (AVPs) . . . . . 21
8.3.2. Default L2-Specific Sublayer Bits . . . . . . . . . . 21
8.3.3. ATM-Specific Sublayer Bits . . . . . . . . . . . . . . 21
8.3.4. VCCV Capability AVP Values . . . . . . . . . . . . . . 22
9. Congestion Considerations . . . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . . 26
There is a need for fault detection and diagnostic mechanisms that can be used for end-to-end fault detection and diagnostics for a Pseudowire, as a means of determining the PW's true operational state. Operators have indicated in [RFC4377] and [RFC3916] that such a tool is required for PW operation and maintenance. This document defines a protocol called Virtual Circuit Connectivity Verification (VCCV) that satisfies these requirements. VCCV is, in its simplest description, a control channel between a pseudowire's ingress and egress points over which connectivity verification messages can be sent.
需要一种故障检测和诊断机制，用于对假导线进行端到端故障检测和诊断，作为确定PW真实运行状态的手段。操作员在[RFC4377]和[RFC3916]中指出，PW操作和维护需要此类工具。本文件定义了一个称为虚拟电路连接验证（VCCV）的协议，该协议满足这些要求。在最简单的描述中，VCCV是伪线入口点和出口点之间的控制通道，通过该通道可以发送连接验证消息。
The Pseudowire Edge-to-Edge Emulation (PWE3) Working Group defines a mechanism that emulates the essential attributes of a telecommunications service (such as a T1 leased line or Frame Relay) over a variety of Packet Switched Network (PSN) types [RFC3985]. PWE3 is intended to provide only the minimum necessary functionality to emulate the service with the required degree of faithfulness for the given service definition. The required functions of PWs include encapsulating service-specific bit streams, cells, or PDUs arriving at an ingress port and carrying them across an IP path or MPLS tunnel. In some cases, it is necessary to perform other operations, such as managing their timing and order, to emulate the behavior and characteristics of the service to the required degree of faithfulness.
伪线边到边仿真（PWE3）工作组定义了一种机制，该机制通过各种分组交换网络（PSN）类型模拟电信服务（如T1专线或帧中继）的基本属性[RFC3985]。PWE3旨在仅提供最低限度的必要功能，以便以给定服务定义所需的忠实度模拟服务。PWs所需的功能包括封装到达入口端口的特定于服务的比特流、小区或PDU，并通过IP路径或MPLS隧道携带它们。在某些情况下，有必要执行其他操作，例如管理它们的时间和顺序，以模拟服务的行为和特征，达到所需的忠实程度。
From the perspective of Customer Edge (CE) devices, the PW is characterized as an unshared link or circuit of the chosen service. In some cases, there may be deficiencies in the PW emulation that impact the traffic carried over a PW and therefore limit the applicability of this technology. These limitations must be fully described in the appropriate service-specific documentation.
从客户边缘（CE）设备的角度来看，PW的特征是所选服务的非共享链路或电路。在某些情况下，PW仿真中可能存在影响通过PW的流量的缺陷，因此限制了该技术的适用性。这些限制必须在相应的特定于服务的文档中充分说明。
For each service type, there will be one default mode of operation that all PEs offering that service type must support. However, optional modes have been defined to improve the faithfulness of the emulated service, as well as to offer a means by which older implementations may support these services.
对于每种服务类型，都有一种默认操作模式，所有提供该服务类型的PEs都必须支持该模式。但是，已经定义了可选模式，以提高模拟服务的忠实性，并提供一种旧的实现可以支持这些服务的方法。
Figure 1 depicts the architecture of a pseudowire as defined in [RFC3985]. It further depicts where the VCCV control channel resides within this architecture, which will be discussed in detail shortly.
图1描述了[RFC3985]中定义的伪线的体系结构。它进一步描述了VCCV控制通道在该体系结构中的位置，稍后将对此进行详细讨论。
|<-------------- Emulated Service ---------------->|
| |<---------- VCCV ---------->| |
| |<------- Pseudowire ------->| |
| | | |
| | |<-- PSN Tunnel -->| | |
| V V V V |
V AC +----+ +----+ AC V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | | |
Customer | | Customer
Edge 1 | | Edge 2
| |
| |
Native service Native service
|<-------------- Emulated Service ---------------->|
| |<---------- VCCV ---------->| |
| |<------- Pseudowire ------->| |
| | | |
| | |<-- PSN Tunnel -->| | |
| V V V V |
V AC +----+ +----+ AC V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | | |
Customer | | Customer
Edge 1 | | Edge 2
| |
| |
Native service Native service
Figure 1: PWE3 VCCV Operation Reference Model
图1:PWE3 VCCV操作参考模型
From Figure 1, Customer Edge (CE) routers CE1 and CE2 are attached to the emulated service via Attachment Circuits (ACs), and to each of the Provider Edge (PE) routers (PE1 and PE2, respectively). An AC can be a Frame Relay Data Link Connection Identifier (DLCI), an ATM Virtual Path Identifier / Virtual Channel Identifier (VPI/VCI), an Ethernet port, etc. The PE devices provide pseudowire emulation, enabling the CEs to communicate over the PSN. A pseudowire exists between these PEs traversing the provider network. VCCV provides several means of creating a control channel over the PW, between the PE routers that attach the PW.
从图1中，客户边缘（CE）路由器CE1和CE2通过连接电路（ACs）连接到模拟服务，并连接到每个提供商边缘（PE）路由器（分别为PE1和PE2）。AC可以是帧中继数据链路连接标识符（DLCI）、ATM虚拟路径标识符/虚拟信道标识符（VPI/VCI）、以太网端口等。PE设备提供伪线仿真，使CEs能够通过PSN进行通信。通过提供商网络的这些PE之间存在伪线。VCCV提供了几种在连接PW的PE路由器之间通过PW创建控制通道的方法。
Figure 2 depicts how the VCCV control channel is associated with the pseudowire protocol stack.
图2描述了VCCV控制通道如何与伪线协议栈相关联。
+-------------+ +-------------+
| Layer2 | | Layer2 |
| Emulated | < Emulated Service > | Emulated |
| Services | | Services |
+-------------+ +-------------+
| | VCCV/PW | |
|Demultiplexer| < Control Channel > |Demultiplexer|
+-------------+ +-------------+
| PSN | < PSN Tunnel > | PSN |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
| |
| ____ ___ ____ |
| _/ \___/ \ _/ \__ |
| / \__/ \_ |
| / \ |
+--------| MPLS or IP Network |---+
\ /
\ ___ ___ __ _/
\_/ \____/ \___/ \____/
+-------------+ +-------------+
| Layer2 | | Layer2 |
| Emulated | < Emulated Service > | Emulated |
| Services | | Services |
+-------------+ +-------------+
| | VCCV/PW | |
|Demultiplexer| < Control Channel > |Demultiplexer|
+-------------+ +-------------+
| PSN | < PSN Tunnel > | PSN |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
| |
| ____ ___ ____ |
| _/ \___/ \ _/ \__ |
| / \__/ \_ |
| / \ |
+--------| MPLS or IP Network |---+
\ /
\ ___ ___ __ _/
\_/ \____/ \___/ \____/
Figure 2: PWE3 Protocol Stack Reference Model including the VCCV Control Channel
图2:PWE3协议栈参考模型，包括VCCV控制通道
VCCV messages are encapsulated using the PWE3 encapsulation as described in Sections 5 and 6, so that they are handled and processed in the same manner (or in some cases, a similar manner) as the PW PDUs for which they provide a control channel. These VCCV messages are exchanged only after the capability (expressed as two VCCV type spaces, namely the VCCV Control Channel and Connectivity Verification Types) and desire to exchange such traffic has been advertised between the PEs (see Sections 5.3 and 6.3), and VCCV types chosen.
VCCV消息使用第5节和第6节所述的PWE3封装进行封装，以便以与它们提供控制通道的PW PDU相同的方式（或在某些情况下，以类似的方式）对其进行处理和处理。这些VCCV消息仅在PEs（见第5.3节和第6.3节）和选择的VCCV类型之间公布了交换此类流量的能力（表示为两个VCCV类型空间，即VCCV控制通道和连接验证类型）和愿望后交换。
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]中所述进行解释。
AC Attachment Circuit [RFC3985].
交流连接电路[RFC3985]。
AVP Attribute Value Pair [RFC3931].
AVP属性值对[RFC3931]。
CC Control Channel (used as CC Type).
CC控制通道（用作CC类型）。
CE Customer Edge.
CE客户优势。
CV Connectivity Verification (used as CV Type).
CV连接性验证（用作CV类型）。
CW Control Word [RFC3985].
连续波控制字[RFC3985]。
L2SS L2-Specific Sublayer [RFC3931].
L2SS L2特定子层[RFC3931]。
LCCE L2TP Control Connection Endpoint [RFC3931].
LCCE L2TP控制连接端点[RFC3931]。
OAM Operation and Maintenance.
OAM操作和维护。
PE Provider Edge.
PE提供商边缘。
PSN Packet Switched Network [RFC3985].
PSN分组交换网络[RFC3985]。
PW Pseudowire [RFC3985].
PW伪线[RFC3985]。
PW-ACH PW Associated Channel Header [RFC4385].
PW-ACH PW相关信道头[RFC4385]。
VCCV Virtual Circuit Connectivity Verification.
虚拟电路连通性验证。
The goal of VCCV is to verify and further diagnose the pseudowire forwarding path. To this end, VCCV is comprised of different components:
VCCV的目标是验证和进一步诊断伪线转发路径。为此，VCCV由不同的组件组成：
o a means of signaling VCCV capabilities to a peer PE,
o 向对等PE发送VCCV能力信号的方法，
o an encapsulation for the VCCV control channel messages that allows the receiving PE to intercept, interpret, and process them locally as OAM messages, and
o VCCV控制通道消息的封装，允许接收PE截获、解释和本地处理这些消息作为OAM消息，以及
o specifications for the operation of the various VCCV operational modes transmitted within the VCCV messages.
o VCCV消息中传输的各种VCCV操作模式的操作规范。
When a pseudowire is first signaled using the Label Distribution Protocol (LDP) [RFC4447] or the Layer Two Tunneling Protocol version 3 (L2TPv3) [RFC3931], a message is sent from the initiating PE to the receiving PE requesting that a pseudowire be set up. This message has been extended to include VCCV capability information (see Section 4). The VCCV capability information indicates to the receiving PE which combinations of Control Channel (CC) and Connectivity Verification (CV) Types it is capable of receiving. If the receiving PE agrees to establish the PW, it will return its capabilities in the subsequent signaling message to indicate which CC
当首次使用标签分发协议（LDP）[RFC4447]或第二层隧道协议版本3（L2TPv3）[RFC3931]向伪线发送信号时，将从发起PE向接收PE发送一条消息，请求设置伪线。此消息已扩展为包括VCCV能力信息（见第4节）。VCCV能力信息向接收PE指示其能够接收的控制信道（CC）和连接验证（CV）类型的组合。如果接收PE同意建立PW，它将在随后的信令消息中返回其能力，以指示哪个CC
and CV Types it is capable of processing. Precedence rules for which CC and CV Type to choose in cases where more than one is specified in this message are defined in Section 7 of this document.
以及它能够处理的CV类型。本文件第7节定义了在本信息中指定了多个CC和CV类型的情况下选择的CC和CV类型的优先规则。
Once the PW is signaled, data for the PW will flow between the PEs terminating the PW. At this time, the PEs can begin transmitting VCCV messages based on the CC and CV Type combinations just discussed. To this end, VCCV defines an encapsulation for these messages that identifies them as belonging to the control channel for the PW. This encapsulation is designed to both allow the control channel to be processed functionally in the same manner as the data traffic for the PW in order to faithfully test the data plane for the PE, and allow the PE to intercept and process these VCCV messages instead of forwarding them out of the AC towards the CE as if they were data traffic. In this way, the most basic function of the VCCV control channel is to verify connectivity of the pseudowire and the data plane used to transport the data path for the pseudowire. It should be noted that because of the number of combinations of optional and mandatory data-plane encapsulations for PW data traffic, VCCV defines a number of Control Channel (CC) and Connectivity Verification (CV) types in order to support as many of these as possible. While designed to support most of the existing combinations (both mandatory and optional), VCCV does define a default CC and CV Type combination for each PW Demultiplexer type, as will be described in detail later in this document.
一旦PW发出信号，PW的数据将在终止PW的PEs之间流动。此时，PEs可以根据刚才讨论的CC和CV类型组合开始传输VCCV消息。为此，VCCV为这些消息定义了一个封装，将它们标识为属于PW的控制通道。该封装设计为既允许控制信道以与PW数据通信相同的方式进行功能处理，以便忠实地测试PE的数据平面，又允许PE截获和处理这些VCCV消息，而不是将它们从AC转发到CE，就好像它们是数据通信一样。这样，VCCV控制通道的最基本功能是验证伪线和用于传输伪线数据路径的数据平面的连接。应注意的是，由于PW数据通信的可选和强制性数据平面封装组合的数量，VCCV定义了许多控制通道（CC）和连接验证（CV）类型，以便尽可能多地支持这些类型。虽然VCCV设计用于支持大多数现有组合（强制和可选），但它确实为每种PW解复用器类型定义了默认的CC和CV类型组合，本文档稍后将对此进行详细描述。
VCCV can be used both as a fault detection and/or a diagnostic tool for pseudowires. For example, an operator can periodically invoke VCCV on a timed, on-going basis for proactive connectivity verification on an active pseudowire, or on an ad hoc or as-needed basis as a means of manual connectivity verification. When invoking VCCV, the operator triggers a combination of one of its various CC Types and one of its various CV Types. The CV Types include LSP Ping [RFC4379] for MPLS PWs, and ICMP Ping [RFC0792] [RFC4443] for both MPLS and L2TPv3 PWs. We define a matrix of acceptable CC and CV Type combinations further in this specification.
VCCV可用作假导线的故障检测和/或诊断工具。例如，运营商可以定期、持续地调用VCCV，以便在活动伪线上进行主动连接验证，或者临时或根据需要调用VCCV，作为手动连接验证的手段。调用VCCV时，运算符将触发其各种CC类型之一和各种CV类型之一的组合。CV类型包括用于MPLS PWs的LSP Ping[RFC4379]，以及用于MPLS和L2TPv3 PWs的ICMP Ping[RFC0792][RFC4443]。我们在本规范中进一步定义了可接受CC和CV类型组合的矩阵。
The control channel maintained by VCCV can additionally carry fault detection status between the endpoints of the pseudowire. Furthermore, this information can then be translated into the native OAM status codes used by the native access technologies, such as ATM, Frame-Relay or Ethernet. The specific details of such status interworking is out of the scope of this document, and is only noted here to illustrate the utility of VCCV for such purposes. Complete details can be found in [MSG-MAP] and [RFC4447].
VCCV维护的控制通道还可以在伪线端点之间传输故障检测状态。此外，该信息随后可被转换为本机接入技术（例如ATM、帧中继或以太网）所使用的本机OAM状态码。此类状态交互的具体细节不在本文件范围内，此处仅说明VCCV在此类用途中的用途。完整的详细信息可在[MSG-MAP]和[RFC4447]中找到。
The VCCV Control Channel (CC) Type defines several possible types of control channel that VCCV can support. These control channels can in turn carry several types of protocols defined by the Connectivity Verification (CV) Type. VCCV potentially supports multiple CV Types concurrently, but it only supports the use of a single CC Type. The specific type or types of VCCV packets that can be accepted and sent by a router are indicated during capability advertisement as described in Sections 5.3 and 6.3. The various VCCV CV Types supported are used only when they apply to the context of the PW demultiplexer in use. For example, the LSP Ping CV Type should only be used when MPLS Labels are utilized as PW Demultiplexer.
VCCV控制通道（CC）类型定义了VCCV可以支持的几种可能的控制通道类型。这些控制通道可以依次承载由连接性验证（CV）类型定义的几种类型的协议。VCCV可能同时支持多个CV类型，但它只支持使用单个CC类型。如第5.3节和第6.3节所述，可由路由器接受和发送的特定类型的VCCV数据包在能力公告期间予以说明。支持的各种VCCV类型仅在应用于正在使用的PW解复用器的上下文时使用。例如，仅当MPLS标签用作PW解复用器时，才应使用LSP Ping CV类型。
Once a set of VCCV capabilities is received and advertised, a CC Type and CV Type(s) that match both the received and transmitted capabilities can be selected. That is, a PE router needs to only allow Types that are both received and advertised to be selected, performing a logical AND between the received and transmitted bitflag fields. The specific CC Type and CV Type(s) are then chosen within the constraints and rules specified in Section 7. Once a specific CC Type has been chosen (i.e., it matches both the transmitted and received VCCV CC capability), transmitted and replied to, this CC Type MUST be the only one used until such time as the pseudowire is re-signaled. In addition, based on these rules and the procedures defined in Section 5.2 of [RFC4447], the pseudowire MUST be re-signaled if a different set of capabilities types is desired. The relevant portion of Section 5.2 of [RFC4447] is:
一旦接收并公布了一组VCCV能力，就可以选择与接收和传输能力相匹配的CC类型和CV类型。也就是说，PE路由器只需要允许选择接收和播发的类型，在接收和传输的位标志字段之间执行逻辑and。然后在第7节规定的约束和规则范围内选择特定CC类型和CV类型。一旦选择了特定的CC类型（即，它与发送和接收的VCCV CC能力相匹配）、发送和回复，该CC类型必须是唯一使用的CC类型，直到伪线重新发出信号为止。此外，根据这些规则和[RFC4447]第5.2节中定义的程序，如果需要一组不同的功能类型，则必须重新通知伪线。[RFC4447]第5.2节的相关部分为：
Interface Parameter Sub-TLV
接口参数子TLV
Note that as the "interface parameter sub-TLV" is part of the FEC, the rules of LDP make it impossible to change the interface parameters once the pseudowire has been set up.
注意，由于“接口参数子TLV”是FEC的一部分，LDP规则使得一旦设置了伪线，就不可能更改接口参数。
The CC and CV Type indicator fields are defined as 8-bit bitmasks used to indicate the specific CC or CV Type or Types (i.e., none, one, or more) of control channel packets that may be sent on the VCCV control channel. These values represent the numerical value corresponding to the actual bit being set in the bitfield. The definition of each CC and CV Type is dependent on the PW type context, either MPLS or L2TPv3, within which it is defined.
CC和CV类型指示符字段定义为8位位位掩码，用于指示可在VCCV控制信道上发送的控制信道分组的特定CC或CV类型（即，无、一个或多个）。这些值表示与位字段中设置的实际位相对应的数值。每个CC和CV类型的定义取决于PW类型上下文（MPLS或L2TPv3），在该上下文中定义CC和CV类型。
Control Channel (CC) Types:
控制通道（CC）类型：
The defined values for CC Types for MPLS PWs are:
MPLS PWs CC类型的定义值为：
MPLS Control Channel (CC) Types:
MPLS控制信道（CC）类型：
Bit (Value) Description
============ ==========================================
Bit 0 (0x01) - Type 1: PWE3 Control Word with 0001b as
first nibble (PW-ACH, see [RFC4385])
Bit 1 (0x02) - Type 2: MPLS Router Alert Label
Bit 2 (0x04) - Type 3: MPLS PW Label with TTL == 1
Bit 3 (0x08) - Reserved
Bit 4 (0x10) - Reserved
Bit 5 (0x20) - Reserved
Bit 6 (0x40) - Reserved
Bit 7 (0x80) - Reserved
Bit (Value) Description
============ ==========================================
Bit 0 (0x01) - Type 1: PWE3 Control Word with 0001b as
first nibble (PW-ACH, see [RFC4385])
Bit 1 (0x02) - Type 2: MPLS Router Alert Label
Bit 2 (0x04) - Type 3: MPLS PW Label with TTL == 1
Bit 3 (0x08) - Reserved
Bit 4 (0x10) - Reserved
Bit 5 (0x20) - Reserved
Bit 6 (0x40) - Reserved
Bit 7 (0x80) - Reserved
The defined values for CC Types for L2TPv3 PWs are:
L2TPv3 PWs CC类型的定义值为：
L2TPv3 Control Channel (CC) Types:
L2TPv3控制通道（CC）类型：
Bit (Value) Description
============ ==========================================
Bit 0 (0x01) - L2-Specific Sublayer with V-bit set
Bit 1 (0x02) - Reserved
Bit 2 (0x04) - Reserved
Bit 3 (0x08) - Reserved
Bit 4 (0x10) - Reserved
Bit 5 (0x20) - Reserved
Bit 6 (0x40) - Reserved
Bit 7 (0x80) - Reserved
Bit (Value) Description
============ ==========================================
Bit 0 (0x01) - L2-Specific Sublayer with V-bit set
Bit 1 (0x02) - Reserved
Bit 2 (0x04) - Reserved
Bit 3 (0x08) - Reserved
Bit 4 (0x10) - Reserved
Bit 5 (0x20) - Reserved
Bit 6 (0x40) - Reserved
Bit 7 (0x80) - Reserved
Connectivity Verification (CV) Types:
连接验证（CV）类型：
The defined values for CV Types for MPLS PWs are:
MPLS PWs CV类型的定义值为：
MPLS Connectivity Verification (CV) Types:
MPLS连接验证（CV）类型：
Bit (Value) Description
============ ==========================================
Bit 0 (0x01) - ICMP Ping
Bit 1 (0x02) - LSP Ping
Bit 2 (0x04) - Reserved
Bit 3 (0x08) - Reserved
Bit 4 (0x10) - Reserved
Bit 5 (0x20) - Reserved
Bit (Value) Description
============ ==========================================
Bit 0 (0x01) - ICMP Ping
Bit 1 (0x02) - LSP Ping
Bit 2 (0x04) - Reserved
Bit 3 (0x08) - Reserved
Bit 4 (0x10) - Reserved
Bit 5 (0x20) - Reserved
Bit 6 (0x40) - Reserved Bit 7 (0x80) - Reserved
位6（0x40）-保留位7（0x80）-保留
The defined values for CV Types for L2TPv3 PWs are:
L2TPv3 PWs CV类型的定义值为：
L2TPv3 Connectivity Verification (CV) Types:
L2TPv3连接验证（CV）类型：
Bit (Value) Description
============ ==========================================
Bit 0 (0x01) - ICMP Ping
Bit 1 (0x02) - Reserved
Bit 2 (0x04) - Reserved
Bit 3 (0x08) - Reserved
Bit 4 (0x10) - Reserved
Bit 5 (0x20) - Reserved
Bit 6 (0x40) - Reserved
Bit 7 (0x80) - Reserved
Bit (Value) Description
============ ==========================================
Bit 0 (0x01) - ICMP Ping
Bit 1 (0x02) - Reserved
Bit 2 (0x04) - Reserved
Bit 3 (0x08) - Reserved
Bit 4 (0x10) - Reserved
Bit 5 (0x20) - Reserved
Bit 6 (0x40) - Reserved
Bit 7 (0x80) - Reserved
If none of the types above are supported, the entire CC and CV Type Indicator fields SHOULD be transmitted as 0x00 (i.e., all bits in the bitfield set to 0) to indicate this to the peer.
如果上述类型均不受支持，则应将整个CC和CV类型指示符字段作为0x00（即，位字段中的所有位设置为0）传输，以向对等方指示这一点。
If no capability is signaled, then the peer MUST assume that the peer has no VCCV capability and follow the procedures specified in this document for this case.
如果未发出任何能力信号，则对等方必须假设该对等方没有VCCV能力，并遵循本文件中针对这种情况规定的程序。
When MPLS is used to transport PW packets, VCCV packets are carried over the MPLS LSP as defined in this section. In order to apply IP monitoring tools to a PW, an operator may configure VCCV as a control channel for the PW between the PE's endpoints [RFC3985]. Packets sent across this channel from the source PE towards the destination PE either as in-band traffic with the PW's data, or out-of-band. In all cases, the control channel traffic is not forwarded past the PE endpoints towards the Customer Edge (CE) devices; instead, VCCV messages are intercepted at the PE endpoints for exception processing.
当使用MPLS传输PW数据包时，VCCV数据包通过本节中定义的MPLS LSP进行传输。为了将IP监控工具应用于PW，操作员可以将VCCV配置为PE端点之间PW的控制通道[RFC3985]。通过此通道从源PE向目标PE发送的数据包，可以作为PW数据的带内通信量，也可以作为带外通信量。在所有情况下，控制信道通信量不会经过PE端点转发到客户边缘（CE）设备；相反，在PE端点截获VCCV消息以进行异常处理。
As already described in Section 4, the capability of which control channel types (CC Type) are supported is advertised by a PE. Once the receiving PE has chosen a CC Type mode to use, it MUST continue using this mode until such time as the PW is re-signaled. Thus, if a new CC Type is desired, the PW must be torn-down and re-established.
如第4节所述，支持控制信道类型（CC类型）的能力由PE公布。一旦接收PE选择使用CC类型模式，它必须继续使用该模式，直到PW重新发出信号。因此，如果需要新的CC类型，必须拆除PW并重新建立。
Ideally, such a control channel would be completely in-band (i.e., following the same data-plane faith as PW data). When a control word is present on the PW, it is possible to indicate the control channel by setting a bit in the control word header (see Section 5.1.1).
理想情况下，这样的控制信道将完全在频带内（即，遵循与PW数据相同的数据平面）。当PW上存在控制字时，可以通过在控制字标题中设置一个位来指示控制通道（见第5.1.1节）。
Section 5.1.1 through Section 5.1.3 describe each of the currently defined VCCV Control Channel Types (CC Types).
第5.1.1节至第5.1.3节描述了当前定义的每个VCCV控制通道类型（CC类型）。
CC Type 1 is also referred to as "PWE3 Control Word with 0001b as first nibble". It uses the PW Associated Channel Header (PW-ACH); see Section 5 of [RFC4385].
CC类型1也称为“第一个半字节为0001b的PWE3控制字”。它使用PW相关信道头（PW-ACH）；参见[RFC4385]第5节。
The PW set-up protocol [RFC4447] determines whether a PW uses a control word. When a control word is used, and that CW uses the "Generic PW MPLS Control Word" format (see Section 3 of [RFC4385]), a Control Channel for use of VCCV messages can be created by using the PW Associated Channel CW format (see Section 5 of [RFC4385]).
PW设置协议[RFC4447]确定PW是否使用控制字。当使用控制字且CW使用“通用PW MPLS控制字”格式（见[RFC4385]第3节）时，可通过使用PW相关通道CW格式（见[RFC4385]第5节）创建用于VCCV消息的控制通道。
The PW Associated Channel for VCCV control channel traffic is defined in [RFC4385] as shown in Figure 3:
[RFC4385]中定义了VCCV控制信道流量的PW相关信道，如图3所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: PW Associated Channel Header
图3:PW相关信道头
The first nibble is set to 0001b to indicate a channel associated with a pseudowire (see Section 5 of [RFC4385] and Section 3.6 of [RFC4446]). The Version and the Reserved fields are set to 0, and the Channel Type is set to 0x0021 for IPv4 and 0x0057 for IPv6 payloads.
第一个半字节设置为0001b，以指示与伪线相关联的信道（参见[RFC4385]第5节和[RFC4446]第3.6节）。版本和保留字段设置为0，通道类型设置为0x0021（IPv4）和0x0057（IPv6有效负载）。
For example, Figure 4 shows how the Ethernet [RFC4448] PW-ACH would be received containing an LSP Ping payload corresponding to a choice of CC Type of 0x01 and a CV Type of 0x02:
例如，图4显示了如何接收以太网[RFC4448]PW-ACH，其中包含与CC类型0x01和CV类型0x02的选择相对应的LSP Ping有效负载：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| 0x21 (IPv4) or 0x57 (IPv6) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| 0x21 (IPv4) or 0x57 (IPv6) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: PW Associated Channel Header for VCCV
图4:VCCV的PW相关信道头
It should be noted that although some PW types are not required to carry the control word, this type of VCCV can only be used for those PW types that do employ the control word when it is in use. Further, this CC Type can only be used if the PW CW follows the "Generic PW MPLS Control Word" format. This mode of VCCV operation MUST be supported when the control word is present.
需要注意的是，尽管某些PW类型不需要携带控制字，但这种类型的VCCV只能用于使用控制字的PW类型。此外，仅当PW CW遵循“通用PW MPLS控制字”格式时，才能使用此CC类型。当控制字存在时，必须支持此VCCV操作模式。
CC Type 2 is also referred to as "MPLS Router Alert Label".
CC类型2也称为“MPLS路由器警报标签”。
A VCCV control channel can alternatively be created by using the MPLS router alert label [RFC3032] immediately above the PW label. It should be noted that this approach could result in a different Equal Cost Multi-Path (ECMP) hashing behavior than pseudowire PDUs, and thus result in the VCCV control channel traffic taking a path which differs from that of the actual data traffic under test. Please see Section 2 of [RFC4928].
VCCV控制通道也可以通过使用PW标签正上方的MPLS路由器警报标签[RFC3032]创建。应该注意的是，该方法可能导致与伪线PDU不同的等成本多路径（ECMP）散列行为，从而导致VCCV控制信道通信量采用与被测实际数据通信量不同的路径。请参见[RFC4928]第2节。
CC Type 2 can be used whether the PW is set-up with a Control Word present or not.
无论PW是否设置有控制字，都可以使用CC类型2。
This is the preferred mode of VCCV operation when the Control Word is not present.
当控制字不存在时，这是VCCV操作的首选模式。
If the Control Word is in use on this PW, it MUST also be included before the VCCV message. This is done to avoid the different ECMP hashing behavior. In this case, the CW uses the PW-ACH format described in Section 5.1.1 (see Figures 3 and 4). If the Control Word is not in use on this PW, the VCCV message follows the PW Label directly.
如果此PW上正在使用控制字，则必须在VCCV消息之前包含该控制字。这样做是为了避免不同的ECMP哈希行为。在这种情况下，CW使用第5.1.1节所述的PW-ACH格式（见图3和图4）。如果此PW上未使用控制字，则VCCV消息直接跟随PW标签。
CC Type 3 is also referred to as "MPLS PW Label with TTL == 1".
CC类型3也称为“TTL==1的MPLS PW标签”。
The TTL of the PW label can be set to 1 to force the packet to be processed within the destination router's control plane. This approach could also result in a different ECMP hashing behavior and VCCV messages taking a different path than the PW data traffic.
PW标签的TTL可以设置为1，以强制在目标路由器的控制平面内处理数据包。这种方法还可能导致不同的ECMP哈希行为，并且VCCV消息采用与PW数据通信不同的路径。
CC Type 3 can be used whether the PW is set-up with a Control Word present or not.
无论PW是否设置有控制字，都可以使用CC类型3。
If the Control Word is in use on this PW, it MUST also be included before the VCCV message. This is done to avoid the different ECMP hashing behavior. In this case, the CW uses the PW-ACH format
如果此PW上正在使用控制字，则必须在VCCV消息之前包含该控制字。这样做是为了避免不同的ECMP哈希行为。在这种情况下，CW使用PW-ACH格式
described in Section 5.1.1 (see Figures 3 and 4). If the Control Word is not in use on this PW, the VCCV message follows the PW Label directly.
如第5.1.1节所述（见图3和图4）。如果此PW上未使用控制字，则VCCV消息直接跟随PW标签。
When this optional connectivity verification mode is used, an ICMP Echo packet using the encoding specified in [RFC0792] (ICMPv4) or [RFC4443] (ICMPv6) achieves connectivity verification. Implementations MUST use ICMPv4 [RFC0792] if the signaling for VCCV used IPv4 addresses, or ICMPv6 [RFC4443] if IPv6 addresses were used. If the pseudowire is set up statically, then the encoding MUST use that which was used for the pseudowire in the configuration.
使用此可选连接验证模式时，使用[RFC0792]（ICMPv4）或[RFC4443]（ICMPv6）中指定的编码的ICMP回显数据包实现连接验证。如果VCCV的信令使用IPv4地址，则实现必须使用ICMPv4[RFC0792]，如果使用IPv6地址，则实现必须使用ICMPv6[RFC4443]。如果伪线是静态设置的，则编码必须使用配置中用于伪线的编码。
The LSP Ping header MUST be used in accordance with [RFC4379] and MUST also contain the target FEC Stack containing the sub-TLV of sub-Type 8 for the "L2 VPN endpoint", 9 for "FEC 128 Pseudowire (deprecated)", 10 for "FEC 128 Pseudowire", or 11 for the "FEC 129 Pseudowire". The sub-TLV value indicates the PW to be verified.
The LSP Ping header MUST be used in accordance with [RFC4379] and MUST also contain the target FEC Stack containing the sub-TLV of sub-Type 8 for the "L2 VPN endpoint", 9 for "FEC 128 Pseudowire (deprecated)", 10 for "FEC 128 Pseudowire", or 11 for the "FEC 129 Pseudowire". The sub-TLV value indicates the PW to be verified.translate error, please retry
To permit the indication of the type or types of PW control channel(s) and connectivity verification mode or modes over a particular PW, a VCCV parameter is defined in Section 5.3.1 that is used as part of the PW establishment signaling. When a PE signals a PW and desires PW OAM for that PW, it MUST indicate this during PW establishment using the messages defined in Section 5.3.1. Specifically, the PE MUST include the VCCV interface parameter sub-TLV (0x0C) assigned in [RFC4446] in the PW set-up message [RFC4447].
为了允许指示特定PW上的PW控制信道类型和连接验证模式，第5.3.1节定义了VCCV参数，该参数用作PW建立信令的一部分。当PE发出PW信号并希望该PW具有PW OAM时，它必须在PW建立期间使用第5.3.1节中定义的消息进行指示。具体而言，PE必须包括PW设置消息[RFC4447]中[RFC4446]中分配的VCCV接口参数sub TLV（0x0C）。
The decision of the type of VCCV control channel is left completely to the receiving control entity, although the set of choices is given by the sender in that it indicates the control channels and connectivity verification type or types that it can understand. The receiver SHOULD choose a single Control Channel Type from the match between the choices sent and received, based on the capability advertisement selection specified in Section 7, and it MUST continue to use this type for the duration of the life of the control channel. Changing Control Channel Types after one has been established to be in use could potentially cause problems at the receiving end and could also lead to interoperability issues; thus, it is NOT RECOMMENDED.
VCCV控制通道类型的决定完全由接收控制实体决定，尽管发送方给出了一组选择，因为它指明了控制通道和连接验证类型，或者它可以理解的类型。接收机应根据第7节中规定的能力广告选择，从发送和接收的选择之间的匹配中选择单个控制信道类型，并且在控制信道的使用寿命期间必须继续使用该类型。在一个控制信道被确定为正在使用后，更改控制信道类型可能会在接收端造成问题，也可能导致互操作性问题；因此，不建议这样做。
When a PE sends a label mapping message for a PW, it uses the VCCV parameter to indicate the type of OAM control channels and connectivity verification type or types it is willing to receive and can send on that PW. A remote PE MUST NOT send VCCV messages before the capability of supporting the control channel(s) (and connectivity verification type(s) to be used over them) is signaled. Then, it can do so only on a control channel and using the connectivity verification type(s) from the ones indicated.
当PE发送PW的标签映射消息时，它使用VCCV参数指示OAM控制通道的类型和连接验证类型，或者它愿意在该PW上接收和可以发送的类型。在发出支持控制通道（以及通过控制通道使用的连接验证类型）的能力的信号之前，远程PE不得发送VCCV消息。然后，它只能在控制通道上执行此操作，并使用所示连接验证类型中的连接验证类型。
If a PE receives VCCV messages prior to advertising capability for this message, it MUST discard these messages and not reply to them. In this case, the PE SHOULD increment an error counter and optionally issue a system and/or SNMP notification to indicate to the system administrator that this condition exists.
如果PE在此消息的播发功能之前收到VCCV消息，则必须丢弃这些消息，而不是回复这些消息。在这种情况下，PE应增加一个错误计数器，并可选择发出系统和/或SNMP通知，以向系统管理员指示存在此情况。
When LDP is used as the PW signaling protocol, the requesting PE indicates its configured VCCV capability or capabilities to the remote PE by including the VCCV parameter with appropriate options in the VCCV interface parameter sub-TLV field of the PW ID FEC TLV (FEC 128) or in the interface parameter sub-TLV of the Generalized PW ID FEC TLV (FEC 129). These options indicate which control channel and connectivity verification types it supports. The requesting PE MAY indicate that it supports multiple control channel options, and in doing so, it agrees to support any and all indicated types if transmitted to it. However, it MUST do so in accordance with the rules stipulated in Section 5.3.1 (VCCV Capability Advertisement Sub-TLV.)
当LDP用作PW信令协议时，请求PE通过在PW ID FEC TLV（FEC 128）的VCCV接口参数sub TLV字段或通用PW ID FEC TLV的接口参数sub TLV中包括具有适当选项的VCCV参数，向远程PE指示其配置的VCCV能力（FEC 129）。这些选项指示其支持的控制通道和连接验证类型。请求PE可指示其支持多个控制通道选项，并且在这样做时，其同意支持任何和所有指示的类型（如果传输到其）。但是，其必须按照第5.3.1节规定的规则进行（VCCV能力广告子TLV）
Local policy may direct the PE to support certain OAM capability and to indicate it. The absence of the VCCV parameter indicates that no OAM functions are supported by the requesting PE, and thus the receiving PE MUST NOT send any VCCV control channel traffic to it. The reception of a VCCV parameter with no options set MUST be ignored as if one is not transmitted at all.
本地策略可能会指示PE支持某些OAM功能并指示它。缺少VCCV参数表示请求PE不支持OAM功能，因此接收PE不得向其发送任何VCCV控制信道流量。必须忽略接收未设置选项的VCCV参数，如同根本未发送一样。
The receiving PE similarly indicates its supported control channel types in the label mapping message. These may or may not be the same as the ones that were sent to it. The sender should examine the set that is returned to understand which control channels it may establish with the remote peer, as specified in Sections 4 and 7. Similarly, it MUST NOT send control channel traffic to the remote PE for which the remote PE has not indicated it supports.
接收PE同样在标签映射消息中指示其支持的控制通道类型。这些可能与发送给它的内容相同，也可能不同。按照第4节和第7节的规定，发送方应检查返回的集合，以了解它可以与远程对等方建立哪些控制通道。同样，它不得向远程PE未表示支持的远程PE发送控制信道通信量。
[RFC4447] defines an Interface Parameter Sub-TLV field in the LDP PW ID FEC (FEC 128) and an Interface Parameters TLV in the LDP Generalized PW ID FEC (FEC 129) to signal different capabilities for
[RFC4447]在LDP PW ID FEC（FEC 128）中定义接口参数Sub TLV字段，并在LDP通用PW ID FEC（FEC 129）中定义接口参数TLV，以表示不同的功能
specific PWs. An optional sub-TLV parameter is defined to indicate the capability of supporting none, one, or more control channel and connectivity verification types for VCCV. This is the VCCV parameter field. If FEC 128 is used, the VCCV parameter field is carried in the Interface Parameter sub-TLV field. If FEC 129 is used, it is carried as an Interface Parameter sub-TLV in the Interface Parameters TLV.
特定PWs。定义了可选的子TLV参数，以指示支持VCCV无、一个或多个控制通道和连接验证类型的能力。这是VCCV参数字段。如果使用FEC 128，则在接口参数子TLV字段中携带VCCV参数字段。如果使用FEC 129，则将其作为接口参数TLV中的接口参数sub TLV携带。
The VCCV parameter ID is defined as follows in [RFC4446]:
VCCV参数ID在[RFC4446]中定义如下：
Parameter ID Length Description 0x0c 4 VCCV
参数ID长度说明0x0c 4 VCCV
The format of the VCCV parameter field is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0c | 0x04 | CC Types | CV Types |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0c | 0x04 | CC Types | CV Types |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Control Channel Type field (CC Type) defines a bitmask used to indicate the type of control channel(s) (i.e., none, one, or more) that a router is capable of receiving control channel traffic on. If more than one control channel is specified, the router agrees to accept control traffic over either control channel; however, see the rules specified in Sections 4 and 7 for more details. If none of the types are supported, a CC Type Indicator of 0x00 SHOULD be transmitted to indicate this to the peer. However, if no capability is signaled, then the PE MUST assume that its peer is incapable of receiving any of the VCCV CC Types and MUST NOT send any OAM control channel traffic to it. Note that the CC and CV Types definitions are consistent regardless of the PW's transport or access circuit type. The CC and CV Type values are defined in Section 4.
控制信道类型字段（CC类型）定义了一个位掩码，用于指示路由器能够接收控制信道流量的控制信道类型（即，无、一个或多个）。如果指定了多个控制信道，则路由器同意通过任一控制信道接受控制流量；但是，有关更多详细信息，请参见第4节和第7节中规定的规则。如果不支持任何类型，则应发送0x00的CC类型指示符，以向对等方表明这一点。然而，如果没有发送任何能力信号，则PE必须假设其对等方无法接收任何VCCV CC类型，并且不得向其发送任何OAM控制信道通信量。请注意，无论PW的传输或接入电路类型如何，CC和CV类型的定义都是一致的。CC和CV类型值在第4节中定义。
When L2TPv3 is used to set up a PW over an IP PSN, VCCV packets are carried over the L2TPv3 session as defined in this section. L2TPv3 provides a "Hello" keepalive mechanism for the L2TPv3 control plane that operates in-band over IP or UDP (see Section 4.4 of [RFC3931]). This built-in Hello facility provides dead peer and path detection only for the group of sessions associated with the L2TP Control Connection. VCCV, however, allows individual L2TP sessions to be tested. This provides a more granular mechanism which can be used to troubleshoot potential problems within the data plane of L2TP endpoints themselves, or to provide additional connection status of individual pseudowires.
当L2TPv3用于通过IP PSN建立PW时，VCCV数据包将通过本节中定义的L2TPv3会话进行传输。L2TPv3为通过IP或UDP在频带内运行的L2TPv3控制平面提供“Hello”keepalive机制（参见[RFC3931]第4.4节）。此内置Hello功能仅为与L2TP控制连接关联的会话组提供死对等和路径检测。然而，VCCV允许测试单个L2TP会话。这提供了一种更细粒度的机制，可用于解决L2TP端点本身的数据平面内的潜在问题，或提供单个伪线的附加连接状态。
The capability of which Control Channel Type (CC Type) to use is advertised by a PE to indicate which of the potentially various control channel types are supported. Once the receiving PE has chosen a mode to use, it MUST continue using this mode until such time as the PW is re-signaled. Thus, if a new CC Type is desired, the PW must be torn down and re-established.
PE公布要使用的控制信道类型（CC类型）的能力，以指示支持哪些潜在的各种控制信道类型。一旦接收PE选择了要使用的模式，它必须继续使用该模式，直到PW重新发出信号。因此，如果需要新的CC类型，必须拆除PW并重新建立。
An LCCE sends VCCV messages on an L2TPv3-signaled pseudowire for fault detection and diagnostic of the L2TPv3 session. The VCCV message travels in-band with the Session and follows the exact same path as the user data for the session, because the IP header and L2TPv3 Session header are identical. The egress LCCE of the L2TPv3 session intercepts and processes the VCCV message, and verifies the signaling and forwarding state of the pseudowire on reception of the VCCV message. It is to be noted that the VCCV mechanism for L2TPv3 is primarily targeted at verifying the pseudowire forwarding and signaling state at the egress LCCE. It also helps when L2TPv3 Control Connection and Session paths are not identical.
LCCE通过L2TPv3信号伪线发送VCCV消息，用于L2TPv3会话的故障检测和诊断。VCCV消息随会话在频带内传输，并遵循与会话用户数据完全相同的路径，因为IP头和L2TPv3会话头是相同的。L2TPv3会话的出口LCCE截获并处理VCCV消息，并在接收到VCCV消息时验证伪线的信令和转发状态。应注意，L2TPv3的VCCV机制主要旨在验证出口LCCE处的伪线转发和信令状态。当L2TPv3控制连接和会话路径不相同时，它也会有所帮助。
In order to carry VCCV messages within an L2TPv3 session data packet, the PW MUST be established such that an L2-Specific Sublayer (L2SS) that defines the V-bit is present. This document defines the V-bit for the Default L2-Specific Sublayer [RFC3931] and the ATM-Specific Sublayer [RFC4454] using the Bit 0 position (see Sections 8.3.2 and 8.3.3). The L2-Specific Sublayer presence and type (either the Default or a PW-Specific L2SS) is signaled via the L2-Specific Sublayer AVP, Attribute Type 69, as defined in [RFC3931]. The V-bit within the L2-Specific Sublayer is used to identify that a VCCV message follows, and when the V-bit is set the L2SS has the format shown in Figure 5:
为了在L2TPv3会话数据包中承载VCCV消息，必须建立PW，以确保存在定义V位的L2特定子层（L2SS）。本文档使用位0位置定义默认L2特定子层[RFC3931]和ATM特定子层[RFC4454]的V位（见第8.3.2和8.3.3节）。L2特定子层的存在和类型（默认或PW特定L2SS）通过[RFC3931]中定义的L2特定子层AVP属性类型69发出信号。L2特定子层中的V位用于标识VCCV消息，当设置V位时，L2SS的格式如图5所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0 0 0|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0 0 0|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: L2-Specific Sublayer Format when the V-bit (bit 0) is set
图5：设置V位（位0）时L2特定的子层格式
The VCCV messages are distinguished from user data by the V-bit. The V-bit is set to 1, indicating that a VCCV session message follows. The next three bits MUST be set to 0 when sending and ignored upon receipt. The remaining fields comprising 28 bits (i.e., Version, Reserved, and Channel Type) follow the same definition, format, and number registry from Section 5 of [RFC4385].
VCCV消息通过V位与用户数据区分开来。V位设置为1，表示随后出现VCCV会话消息。下三位在发送时必须设置为0，在接收时忽略。包含28位（即版本、保留和通道类型）的其余字段遵循[RFC4385]第5节中相同的定义、格式和编号注册表。
The Version and Reserved fields are set to 0. For the CV Type currently defined of ICMP Ping (0x01), the Channel Type can indicate IPv4 (0x0021) or IPv6 (0x0057) (see [RFC4385]) as the VCCV payload directly following the L2SS.
版本和保留字段设置为0。对于当前定义的ICMP Ping（0x01）的CV类型，信道类型可以指示IPv4（0x0021）或IPv6（0x0057）（请参阅[RFC4385]）作为直接位于L2SS之后的VCCV有效负载。
The VCCV message over L2TPv3 directly follows the L2-Specific Sublayer with the V-bit set. It MUST contain an ICMP Echo packet as described in Section 6.2.1.
L2TPv3上的VCCV消息直接跟随具有V位集的L2特定子层。它必须包含第6.2.1节所述的ICMP回显数据包。
When this connectivity verification mode is used, an ICMP Echo packet using the encoding specified in [RFC0792] for (ICMPv4) or [RFC4443] (for ICMPv6) achieves connectivity verification. Implementations MUST use ICMPv4 [RFC0792] if the signaling for the L2TPv3 PW used IPv4 addresses, or ICMPv6 [RFC4443] if IPv6 addresses were used. If the pseudowire is set-up statically, then the encoding MUST use that which was used for the pseudowire in the configuration.
使用此连接验证模式时，使用[RFC0792]中为（ICMPv4）或[RFC4443]（为ICMPv6）指定的编码的ICMP回显数据包实现连接验证。如果L2TPv3 PW的信令使用IPv4地址，则实现必须使用ICMPv4[RFC0792]，如果使用IPv6地址，则实现必须使用ICMPv6[RFC4443]。如果伪线是静态设置的，则编码必须使用配置中用于伪线的编码。
The ICMP Ping packet directly follows the L2SS with the V-bit set. In the ICMP Echo request, the IP Header fields MUST have the following values: the destination IP address is set to the remote LCCE's IP address for the tunnel endpoint, the source IP address is set to the local LCCE's IP address for the tunnel endpoint, and the TTL or Hop Limit is set to 1.
ICMP Ping数据包直接跟随L2SS并设置V位。在ICMP回显请求中，IP头字段必须具有以下值：目标IP地址设置为隧道端点的远程LCCE IP地址，源IP地址设置为隧道端点的本地LCCE IP地址，TTL或跃点限制设置为1。
A new optional AVP is defined in Section 6.3.1 to indicate the VCCV capabilities during session establishment. An LCCE MUST signal its desire to use connectivity verification for a particular L2TPv3 session and its VCCV capabilities using the VCCV Capability AVP.
第6.3.1节定义了新的可选AVP，以指示会话建立期间的VCCV能力。LCCE必须表明其希望使用连接验证来验证特定L2TPv3会话及其使用VCCV功能AVP的VCCV功能。
An LCCE MUST NOT send VCCV packets on an L2TPv3 session unless it has received VCCV capability by means of the VCCV Capability AVP from the remote end. If an LCCE receives VCCV packets and it is not VCCV capable or it has not sent VCCV capability indication to the remote end, it MUST discard these messages. It should also increment an error counter. In this case the LCCE MAY optionally issue a system and/or SNMP notification.
LCCE不得在L2TPv3会话上发送VCCV数据包，除非它已通过VCCV能力AVP从远程端接收到VCCV能力。如果LCCE接收到VCCV数据包，但不支持VCCV，或者未向远程端发送VCCV能力指示，则必须丢弃这些消息。它还应该增加一个错误计数器。在这种情况下，LCCE可以选择发出系统和/或SNMP通知。
The "VCCV Capability AVP", Attribute Type 96, specifies the VCCV capabilities as a pair of bitflags for the Control Channel (CC) and Connectivity Verification (CV) Types. This AVP is exchanged during
属性类型96“VCCV Capability AVP”将VCCV功能指定为控制通道（CC）和连接验证（CV）类型的一对位标志。此AVP在传输过程中交换
session establishment (in ICRQ (Incoming-Call-Request), ICRP (Incoming-Call-Reply), OCRQ (Outgoing-Call-Request), or OCRP (Outgoing-Call-Reply) messages). The value field has the following format:
会话建立（在ICRQ（呼入请求）、ICRP（呼入应答）、OCRQ（呼出请求）或OCRP（呼出应答）消息中）。“值”字段的格式如下：
VCCV Capability AVP (ICRQ, ICRP, OCRQ, OCRP)
VCCV能力AVP（ICRQ、ICRP、OCRQ、OCRP）
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC Types | CV Types |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC Types | CV Types |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CC Types:
CC类型：
The Control Channel (CC) Types field defines a bitmask used to indicate the type of control channel(s) that may be used to receive OAM traffic on for the given Session. The router agrees to accept VCCV traffic at any time over any of the signaled VCCV control channel types. CC Type values are defined in Section 4. Although there is only one value defined in this document, the CC Types field is included for forward compatibility should further CC Types need to be defined in the future.
控制信道（CC）类型字段定义了一个位掩码，用于指示可用于接收给定会话上的OAM流量的控制信道类型。路由器同意在任何时间通过任何信号VCCV控制信道类型接受VCCV流量。CC类型值在第4节中定义。尽管本文档中只定义了一个值，但如果将来需要定义更多的CC类型，则包含CC类型字段是为了向前兼容。
A CC Type of 0x01 may only be requested when there is an L2- Specific Sublayer that defines the V-bit present. If a CC Type of 0x01 is requested without requesting an L2-Specific Sublayer AVP with an L2SS type that defines the V-bit, the session MUST be disconnected with a Call-Disconnect-Notify (CDN) message.
只有当存在定义V位的L2特定子层时，才能请求0x01的CC类型。如果请求的CC类型为0x01，而未请求具有定义V位的L2SS类型的L2特定子层AVP，则必须使用呼叫断开通知（CDN）消息断开会话。
If no CC Type is supported, a CC Type Indicator of 0x00 SHOULD be sent.
如果不支持CC类型，则应发送0x00的CC类型指示符。
CV Types:
CV类型：
The Connectivity Verification (CV) Types field defines a bitmask used to indicate the specific type or types (i.e., none, one, or more) of control packets that may be sent on the specified VCCV control channel. CV Type values are defined in Section 4.
连接性验证（CV）类型字段定义一个位掩码，用于指示可在指定VCCV控制通道上发送的控制数据包的特定类型（即无、一个或多个）。CV类型值在第4节中定义。
If no VCCV Capability AVP is signaled, then the LCCE MUST assume that the peer is incapable of receiving VCCV and MUST NOT send any OAM control channel traffic to it.
如果没有向VCCV能力AVP发送信号，则LCCE必须假设对等方无法接收VCCV，并且不得向其发送任何OAM控制信道流量。
All L2TP AVPs have an M (Mandatory) bit, H (Hidden) bit, Length, and Vendor ID. The Vendor ID for the VCCV Capability AVP MUST be 0, indicating that this is an IETF-defined AVP. This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 8.
所有L2TP AVP都有M（强制）位、H（隐藏）位、长度和供应商ID。VCCV能力AVP的供应商ID必须为0，表示这是IETF定义的AVP。该AVP可能被隐藏（H位可能为0或1）。此AVP的M位应设置为0。此AVP的长度（隐藏前）为8。
When a PE receives a VCCV capability advertisement, the advertisement may potentially contain more than one CC or CV Type. Only matching capabilities can be selected. When multiple capabilities match, only one CC Type MUST be used.
当PE收到VCCV能力播发时，播发可能包含多个CC或CV类型。只能选择匹配的功能。当多个功能匹配时，只能使用一种CC类型。
In particular, as already specified, once a valid CC Type is used by a PE (traffic sent using that encapsulation), the PE MUST NOT send any traffic down another CC Type control channel.
特别是，如前所述，一旦PE使用了有效的CC类型（使用该封装发送的流量），则PE不得沿另一个CC类型控制通道发送任何流量。
For cases where multiple CC Types are advertised, the following precedence rules apply when choosing the single CC Type to use:
对于播发多个CC类型的情况，在选择要使用的单个CC类型时，以下优先规则适用：
1. Type 1: PWE3 Control Word with 0001b as first nibble
1. 类型1:PWE3控制字，0001b为第一个半字节
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标签
For MPLS PWs, the CV Type of LSP Ping (0x02) is the default, and the CV Type of ICMP Ping (0x01) is optional.
对于MPLS PWs，LSP Ping（0x02）的CV类型是默认值，ICMP Ping（0x01）的CV类型是可选的。
The VCCV Interface Parameters Sub-TLV codepoint is defined in [RFC4446]. IANA has created and will maintain registries for the CC Types and CV Types (bitmasks in the VCCV Parameter ID). The CC Type and CV Type new registries (see Sections 8.1.1 and 8.1.2, respectively) have been created in the Pseudo Wires Name Spaces, reachable from [IANA.pwe3-parameters]. The allocations must be done using the "IETF Consensus" policy defined in [RFC2434].
[RFC4446]中定义了VCCV接口参数子TLV代码点。IANA已经创建并将维护CC类型和CV类型的注册表（VCCV参数ID中的位掩码）。CC类型和CV类型新注册表（分别参见第8.1.1节和第8.1.2节）已在伪导线名称空间中创建，可从[IANA.pwe3参数]访问。必须使用[RFC2434]中定义的“IETF共识”策略进行分配。
IANA has set up a registry of "MPLS VCCV Control Channel Types". These are 8 bitfields. CC Type values 0x01, 0x02, and 0x04 are specified in Section 4 of this document. The remaining bitfield values (0x08, 0x10, 0x20, 0x40, and 0x80) are to be assigned by IANA using the "IETF Consensus" policy defined in [RFC2434]. A VCCV
IANA已经建立了“MPLS VCCV控制通道类型”注册表。这是8位字段。本文件第4节规定了CC类型值0x01、0x02和0x04。剩余的位字段值（0x08、0x10、0x20、0x40和0x80）将由IANA使用[RFC2434]中定义的“IETF共识”策略分配。VCCV
Control Channel Type description and a reference to an RFC approved by the IESG are required for any assignment from this registry.
此注册表中的任何分配都需要控制通道类型说明和对IESG批准的RFC的引用。
MPLS Control Channel (CC) Types:
MPLS控制信道（CC）类型：
Bit (Value) Description
============ ==========================================
Bit 0 (0x01) - Type 1: PWE3 Control Word with 0001b as
first nibble (PW-ACH, see [RFC4385])
Bit 1 (0x02) - Type 2: MPLS Router Alert Label
Bit 2 (0x04) - Type 3: MPLS PW Label with TTL == 1
Bit 3 (0x08) - Reserved
Bit 4 (0x10) - Reserved
Bit 5 (0x20) - Reserved
Bit 6 (0x40) - Reserved
Bit 7 (0x80) - Reserved
Bit (Value) Description
============ ==========================================
Bit 0 (0x01) - Type 1: PWE3 Control Word with 0001b as
first nibble (PW-ACH, see [RFC4385])
Bit 1 (0x02) - Type 2: MPLS Router Alert Label
Bit 2 (0x04) - Type 3: MPLS PW Label with TTL == 1
Bit 3 (0x08) - Reserved
Bit 4 (0x10) - Reserved
Bit 5 (0x20) - Reserved
Bit 6 (0x40) - Reserved
Bit 7 (0x80) - Reserved
The most significant (high order) bit is labeled Bit 7, and the least significant (low order) bit is labeled Bit 0, see parenthetical "Value".
最高有效位（高阶）标记为第7位，最低有效位（低阶）标记为第0位，请参见括号中的“值”。
IANA has set up a registry of "MPLS VCCV Control Verification Types". These are 8 bitfields. CV Type values 0x01 and 0x02 are specified in Section 4 of this document. The remaining bitfield values (0x04, 0x08, 0x10, 0x20, 0x40, and 0x80) are to be assigned by IANA using the "IETF Consensus" policy defined in [RFC2434]. A VCCV Control Verification Type description and a reference to an RFC approved by the IESG are required for any assignment from this registry.
IANA已经建立了“MPLS VCCV控制验证类型”注册表。这是8位字段。本文件第4节规定了CV类型值0x01和0x02。剩余的位字段值（0x04、0x08、0x10、0x20、0x40和0x80）将由IANA使用[RFC2434]中定义的“IETF共识”策略进行分配。本登记处的任何分配都需要VCCV控制验证类型说明和IESG批准的RFC参考。
MPLS Connectivity Verification (CV) Types:
MPLS连接验证（CV）类型：
Bit (Value) Description
============ ==========================================
Bit 0 (0x01) - ICMP Ping
Bit 1 (0x02) - LSP Ping
Bit 2 (0x04) - Reserved
Bit 3 (0x08) - Reserved
Bit 4 (0x10) - Reserved
Bit 5 (0x20) - Reserved
Bit 6 (0x40) - Reserved
Bit 7 (0x80) - Reserved
Bit (Value) Description
============ ==========================================
Bit 0 (0x01) - ICMP Ping
Bit 1 (0x02) - LSP Ping
Bit 2 (0x04) - Reserved
Bit 3 (0x08) - Reserved
Bit 4 (0x10) - Reserved
Bit 5 (0x20) - Reserved
Bit 6 (0x40) - Reserved
Bit 7 (0x80) - Reserved
The most significant (high order) bit is labeled Bit 7, and the least significant (low order) bit is labeled Bit 0, see parenthetical "Value".
最高有效位（高阶）标记为第7位，最低有效位（低阶）标记为第0位，请参见括号中的“值”。
The PW Associated Channel Types used by VCCV as defined in Sections 5.1.1 and 6.1 rely on previously allocated numbers from the Pseudowire Associated Channel Types Registry [RFC4385] in the Pseudo Wires Name Spaces reachable from [IANA.pwe3-parameters]. In particular, 0x21 (Internet Protocol version 4) MUST be used whenever an IPv4 payload follows the Pseudowire Associated Channel Header, or 0x57 MUST be used when an IPv6 payload follows the Pseudowire Associated Channel Header.
第5.1.1节和第6.1节中定义的VCCV使用的PW相关信道类型依赖于可从[IANA.pwe3参数]访问的伪线名称空间中的伪线相关信道类型注册表[RFC4385]中先前分配的编号。特别是，每当IPv4有效负载跟随伪线关联的信道头时，必须使用0x21（Internet协议版本4），或者当IPv6有效负载跟随伪线关联的信道头时，必须使用0x57。
Section 8.3.1 through Section 8.3.3 are registrations of new L2TP values for registries already managed by IANA. Section 8.3.4 is a new registry that has been added to the existing L2TP name spaces, and will be maintained by IANA accordingly. The Layer Two Tunneling Protocol "L2TP" Name Spaces are reachable from [IANA.l2tp-parameters].
第8.3.1节至第8.3.3节是IANA已经管理的注册的新L2TP值的注册。第8.3.4节是一个新的注册表，已添加到现有L2TP名称空间中，并将由IANA相应地维护。第二层隧道协议“L2TP”名称空间可从[IANA.L2TP参数]访问。
An additional AVP Attribute is specified in Section 6.3.1. It was defined by IANA as described in Section 2.2 of [RFC3438].
第6.3.1节规定了附加的AVP属性。IANA在[RFC3438]第2.2节中对其进行了定义。
Attribute
Type Description
--------- ----------------------------------
96 VCCV Capability AVP
Attribute
Type Description
--------- ----------------------------------
96 VCCV Capability AVP
The Default L2-Specific Sublayer contains 8 bits in the low-order portion of the header. This document defines one reserved bit in the Default L2-Specific Sublayer in Section 6.1, which was assigned by IANA following IETF Consensus [RFC2434].
默认的L2特定子层在报头的低阶部分包含8位。本文件在第6.1节中的默认L2特定子层中定义了一个保留位，由IANA在IETF协商一致[RFC2434]后分配。
Default L2-Specific Sublayer bits - per [RFC3931]
---------------------------------
Bit 0 - V (VCCV) bit
Default L2-Specific Sublayer bits - per [RFC3931]
---------------------------------
Bit 0 - V (VCCV) bit
The ATM-Specific Sublayer contains 8 bits in the low-order portion of the header. This document defines one reserved bit in the ATM-Specific Sublayer in Section 6.1, which was assigned by IANA following IETF Consensus [RFC2434].
ATM特定子层在报头的低阶部分包含8位。本文件在第6.1节中定义了ATM特定子层中的一个保留位，该保留位由IANA根据IETF共识[RFC2434]分配。
ATM-Specific Sublayer bits - per [RFC4454]
--------------------------
Bit 0 - V (VCCV) bit
ATM-Specific Sublayer bits - per [RFC4454]
--------------------------
Bit 0 - V (VCCV) bit
This is a new registry that IANA maintains in the L2TP Name Spaces.
这是IANA在L2TP名称空间中维护的新注册表。
IANA created and maintains a registry for the CC Types and CV Types bitmasks in the VCCV Capability AVP, defined in Section 6.3.1. The allocations must be done using the "IETF Consensus" policy defined in [RFC2434]. A VCCV CC or CV Type description and a reference to an RFC approved by the IESG are required for any assignment from this registry.
IANA为第6.3.1节定义的VCCV能力AVP中的CC类型和CV类型位掩码创建并维护一个注册表。必须使用[RFC2434]中定义的“IETF共识”策略进行分配。本注册处的任何分配都需要VCCV CC或CV类型说明以及IESG批准的RFC参考。
IANA has reserved the following bits in this registry:
IANA已在此注册表中保留以下位：
VCCV Capability AVP (Attribute Type 96) Values
---------------------------------------------------
VCCV Capability AVP (Attribute Type 96) Values
---------------------------------------------------
L2TPv3 Control Channel (CC) Types:
L2TPv3控制通道（CC）类型：
Bit (Value) Description
============ ==========================================
Bit 0 (0x01) - L2-Specific Sublayer with V-bit set
Bit 1 (0x02) - Reserved
Bit 2 (0x04) - Reserved
Bit 3 (0x08) - Reserved
Bit 4 (0x10) - Reserved
Bit 5 (0x20) - Reserved
Bit 6 (0x40) - Reserved
Bit 7 (0x80) - Reserved
Bit (Value) Description
============ ==========================================
Bit 0 (0x01) - L2-Specific Sublayer with V-bit set
Bit 1 (0x02) - Reserved
Bit 2 (0x04) - Reserved
Bit 3 (0x08) - Reserved
Bit 4 (0x10) - Reserved
Bit 5 (0x20) - Reserved
Bit 6 (0x40) - Reserved
Bit 7 (0x80) - Reserved
L2TPv3 Connectivity Verification (CV) Types:
L2TPv3连接验证（CV）类型：
Bit (Value) Description
============ ==========================================
Bit 0 (0x01) - ICMP Ping
Bit 1 (0x02) - Reserved
Bit 2 (0x04) - Reserved
Bit 3 (0x08) - Reserved
Bit 4 (0x10) - Reserved
Bit 5 (0x20) - Reserved
Bit 6 (0x40) - Reserved
Bit 7 (0x80) - Reserved
Bit (Value) Description
============ ==========================================
Bit 0 (0x01) - ICMP Ping
Bit 1 (0x02) - Reserved
Bit 2 (0x04) - Reserved
Bit 3 (0x08) - Reserved
Bit 4 (0x10) - Reserved
Bit 5 (0x20) - Reserved
Bit 6 (0x40) - Reserved
Bit 7 (0x80) - Reserved
The most significant (high order) bit is labeled Bit 7, and the least significant (low order) bit is labeled Bit 0, see parenthetical "Value".
最高有效位（高阶）标记为第7位，最低有效位（低阶）标记为第0位，请参见括号中的“值”。
The bandwidth resources used by VCCV are recommended to be minimal compared to those of the associated PW. The bandwidth required for the VCCV channel is taken outside any allocation for PW data traffic, and can be configurable. When doing resource reservation or network planning, the bandwidth requirements for both PW data and VCCV traffic need to be taken into account.
与相关PW相比，建议VCCV使用的带宽资源最小。VCCV信道所需的带宽在PW数据流量的任何分配之外，并且可以配置。在进行资源预留或网络规划时，需要考虑PW数据和VCCV流量的带宽要求。
VCCV applications (i.e., Connectivity Verification (CV) Types) MUST consider congestion and bandwidth usage implications and provide details on bandwidth or packet frequency management. VCCV applications can have built-in bandwidth management in their protocols. Other VCCV applications can have their bandwidth configuration-limited, and rate-limiting them can be harmful as it could translate to incorrectly declaring connectivity failures. For all other VCCV applications, outgoing VCCV messages SHOULD be rate-limited to prevent aggressive connectivity verification consuming excessive bandwidth, causing congestion, becoming denial-of-service attacks, or generating an excessive packet rate at the CE-bound PE.
VCV应用（即连接性验证（CV）类型）必须考虑拥塞和带宽使用的影响，并提供带宽或分组频率管理的细节。VCCV应用程序可以在其协议中内置带宽管理。其他VCCV应用程序的带宽配置可能会受到限制，而速率限制可能是有害的，因为这可能会转化为不正确地声明连接故障。对于所有其他VCCV应用程序，传出VCCV消息应进行速率限制，以防止攻击性连接验证消耗过多带宽，造成拥塞，成为拒绝服务攻击，或在绑定CE的PE上生成过多的数据包速率。
If these conditions cannot be followed, an adaptive loss-based scheme SHOULD be applied to congestion-control outgoing VCCV traffic, so that it competes fairly with TCP within an order of magnitude. One method of determining an acceptable bandwidth for VCCV is described in [RFC3448] (TFRC); other methods exist. For example, bandwidth or packet frequency management can include any of the following: a negotiation of transmission interval/rate, a throttled transmission rate on "congestion detected" situations, a slow-start after shutdown due to congestion and until basic connectivity is verified, and other mechanisms.
如果不能满足这些条件，则应将基于自适应损耗的方案应用于拥塞控制传出VCCV流量，以便在一个数量级内与TCP公平竞争。[RFC3448]（TFRC）中描述了确定VCCV可接受带宽的一种方法；还有其他方法。例如，带宽或分组频率管理可以包括以下任一项：传输间隔/速率的协商、在“检测到拥塞”情况下的节流传输速率、由于拥塞而关闭后的缓慢启动以及直到验证基本连接为止，以及其他机制。
The ICMP and MPLS LSP PING applications SHOULD be rate-limited to below 5% of the bit-rate of the associated PW. For this purpose, the considered bit-rate of a pseudowire is dependent on the PW type. For pseudowires that carry constant bit-rate traffic (e.g., TDM PWs) the full bit-rate of the PW is used. For pseudowires that carry variable bit-rate traffic (e.g., Ethernet PWs), the mean or sustained bit-rate of the PW is used.
ICMP和MPLS LSP PING应用程序的速率应限制在相关PW比特率的5%以下。为此，所考虑的伪线比特率取决于PW类型。对于承载恒定比特率业务（例如，TDM PW）的伪线，使用PW的全比特率。对于承载可变比特率业务的伪线（例如，以太网PW），使用PW的平均或持续比特率。
As described in Section 10, incoming VCCV messages can be rate-limited as a protection against denial-of-service attacks. This throttling or policing of incoming VCCV messages should not be more stringent than the bandwidth allocated to the VCCV channel to prevent false indications of connectivity failure.
如第10节所述，传入的VCCV消息可以进行速率限制，以防止拒绝服务攻击。传入VCCV消息的限制或监管不应比分配给VCCV通道的带宽更严格，以防止连接故障的错误指示。
Routers that implement VCCV create a Control Channel (CC) associated with a pseudowire. This control channel can be signaled (e.g., using LDP or L2TPv3 depending on the PWE3) or statically configured. Over this control channel, VCCV Connectivity Verification (CV) messages are sent. Therefore, three different areas are of concern from a security standpoint.
实现VCCV的路由器创建与伪线关联的控制通道（CC）。该控制信道可以发信号（例如，根据PWE3使用LDP或L2TPv3）或静态配置。通过此控制通道，发送VCCV连接验证（CV）消息。因此，从安全角度来看，有三个不同的领域值得关注。
The first area of concern relates to control plane parameter and status message attacks, that is, attacks that concern the signaling of VCCV capabilities. MPLS PW Control Plane security is discussed in Section 8.2 of [RFC4447]. L2TPv3 PW Control Plane security is discussed in Section 8.1 of [RFC3931]. The addition of the connectivity verification negotiation extensions does not change the security aspects of Section 8.2 of [RFC4447], or Section 8.1 of [RFC3931]. Implementation of IP source address filters may also aid in deterring these types of attacks.
第一个关注领域涉及控制平面参数和状态消息攻击，即涉及VCCV能力信令的攻击。[RFC4447]第8.2节讨论了MPLS PW控制平面安全性。[RFC3931]第8.1节讨论了L2TPv3 PW控制平面的安全性。添加连接验证协商扩展不会改变[RFC4447]第8.2节或[RFC3931]第8.1节的安全方面。IP源地址筛选器的实现也有助于阻止这些类型的攻击。
A second area of concern centers on data-plane attacks, that is, attacks on the associated channel itself. Routers that implement the VCCV mechanisms are subject to additional data-plane denial-of-service attacks as follows:
第二个关注领域是数据平面攻击，即对相关通道本身的攻击。实施VCCV机制的路由器会受到以下额外的数据平面拒绝服务攻击：
An intruder could intercept or inject VCCV packets effectively providing false positives or false negatives.
入侵者可以截获或注入VCCV数据包，有效地提供误报或漏报。
An intruder could deliberately flood a peer router with VCCV messages to deny services to others.
入侵者可能故意向对等路由器发送VCCV消息，以拒绝向其他路由器提供服务。
A misconfigured or misbehaving device could inadvertently flood a peer router with VCCV messages which could result in denial of services. In particular, if a router has either implicitly or explicitly indicated that it cannot support one or all of the types of VCCV, but is sent those messages in sufficient quantity, it could result in a denial of service.
配置错误或行为不当的设备可能会无意中向对等路由器发送VCCV消息，从而导致拒绝服务。特别是，如果路由器隐式或显式表示它不能支持一种或所有类型的VCCV，但发送了足够数量的这些消息，则可能导致拒绝服务。
To protect against these potential (deliberate or unintentional) attacks, multiple mitigation techniques can be employed:
为防止这些潜在（故意或无意）攻击，可采用多种缓解技术：
VCCV message throttling mechanisms can be used, especially in distributed implementations which have a centralized control-plane
可以使用VCCV消息限制机制，特别是在具有集中控制平面的分布式实现中
processor with various line cards attached by some control-plane data path. In these architectures, VCCV messages may be processed on the central processor after being forwarded there by the receiving line card. In this case, the path between the line card and the control processor may become saturated if appropriate VCCV traffic throttling is not employed, which could lead to a complete denial of service to users of the particular line card. Such filtering is also useful for preventing the processing of unwanted VCCV messages, such as those which are sent on unwanted (and perhaps unadvertised) control channel types or VCCV types.
带有各种线路卡的处理器，由一些控制平面数据路径连接。在这些体系结构中，VCCV消息在被接收线路卡转发到中央处理器后，可以在中央处理器上进行处理。在这种情况下，如果未采用适当的VCCV流量限制，线路卡和控制处理器之间的路径可能会饱和，这可能导致对特定线路卡用户的完全拒绝服务。这种过滤对于防止不需要的VCCV消息的处理也很有用，例如那些在不需要的（可能是未经广告的）控制信道类型或VCCV类型上发送的消息。
Section 8.1 of [RFC4447] discusses methods to protect the data plane of MPLS PWs from data-plane attacks. However the implementation of the connectivity verification protocol expands the range of possible data-plane attacks. For this reason implementations MUST provide a method to secure the data plane. This can be in the form of encryption of the data by running IPsec on MPLS packets encapsulated according to [RFC4023], or by providing the ability to architect the MPLS network in such a way that no external MPLS packets can be injected (private MPLS network).
[RFC4447]第8.1节讨论了保护MPLS PWs数据平面免受数据平面攻击的方法。然而，连接验证协议的实施扩大了可能的数据平面攻击的范围。因此，实现必须提供保护数据平面的方法。这可以是通过在根据[RFC4023]封装的MPLS数据包上运行IPsec对数据进行加密的形式，或者通过提供构建MPLS网络的能力，使得无法注入外部MPLS数据包（专用MPLS网络）。
For L2TPv3, data packet spoofing considerations are outlined in Section 8.2 of [RFC3931]. While the L2TPv3 Session ID provides traffic separation, the optional Cookie field provides additional protection to thwart spoofing attacks. To maximize protection against a variety of data-plane attacks, a 64-bit Cookie can be used. L2TPv3 can also be run over IPsec as detailed in Section 4.1.3 of [RFC3931].
[RFC3931]第8.2节概述了L2TPv3的数据包欺骗注意事项。L2TPv3会话ID提供流量分离，而可选Cookie字段提供额外的保护以阻止欺骗攻击。为了最大限度地防止各种数据平面攻击，可以使用64位Cookie。L2TPv3也可以通过IPsec运行，详见[RFC3931]第4.1.3节。
A third and last area of concern relates to the processing of the actual contents of VCCV messages, i.e., LSP Ping and ICMP messages. Therefore, the corresponding security considerations for these protocols (LSP Ping [RFC4379], ICMPv4 Ping [RFC0792], and ICMPv6 Ping [RFC4443]) apply as well.
第三个也是最后一个关注领域涉及VCCV消息实际内容的处理，即LSP Ping和ICMP消息。因此，这些协议的相应安全注意事项（LSP Ping[RFC4379]、ICMPv4 Ping[RFC0792]和ICMPv6 Ping[RFC4443]）也适用。
The authors would like to thank Hari Rakotoranto, Michel Khouderchah, Bertrand Duvivier, Vanson Lim, Chris Metz, W. Mark Townsley, Eric Rosen, Dan Tappan, Danny McPherson, Luca Martini, Don O'Connor, Neil Harrison, Danny Prairie, Mustapha Aissaoui, and Vasile Radoaca for their valuable comments and suggestions.
作者要感谢哈里·拉科托兰托、米歇尔·考德查、伯特兰·杜维维尔、范森·林、克里斯·梅茨、W.马克·汤斯利、埃里克·罗森、丹·塔潘、丹尼·麦克弗森、卢卡·马提尼、唐·奥康纳、尼尔·哈里森、丹尼·普雷利、穆斯塔法·艾萨维和瓦西里·拉多卡，感谢他们提出的宝贵意见和建议。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[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月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[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月。
[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月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]Conta，A.，Deering，S.和M.Gupta，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年3月。
[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月。
[IANA.l2tp-parameters] Internet Assigned Numbers Authority, "Layer Two Tunneling Protocol "L2TP"", April 2007, <http://www.iana.org/assignments/l2tp-parameters>.
[IANA.l2tp参数]互联网分配号码管理局，“第二层隧道协议”l2tp“，2007年4月<http://www.iana.org/assignments/l2tp-parameters>.
[IANA.pwe3-parameters] Internet Assigned Numbers Authority, "Pseudo Wires Name Spaces", June 2007, <http://www.iana.org/assignments/pwe3-parameters>.
[IANA.pwe3参数]互联网分配号码管理局，“伪电线名称空间”，2007年6月<http://www.iana.org/assignments/pwe3-parameters>.
[MSG-MAP] Nadeau, T., "Pseudo Wire (PW) OAM Message Mapping", Work in Progress, March 2007.
[MSG-MAP]Nadeau，T.，“伪线（PW）OAM消息映射”，正在进行的工作，2007年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update", BCP 68, RFC 3438, December 2002.
[RFC3438]汤斯利，W.“第二层隧道协议（L2TP）互联网分配号码管理局（IANA）注意事项更新”，BCP 68，RFC 3438，2002年12月。
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[RFC3448]Handley，M.，Floyd，S.，Padhye，J.，和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，RFC 3448，2003年1月。
[RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004.
[RFC3916]Xiao，X.，McPherson，D.，和P.Pate，“伪线仿真边到边（PWE3）的要求”，RFC 39162004年9月。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985]Bryant，S.和P.Pate，“伪线仿真边到边（PWE3）架构”，RFC 39852005年3月。
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
[RFC4023]Worster，T.，Rekhter，Y.，和E.Rosen，“在IP或通用路由封装（GRE）中封装MPLS”，RFC 4023，2005年3月。
[RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. Matsushima, "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006.
[RFC4377]Nadeau，T.，Morrow，M.，Swallow，G.，Allan，D.，和S.Matsushima，“多协议标签交换（MPLS）网络的运营和管理（OAM）要求”，RFC 4377，2006年2月。
[RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.
[RFC4448]Martini，L.，Rosen，E.，El Aawar，N.，和G.Heron，“通过MPLS网络传输以太网的封装方法”，RFC 4448，2006年4月。
[RFC4454] Singh, S., Townsley, M., and C. Pignataro, "Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3)", RFC 4454, May 2006.
[RFC4454]Singh，S.，Townsley，M.，和C.Pignataro，“第2层隧道协议第3版（L2TPv3）上的异步传输模式（ATM）”，RFC 4454，2006年5月。
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 4928, June 2007.
[RFC4928]Swallow，G.，Bryant，S.和L.Andersson，“避免MPLS网络中的等成本多路径处理”，BCP 128，RFC 4928，2007年6月。
George Swallow Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA
George Swallow Cisco Systems，Inc.美国马萨诸塞州Boxborough市比弗布鲁克路300号，邮编01719
EMail: swallow@cisco.com
EMail: swallow@cisco.com
Monique Morrow Cisco Systems, Inc. Glatt-com CH-8301 Glattzentrum Switzerland
Monique Morrow思科系统有限公司Glatt com CH-8301瑞士Glattzentrum
EMail: mmorrow@cisco.com
EMail: mmorrow@cisco.com
Yuichi Ikejiri NTT Communication Corporation 1-1-6, Uchisaiwai-cho, Chiyoda-ku Tokyo 100-8019 Shinjuku-ku JAPAN
Yuichi Ikejiri NTT通信公司1-1-6，日本东京千代田町内石湾町100-8019新宿
EMail: y.ikejiri@ntt.com
EMail: y.ikejiri@ntt.com
Kenji Kumaki KDDI Corporation KDDI Bldg. 2-3-2 Nishishinjuku Tokyo 163-8003 JAPAN
Kenji Kumaki KDDI公司KDDI大厦2-3-2 Nishishinjuku东京163-8003日本
EMail: ke-kumaki@kddi.com
EMail: ke-kumaki@kddi.com
Peter B. Busschbach Alcatel-Lucent 67 Whippany Road Whippany, NJ, 07981 USA
Peter B.Busschbach Alcatel-Lucent美国新泽西州惠帕尼市惠帕尼路67号，邮编：07981
EMail: busschbach@alcatel-lucent.com
EMail: busschbach@alcatel-lucent.com
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 USA
Rahul Aggarwal Juniper Networks美国加利福尼亚州桑尼维尔北马蒂尔达大道1194号，邮编94089
EMail: rahul@juniper.net
EMail: rahul@juniper.net
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112 USA
Luca Martini Cisco Systems，Inc.地址：美国科罗拉多州恩格尔伍德东尼科尔斯大道9155号400室，邮编：80112
EMail: lmartini@cisco.com
EMail: lmartini@cisco.com
Authors' Addresses
作者地址
Thomas D. Nadeau (editor) Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA
Thomas D.Nadeau（编辑）思科系统公司，地址：美国马萨诸塞州Boxborough市比弗布鲁克路300号，邮编01719
EMail: tnadeau@lucidvision.com
EMail: tnadeau@lucidvision.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
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.