[要約] RFC 6073は、セグメント化された擬似ワイヤに関する要約と目的を提供します。セグメント化された擬似ワイヤは、異なるネットワーク技術を使用するセグメント間のトラフィックを転送するための方法を定義します。
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）ドメイン間または2つ以上の異なるPW制御プレーンドメイン間で擬似動物（PWS）を接続する方法について説明します。。異なるPW制御プレーンドメインは、独立した自律システムに属している可能性があります。または、PSNテクノロジーが異質であるか、特定のPSNポイントでPWを集計する必要がある場合があります。PWパケットデータユニットは、PWペイロードを変更せずに、1つの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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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-PWS）を確立するためのシグナル伝達およびカプセル化技術を定義します。マルチセグメントの擬似動物（MS-PWS）は、2つの一般的なケースで最も役立ちます。
-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.
-私。場合によっては、終了したソースと宛先PEの間にPW制御チャネルを確立することは不可能、望ましく、または実行可能です。少なくとも、PW制御チャネルの確立には、リモート（終了）PE IPアドレスの知識と到達可能性が必要です。ローカル（終了）PEは、トポロジ、運用、またはセキュリティの制約のためにこの情報にアクセスできない場合があります。
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.
例としては、終了PESが異なるプロバイダーネットワーク（ASE）に存在するL2VPN間シナリオと、2つのネットワーク間で交換されるすべての制御トラフィックに暗号化する慣行です。技術的には、SS-PWを使用できますが、これにはすべての終了ソースおよび宛先PEノードの暗号化署名が必要です。MS-PWを使用すると、プロバイダーは、2つのドメインを接続するPWスイッチングポイントのみに重要な管理を限定できます。
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.
2番目の例には、終端PEの間のPWセットアップパスが外部エンティティによって計算される場合、単一が含まれる場合があります。PWE3制御チャネルの完全なメッシュがPE-A、PE-B、およびPE-Cの間に確立されていると仮定します。PE-AとPE-Cの終了の間に、PWを介してトンネルされたクライアント層L2接続が必要です。外部エンティティは、PE-Bを通過するPWセットアップパスを計算します。これにより、2つの離散PWセグメントが構築されます。1つはPE-AとPE-Bの間、もう1つはPE-BとPE-Cの間です。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.
3番目の例では、階層IP/MPLSネットワークでのPWSの使用が含まれます。バックボーンに接続されたアクセスネットワークは、PWSを使用して、同じアクセスネットワークによってサービスされる顧客サイト間で顧客のペイロードを輸送し、バックボーンを終了または後続のPWセグメントに切り替えることができるバックボーンの端まで輸送します。アクセスネットワークとバックボーンネットワーク間のPWE3の切り替えを使用すると、PWE3制御チャネルとアクセスネットワークT-PEによって処理されるルーティング情報を潜在的に削減できます。
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:
PWSを確立するための4つの異なるメカニズムがあります。
-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。FEC 128を使用したLDP（PWID FEC要素）-III。FEC 129を使用したLDP（一般化された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セグメントは個別に機能することはできません。したがって、完全なMS-PWを一度に信号することなく、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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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。MS-PWの最初と最後のセグメントに終了PEが存在します。これには、[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）。2つのT-PEデバイスの間に直接設定されたPW。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として振る舞い、機能する2つ以上の連続した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デバイス、T-PEおよび/またはS-PE（Switching PE）の間で各方向に1つのPSNトンネルを横断するシングルセグメントまたはマルチセグメントPWの一部。
- 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-PESのセット。
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]で説明されているように、1つのPEからPSN上の1つまたは複数のPESにエミュレートされたサービスの重要な要素を運ぶメカニズムです。多くのプロバイダーは、既存（または新しい）L2VPNサービス（フレームリレー、ATM、またはイーサネットなど）をPSNに移行する手段としてPWSを展開しています。
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）とPWSが境界として交差します。
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.
現在、L2VPN Inter-AS機能がサポートされており、MPLSカプセル化とLDPシグナル伝達を採用するいくつかの手法が文書化されています[RFC4364]。また、L2TPV3を使用して同じ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）では、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：AC参照モデルを使用したPWの切り替え
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では、2つの別々のPSNの擬似ワイヤがネイティブサービスアタッチメントサーキットを使用して一緒に縫い合わされます。PE2とPE3は、それらが直接接続されているPSNのコントロールプレーンのみを実行します。PE2およびPE3では、PW1とPW2はアタッチメント回路AC1を使用して接続され、PW3とPW4はアタッチメント回路AC2を使用して接続されています。
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.
図3では、SPE1は2つの別々のコントロールプレーンを実行します。1つはTPE1に、もう1つはTPE2に向かっています。PWスイッチングポイント（S-PE）は、PWセグメント1とPWセグメント3を接続するように構成され、TPE1とTPE2の間のマルチセグメントPWを完了します。PWセグメント1とPWセグメント3は同じPWタイプでなければなりませんが、PSNトンネル1とPSNトンネル2は同じ技術である必要はありません。後者の場合、PWが異なる技術に切り替えられた場合、PESは異なる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.
IPカプセル化または汎用ルーティングカプセル化（GRE）[RFC4023]を介したMPLなど、1つのPSNテクノロジーを別のPSNテクノロジーに適合させることが可能であることに注意する必要がありますが、これはこのドキュメントの範囲外です。さらに、S-PEでPWS自体でインターワーキング関数を実行し、あるPWタイプから別の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の確立のすべての要素は、このドキュメントの範囲外であり、このドキュメントの議論は純粋に例として機能します。また、PWはパスに沿って複数のPWスイッチングポイントを通過できることに注意してください。また、Edge PESは、PWが移動したS-PEの数に関する特定の知識を必要としません（ただし、これはトラブルシューティングの目的で報告される場合があります）。
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-PWSで採用された一般的なアプローチは、受信後すぐにシグナリング情報を渡すことにより、個々のコントロールプレーンを接続することです。まず、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のPWSは独立して確立され、各PSNは別のPWドメインとして扱われます。たとえば、MPLS PSNSの場合の図2では、[RFC4447]で説明されているLDPターゲットセッションを使用してPW1がPE1とPE2の間にセットアップされ、同時に個別の擬似動物PW2がPE3とPE4の間にセットアップされます。PE2およびPE3のPW1およびPW2のACSは、それらが同じPWタイプ、たとえばATM仮想チャネル接続（VCC）、イーサネットVLANなどになるように構成する必要があります。
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]で説明されています。そのカプセル化に関連するRFCで指定されているPWタイプの適用性（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-PWSと同様に、任意のセグメントのパフォーマンスは、基礎となる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タイプは異なる最大パフォーマンス目標を達成できる可能性があるため、どのPSNタイプがMS-PWのパスに沿って使用されるかを慎重に検討する必要があります。
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は[RFC4447]で説明されているLDPターゲットセッションを使用してPWセグメント1を設定し、同時に別の擬似ワイヤーであるPWセグメント3がT-PE2にセットアップされます。各PWはPESで個別に構成されていますが、S-PE1では、PWセグメント1はPWセグメント3に接続されています。PDUは、PWラベルレベルの擬似動物間で切り替えられます。したがって、データプレーンは、特定の擬似型タイプに関する特別な知識を必要としません。2つのPWを接続するには、単純な標準MPLSラベルスワップ操作で十分であり、この場合は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-PESの数に対する唯一の制限は、PW MPLSラベルのTTLフィールドによって課されます。PW MPLSラベルのTTLの設定は、発信中のPEに関するローカルポリシーの問題ですが、255に設定する必要があります。ただし、PW PDUに運用、管理、およびメンテナンス（OAM）パケットが含まれている場合、TTLはTTLに含まれます。このドキュメントで後で説明したように、必要な値に設定できます。
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はMPLSパケットを1つのPWからもう一方のPWに向けるように構成する必要があります。この場合、制御プロトコルは関係ありません。コントロールプレーンの1つが単純な静的PW構成であり、他のコントロールプレーンが動的LDP FEC 128または一般化されたPW FECである場合、図の参照モデルのアタッチメント回路（AC）と同様と見なす必要があります。1.スイッチングポイントPEは、静的PWセグメントでパケットの送信または受信の障害を検出する場合、適切なPWステータスを信号する必要があります。PWステータス通信メカニズムが存在しない場合、PWが静的に構成されている場合、動的LDP PWに通知されるステータスは、ローカルインターフェイス障害に限定されます。この場合、S-PE PEは、アクティブなシグナル伝達の役割を想定して、T-PEと非常によく似た方法で動作します。これは、静的PWが上昇しているとみなされる場合、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がスイッチングポイントで構成されている場合、ラベルスイッチングルーター（LSR）は、リモートPEから2つのPW LDP FECの少なくとも1つを受け取るまで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に送り返すことができます。LDPリベラルラベル保持モードは引き続き適用されます。したがって、PEがまだ構成されていない場合、ラベルマッピングは将来の使用のために保存されます。MS-PWは、すべての構成要素SS-PWがアップしている場合にのみ宣言されます。
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.
[RFC4447]で定義されている擬似識別子（PWID）は、PEの各ペア間の一意の数字です。したがって、MS-PWを形成する各SS-PWには異なるPWIDがある場合があります。一般化されたPW FECの場合、アタッチメントグループ識別子（AGI） /ソースアタッチメント識別子（SAI） /ターゲットアタッチメント識別子（TAI）も、一部または時にはすべてSS-PWSで異なる必要がある場合があります。
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 T-PE) and the passive T-PE (the Target T-PE) MUST be identified before signaling is initiated for a given MS-PW.
FEC 129を使用してMS-PWがシグナルを使用すると、各T-PEはMS-PWのシグナルを独立して開始する可能性があります。MS-PWパスが静的に構成されていない場合、特定の場合には、シグナル伝達手順により、異なるS-PEを介してMS-PWの各方向を設定しようとする可能性があります。オペレーターがこの状況を回避したい場合、T-PEの1つはPWシグナリング（アクティブロール）を開始する必要があり、もう1つはLDPラベルマッピングを受信するのを待ってから、それぞれのPW LDPラベルマッピングメッセージ（パッシブロール）を送信します。MS-PWパスが静的に構成されていない場合、アクティブT-PE（ソース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の1つをアクティブな役割に設定する必要があり、もう1つは受動的な役割に設定する必要があります。
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が想定できる2つの異なる役割があります。アクティブとパッシブです。アクティブな役割を想定するPEはLDP PWセットアップメッセージを送信しますが、PEがパッシブロールPEは、着信LDP PWセットアップメッセージに単純に返信します。S-PEは、PWID FEC 128 LDPメッセージが受信されるまで常に受動的であり、対応する一般化されたPW FEC LDPメッセージが形成および送信されます。一般化されたFEC PW LDPメッセージが受信された場合、スイッチングポイントPEが受動的な役割を果たしている場合、対応する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.
PWIDは、対応する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-PEとの後方互換性のために設定する必要があります。SP-PE TLVは、スイッチングポイントが移動するごとに1回のみ表示される場合があり、長さゼロになることはできません。SP-PE TLVは各S-PEのPW FECに追加され、LDPメッセージのSP-PE TLVの順序を保持する必要があります。SP-PE TLVは、MS-PWSの仮想回路接続検証（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.
値フィールドの解釈方法をエンコードします。
- 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.
型フィールドで指定されていると解釈される情報をエンコードする長さのオクテットのオクテット文字列。
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.
現地の政策上の理由から、特定のS-PEは、それを横断するラベルマッピングメッセージですべてのSP-PE TLVを除外し、独自のSP-PE TLVを含めないことができます。この場合、上流のPEから、この特定のS-PEがT-PEであるかのように見えます。S-PEがサービスプロバイダーの管理境界にある場合、ローカルポリシーに応じてこれが必要になる場合があります。また、それらを削除したS-PEを超えたパスを記述するSP-PE TLVがないため、VCCVはその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には、S-PEトラバースのさまざまな特性を記述するサブTLVが含まれています。SP-PE TLVには、以下に指定された適切な必須サブTLVを含める必要があります。PWスイッチングポイントPEサブTLVの定義は次のとおりです。
- 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セグメントが使用されたLDP FEC 128を通過してPWを通知した場合にのみ適用されます。このサブTLVタイプには、[RFC4447]で説明されているPWIDの形式のPWIDが含まれています。これは、わずか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.
- 最後のPWスイッチングポイントのリモートIPアドレスは、トラバースまたはT-PEのリモート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スイッチングポイントのトラバースまたはT-PEのIPv4またはIPv6アドレス。これはオプションのサブTLVです。ほとんどの場合、これはLDPセッションのリモートIPアドレスになります。このSub-TLVは、他のS-PEから他のSP-PE TLVが存在しない場合、またはLDPセッションのリモートIPアドレスが「PWスイッチングポイントのローカルIPアドレス」TLV値に対応しない場合にのみ含める必要があります。最後の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セグメントが使用されたLDP FEC 129を通過してPWを通知した場合にのみ適用されます。
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]は、PWをアタッチメント回路（AC）に適応させるためにネットワークサービス処理（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].
- 0x09フラグメンテーションインジケーター[RFC4623]に従って断片化されたPWフレームの再組み立てが可能である場合、このパラメーターはスイッチングポイントによってFECに挿入される場合があります。
- 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タイプを反映するためにリセットする必要があります。CCタイプビットフィールドには、ビット1 "タイプ2：MPLSルーターアラートラベル"に設定されている必要があります。他のビットフィールドは、S-PEでサポートされているCCタイプを反映するためにリセットする必要があります。
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は、PWスイッチングポイントPE TLVを検査して、独自のIPアドレスが表示されないことを確認する必要があります。PEのIPアドレスが受信したPWスイッチングポイントPE TLVに表示される場合、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 PWS -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から他のPWにパケットを向けるように構成する必要があります。この場合、制御プロトコルは関係ありません。構成には、L2TPV3セッションID（および関連するCookie、存在する場合）のMPLS PWラベルマップと、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の参照モデルでアタッチメント回路（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に切り替えられる場合、静的コントロールプレーンは、図1の参照モデルでアタッチメント回路（AC）と同一であると見なす必要があります。（L2TPV3 SET-LINK-INFO（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.
動的PWSを切り替えるとき、スイッチングポイントは常に初期のパッシブロールを想定します。したがって、ノードの片側から接続要求（ラベルマッピングまたは着信 - コールレクエスト（ICRQ））を受信するまで、LDP/MPLSまたはL2TPV3 PWを開始しません。MPLS PWはFEC識別子によって結合された2つの単方向ラベルスイッチ付きパス（LSP）で構成されていますが、L2TPV3 PWは本質的に双方向であり、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.
以下は、LDPとL2TPV3の間のメッセージの2つの例交換です。1つ目は、L2TPV3 T-PEがMS-PWを開始する場合です。2つ目は、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メッセージを使用して、インターフェイスステータスの変更（「UP」または「ダウン」からのインターフェイスの遷移など）を示します。MPLS/LDP PWSは、[RFC4447]のセクション4.4で定義されているLDPラベル撤回またはPWステータス通知メッセージを介してこれを示すいずれかです。LDPステータスTLVビットは、[RFC5641]で指定されたL2TPV3等価回路ステータス値TLVにマッピングする必要があります。
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は、単一のメッセージ、Call-Disconnect-Notify（CDN）を使用して、擬似ワイヤを取り壊します。CDNメッセージは、LDPのラベル引き出しメッセージに変換されます。以下は、LDPとL2TPV3の間のメッセージの2つの例交換です。1つ目は、L2TPV3 T-PEがMS-PWの終了を開始する場合です。2つ目は、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
ac "down" l2tpv3 cdn ---> ldpラベル引き出し---> ac "down" <-ldpラベルリリース
<--------------- 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"
AC "DOWN" LDPラベル引き出し---> L2TPV3CDN-> <-LDPラベルリリース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パラメーターは、[RFC4667]で定義されたL2TP「インターフェイス最大伝送ユニット」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 "PSEUDOWIRE TYPE" 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 129 SAI/TAI
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 PWSを切り替えるときにサポートされていません。
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 "PWスイッチングポイントAVP"は属性タイプ101です。AVPは隠されている場合があります（L2TP AVP H-BITは0または1である場合があります）、AVPの長さは6に加えて、スイッチングポイントPEサブの一連の長さです。-AVPに含まれる-TLV、および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を切り替えると、パケットが1つのPWからもう一方のパケットに送信され、MPLSラベルスタックをL2TPV3およびIPヘッダーに置き換えます。
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固有のサブレーヤーを介して実行されます。MPLSの場合、これら2つの関数（PSN収束と一緒に）は、MPLS制御ワードを介して実行されます。これらの機能はMPLSとL2TPV3で異なるため、2つの間のインターワーキングが必要になる場合があります。
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から別の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.
-私。これらのビットは、MPLS PW PDUで常にゼロです。それらを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の適切な形式で新しいシーケンス番号を再生することによりサポートされる場合があります。スイッチングノードでのこのタイプのシーケンスインターワーキングがサポートされておらず、セッションのセットアップ中にL2TP制御チャネルを介してすべてのパケットのシーケンスを要求する場合、スイッチングノードは、CDNメッセージをで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で定義されている回路ステータスAVPのステータスビットと[RFC5641]で定義された拡張回路ステータス値は、セクション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のSub-TLVインターフェイスパラメーターに含まれるVCCVパラメーターを送信してはなりません。L2TPV3 PWセグメントからMPLS 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のSub-TLVインターフェイスパラメーターを使用して、MS-PW 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は、PWID FEC TLVのインターフェイスパラメーターフィールドまたは一般化されたPWID FEC TLVのSUB-TLVインターフェイスパラメーターに含まれるVCCVパラメーターを使用して、ファーエンドT-PE2に示すものを示しています。PE1サポート。これは、T-PE1とT-PE2が直接接続されている場合に使用されるのと同じVCCVパラメーターです。S-PE2は、インターフェイスパラメーターの適応関数の一部としてPWスイッチングポイントであるため、VCCVパラメーターをローカルで処理し、T-PE2に渡します。T-PE1とT-PE2の間のパスに複数のS-PEがある場合、それぞれが同じ処理を実行し、VCCVパラメーターに沿って渡します。VCCVパラメーターのローカル処理は、S-PEでサポートされていない発信元T-PEによって指定されたCCタイプを削除します。たとえば、T-PE1がCCタイプ1、2、および3をサポートしていることを示した場合、S-PEはルーターアラートCCタイプ2を削除し、TLVの残りの部分を変更せずに残し、変更された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）は、PWパスに沿った初期T-PE（T-PE1）とすべてのS-PEによってサポートされているCCタイプのみを示すVCCVパラメーターを受信します。
The VCCV parameter ID is defined as follows in [RFC4446]:
VCCVパラメーターIDは、[RFC4446]で次のように定義されています。
Parameter ID Length Description 0x0c 4 VCCV
パラメーターID長い説明0x0c 4 VCCV
The format of the VCCV parameter field is as follows:
VCCVパラメーターフィールドの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0c | 0x04 | CC Types | CV Types |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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（0x01） - タイプ1：[RFC4385]で定義されている最初のニブルとして0001Bを備えたPWE3コントロールワードビット1（0x02） - タイプ2：MPLSルーターアラートラベルビット2（0x04） - タイプ3：MPLS Demultiplexor PW Label withTTL == 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-PWSに使用できます。ただし、ユーザーパケットでCWが有効になっている場合、[RFC5085]のルールに従ってVCCV CCタイプ1を使用する必要があります。MS-PWSに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-PWSではサポートされておらず、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-PWSに使用できます。ただし、CWが有効になっている場合、[RFC5085]のルールに従ってVCCVタイプ1が推奨されます。VCCVタイプ3のTTLメソッドを使用すると、PEはPWラベルTTLをターゲットPEに到達するために必要な適切な値に設定することに注意してください。それ以外の場合、VCCVパケットは、ACを介してCustomer Premise機器（CPE）に転送される場合があります。
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.
-私。エンドツーエンドのMS-PW接続検証。この操作により、MS-PWの接続性をソースT-PEから宛先T-PEにテストできます。これを行うには、送信T-PEには、VCCV-Pingエコー要求のMS-PWの最後のセグメントで使用されるFECを宛先T-PEに含める必要があります。この情報は、送信T-PEで構成されているか、以下に説明するように、オプションのSP-PE TLVの対応するサブTLVを処理することにより取得されます。
-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から宛先S-PEまたはT-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情報が正しい場合、これがFECの有効なルーターであることを示すVCCVエコーの返信が受信されます。ただし、SP-PE TLV情報が正しくない場合、この操作により、最初の誤ったスイッチングポイントが決定される可能性がありますが、それ以上の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パストレース。この操作は、s-PESまたはT-PEによってエコー応答メッセージで返されたターゲットFECスタックTLV [RFC4379]に含まれるFECを使用してMS-PWのデータパスを追跡します。送信T-PEまたはS-PEは、この情報を使用して、MS-PWのパスに沿って各S-PEを1回の操作でLSP Traceと同様の方法で再帰的にテストします。この操作は、MS-PWの実際のデータパスを決定することができ、静的に構成されたMS-PWSとシグナル付き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.
上記の操作は、中間S-PEおよび/または宛先T-PEに依存して、PWスイッチングポイントPE TLVをMS-PWセットアッププロセスの一部として含めるか、VCCVエコーにターゲットFECスタックTLVを含めることに注意してください。返信メッセージ。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.
コントロールプレーンの課題は、必要な情報を使用してVCCVエコーリクエストパケットを構築して、目的のS-PEまたはT-PEに到達するために必要な情報を構築できることです。パケットは運命づけられています。これは、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にはセグメントのFEC 128があります（PWセグメント1）がありますが、VCCVの場合、次のセグメントのFEC 128（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.
部分的またはエンドツーエンドの接続またはパス検証を実行する場合、Echo要求メッセージの送信者には、ターゲットS-PE/T-PEノードの最後のセグメントのFECが必要です。この情報は、PWスイッチングポイントPE TLVの対応するサブ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
タイプ説明0x01最後のPWセグメントのPWIDトラバースされた0x03 PWスイッチングポイントのローカルIPアドレス0x04最後のPWスイッチングポイントトラバースまたはT-PEのリモートIPアドレス
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.
オプションのMS-PWパストレース操作を実行すると、T-PEは、MS-PWパスのS-PEを1つずつ調査することにより、ターゲット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の返品コード（ラベルを切り替えたラベル）で構成されるエコー応答でリクエストに応答します。スタック深度）は、それがMS-PWの出力ルーターではなくS-PEであることを示します。
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-PESは、エコー応答メッセージのターゲットFECスタック（[RFC4379]のセクション3.2および4.5）に従って、下流のPWセグメントのFECを含める必要があります。FEC 128 PWSは、ターゲットFECスタックのSub-TLVに対して[RFC4379]のセクション3.2.9に示す形式を使用する必要がありますが、FEC 129 PWSは、サブの[RFC4379]のセクション3.2.10に示す形式を使用する必要があります。ターゲット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).
ノードがMS-PWのT-PEまたは出口ノードである場合、3（Egressルーター）の戻りコードを使用してエコー応答でエコー要求に応答します。
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つの同様の方法があります。Path Traceは、LDPコントロールプレーンを使用して検証するパスに関する情報を取得しないため、MS-PWの一部が静的に構成されたSS-PWSである場合、この方法は適しています。パス検証法は、LDP制御プレーンから得られた情報に依存しているため、MS-PWパスのLDPシグナル転送情報と比較して、現在の転送挙動のより良い検証を提供します。ただし、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.
図3では、T-PE1、S-PE、およびT-PE2がコントロールコントロールワードをサポートする場合、PWコントロールプレーンはCWの使用を自動的に交渉します。VCCV CCタイプ3は、PWでCWが有効になっているかどうかにかかわらず正しく機能します。ただし、VCCVタイプ1（エンドツーエンド検証のみに使用できます）は、CWが有効になっている場合にのみサポートされます。
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.
-私。T-PEは、VCCV-PINGエコー要求メッセージを形成し、FECは最後のPWセグメントのそれを宛先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は、内側のPWラベルTTLを正確な値に設定して、パケットがファーエンドT-PEに到達できるようにします。（値は、コントロールプレーン情報からS-PEの数をカウントすることによって決定されます。）あるいは、CCタイプ1がサポートされている場合、[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は、データパケットが取ったものとまったく同じデータパスに従う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 Decrementと新しい外側ラベルプッシュで内側のラベルスワップを実行します。
-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が使用されていない場合）、UDP宛先ポート3503を使用して有効なIPヘッダーをチェックすることにより、VCCVパケットであると判断できます。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.
図3では、T-PE1が1に等しいPWラベルのTTLでVCCVメッセージを送信すると、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のセクション3.2.10に従って構築されています。VCCVLSPPingパケットの構築に必要なすべての情報は、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とT-PEの間の最後から2番目のLSRが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をサポートすると仮定すると、上記のようにPWラベルTTLを使用してS-PE間のVCCVを達成できます。図3では、S-PEは、PWラベルTTLを1に設定してVCCVメッセージを送信することにより、ITとT-PE2の間のパスを検証する場合があります。PWラベルTTLを2に設定してVCCVメッセージを送信することにより、ITとS-PEの2つのセグメントとの間の接続性は、TTLを連続的に増加させることで接続性の問題を診断できます。適切なVCCVエコーリクエストパケット（[RFC4379]、セクション3.2.9または3.2.10で説明されているように）を構築するために必要なすべての情報は、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では、単一の動作コマンドによってT-PE1から発信されるMS-PWでVCCVトレースを実行できます。次のプロセスが続きます：
-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.
-私。T-PE1は、検証のために最初のセグメント（T-PE1とS-PEの間のPW1）からS-PEに最初のセグメント（T-PE1とS-PEの間のPW1）を含むTTLセットを1に設定してVCCVエコー要求を送信します。FECスタック検証が有効になっている場合、リクエストには、セグメント化されたPWが乗っている輸送トンネルの種類に依存するLDPプレフィックスやRSVP LSPなどの追加のサブTLVも含まれる場合があります。
-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でエコー要求を検証します。これは、最初のセグメントと2番目のセグメント間の切り替えポイントであるため、8の戻りコードでエコー応答を作成し、ECHOの応答を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（Egressルーター）の戻りコードを使用してエコー応答で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は、ECHOの応答には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の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では、単一の動作コマンドによってT-PE1から発信されるMS-PWでVCCVトレースを実行できます。次のオプションのプロセスが続きます。
-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.
-私。T-PE1は、検証のために最初のセグメント（T-PE1とS-PEの間のPW1）からS-PEに最初のセグメント（T-PE1とS-PEの間のPW1）を含むTTLセットを1に設定してVCCVエコー要求を送信します。FECスタック検証が有効になっている場合、リクエストには、セグメント化されたPWが乗っている輸送トンネルの種類に依存するLDPプレフィックスやRSVP LSPなどの追加のサブTLVも含まれる場合があります。
-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のリターンコードを使用してエコー応答をビルドし、echo返信をT-PE1に送り返し、MS-PWに沿った次のセグメントのFEC 128情報をVCCV Echo ReplyパケットにターゲットFECスタックを使用して追加します。TLV（[RFC4379]のセクション3.2および4.5に従って）。
-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は、以前のVCCVエコー返信で受信したFECスタックTLVから得られた情報に基づいて、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（Egressルーター）の戻りコードを使用してエコー応答で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は、ECHOの応答には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の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-MSG-Map]で定義されているように、PWまたはアタッチメント回路障害を示すPWステータスメッセージを障害表示または接続ACのOAMメッセージにマッピングする必要があります。
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にアタッチメント回路はありませんが、2つのPWが接続されています。同様に、PWSのステータスは、制御プレーンのスイッチング関数によって、1つのPWから他のPWに変更されずに転送されます。ただし、S-PEでローカルに添付されたPWセグメントの1つの障害ステータスを通信する必要がある場合があります。LDPの場合、これは、PWステータスTLVを含むLDP通知メッセージと、次のようにオプションのPWスイッチングポイント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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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.
The merging of the received LDP status and the local status for the PW segments at an S-PE can be summarized as follows:
S-PEでのPWセグメントの受信したLDPステータスとローカルステータスのマージは、次のように要約できます。
-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.
-私。両方のPWセグメントのローカルステータスが増加すると、S-PEは受信したACまたはPWステータスビットを変更せずに渡します。つまり、ステータス通知TLVは変更されていませんが、FEC 128 TLVの場合のPWIDは値に設定されます。次のホップのPWセグメントの。
-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
0x00000008-ローカルPSNに面したPW（イングレス）障害を受け取る0x00000010-ローカルPSNに面したPW（出口）送信障害
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.
各S-PEは、各PWセグメントに対して2つの32ビットPWステータスワードのみを保存する必要があります。1つは局所障害とリモート障害（通常は別のPEから受信）です。最初の障害は、32ビットステータスワードに適切なビットを設定し、その後の各障害は適切なPWステータスワードに囲まれます。PWステータスワードがリモート障害を保存する場合、このルールは、特定のPWセグメントで最初に障害を受けた論理または操作の影響を及ぼします。
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で受信されたリモート障害は、MS-PWに沿って変化していない一方、S-PEが検出された局所障害は両方の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-PEから複数の障害を受けることができます。ただし、リモートの最も近い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ステータスビットのS-PEでPWステータス通知メッセージが開始されると、同じステータスビット（および上流の隣人から受信）のさらなるステータスメッセージがローカルで処理され、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".
* 「0x00000010-ローカルPSNに面したPW（出口）送信障害」を含むS-PE3にPWステータスメッセージを送信します。
* Send a PW status message to S-PE1 containing "0x00000008 - Local PSN-facing PW (ingress) Receive Fault".
* 「0x00000008-ローカルPSNに面したPW（イングレス）受信障害」を含むS-PE1に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".
*
* Send a PW status message to S-PE3 containing "0x00000008 - Local PSN-facing PW (ingress) Receive Fault".
* 「0x00000008-ローカルPSNに面したPW（イングレス）受信障害」を含むS-PE3に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".
* 「0x00000008-ローカルPSNに面したPW（イングレス）受信障害」を含むS-PE3にPWステータスメッセージを送信します。
* Send a PW status message to S-PE1 containing "0x00000010 - Local PSN-facing PW (egress) Transmit Fault".
* 「0x00000010-ローカルPSNに面したPW（出口）送信障害」を含む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".
* 「0x00000008-ローカルPSNに面したPW（イングレス）受信障害」を含むS-PE1にPWステータスメッセージを送信します。
* Send a PW status message to S-PE3 containing "0x00000010 - Local PSN-facing PW (egress) Transmit Fault".
* 「0x00000010-ローカルPSNに面したPW（出口）送信障害」を含む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によって受信されたリモートPWステータス障害メッセージは、S-PEに対応する局所障害がない場合にのみ転送されます。（局所断層は常に遠隔障害に取って代わります。）
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ステータスメッセージが隣接するPESに送信され、障害がクリアされます。
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.
SP-PE TLVを含むPWステータスメッセージが受信されると、上記の手順に従ってPWステータスワードの内容とともに、SP-PE TLV情報が保存される場合があります。保存されている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スイッチングアーキテクチャは、T-PEがPWセグメントのセットアップに参加している場合と同じ方法で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.
このドキュメントで概説されている手順は、MS-PWSの交差点を境界として提供および管理するために使用できます。自動発見を含むより高度なメカニズムの使用と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.
このドキュメントは、擬似動物のセットアップと維持に必要なLDP、L2TPV3、およびVCCV拡張機能を指定します。擬似動物を設定する目的は、レイヤー2フレームを擬似ワイヤの一方の端からもう一方の端にカプセル化および送信できるようにすることです。したがって、次のセクションでは、データプレーンとコントロールプレーンの両方のセキュリティ上の考慮事項について説明します。[RFC5920]で指定されたガイドラインとセキュリティ上の考慮事項は、PSNがMPLSの場合、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ネットワークと非常によく似たプロセスです。CWが有効になっていないときにPWにVCCVタイプ3を使用する場合、PACKETがMS-PWパスに沿ったホップ数よりも大きいTTLで作成されている場合、またはパスに沿ったS-PEがMISに沿ったS-PEで作成されている場合に注意してください。TTLを処理すると、パケットはネイティブPWパケットとしてアタッチメント回路から誤って転送される可能性があります。このパケットは、CEによってエラーパケットとして扱われる可能性が最も高いでしょう。ただし、この可能性が受け入れられない場合、VCCVパケットがACに誤って転送されないことを保証するためにCWを有効にする必要があります。
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.
LDPの使用に関する一般的なセキュリティ上の考慮事項は、RFC 5036のセクション5で指定されています。L2TPV3コントロールプレーンに関するセキュリティに関する考慮事項は、[RFC3931]で指定されています。これらの考慮事項は、LDPまたはL2TPV3がPWSのセットアップに使用される場合にも当てはまります。
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.)
擬似ワイヤは、2つのアタッチメントサーキットを接続します。LDP接続がどこからでも任意に受け入れられないことを確認することが重要です。そうしないと、ローカルアタッチメント回路が任意のリモートアタッチメント回路に接続される可能性があります。したがって、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]のコントロールメッセージ認証オプションを使用できます。これにより、制御メッセージの整合性と認証が提供され、ソースアドレスのスプーフィングの可能性がなくなります。メッセージ認証オプションの使用はプライバシーを提供しませんが、コントロールメッセージのプライバシーは通常非常に重要であるとは見なされません。LDPと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全体に関連付けられた適格なピアのセットだけでなく、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タイプ名スペース」をすでに維持しています。次の値が割り当てられています。
TLV type Description 0x096D Pseudowire Switching Point PE TLV
TLVタイプの説明0x096D PSEUDOWIREスイッチングポイント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:
このドキュメントでは、新しいLDPステータスコードを使用しています。IANAは、RFC 5036で定義されたレジストリ「ステータスコード名スペース」をすでに維持しています。次の値は割り当てられています。
Assignment E Description 0x0000003A 0 PW Loop Detected
割り当てe説明0x0000003a 0 PWループが検出されました
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:
レジストリ名：結果コードAVP（属性タイプ1）値CDNメッセージの結果の結果コード値は次のとおりです。
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は、「Pseudowire Switching Point PE Sub-TLVタイプ」という名前のレジストリを設定しました。これらは8ビット値です。タイプ値1〜6は、このドキュメントで定義されています。タイプ値7〜64は、[RFC5226]で定義された「エキスパートレビュー」ポリシーを使用してIANAによって割り当てられます。タイプ値65〜127、および0および255は、RFC 5226で定義されたIETFコンセンサスポリシーを使用して割り当てられます。タイプ値128から254は、ベンダー独自の拡張用に予約されており、「最初の」を使用してIANAによって割り当てられます。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 4最後のPWセグメントのPWIDトラバース0x02変数PWスイッチングポイント説明文字列0x03 4/16 PWスイッチングポイントのローカルIPアドレス0x04 4/16最後のPWスイッチングポイントのリモートIPアドレストラバースまたはT-PE 0x05変数変数FEC要素最後のPWセグメントは0x06 12 L2 PWスイッチングポイントのPWアドレスを通過しました
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Lau、J.、ed。、Ed。、Townsley、M.、ed。、およびI. Goyret、ed。、「レイヤー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] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想ネットワーク（VPNS）」、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. Swallow、「Multi-Protocol Label Switched（MPLS）データプレーン障害の検出」、RFC 4379、2006年2月。
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.
[RFC4385] Bryant、S.、Swallow、G.、Martini、L。、およびD. McPherson、「Pseudowire Emulation Edge-to-Edge（PWE3）がMPLS PSNを介して使用するコントロールワード」、RFC 4385、2006年2月。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4446] Martini、L。、「Pseudowire Edge to Edge Emulation（PWE3）のIANAの割り当て」、BCP 116、RFC 4446、2006年4月。
[RFC4447] Martini, L., 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] Martini、L.、Ed。、Ed。、Rosen、E.、El-Aawar、N.、Smith、T.、およびG. Heron、「ラベル分布プロトコル（LDP）を使用した擬似ワイヤーのセットアップとメンテナンス」、RFC 4447、2006年4月。
[RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto, "Attachment Individual Identifier (AII) Types for Aggregation", RFC 5003, September 2007.
[RFC5003] Metz、C.、Martini、L.、Balus、F。、およびJ. Sugimoto、「集約のためのアタッチメント個体識別子（AII）タイプ」、RFC 5003、2007年9月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、ed。、Minei、I.、ed。、およびB. Thomas、ed。、「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] Nadeau、T.、ed。、およびC. Pignataro、ed。、「Pseudowire Virtual Curned Connectivity Verification（VCCV）：Pseudowiresの制御チャネル」、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] McGill、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.、Morrow、M.、Martini、L.、Stein、Y（J）。、Allan、D.、およびT. Nadeau、 "Pseudowire（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] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「Mpls Label Stack Encoding」、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）考慮事項更新」、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] Bryant、S.、ed。、およびP. Pate、ed。、「Pseudo Wire Emulation Edge-to-Edge（PWE3）Architecture」、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. Rosen、ed。、「IPまたは汎用ルーティングカプセル化（GRE）のMPLのカプセル化」、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] Singh、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、「Pseudowire Emulation Edge-to-Edge（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] Luo、W。、「レイヤー2仮想プライベートネットワーク（L2VPN）レイヤー2トンネリングプロトコル（L2TP）の拡張機能」、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] Martini、L.、Jayakumar、J.、Bocci、M.、El-Aawar、N.、Brayley、J。、およびG. Koleyni、「MPLSネットワーク上の非同期移転モード（ATM）の輸送のためのカプセル化方法」"、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] Bitar、N.、ed。、Bocci、M.、ed。、およびL. Martini、ed。、「マルチセグメント擬似ワイヤーエミュレーションエッジツーエッジ（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] Bocci、M。およびS. Bryant、「マルチセグメントの擬似ワイヤーエミュレーションエッジツーエッジのアーキテクチャ」、RFC 5659、2009年10月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L.、ed。、「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.
著者は、Satoru Matsushima、Wei Luo、Neil McGill、Skip Booth、Neil Hart、Michael Hua、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
Florin Balus Alcatel-Lucent 701 East Middlefield Rd。Mountain View、CA 94043 US Email：florin.balus@alcatel-lucent.com
Mike Duckett Bellsouth Lindbergh Center, D481 575 Morosgo Dr Atlanta, GA 30324 US EMail: mduckett@bellsouth.net
Mike Duckett Bellsouth Lindbergh Center、D481 575 Morosgo Dr Atlanta、GA 30324 US Email：mduckett@bellsouth.net
Authors' Addresses
著者のアドレス
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO 80112 US EMail: lmartini@cisco.com
Luca Martini Cisco Systems、Inc。9155 East Nichols Avenue、Suite 400 Englewood、Co 80112 US Email：lmartini@cisco.com
Chris Metz Cisco Systems, Inc. EMail: chmetz@cisco.com
Chris Metz Cisco Systems、Inc。電子メール：chmetz@cisco.com
Thomas D. Nadeau EMail: tnadeau@lucidvision.com
Thomas D. Nadeauメール：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
Matthew Bocci Alcatel-Lucent Grove House、Waltham Road Rd White Waltham、Berks SL6 3TN UKメール：matthew.bocci@alcatel-lucent.co.uk
Mustapha Aissaoui Alcatel-Lucent 600, March Road, Kanata, ON Canada EMail: mustapha.aissaoui@alcatel-lucent.com
Mustapha aissaoui Alcatel-Lucent 600、March Road、Kanata、Canada email：mustapha.aissaoui@alcatel-lucent.com