[要約] RFC 5085は、仮想回線接続の確認を行うための制御チャネルであるVCCVに関するものです。このRFCの目的は、仮想回線の接続性を確認するための標準化された手法を提供することです。
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
Pseudowire仮想回路接続検証（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
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）タイプ[RFC3985]を介して、電気通信サービス（T1リースラインまたはフレームリレーなど）の本質的な属性をエミュレートするメカニズムを定義します。。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エミュレーションには、トラフィックに影響を与えるため、この技術の適用性を制限する不足がある場合があります。これらの制限は、適切なサービス固有のドキュメントで完全に説明する必要があります。
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がサポートする必要があるデフォルトの操作モードが1つあります。ただし、オプションのモードは、エミュレートサービスの忠実さを改善し、古い実装がこれらのサービスをサポートできる手段を提供するために定義されています。
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
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を提供し、CESがCESを通信できるようにします。PSN。プロバイダーネットワークを通過するこれらのPESの間に擬似具体が存在します。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 |---+
\ /
\ ___ ___ __ _/
\_/ \____/ \___/ \____/
Figure 2: PWE3 Protocol Stack Reference Model including the VCCV Control Channel
図2：VCCV制御チャネルを含むPWE3プロトコルスタック参照モデル
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メッセージは、機能（2つのVCCVタイプスペース、つまりVCCV制御チャネルと接続検証タイプとして表される）の後にのみ交換され、そのようなトラフィックを交換したいという欲求は、PES（セクション5.3と6.3を参照）、および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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
AC Attachment Circuit [RFC3985].
ACアタッチメント回路[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].
CWコントロールワード[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 Pseudowire [RFC3985]。
PW-ACH PW Associated Channel Header [RFC4385].
PW-ach PW関連チャネルヘッダー[RFC4385]。
VCCV Virtual Circuit Connectivity Verification.
VCCV仮想回路接続検証。
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 VCCV機能をピアPEに信号する手段、
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 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.
ラベル分布プロトコル（LDP）[RFC4447]またはレイヤー2トンネリングプロトコルバージョン3（L2TPV3）[RFC3931] [RFC3931]を使用して、擬似ワイヤが最初に信号を送られると、受信PEからメッセージが送信されます。上。このメッセージは、VCCV機能情報を含めるように拡張されています（セクション4を参照）。VCCV機能情報は、受信PEに、コントロールチャネル（CC）と接続検証（CV）の組み合わせが受信できることを示します。受信PEがPWを確立することに同意した場合、その後のシグナリングメッセージにその機能を返し、処理できるCCタイプとCVタイプを示します。このドキュメントのセクション7では、このメッセージで複数の指定が指定されている場合に選択する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を終了させるPEの間に流れます。現時点では、PESは、CCとCVタイプの組み合わせに基づいてVCCVメッセージの送信を開始できます。この目的のために、VCCVは、これらのメッセージのカプセル化を定義し、それらをPWのコントロールチャネルに属していると識別します。このカプセル化は、PEのデータプレーンを忠実にテストし、PEがこれらのVCCVメッセージをインターセプトして処理できるように、PWのデータトラフィックと同じ方法で制御チャネルを機能的に処理できるように設計されています。ACからCEに向けてデータトラフィックであるかのように転送します。このようにして、VCCV制御チャネルの最も基本的な機能は、擬似ワイヤの接続性と、擬似ワイヤのデータパスの輸送に使用されるデータプレーンを検証することです。PWデータトラフィックのオプションと必須のデータプレーンカプセルの組み合わせの数のために、VCCVは多くの制御チャネル（CC）および接続検証（CV）タイプを定義して、これらの多くをサポートするために、可能。既存の組み合わせのほとんど（必須とオプションの両方）をサポートするように設計されていますが、VCCVは、このドキュメントの後半で詳しく説明するように、各PW Demultiplexerタイプのデフォルトの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を呼び出すと、オペレーターは、さまざまなCCタイプの1つと、さまざまなCVタイプの1つの組み合わせをトリガーします。CVタイプには、MPLS PWS用のLSP Ping [RFC4379]、およびMPLSとL2TPV3 PWの両方の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タイプの使用のみをサポートします。ルーターで受け入れて送信できるVCCVパケットの特定のタイプまたはタイプは、セクション5.3および6.3で説明されているように、機能広告中に示されています。サポートされているさまざまなVCCV CVタイプは、使用中のPW Demultiplexerのコンテキストに適用される場合にのみ使用されます。たとえば、LSP Ping CVタイプは、MPLSラベルがPW Demultiplexerとして使用されている場合にのみ使用する必要があります。
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ルーターは、受信および宣伝されたタイプの選択を許可する必要があります。次に、特定のCCタイプとCVタイプは、セクション7で指定された制約とルール内で選択されます。特定のCCタイプが選択されたら（つまり、送信および受信されたVCCV CC機能の両方に一致します）、送信および返信、このCCタイプは、Pseudowireが再署名されるまで使用される唯一のものでなければなりません。さらに、これらのルールと[RFC4447]のセクション5.2で定義されている手順に基づいて、異なる機能タイプが必要な場合は、擬似ワイヤーを再署名する必要があります。[RFC4447]のセクション5.2の関連部分は次のとおりです。
Interface Parameter Sub-TLV
インターフェイスパラメーターSub-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.
「インターフェイスパラメーターSub-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タイプインジケーターフィールドは、VCCV制御チャネルで送信される可能性のある制御チャネルパケットの特定のCCまたはCVタイプまたはタイプ（つまり、1つ以上）を示すために使用される8ビットビットマスクとして定義されます。これらの値は、ビットフィールドで設定されている実際のビットに対応する数値を表します。各CCおよびCVタイプの定義は、MPLSまたはL2TPV3のいずれかのPWタイプコンテキストに依存します。
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
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
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 6 (0x40) - Reserved
Bit 7 (0x80) - Reserved
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
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）デバイスに向かって転送されません。代わりに、VCCVメッセージは、例外処理のためにPEエンドポイントで傍受されます。
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を参照）を使用する場合、VCCVメッセージを使用するためのコントロールチャネルをPW関連チャネルCW形式（[RFC4385]のセクション5を参照してください。
The PW Associated Channel for VCCV control channel traffic is defined in [RFC4385] as shown in Figure 3:
図3に示すように、VCCV制御チャネルトラフィックのPW関連チャネルは[RFC4385]で定義されています。
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に設定され、チャネルタイプはIPv4では0x0021、IPv6ペイロードでは0x0057に設定されています。
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が、0x01のCCタイプの選択に対応するLSP pingペイロードと0x02のCVタイプに対応する方法を受信する方法を示しています。
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タイプにのみ使用できることに注意してください。さらに、このCCタイプは、PW CWが「汎用PW MPLS制御ワード」形式に従う場合にのみ使用できます。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.
CCタイプ2は、PWがコントロールワードが存在するかどうかにかかわらずセットアップされているかどうかにかかわらず使用できます。
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.
CCタイプ3は、PWがコントロールワードが存在するかどうかにかかわらずセットアップされているかどうかにかかわらず使用できます。
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ラベルに直接従います。
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）または[RFC443]（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.
LSP Pingヘッダーは[RFC4379]に従って使用する必要があり、「L2 VPNエンドポイント」のサブタイプ8のサブTLVを含むターゲットFECスタックを含める必要があります。10の「FEC 128 Pseudowire」の場合、または「FEC 129 Pseudowire」の場合は11。サブTLV値は、検証するPWを示します。
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制御チャネルおよび接続検証モードまたはモードのタイプまたはタイプの兆候を可能にするために、VCCVパラメーターは、PW確立シグナリングの一部として使用されるセクション5.3.1で定義されています。PEがPWを信号し、そのPWにPW OAMを希望する場合、セクション5.3.1で定義されたメッセージを使用して、PWの確立中にこれを示す必要があります。具体的には、PEは、[RFC4446]にPWセットアップメッセージ[RFC4447]に割り当てられた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は、VCCVインターフェイスパラメーターSub-TLVフィールドにPW ID FEC TLVフィールドに適切なオプションを持つVCCVパラメーターを含めることにより、その構成されたVCCV機能またはリモートPEへの機能を示します（FEC 128（FEC 128））または、一般化されたPW ID FEC TLV（FEC 129）のインターフェイスパラメーターサブTLV。これらのオプションは、サポートする制御チャネルと接続の検証タイプを示しています。要求PEは、複数の制御チャネルオプションをサポートしていることを示している可能性があり、そうすることで、それに送信された場合、すべての指定されたタイプをサポートすることに同意します。ただし、セクション5.3.1（VCCV Capability Advertisement Sub-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.
ローカルポリシーは、特定のOAM機能をサポートし、それを示すようにPEに指示する場合があります。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で指定されているように、リモートピアで確立できる制御チャネルを理解するために返されるセットを調べる必要があります。それがサポートすることを示しました。
[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 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.
[RFC4447]は、LDP PW ID FEC（FEC 128）のインターフェイスパラメーターサブTLVフィールドとLDP一般化PW ID FEC（FEC 129）のインターフェイスパラメーターTLVを定義し、特定のPWの異なる機能を信号します。オプションのSub-TLVパラメーターは、VCCVのNone、1、またはより多くの制御チャネルおよび接続検証タイプをサポートする機能を示すために定義されています。これがVCCVパラメーターフィールドです。FEC 128を使用すると、VCCVパラメーターフィールドはインターフェイスパラメーターSub-TLVフィールドに配置されます。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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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タイプ）は、ルーターがコントロールチャネルトラフィックを受信できることをコントロールチャネルのタイプ（つまり、なし、1つ以上）を示すために使用されるビットマスクを定義します。複数の制御チャネルが指定されている場合、ルーターはどちらの制御チャネル上の制御トラフィックを受け入れることに同意します。ただし、詳細については、セクション4および7で指定されたルールを参照してください。どれもサポートされていない場合、これをピアに示すために0x00のCCタイプインジケーターを送信する必要があります。ただし、機能がない場合、PEはそのピアがVCCV CCタイプを受信できないと仮定し、OAMコントロールチャネルトラフィックを送信してはなりません。CCおよびCVタイプの定義は、PWの輸送またはアクセス回路の種類に関係なく一貫していることに注意してください。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コントロールプレーンの「ハロー」キープライブメカニズムを提供します（[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.
使用するコントロールチャネルタイプ（CCタイプ）の機能は、PEによって宣伝され、潜在的にさまざまな制御チャネルタイプのどれがサポートされているかを示します。受信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セッションの障害検出と診断のために、L2TPV3-署名の擬似擬似擬似擬似擬似擬似擬似擬似擬似擬似ワイヤでVCCVメッセージを送信します。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メッセージを携帯するには、Vビットが存在するL2固有のサブレーヤー（L2SS）が存在するようにPWを確立する必要があります。このドキュメントでは、ビット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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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セッションメッセージが続くことを示します。次の3つのビットは、受信時に送信時に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。
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]で指定されたエンコードを使用したICMPエコーパケット（ICMPV4）または[RFC4443]（ICMPv6の場合）は接続性の検証を実現します。実装は、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パケットは、VビットセットでL2SSを直接追跡します。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は、VCCV機能AVPを使用して、特定のL2TPV3セッションとその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は、リモートエンドからVCCV機能AVPを使用してVCCV機能を受け取っていない限り、L2TPV3セッションで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 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:
属性タイプ96の「VCCV機能AVP」は、VCCV機能をコントロールチャネル（CC）および接続検証（CV）タイプのBitFlagsのペアとして指定します。このAVPは、セッション設立中（ICRQ（受信コールレクエスト）、ICRP（受信 - コールリューズ）、OCRQ（発信-Call-Request）、またはOCRP（Outinovering-Call-Reply）メッセージ）中に交換されます。値フィールドには次の形式があります。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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で定義されています。このドキュメントには1つの値が定義されている値は1つだけですが、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.
0x01のCCタイプは、Vビットの存在を定義するL2固有のサブレイヤーがある場合にのみ要求できます。Vビットを定義するL2SSタイプを備えたL2固有のサブレイヤーAVPを要求せずに0x01のCCタイプが要求される場合、セッションはCall-Disconnect-Notify（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制御チャネルで送信される可能性のある制御パケットの特定のタイプまたはタイプ（つまり、1つ以上）を示すために使用されるビットマスクを定義します。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タイプが含まれる可能性があります。一致する機能のみを選択できます。複数の機能が一致する場合、1つの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.
特に、すでに指定されているように、有効なCCタイプがPE（そのカプセル化を使用して送信されるトラフィック）で使用されると、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：0001Bを最初のニブルとして制御するPWE3
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].
VCCVインターフェイスパラメーターSub-TLV CodePointは[RFC4446]で定義されています。IANAは、CCタイプとCVタイプのレジストリを作成し、維持します（VCCVパラメーターIDのビットマスク）。CCタイプとCVタイプの新しいレジストリ（それぞれセクション8.1.1および8.1.2を参照）は、[iana.pwe3-parameters]から到達可能な擬似ワイヤー名スペースに作成されています。[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 Control Channel Type description and a reference to an RFC approved by the IESG are required for any assignment from this registry.
IANAは、「MPLS VCCV制御チャネルタイプ」のレジストリを設定しました。これらは8ビットフィールドです。CCタイプの値0x01、0x02、および0x04は、このドキュメントのセクション4で指定されています。残りのビットフィールド値（0x08、0x10、0x20、0x40、および0x80）は、[RFC2434]で定義された「IETFコンセンサス」ポリシーを使用してIANAによって割り当てられます。VCCV制御チャネルタイプの説明と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
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ビットフィールドです。CVタイプ値0x01および0x02は、このドキュメントのセクション4で指定されています。残りのビットフィールド値（0x04、0x08、0x10、0x20、0x40、および0x80）は、[RFC2434]で定義された「IETFコンセンサス」ポリシーを使用してIANAによって割り当てられます。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
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-PARAMETERS]から到達可能な擬似ワイヤ名スペースの擬似ワイヤー関連チャネルタイプレジストリ[RFC4385]から以前に割り当てられた数値に依存しています。特に、IPv4ペイロードがPSEUDOWIRE関連チャネルヘッダーに従う場合は、0x21（インターネットプロトコルバージョン4）を使用する必要があります。
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によって維持されます。レイヤー2つのトンネルプロトコル「L2TP」名スペースは、[IANA.L2TP-PARAMETERS]から到達可能です。
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属性が指定されています。[RFC3438]のセクション2.2で説明されているように、IANAによって定義されました。
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ビットが含まれています。このドキュメントでは、IETFコンセンサス[RFC2434]に続いてIANAによって割り当てられたセクション6.1のデフォルトのL2固有のサブレーヤーの1つの予約ビットを定義します。
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ビットが含まれています。このドキュメントでは、IETFコンセンサス[RFC2434]に続いてIANAによって割り当てられたセクション6.1のATM固有のサブレーヤーの1つの予約ビットを定義します。
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
---------------------------------------------------
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
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
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.
VCCVが使用する帯域幅リソースは、関連するPWの帯域幅リソースと比較して最小限であることをお勧めします。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.
VCCVアプリケーション（つまり、接続検証（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トラフィックに適用する必要があります。そうすれば、1桁内にTCPと公正に競合します。VCCVの許容可能な帯域幅を決定する1つの方法は、[RFC3448]（TFRC）で説明されています。他の方法が存在します。たとえば、帯域幅またはパケットの周波数管理には、以下のいずれかを含めることができます：伝送間隔/レートの交渉、「輻輳が検出された」状況のスロットル伝送速度、輻輳によるシャットダウン後の遅いスタート、基本的な接続が検証されるまで、その他のメカニズム。
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 PWSなど）を運ぶ擬似動物の場合、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を使用するなど）または静的に構成されたシグナル（例：LDPまたはL2TPV3を使用）にできます。この制御チャネルで、VCCV接続検証（CV）メッセージが送信されます。したがって、セキュリティの観点からは、3つの異なる領域が懸念されています。
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機能のシグナル伝達に関係する攻撃に関連しています。MPLS PWコントロールプレーンのセキュリティについては、[RFC447]のセクション8.2で説明しています。L2TPV3 PWコントロールプレーンのセキュリティについては、[RFC3931]のセクション8.1で説明しています。接続検証交渉拡張の追加では、[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:
懸念の2番目の領域は、データプレーン攻撃、つまり関連するチャネル自体への攻撃に集中しています。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の1つまたはすべてをサポートできないが、それらのメッセージを十分な量で送信することができないことを暗黙的または明示的に示した場合、サービスの拒否につながる可能性があります。
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 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タイプで送信されるものなど、不要な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].
L2TPV3の場合、[RFC3931]のセクション8.2で、データパケットのスプーフィングに関する考慮事項が概説されています。L2TPV3セッションIDはトラフィックの分離を提供しますが、オプションのCookieフィールドは、スプーフィング攻撃を阻止するために追加の保護を提供します。さまざまなデータ面攻撃に対する保護を最大化するために、64ビットのCookieを使用できます。L2TPV3は、[RFC3931]のセクション4.1.3で詳述されているように、IPSECを介して実行することもできます。
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.
懸念の3番目の最後の領域は、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.
著者は、Hari Rakotoranto、Michel Khouderchah、Bertrand Duvivier、Vanson Lim、Chris Metz、W。MarkTownsley、Eric Rosen、Dan Tappan、Danny McPherson、Luca Martini、Don O'Connor、Neil Harrison、Danny Prairie、ustaphaに感謝します。Aissaoui、およびVasile Radoacaの貴重なコメントと提案。
[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.、Farinacci、D.、Li、T。、およびA. conta、「Mpls Label Stack Encoding」、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、「レイヤー2つのトンネルプロトコル - バージョン3（L2TPV3）」、RFC 3931、2005年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、「Multi-Protocol Label Switched（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、「Pseudowire Emulation Edge-to-Edge（PWE3）がMPLS PSNを介して使用するための単語」、RFC 4385、2006年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。、「Pseudowire Edge to Edge Emulation（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-parameters]インターネットに割り当てられた数字の権限、「レイヤー2トンネリングプロトコル "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-parameters]インターネットに割り当てられた数字の権限、「擬似ワイヤ名スペース」、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。、「Pseudo Wire（PW）OAM Message Mapping」、2007年3月、Work in Progress。
[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] Townsley、W。、「レイヤー2つのトンネルプロトコル（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 Friendry Rate Control（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 3916、2004年9月。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985] Bryant、S。およびP. Pate、「Pseudo Wire Emulation Edge-to-Edge（PWE3）アーキテクチャ」、RFC 3985、2005年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）のMPLのカプセル化」、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、「オペレーションと管理（OAM）要件マルチプロトコルラベルスイッチ（MPLS）ネットワーク」、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、「非同期伝達モード（ATM）層2トンネルプロトコルバージョン3（L2TPV3）」、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。300 Beaver Brook Road Boxborough、MA 01719 USA
EMail: swallow@cisco.com
Monique Morrow Cisco Systems, Inc. Glatt-com CH-8301 Glattzentrum Switzerland
Monique Morrow Cisco Systems、Inc。Glatt-Com CH-8301 Glattzentrum Switzerland
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 Communication Corporation 1-1-6、Uchisaiwai-cho、Chiyoda-ku Tokyo 100-8019 Shinjuku-ku Japan
EMail: y.ikejiri@ntt.com
Kenji Kumaki KDDI Corporation KDDI Bldg. 2-3-2 Nishishinjuku Tokyo 163-8003 JAPAN
Kenji Kumaki Kddi Corporation Kddi Bldg。2-3-2東京163-8003日本
EMail: ke-kumaki@kddi.com
Peter B. Busschbach Alcatel-Lucent 67 Whippany Road Whippany, NJ, 07981 USA
ピーター・B・バス・バッハ・アルカテル・ルーセント67ウィッパニー・ロード・ホイッパニー、ニュージャージー州、07981 USA
EMail: busschbach@alcatel-lucent.com
Rahul Aggarwal
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
USA
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 East Nichols Avenue、Suite 400 Englewood、Co、80112 USA
EMail: lmartini@cisco.com
Authors' Addresses
著者のアドレス
Thomas D. Nadeau (editor) Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA
トーマスD.ナドー（編集者）シスコシステムズ、300ビーバーブルックロードボックスボロー、マサチューセッツ州01719 USA
EMail: tnadeau@lucidvision.com
Carlos Pignataro (editor) Cisco Systems, Inc. 7200 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709 USA
Carlos Pignataro（編集者）Cisco Systems、Inc。7200 Kit Creek Road PO Box 14987 Research Triangle Park、NC 27709 USA
EMail: cpignata@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。