[要約] 要約：RFC 5994は、Ethernet擬似ワイヤをMPLSトランスポートネットワークに適用する方法について説明しています。 目的：このRFCの目的は、Ethernet擬似ワイヤを使用してMPLSトランスポートネットワークを構築するためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) S. Bryant, Ed.
Request for Comments: 5994 M. Morrow
Category: Informational G. Swallow
ISSN: 2070-1721 Cisco Systems
R. Cherukuri
Juniper Networks
T. Nadeau
Huawei Technologies
N. Harrison
BT
B. Niven-Jenkins
Velocix
October 2010
Application of Ethernet Pseudowires to MPLS Transport Networks
MPLS輸送ネットワークへのイーサネット擬似動物の適用
Abstract
概要
Ethernet pseudowires are widely deployed to support packet transport of Ethernet services. These services in-turn provide transport for a variety of client networks, e.g., IP and MPLS. This document uses procedures defined in the existing IETF specifications of Ethernet pseudowires carried over MPLS networks.
イーサネットの擬似ワイヤは、イーサネットサービスのパケット輸送をサポートするために広く展開されています。これらのサービスは、さまざまなクライアントネットワーク、例えばIPやMPLSの輸送を提供します。このドキュメントでは、MPLSネットワークを介して運ばれたイーサネットの擬似動物の既存のIETF仕様で定義された手順を使用します。
Many of the requirements for the services provided by the mechanisms explained in this document are also recognized by the MPLS transport profile (MPLS-TP) design effort formed jointly by the IETF and ITU-T. The solution described here does not address all of the MPLS-TP requirements, but it provides a viable form of packet transport service using tools that are already available.
このドキュメントで説明されているメカニズムによって提供されるサービスの要件の多くは、IETFとITU-Tによって共同で形成されたMPLS輸送プロファイル（MPLS-TP）設計の取り組みによっても認識されています。ここで説明するソリューションは、MPLS-TP要件のすべてに対処するわけではありませんが、すでに利用可能なツールを使用して、実行可能な形式のパケット輸送サービスを提供します。
This document also serves as an indication that existing MPLS techniques form an appropriate basis for the design of a fully-featured packet transport solution addressing all of the requirements of MPLS-TP.
このドキュメントは、既存のMPLS手法がMPLS-TPのすべての要件に対処する完全に機能するパケットトランスポートソリューションの設計に適切な基礎を形成することを示すものとしても機能します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc5994.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5994で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. PWE3 Configuration . . . . . . . . . . . . . . . . . . . . . . 5
3. Operations, Administration, and Maintenance (OAM) . . . . . . 5
3.1. VCCV Profile 1: BFD without IP/UDP Headers . . . . . . . . 6
3.2. VCCV Profile 2: BFD with IP/UDP Headers . . . . . . . . . 6
4. MPLS Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. External Configuration . . . . . . . . . . . . . . . . . . 6
4.2. Control Plane Configuration . . . . . . . . . . . . . . . 7
5. Congestion Considerations . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Ethernet pseudowires are widely deployed to support packet transport of Ethernet services. These services in-turn provide transport for a variety of client networks, e.g., IP and MPLS. This document uses procedures defined in the existing IETF specifications of Ethernet pseudowires carried over MPLS networks.
イーサネットの擬似ワイヤは、イーサネットサービスのパケット輸送をサポートするために広く展開されています。これらのサービスは、さまざまなクライアントネットワーク、例えばIPやMPLSの輸送を提供します。このドキュメントでは、MPLSネットワークを介して運ばれたイーサネットの擬似動物の既存のIETF仕様で定義された手順を使用します。
Many of the requirements for the services provided by the mechanisms explained in this document are also recognized by the MPLS transport profile (MPLS-TP) design effort formed jointly by the IETF and ITU-T [RFC5654]. For example, the ability to operate solely with network management control, the ability to use Operations, Administration, and Maintenance (OAM) that does not rely on IP forwarding, and the ability to provide light-weight proactive connection verification (CV) functionality.
このドキュメントで説明されているメカニズムによって提供されるサービスの要件の多くは、IETFとITU-T [RFC5654]によって共同で形成されたMPLS輸送プロファイル（MPLS-TP）設計の取り組みによっても認識されています。たとえば、ネットワーク管理制御のみで動作する能力、IP転送に依存しない運用、管理、およびメンテナンス（OAM）を使用する能力、および軽量のプロアクティブ接続検証（CV）機能を提供する能力。
The solution described in this document does not address all of the MPLS-TP requirements, but it provides a viable form of packet transport service using tools that are already available.
このドキュメントで説明されているソリューションは、MPLS-TP要件のすべてに対処するわけではありませんが、すでに利用可能なツールを使用して、実行可能な形式のパケット輸送サービスを提供します。
The key purpose of this document is to demonstrate that there is an existing IETF mechanism with known implementations that satisfies the requirements posed by the operator community. It is recognized that it is possible to design a more efficient method of satisfying the requirements, and the IETF anticipates that improved solutions will be proposed in the future as part of the MPLS-TP effort. Indeed, the solution described in this document is not intended to detract from the MPLS-TP effort. Instead, it provides legitimacy for that work by showing that there is a real demand from networks that are already deployed, and by indicating that the MPLS-TP solutions work is based on sound foundations.
このドキュメントの重要な目的は、オペレーターコミュニティによってもたらされる要件を満たす既知の実装を備えた既存のIETFメカニズムがあることを実証することです。要件を満たすより効率的な方法を設計することが可能であることが認識されており、IETFは、MPLS-TPの取り組みの一環として、将来改善されたソリューションが提案されると予想しています。実際、このドキュメントで説明されているソリューションは、MPLS-TPの取り組みを損なうことを意図していません。代わりに、すでに展開されているネットワークからの実際の需要があることを示すことにより、その作業の正当性を提供し、MPLS-TPソリューションの作業が健全な基礎に基づいていることを示すことにより。
Much of the notation used in this document is defined in [RFC3985] to which the reader is referred for definitions.
このドキュメントで使用されている表記の多くは、[RFC3985]で定義されており、読者は定義について紹介されています。
The architecture required for this mechanism is illustrated in Figure 1.
このメカニズムに必要なアーキテクチャを図1に示します。
+----------------------------------------------------------------+
| |
| IP/MPLS PSN (PHP may be enabled) |
| (client) |
| |
| +---------------------------+ |
| | | |
| | MPLS PSN (No PHP) | |
| | (server) | |
| | | |
| CE1 |PE1 PE2| CE2 |
| +-----+ +-----+ +-----+ +-----+ |
| | | | | | | | | | | | | | | | | |
| | | | +------+ | | | | | | +------+ | | | |
| | | | | 802.3| | | | | | | | 802.3| | | | |
| +-----+ +-----+ +-----+ +-----+ |
| | | | | | | | | |
| | | +-- ---------------------- -+ | | |
+----- --- -------- -- ---------------------- - -------- --- ----+
| | | |<--MPLS LSP (no PHP)->| | | |
| | | | (server) | | | |
| | | | | |
| | |<------------PW----------->| | |
| | | (server) | | |
| | | |
| |<-------------802.3 (Ethernet)-------------->| |
| | (client) | |
| |
|<---------IP/MPLS LSP (PHP may be supported)-------->|
| (client) |
Figure 1: Application Ethernet over MPLS PW to MPLS Transport Networks
図1：MPLS PWからMPLS輸送ネットワークを介したアプリケーションイーサネット
An 802.3 (Ethernet) circuit is established between CE1 and CE2. This circuit may be used for the concurrent transport of MPLS packets as well as IPv4 and IPv6 packets. The MPLS packets may carry IPv4, IPV6, or pseudowire payloads, and Penultimate Hop Popping (PHP) may be used. For clarity, these paths are labeled as the client in Figure 1.
802.3（イーサネット）回路は、CE1とCE2の間に確立されています。この回路は、MPLSパケットの同時輸送とIPv4およびIPv6パケットに使用できます。MPLSパケットは、IPv4、IPv6、またはPseudowireペイロードを搭載し、最後から2番目のホップポップ（PHP）を使用する場合があります。明確にするために、これらのパスは図1のクライアントとしてラベル付けされています。
An Ethernet pseudowire (PW) is provisioned between PE1 and PE2 and is used to carry the Ethernet from PE1 to PE2. The Ethernet PW is carried over an MPLS Packet Switched Network (PSN), but this PSN MUST NOT be configured with PHP. For clarity, this Ethernet PW and the MPLS PSN are labeled as the server in Figure 1. In the remainder of this document, call the server network a transport network.
Ethernet Pseudowire（PW）はPE1とPE2の間でプロビジョニングされ、PE1からPE2にイーサネットを運ぶために使用されます。イーサネットPWはMPLSパケットスイッチネットワーク（PSN）に携帯されていますが、このPSNはPHPで構成する必要はありません。明確にするために、このイーサネットPWとMPLS PSNは、図1のサーバーとしてラベル付けされています。このドキュメントの残りの部分では、サーバーネットワークを輸送ネットワークと呼びます。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
The PWE3 encapsulation used by this specification to satisfy the transport requirement is Ethernet [RFC4448]. This is used in "raw" mode.
輸送要件を満たすためにこの仕様で使用されるPWE3カプセル化はイーサネット[RFC4448]です。これは「RAW」モードで使用されます。
The Control Word MUST be used. The sequence number MUST be zero.
コントロールワードを使用する必要があります。シーケンス番号はゼロでなければなりません。
The use of the Pseudowire Setup and Maintenance Label Distribution Protocol [RFC4447] is not required by the profile of the PWE3 Ethernet pseudowire functionality defined in this document.
Pseudowireのセットアップおよびメンテナンスラベル分布プロトコル[RFC4447]の使用は、このドキュメントで定義されているPWE3イーサネットの擬似ワイヤ機能のプロファイルによっては必要ありません。
The pseudowire label is statically provisioned.
Pseudowireラベルは静的にプロビジョニングされています。
Within a connection, traffic units sent from the single source are constrained to stay within the connection under defect-free conditions. During misconnected defects, a connection can no longer be assumed to be constrained, and traffic units (and by implication also OAM packets) can 'leak' unidirectionally outside a connection. Therefore, during a misconnected state, it is not possible to rely on OAM, which relies on a request/response mechanism, and, for this reason, such OAM should be treated with caution if used for diagnostic purposes.
接続内で、単一のソースから送信されるトラフィックユニットは、欠陥のない条件下で接続内にとどまるように制約されます。誤った接続された欠陥の間、接続が制約されていると想定することはできなくなり、トラフィックユニット（および含意により、パケットも含む）は、接続の外側に一方的に「漏れ」することができます。したがって、誤接続された状態では、要求/応答メカニズムに依存するOAMに依存することはできません。このため、診断目的で使用する場合は、そのようなOAMは注意して扱う必要があります。
Further, when implementing an Equal Cost Multipath (ECMP) function with MPLS, use of the label stack as the path selector such that the OAM and data are not in a co-path SHOULD be avoided, as any failure in the data path will not be reflected in the OAM path. Therefore, an OAM that is carried within the data-path below the PW label (such as Virtual Circuit Connectivity Verification (VCCV)) is NOT vulnerable to the above failure mode. For these reasons, the OAM mechanism is as described in [RFC5085], which uses Bidirectional Forwarding Detection (BFD) [RFC5880] for connection verification (CV). The method of using BFD as a CV method in VCCV is described in [RFC5885]. One of the VCCV profiles described in Section 3.1 or Section 3.2 MUST be used. Once a VCCV control channel is provisioned and the operational status of the PW is UP, no other profile should be used until such time as the PW's operational status is set to DOWN.
さらに、MPLSを使用して等しいコストマルチパス（ECMP）関数を実装する場合、データパスの障害がないため、OAMとデータが共同パスに含まれないようにパスセレクターとしてラベルスタックを使用すると、OAMパスに反映されます。したがって、PWラベル（仮想回路接続検証（VCCV）など）の下のデータパス内で運ばれるOAMは、上記の障害モードに対して脆弱ではありません。これらの理由から、OAMメカニズムは[RFC5085]に記載されているとおりであり、接続検証（CV）に双方向転送検出（BFD）[RFC5880]を使用しています。VCCVのCVメソッドとしてBFDを使用する方法は、[RFC5885]で説明されています。セクション3.1またはセクション3.2で説明するVCCVプロファイルの1つを使用する必要があります。VCCV制御チャネルがプロビジョニングされ、PWの動作ステータスが増加すると、PWの動作ステータスが下に設定されるまで他のプロファイルを使用する必要はありません。
When PE1 and PE2 are not IP capable or have not been configured with IP addresses, the following VCCV mechanism SHOULD be used.
PE1とPE2がIP対応またはIPアドレスで構成されていない場合、次のVCCVメカニズムを使用する必要があります。
The connection verification method used by VCCV is BFD with diagnostics as defined in [RFC5885].
VCCVで使用される接続検証方法は、[RFC5885]で定義されているように診断を伴うBFDです。
[RFC5085] specifies that the first nibble is set to 0x1 to indicate a channel associated with a pseudowire [RFC4385].
[RFC5085]は、最初のニブルが0x1に設定されていることを指定して、擬似化に関連するチャネル[RFC4385]を示しています。
The Version and the Reserved fields are set to zero, and the Channel Type is set to 0x7 to indicate that the payload carried is BFD without IP/UDP headers, as is defined in [RFC5885].
バージョンと予約済みフィールドはゼロに設定されており、チャネルタイプは0x7に設定されており、[RFC5885]で定義されているように、伝達されるペイロードがIP/UDPヘッダーなしでBFDであることを示します。
When PE1 and PE2 are IP capable and have been configured with IP addresses, the following VCCV mechanism may be used.
PE1とPE2がIP対応であり、IPアドレスで構成されている場合、次のVCCVメカニズムを使用できます。
The connection verification method used by VCCV is BFD with diagnostics as defined in [RFC5885].
VCCVで使用される接続検証方法は、[RFC5885]で定義されているように診断を伴うBFDです。
[RFC5085] specifies that the first nibble is set to 0x1 to indicate a channel associated with a pseudowire [RFC4385].
[RFC5085]は、最初のニブルが0x1に設定されていることを指定して、擬似化に関連するチャネル[RFC4385]を示しています。
The Version and the Reserved fields are set to 0, and the Channel Type is set to 0x21 for IPv4 and 0x56 for IPv6 payloads [RFC4446].
バージョンと予約済みフィールドは0に設定され、チャネルタイプはIPv4では0x21、IPv6ペイロードの場合は0x56に設定されています[RFC4446]。
The architecture of MPLS-enabled networks is described in [RFC3031]. This section describes a subset of the functionality of the MPLS-enabled PSN. There are two cases that need to be considered:
MPLS対応ネットワークのアーキテクチャは[RFC3031]で説明されています。このセクションでは、MPLS対応PSNの機能のサブセットについて説明します。考慮する必要がある2つのケースがあります。
1. The case where external configuration is used.
1. 外部構成が使用される場合。
2. The case where a control plane is available.
2. コントロールプレーンが利用可能な場合。
Where the use of a control plane is desired, this may be based on Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945].
コントロールプレーンの使用が必要な場合、これは一般化されたマルチプロトコルラベルスイッチング（GMPLS）[RFC3945]に基づいている可能性があります。
The use of external provisioning is not precluded from being supported by the current MPLS specifications. It is however explicitly described in this specification to address the requirements specified by the ITU [RFC5654] to address the needs in a transport environment.
外部プロビジョニングの使用は、現在のMPLS仕様によってサポートされることを妨げられません。ただし、この仕様では、輸送環境のニーズに対処するためにITU [RFC5654]によって指定された要件に対処するために、この仕様で明示的に説明されています。
The MPLS encapsulation is specified in [RFC3032]. All MPLS labels used in the server layer (Figure 1) MUST be statically provisioned. Labels may be selected from either the per-platform or the per-interface label space.
MPLSカプセル化は[RFC3032]で指定されています。サーバーレイヤー（図1）で使用されるすべてのMPLSラベルは、静的にプロビジョニングする必要があります。ラベルは、プラットフォームごとまたはインターフェイスごとのラベルスペースから選択できます。
All transport Label Switched Paths (LSPs) utilized by the PWs described in Section 2 MUST support both unidirectional and bidirectional point-to-point connections.
セクション2で説明されているPWSによって利用されるすべてのトランスポーターラベルスイッチ付きパス（LSP）は、単方向と双方向の両方のポイントツーポイント接続の両方をサポートする必要があります。
The transport LSPs SHOULD support unidirectional point-to-multipoint connections.
トランスポートLSPは、単方向のポイントツーマルチポイント接続をサポートする必要があります。
The forward and backward directions of a bidirectional connection SHOULD follow a symmetrically routed (reciprocal) LSP in the server network.
双方向接続の前方方向と後方方向は、サーバーネットワークの対称的にルーティングされた（相互）LSPに従う必要があります。
Equal Cost Multipath (ECMP) load balancing MUST NOT be configured on the transport LSPs utilized by the PWs described in Section 2.
等しいコストマルチパス（ECMP）ロードバランシングは、セクション2で説明されているPWSによって使用される輸送LSPで構成されてはなりません。
The merging of Label Switched Paths is prohibited and MUST NOT be configured for the transport LSPs utilized by the PWs described in Section 2.
ラベルスイッチされたパスのマージは禁止されており、セクション2で説明したPWSによって使用される輸送LSPに対して構成されてはなりません。
Penultimate hop popping by the transport Label Switched Routers (LSRs) MUST be disabled on transport LSPs.
トランスポートラベルスイッチ付きルーター（LSR）によってポップポップする最後から2番目のホップは、輸送LSPで無効にする必要があります。
Both EXP-Inferred-PSC LSPs (E-LSP) and Label-Only-Inferred-PSC LSPs (L-LSP) MUST be supported as defined in [RFC3270].
expinferred-PSC LSP（E-LSP）とラベルのみの有名-PSC LSP（L-LSP）の両方は、[RFC3270]で定義されているようにサポートする必要があります。
For the MPLS EXP field [RFC3270] [RFC5462], only the pipe and short-pipe models are supported.
MPLS EXPフィールド[RFC3270] [RFC5462]の場合、パイプモデルと短パイプモデルのみがサポートされています。
In this section, we describe the control plane configuration when [RFC3209] or the bidirectional support in GMPLS ([RFC3471] and [RFC3473]) are used to configure the transport MPLS PSN. When these protocols are used to provide the control plane, the following are automatically provided:
このセクションでは、[RFC3209]またはGMPLS（[RFC3471]および[RFC3473]）での双方向サポートを使用して、トランスポートMPLS PSNを構成するために使用される場合の制御プレーン構成について説明します。これらのプロトコルを使用してコントロールプレーンを提供する場合、以下が自動的に提供されます。
1. There is no label merging unless it is deliberately enabled to support Fast Re-route (FRR) [RFC3209].
1. Fast Re-Route（FRR）[RFC3209]をサポートすることを意図的に有効にしない限り、ラベルマージはありません。
2. A single path is provided end-to-end (there is no ECMP).
2. 単一のパスがエンドツーエンド（ECMPはありません）が提供されます。
3. Label Switched Paths may be unidirectional or bidirectional as required.
3. ラベルスイッチされたパスは、必要に応じて一方向または双方向である場合があります。
Additionally, the following configuration restrictions required to support external configuration MUST be applied:
さらに、外部構成をサポートするために必要な次の構成制限を適用する必要があります。
o Penultimate hop popping [RFC3031] by the LSRs MUST be disabled on LSPs providing PWE3 transport network functionality.
o PWE3トランスポートネットワーク機能を提供するLSPでLSRSによる2番目のホップポップ[RFC3031]は無効にする必要があります。
o Both E-LSP and L-LSP MUST be supported as defined in [RFC3270].
o E-LSPとL-LSPの両方は、[RFC3270]で定義されているようにサポートする必要があります。
o The MPLS EXP [RFC5462] field is supported according to [RFC3270] only when the pipe and short-pipe models are utilized.
o MPLS EXP [RFC5462]フィールドは、[RFC3270]に従ってサポートされています。パイプと短パイプモデルが使用されている場合のみです。
This document describes a method of using the existing PWE3 Ethernet pseudowire [RFC4448] to solve a particular network application. The congestion considerations associated with that pseudowire and all subsequent work on congestion considerations regarding Ethernet pseudowires are applicable to this RFC.
このドキュメントでは、既存のPWE3イーサネットPSEUDOWIRE [RFC4448]を使用して、特定のネットワークアプリケーションを解決する方法について説明します。その擬似ワイヤーに関連する渋滞の考慮事項と、イーサネットの擬似動物に関する混雑に関する考慮事項に関するその後のすべての作業は、このRFCに適用されます。
This RFC provides a description of the use of existing IETF Proposed Standards to solve a network problem, and raises no new security issues.
このRFCは、ネットワークの問題を解決するために既存のIETF提案標準の使用の説明を提供し、新しいセキュリティの問題を提起しません。
The PWE3 security considerations are described in [RFC3985] and the Ethernet pseudowire security considerations of [RFC4448].
PWE3のセキュリティ上の考慮事項は、[RFC3985]および[RFC448]のイーサネット擬似ワイヤーセキュリティに関する考慮事項で説明されています。
The Ethernet pseudowire is transported on an MPLS PSN; therefore, the security of the pseudowire itself will only be as good as the security of the MPLS PSN. The server MPLS PSN can be secured by various methods, as described in [RFC3031].
イーサネットの擬似ワイヤは、MPLS PSNで輸送されます。したがって、擬似ワイヤ自体のセキュリティ自体は、MPLS PSNのセキュリティと同じくらい優れているでしょう。サーバーMPLS PSNは、[RFC3031]で説明されているように、さまざまな方法で保護できます。
The use of static configuration exposes an MPLS PSN to a different set of security risks to those found in a PSN using dynamic routing. If a path is misconfigured in a statically configured network, the result can be a persistent black hole, or much worse, a persistent forwarding loop. On the other hand, most of the distributed components are less complex. This is however offset by the need to provide fail-over and redundancy in the management and configuration system and the communications paths between those central systems and the LSRs.
静的構成を使用すると、MPLS PSNが異なるセキュリティリスクに、動的ルーティングを使用してPSNで見つかったリスクにさらされます。静的に構成されたネットワークでパスが誤解されている場合、結果は永続的なブラックホール、またははるかに悪いことに、永続的な転送ループになります。一方、分散コンポーネントのほとんどはそれほど複雑ではありません。ただし、これは、管理および構成システムとそれらの中央システムとLSRの間の通信パスでフェールオーバーと冗長性を提供する必要性によって相殺されます。
Security achieved by access control of media access control (MAC) addresses, and the security of the client layers, is out of the scope of this document.
メディアアクセス制御（MAC）アドレスのアクセス制御とクライアントレイヤーのセキュリティによって達成されるセキュリティは、このドキュメントの範囲外です。
The authors wish to thank Matthew Bocci, John Drake, Adrian Farrel, Andy Malis, and Yaakov Stein for their review and proposed enhancements to the text.
著者は、マシュー・ボッチ、ジョン・ドレイク、エイドリアン・ファレル、アンディ・マリス、ヤアコフ・スタインのレビューとテキストの強化を提案してくれたことに感謝したいと考えています。
[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月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[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月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSP TunnelsのRSVPへの拡張"、RFC 3209、12月2001年。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P。、およびJ. Heinanen、「Multi-Protocol Label Switching」（MPLS）差別化されたサービスのサポート」、RFC 3270、2002年5月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナルリソースリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] Mannie、E。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ」、RFC 3945、2004年10月。
[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., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447] Martini、L.、Rosen、E.、El-Aawar、N.、Smith、T.、およびG. Heron、「ラベル分布プロトコル（LDP）を使用したPseudowireのセットアップとメンテナンス」、RFC 4447、2006年4月。
[RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.
[RFC4448] Martini、L.、Rosen、E.、El-Aawar、N。、およびG. Heron、「MPLSネットワーク上のイーサネットの輸送のためのカプセル化方法」、RFC 4448、2006年4月。
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5085] Nadeau、T。およびC. Pignataro、「Pseudowire仮想回路接続検証（VCCV）：Pseudowiresの制御チャネル」、RFC 5085、2007年12月。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5462] Andersson、L。and R. Asati、「マルチプロトコルラベルスイッチング（MPLS）ラベルスタックエントリ：「Exp」フィールド「トラフィッククラス」フィールドに改名されたフィールド、RFC 5462、2009年2月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880] Katz、D。およびD. Ward、「双方向転送検出（BFD）」、RFC 5880、2010年6月。
[RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, June 2010.
[RFC5885] Nadeau、T。およびC. Pignataro、「Pseudowire仮想回路接続検証（VCCV）の双方向転送検出（BFD）」、2010年6月、RFC 5885。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985] Bryant、S。およびP. Pate、「Pseudo Wire Emulation Edge-to-Edge（PWE3）アーキテクチャ」、RFC 3985、2005年3月。
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[RFC5654] Niven-Jenkins、B.、Brungard、D.、Betts、M.、Sprecher、N。、およびS. Ueno、「MPLS輸送プロファイルの要件」、RFC 5654、2009年9月。
Authors' Addresses
著者のアドレス
Stewart Bryant (editor) Cisco Systems 250, Longwater, Green Park Reading RG2 6GB UK
スチュワートブライアント（編集者）シスコシステム250、ロングウォーター、グリーンパークリーディングRG2 6GB UK
EMail: stbryant@cisco.com
Monique Morrow
Cisco Systems
Glatt-com
CH-8301 Glattzentrum
Switzerland
EMail: mmorrow@cisco.com
George Swallow Cisco Systems 1414 Massachusetts Ave. Boxborough, MA 01719
ジョージ・スワロー・シスコ・システム1414マサチューセッツ・アベニュー・ボックスボロー、マサチューセッツ州01719
EMail: swallow@cisco.com
Rao Cherukuri Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089
Rao Cherukuri Juniper Networks 1194 N. Mathilda Ave. Sunnyvale、CA 94089
EMail: cherukuri@juniper.net
Thomas D. Nadeau Huawei Technologies Central Expressway Santa Clara, CA 95050
トーマス・D・ナドー・ホーウェイ・テクノロジーズセントラルエクスプレスウェイサンタクララ、カリフォルニア95050
EMail: thomas.nadeau@huawei.com
Neil Harrison BT
ニール・ハリソンbt
EMail: neil.2.harrison@bt.com
Ben Niven-Jenkins Velocix 326 Science Park Milton Road, Cambridge CB4 0WG UK
Ben Niven-Jenkins Velocix 326 Science Park Milton Road、Cambridge CB4 0WG UK
EMail: ben@niven-jenkins.co.uk