Internet Engineering Task Force (IETF) L. Martini
Request for Comments: 6073 C. Metz
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 T. Nadeau
LucidVision
M. Bocci
M. Aissaoui
Alcatel-Lucent
January 2011
Segmented Pseudowire
Abstract
抽象
This document describes how to connect pseudowires (PWs) between different Packet Switched Network (PSN) domains or between two or more distinct PW control plane domains, where a control plane domain uses a common control plane protocol or instance of that protocol for a given PW. The different PW control plane domains may belong to independent autonomous systems, or the PSN technology is heterogeneous, or a PW might need to be aggregated at a specific PSN point. The PW packet data units are simply switched from one PW to another without changing the PW payload.
この文書では、異なるパケット交換ネットワーク（PSN）ドメイン間、または制御プレーンドメインが所与PWのためにそのプロトコルの共通の制御プレーンプロトコルまたはインスタンスを使用して2つ以上の異なるPW制御プレーンドメイン間の疑似回線（のPW）を接続する方法について説明します。異なるPW制御プレーンドメインは、独立した自律システムに属していてもよい、またはPSN技術が不均一である、またはPWは、特定のPSN点に集約する必要があるかもしれません。 PWパケットデータユニットは、単に、PWペイロードを変更することなく、別のPWから切り替えられます。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6073.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6073で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................4
2. Specification of Requirements ...................................5
3. Terminology .....................................................5
4. General Description .............................................6
5. PW Switching and Attachment Circuit Type ........................9
6. Applicability ...................................................9
7. MPLS-PW to MPLS-PW Switching ...................................10
7.1. Static Control Plane Switching ............................10
7.2. Two LDP Control Planes Using the Same FEC Type ............11
7.2.1. FEC 129 Active/Passive T-PE Election Procedure .....11
7.3. LDP Using FEC 128 to LDP Using the Generalized FEC 129 ....12
7.4. LDP SP-PE TLV .............................................12
7.4.1. PW Switching Point PE Sub-TLVs .....................14
7.4.2. Adaptation of Interface Parameters .................15
7.5. Group ID ..................................................16
7.6. PW Loop Detection .........................................16
8. MPLS-PW to L2TPv3-PW Control Plane Switching ...................16
8.1. Static MPLS and L2TPv3 PWs ................................17
8.2. Static MPLS PW and Dynamic L2TPv3 PW ......................17
8.3. Static L2TPv3 PW and Dynamic LDP/MPLS PW ..................17
8.4. Dynamic LDP/MPLS and L2TPv3 PWs ...........................17
8.4.1. Session Establishment ..............................18
8.4.2. Adaptation of PW Status message ....................18
8.4.3. Session Tear Down ..................................18
8.5. Adaptation of L2TPv3 AVPs to Interface Parameters .........19
8.6. Switching Point TLV in L2TPv3 .............................20
8.7. L2TPv3 and MPLS PW Data Plane .............................20
8.7.1. Mapping the MPLS Control Word to L2TP ..............21
9. Operations, Administration, and Maintenance (OAM) ..............22
9.1. Extensions to VCCV to Support MS-PWs ......................22
9.2. OAM from MPLS PW to L2TPv3 PW .............................22
9.3. OAM Data Plane Indication from MPLS PW to MPLS PW .........22
9.4. Signaling OAM Capabilities for Switched Pseudowires .......23
9.5. OAM Capability for MS-PWs Demultiplexed Using MPLS ........23
9.5.1. MS-PW and VCCV CC Type 1 ...........................24
9.5.2. MS-PW and VCCV CC Type 2 ...........................24
9.5.3. MS-PW and VCCV CC Type 3 ...........................24
9.6. MS-PW VCCV Operations .....................................24
9.6.1. VCCV Echo Message Processing .......................25
9.6.2. Detailed VCCV Procedures ...........................27
10. Mapping Switched Pseudowire Status ............................31
10.1. PW Status Messages Initiated by the S-PE .................32
10.1.1. Local PW2 Transmit Direction Fault ................33
10.1.2. Local PW1 Transmit Direction Fault ................34
10.1.3. Local PW2 Receive Direction Fault .................34
10.1.4. Local PW1 Receive Direction Fault .................34
10.1.5. Clearing Faults ...................................34
10.2. PW Status Messages and SP-PE TLV Processing ..............35
10.3. T-PE Processing of PW Status Messages ....................35
10.4. Pseudowire Status Negotiation Procedures .................35
10.5. Status Dampening .........................................35
11. Peering between Autonomous Systems ............................35
12. Congestion Considerations .....................................36
13. Security Considerations .......................................36
13.1. Data Plane Security ......................................36
13.1.1. VCCV Security Considerations ......................36
13.2. Control Protocol Security ................................37
14. IANA Considerations ...........................................38
14.1. L2TPv3 AVP ...............................................38
14.2. LDP TLV TYPE .............................................38
14.3. LDP Status Codes .........................................38
14.4. L2TPv3 Result Codes ......................................38
14.5. New IANA Registries ......................................39
15. Normative References ..........................................39
16. Informative References ........................................40
17. Acknowledgments ...............................................42
18. Contributors ..................................................42
The PWE3 Architecture [RFC3985] defines the signaling and encapsulation techniques for establishing Single-Segment Pseudowires (SS-PWs) between a pair of terminating PEs. Multi-Segment Pseudowires (MS-PWs) are most useful in two general cases:
PWE3アーキテクチャ[RFC3985]はのPEを終了する一対の単一セグメント疑似回線（SS-のPW）を確立するためのシグナリングおよびカプセル化技術を定義しています。マルチセグメント疑似回線（MS-のPW）は、二つの一般的なケースにおいて最も有用です。
-i. In some cases it is not possible, desirable, or feasible to
establish a PW control channel between the terminating source
and destination PEs. At a minimum, PW control channel
establishment requires knowledge of and reachability to the
remote (terminating) PE IP address. The local (terminating)
PE may not have access to this information because of
topology, operational, or security constraints.
An example is the inter-AS L2VPN scenario where the
terminating PEs reside in different provider networks (ASes)
and it is the practice to cryptographically sign all control
traffic exchanged between two networks. Technically, an
SS-PW could be used but this would require cryptographic
signatures on ALL terminating source and destination PE
nodes. An MS-PW allows the providers to confine key
administration to just the PW switching points connecting the
two domains.
A second example might involve a single AS where the PW setup path between the terminating PEs is computed by an external entity. Assume that a full mesh of PWE3 control channels is established between PE-A, PE-B, and PE-C. A client-layer L2 connection tunneled through a PW is required between terminating PE-A and PE-C. The external entity computes a PW setup path that passes through PE-B. This results in two discrete PW segments being built: one between PE-A and PE-B and one between PE-B and PE-C. The successful client-layer L2 connection between terminating PE-A and terminating PE-C requires that PE-B performs the PWE3 switching process.
終端PE間のPWセットアップパスは、外部のエンティティによって計算されるように、第2の例では、単を含むかもしれません。 PWE3制御チャネルのフルメッシュは、PE-A、PE-B、及びPE-Cとの間に確立されているものとします。 PWを介してトンネリングクライアント層L2の接続は、PE-AおよびPE-C終端との間に必要とされます。外部エンティティは、PE-Bを通過PWセットアップパスを計算します。これは内蔵されている2つの別個のPWセグメントをもたらす：PE-AおよびPE-BおよびPE-B及びPE-Cとの間の1つの間に1つ。 PE-Aを終了し、PE-C終端間の正常なクライアント層L2の接続は、PE-Bは、PWE3切替処理を行うことを必要とします。
A third example involves the use of PWs in hierarchical IP/MPLS networks. Access networks connected to a backbone use PWs to transport customer payloads between customer sites serviced by the same access network and up to the edge of the backbone where they can be terminated or switched onto a succeeding PW segment crossing the backbone. The use of PWE3 switching between the access and backbone networks can potentially reduce the PWE3 control channels and routing information processed by the access network T-PEs.
第三の例では、階層的なIP / MPLSネットワークでのPWの使用を含みます。バックボーンに接続されているアクセスネットワークは同じアクセスネットワークによって、それらが終了またはバックボーンを横切る後続PWセグメントに切り替えることができるバックボーンのエッジまでのサービス顧客サイトとの間で顧客のペイロードを輸送するためのPWを使用します。アクセスとバックボーンネットワーク間の切り替えPWE3の使用は、潜在的にPWE3制御チャネル及びアクセスネットワークT-PESで処理ルーティング情報を低減することができます。
It should be noted that PWE3 switching does not help in any way to reduce the amount of PW state supported by each access network T-PE.
PWE3スイッチングは各アクセスネットワークT-PEによってサポートPW状態の量を減少させる任意の方法で解決しないことに留意すべきです。
-ii. In some applications, the signaling protocol and encapsulation on each segment of the PW are different. The terminating PEs are connected to networks employing different PW signaling and encapsulation protocols. In this case, it is not possible to use an SS-PW. An MS-PW with the appropriate signaling protocol interworking performed at the PW switching points can enable PW connectivity between the terminating PEs in this scenario.
-II。いくつかの用途では、PWの各セグメント上のシグナリングプロトコルおよびカプセル化は異なっています。終端PEは異なるPWシグナリングおよびカプセル化プロトコルを用いるネットワークに接続されています。このような場合には、SS-PWを使用することはできません。 PW切り替えポイントで実行適切なシグナリングプロトコルのインターワーキングを持つMS-PWは、このシナリオで終端PE間PWの接続を可能にすることができます。
A more detailed discussion of the requirements pertaining to MS-PWs can be found in [RFC5254].
MS-のPWに関連する要件のより詳細な議論は[RFC5254]に見出すことができます。
There are four different mechanisms to establish PWs:
PWをを確立するために、四つの異なるメカニズムがあります。
-i. Static configuration of the PW (MPLS or Layer 2 Tunneling Protocol version 3 (L2TPv3)) -ii. LDP using FEC 128 (PWid FEC Element) -iii. LDP using FEC 129 (Generalized PWid FEC Element) -iv. L2TPv3
-私。 PW（MPLSまたはレイヤ2トンネリングプロトコルバージョン3（L2TPv3の））の静的な構成-II。 LDP FEC 128（PWID FEC要素）-IIIを使用。 LDP使用FEC 129（一般PWID FEC要素）-iv。 L2TPv3の
While MS-PWs are composed of PW segments, each PW segment cannot function independently, as the PW service is always instantiated across the complete MS-PW. Hence, no PW segments can be signaled or be operational without the complete MS-PW being signaled at once.
MS-のPWがPWのセグメントで構成されているがPWサービスは、常に完全なMS-PWを横切ってインスタンス化されるように、各PWセグメントは、独立して機能することができません。したがって、何PWセグメントはシグナリングないまたは完全なMS-PWは、一度にシグナリングされることなく動作することがすることができます。
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]に記載されているように解釈されます。
- PW Terminating Provider Edge (T-PE). A PE where the customer-facing attachment circuits (ACs) are bound to a PW forwarder. A Terminating PE is present in the first and last segments of a MS-PW. This incorporates the functionality of a PE as defined in [RFC3985].
- PWの終端プロバイダエッジ（T-PE）。顧客向けの接続回線（ACS）がPWフォワーダに結合されているPE。終端PEは、MS-PWの最初と最後のセグメントに存在します。 [RFC3985]で定義されるように、これはPEの機能を組み込んでいます。
- Single-Segment Pseudowire (SS-PW). A PW set up directly between two T-PE devices. The PW label is unchanged between the originating and terminating T-PEs.
- 単一セグメント擬似回線（SS-PW）。 PWは、2つのT-PEデバイス間で直接設定します。 PWラベルは、発信および着信T-PE間変更されていません。
- Multi-Segment Pseudowire (MS-PW). A static or dynamically configured set of two or more contiguous PW segments that behave and function as a single point-to-point PW. Each end of an MS-PW by definition MUST terminate on a T-PE.
- マルチセグメント疑似回線（MS-PW）。シングルポイント・ツー・ポイントPWとして動作および機能二つ以上の連続するPWセグメントの静的または動的に構成されたセット。定義によるMS-PWの各端部は、T-PEで終端しなければなりません。
- PW Segment. A part of a single-segment or multi-segment PW, which traverses one PSN tunnel in each direction between two PE devices, T-PEs and/or S-PEs (switching PE).
- PWセグメント。 2つのPEデバイス間の各方向の一方PSNトンネルを横切る単一セグメントまたはマルチセグメントPW、T-PES及び/又はS-PES（PEスイッチング）の一部。
- PW Switching Provider Edge (S-PE). A PE capable of switching the control and data planes of the preceding and succeeding PW segments in an MS-PW. The S-PE terminates the PSN tunnels of the preceding and succeeding segments of the MS-PW. It therefore includes a PW switching point for an MS-PW. A PW switching point is never the S-PE and the T-PE for the same MS-PW. A PW switching point runs necessary protocols to set up and manage PW segments with other PW switching points and terminating PEs. An S-PE can exist anywhere a PW must be processed or policy applied. It is therefore not limited to the edge of a provider network.
- PWスイッチングプロバイダエッジ（S-PE）。 MS-PWに前後PWセグメントの制御およびデータプレーンを切り替えることができるPE。 S-PEは、MS-PWの先行及び後続のセグメントのPSNトンネルを終了します。したがって、MS-PWのためのPW切り替えポイントを含みます。 PW切り替えポイントは、同一のMS-PW用のS-PE及びT-PEことはありません。 PW切り替えポイントを設定し、他のPWスイッチング点と終了のPEとPWセグメントを管理するために必要なプロトコルを実行します。 S-PEは、PWが処理されなければならないか、ポリシーが適用どこでも存在することができます。したがって、プロバイダーネットワークのエッジに限定されるものではありません。
- MS-PW path. The set of S-PEs that will be traversed in sequence to form the MS-PW.
- MS-PWパス。 MS-PWを形成するシーケンスで横断するS-PEのセット。
A pseudowire (PW) is a mechanism that carries the essential elements of an emulated service from one PE to one or more other PEs over a PSN as described in Figure 1 and in [RFC3985]. Many providers have deployed PWs as a means of migrating existing (or building new) L2VPN services (e.g., Frame Relay, ATM, or Ethernet) onto a PSN.
疑似回線（PW）は、図1及び[RFC3985]に記載されているようにPSNを介して1つまたは複数の他のPEへの1つのPEからエミュレートされたサービスの本質的な要素を搬送する機構です。多くのプロバイダは、既存の（または構築する新しい）L2VPNサービスを移行するための手段としてのPWを展開している（例えば、フレームリレー、ATM、またはイーサネット）PSNへ。
PWs may span multiple domains of the same or different provider networks. In these scenarios, PW control channels (i.e., targeted LDP, L2TPv3) and PWs will cross AS boundaries.
PWSが同じまたは異なるプロバイダ・ネットワークの複数のドメインにまたがることができます。これらのシナリオでは、PW制御チャネル（即ち、LDP、L2TPv3の標的）およびPWは、境界と交差します。
Inter-AS L2VPN functionality is currently supported, and several techniques employing MPLS encapsulation and LDP signaling have been documented [RFC4364]. It is also straightforward to support the same inter-AS L2VPN functionality employing L2TPv3. In this document, we define a methodology to switch a PW between different Packet Switched Network (PSN) domains or between two or more distinct PW control plane domains.
インターAS L2VPN機能は現在サポートされており、いくつかの技術は、MPLSカプセル化およびLDPシグナリングを採用[RFC4364]を文書化されています。 L2TPv3のを利用し、同じAS間L2VPN機能をサポートすることも簡単です。この文書では、我々は、異なるパケット交換ネットワーク（PSN）ドメインの間、または2つ以上の異なるPW制御プレーンドメイン間PWを切り替える方法を定義します。
|<-------------- Emulated Service ---------------->|
| |
| |<-------- 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 Reference Model
図1：PWE3参照モデル
There are two methods for switching a PW between two PW domains. In the first method (Figure 2), the two separate control plane domains terminate on different PEs.
2つのPWドメイン間PWを切り替えるための2つの方法があります。第一の方法（図2）において、二つの別々の制御プレーンドメインは別のPEで終端します。
|<-------Multi-Segment Pseudowire------->|
| PSN PSN |
AC | |<-1->| |<-2->| | AC
| V V V V V V |
| +----+ +-----+ +----+ +----+ |
+----+ | | |=====| | | |=====| | | +----+
| |-------|......PW1.......|--AC1--|......PW2......|-------| |
| CE1| | | | | | | | | | | |CE2 |
| |-------|......PW3.......|--AC2--|......PW4......|-------| |
+----+ | | |=====| | | |=====| | | +----+
^ +----+ +-----+ +----+ +----+ ^
| PE1 PE2 PE3 PE4 |
| ^ ^ |
| | | |
| PW switching points |
| |
| |
|<-------------------- Emulated Service ---------------->|
Figure 2: PW Switching Using AC Reference Model
図2：PWは、ACリファレンスモデルを用いたスイッチング
In Figure 2, pseudowires in two separate PSNs are stitched together using native service attachment circuits. PE2 and PE3 only run the control plane for the PSN to which they are directly attached. At PE2 and PE3, PW1 and PW2 are connected using attachment circuit AC1, while PW3 and PW4 are connected using attachment circuit AC2.
図2では、二つの別々のPSN内の疑似回線をネイティブサービス接続回線を使用して一緒に縫合されています。 PE2とPE3は、彼らだけが直接接続されているにPSNのための制御プレーンを実行します。 PW3およびPW4は、アタッチメント回路AC2を用いて接続されているPE2及びPE3、PW1およびPW2において、アタッチメント回路AC1を使用して接続されています。
Native |<-----Multi-Segment Pseudowire------>| Native
Service | PSN PSN | Service
(AC) | |<-Tunnel->| |<-Tunnel->| | (AC)
| V V 1 V V 2 V V |
| +----+ +-----+ +----+ |
+----+ | |TPE1|==========|SPE1 |==========|TPE2| | +----+
| |------|.....PW.Seg't1....X....PW.Seg't3.....|-------| |
| CE1| | | | | | | | | |CE2 |
| |------|.....PW.Seg't2....X....PW.Seg't4.....|-------| |
+----+ | | |==========| |==========| | | +----+
^ +----+ +-----+ +----+ ^
| Provider Edge 1 ^ Provider Edge 2 |
| | |
| | |
| PW switching point |
| |
|<----------------- Emulated Service --------------->|
Figure 3: MS-PW Reference Model
図3：MS-PW参照モデル
In Figure 3, SPE1 runs two separate control planes: one toward TPE1, and one toward TPE2. The PW switching point (S-PE) is configured to connect PW Segment 1 and PW Segment 3 together to complete the multi-segment PW between TPE1 and TPE2. PW Segment 1 and PW Segment 3 MUST be of the same PW type, but PSN Tunnel 1 and PSN Tunnel 2 need not be the same technology. In the latter case, if the PW is switched to a different technology, the PEs must adapt the PDU encapsulation between the different PSN technologies. In the case where PSN Tunnel 1 and PSN Tunnel 2 are the same technology, the PW PDU does not need to be modified, and PDUs are then switched between the pseudowires at the PW label level.
TPE1に向かって一及びTPE2に向かって1：図3では、SPE1は、2つの別々の制御プレーンを実行します。 PWスイッチングポイント（S-PE）がTPE1とTPE2の間にマルチセグメントPWを完了するために一緒にPWセグメント1及びPWセグメント3を接続するように構成されています。 PWセグメント1とPWセグメント3は同じPWタイプである必要がありますが、PSNトンネル1とPSNトンネル2は、同じ技術である必要はありません。 PWは、異なる技術に切り替えられた場合、後者の場合、PEは異なるPSN技術間PDUカプセル化を適応しなければなりません。 PSNトンネル1とPSNトンネル2は同じ技術である場合には、PW PDUを変更する必要がなく、PDUは、次にPWラベルレベルで疑似回線間で切り替えられます。
It should be noted that it is possible to adapt one PSN technology to a different one, for example, MPLS over an IP encapsulation or Generic Routing Encapsulation (GRE) [RFC4023], but this is outside the scope of this document. Further, one could perform an interworking function on the PWs themselves at the S-PE, allowing conversion from one PW type to another, but this is also outside the scope of this document.
例えば、異なる1つに1つのPSN技術を適応させることが可能であることに留意すべきである、IPカプセル化オーバーMPLS又は総称ルーティングカプセル化（GRE）[RFC4023]、これはこの文書の範囲外です。さらに、一方がもう1つのPWタイプの変換を可能にする、S-PEでのPWに自身を相互接続機能を実行することができ、これはこの文書の範囲外でもあります。
This document describes procedures for building multi-segment pseudowires using manual configuration of the switching point PE1.
この文書は、スイッチングポイントPE1の手動設定を使用してマルチセグメント疑似回線を構築するための手順を記載しています。
Other documents may build on this base specification to automate the configuration and selection of S-PE1. All elements of the establishment of end-to-end MS-PWs including routing and signaling are out of scope of this document, and any discussion in this document serves purely as examples. It should also be noted that a PW can traverse multiple PW switching points along it's path, and the edge PEs will not require any specific knowledge of how many S-PEs the PW has traversed (though this may be reported for troubleshooting purposes).
他の文書には、S-PE1の設定と選択を自動化するために、この基本仕様に構築することができます。ルーティングおよびシグナリングを含むエンドツーエンドのMS-のPWの確立のすべての要素は、この文書の範囲外であり、この文書の任意の議論は、単に一例として機能します。また、パスだと（これは、トラブルシューティングの目的のために報告されてもよいが）エッジPEが-PES S PWが横断しているどのように多くの特定の知識を必要としない沿っPWが複数のPWスイッチポイントを横切ることができることに留意すべきです。
The general approach taken for MS-PWs is to connect the individual control planes by passing along any signaling information immediately upon reception. First, the S-PE is configured to switch a PW segment from a specific peer to another PW segment destined for a different peer. No control messages are exchanged yet, as the S-PE does not have enough information to actually initiate the PW setup messages. However, if a session does not already exist, a control protocol (LDP/L2TP) session MAY be setup. In this model, the MS-PW setup is starting from the T-PE devices. Once the T-PE is configured, it sends the PW control setup messages. These messages are received by the S-PE, and immediately used to form the PW setup messages for the next SS-PW of the MS-PW.
MS-のPWに要する一般的なアプローチは、受信時に即座に任意のシグナリング情報に沿って通過することによって、個々の制御プレーンを接続することです。まず、S-PEは、異なるピア宛の別のPWセグメントに特定のピアからPWセグメントを切り替えるように構成されています。 S-PEは、実際にPW設定メッセージを開始するのに十分な情報を持っていないとして、いかなる制御メッセージは、まだ交換されていません。セッションが既に存在していない場合は、制御プロトコル（LDP / L2TP）セッションがセットアップされる場合があります。このモデルでは、MS-PWセットアップは、T-PEデバイスから開始されます。 T-PEを設定したら、それはPW制御設定メッセージを送信します。これらのメッセージは、S-PEにより受信され、直ちにMS-PWの次のSS-PWのためのPWセットアップメッセージを形成するために使用されます。
The PWs in each PSN are established independently, with each PSN being treated as a separate PW domain. For example, in Figure 2 for the case of MPLS PSNs, PW1 is setup between PE1 and PE2 using the LDP targeted session as described in [RFC4447], and at the same time a separate pseudowire, PW2, is setup between PE3 and PE4. The ACs for PW1 and PW2 at PE2 and PE3 MUST be configured such that they are the same PW type, e.g., ATM Virtual Channel Connection (VCC), Ethernet VLAN, etc.
各PSNが別々PWドメインとして扱われる各PSN内のPWは、独立して確立されます。 [RFC4447]に記載されているように、例えば、MPLSのPSNの場合については、図2において、PW1は、LDPターゲットセッションを使用してPE1とPE2の間に設定され、そして同時に別疑似回線において、PW2は、PE3およびPE4の間でセットアップされます。 PE2及びPE3でPW1およびPW2のためのACSは、それらが、例えば、ATM仮想チャネル接続（VCC）、イーサネットVLAN、等同じPWタイプであるように構成されなければなりません
The general applicability of MS-PWs and their relationship to L2VPNs are described in [RFC5659]. The applicability of a PW type, as specified in the relevant RFC for that encapsulation (e.g., [RFC4717] for ATM), applies to each segment. This section describes further applicability considerations.
MS-のPWとのL2VPNとの関係の一般的な適用は、[RFC5659]に記載されています。 PWタイプの適用は、そのカプセル化に関連するRFC（ATM用の例えば、[RFC4717]）で指定されるように、各セグメントに適用されます。このセクションでは、更なる適用性の考慮事項について説明します。
As with SS-PWs, the performance of any segment will be limited by the performance of the underlying PSN. The performance may be further degraded by the emulation process, and performance degradation may be further increased by traversing multiple PW segments. Furthermore, the overall performance of an MS-PW is no better than the worst-performing segment of that MS-PW.
SS-のPWと同様に、任意のセグメントの業績は、基礎となるPSNの性能によって制限されます。性能をさらにエミュレーション処理によって分解することができ、性能劣化はさらに、複数のPWセグメントをトラバースすることによって増加させることができます。また、MS-PWの全体的な性能は、MS-PWの最悪実行セグメントよりも良好ではありません。
Since different PSN types may be able to achieve different maximum performance objectives, it is necessary to carefully consider which PSN types are used along the path of an MS-PW.
異なるPSNタイプが異なる最大性能目標を達成することができるかもしれないので、慎重にMS-PWの経路に沿って使用されるPSNタイプを考慮する必要があります。
Referencing Figure 3, T-PE1 set up PW Segment 1 using the LDP targeted session as described in [RFC4447], at the same time a separate pseudowire, PW Segment 3, is setup to T-PE2. Each PW is configured independently on the PEs, but on S-PE1, PW Segment 1 is connected to PW Segment 3. PDUs are then switched between the pseudowires at the PW label level. Hence, the data plane does not need any special knowledge of the specific pseudowire type. A simple standard MPLS label swap operation is sufficient to connect the two PWs, and in this case the PW adaptation function cannot be used. However, when pushing a new PSN label, the Time to Live (TTL) SHOULD be set to 255, or some other locally configured fixed value.
図3を参照して、T-PE1は、別個の疑似回線、PWセグメント3は、T-PE2に設定されると同時に、[RFC4447]に記載されているようにLDPターゲットセッションを使用してPWセグメント1を設定します。各PWは、PESに独立して構成されているが、S-PE1に、PWセグメント1が3のPDUは、次に、PWラベルレベルで疑似回線間で切り替えられるPWセグメントに接続されています。従って、データプレーンは、特定の疑似回線の種類の特別な知識を必要としません。単純な標準的なMPLSラベルスワップ動作は、二つのPWを接続するために十分であり、この場合、PW適応機能は使用できません。新しいPSNのラベルをプッシュするときただし、（TTL）の生存時間は255に設定、またはいくつかの他のローカルに設定された一定の値である必要があります。
This process can be repeated as many times as necessary; the only limitation to the number of S-PEs traversed is imposed by the TTL field of the PW MPLS label. The setting of the TTL of the PW MPLS label is a matter of local policy on the originating PE, but SHOULD be set to 255. However, if the PW PDU contains an Operations, Administration, and Maintenance (OAM) packet, then the TTL can be set to the required value as explained later in this document.
このプロセスは、必要に応じて何度でも繰り返すことができます。 S-PEの数の唯一の制限は、PW MPLSラベルのTTLフィールドによって課されるトラバース。 PW MPLSラベルのTTLの設定は、発信PEのローカルポリシーの問題であるが、PW PDUは、運用、管理、および保守（OAM）パケットは、TTLが含まれている場合、しかし、255に設定されてくださいこのドキュメントで後述するように必要な値に設定することができます。
There are three different mechanisms for MPLS-to-MPLS PW setup:
MPLSツーMPLS PWのセットアップのための3つの異なるメカニズムがあります。
-i. Static configuration of the PW -ii. LDP using FEC 128 -iii. LDP using the generalized FEC 129
-私。 PWの-IIの静的な構成。 FEC 128 -IIIを使用してLDP。一般FEC 129を使用してLDP
This results in four distinct PW switching situations that are significantly different and must be considered in detail:
これは大幅に異なっており、詳細に検討しなければならない4つの別個のPWスイッチング状況での結果：
-i. Switching between two static control planes -ii. Switching between a static and a dynamic LDP control plane -iii. Switching between two LDP control planes using the same FEC type -iv. Switching between LDP using FEC 128 and LDP using the generalized FEC 129
-私。 2スタティックコントロールプレーン-IIの切り替え。静的および動的LDPコントロールプレーン-III切り替えます。同じFEC型-ivを使用して、2つのLDP制御プレーンを切り替えます。一般FEC 129を使用してFEC 128およびLDPを使用して、LDP切り替えます
In the case of two static control planes, the S-PE MUST be configured to direct the MPLS packets from one PW into the other. There is no control protocol involved in this case. When one of the control planes is a simple static PW configuration and the other control plane is a dynamic LDP FEC 128 or generalized PW FEC, then the static control plane should be considered similar to an attachment circuit (AC) in the reference model of Figure 1. The switching point PE SHOULD signal the appropriate PW status if it detects a failure in sending or receiving packets over the static PW segment. In the absence of a PW status communication mechanism when the PW is statically configured, the status communicated to the dynamic LDP PW will be limited to local interface failures. In this case, the S-PE PE behaves in a very similar manner to a T-PE, assuming an active signaling role. This means that the S-PE will immediately send the LDP Label Mapping message if the static PW is deemed to be UP.
2つの静的制御プレーンの場合に、S-PEは、他に1 PWからMPLSパケットを導くように構成されなければなりません。この場合に関わる一切制御プロトコルはありません。制御プレーンの一つは単純な静的なPW構成および他の制御プレーンは、動的LDP FEC 128又は一般PW FECである場合、次いで、静的制御プレーンは、図の参照モデルにおけるアタッチメント回路（AC）と同様とみなされるべきですそれは、静的なPWセグメントを介してパケットの送受信の障害を検出した場合1.スイッチングポイントは、PEは、適切なPWステータスを通知すべきです。 PWが静的に構成されているPWステータス通信機構の非存在下で、動的LDP PWに通信ステータスは、ローカルインタフェースの障害に限定されるであろう。この場合、S-PE PEは、アクティブなシグナリングの役割を想定し、T-PEと非常に類似した方法で動作します。これは、静的なPWがUPであると判断される場合、S-PEは直ちにLDPラベルマッピングメッセージを送信することを意味します。
The S-PE SHOULD assume an initial passive role. This means that when independent PWs are configured on the switching point, the Label Switching Router (LSR) does not advertise the LDP PW FEC mapping until it has received at least one of the two PW LDP FECs from a remote PE. This is necessary because the switching point LSR does not know a priori what the interface parameter field in the initial FEC advertisement will contain.
S-PEは、最初の受動的な役割を引き受けるべきです。これは、独立のPWは、スイッチングポイントに設定されている場合、それはリモートPEから二つのPW LDPのFECの少なくとも一方を受信するまで、ラベルスイッチングルータ（LSR）がLDP PW FECマッピングをアドバタイズしないことを意味します。スイッチングポイントLSRは、初期FEC広告のインターフェイスパラメータフィールドが含まれていますどのようなアプリオリを知らないので、これが必要です。
If one of the S-PEs doesn't accept an LDP Label Mapping message, then a Label Release message may be sent back to the originator T-PE depending on the cause of the error. LDP liberal label retention mode still applies; hence, if a PE is simply not configured yet, the label mapping is stored for future use. An MS-PW is declared UP only when all the constituent SS-PWs are UP.
S-PEの1は、LDPラベルマッピングメッセージを受け入れない場合は、ラベル解放メッセージは、エラーの原因に応じてバック発信元T-PEに送信されることがあります。自民党リベラルラベル保持モードでは、まだ適用されます。 PEは、単にまだ設定されていない場合、したがって、ラベルマッピングは、将来の使用のために格納されます。 MS-PWを構成するすべてのSS-PWSはUPされている場合にのみ、UP宣言されています。
The Pseudowire Identifier (PWid), as defined in [RFC4447], is a unique number between each pair of PEs. Hence, each SS-PW that forms an MS-PW may have a different PWid. In the case of the generalized PW FEC, the Attachment Group Identifier (AGI) / Source Attachment Identifier (SAI) / Target Attachment Identifier (TAI) may have to also be different for some, or sometimes all, SS-PWs.
疑似回線識別子（PWID）、[RFC4447]で定義されるように、PEの各対の間の固有の番号です。したがって、MS-PWを構成する各SS-PWは、異なるPWIDを有していてもよいです。一般PW FECの場合、添付ファイルは、グループ識別子（AGI）/ソース添付識別子（SAI）/ターゲットアタッチメント識別子（TAI）は、いくつかのために異なることが有していてもよく、又は時には全て、SS-のPW。
When an MS-PW is signaled using FEC 129, each T-PE might independently start signaling the MS-PW. If the MS-PW path is not statically configured, in certain cases the signaling procedure could result in an attempt to set up each direction of the MS-PW through different S-PEs. If an operator wishes to avoid this situation, one of the T-PEs MUST start the PW signaling (active role), while the other waits to receive the LDP label mapping before sending the respective PW LDP Label Mapping message (passive role). When the MS-PW path is not statically configured, the active T-PE (the Source
MS-PWは、FEC 129を使用して通知された場合に、各T-PEは、独立して、MS-PWシグナリング始めるかもしれません。 MS-PWパスが静的に構成されていない場合は、一定の場合にシグナリング手順は、異なるS-PES介しMS-PWのそれぞれの方向を設定する試みが生じる可能性があります。操作者がこの状況を回避したい場合、他の待機各PW LDPラベルマッピングメッセージ（受動的な役割）を送信する前に、LDPラベルマッピングを受け取るようにしながら、T-PEの一つは、PWシグナリング（積極的に）開始しなければなりません。 MS-PWパスが静的に構成されていない、アクティブT-PE（出典
T-PE) and the passive T-PE (the Target T-PE) MUST be identified before signaling is initiated for a given MS-PW.
シグナリングが与えMS-PWのために開始される前にT-PE）および受動T-PE（ターゲットT-PE）が同定されなければなりません。
The determination of which T-PE assumes the active role SHOULD be done as follows:
T-PEの決定は、次のように積極的な役割を行うべき前提としています。
The SAII and TAII are compared as unsigned integers; if the SAII is larger, then the T-PE assumes the active role.
SAIIとTAIIは符号なし整数として比較されます。 SAIIが大きければ、次にT-PEは、積極的な役割を想定しています。
The selection process to determine which T-PE assumes the active role MAY be superseded by manual provisioning. In this case, one of the T-PEs MUST be set to the active role, and the other one MUST be set to the passive role.
選択プロセスは、T-PEは、手動プロビジョニングによって無効とされることがあり積極的な役割を想定しているかを決定します。この場合には、T-PEの一つは積極的な役割に設定しなければなりません、そして他方は受動的な役割に設定しなければなりません。
When a PE is using the generalized FEC 129, there are two distinct roles that a PE can assume: active and passive. A PE that assumes the active role will send the LDP PW setup message, while a passive role PE will simply reply to an incoming LDP PW setup message. The S-PE will always remain passive until a PWid FEC 128 LDP message is received, which will cause the corresponding generalized PW FEC LDP message to be formed and sent. If a generalized FEC PW LDP message is received while the switching point PE is in a passive role, the corresponding PW FEC 128 LDP message will be formed and sent.
アクティブおよびパッシブ：PEは一般FEC 129を使用している場合、PEをとることができることを二つの異なる役割があります。受動的な役割PEは単に着信LDP PWセットアップメッセージに返信する一方、LDP PWセットアップメッセージを送信する積極的な役割を想定しているPE。 PWID FEC 128 LDPメッセージが受信されるまで、S-PEは、常に、対応する一般化されたPW FEC LDPメッセージが形成されて送信させるなる、パッシブ残ります。スイッチング点PEは受動的な役割にある間に一般FEC PW LDPメッセージを受信した場合、対応するPW FEC 128 LDPメッセージが形成されて送信されます。
PWids need to be mapped to the corresponding AGI/TAI/SAI and vice versa. This can be accomplished by local S-PE configuration, or by some other means, such as some form of auto discovery. Such other means are outside the scope of this document.
PWidsその逆対応AGI / TAI / SAIにマッピングされる必要があります。これは、ローカルS-PEの構成によって、又はそのような自動検出のいくつかの形態のようないくつかの他の手段によって達成することができます。このような他の手段は、この文書の範囲外です。
The edge-to-edge PW might traverse several switching points, in separate administrative domains. For management and troubleshooting reasons, it is useful to record information about the switching points at the S-PEs that the PW traverses. This is accomplished by using a PW Switching Point PE TLV (SP-PE TLV).
エッジ・ツー・エッジPWは別の管理ドメイン内に、いくつかのスイッチングポイントを横切るかもしれません。管理とトラブルシューティングの理由から、PWが通過することをS-PESでスイッチングポイントに関する情報を記録するのに便利です。これは、PWスイッチング・ポイントPE TLV（SP-PE TLV）を使用することによって達成されます。
Sending the SP-PE TLV is OPTIONAL; however, the PE or S-PE MUST process the TLV upon reception. The "U" bit MUST be set for backward compatibility with T-PEs that do not support the MS-PW extensions described in the document. The SP-PE TLV MAY appear only once for each switching point traversed, and it cannot be of length zero. The SP-PE TLV is appended to the PW FEC at each S-PE, and the order of the SP-PE TLVs in the LDP message MUST be preserved. The SP-PE TLV is necessary to support some of the Virtual Circuit Connectivity Verification (VCCV) functions for MS-PWs. See Section 9.5 for more details. The SP-PE TLV is encoded as follows:
SP-PE TLVの送信はオプションです。しかし、PEまたはS-PEは、受信時にTLVを処理しなければなりません。 「U」のビットは、文書に記載MS-PWの拡張機能をサポートしていないT-PESとの下位互換性のために設定しなければなりません。 SP-PE TLVは横断各スイッチング・ポイントのために一度だけ表示されてもよく、それは長さゼロにすることはできません。 SP-PE TLVは、各S-PEでPW FECに付加され、LDPメッセージ内のSP-PEのTLVの順序は保存されなければなりません。 SP-PE TLVは、MS-PWのための仮想回線接続検証（VCCV）機能の一部をサポートする必要があります。詳細は、9.5節を参照してください。次のようにSP-PE TLVがコードされます。
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| SP-PE TLV (0x096D) | SP-PE TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Type | Length | Variable Length Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length Value |
| " " " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- SP-PE TLV Length
- SP-PE TLVの長さ
Specifies the total length of all the following SP-PE TLV fields in octets.
オクテット内のすべての次SP-PE TLVフィールドの合計の長さを指定します。
- Sub-TLV Type
- サブTLVタイプ
Encodes how the Value field is to be interpreted.
Valueフィールドがどのように解釈されるかエンコードします。
- Length
- 長さ
Specifies the length of the Value field in octets.
オクテットで値フィールドの長さを指定します。
- Value
- バリュー
Octet string of Length octets that encodes information to be interpreted as specified by the Type field.
Typeフィールドによって指定されるように解釈されるべき情報を符号化長さオクテットのオクテットストリング。
PW Switching Point PE sub-TLV Types are assigned by IANA according to the process defined in Section 14 (IANA Considerations) below.
PWスイッチング・ポイントPEサブTLVのタイプは、以下の第14章（IANAの考慮）で定義されたプロセスによれば、IANAによって割り当てられています。
For local policy reasons, a particular S-PE can filter out all
SP-PE TLVs in a Label Mapping message that traverses it and not
include its own SP-PE TLV. In this case, from any upstream PE,
it will appear as if this particular S-PE is the T-PE. This
might be necessary, depending on local policy, if the S-PE is at
the service provider administrative boundary. It should also be
noted that because there are no SP-PE TLVs describing the path
beyond the S-PE that removed them, VCCV will only work as far as
that S-PE.
The SP-PE TLV contains sub-TLVs that describe various characteristics of the S-PE traversed. The SP-PE TLV MUST contain the appropriate mandatory sub-TLVs specified below. The definitions of the PW Switching Point PE sub-TLVs are as follows:
SP-PE TLVサブTLVを含んでいるS-PEの種々の特性を記述するトラバース。 SP-PE TLVは以下の指定された適切な必須のサブTLVを含まなければなりません。次のようにポイントPEサブTLVをスイッチングPWの定義は次のとおりです。
- PWid of last PW segment traversed.
- 最後のPWセグメントのPWIDを横断しました。
This is only applicable if the last PW segment traversed used LDP FEC 128 to signal the PW. This sub-TLV type contains a PWid in the format of the PWid described in [RFC4447]. This is just a 32-bit unsigned integer number.
最後PWセグメントがPWを通知するLDP FEC 128を用い横断場合にのみ適用可能です。このサブTLVのタイプは、PWIDの形式でPWIDは[RFC4447]で説明含ま。これは単に、32ビットの符号なし整数です。
- PW Switching Point description string.
- PWポイントの説明文字列を切り替えます。
An OPTIONAL description string of text up to 80 characters long. Human-readable text MUST be provided in the UTF-8 character set using the Default Language [RFC2277].
長さが80文字までのテキストのオプションの説明文字列。人間が読めるテキストは、デフォルト言語[RFC2277]を使用してUTF-8文字セットに提供しなければなりません。
- Local IP address of PW Switching Point.
- PW切り替えポイントのローカルIPアドレス。
The local IPv4 or IPv6 address of the PW Switching Point. This is an OPTIONAL Sub-TLV. In most cases, this will be the local LDP session IP address of the S-PE.
PWスイッチングポイントのローカルIPv4またはIPv6アドレス。これはオプションのサブTLVです。ほとんどの場合、これは、S-PEのローカルLDPセッションのIPアドレスになります。
- Remote IP address of the last PW Switching Point traversed or of the T-PE.
- またはT-PEの横断最後のPWスイッチング・ポイントのリモートIPアドレス。
The IPv4 or IPv6 address of the last PW Switching Point traversed or of the T-PE. This is an OPTIONAL Sub-TLV. In most cases, this will be the remote IP address of the LDP session. This Sub-TLV SHOULD only be included if there are no other SP-PE TLVs present from other S-PEs, or if the remote IP address of the LDP session does not correspond to the "Local IP address of PW Switching Point" TLV value contained in the last SP-PE TLV.
ポイントスイッチング最後PWのIPv4またはIPv6アドレスまたはT-PEの横断しました。これはオプションのサブTLVです。ほとんどの場合、これは、LDPセッションのリモートIPアドレスになります。そこに他のS-PESから他のSP-PEのTLVが存在しない場合、またはこのサブTLVは、含まれるべきであるLDPセッションのリモートIPアドレスは、TLV値「PWスイッチング・ポイントのローカルIPアドレス」に対応していない場合最後にSP-PE TLVに含まれています。
- The FEC element of last PW segment traversed.
- 最後PWセグメントのFEC要素を横断しました。
This is only applicable if the last PW segment traversed used LDP FEC 129 to signal the PW.
最後PWセグメントがPWを通知するLDP FEC 129を用い横断場合にのみ適用可能です。
The FEC element of the last PW segment traversed. This is encoded in the following format:
最後のPWセグメントのFEC要素を横断しました。これは、次の形式でエンコードされています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- L2 PW address of the PW Switching Point (recommended format).
- PWスイッチングポイント（推奨フォーマット）のL2 PWアドレス。
This sub-TLV type contains an L2 PW address of PW Switching Point in the format described in Section 3.2 of [RFC5003]. This includes the AII type field and length, as well as the L2 PW address with the AC ID field set to zero.
このサブTLVのタイプは、[RFC5003]のセクション3.2で説明したフォーマットでPW切り替えポイントのL2 PWアドレスを含みます。これは、AIIタイプフィールドおよび長さ、ならびにゼロに設定AC IDフィールドとL2 PWアドレスを含みます。
[RFC4447] defines several interface parameters, which are used by the Network Service Processing (NSP) to adapt the PW to the attachment circuit (AC). The interface parameters are only used at the endpoints, and MUST be passed unchanged across the S-PE. However, the following interface parameters MAY be modified as follows:
[RFC4447]は接続回線（AC）にPWを適応させるために、ネットワークサービス処理（NSP）によって使用されるいくつかのインタフェースパラメータを定義します。インターフェイスパラメータは、エンドポイントで使用され、S-PEを横切って変化しない渡されなければなりません。次のようにただし、以下のインタフェースパラメータを変更してもよいです。
- 0x03 Optional Interface Description string This Interface parameter MAY be modified or altogether removed from the FEC element depending on local configuration policies.
- 0x03のオプションのインターフェイスの説明文字列このインタフェースパラメータを変更または完全にローカル設定ポリシーに応じFEC要素から除去することができます。
- 0x09 Fragmentation indicator This parameter MAY be inserted in the FEC by the switching point if it is capable of re-assembly of fragmented PW frames according to [RFC4623].
- それは断片化されたPWの再組み立てが可能である場合、このパラメータは、スイッチングポイントによってFECに挿入することができる0x09の断片化インジケータは[RFC4623]に記載のフレーム。
- 0x0C VCCV parameter This Parameter contains the Control Channel (CC) type and Connectivity Verification (CV) type bit fields. The CV type bit field MUST be reset to reflect the CV type supported by the S-PE. The CC type bit field MUST have bit 1 "Type 2: MPLS Router Alert Label" set to 0. The other bit fields MUST be reset to reflect the CC type supported by the S-PE.
- 0x0CののVCCVパラメータは、このパラメータは、制御チャネル（CC）を入力し、接続検証（CV）はビットフィールドを入力含まれています。 CVタイプのビットフィールドは、S-PEによってサポートCVタイプを反映するためにリセットする必要があります。他のビットフィールドは、S-PEによってサポートされているCCタイプを反映するためにリセットする必要が0に設定：CCタイプビットフィールドは、ビット1「MPLSルータ警告ラベルタイプ2」を持たなければなりません。
The Group ID (GR ID) is used to reduce the number of status messages that need to be sent by the PE advertising the PW FEC. The GR ID has local significance only, and therefore MUST be mapped to a unique GR ID allocated by the S-PE.
グループID（GR ID）はPW FECを広告するPEによって送信される必要があるステータスメッセージの数を減らすために使用されます。 GR IDはローカルな意味を有しており、従ってS-PEにより割り当てられた一意のGR IDにマッピングされなければなりません。
A switching point PE SHOULD inspect the PW Switching Point PE TLV, to verify that its own IP address does not appear in it. If the PE's IP address appears in a received PW Switching Point PE TLV, the PE SHOULD break the loop and send a label release message with the following error code:
スイッチングポイントのPEは、独自のIPアドレスがそれに表示されていないことを確認するために、PWスイッチング・ポイントPE TLVを検査する必要があります。 PEのIPアドレスがポイントPE TLVを切り替え受けPWに表示された場合、PEは、ループを切断し、次のエラーコード付きラベル解放メッセージを送信する必要があります：
Value E Description 0x0000003A 0 PW Loop Detected
検出値E説明0x0000003A 0 PWループ
If an S-PE along the MS-PW removed all SP-PE TLVs, as mentioned above, this loop detection method will fail.
MS-PWに沿ってS-PEは、全てのSP-PE TLVを削除した場合、上述したように、このループ検出方法は失敗します。
Both MPLS and L2TPv3 PWs may be static or dynamic. This results in four possibilities when switching between L2TPv3 and MPLS.
MPLSとL2TPv3の両方のPWは、静的または動的であってもよいです。 L2TPv3のとMPLSを切り替えるとき、これは4つの可能性につながります。
-i. Switching between static MPLS and L2TPv3 PWs -ii. Switching between a static MPLS PW and a dynamic L2TPv3 PW -iii. Switching between a static L2TPv3 PW and a dynamic LDP/MPLS PW -iv. Switching between a dynamic LDP/MPLS PW and a dynamic L2TPv3 PW
-私。静的MPLSとL2TPv3のPWを-II間の切り替え。静的MPLS PWと動的L2TPv3のPWの-IIIの切り替え。静的L2TPv3のPWと動的LDP / MPLS PWの-ivの切り替え。ダイナミックLDP / MPLS PWと動的L2TPv3のPWの切り替え
In the case of two static control planes, the S-PE MUST be configured to direct packets from one PW into the other. There is no control protocol involved in this case. The configuration MUST include which MPLS PW Label maps to which L2TPv3 Session ID (and associated Cookie, if present) as well as which MPLS Tunnel Label maps to which PE destination IP address.
2つの静的制御プレーンの場合に、S-PEは、他に1 PWから直接パケットに設定する必要があります。この場合に関わる一切制御プロトコルはありません。構成は、MPLS PWラベルマップを含まなければならないためにどののL2TPv3セッションID（及び関連するクッキーが存在する場合）、ならびにそのPE先IPアドレスへのMPLSトンネルラベルマップ。
When a statically configured MPLS PW is switched to a dynamic L2TPv3 PW, the static control plane should be considered identical to an attachment circuit (AC) in the reference model of Figure 1. The switching point PE SHOULD signal the appropriate PW status if it detects a failure in sending or receiving packets over the static PW. Because the PW is statically configured, the status communicated to the dynamic L2TPv3 PW will be limited to local interface failures. In this case, the S-PE behaves in a very similar manner to a T-PE, assuming an active role.
静的に構成されたMPLS PWがダイナミックのL2TPv3 PWに切り換えられると、静的制御プレーンは、図1が検出した場合、適切なPWステータスを知らせるべきでスイッチングポイントPEの参照モデルにおけるアタッチメント回路（AC）と同一とみなされるべきです静的PWを超えるパケットを送信または受信に失敗。 PWが静的に構成されているため、ダイナミックのL2TPv3 PWに通信ステータスは、ローカルインタフェースの障害に限定されるであろう。この場合、S-PEは、積極的な役割を仮定すると、T-PEと非常に類似した方法で動作します。
When a statically configured L2TPv3 PW is switched to a dynamic LDP/MPLS PW, then the static control plane should be considered identical to an attachment circuit (AC) in the reference model of Figure 1. The switching point PE SHOULD signal the appropriate PW status (via an L2TPv3 Set-Link-Info (SLI) message) if it detects a failure in sending or receiving packets over the static PW. Because the PW is statically configured, the status communicated to the dynamic LDP/MPLS PW will be limited to local interface failures. In this case, the S-PE behaves in a very similar manner to a T-PE, assuming an active role.
静的に構成されたL2TPv3 PWを動的LDP / MPLS PWに切り換えられると、次に、静的制御プレーンスイッチング点PEは、適切なPWステータスを通知すべきである。図1の参照モデルにおけるアタッチメント回路（AC）と同一とみなされるべきです（L2TPv3の設定-リンク情報（SLI）メッセージを経由して）それは、静的PWを超えるパケットを送信または受信に障害を検出します。 PWが静的に構成されているため、ダイナミックLDP / MPLS PWに通信ステータスは、ローカルインタフェースの故障に限定されるであろう。この場合、S-PEは、積極的な役割を仮定すると、T-PEと非常に類似した方法で動作します。
When switching between dynamic PWs, the switching point always assumes an initial passive role. Thus, it does not initiate an LDP/MPLS or L2TPv3 PW until it has received a connection request (Label Mapping or Incoming-Call-Request (ICRQ)) from one side of the node. Note that while MPLS PWs are made up of two unidirectional Label Switched Paths (LSPs) bonded together by FEC identifiers, L2TPv3 PWs are bidirectional in nature, setup via a three-message exchange (ICRQ, Incoming-Call-Reply (ICRP), and Incoming-Call-Connected (ICCN)). Details of Session Establishment, Tear Down, and PW Status signaling are detailed below.
ダイナミックPWを切り替える場合、切り替えポイントは、常に最初の受動的な役割を前提としています。それはノードの一方の側からの接続要求（ラベルマッピングまたは着信リクエスト（ICRQ））を受信するまでこのように、LDP / MPLSまたはL2TPv3のPWを開始しません。 MPLSのPWSは2つの単方向ラベルで構成されていながら、FEC識別子により結合スイッチパス（LSP）ことに注意してください、L2TPv3のPWSが自然、3-のメッセージ交換を介したセットアップ（ICRQ、着信-返信（ICRP）で双方向であり、着信接続（ICCN））。セッション確立の詳細については、取り壊し、およびPWステータスシグナリングは、以下に詳述されています。
When the S-PE receives an L2TPv3 ICRQ message, the identifying AVPs included in the message are mapped to FEC identifiers and sent in an LDP Label Mapping message. Conversely, if an LDP Label Mapping message is received, it is either mapped to an ICRP message or causes an L2TPv3 session to be initiated by sending an ICRQ.
S-PEは、L2TPv3のICRQメッセージを受信すると、特定のAVPは、メッセージに含まれるFEC識別子にマッピングされ、LDPラベルマッピングメッセージで送信されます。 LDPラベルマッピングメッセージを受信した場合、逆に、それはいずれかICRPメッセージにマッピングされた又はICRQを送信することによって開始されるのL2TPv3セッションを引き起こします。
Following are two example exchanges of messages between LDP and L2TPv3. The first is a case where an L2TPv3 T-PE initiates an MS-PW; the second is a case where an MPLS T-PE initiates an MS-PW.
自民党とL2TPv3の間のメッセージの2例の交換は次のとおりです。最初は、L2TPv3のT-PEは、MS-PWを開始する場合です。第二は、MPLS T-PEは、MS-PWを開始する場合です。
PE 1 (L2TPv3) PW Switching Node PE3 (MPLS/LDP)
PE 1（L2TPv3の）PWスイッチングノードPE3（MPLS / LDP）
AC "Up"
L2TPv3 ICRQ --->
LDP Label Mapping --->
AC "Up"
<--- LDP Label Mapping
<--- L2TPv3 ICRP
L2TPv3 ICCN --->
<-------------------- MS-PW Established ------------------>
PE 1 (MPLS/LDP) PW Switching Node PE3 (L2TPv3)
AC "Up"
LDP Label Mapping --->
L2TPv3 ICRQ --->
<--- L2TPv3 ICRP
<--- LDP Label Mapping
L2TPv3 ICCN --->
AC "Up"
<-------------------- MS-PW Established ------------------>
L2TPv3 uses the SLI message to indicate an interface status change (such as the interface transitioning from "Up" or "Down"). MPLS/LDP PWs either signal this via an LDP Label Withdraw or the PW Status Notification message defined in Section 4.4 of [RFC4447]. The LDP status TLV bit SHOULD be mapped to the L2TPv3 equivalent Extended Circuit Status Values TLV specified in [RFC5641].
L2TPv3のは、（例えば、「アップ」または「ダウン」から移行インタフェースとして）インターフェイスステータスの変更を示すために、SLIメッセージを使用します。 MPLS / LDPのPWは、LDPラベル撤回または[RFC4447]のセクション4.4で定義されたPW状態通知メッセージを介してこの信号のいずれか。 LDP状態TLVビットがL2TPv3の等価拡張回線状態がTLVは[RFC5641]で指定された値にマップされるべきです。
L2TPv3 uses a single message, Call-Disconnect-Notify (CDN), to tear down a pseudowire. The CDN message translates to a Label Withdraw message in LDP. Following are two example exchanges of messages between LDP and L2TPv3. The first is a case where an L2TPv3 T-PE initiates the termination of an MS-PW; the second is a case where an MPLS T-PE initiates the termination of an MS-PW.
L2TPv3のは、単一のメッセージを使用して、コール切断は、通知（CDN）、疑似回線を切断します。 CDNメッセージは、LDPにメッセージを撤回ラベルに変換されます。自民党とL2TPv3の間のメッセージの2例の交換は次のとおりです。最初は、L2TPv3のT-PEは、MS-PWの終了を開始する場合です。第二は、MPLS T-PEは、MS-PWの終了を開始する場合です。
PE 1 (L2TPv3) PW Switching Node PE3 (MPLS/LDP)
PE 1（L2TPv3の）PWスイッチングノードPE3（MPLS / LDP）
AC "Down"
L2TPv3 CDN --->
LDP Label Withdraw --->
AC "Down"
<-- LDP Label Release
<--------------- MS-PW Data Path Down ------------------>
PE 1 (MPLS LDP) PW Switching Node PE3 (L2TPv3)
AC "Down"
LDP Label Withdraw --->
L2TPv3 CDN -->
<-- LDP Label Release
AC "Down"
<---------------- MS-PW Data Path Down ------------------>
[RFC4447] defines several interface parameters that MUST be mapped to the equivalent AVPs in L2TPv3 setup messages.
[RFC4447]はL2TPv3のセットアップメッセージにおける同等のAVPにマッピングされなければならないいくつかのインタフェースパラメータを定義します。
* Interface MTU
*インターフェイスのMTU
The Interface MTU parameter is mapped directly to the L2TP "Interface Maximum Transmission Unit" AVP defined in [RFC4667].
インタフェースMTUパラメータはL2TP「インタフェース最大転送単位」[RFC4667]で定義されたAVPに直接マッピングされます。
* Max Number of Concatenated ATM cells
連結ATMセルの最大数*
This interface parameter is mapped directly to the L2TP "ATM Maximum Concatenated Cells AVP" described in Section 6 of [RFC4454].
このインタフェースパラメータは、[RFC4454]のセクション6で説明L2TP「ATM最大連結セルAVP」に直接マッピングされます。
* PW Type
* PWタイプ
The PW Type defined in [RFC4446] is mapped to the L2TPv3 "Pseudowire Type" AVP defined in [RFC3931].
[RFC4446]で定義されたPWタイプは[RFC3931]で定義されたL2TPv3「疑似回線タイプ」AVPにマッピングされます。
* PWid (FEC 128)
* PWID（FEC 128）
For FEC 128, the PWid is mapped directly to the L2TPv3 "Remote End ID" AVP defined in [RFC3931].
FEC 128は、PWIDは[RFC3931]で定義されたL2TPv3「リモートエンドID」AVPに直接マッピングされます。
* Generalized FEC 129 SAI/TAI
*一般FEC SAI 129 / IS
Section 4.3 of [RFC4667] defines how to encode the SAI and TAI parameters. These can be mapped directly.
[RFC4667]のセクション4.3はSAIとTAIパラメータをエンコードする方法を規定します。これらは、直接マッピングすることができます。
Other interface parameter mappings are unsupported when switching between LDP/MPLS and L2TPv3 PWs.
LDP / MPLSとL2TPv3のPWを切り替える際に、他のインターフェイスパラメータのマッピングはサポートされていません。
When translating between LDP and L2TPv3 control messages, the PW Switching Point PE TLV described earlier in this document is carried in a single variable-length L2TP AVP present in the ICRQ and ICRP messages, and optionally in the ICCN message.
LDPとL2TPv3の制御メッセージの間に変換するときに、PWは、ポイントPE TLVは、このドキュメントのICRQとICRPメッセージに単一の可変長L2TP AVP存在で運ばれ、及び任意にICCNメッセージで説明したスイッチング。
The L2TP "PW Switching Point AVP" is Attribute Type 101. The AVP MAY be hidden (the L2TP AVP H-bit may be 0 or 1), the length of the AVP is 6 plus the length of the series of Switching Point PE sub-TLVs included in the AVP, and the AVP MUST NOT be marked Mandatory (the L2TP AVP M-bit MUST be 0).
L2TP「ポイントAVPスイッチングPW」は、属性タイプ101 AVPを隠すことができる（L2TP AVP Hビットは0または1であってもよい）、AVPの長さは、ポイントPEサブスイッチングの一連の6を加えた長さであります-TLVsはAVPに含まれ、そしてAVPは、（L2TP AVP Mビットは0でなければなりません）必須マークされてはいけません。
When switching between an MPLS and L2TP PW, packets are sent in their entirety from one PW to the other, replacing the MPLS label stack with the L2TPv3 and IP header or vice versa.
MPLS及びL2TP PW切り替える場合、パケットは、L2TPv3の及びIPヘッダと共に又はその逆のMPLSラベルスタックを置き換える、他の1つのPWからその全体が送信されます。
Section 5.4 of [RFC3985] discusses the purpose of the various shim headers necessary for enabling a pseudowire over an IP or MPLS PSN. For L2TPv3, the Payload Convergence and Sequencing function is carried out via the Default L2-Specific Sublayer defined in [RFC3931]. For MPLS, these two functions (together with PSN Convergence) are carried out via the MPLS Control Word. Since these functions are different between MPLS and L2TPv3, interworking between the two may be necessary.
[RFC3985]のセクション5.4は、IPまたはMPLS PSN上擬似回線を可能にするために必要な各種のシムヘッダの目的を説明します。 L2TPv3のために、ペイロードコンバージェンスおよびシーケンシング機能は、[RFC3931]で定義されたデフォルトL2特有のSublayerを介して行われます。 MPLSのために、この2つの機能（共にPSN収束有する）がMPLSコントロールワードを介して行われます。これらの機能は、MPLSとL2TPv3の間で異なるので、両者の間のインターワーキングを必要とすることができます。
The L2TP L2-Specific Sublayer and MPLS Control Word are shim headers, which in some cases are not necessary to be present at all. For example, an Ethernet PW with sequencing disabled will generally not require an MPLS Control Word or L2TP Default L2-Specific Sublayer to be present at all. In this case, Ethernet frames are simply sent from one PW to the other without any modification beyond the MPLS and L2TP/IP encapsulation and decapsulation.
L2TP L2特有の副層及びMPLS制御ワードは、いくつかの場合には全く存在である必要はないシムヘッダです。たとえば、無効シーケンシングとのイーサネットPWは、一般的に、すべての存在することがMPLS制御ワードまたはL2TPデフォルトL2特有の副層を必要としません。この場合、イーサネットフレームは単にMPLSおよびL2TP / IPカプセル化とカプセル化解除を超えそのまま他の1つのPWから送信されます。
The following section offers guidelines for how to interwork between L2TP and MPLS for those cases where the Payload Convergence, Sequencing, or PSN Convergence functions are necessary on one or both sides of the switching node.
以下のセクションは、ペイロードコンバージェンス、配列決定、またはPSN収束機能は、スイッチングノードの片側または両側に必要であるような場合のためにL2TPとMPLSとの間にインターワーキングする方法のガイドラインを提供します。
The MPLS Control Word consists of (from left to right):
MPLS制御ワードは、（左から右へ）で構成されています。
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 0| Reserved | Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-i. These bits are always zero in an MPLS PW PDU. It is not
necessary to map them to L2TP.
-ii. These six bits may be used for Payload Convergence depending on the PW type. For ATM, the first four of these bits are defined in [RFC4717]. These map directly to the bits defined in [RFC4454]. For Frame Relay, these bits indicate how to set the bits in the Frame Relay header that must be regenerated for L2TP as it carries the Frame Relay header intact.
-II。これらの6ビットはPWの種類に応じてペイロード収束のために使用することができます。 ATMのために、これらのビットの最初の4つは、[RFC4717]で定義されています。これらは、[RFC4454]で定義されたビットに直接マッピングします。フレーム・リレーのために、これらのビットは、それが完全なフレームリレーヘッダを運ぶようにL2TPのために再生されなければならないフレーム・リレー・ヘッダ内のビットを設定する方法を示しています。
-iii. L2TP determines its payload length from IP. Thus, this Length field need not be carried directly to L2TP. This Length field will have to be calculated and inserted for MPLS when necessary.
-III。 L2TPはIPからのペイロード長を決定します。したがって、この長さフィールドは、L2TPに直接運ばれる必要がありません。この長さフィールドは、必要なときにMPLSのために計算して挿入する必要があります。
-iv. The Default L2-Specific Sublayer has a sequence number with different semantics than that of the MPLS Control Word. This difference eliminates the possibility of supporting sequencing across the MS-PW by simply carrying the sequence number through the switching point transparently. As such, sequence numbers MAY be supported by checking the sequence numbers of packets arriving at the switching point and regenerating a new sequence number in the appropriate format for the PW on egress. If this type of sequence interworking at the switching node is not supported, and a T-PE requests sequencing of all packets via the L2TP control channel during session setup, the switching node SHOULD NOT allow the session to be established by sending a CDN message with Result Code set to 31 "Sequencing not supported".
-iv。デフォルトL2特有のサブレイヤは、MPLS制御ワードとは異なるセマンティクスを持つシーケンス番号を有しています。この差は、単に透過切り替えポイントを介してシーケンス番号を搬送することにより、MS-PWを横切って配列決定をサポートする可能性を排除します。このように、シーケンス番号は、スイッチングポイントに到着するパケットのシーケンス番号をチェックし、出力にPWのために適切なフォーマットで新しいシーケンス番号を再生によって支持されてもよいです。スイッチングノードでの配列インターワーキングのこのタイプはサポートされておらず、T-PEは、セッションセットアップ中L2TP制御チャネルを介してすべてのパケットの順序を要求した場合、交換ノードは、セッションとCDNメッセージを送信することによって確立されることを可能にするべきではありません31に設定し、結果コードは「順序がサポートされていません」。
Single-segment pseudowires are signaled using the Virtual Circuit Connectivity Verification (VCCV) parameter included in the interface parameter field of the PWid FEC TLV or the interface parameter sub-TLV of the Generalized PWid FEC TLV as described in [RFC5085]. When a switching point exists between PE nodes, it is required to be able to continue operating VCCV end-to-end across a switching point and to provide the ability to trace the path of the MS-PW over any number of segments.
単一セグメント疑似回線は、[RFC5085]に記載されているようにPWID FEC TLV又は一般PWID FEC TLVのインタフェースパラメータサブTLVのインタフェースパラメータフィールドに含まれる仮想回線接続検証（VCCV）パラメータを使用してシグナリングされます。切り替え点がPEノード間に存在する場合、オペレーティングVCCVのエンドツーエンドのスイッチングポイントを横断を続行すると、任意の数のセグメント上MS-PWの経路を追跡する能力を提供できることが要求されます。
This document provides a method for achieving these two objectives. This method is based on reusing the existing VCCV Control Word (CW) and decrementing the TTL of the PW label at each S-PE in the path of the MS-PW.
この文書では、これらの2つの目的を達成するための方法を提供します。この方法は、既存のVCCV制御語（CW）を再利用し、MS-PWの経路内の各S-PEでPWラベルのTTLをデクリメントに基づいています。
When an MS-PW includes SS-PWs that use the L2TPv3, the MPLS PW OAM MUST be terminated at the S-PE connecting the L2TPv3 and MPLS segments. Status information received in a particular PW segment can then be used to generate the appropriate status messages on the following PW segment. In the case of L2TPV3, the status bits in the circuit status AVP defined in Section 5.4.5 of [RFC3931] and Extended Circuit Status Values defined in [RFC5641] can be mapped directly to the PW status bits defined in Section 5.4.3 of [RFC4447].
MS-PWは、L2TPv3のを使用するSS-のPWを含む場合、MPLS PW OAMは、L2TPv3の及びMPLSセグメントを接続するS-PEで終端されなければなりません。特定のPWセグメントで受信されたステータス情報は、次のPWセグメント上の適切なステータスメッセージを生成するために使用することができます。 L2TPV3の場合には、[RFC3931]のセクション5.4.5で定義され、[RFC5641]で定義される回路状態値を拡張回路状態AVP内のステータス・ビットは、セクション5.4.3で定義されたPWステータスビットに直接マッピングすることができます[RFC4447]。
VCCV messages are specific to the MPLS data plane and cannot be used for an L2TPv3 PW segment. Therefore, the S-PE MUST NOT send the VCCV parameter included in the interface parameter field of the PWid FEC TLV or the sub-TLV interface parameter of the Generalized PWid FEC TLV. It might be possible to translate VCCV messages from L2TPv3 PW segments to MPLS PW segments and vice versa; however, this topic is left for further study.
VCCVメッセージはMPLSデータプレーンに対して特異的であるとのL2TPv3 PWセグメントのために使用することができません。従って、S-PEは、PWID FEC TLV又は一般PWID FEC TLVのサブTLVインターフェイスパラメータのインタフェースパラメータフィールドに含まVCCVパラメータを送ってはいけません。 MPLS PWセグメント及びその逆へのL2TPv3 PWセグメントからVCCVメッセージを翻訳することは可能かもしれません。ただし、このトピックでは、さらなる研究のために残されています。
As stated above, the S-PE MUST perform a standard MPLS label swap operation on the MPLS PW label. By the rules defined in [RFC3032], the PW label TTL MUST be decreased at every S-PE. Once the PW label TTL reaches the value of 0, the packet is sent to the control plane to be processed. Hence, by controlling the PW TTL value of the PW label, it is possible to select exactly which S-PE will respond to the VCCV packet.
上述したように、S-PEは、MPLS PWラベルに標準MPLSラベルスワップ操作を実行しなければなりません。 [RFC3032]で定義されたルールによって、PWラベルTTLは、各S-PEで減少しなければなりません。 PWラベルTTLが0の値に達すると、パケットを処理する制御プレーンに送られます。したがって、PWラベルのPW TTL値を制御することで、S-PEは、VCCVパケットに応答するかを正確に選択することが可能です。
Similarly to SS-PW, MS-PW VCCV capabilities are signaled using the VCCV parameter included in the interface parameter field of the PWid FEC TLV or the sub-TLV interface parameter of the Generalized PWid FEC TLV as described in [RFC5085].
同様にSS-PWに、MS-PWのVCCV機能は、[RFC5085]に記載されているようにPWID FEC TLVのインタフェースパラメータフィールドまたは一般PWID FEC TLVのサブTLVインターフェイスパラメータに含まVCCVパラメータを使用してシグナリングされます。
In Figure 3, T-PE1 uses the VCCV parameter included in the interface parameter field of the PWid FEC TLV or the sub-TLV interface parameter of the Generalized PWid FEC TLV to indicate to the far-end T-PE2 what VCCV capabilities T-PE1 supports. This is the same VCCV parameter as would be used if T-PE1 and T-PE2 were connected directly. S-PE2, which is a PW switching point, as part of the adaptation function for interface parameters, processes locally the VCCV parameter then passes it to T-PE2. If there were multiple S-PEs on the path between T-PE1 and T-PE2, each would carry out the same processing, passing along the VCCV parameter. The local processing of the VCCV parameter removes CC Types specified by the originating T-PE that are not supported on the S-PE. For example, if T-PE1 indicates that it supports CC Types 1, 2, and 3, then the S-PE removes the Router Alert CC Type 2, leaving the rest of the TLV unchanged, and passes the modified VCCV parameter to the next S-PE along the path.
図3において、T-PE1は、遠端T-PE2何VCCV能力を示すために、PWID FEC TLV又は一般PWID FEC TLVのサブTLVインターフェイスパラメータのインタフェースパラメータフィールドに含まVCCVパラメータを使用してT- PE1はサポートしています。これは、T-PE1及びT-PE2が直接接続された場合に使用されるのと同じVCCVパラメータです。 PW切り替えポイントであるS-PE2は、インターフェイスパラメータの適応機能の一部として、VCCVパラメータは、次にT-PE2に渡しローカルに処理します。複数のS-PEがT-PE1及びT-PE2間の経路上にあった場合、それぞれがVCCVパラメータに沿って通過する、同様の処理を行うことになります。 VCCVパラメータの局所的な処理は、S-PEにサポートされていない元のT-PEで指定されたCCタイプを除去します。 T-PE1は、それがCCタイプ1、2、および3をサポートしていることを示している場合、例えば、その後、S-PEは不変TLVの残りの部分を残して、ルータ警告CCタイプ2を除去し、次のように変更VCCVパラメータを渡します経路に沿ったS-PE。
The far end T-PE (T-PE2) receives the VCCV parameter indicating only the CC Types that are supported by the initial T-PE (T-PE1) and all S-PEs along the PW path.
遠端T-PE（T-PE2）は、初期T-PE（T-PE1）及びPWの経路に沿った全てのS-PESでサポートされている唯一のCCタイプを示すVCCVパラメータを受信します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bit 0 (0x01) - Type 1: PWE3 Control Word with 0001b as first nibble as defined in [RFC4385] Bit 1 (0x02) - Type 2: MPLS Router Alert Label Bit 2 (0x04) - Type 3: MPLS Demultiplexor PW Label with TTL == 1 (Type 3).
ビット0（0×01） - タイプ1：PWE3コントロールワードで定義されたように、第1のニブルとして0001Bと[RFC4385]のビット1（0×02） - タイプ2：MPLSルータ警告ラベルビット2（0×04） - タイプ3：MPLSデマルチプレクサPWラベルとTTL == 1（タイプ3）。
VCCV CC Type 1 can be used for MS-PWs. However, if the CW is enabled on user packets, VCCV CC Type 1 MUST be used according to the rules in [RFC5085]. When using CC Type 1 for MS-PWs, the PE transmitting the VCCV packet MUST set the TTL to the appropriate value to reach the destination S-PE. However, if the packet is destined for the T-PE, the TTL can be set to any value that is sufficient for the packet to reach the T-PE.
VCCVのCCタイプ1は、MS-PWのために使用することができます。 CWは、ユーザパケットに対して有効になっている場合は、VCCVのCCタイプ1は、[RFC5085]のルールに従って使用しなければなりません。 MS-のPW用CCタイプ1を使用する場合、VCCVパケットを送信PE先S-PEに到達するために適切な値にTTLを設定しなければなりません。パケットは、T-PE宛である場合は、TTLは、パケットがT-PEに到達するために十分な任意の値に設定することができます。
VCCV CC Type 2 is not supported for MS-PWs and MUST be removed from a VCCV parameter field by the S-PE.
VCCVのCCタイプ2は、MS-PWのためにサポートされていないため、S-PEによりVCCVパラメータフィールドから除去されなければなりません。
VCCV CC Type 3 can be used for MS-PWs; however, if the CW is enabled, VCCV Type 1 is preferred according to the rules in [RFC5085]. Note that for using the VCCV Type 3, TTL method, the PE will set the PW label TTL to the appropriate value necessary to reach the target PE; otherwise, the VCCV packet might be forwarded over the AC to the Customer Premise Equipment (CPE).
VCCVのCCタイプ3は、MS-PWのために使用することができます。 CWが有効になっている場合は、VCCVタイプ1は、[RFC5085]のルールに従って好ましいです。 VCCVタイプ3、TTL方式を使用するため、PEは、ターゲットPEに到達するために必要な適切な値にPWラベルTTLを設定することに注意してください。それ以外の場合は、VCCVパケットは、顧客宅内機器（CPE）にACを介して転送される可能性があります。
This document specifies four VCCV operations:
この文書では、4つのVCCV操作を指定します。
-i. End-to-end MS-PW connectivity verification. This operation
enables the connectivity of the MS-PW to be tested from
source T-PE to destination T-PE. In order to do this, the
sending T-PE must include the FEC used in the last segment
of the MS-PW to the destination T-PE in the VCCV-Ping echo
request. This information is either configured at the
sending T-PE or is obtained by processing the corresponding
sub-TLVs of the optional SP-PE TLV, as described below.
-ii. Partial MS-PW connectivity verification. This operation enables the connectivity of any contiguous subset of the segments of an MS-PW to be tested from the source T-PE or a source S-PE to a destination S-PE or T-PE. Again, the FEC used on the last segment to be tested must be included in the VCCV-Ping echo request message. This information is determined by the sending T-PE or S-PE as in (i) above.
-II。部分的なMS-PWの接続性検証。この操作は、MS-PWのセグメントの任意の連続部分集合の接続がソースT-PEまたは先S-PEまたはT-PEとソースS-PEから試験することを可能にします。再び、FECはVCCV-Pingのエコー要求メッセージに含まれていなければならない試験すべき最後のセグメントで使用されます。この情報には、上記（i）のように送信T-PEまたはS-PEにより決定されます。
-iii. MS-PW path verification. This operation verifies the path of the MS-PW, as returned by the SP-PE TLV, against the actual data path of the MS-PW. The sending T-PE or S-PE iteratively sends a VCCV echo request to each S-PE along the MS-PW path, using the FEC for the corresponding MS-PW segment in the SP-PE TLV. If the SP-PE TLV information is correct, then a VCCV echo reply showing that this is a valid router for the FEC will be received. However, if the SP-PE TLV information is incorrect, then this operation enables the first incorrect switching point to be determined, but not the actual path of the MS-PW beyond that. This operation cannot be used when the MS-PW is statically configured or when the SP-PE TLV is not supported. The processing of the PW Switching Point PE TLV used for this operation is described below. This operation is OPTIONAL.
-III。 MS-PWパス検証。 MS-PWの実際のデータパスに対して、SP-PE TLVによって返されるこの操作は、MS-PWのパスを検証します。送信T-PEまたはS-PEは反復SP-PE TLVに対応するMS-PWセグメントに対してFECを使用して、MS-PWの経路に沿って各S-PEへVCCVエコー要求を送信します。 SP-PE TLV情報が正しい場合、VCCVは、これはFECのために有効なルータが受信されていることを示す返信エコー。 SP-PE TLV情報が正しくない場合は、この動作は、第1の間違ったスイッチング点を決定することができ、それを超えてMS-PWのない実際のパス。 MS-PWが静的に構成されている場合、またはSP-PE TLVがサポートされていない場合、この操作は使用できません。この操作に使用されるPWスイッチング・ポイントPE TLVの処理については後述します。この操作はオプションです。
-iv. MS-PW path trace. This operation traces the data path of the MS-PW using FECs included in the Target FEC stack TLV [RFC4379] returned by S-PEs or T-PEs in an echo reply message. The sending T-PE or S-PE uses this information to recursively test each S-PE along the path of the MS-PW in a single operation in a similar manner to LSP trace. This operation is able to determine the actual data path of the MS-PW, and can be used for both statically configured and signaled MS-PWs. Support for this operation is OPTIONAL.
-iv。 MS-PWパストレース。この操作は、のFECを用いたMS-PWのデータパスをトレースエコー応答メッセージでS-PESまたはT-PESによって返されたターゲットFECスタックTLV [RFC4379]に含まれます。送信T-PEまたはS-PEは、再帰的にLSPトレースと同様に、単一の操作でMS-PWの経路に沿って各S-PEをテストするためにこの情報を使用します。この操作は、MS-PWの実際のデータパスを決定することができる、そして静的に設定し、MS-のPWのシグナリングの両方に使用することができます。この操作のサポートはオプションです。
Note that the above operations rely on intermediate S-PEs and/or the destination T-PE to include the PW Switching Point PE TLV as a part of the MS-PW setup process, or to include the Target FEC stack TLV in the VCCV echo reply message. For various reasons, e.g., privacy or security of the S-PE/T-PE, this information may not be available to the source T-PE. In these cases, manual configuration of the FEC MAY still be used.
上記動作はPWはMS-PWのセットアッププロセスの一部としてポイントPE TLVを切り替え、またはVCCVエコーにターゲットFECスタックTLVを含むことを含むように中間S-PES及び/又は宛先T-PEに依存していることに注意してくださいメッセージを返信します。 S-PE / T-PEの様々な理由、例えば、プライバシーやセキュリティのために、この情報はソースT-PEに利用可能ではないかもしれません。これらのケースでは、FECの手動設定は、まだ使用されるかもしれません。
The challenge for the control plane is to be able to build the VCCV echo request packet with the necessary information to reach the desired S-PE or T-PE, for example, the target FEC 128 PW sub-TLV of the downstream PW segment that the packet is destined for. This could be even more difficult in situations in which the MS-PW spans different providers and Autonomous Systems.
制御プレーンのための課題は、例えば、所望のS-PEまたはT-PEに到達するために必要な情報をVCCVエコー要求パケットを構築することができるようにその下流PWセグメントのターゲットFEC 128 PWサブTLVでありますパケットを宛てています。これは、MS-PWが異なるプロバイダと自律システムにまたがるする状況ではさらに困難である可能性があります。
For example, in Figure 3, T-PE1 has the FEC 128 of the segment (PW segment 1), but it does not readily have the information required to compose the FEC 128 of the following segment (PW segment 3), if a VCCV echo request is to be sent to T-PE2. This can be achieved by the methods described in the following subsections.
例えば、図3において、T-PE1は、セグメント（PWセグメント1）のFEC 128を有するが、VCCV場合には、容易に、次のセグメント（PWセグメント3）のFEC 128を構成するために必要な情報を持っていませんエコー要求はT-PE2に送信します。これは、以下のサブセクションで説明した方法により達成することができます。
When performing a partial or end-to-end connectivity or path verification, the sender of the echo request message requires the FEC of the last segment to the target S-PE/T-PE node. This information can either be configured manually or be obtained by inspecting the corresponding sub-TLVs of the PW Switching Point PE TLV.
部分的またはエンドツーエンド接続またはパスの検証を行う際に、エコー要求メッセージの送信者は、ターゲットS-PE / T-PEノードに最後のセグメントのFECを必要とします。この情報は、手動で設定することができ、またはポイントPE TLVスイッチングPWの対応するサブTLVを検査することによって得られます。
The necessary SP-PE sub-TLVs are:
必要SP-PEサブTLVがあります。
Type Description 0x01 PWid of last PW segment traversed 0x03 Local IP address of PW Switching Point 0x04 Remote IP address of last PW Switching Point traversed or of the T-PE
最後のPWセグメントのタイプ説明0x01のPWIDは、ポイントを切り替え、最後のPWのPWスイッチング・ポイント0x04のリモートIPアドレスの0x03のローカルIPアドレスが横断またはT-PEのトラバース
When performing an OPTIONAL MS-PW path trace operation, the T-PE will automatically learn the target FEC by probing, one by one, the S-PEs of the MS-PW path, using the FEC returned in the Target FEC stack of the previous VCCV echo reply.
OPTIONAL MS-PWパストレース動作を行う場合、T-PEが自動的に、一つ一つをプロービングすることによってターゲットFECを学ぶことが、FECを使用したMS-PWパスのS-PEは、のターゲットFECスタックに返さ前のVCCVエコー応答。
Upon receiving a VCCV echo request, the control plane on S-PEs (or the target node of each segment of the MS-PW) validates the request and responds to the request with an echo reply consisting of a return code of 8 (label switched at stack depth) indicating that it is an S-PE and not the egress router for the MS-PW.
VCCVエコー要求を受信すると、S-PES上の制御プレーン（またはMS-PWの各セグメントのターゲット・ノード）は、要求を検証し、（ラベルが切り替え8のリターン・コードから成るエコー応答で要求に応答しますスタックの深さで）、それはS-PEはなく、MS-PW用の出口ルータであることを示します。
S-PEs that wish to reveal their downstream next-hop in a trace operation should include the FEC of the downstream PW segment in the Target FEC stack (as per Sections 3.2 and 4.5 of [RFC4379]) of the echo reply message. FEC 128 PWs MUST use the format shown in Section 3.2.9 of [RFC4379] for the sub-TLV in the Target FEC stack, while FEC 129 PWs MUST use the format shown in Section 3.2.10 of [RFC4379] for the sub-TLV in the Target FEC stack. Note that an S-PE MUST NOT include this FEC information in the reply if it has been configured not to do so for administrative reasons or for reasons explained previously.
トレース操作でそれらの下流の次のホップを明らかにしたいS-PEはエコー応答メッセージ（セクション3.2と[RFC4379]の4.5の通り）ターゲットFECスタックの下流PWセグメントのFECを含むべきです。 FEC 129 PWSはサブために[RFC4379]のセクション3.2.10に示す形式を使用する必要がありながら、FEC 128のPWは、ターゲットFECスタックにおけるサブTLVのために[RFC4379]のセクション3.2.9に示すようなフォーマットを使用しなければなりませんターゲットFECスタックのTLV。管理上の理由で、または以前に説明の理由のためにそうしないように設定されている場合、S-PEは、応答にこのFEC情報を含んではならないことに留意されたいです。
If the node is the T-PE or the egress node of the MS-PW, it responds to the echo request with an echo reply with a return code of 3 (Egress Router).
ノードは、T-PEまたはMS-PWの出口ノードである場合、それは3（出口ルータ）の戻りコードを有するエコー応答エコー要求に応答します。
The operation to be taken by the node receiving the echo reply in response to an echo request depends on the VCCV mode of operation described above. See Section 9.5.2 for detailed procedures.
エコー要求に応答してエコー応答を受信したノードによって取られるべき動作は、上述した動作のVCCVモードに依存します。詳細な手順については、セクション9.5.2を参照してください。
There are two similar methods of verifying the MS-PW path: Path Trace and Path Verification. Path Trace does not use the LDP control plane to obtain information on the path to verify, so this method is well suited if portions of the MS-PW are statically configured SS-PWs. The Path Verification method relies on information obtained from the LDP control plane, and hence offers better verification of the current forwarding behavior compared to the LDP signaled forwarding information of the MS-PW path. However, in the case where there are statically signaled SS-PWs in the MS-PW path, the path information is unavailable and must be programmed manually.
パストレースとパス検証：MS-PWパスを検証する2つの類似の方法があります。パストレースを確認するために、パスの情報を取得するためにLDP制御プレーンを使用していないので、MS-PWの部分が静的SS-PWを構成している場合は、この方法が適しています。パスの検証方法は、LDP制御プレーンから得られる情報に依存し、したがってLDPに比べ現在の転送動作のより良好な検証を提供するMS-PWパスの情報を転送するシグナリング。しかし、静的MS-PWパスにSS-のPWがシグナリングされる場合には、経路情報が利用できない、手動でプログラムされなければなりません。
In Figure 3, if T-PE1, S-PE, and T-PE2 support Control Word, the PW control plane will automatically negotiate the use of the CW. VCCV CC Type 3 will function correctly whether or not the CW is enabled on the PW. However, VCCV Type 1 (which can be use for end-to-end verification only) is only supported if the CW is enabled.
T-PE1、S-PE、およびT-PE2は、コントロールワードをサポートしている場合、図3においては、PW制御プレーンは自動的にCWの使用をネゴシエートします。 VCCVのCCタイプ3は、CWがPWで有効になっているかどうかを正しく機能します。 CWが有効になっている場合は、（唯一のエンド・ツー・エンドの検証のために使用することができる）VCCVタイプ1のみがサポートされています。
At the S-PE, the data path operations include an outer label pop, inner label swap, and new outer label push. Note that there is no requirement for the S-PE to inspect the CW. Thus, the end-to-end connectivity of the multi-segment pseudowire can be verified by performing all of the following steps:
S-PEでは、データパス操作は、外側ラベルポップ、インナーラベルスワップ、および新しい外装ラベルプッシュを含みます。 S-PEは、CWを検査するための必要はないことに留意されたいです。従って、マルチセグメントの疑似回線のエンドツーエンド接続は、以下の工程の全てを実行することによって確認することができます。
-i. The T-PE forms a VCCV-Ping echo request message with the FEC
matching that of the last PW segment to the destination
T-PE.
-ii. The T-PE sets the inner PW label TTL to the exact value to allow the packet to reach the far-end T-PE. (The value is determined by counting the number of S-PEs from the control plane information.) Alternatively, if CC Type 1 is supported, the packet can be encapsulated according to CC Type 1 in [RFC5085].
-II。 T-PEは、パケットが遠端T-PEに到達することを可能にする正確な値に内側PWラベルTTLを設定します。 CCタイプ1がサポートされている場合（値は、制御プレーンの情報からS-PEの数をカウントすることによって決定される。）あるいは、パケットは[RFC5085]でのCCタイプ1に従ってカプセル化することができます。
-iii. The T-PE sends a VCCV packet that will follow the exact same data path at each S-PE as that taken by data packets.
-III。 T-PEは、データパケットによって取られるように、各S-PEでまったく同じデータ・パスに続くVCCVパケットを送信します。
-iv. The S-PE may perform an outer label pop, if Penultimate Hop Popping (PHP) is disabled, and will perform an inner label swap with TTL decrement and a new outer label push.
-iv。 S-PEは、最後から二番目のホップポッピング（PHP）が無効である場合、外側のラベルポップを実行してもよいし、TTLの減少と新たな外装ラベルプッシュ付きインナーラベルスワップを実行します。
-v. There is no requirement for the S-PE to inspect the CW.
-v。 S-PEはCWを検査するための要件はありません。
-vi. The VCCV packet is diverted to VCCV control processing at the destination T-PE.
-vi。 VCCVパケットは宛先T-PEで制御処理をVCCVに転用されます。
-vii. The destination T-PE replies using the specified reply mode, i.e., reverse PW path or IP path.
-VII。宛先T-PE、すなわち、PWパスまたはIP経路を逆に、指定された応答モードを使用して応答します。
In order to trace part of the multi-segment pseudowire, the TTL of the PW label may be used to force the VCCV message to 'pop out' at an intermediate node. When the TTL expires, the S-PE can determine that the packet is a VCCV packet either by checking the CW or (if the CW is not in use) by checking for a valid IP header with UDP destination port 3503. The packet should then be diverted to VCCV processing.
マルチセグメント疑似回線の一部を追跡するために、PWラベルのTTLは、中間ノードに「飛び出し」にVCCVメッセージを強制するために使用することができます。 TTLが期限切れになると、S-PEは、（CWが使用中でない場合）、パケットはCWをチェックすることによって、またはいずれかのVCCVパケットであると判断することができるUDP宛先ポート3503を持つ有効なIPヘッダのパケットをチェックすることによりべき次いでVCCV処理に転用します。
In Figure 3, if T-PE1 sends a VCCV message with the TTL of the PW label equal to 1, the TTL will expire at the S-PE. T-PE1 can thus verify the first segment of the pseudowire.
T-PE1が1に等しいPWラベルのTTLとVCCVメッセージを送信する場合、図3において、TTLは、S-PEで期限切れとなります。 T-PE1は、このように疑似回線の最初のセグメントを検証することができます。
The VCCV packet is built according to [RFC4379], Section 3.2.9 for FEC 128, or Section 3.2.10 for FEC 129. All the information necessary to build the VCCV LSP ping packet is collected by inspecting the S-PE TLVs.
VCCVパケットは、[RFC4379]に従って構築されたFEC 128については、セクション3.2.9、又はFEC 129 VCCV LSPのpingパケットを構築するために必要なすべての情報については、セクション3.2.10を、S-PE TLVを検査することによって収集されます。
Note that this use of the TTL is subject to the caution expressed in [RFC5085]. If a penultimate LSR between S-PEs or between an S-PE and a T-PE manipulates the PW label TTL, the VCCV message may not emerge from the MS-PW at the correct S-PE.
TTLのこの使用は[RFC5085]で表さ注意の対象であることに留意されたいです。 S-PE間またはS-PEの間であれば最後から二番目のLSR及びT-PEは、PWラベルTTLを操作し、VCCVメッセージが正しいS-PEでMS-PWから出なくてもよいです。
Assuming that all nodes along an MS-PW support the Control Word CC Type 3, VCCV between S-PEs may be accomplished using the PW label TTL as described above. In Figure 3, the S-PE may verify the path between it and T-PE2 by sending a VCCV message with the PW label TTL set to 1. Given a more complex network with multiple S-PEs, an S-PE may verify the connectivity between it and an S-PE two segments away by sending a VCCV message with the PW label TTL set to 2. Thus, an S-PE can diagnose connectivity problems by successively increasing the TTL. All the information needed to build the proper VCCV echo request packet (as described in [RFC4379], Sections 3.2.9 or 3.2.10) is obtained automatically from the LDP label mapping that contains S-PE TLVs.
上記のようにMS-PWに沿ってすべてのノードが制御ワードのCCタイプ3をサポートすると仮定すると、S-PE間VCCVは、PWラベルTTLを用いて達成することができます。図3において、S-PEは、複数のS-PESとのより複雑なネットワークを考えると1に設定PWラベルTTLとVCCVメッセージを送信することによりそれとT-PE2間のパスを確認してもよい、S-PEは、検証することができます二つのセグメント離れしたがって2に設定PWラベルTTLとVCCVメッセージを送信することによりそれとS-PEとの間の接続は、S-PEは、連続的にTTLを増加させることにより、接続の問題を診断することができます。 （[RFC4379]に記載されているように、セクション3.2.9または3.2.10）適切VCCVエコー要求パケットを構築するために必要なすべての情報を、S-PEのTLVが含まれているLDPラベルマッピングから自動的に取得されます。
As an example, in Figure 3, VCCV trace can be performed on the MS-PW originating from T-PE1 by a single operational command. The following process ensues:
一例として、図3に、VCCVトレースは、単一の動作指令によりT-PE1からMS-PWの発信を行うことができます。次のプロセスが続きます。
-i. T-PE1 sends a VCCV echo request with TTL set to 1 and a FEC
containing the pseudowire information of the first segment
(PW1 between T-PE1 and S-PE) to S-PE for validation. If FEC
Stack Validation is enabled, the request may also include an
additional sub-TLV such as LDP Prefix and/or RSVP LSP,
dependent on the type of transport tunnel the segmented PW
is riding on.
-ii. S-PE validates the echo request with the FEC. Since it is a switching point between the first and second segment, it builds an echo reply with a return code of 8 and sends the echo reply back to T-PE1.
-II。 S-PEは、FECを有するエコー要求を検証します。それは第一と第二のセグメントの間の切り替えポイントであるので、8の戻りコードとエコー応答を構築し、バックT-PE1へエコー応答を送信します。
-iii. T-PE1 builds a second VCCV echo request based on the information obtained from the control plane (SP-PE TLV). It then increments the TTL and sends it out to T-PE2. Note that the VCCV echo request packet is switched at the S-PE data path and forwarded to the next downstream segment without any involvement from the control plane.
-III。 T-PE1は、制御プレーン（SP-PE TLV）から得られた情報に基づいて、第2のVCCVエコー要求を構築します。その後、TTLをインクリメントし、T-PE2に送出します。 VCCVエコー要求パケットがS-PEデータパスに切り替えて、制御プレーンからの関与なしに次の下流のセグメントに転送されることに留意されたいです。
-iv. T-PE2 receives and validates the echo request with the FEC. Since T-PE2 is the destination node or the egress node of the MS-PW, it replies to T-PE1 with an echo reply with a return code of 3 (Egress Router).
-iv。 T-PE2は、受信したFEC有するエコー要求を検証します。 T-PE2は、宛先ノードまたはMS-PWの出口ノードであるので、3（出口ルータ）の戻りコードを有するエコー応答とT-PE1へ返信します。
-v. T-PE1 receives the echo reply from T-PE2. T-PE1 is made aware that T-PE2 is the destination of the MS-PW because the echo reply has a return code of 3. The trace process is completed.
-v。 T-PE1はT-PE2からエコー応答を受信します。 T-PE1は、エコー応答がトレース処理が完了し3の戻りコードを有しているため、T-PE2は、MS-PWの宛先であることを知らされます。
If no echo reply is received, or an error code is received from a particular PE, the trace process MUST stop immediately, and packets MUST NOT be sent further along the MS-PW.
いかなるエコー応答が受信されない、またはエラー・コードが特定のPEから受信した場合、トレース処理を直ちに停止しなければならない、そして、パケットはMS-PWに沿ってさらに送ってはいけません。
For more detail on the format of the VCCV echo packet, refer to [RFC5085] and [RFC4379]. The TTL here refers to that of the inner (PW) label TTL.
VCCVエコーパケットのフォーマットに関する詳細については、[RFC5085]及び[RFC4379]を参照。ここで、TTLは、内側（PW）ラベルTTLのものを指します。
As an example, in Figure 3, VCCV trace can be performed on the MS-PW originating from T-PE1 by a single operational command. The following OPTIONAL process ensues:
一例として、図3に、VCCVトレースは、単一の動作指令によりT-PE1からMS-PWの発信を行うことができます。次の任意のプロセスが続きます。
-i. T-PE1 sends a VCCV echo request with TTL set to 1 and a FEC
containing the pseudowire information of the first segment
(PW1 between T-PE1 and S-PE) to S-PE for validation. If FEC
Stack Validation is enabled, the request may also include an
additional sub-TLV such as LDP Prefix and/or RSVP LSP,
dependent on the type of transport tunnel the segmented PW
is riding on.
-ii. The S-PE validates the echo request with the FEC.
-II。 S-PEは、FECを有するエコー要求を検証します。
-iii. The S-PE builds an echo reply with a return code of 8 and sends the echo reply back to T-PE1, appending the FEC 128 information for the next segment along the MS-PW to the VCCV echo reply packet using the Target FEC stack TLV (as per Sections 3.2 and 4.5 of [RFC4379]).
-III。 S-PEは、8の戻りコードとエコー応答を構築し、バックT-PE1へエコー応答を送信し、ターゲットFECスタックを使用VCCVエコー応答パケットにMS-PWに沿って次のセグメントのためのFEC 128の情報を付加しますTLV（セクション3.2および4.5の通り、[RFC4379]）。
-iv. T-PE1 builds a second VCCV echo request based on the information obtained from the FEC stack TLV received in the previous VCCV echo reply. It then increments the TTL and sends it out to T-PE2. Note that the VCCV echo request packet is switched at the S-PE data path and forwarded to the next downstream segment without any involvement from the control plane.
-iv。 T-PE1は、TLVが前のVCCVエコー応答で受信したFECスタックから得られる情報に基づいて、第2のVCCVエコー要求を構築します。その後、TTLをインクリメントし、T-PE2に送出します。 VCCVエコー要求パケットがS-PEデータパスに切り替えて、制御プレーンからの関与なしに次の下流のセグメントに転送されることに留意されたいです。
-v. T-PE2 receives and validates the echo request with the FEC. Since T-PE2 is the destination node or the egress node of the MS-PW, it replies to T-PE1 with an echo reply with a return code of 3 (Egress Router).
-v。 T-PE2は、受信したFEC有するエコー要求を検証します。 T-PE2は、宛先ノードまたはMS-PWの出口ノードであるので、3（出口ルータ）の戻りコードを有するエコー応答とT-PE1へ返信します。
-vi. T-PE1 receives the echo reply from T-PE2. T-PE1 is made aware that T-PE2 is the destination of the MS-PW because the echo reply has a return code of 3. The trace process is completed.
-vi。 T-PE1はT-PE2からエコー応答を受信します。 T-PE1は、エコー応答がトレース処理が完了し3の戻りコードを有しているため、T-PE2は、MS-PWの宛先であることを知らされます。
If no echo reply is received, or an error code is received from a particular PE, the trace process MUST stop immediately, and packets MUST NOT be sent further along the MS-PW.
いかなるエコー応答が受信されない、またはエラー・コードが特定のPEから受信した場合、トレース処理を直ちに停止しなければならない、そして、パケットはMS-PWに沿ってさらに送ってはいけません。
For more detail on the format of the VCCV echo packet, refer to [RFC5085] and [RFC4379]. The TTL here refers to that of the inner (PW) label TTL.
VCCVエコーパケットのフォーマットに関する詳細については、[RFC5085]及び[RFC4379]を参照。ここで、TTLは、内側（PW）ラベルTTLのものを指します。
In the PW switching with attachment circuits case (Figure 2), PW status messages indicating PW or attachment circuit faults MUST be mapped to fault indications or OAM messages on the connecting AC as defined in [PW-MSG-MAP].
PWは、アタッチメント回路ケース（図2）との切り替えで、PW又は[PW-MSG-MAP]で定義されるように接続回線障害が接続ACに指示又はOAMメッセージをフォールトにマッピングされなければならないことを示すPWステータスメッセージ。
In the PW control plane switching case (Figure 3), there is no attachment circuit at the S-PE, but the two PWs are connected together. Similarly, the status of the PWs is forwarded unchanged from one PW to the other by the control plane switching function. However, it may sometimes be necessary to communicate fault status of one of the locally attached PW segments at an S-PE. For LDP, this can be accomplished by sending an LDP notification message containing the PW status TLV, as well as an OPTIONAL PW Switching Point PE TLV as follows:
PW制御プレーンスイッチングの場合（図3）において、そこにS-PEでない接続回線ではないが、二つのPWが接続されます。同様のPWのステータスは、コントロールプレーンのスイッチング機能により他の1つのPWから不変転送されます。しかし、時々、S-PEでローカル接続PWセグメントの1つの障害状態を通信するために必要であってもよいです。 LDPのために、これは次のようにポイントPE TLVスイッチングPWステータスTLVを含むLDP通知メッセージを送信すること、ならびにOPTIONAL PWによって達成することができます。
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| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1| Status (0x0300) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1| Status Code=0x00000028 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type=0 | PW Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Status TLV | PWid FEC or Generalized ID FEC|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| PWid FEC or Generalized ID FEC (contd.) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| SP-PE TLV (0x096D) | SP-PE TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Variable Length Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Only one SP-PE TLV can be present in this message. This message is then relayed by each S-PE unchanged. The T-PE decodes the status message and the included SP-PE TLV to detect exactly where the fault occurred. At the T-PE, if there is no SP-PE TLV included in the LDP status notification, then the status message can be assumed to have originated at the remote T-PE.
唯一のSP-PE TLVは、このメッセージ中に存在することができます。このメッセージは、不変の各S-PEにより中継されます。 T-PEは、ステータスメッセージをデコードし、障害が発生した場所に含まSP-PE TLVは正確に検出します。存在する場合、T-PEで、全くSP-PE TLVは、ステータスメッセージがリモートT-PEで発生していると仮定することができ、LDP状態通知に含まれていません。
The merging of the received LDP status and the local status for the PW segments at an S-PE can be summarized as follows:
次のように受信したLDP状態およびS-PEでPWセグメントのローカルステータスのマージに要約することができます。
-i. When the local status for both PW segments is UP, the S-PE
passes any received AC or PW status bits unchanged, i.e.,
the status notification TLV is unchanged, but the PWid in
the case of a FEC 128 TLV is set to the value of the PW
segment of the next hop.
-ii. When the local status for any of the PW segments is at fault, the S-PE always sends the local status bits regardless of whether the received status bits from the remote node indicated that an upstream fault has cleared. AC status bits are passed along unchanged.
-II。 PWセグメントの任意のローカルステータスが故障している場合、S-PEは関係なく、常にリモート・ノードから受信したステータスビットは上流の障害がクリアされたことを示したかどうかのローカルステータスビットを送信します。 ACステータスビットは変更されずに渡されています。
The PW fault directions are defined as follows:
次のようにPW障害方向が定義されています。
+-------+
---PW1 Receive---->| |-----PW2 Transmit---->
S-PE1 | S-PE2 | S-PE3
<--PW1 Transmit----| |<----PW2 Receive------
+-------+
Figure 4: S-PE and PW Transmission/Reception Directions
図4：S-PEおよびPW送信/受信行き方
When a local fault is detected by the S-PE, a PW status message is sent in both directions along the PW. Since there are no attachment circuits on an S-PE, only the following status messages are relevant:
ローカル障害がS-PEにより検出された場合、PWステータスメッセージはPWに沿って両方向に送信されます。 S-PEには接続回線が存在しないので、唯一の次のステータスメッセージが関連しています。
0x00000008 - Local PSN-facing PW (ingress) Receive Fault
0x00000010 - Local PSN-facing PW (egress) Transmit Fault
Each S-PE needs to store only two 32-bit PW status words for each PW segment: one for local failures and one for remote failures (normally received from another PE). The first failure will set the appropriate bit in the 32-bit status word, and each subsequent failure will be ORed to the appropriate PW status word. In the case that the PW status word stores remote failures, this rule has the effect of a logical OR operation with the first failure received on the particular PW segment.
局所障害のための1つおよび（通常は別のPEから受け取った）リモート障害のための1つの各S-PEは、各PWセグメントの2つだけの32ビットPWステータスワードを格納する必要があります。最初の障害は、32ビット・ステータス・ワードの対応するビットを設定し、各後続の故障が適切なPWステータスワードにORされます。 PWステータスワード記憶リモート障害は、このルールは、特定のPWセグメント上で受信された最初の失敗の論理OR演算の効果を有する場合。
It should be noted that remote failures received on an S-PE are just passed along the MS-PW unchanged, while local failures detected an S-PE are signaled on both PW segments.
ローカル障害がS-PEは両方PWセグメント上でシグナリングされる検出ながら遠隔障害がS-PEで受信を単にそのままMS-PWに沿って通過していることに留意すべきです。
A T-PE can receive multiple failures from S-PEs along the MS-PW; however, only the failure from the remote closest S-PE will be stored (last PW status message received). The PW status word received is just ORed to any existing remote PW status already stored on the T-PE.
T-PEは、MS-PWに沿ってS-PESから複数の障害を受けることができます。しかし、遠隔最も近いS-PEからのみ障害が（最後PWステータスメッセージを受信）が格納されます。受信PW・ステータス・ワードは、単に既にT-PEに格納されている既存のリモートPW状態に論理和されます。
Given that there are two PW segments at a particular S-PE for a particular MS-PW (referring to Figure 4), there are four possible failure cases as follows:
次のように特定のMS-PWのための特定のS-PEで2つのPWセグメントが存在することを考える（図4を参照）は、4つの可能な故障の場合があります。
-i. PW2 Transmit direction fault -ii. PW1 Transmit direction fault -iii. PW2 Receive direction fault -iv. PW1 Receive direction fault
-私。 PW2送信方向の障害-II。 PW1送信方向の障害-III。 PW2は、方向フォルト-ivを受信します。 PW1は、方向フォルトを受け取ります
Once a PW status notification message is initiated at an S-PE for a particular PW status bit, any further status message for the same status bit (and received from an upstream neighbor) is processed locally and not forwarded until the S-PE original status error state is cleared.
PW状態通知メッセージは、特定のPWステータスビットのためのS-PEで開始同じステータス・ビットのための任意のさらなるステータスメッセージ（および上流隣接から受信した）局所的に処理され、S-PE元の状態までは転送されないされたらエラー状態がクリアされます。
Each S-PE along the MS-PW MUST store any PW status messages transiting it. If more than one status message with the same PW status bit set is received by a T-PE or S-PE, only the last PW status message is stored.
MS-PWに沿って各S-PEは、それを通過する任意のPWステータスメッセージを格納しなければなりません。同じPWステータスビットが設定された複数のステータスメッセージがT-PEまたはS-PEにより受信された場合、最後PWステータスメッセージが格納されています。
When this failure occurs, the S-PE will take the following actions:
この障害が発生した場合、S-PEは、次のアクションを取ることになります。
* Send a PW status message to S-PE3 containing "0x00000010 - Local PSN-facing PW (egress) Transmit Fault".
* " - ローカルPSNに面したPW（出力）送信障害を0x00000010" を含むS-PE3にPWステータスメッセージを送信します。
* Send a PW status message to S-PE1 containing "0x00000008 - Local PSN-facing PW (ingress) Receive Fault".
*含むS-PE1にPWステータスメッセージを送る "0x00000008 - ローカルPSNに面したPW（入力）障害を受信します"。
* Store 0x00000010 in the local PW status word for the PW segment toward S-PE3.
* S-PE3に向けたPWセグメントのローカルPWのステータスワードのストア0x00000010。
When this failure occurs, the S-PE will take the following actions:
この障害が発生した場合、S-PEは、次のアクションを取ることになります。
* Send a PW status message to S-PE1 containing "0x00000010 - Local PSN-facing PW (egress) Transmit Fault".
* " - ローカルPSNに面したPW（出力）送信障害を0x00000010" を含むS-PE1へのPWステータスメッセージを送信します。
* Send a PW status message to S-PE3 containing "0x00000008 - Local PSN-facing PW (ingress) Receive Fault".
*含むS-PE3にPWステータスメッセージを送る "0x00000008 - ローカルPSNに面したPW（入力）障害を受信します"。
* Store 0x00000010 in the local PW status word for the PW segment toward S-PE1.
* S-PE1に向けたPWセグメントのローカルPWのステータスワードのストア0x00000010。
When this failure occurs, the S-PE will take the following actions:
この障害が発生した場合、S-PEは、次のアクションを取ることになります。
* Send a PW status message to S-PE3 containing "0x00000008 - Local PSN-facing PW (ingress) Receive Fault".
*含むS-PE3にPWステータスメッセージを送る "0x00000008 - ローカルPSNに面したPW（入力）障害を受信します"。
* Send a PW status message to S-PE1 containing "0x00000010 - Local PSN-facing PW (egress) Transmit Fault".
* " - ローカルPSNに面したPW（出力）送信障害を0x00000010" を含むS-PE1へのPWステータスメッセージを送信します。
* Store 0x00000008 in the local PW status word for the PW segment toward S-PE3.
* S-PE3に向けたPWセグメントのローカルPWのステータスワードのストア0x00000008。
When this failure occurs, the S-PE will take the following actions:
この障害が発生した場合、S-PEは、次のアクションを取ることになります。
* Send a PW status message to S-PE1 containing "0x00000008 - Local PSN-facing PW (ingress) Receive Fault".
*含むS-PE1にPWステータスメッセージを送る "0x00000008 - ローカルPSNに面したPW（入力）障害を受信します"。
* Send a PW status message to S-PE3 containing "0x00000010 - Local PSN-facing PW (egress) Transmit Fault".
* " - ローカルPSNに面したPW（出力）送信障害を0x00000010" を含むS-PE3にPWステータスメッセージを送信します。
* Store 0x00000008 in the local PW status word for the PW segment toward S-PE1.
* S-PE1に向けたPWセグメントのローカルPWのステータスワードのストア0x00000008。
Remote PW status fault clearing messages received by an S-PE will only be forwarded if there are no corresponding local faults on the S-PE. (Local faults always supersede remote faults.)
S-PEに対応するローカルの障害が存在しない場合、S-PEが受信したメッセージをクリアするリモートPWステータスの障害にのみ転送されます。 （ローカルフォールトは常にリモート障害を優先します。）
Once the local fault has cleared, and there is no corresponding (same PW status bit set) remote fault, a PW status message is sent out to the adjacent PEs, clearing the fault.
ローカルフォールトがクリアされており、該当する（同じPWステータス・ビット・セット）リモート障害が存在しないと、PWステータスメッセージは、障害をクリアし、隣接するPEに送出されます。
When a PW status fault clearing message is forwarded, the S-PE will always send the SP-PE TLV associated with the PE that cleared the fault.
PWステータス故障除去メッセージが転送されると、S-PEは、常に障害をクリアPEに関連したSP-PE TLVを送信します。
When a PW status message is received that includes an SP-PE TLV, the SP-PE TLV information MAY be stored, along with the contents of the PW status Word according to the procedures described above. The SP-PE TLV stored is always the SP-PE TLV that is associated with the PE that set that particular last fault. If subsequent PW status messages for the same PW status bit are received, the SP-PE TLV will overwrite the previously stored SP-PE TLV.
PWステータスメッセージがSP-PE TLVが含まれていることを受信されると、SP-PE TLV情報は、上述した手順に従ってPWステータスワードの内容と共に、記憶されてもよいです。格納されたSP-PE TLVは、常に特定の最後の障害に設定PEと関連しているSP-PE TLVです。同じPWステータスビットのための後続のPWステータスメッセージを受信した場合、SP-PE TLVは、以前に格納されたSP-PE TLVを上書きします。
The PW switching architecture is based on the concept that the T-PE should process the PW LDP messages in the same manner as if it were participating in the setup of a PW segment. However, a T-PE participating in an MS-PW SHOULD be able to process the SP-PE TLV. Otherwise, the processing of PW status messages and other PW setup messages is exactly as described in [RFC4447].
PWスイッチングアーキテクチャは、それがPWセグメントの設定に参加しているかのようにT-PEも同様にPW LDPメッセージを処理する概念に基づいています。しかし、MS-PWに参加するT-PEは、SP-PE TLVを処理することができるべきです。そうでなければ、PWステータスメッセージと他のPWセットアップメッセージの処理は、[RFC4447]に記載のとおりになります。
Pseudowire status signaling methodology, defined in [RFC4447], SHOULD be transparent to the switching point.
[RFC4447]で定義された疑似回線ステータスシグナリング方法は、スイッチングポイントに透明であるべきです。
When the PW control plane switching methodology is used to cross an administrative boundary, it might be necessary to prevent excessive status signaling changes from being propagated across the administrative boundary. This can be achieved by using a similar method as commonly employed for the BGP route advertisement dampening. The details of this OPTIONAL algorithm are a matter of implementation and are outside the scope of this document.
PW制御プレーンスイッチング方法は管理境界を横断するために使用される場合、行政境界を越えて伝播されることから、過剰なステータスシグナリングの変化を防止するために必要かもしれません。一般にBGPルート広告減衰のために用い、これは同様の方法を使用することによって達成することができます。このオプションのアルゴリズムの詳細は、実装の問題であり、この文書の範囲外です。
The procedures outlined in this document can be employed to provision and manage MS-PWs crossing AS boundaries. The use of more advanced mechanisms involving auto-discovery and ordered PWE3 MS-PW signaling will be covered in a separate document.
この文書で説明する手順は、プロビジョニングに使用されるとの境界AS MS-PWの交差を管理することができます。自動検出を含む、より高度なメカニズムの使用とPWE3 MS-PWシグナリングは別の文書で説明します命じました。
Each PSN carrying the PW may be subject to congestion. The congestion considerations in [RFC3985] apply to PW segments as well. Each PW segment will handle any congestion experienced by the PW traffic independently of the other MS-PW segments. It is possible that passing knowledge of congestion between segments and to the T-PEs can result in more efficient edge-to-edge congestion mitigation systems. However, any specific methods of congestion mitigation are outside the scope of this document and left for further study.
PWを運ぶ各PSNは混雑を受けることができます。 [RFC3985]の輻輳の考慮もPWセグメントに適用します。各PWセグメントは、互いに独立して、MS-PWセグメントのPWトラフィックによって経験される任意の輻輳を処理します。セグメント間及びT-PEに輻輳の知識を通過すると、より効率的なエッジ・ツー・エッジ輻輳緩和システムをもたらすことが可能です。しかし、混雑緩和のいずれかの具体的な方法は、この文書の範囲外であり、さらなる研究のために残しました。
This document specifies the LDP, L2TPv3, and VCCV extensions that are needed for setting up and maintaining pseudowires. The purpose of setting up pseudowires is to enable Layer 2 frames to be encapsulated and transmitted from one end of a pseudowire to the other. Therefore, we discuss the security considerations for both the data plane and the control plane in the following sections. The guidelines and security considerations specified in [RFC5920] also apply to MS-PW when the PSN is MPLS.
この文書では、設定と疑似回線を維持するために必要とされる自民党、L2TPv3の、およびVCCV拡張子を指定します。疑似回線を設定する目的は、他の疑似回線の一端からカプセル化されて送信されるレイヤ2つのフレームを可能にすることです。したがって、我々は、データプレーンと、次のセクションでは、コントロールプレーンの両方のためのセキュリティの考慮事項について説明します。 PSNがMPLSのとき[RFC5920]で指定されたガイドラインとセキュリティの考慮も、MS-PWに適用されます。
Data plane security considerations as discussed in [RFC4447], [RFC3931], and [RFC3985] apply to this extension without any changes.
[RFC4447]で説明したように、データプレーンセキュリティ問題、[RFC3931]及び[RFC3985]は変更せずに、この拡張に適用されます。
The VCCV technology for MS-PW offers a method for the service provider to verify the data path of a specific PW. This involves sending a packet to a specific PE and receiving an answer that either confirms the information contained in the packet or indicates that it is incorrect. This is a very similar process to the commonly used IP ICMP ping and TTL expired methods for IP networks. It should be noted that when using VCCV Type 3 for PW when the CW is not enabled, if a packet is crafted with a TTL greater than the number of hops along the MS-PW path, or an S-PE along the path mis-processes the TTL, the packet could mistakenly be forwarded out of the attachment circuit as a native PW packet. This packet would most likely be treated as an error packet by the CE. However, if this possibility is not acceptable, the CW should be enabled to guarantee that a VCCV packet will never be mistakenly forwarded to the AC.
MS-PW用VCCV技術は、特定のPWのデータパスを確認するために、サービスプロバイダのための方法を提供しています。これは、特定のPEにパケットを送信し、パケットに含まれる情報を確認するか、それが間違っていることを示しているいずれかの回答を受信することを含みます。これは、一般的に使用されるIPのICMP pingに非常に類似したプロセスで、TTLはIPネットワークのための方法を期限切れ。パケットが経路に沿って、MS-PWの経路に沿ったホップ数よりも大きいTTL、またはS-PEで作られた場合にCWが有効でない場合PWためVCCVタイプ3を使用する際に留意すべきである誤TTLを処理し、パケットが誤っネイティブPWパケットとして接続回線から転送することができます。このパケットは、最も可能性の高いCEでエラーパケットとして扱われます。この可能性が許容できない場合は、CWは、VCCVパケットが誤ってACに転送されないことを保証するために有効にする必要があります。
General security considerations with regard to the use of LDP are specified in Section 5 of RFC 5036. Security considerations with regard to the L2TPv3 control plane are specified in [RFC3931]. These considerations apply as well to the case where LDP or L2TPv3 is used to set up PWs.
自民党の使用に関して一般的なセキュリティ上の考慮事項は、[RFC3931]で指定されたL2TPv3コントロールプレーンに関してはRFC 5036のセキュリティ上の考慮事項のセクション5で指定されています。これらの考慮事項は、LDPまたはL2TPv3のはPWのを設定するために使用されている場合にも同様に適用されます。
A pseudowire connects two attachment circuits. It is important to make sure that LDP connections are not arbitrarily accepted from anywhere, or else a local attachment circuit might get connected to an arbitrary remote attachment circuit. Therefore, an incoming session request MUST NOT be accepted unless its IP source address is known to be the source of an "eligible" peer. The set of eligible peers could be pre-configured (either as a list of IP addresses or as a list of address/mask combinations), or it could be discovered dynamically via an auto-discovery protocol that is itself trusted. (Note that if the auto-discovery protocol were not trusted, the set of "eligible peers" it produces could not be trusted.)
疑似回線は、二つの接続回線を接続しています。自民党の接続が任意のどこから受け入れていないことを確認することが重要であるか、あるいはローカル接続回線は、任意のリモート接続回線に接続される可能性があります。その送信元IPアドレスが「適格」ピアの源であることが知られていない限りそのため、受信したセッション要求を受け入れてはなりません。適格なピアのセットすることができ事前設定（IPアドレスのリストとして、またはアドレス/マスクの組み合わせのリストとしてのいずれか）、またはそれ自体が信頼されている自動検出プロトコルを介して動的に発見することができます。 （自動検出プロトコルは、信頼されていなかった場合、それが生成する「適格なピア」のセットが信頼することができなかったことに注意してください。）
Even if a connection request appears to come from an eligible peer, its source address may have been spoofed. So some means of preventing source address spoofing must be in place. For example, if all the eligible peers are in the same network, source address filtering at the border routers of that network could eliminate the possibility of source address spoofing.
接続要求が適格ピアから来るように見えても、その送信元アドレスが詐称されている場合があります。だから、送信元アドレスのスプーフィングを防止するいくつかの手段が所定の位置になければなりません。すべての適格なピアが同じネットワークにある場合、例えば、そのネットワークの境界ルータでフィルタリング送信元アドレスは、送信元アドレススプーフィングの可能性を排除することができます。
For a greater degree of security, the LDP authentication option, as described in Section 2.9 of [RFC5036], or the Control Message Authentication option of [RFC3931], MAY be used. This provides integrity and authentication for the control messages, and eliminates the possibility of source address spoofing. Use of the message authentication option does not provide privacy, but privacy of control messages is not usually considered to be highly important. Both the LDP and L2TPv3 message authentication options rely on the configuration of pre-shared keys, making it difficult to deploy when the set of eligible neighbors is determined by an auto-configuration protocol.
セキュリティのより大きな程度については、[RFC5036]のセクション2.9に記載されているようにLDP認証オプション、または[RFC3931]の制御メッセージ認証オプションを使用してもよいです。これは、制御メッセージのための整合性と認証を提供し、送信元アドレススプーフィングの可能性を排除します。メッセージ認証オプションを使用すると、プライバシーを提供していませんが、制御メッセージのプライバシーは通常、非常に重要であると考えられていません。どちらも自民党とL2TPv3のメッセージ認証オプションは、対象と隣人のセットが自動設定プロトコルによって決定されたとき、それは難しい展開になって、事前共有キーの設定に依存しています。
The protocol described in this document relies on the LDP MD5 authentication key option, as described in Section 2.9 of [RFC5036], to provide integrity and authentication for the LDP messages and protect against source address spoofing. This mechanism relies on the configuration of pre-shared keys, which typically introduces some fragility. In the specific case of MS-PW, the number of links that leave an organization will be limited in practice, so the reliance on pre-shared keys should be manageable.
[RFC5036]のセクション2.9で説明したように、本書に記載されているプロトコルはLDPメッセージの整合性と認証を提供し、送信元アドレススプーフィングから保護するために、LDP MD5認証キーオプションに依存しています。このメカニズムは、典型的にはいくつかの脆弱性を導入する事前共有キーの構成に依存しています。 MS-PWの特定の場合において、組織を離れるリンクの数は、実際に制限されるので、事前共有鍵への依存は、管理可能であるべきです。
When the Generalized PWid FEC Element is used, it is possible that a particular peer may be one of the eligible peers, but may not be the right one to connect to the particular attachment circuit identified by the particular instance of the Generalized ID FEC element. However, given that the peer is known to be one of the eligible peers (as discussed above), this would be the result of a configuration error, rather than a security problem. Nevertheless, it may be advisable for a PE to associate each of its local attachment circuits with a set of eligible peers, rather than have just a single set of eligible peers associated with the PE as a whole.
一般PWID FEC要素が使用される場合、特定のピアが対象ピアの1つであってもよいが、一般ID FEC要素の特定のインスタンスによって識別される特定の接続回線に接続するための正しいものではないかもしれない可能性があります。しかしながら、（上述のように）ピアが対象ピアの1つであることが知られていることを考えると、これは、コンフィギュレーション・エラーの結果ではなく、セキュリティ上の問題であろう。それにもかかわらず、全体としてのPEと関連する対象ピアの1つだけセットを有するのではなく、対象ピアのセットを用いて、そのローカル接続回線の各々を関連付けるためにPEが望ましいことがあります。
This document uses a new L2TP parameter; IANA already maintains the registry "Control Message Attribute Value Pairs" defined by [RFC3438]. The following new value has been assigned:
この文書は、新しいL2TPパラメータを使用しています。 IANAはすでに[RFC3438]で定義されたレジストリ「コントロールメッセージ属性値ペア」を維持しています。次の新しい値が割り当てられています。
101 PW Switching Point AVP
101 PWは、ポイントAVPを切り替えます
This document uses a new LDP TLV type; IANA already maintains the registry "TLV TYPE NAME SPACE" defined by RFC 5036. The following value has been assigned:
この文書は、新しいLDP TLVタイプを使用しています。 IANAはすでにRFC 5036で定義された「TLV TYPEの名前空間には、」次の値が割り当てられているレジストリを維持します。
TLV type Description
0x096D Pseudowire Switching Point PE TLV
This document uses a new LDP status code; IANA already maintains the registry "STATUS CODE NAME SPACE" defined by RFC 5036. The following value has been assigned:
この文書は、新しい自民党のステータスコードを使用しています。 IANAは、すでに以下の値が割り当てられているRFC 5036で定義されたレジストリ「ステータスコードの名前空間」を維持します。
Assignment E Description
0x0000003A 0 PW Loop Detected
This document uses a new L2TPv3 Result Code for the CDN message, as assigned by IANA in the "Result Code AVP (Attribute Type 1) Values" registry.
「コードAVPを結果（属性タイプ1）の値」レジストリにIANAによって割り当てられたこの文書は、CDNメッセージのための新しいL2TPv3の結果コードを使用しています。
Registry Name: Result Code AVP (Attribute Type 1) Values Defined Result Code values for the CDN message are:
レジストリ名：CDNメッセージのためのコードAVP（属性タイプ1）の結果値の定義されたResult Code値は以下のとおりです。
Assignment Description 31 Sequencing not supported
割り当ての説明31シーケンスはサポートされていません
IANA has set up a registry named "Pseudowire Switching Point PE sub-TLV Type". These are 8-bit values. Type values 1 through 6 are defined in this document. Type values 7 through 64 are to be assigned by IANA using the "Expert Review" policy defined in [RFC5226]. Type values 65 through 127, as well as 0 and 255, are to be allocated using the IETF consensus policy defined in RFC 5226. Type values 128 through 254 are reserved for vendor proprietary extensions and are to be assigned by IANA, using the "First Come First Served" policy defined in RFC 5226.
IANAは、「擬似回線の切り替えポイントPEサブTLVタイプ」という名前のレジストリを設定しています。これらは、8ビットの値です。タイプ値は、1〜6は、この文書で定義されています。タイプ値7〜64は、[RFC5226]で定義された「エキスパートレビュー」ポリシーを使用してIANAによって割り当てられるべきです。タイプ「は、第1を使用して、254を通る128は、ベンダー独自の拡張のために予約され、IANAによって割り当てられるIETFコンセンサスRFC 5226.タイプで定義されたポリシー値を使用して割り当てられるべきであり、127を介して65、並びに0〜255値まずRFC 5226で定義された「政策を添えてきます。
The Type Values are assigned as follows:
次のようにタイプの値が割り当てられています。
Type Length Description
型長さ説明
0x01 4 PWid of last PW segment traversed 0x02 variable PW Switching Point description string 0x03 4/16 Local IP address of PW Switching Point 0x04 4/16 Remote IP address of last PW Switching Point traversed or of the T-PE 0x05 variable FEC Element of last PW segment traversed 0x06 12 L2 PW address of PW Switching Point
0x01の最後PWセグメントの4 PWIDはポイントスイッチング最後PWのポイント0x04の4/16リモートIPアドレスが横断またはT-PE 0x05の可変FEC素子のスイッチングPWの4/16ローカルIPアドレス0x03のポイントの説明文字列を切り替え0x02の変数PWを横断しました最後のPWセグメントは、PWスイッチング・ポイントの0x06で12 L2 PWアドレスを横断しました
[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月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、 "文字セットと言語のIETF方針"、BCP 18、RFC 2277、1998年1月。
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931]ラウ、J.、エド、Townsley、M.、エド、およびI. Goyret、エド、 "レイヤ2トンネリングプロトコル - バージョン3（L2TPv3の）"。。。、RFC 3931、2005年3月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）"、RFC 4364、2006年2月。
[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月。
[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., Ed., 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]、RFC 4447マティーニ、L.、エド。、ローゼン、E.、エルAawar、N.、スミス、T.、およびG.サギ、 "ラベル配布プロトコル（LDP）を使用して疑似回線の設定とメンテナンス" 、2006年4月。
[RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto, "Attachment Individual Identifier (AII) Types for Aggregation", RFC 5003, September 2007.
[RFC5003]メス、C.、マルティーニ、L.、Balus、F.、及びJ.杉本、 "集約のためのアタッチメント個体識別子（AII）タイプ"、RFC 5003、2007年9月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036]アンデション、L.、エド。、Minei、I.、エド。、およびB.トーマス、エド。、 "LDP仕様"、RFC 5036、2007年10月。
[RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5085]ナドー、T.、エド、およびC. Pignataro、エド、 "Pseudowireの仮想回線接続性検証（VCCV）：スードワイヤ用制御チャネル"。。、RFC 5085、2007年12月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC5641] McGill, N. and C. Pignataro, "Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values", RFC 5641, August 2009.
[RFC5641]マギル、N.およびC. Pignataro、 "レイヤ2トンネリングプロトコルバージョン3（L2TPv3の）拡張サーキットステータス値"、RFC 5641、2009年8月。
[PW-MSG-MAP] Aissaoui, M., Busschbach, P., Morrow, M., Martini, L., Stein, Y(J)., Allan, D., and T. Nadeau, "Pseudowire (PW) OAM Message Mapping", Work in Progress, October 2010.
[PW-MSG-MAP] Aissaoui、M.、Busschbach、P.、モロー、M.、マティーニ、L.、スタイン、Y（J）、アラン、D.、およびT.ナドー、「疑似回線（PW） OAMメッセージマッピング」、進歩、2010年10月の作業。
[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月。
[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月。
[RFC3985] Bryant, S., Ed., and P. Pate, Ed., "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, Ed., "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月。
[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月。
[RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly", RFC 4623, August 2006.
[RFC4623] Malis、A.およびM. Townsley、 "擬似ワイヤエミュレーションエッジ・ツー・エッジ（PWE3）フラグメンテーションおよび再構成"、RFC 4623、2006年8月。
[RFC4667] Luo, W., "Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP)", RFC 4667, September 2006.
[RFC4667]羅、W.、 "レイヤレイヤ2トンネリングプロトコル（L2TP）のための2バーチャルプライベートネットワーク（L2VPN）拡張機能"、RFC 4667、2006年9月。
[RFC4717] Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N., Brayley, J., and G. Koleyni, "Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks", RFC 4717, December 2006.
[RFC4717]マルティーニ、MPLSネットワークの上の非同期転送モードのトランスポート（ATM）のためのL.、Jayakumar、J.、ボッチ、M.、エルAawar、N.、Brayley、J.、およびG. Koleyni、「カプセル化方法」、RFC 4717、2006年12月。
[RFC5254] Bitar, N., Ed., Bocci, M., Ed., and L. Martini, Ed., "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", RFC 5254, October 2008.
[RFC5254]ビタール、N.編、ボッチ、M.、編、及びL.マティーニ、エド。、 "マルチセグメント疑似回線エミュレーションエッジ・ツー・エッジ（PWE3）のための要件"、RFC 5254、2008年10月。
[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009.
[RFC5659]ボッチ、M.とS.ブライアント、「マルチセグメント擬似回線エミュレーションエッジツーエッジのためのアーキテクチャ」、RFC 5659、2009年10月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]牙、L.、エド。、 "MPLSおよびGMPLSネットワークのセキュリティフレームワーク"、RFC 5920、2010年7月。
The authors wish to acknowledge the contributions of Satoru Matsushima, Wei Luo, Neil Mcgill, Skip Booth, Neil Hart, Michael Hua, and Tiberiu Grigoriu.
著者は悟松島、魏羅、ニール・マギル、スキップブース、ニール・ハート、マイケル華、とTiberiu Grigoriuの貢献を認めることを望みます。
The following people also contributed text to this document:
以下の人々はまた、この文書にテキストを寄付しました：
Florin Balus Alcatel-Lucent 701 East Middlefield Rd. Mountain View, CA 94043 US EMail: florin.balus@alcatel-lucent.com
フローリンBalusアルカテル・ルーセント701東ミドルRdを。マウンテンビュー、CA 94043米国電子メール：florin.balus@alcatel-lucent.com
Mike Duckett Bellsouth Lindbergh Center, D481 575 Morosgo Dr Atlanta, GA 30324 US EMail: mduckett@bellsouth.net
マイク・ダケットベルサウスリンドバーグセンター、D481 575 Morosgo博士アトランタ、GA 30324米国電子メール：mduckett@bellsouth.net
Authors' Addresses
著者のアドレス
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO 80112 US EMail: lmartini@cisco.com
ルカ・マティーニシスコシステムズ株式会社9155東ニコルズアベニュー、スイート400イングルウッド、CO 80112米国電子メール：lmartini@cisco.com
Chris Metz Cisco Systems, Inc. EMail: chmetz@cisco.com
クリス・メッツシスコシステムズ、株式会社Eメール：chmetz@cisco.com
Thomas D. Nadeau EMail: tnadeau@lucidvision.com
トーマスD.ナドーEメール：tnadeau@lucidvision.com
Matthew Bocci Alcatel-Lucent Grove House, Waltham Road Rd White Waltham, Berks SL6 3TN UK EMail: matthew.bocci@alcatel-lucent.co.uk
マシューボッチアルカテル・ルーセントグローブハウス、ウォルサム道路Rdのホワイトウォルサム、バークスSL6 3TN英国Eメール：matthew.bocci@alcatel-lucent.co.uk
Mustapha Aissaoui Alcatel-Lucent 600, March Road, Kanata, ON Canada EMail: mustapha.aissaoui@alcatel-lucent.com
ムスタファAissaouiアルカテル・ルーセント600、カナダのメールに月の道、カナタ、：mustapha.aissaoui@alcatel-lucent.com