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
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.
この文書は、制御チャネル上で使用される疑似回線（PW）、ならびに対応する動作と、（例えば接続性検証など）管理機能に関連付けられている制御チャネルを提供する仮想回線接続検証（VCCV）を、記載されています。 VCCVは現在、PWのために定義されたすべてのサポートされているアクセス回路と輸送タイプに適用されます。
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の真の動作状態を決定する手段として、擬似回線のためのエンドツーエンドの障害検出および診断のために使用することができる障害検出および診断のメカニズムが必要です。オペレータは、このようなツールは、PWの操作およびメンテナンスに必要であること、[RFC4377]及び[RFC3916]に示されています。この文書では、これらの要件を満たす仮想回線接続性検証（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）ワーキンググループは、（例えばT1専用回線やフレームリレーのような）通信サービスの本質的な特性をエミュレートするメカニズムを定義ネットワーク（PSN）タイプ[RFC3985]をスイッチ。 PWE3は、与えられたサービス定義のために忠実の必要な程度でサービスをエミュレートするために最低限必要な機能を提供することを意図しています。 PWの必要な機能は、サービス固有のビットストリーム、細胞、または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.
各サービスタイプの場合、そのサービスの種類を提供するすべてのPEがサポートしなければならない操作の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は、PEデバイスを介して通信するためのCEを可能にする、疑似回線エミュレーションを提供するフレームリレーデータリンク接続識別子（DLCI）、ATM仮想パス識別子/仮想チャネル識別子（VPI / VCI）、イーサネットポートなどとすることができます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 |---+
\ /
\ ___ ___ __ _/
\_/ \____/ \___/ \____/
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.
セクション5および6に記載したように、彼らは同じように取り扱われ、処理されるようにVCCVメッセージは、PWE3カプセル化を使用してカプセル化された（またはいくつかの場合、同様に）、彼らは、制御チャネルを提供するためにPWのPDUとして。これらのVCCVメッセージのみPE間で宣伝されていると、このようなトラフィックを交換したい（2つのVCCVタイプのスペース、すなわちVCCV制御チャネルと接続検証タイプとして表される）の能力の後に交換され、およびVCCVタイプ（セクション5.3と6.3を参照してください）選ばれました。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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特有のSublayer [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.
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ピア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
受信PEは、傍受解釈、およびOAMメッセージとしてローカルに処理することができVCCV制御チャンネルメッセージのカプセル化、O、及び
o specifications for the operation of the various VCCV operational modes transmitted within the VCCV messages.
VCCVメッセージの中に送信される各種のVCCV動作モードの動作のためのO仕様。
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.
疑似回線は第1のラベル配布プロトコル（LDP）[RFC4447]またはレイヤ2トンネリングプロトコルバージョン3（L2TPv3の）[RFC3931]を使用して通知された場合に、メッセージが疑似回線を設定することを要求する受信PEに開始PEから送信されますアップ。このメッセージは、（セクション4を参照）VCCV能力情報を含むように拡張されています。 VCCV能力情報は、それが受信することができる制御チャネル（CC）との接続検証の組み合わせ（CV）型受信PEに示します。受信PEはPWを確立することに同意する場合、それは処理することが可能であるCCおよびCVタイプを示すために、後続のシグナリングメッセージ内にその機能を返します。複数のは、このメッセージに指定されている場合に選択するCCおよびCVタイプの優先ルールは、このドキュメントのセクション7で定義されています。
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間で流れることになります。このとき、PEはちょうど議論CCおよびCVタイプの組み合わせに基づいて、VCCVメッセージの送信を開始することができます。このため、VCCVはPWのための制御チャネルに属するものとして、それらを識別し、これらのメッセージのカプセル化を定義します。このカプセル化は、両方に設計された制御チャネルが忠実PEのデータプレーンをテストするためにPWのデータトラフィックと同じ方法で機能的に処理することを可能にし、PEは、これらのVCCVメッセージをインターセプトして処理することを可能にする代わりに彼らは、データトラフィックであるかのようにCEに向けてACからそれらを転送します。このように、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を呼び出すときに、オペレータは、そのさまざまなCCタイプの1とその様々なCVタイプの1の組み合わせをトリガします。 CVタイプは、MPLSとL2TPv3のPWを両方のためのLSP pingのMPLS PWをのために[RFC4379]、および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パケットのタイプは、機能広告中に示されています。彼らは、使用中のPWデマルチプレクサのコンテキストに適用された場合にのみサポートされるさまざまなVCCVのCVタイプが使用されています。 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受信および送信ビットフラグフィールド間を行います。特定のCCタイプが選択されたら、特定のCCタイプおよびCVタイプ（複数可）、その後、セクション7で指定された制約やルール内で選択されている（すなわち、それは、送信一致両方とVCCVの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の一部であるとして、自民党のルールは、疑似回線が設定されていたら、それは不可能インターフェイスパラメータを変更するために作ることに注意してください。
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タイプインジケータフィールドは、特定のCC又はCVタイプ又は種類VCCV制御チャンネル上で送信される制御チャネルのパケット（即ち、なし、1個、又はそれ以上）を示すために使用される8ビットのビットマスクとして定義されます。これらの値は、ビットフィールドに設定されている実際のビットに対応する数値を表しています。各CCおよびCVタイプの定義は、MPLSかが定義される範囲内のL2TPv3、いずれかPW型文脈に依存しています。
Control Channel (CC) Types:
制御チャネル（CC）タイプ：
The defined values for CC Types for MPLS PWs are:
MPLS PWを用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のPWのための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 PWを用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
ビット6（0x40の） - 予約ビット7（0x80を） - 予約
The defined values for CV Types for L2TPv3 PWs are:
L2TPv3のPWのための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タイプインジケータフィールド（すなわち、0に設定されビットフィールド内の全てのビット）は、ピアにこれを示すためには0x00として送信されるべきです。
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上に搬送されます。 PWにIP監視ツールを適用するために、オペレータは、PEのエンドポイント[RFC3985]の間のPW用の制御チャネルとしてVCCVを構成することができます。 PWのデータ、またはアウトオブバンドで帯域トラフィックとして先PEのいずれかに向かってソースPEからこのチャネルを介して送信されるパケット。全ての場合において、制御チャネルトラフィックは、顧客エッジ（CE）デバイスに向けPEエンドポイントを越えて転送されません。代わりに、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.3項による5.1.1は、現在定義されている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は、「第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制御ワード」フォーマットを使用することである場合、制御チャネルのためにPW関連するチャネルCW方式を使用して作成することができるVCCVメッセージの使用（（[RFC4385]のセクション3を参照） [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]及び[RFC4446]のセクション3.6のセクション5を参照）。バージョンと予約フィールドが0に設定され、チャネルタイプは、IPv4とIPv6のペイロードのための0x0057のために0x0021に設定されています。
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タイプおよび0×02のCVタイプの選択に対応する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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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の）、または[RFC4443]（ICMPv6の）を使用して、ICMPエコーパケットは、接続性検証を実現します。 IPv6アドレスが使用された場合VCCVのためのシグナリングは、IPv4アドレス、またはICMPv6の[RFC4443]を使用した場合の実装はICMPv4の[RFC0792]を使用しなければなりません。疑似回線が静的に設定されている場合、符号化は、構成に疑似回線のために使用したものを使用しなければなりません。
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]に従って使用する必要があり、また、「FEC 128疑似回線（非推奨）」を、「L2 VPNエンドポイント」のサブタイプ8のサブTLVを含むターゲットFECスタックを含む9なければなりません、 「FEC 128疑似」10または「FEC 129疑似」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は、VCCVインターフェイスパラメータPWセットアップメッセージ[RFC4447]の[RFC4446]に割り当てられたサブ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節で指定された能力の広告の選択に基づいて、送受信された選択肢の間の一致から、単一の制御チャネルの種類を選択する必要があり、それは、制御チャネルの生活の継続のためのこのタイプを使用し続ける必要があります。 1が使用中であることが確立された後に制御チャネルの種類を変更すると、潜在的に、受信側で問題を引き起こす可能性があり、また、相互運用性の問題につながる可能性があります。したがって、それは推奨されません。
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ラベルマッピングメッセージを送信するとき、受信すると、PWことに送ることができる喜んでOAM制御チャネルのタイプおよび接続性検証の種類またはタイプを示すために、VCCVパラメータを使用します。制御チャネル（単数または複数）（およびその上に使用する接続性検証のタイプ（複数可））をサポートする能力が通知される前に、リモート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のVCCVインターフェイスパラメータサブTLVフィールドに適切なオプションを有するVCCVパラメータを含むことにより、リモートPEに、その構成VCCV機能又は能力を示す（FEC 128 ）またはインタフェースパラメータ一般PW ID FEC TLVのサブTLV（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.
ローカルポリシーは、特定のOAM機能をサポートするために、それを示すために、PEに指示することができます。 VCCVパラメータの不在にはOAM機能が要求PEによってサポートされていないことを示し、したがって、受信PEは、それに任意のVCCV制御チャネルトラフィックを送信してはいけません。 1がまったく送信されていないかのようにオプションなしのセットで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は、同様にラベルマッピングメッセージに、サポート制御チャネルタイプを示します。これらは、またはそれに送られたものと同じであってもなくてもよいです。送信者は、リモートPEがなかったため、リモート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]は、特定のPWのために異なる能力を知らせるためにLDP PW ID FEC（FEC 128）とLDP一般PW ID FEC（FEC 129）のインタフェースパラメータTLVにインタフェースパラメータサブTLVフィールドを定義します。任意のサブTLVパラメータはいずれも、一つまたは複数の制御チャネルとVCCVの接続検証のタイプをサポートしない能力を示すために定義されています。これは、VCCVパラメータフィールドです。 FEC 128が使用される場合、VCCVパラメータフィールドは、インタフェースパラメータサブTLVフィールドで搬送されます。 FEC 129が使用される場合、それは、インターフェイスパラメータTLVのインタフェースパラメータサブTLVとして実施されます。
The VCCV parameter ID is defined as follows in [RFC4446]:
[RFC4446]に次のようにVCCVパラメータIDが定義されています。
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で指定したルールを参照してください。タイプのどれもがサポートされていない場合は、0×00のCCタイプインジケータは、ピアにこれを示すために送信されるべきである（SHOULD）。何の機能が通知されていない場合は、その後、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を参照）を提供します。これは、内蔵のハロー施設のみ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メッセージを送信します。 IPヘッダとのL2TPv3セッションヘッダが同一であるため、VCCVメッセージは、セッションにインバンド進行およびセッションのユーザデータとまったく同じ経路をたどります。 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特有のSublayer（L2SS）が存在するように確立されなければなりません。この文書では、ビット0位置を使用して、デフォルトL2特有のSublayer [RFC3931]とATM-特有のSublayer [RFC4454]のためのVビットを（セクション8.3.2および8.3.3を参照）を定義します。 [RFC3931]で定義されるようにL2特有のSublayerの存在およびタイプ（デフォルトまたはPW固有L2SSのいずれか）、L2-特有のSublayer AVP、属性タイプ69を介してシグナリングされます。 L2特有のSublayer内の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特有のSublayerフォーマット
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ビットは、VCCVセッションメッセージが続くことを示し、1に設定されています。次の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.
版と予約フィールドはICMPピングの現在定義されているCVタイプについては0に設定される（0×01）、チャネルタイプは、IPv4（0x0021）またはIPv6（0x0057）を示すことができる（[RFC4385]を参照）を直接、次のVCCVペイロードとして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特有のSublayerに従います。 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.
この接続検証モードを使用する場合、（ICMPv6のための）のために[RFC0792]で指定されたエンコーディング（ICMPv4の）、または[RFC4443]を使用して、ICMPエコーパケットは、接続性検証を実現します。 IPv6アドレスが使用された場合のL2TPv3 PWのためのシグナリングは、IPv4アドレス、またはICMPv6の[RFC4443]を使用した場合の実装はICMPv4の[RFC0792]を使用しなければなりません。疑似回線が静的アップが設定されている場合、符号化は、コンフィギュレーションで疑似回線のために使用したものを使用しなければなりません。
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.
新しいオプションのAVPは、セッション確立時のVCCV能力を示すために、6.3.1項で定義されています。 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.
それはリモートエンドからVCCVの能力AVPによってVCCV機能を受け取っていない限り、LCCEは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:
「VCCV能力AVP」、96属性タイプは、制御チャネル（CC）と接続検証（CV）タイプのビットフラグのペアとしてVCCV機能を指定します。このAVPは、（ICRQ（着信リクエスト）、ICRP（着信-返信）、OCRQ（発信・コール要求）、またはOCRP（発信-CALL-返信）メッセージで）セッション確立の間に交換されます。値フィールドの形式は次のとおりです。
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で定義されている、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タイプのみを要求することができます。 0x01でのCCタイプは、Vビットを定義L2SSタイプにL2特有のSublayer AVPを要求することなく、要求された場合、セッションは、コール切断、通知（CDN）メッセージで切断されなければなりません。
If no CC Type is supported, a CC Type Indicator of 0x00 SHOULD be sent.
何CCタイプがサポートされていない場合は、0×00の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は、これはIETF定義AVPであることを示し、0でなければなりません。この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.
具体的には、既に指定されているように、一旦有効な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タイプが宣伝されている例については、次の優先順位の規則が適用されます。
For MPLS PWs, the CV Type of LSP Ping (0x02) is the default, and the CV Type of ICMP Ping (0x01) is optional.
MPLS PWを、LSPのPing（0×02）のCVタイプのデフォルトである、およびICMPのPing（0×01）の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インターフェイスパラメータサブTLVコードポイントは、[RFC4446]で定義されています。 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ビットフィールドです。 CCタイプは0x01で、0x02の値、および0x04のは、このドキュメントのセクション4で指定されています。残りのビットフィールド値（0x08に、0x10を、0x20に、0x40の、とは0x80）が[RFC2434]で定義された "IETFコンセンサス" ポリシーを使用して、IANAによって割り当てられるべきです。 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
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パラメータ]から到達可能な擬似ワイヤの名前空間に擬似回線関連するチャネルタイプレジストリ[RFC4385]から、以前に割り当てられた番号に依存しています。 IPv4のペイロードが疑似回線関連するチャネルヘッダに続く、またはIPv6ペイロードが疑似回線関連するチャネルヘッダに続くときに0x57を使用しなければならないときはいつでも、特に、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.3項による第8.3.1項は、すでにIANAによって管理されるレジストリの新しいL2TP値の登録されています。 8.3.4項では、既存のL2TPの名前空間に追加された新しいレジストリで、それに応じてIANAによって維持されます。レイヤ2トンネリングプロトコル「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].
追加のAVP属性は、セクション6.3.1で指定されています。 [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特有のSublayerでは、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-特有のSublayerでは、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での過度なパケットレートを生成しないようにするべきである（SHOULD）。
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.
これらの条件に従うことができない場合、それは一桁以内TCPと公平に競合するように、適応的な損失に基づく方式は、輻輳制御の発信VCCVトラフィックに適用されるべきです。 VCCVの許容帯域幅を決定する1つの方法は（TFRC）[RFC3448]に記載されています。他の方法が存在します。 、送信間隔/レートの交渉は、「輻輳検出された」状況に絞られ、伝送速度、スロースタート、シャットダウン後の輻輳にしてまで、基本的な接続性が確認される：例えば、帯域幅やパケット周波数管理は、次のいずれかを含むことができ、そして他のメカニズム。
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）を作成します。この制御チャネルは、または静的に設定（例えば、LDPまたはL2TPv3のがPWE3に応じて使用して）シグナリングすることができます。この制御チャネルを介して、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.
懸念の第1の領域は、平面パラメータとステータスメッセージ攻撃、VCCV機能のシグナル伝達に関係する攻撃を制御することに関する。 MPLS PWコントロールプレーンのセキュリティは、[RFC4447]のセクション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メッセージをピアルータをあふれさせることができました。ルータがある場合は特に、暗黙的または明示的には、それが1つまたは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 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のPWのデータプレーンを保護するための方法を論じています。しかし、接続性検証プロトコルの実装が可能データプレーン攻撃の範囲を拡大します。この理由のために実装では、データ・プレーンを保護する方法を提供しなければなりません。これは、（プライベートMPLSネットワーク[RFC4023]に記載のカプセル化されたMPLSパケットにIPsecを実行して、データの暗号化の形態であっても、又は外部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は、トラフィックの分離を提供していますが、オプションのクッキーフィールドは、スプーフィング攻撃を阻止するために、追加の保護を提供します。データプレーンのさまざまな攻撃に対する保護を最大限にするために、64ビットのクッキーを使用することができます。 [RFC3931]のセクション4.1.3で説明するようにL2TPv3のも、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.
著者はハリRakotoranto、ミシェルKhouderchah、ベルトラン・デュヴィヴィエ、バンソン・リム、クリス・メッツ、W.マークTownsley、エリック・ローゼン、ダンタッパン、ダニー・マクファーソン、ルカ・マルティーニ、ドン・オコナー、ニールハリソン、ダニー・プレーリー、ムスタファに感謝したいと思います彼らの貴重なコメントや提案のためのAissaoui、およびバシレRadoaca。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792]ポステル、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、 "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]ラウ、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.ツバメ、2006年2月、RFC 4379 "を検出マルチプロトコルラベルは（MPLS）データプレーン障害をスイッチ"。
[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]ブライアント、S.、ツバメ、G.、マティーニ、L.、およびD.マクファーソン、 "MPLS PSNの上の使用のための擬似回線エミュレーションエッジツーエッジ（PWE3）制御ワード"、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]コンタ、A.、デアリング、S.、およびM.グプタ、 "インターネットプロトコルバージョン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]マティーニ、L.、BCP 116、RFC 4446、2006年4月 "エッジエミュレーションに擬似回線縁（PWE3）のためのIANAの割り当て"。
[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]、L.、ローゼン、E.、エル・Aawar、N.、スミス、T.、およびG.サギ、 "ラベル配布プロトコル（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パラメータ]インターネット割り当て番号機関、 "レイヤ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パラメータ]インターネット割り当て番号機関、「疑似ワイヤの名前空間」、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]ナドー、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] Townsley、W.、 "レイヤ2トンネリングプロトコル（L2TP）IANA（Internet Assigned Numbers Authority）の考慮事項更新"、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]ハンドレー、M.、フロイド、S.、Padhye、J.、およびJ.ウィトマー、 "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]シャオ、X.、マクファーソン、D.、およびP.パテ、 "疑似ワイヤー・エミュレーション・エッジ・ツー・エッジ（PWE3）の要件"、RFC 3916、2004年9月。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985]ブライアント、S.とP.パテ、 "疑似ワイヤーエミュレーション端から端まで（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.ローゼン、 "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]ナドー、T.、モロー、M.、ツバメ、G.、アラン、D.、およびS.松島は、RFC 4377 "操作とマルチプロトコルラベルの管理（OAM）要件（MPLS）ネットワークのスイッチ" 、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]マティーニ、L.、ローゼン、E.、エル・Aawar、N.、およびG.サギ、 "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]シン、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]ツバメ、G.、ブライアント、S.、およびL.アンダーソン、 "MPLSネットワークにおけるイコールコストマルチパス治療の回避"、BCP 128、RFC 4928、2007年6月。
Appendix A. Contributors' Addresses
付録A.貢献者のアドレス
George Swallow Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA
ジョージツバメシスコシステムズ社300ビーバーブルック・ロードボックスボロー、MA 01719 USA
EMail: swallow@cisco.com
メールアドレス：swallow@cisco.com
Monique Morrow Cisco Systems, Inc. Glatt-com CH-8301 Glattzentrum Switzerland
モニークモローシスコシステムズ、株式会社グラットコムCH-8301 Glattzentrumスイス
EMail: mmorrow@cisco.com
メールアドレス：mmorrow@cisco.com
Yuichi Ikejiri NTT Communication Corporation 1-1-6, Uchisaiwai-cho, Chiyoda-ku Tokyo 100-8019 Shinjuku-ku JAPAN
ゆいち いけじり んっｔ こっむにかちおん こｒぽらちおん １ー１ー６、 うちさいわいーちょ、 ちよだーく ときょ １００ー８０１９ しんじゅくーく じゃぱん
EMail: y.ikejiri@ntt.com
メールアドレス：y.ikejiri@ntt.com
Kenji Kumaki KDDI Corporation KDDI Bldg. 2-3-2 Nishishinjuku Tokyo 163-8003 JAPAN
けんじ くまき Ｋっぢ こｒぽらちおん Ｋっぢ Ｂｌｄｇ。 ２ー３ー２ にししんじゅく ときょ １６３ー８００３ じゃぱん
EMail: ke-kumaki@kddi.com
メールアドレス：ke-kumaki@kddi.com
Peter B. Busschbach Alcatel-Lucent 67 Whippany Road Whippany, NJ, 07981 USA
ピーターB. Busschbachアルカテル・ルーセント67ホイッパニー道路ホイッパニー、NJ、USA 07981
EMail: busschbach@alcatel-lucent.com
メールアドレス：busschbach@alcatel-lucent.com
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 USA
ラウール・アガーウォールジュニパーネットワークスの1194北マチルダアベニュー。サニーベール、CA 94089 USA
EMail: rahul@juniper.net
メールアドレス：rahul@juniper.net
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112 USA
ルカ・マティーニシスコシステムズ株式会社9155東ニコルズアベニュー、スイート400イングルウッド、CO、80112 USA
EMail: lmartini@cisco.com
メールアドレス：lmartini@cisco.com
Authors' Addresses
著者のアドレス
Thomas D. Nadeau (editor) Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA
トーマスD.ナドー（エディタ）は、Cisco Systems、Inc.の300ビーバーブルック・ロードボックスボロー、MA 01719 USA
EMail: tnadeau@lucidvision.com
メールアドレス：tnadeau@lucidvision.com
Carlos Pignataro (editor) Cisco Systems, Inc. 7200 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709 USA
カルロスPignataro（エディタ）は、Cisco Systems、Inc.の7200キットクリーク道路私書箱14987リサーチトライアングルパーク、NC 27709 USA
EMail: cpignata@cisco.com
メールアドレス：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。