[要約] RFC 3916は、Pseudo-Wire Emulation Edge-to-Edge（PWE3）の要件を定義しています。その目的は、異なるネットワーク間での仮想回線のエミュレーションを可能にするためのガイドラインを提供することです。
Network Working Group X. Xiao, Ed.
Request for Comments: 3916 Riverstone Networks
Category: Informational D. McPherson, Ed.
Arbor Networks
P. Pate, Ed.
Overture Networks
September 2004
Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)
擬似ワイヤエミュレーションエッジとエッジの要件（PWE3）
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
This document describes base requirements for the Pseudo-Wire Emulation Edge to Edge Working Group (PWE3 WG). It provides guidelines for other working group documents that will define mechanisms for providing pseudo-wire emulation of Ethernet, ATM, and Frame Relay. Requirements for pseudo-wire emulation of TDM (i.e., "synchronous bit streams at rates defined by ITU G.702") are defined in another document. It should be noted that the PWE3 WG standardizes mechanisms that can be used to provide PWE3 services, but not the services themselves.
このドキュメントでは、擬似ワイヤエミュレーションエッジからエッジワーキンググループ（PWE3 WG）の基本要件について説明します。イーサネット、ATM、およびフレームリレーの擬似ワイヤエミュレーションを提供するためのメカニズムを定義する他のワーキンググループドキュメントのガイドラインを提供します。TDMの擬似ワイヤエミュレーションの要件（つまり、 "ITU G.702で定義されたレートでの同期ビットストリーム"）は、別のドキュメントで定義されています。PWE3 WGは、サービス自体ではなく、PWE3サービスを提供するために使用できるメカニズムを標準化することに注意する必要があります。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. What Are Pseudo Wires?. . . . . . . . . . . . . . . . . 2
1.2. Current Network Architecture. . . . . . . . . . . . . . 3
1.3. PWE3 as a Path to Convergence . . . . . . . . . . . . . 4
1.4. Suitable Applications for PWE3. . . . . . . . . . . . . 4
1.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Reference Model of PWE3 . . . . . . . . . . . . . . . . . . . 6
4. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Encapsulation . . . . . . . . . . . . . . . . . . . . . 7
4.2. Frame Ordering. . . . . . . . . . . . . . . . . . . . . 8
4.3. Frame Duplication . . . . . . . . . . . . . . . . . . . 8
4.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . 8
4.5. Consideration of Per-PSN Packet Overhead. . . . . . . . 9
5. Maintenance of Emulated Services. . . . . . . . . . . . . . . 9
5.1. Setup and Teardown of Pseudo-Wires. . . . . . . . . . . 9
5.2. Handling Maintenance Message of the Native Services . . 10
5.3. PE-initiated Maintenance Messages . . . . . . . . . . . 10
6. Management of Emulated Services . . . . . . . . . . . . . . . 12
6.1. MIBs. . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. General MIB Requirements. . . . . . . . . . . . . . . . 12
6.3. Configuration and Provisioning. . . . . . . . . . . . . 13
6.4. Performance Monitoring. . . . . . . . . . . . . . . . . 13
6.5. Fault Management and Notifications. . . . . . . . . . . 13
6.6. Pseudo-Wire Connection Verification and Traceroute. . . 13
7. Faithfulness of Emulated Services . . . . . . . . . . . . . . 13
7.1. Characteristics of an Emulated Service. . . . . . . . . 14
7.2. Service Quality of Emulated Services. . . . . . . . . . 14
8. Non-Requirements. . . . . . . . . . . . . . . . . . . . . . . 14
9. Quality of Service (QoS) Considerations . . . . . . . . . . . 15
10. Inter-domain Issues . . . . . . . . . . . . . . . . . . . . . 16
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
13. References. . . . . . . . . . . . . . . . . . . . . . . . . . 17
13.1. Normative References. . . . . . . . . . . . . . . . . . 17
13.2. Informative References. . . . . . . . . . . . . . . . . 17
14. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 18
15. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 19
Pseudo Wire Emulation Edge-to-Edge (PWE3) is a mechanism that emulates the essential attributes of a service such as ATM, Frame Relay or Ethernet over a Packet Switched Network (PSN). The required functions of PWs include encapsulating service-specific PDUs arriving at an ingress port, and carrying them across a path or tunnel, managing their timing and order, and any other operations required to emulate the behavior and characteristics of the service as faithfully as possible.
Pseudo Wire Emulation Edge-to-Edge（PWE3）は、Packet Switched Network（PSN）を介したATM、フレームリレー、イーサネットなどのサービスの本質的な属性をエミュレートするメカニズムです。PWSの必要な機能には、入り込みポートに到着するサービス固有のPDUのカプセル化、パスまたはトンネルを横切って運ぶこと、タイミングと順序の管理、およびサービスの行動と特性を可能な限り忠実にエミュレートするために必要なその他の操作が含まれます。。
From the customer perspective, the PW is perceived as an unshared link or circuit of the chosen service. However, there may be deficiencies that impede some applications from being carried on a PW. These limitations should be fully described in the appropriate service-specific documents and Applicability Statements.
顧客の観点から見ると、PWは選択されたサービスの非共有リンクまたは回路として認識されます。ただし、一部のアプリケーションがPWで運ばれないようにする不足がある場合があります。これらの制限は、適切なサービス固有のドキュメントと適用性ステートメントで完全に説明する必要があります。
The following sections give some background on where networks are today and why they are changing. It also talks about the motivation to provide converged networks while continuing to support existing services. Finally, it discusses how PWs can be a solution for this dilemma.
次のセクションでは、ネットワークが今日どこにあるのか、なぜそれらが変化しているのかについての背景を示しています。また、既存のサービスをサポートし続けながら、収束したネットワークを提供する動機についても語っています。最後に、PWSがこのジレンマの解決策になる方法について説明します。
For any given service provider delivering multiple services, the current infrastructure usually consists of parallel or "overlay" networks. Each of these networks implements a specific service, such as Frame Relay, Internet access, etc. This is expensive, both in terms of capital expense and operational costs. Furthermore, the presence of multiple networks complicates planning. Service providers wind up asking themselves these questions:
複数のサービスを提供する特定のサービスプロバイダーの場合、現在のインフラストラクチャは通常、並列または「オーバーレイ」ネットワークで構成されています。これらの各ネットワークは、フレームリレー、インターネットアクセスなどの特定のサービスを実装しています。これは、資本費用と運用コストの両方で高価です。さらに、複数のネットワークの存在は計画を複雑にします。サービスプロバイダーは、これらの質問を自問するようになりました。
- Which of my networks do I build out? - How many fibers do I need for each network? - How do I efficiently manage multiple networks?
- どのネットワークを構築していますか？ - 各ネットワークにはいくつの繊維が必要ですか？ - 複数のネットワークを効率的に管理するにはどうすればよいですか？
A converged network helps service providers answer these questions in a consistent and economical fashion.
収束したネットワークは、サービスプロバイダーが一貫した経済的な方法でこれらの質問に答えるのに役立ちます。
In order to maximize return on their assets and minimize their operating costs, service providers often look to consolidate the delivery of multiple service types onto a single networking technology.
資産の収益を最大化し、運用コストを最小限に抑えるために、サービスプロバイダーは、単一のネットワーキングテクノロジーに複数のサービスタイプの配信を統合することを目指しています。
As packet traffic takes up a larger and larger portion of the available network bandwidth, it becomes increasingly useful to optimize public networks for the Internet Protocol. However, many service providers are confronting several obstacles in engineering packet-optimized networks. Although Internet traffic is the fastest growing traffic segment, it does not generate the highest revenue per bit. For example, Frame Relay traffic currently generates higher revenue per bit than native IP services do. Private line TDM services still generate even more revenue per bit than does Frame Relay. In addition, there is a tremendous amount of legacy equipment deployed within public networks that does not communicate using the Internet Protocol. Service providers continue to utilize non-IP equipment to deploy a variety of services, and see a need to interconnect this legacy equipment over their IP-optimized core networks.
パケットトラフィックは、利用可能なネットワーク帯域幅の大部分と大部分を占めるため、インターネットプロトコルのパブリックネットワークを最適化することがますます便利になります。ただし、多くのサービスプロバイダーは、エンジニアリングパケットを最適化したネットワークのいくつかの障害に立ち向かいます。インターネットトラフィックは最も急速に成長しているトラフィックセグメントですが、1ビットあたり最高の収益を生み出しません。たとえば、フレームリレートラフィックは現在、ネイティブIPサービスよりもビットあたりの収益が増加しています。プライベートラインTDMサービスは、フレームリレーよりもビットあたりの収益をさらに多く生成します。さらに、インターネットプロトコルを使用して通信しないパブリックネットワーク内に展開されている膨大な量のレガシー機器があります。サービスプロバイダーは、非IP機器を利用してさまざまなサービスを展開し続け、IP最適化されたコアネットワークにこのレガシー機器を相互接続する必要があると考えています。
How do service providers realize the capital and operational benefits of a new packet-based infrastructure, while leveraging the existing equipment and also protecting the large revenue stream associated with this equipment? How do they move from mature Frame Relay or ATM networks, while still being able to provide these lucrative services?
サービスプロバイダーは、新しいパケットベースのインフラストラクチャの資本と運用上の利点をどのように実現し、既存の機器を活用し、この機器に関連する大規模な収益源を保護しますか？これらの収益性の高いサービスを提供することは、どのようにして成熟したフレームリレーまたはATMネットワークから移行しますか？
One possibility is the emulation of circuits or services via PWs. Circuit emulation over ATM and interworking of Frame Relay and ATM have already been standardized. Emulation allows existing services to be carried across the new infrastructure, and thus enables the interworking of disparate networks.
1つの可能性は、PWSを介した回路またはサービスのエミュレーションです。ATM上の回路エミュレーションとフレームリレーとATMのインターワーキングはすでに標準化されています。エミュレーションにより、既存のサービスを新しいインフラストラクチャ全体に携帯することができ、したがって、異なるネットワークの相互作用が可能になります。
Implemented correctly, PWE3 can provide a means for supporting today's services over a new network.
正しく実装されているPWE3は、新しいネットワークを介して今日のサービスをサポートする手段を提供できます。
What makes an application suitable (or not) for PWE3 emulation? When considering PWs as a means of providing an application, the following questions must be considered:
PWE3エミュレーションに適した（またはそうでない）アプリケーションが何を作るのですか？PWSをアプリケーションを提供する手段と見なす場合、次の質問を考慮する必要があります。
- Is the application sufficiently deployed to warrant emulation? - Is there interest on the part of service providers in providing an emulation for the given application? - Is there interest on the part of equipment manufacturers in providing products for the emulation of a given application? - Are the complexities and limitations of providing an emulation worth the savings in capital and operational expenses?
- アプリケーションはエミュレーションを保証するために十分に展開されていますか？ - 特定のアプリケーションのエミュレーションを提供することに、サービスプロバイダーの側に関心がありますか？ - 特定のアプリケーションのエミュレーションのために製品を提供することに、機器メーカーの側に関心がありますか？ - エミュレーションを提供することの複雑さと制限は、資本と運用費用の節約に値しますか？
If the answer to all four questions is "yes", then the application is likely to be a good candidate for PWE3. Otherwise, there may not be sufficient overlap between the customers, service providers, equipment manufacturers and technology to warrant providing such an emulation.
4つの質問すべてに対する答えが「はい」である場合、アプリケーションはPWE3の良い候補者になる可能性があります。それ以外の場合、顧客、サービスプロバイダー、機器メーカー、技術の間に十分な重複がない場合があります。
To maximize the return on their assets and minimize their operational costs, many service providers are looking to consolidate the delivery of multiple service offerings and traffic types onto a single IP-optimized network.
資産の収益を最大化し、運用コストを最小限に抑えるために、多くのサービスプロバイダーは、単一のIP最適化されたネットワークに複数のサービス提供とトラフィックタイプの配信を統合することを検討しています。
In order to create this next-generation converged network, standard methods must be developed to emulate existing telecommunications formats such as Ethernet, Frame Relay, and ATM over IP-optimized core networks. This document describes requirements for accomplishing this goal.
この次世代の収束ネットワークを作成するには、イーサネット、フレームリレー、ATMなどの既存の通信形式をIP最適化コアネットワークよりもエミュレートするために標準的な方法を開発する必要があります。このドキュメントでは、この目標を達成するための要件について説明しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
キーワード「必須」、「必要」、「必須」、「「shall」、「shallnot」、 "sulld"、 "low" obs "、" becommended "、" "、" optional "は、RFC 2119で説明されているように解釈されます。
Some terms used throughout this document are listed below.
このドキュメント全体で使用されるいくつかの用語を以下に示します。
Attachment Circuit (AC) The physical or virtual circuit attaching a CE to a PE. An AC can be a Frame Relay DLCI, an ATM VPI/VCI, an Ethernet port, a VLAN, a HDLC link, a PPP connection on a physical interface, a PPP session from an L2TP tunnel, an MPLS LSP, etc.
アタッチメント回路（AC）PEにCEを取り付ける物理または仮想回路。ACは、フレームリレーDLCI、ATM VPI/VCI、イーサネットポート、VLAN、HDLCリンク、物理インターフェイス上のPPP接続、L2TPトンネルからのPPPセッション、MPLS LSPなどです。
Customer Edge (CE) A device where one end of a service originates and/or terminates. The CE is not aware that it is using an emulated service rather than a native service.
カスタマーエッジ（CE）サービスの一端が発生および/または終了するデバイス。CEは、ネイティブサービスではなくエミュレートサービスを使用していることを認識していません。
Packet Switched Network (PSN) Within the context of PWE3, this is a network using IP or MPLS as the mechanism for packet forwarding.
PWE3のコンテキスト内で、パケットスイッチネットワーク（PSN）は、パケット転送のメカニズムとしてIPまたはMPLSを使用するネットワークです。
Provider Edge (PE) A device that provides PWE3 to a CE.
プロバイダーエッジ（PE）PWE3をCEに提供するデバイス。
Pseudo Wire (PW) A mechanism that carries the essential elements of an emulated circuit from one PE to another PE over a PSN.
擬似ワイヤ（PW）PSNを介して、あるPEから別のPEにエミュレートされた回路の重要な要素を運ぶメカニズム。
Pseudo Wire Emulation Edge to Edge (PWE3) A mechanism that emulates the essential attributes of a service (such as a T1 leased line or Frame Relay) over a PSN.
擬似ワイヤエミュレーションエッジからエッジ（PWE3）PSNを介してサービスの重要な属性（T1リースラインやフレームリレーなど）をエミュレートするメカニズム。
Pseudo Wire PDU A Protocol Data Unit (PDU) sent on the PW that contains all of the data and control information necessary to emulate the desired service.
Pseudo Wire PDU Aプロトコルデータユニット（PDU）は、目的のサービスをエミュレートするために必要なすべてのデータと制御情報を含むPWに送信されました。
PSN Tunnel A tunnel across a PSN inside which one or more PWs can be carried.
PSNトンネル1つ以上のPWを運ぶことができるPSNを横切るトンネル。
A pseudo-wire (PW) is a connection between two provider edge (PE) devices which connects two attachment circuits (ACs). An AC can be a Frame Relay DLCI, an ATM VPI/VCI, an Ethernet port, a VLAN, a HDLC link, a PPP connection on a physical interface, a PPP session from an L2TP tunnel, an MPLS LSP, etc.
擬似ワイヤー（PW）は、2つのアタッチメントサーキット（ACS）を接続する2つのプロバイダーエッジ（PE）デバイス間の接続です。ACは、フレームリレーDLCI、ATM VPI/VCI、イーサネットポート、VLAN、HDLCリンク、物理インターフェイス上のPPP接続、L2TPトンネルからのPPPセッション、MPLS LSPなどです。
|<------- Pseudo Wire ------>|
| |
| |<-- PSN Tunnel -->| |
V V V V
+----+ +----+
+-----+ | PE1|==================| PE2| +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | |==================| | +-----+
^ | +----+ +----+ ^
| | Provider Edge 1 Provider Edge 2 |
| | |
| Attachment Circuit |
| |
|<-------------- Emulated Service ---------------->|
Customer Customer
Edge 1 Edge 2
Figure 1: PWE3 Reference Model
図1：PWE3参照モデル
During the setup of a PW, the two PEs will be configured or will automatically exchange information about the service to be emulated so that later they know how to process packets coming from the other end. After a PW is set up between two PEs, frames received by one PE from an AC are encapsulated and sent over the PW to the remote PE, where native frames are re-constructed and forwarded to the other CE. For a detailed PWE3 architecture overview, readers should refer to the PWE3 architecture document [PWE3_ARCH].
PWのセットアップ中に、2つのPEが設定されるか、エミュレートするサービスに関する情報を自動的に交換して、後で反対側から来るパケットを処理する方法を知るようにします。2つのPESの間にPWが設定された後、ACから1つのPEで受信したフレームがカプセル化され、PWを介してリモートPEに送信され、ネイティブフレームが再構築され、他のCEに転送されます。詳細なPWE3アーキテクチャの概要については、読者はPWE3アーキテクチャドキュメント[PWE3_ARCH]を参照する必要があります。
This document does not assume that a particular type of PWs (e.g., [L2TPv3] sessions or [MPLS] LSPs) or PSNs (e.g., IP or MPLS) is used. Instead, it describes generic requirements that apply to all PWs and PSNs, for all services including Ethernet, ATM, and Frame Relay, etc.
このドキュメントでは、特定のタイプのPW（[L2TPV3]セッションまたは[MPLS] LSP）またはPSNS（IPまたはMPLSなど）が使用されているとは想定していません。代わりに、イーサネット、ATM、フレームリレーなどを含むすべてのサービスに、すべてのPWSおよびPSNSに適用される一般的な要件を説明します。
This section describes data plane requirements for PWE3.
このセクションでは、PWE3のデータプレーン要件について説明します。
Every PE MUST provide an encapsulation mechanism for PDUs from an AC. It should be noted that the PDUs to be encapsulated may or may not contain L2 header information. This is service specific. Every PWE3 service MUST specify what the PDU is.
すべてのPEは、ACからPDUのカプセル化メカニズムを提供する必要があります。カプセル化されるPDUには、L2ヘッダー情報が含まれている場合と含まれていない場合があることに注意する必要があります。これはサービス固有です。すべてのPWE3サービスは、PDUが何であるかを指定する必要があります。
A PW header consists of all the header fields in a PW PDU that are used by the PW egress to determine how to process the PDU. The PSN tunnel header is not considered as part of the PW header.
PWヘッダーは、PW EgressがPDUの処理方法を決定するために使用されるPW PDUのすべてのヘッダーフィールドで構成されています。PSNトンネルヘッダーは、PWヘッダーの一部とは見なされません。
Specific requirements on PDU encapsulation are listed below.
PDUカプセル化に関する特定の要件を以下に示します。
The egress of a PW needs some information, e.g., which native service the PW PDUs belong to, and possibly some L2 header information, in order to know how to process the PDUs received. A PWE3 encapsulation approach MUST provide some mechanism for conveying such information from the PW ingress to the egress. It should be noted that not all such information must be carried in the PW header of the PW PDUs. Some information (e.g., service type of a PW) can be stored as state information at the egress during PW setup.
PWの出口には、PDUが受信したPDUの処理方法を知るために、PW PDUがどのネイティブサービスに属しているか、場合によってはL2ヘッダー情報などの情報が必要です。PWE3カプセル化アプローチは、PWの侵入から出口にそのような情報を伝えるためのいくつかのメカニズムを提供する必要があります。そのようなすべての情報をPW PDUのPWヘッダーに携帯する必要はないことに注意する必要があります。一部の情報（PWのサービスタイプなど）は、PWセットアップ中に出口で状態情報として保存できます。
A PWE3 approach MUST accommodate variable length PDUs, if variable length PDUs are allowed by the native service. For example, a PWE3 approach for Frame Relay MUST accommodate variable length frames.
PDUSがネイティブサービスによって許可されている場合、PWE3アプローチは可変長PDUに対応する必要があります。たとえば、フレームリレーのPWE3アプローチは、可変長フレームに対応する必要があります。
If a service in its native form is capable of grouping multiple circuits into a "trunk", e.g., multiple ATM VCCs in a VPC or multiple Ethernet 802.1Q interfaces in a port, some mechanism SHOULD be provided so that a single PW can be used to connect two end-trunks. From encapsulation perspective, sufficient information MUST be carried so that the egress of the PW can demultiplex individual circuits from the PW.
ネイティブ形式のサービスが、複数の回路を「トランク」にグループ化できる場合、たとえば、VPCまたはポート内の複数のイーサネット802.1Qインターフェイスの複数のATM VCCをグループ化できる場合は、単一のPWを使用できるように、いくつかのメカニズムを提供する必要があります。2つのエンドトランクを接続します。カプセル化の観点からは、PWの出口がPWから個々の回路を非難することができるように、十分な情報を実施する必要があります。
Most L2 frames have a checksum field to assure frame integrity. Every PWE3 service MUST specify whether the frame's checksum should be preserved across the PW, or should be removed at the ingress PE and then be re-calculated and inserted at the egress PE. For protocols such as ATM and FR, the checksum covers link-local information such as the circuit identifiers (e.g., FR DLCI or ATM VPI/VCI). Therefore, such checksum MUST be removed at the ingress PE and recalculated at the egress PE.
ほとんどのL2フレームには、フレームの完全性を保証するチェックサムフィールドがあります。すべてのPWE3サービスは、フレームのチェックサムをPW全体に保存する必要があるか、侵入PEで削除してから、再計算して出口PEに挿入する必要があるかどうかを指定する必要があります。ATMやFRなどのプロトコルの場合、チェックサムは、回路識別子（FR DLCIまたはATM VPI/VCIなど）などのリンクローカル情報をカバーしています。したがって、そのようなチェックサムは、侵入PEで削除され、出口PEで再計算する必要があります。
Under some circumstances, it is desirable to be able to distinguish PW traffic from other types of traffic such as IPv4 or IPv6 or OAM. For example, if Equal Cost Multi-Path (ECMP) is employed in a PSN, this additional distinguishability can be used to reduce the chance that PW packets get misordered by the load balancing mechanism. Some mechanism SHOULD provide this distinguishability if needed. Such mechanism MAY be defined in the PWE3 WG or other WGs.
状況によっては、PWトラフィックをIPv4やIPv6やOAMなどの他のタイプのトラフィックと区別できることが望ましいです。たとえば、PSNで等しいコストマルチパス（ECMP）が採用されている場合、この追加の識別可能性を使用して、PWパケットが負荷分散メカニズムによって誤って順序付けられる可能性を減らすことができます。必要に応じて、いくつかのメカニズムがこの識別性を提供する必要があります。このようなメカニズムは、PWE3 WGまたは他のWGSで定義される場合があります。
When packets carrying the PW PDUs traverse a PW, they may arrive at the egress out of order. For some services, the frames (either control frames only or both control and data frames) must be delivered in order. For such services, some mechanism MUST be provided for ensuring in-order delivery. Providing a sequence number in the PW header for each packet is one possible approach to detect out-of-order frames. Mechanisms for re-ordering frames may be provided by Native Service Processing (NSP) [PWE3_ARCH] but are out of scope of PWE3.
PW PDUSを運ぶパケットがPWをトラバースすると、それらは故障して出口に到着する場合があります。一部のサービスでは、フレーム（制御フレームのみまたは両方のコントロールとデータフレーム）を順番に配信する必要があります。このようなサービスの場合、注文の配信を確保するために、いくつかのメカニズムを提供する必要があります。各パケットのPWヘッダーにシーケンス番号を提供することは、秩序外フレームを検出するための1つの可能なアプローチです。再注文フレームのメカニズムは、ネイティブサービス処理（NSP）[PWE3_ARCH]によって提供される場合がありますが、PWE3の範囲外です。
In rare cases, packets traversing a PW may be duplicated. For some services, frame duplication is not allowed. For such services some mechanism MUST be provided to ensure that duplicated frames will not be delivered. The mechanism may or may not be the same as the mechanism used to ensure in-order frame delivery.
まれに、PWを通過するパケットが複製される場合があります。一部のサービスでは、フレームの複製は許可されていません。このようなサービスの場合、複製されたフレームが提供されないようにするために、いくつかのメカニズムを提供する必要があります。メカニズムは、順序付けフレームの配信を確保するために使用されるメカニズムと同じである場合と同じである場合があります。
If the combined size of the L2 payload and its associated PWE3 and PSN headers exceeds the PSN path MTU, the L2 payload may need to be fragmented (Alternatively the L2 frame may be dropped). For certain native service, fragmentation may also be needed to maintain a control frame's relative position to the data frames (e.g., an ATM PM cell's relative position). In general, fragmentation has a performance impact. It is therefore desirable to avoid fragmentation if possible. However, for different services, the need for fragmentation can be different. When there is potential need for fragmentation, each service-specific PWE3 document MUST specify whether to fragment the frame in question or to drop it. If an emulated service chooses to drop the frame, the consequence MUST be specified in its applicability statement.
L2ペイロードの複合サイズと関連するPWE3およびPSNヘッダーがPSNパスMTUを超える場合、L2ペイロードを断片化する必要がある場合があります（あるいはL2フレームをドロップする場合があります）。特定のネイティブサービスの場合、データフレームに対する制御フレームの相対位置を維持するために断片化も必要になる場合があります（たとえば、ATM PMセルの相対位置）。一般に、断片化にはパフォーマンスの影響があります。したがって、可能であれば断片化を避けることが望ましいです。ただし、さまざまなサービスの場合、断片化の必要性は異なる場合があります。断片化の潜在的な必要性がある場合、各サービス固有のPWE3ドキュメントは、問題のフレームを断片化するか、ドロップするかを指定する必要があります。エミュレートされたサービスがフレームをドロップすることを選択した場合、その結果を適用可能性ステートメントで指定する必要があります。
When the L2 PDU size is small, in order to reduce PSN tunnel header overhead, multiple PDUs MAY be concatenated before a PSN tunnel header is added. Each encapsulated PDU still carries its own PW header so that the egress PE knows how to process it. However, the benefit of concatenating multiple PDUs for header efficiency should be weighed against the resulting increase in delay, jitter and the larger penalty incurred by packet loss.
L2 PDUサイズが小さい場合、PSNトンネルヘッダーのオーバーヘッドを減らすために、PSNトンネルヘッダーが追加される前に複数のPDUを連結することがあります。カプセル化された各PDUは、出力PEがそれを処理する方法を知っているように、まだ独自のPWヘッダーを搭載しています。ただし、ヘッダー効率のために複数のPDUを連結することの利点は、パケット損失によって生じる遅延、ジッター、およびより大きなペナルティの増加と比較検討する必要があります。
This section describes maintenance requirements for PWE3.
このセクションでは、PWE3のメンテナンス要件について説明します。
A PW must be set up before an emulated circuit can be established, and must be torn down when an emulated circuit is no longer needed. Setup and teardown of a PW can be triggered by a command from the management plane of a PE, or by Setup/Teardown of an AC (e.g., an ATM SVC), or by an auto-discovery mechanism.
エミュレートされた回路を確立する前にPWをセットアップする必要があり、エミュレートされた回路が不要になったときに取り壊す必要があります。PWのセットアップと分解は、PEの管理プレーンからのコマンド、またはACのセットアップ/分解（ATM SVCなど）、または自動配置メカニズムによってトリガーできます。
Every PWE3 approach MUST define some setup mechanism for establishing the PWs. During the setup process, the PEs need to exchange some information (e.g., to learn each other's capability). The setup mechanism MUST enable the PEs to exchange all necessary information. For example, both endpoints must agree on methods for encapsulating PDUs and handling frame ordering. Which signaling protocol to use and what information to exchange are service specific. Every PWE3 approach MUST specify them. Manual configuration of PWs can be considered as a special kind of signaling and is allowed.
すべてのPWE3アプローチは、PWSを確立するためのいくつかのセットアップメカニズムを定義する必要があります。セットアッププロセス中、PESはいくつかの情報を交換する必要があります（例：お互いの能力を学習するため）。セットアップメカニズムは、PESが必要なすべての情報を交換できるようにする必要があります。たとえば、両方のエンドポイントは、PDUをカプセル化してフレームの順序付けを処理する方法に同意する必要があります。どのシグナリングプロトコルを使用するか、どの情報を交換するかはサービス固有のものです。すべてのPWE3アプローチはそれらを指定する必要があります。PWの手動構成は、特別な種類のシグナル伝達と見なすことができ、許可されます。
If a native circuit is bi-directional, the corresponding emulated circuit can be signaled "Up" only when the associated PW and PSN tunnels in both directions are functional.
ネイティブ回路が双方向である場合、対応するエミュレートされた回路は、両方向の関連するPWとPSNトンネルが機能的である場合にのみ「上」に信号を送ることができます。
Some native services have mechanisms for maintenance purpose, e.g., ATM OAM and FR LMI. Such maintenance messages can be in-band (i.e., mixed with data messages in the same AC) or out-of-band (i.e., sent in a dedicated control circuit). For such services, all in-band maintenance messages related to a circuit SHOULD be transported in-band just like data messages through the corresponding PW to the remote CE. In other words, no translation is needed at the PEs for in-band maintenance messages. In addition, it MAY be desirable to provide higher reliability for maintenance messages. The mechanisms for providing high reliability do not have to be defined in the PWE3 WG.
一部のネイティブサービスには、ATM OAMやFR LMIなどのメンテナンス目的のメカニズムがあります。このようなメンテナンスメッセージは、帯域内（つまり、同じACのデータメッセージと混合）または帯域外（つまり、専用のコントロール回路で送信）にすることができます。このようなサービスの場合、回路に関連するすべての帯域内のメンテナンスメッセージは、対応するPWを介してリモートCEにデータメッセージと同様にバンド内で輸送する必要があります。言い換えれば、帯域内のメンテナンスメッセージのPESでは、翻訳は必要ありません。さらに、メンテナンスメッセージの信頼性を高めることが望ましい場合があります。高い信頼性を提供するためのメカニズムは、PWE3 WGで定義する必要はありません。
Out-of-band maintenance messages between a CE and a PE may relate to multiple ACs between the CE and the PE. They need to be processed at the local PE and possibly at the remote PE as well. If a native service has some out-of-band maintenance messages, the corresponding emulated service MUST specify how to process such messages at the PEs. In general, an out-of-band maintenance message is either translated into an in-band maintenance message of the native service or a PWE-specific maintenance message for every AC related to that out-of-band message. As an example, assume the ACs between a CE and a PE are some ATM VCCs inside a VPC. When a F4 AIS [UNI3.0] from the CE is received by the PE, the PE should translate that F4 AIS into a F5 AIS and send it to the remote CE for every VCC. Alternatively, the PE should generate a PWE-specific maintenance message (e.g., label withdrawal) to the remote PE for every VCC. When the remote PE receives such a PWE-specific maintenance message, it may need to generate a maintenance message of the native service and send it to the attached CE.
CEとPEの間のバンド外のメンテナンスメッセージは、CEとPEの間の複数のACSに関連する場合があります。それらは、ローカルPEで、場合によってはリモートPEでも処理する必要があります。ネイティブサービスに帯域外のメンテナンスメッセージがある場合、対応するエミュレートサービスは、PESでそのようなメッセージを処理する方法を指定する必要があります。一般に、バンド外のメンテナンスメッセージは、ネイティブサービスのバンド内メンテナンスメッセージまたはその帯域外のメッセージに関連するすべてのACのPWE固有のメンテナンスメッセージに翻訳されます。例として、CEとPEの間のACSがVPC内の一部のATM VCCであると仮定します。CEからF4 AIS [UNI3.0]がPEによって受信される場合、PEはそのF4 AIをF5 AISに変換し、すべてのVCCのリモートCEに送信する必要があります。あるいは、PEは、すべてのVCCのリモートPEにPWE固有のメンテナンスメッセージ（ラベルの撤退など）を生成する必要があります。リモートPEがこのようなPWE固有のメンテナンスメッセージを受信した場合、ネイティブサービスのメンテナンスメッセージを生成し、添付のCEに送信する必要がある場合があります。
A PE needs to initiate some maintenance messages under some circumstances without being triggered by any native maintenance messages from the CE. These circumstances are usually caused by fault, e.g., a PW failure in the PSN or a link failure between the CE and the PE.
PEは、CEからのネイティブメンテナンスメッセージによってトリガーされることなく、一部の状況下でいくつかのメンテナンスメッセージを開始する必要があります。これらの状況は通常、障害によって引き起こされます。たとえば、PSNのPW障害、またはCEとPEの間のリンク障害。
The reason the PEs need to initiate some maintenance messages under a fault condition is because the existence of a PW between two CEs would otherwise reduce the CEs' maintenance capability. This is illustrated in the following example. If two CEs are directly connected by a physical wire, a native service (e.g., ATM) can use notifications from the lower layer (e.g., the physical link layer) to assist its maintenance. For example, an ATM PVC can be signaled "Down" if the physical wire fails. However, consider the following scenario.
PESが障害状態でいくつかのメンテナンスメッセージを開始する必要がある理由は、2つのCEの間にPWの存在がCESのメンテナンス機能を低下させるためです。これを次の例に示します。2つのCEが物理ワイヤーで直接接続されている場合、ネイティブサービス（ATMなど）は、下層（たとえば、物理リンク層）からの通知を使用して、メンテナンスを支援できます。たとえば、物理ワイヤが故障した場合、ATM PVCは「下」に信号を送ることができます。ただし、次のシナリオを検討してください。
+-----+ Phy-link +----+ +----+ Phy-link +-----+
| CE1 |----------| PE1|......PW......|PE2 |----------| CE2 |
+-----+ +----+ +----+ +-----+
If the PW between PE1 and PE2 fails, CE1 and CE2 will not receive physical link failure notification. As a result, they cannot declare failure of the emulated circuit in a timely fashion, which will in turn affect higher layer applications. Therefore, when the PW fails, PE1 and PE2 need to initiate some maintenance messages to notify the client layer on CE1 and CE2 that use the PW as a server layer. (In this case, the client layer is the emulated service). Similarly, if the physical link between PE1-CE1 fails, PE1 needs to initiate some maintenance message(s) so that the client layer at CE2 will be notified. PE2 may need to be involved in this process.
PE1とPE2の間のPWが失敗した場合、CE1とCE2は物理的なリンク障害通知を受け取りません。その結果、エミュレートされた回路の故障をタイムリーに宣言することはできません。したがって、PWが失敗した場合、PE1とPE2は、PWをサーバーレイヤーとして使用するCE1とCE2のクライアントレイヤーに通知するために、いくつかのメンテナンスメッセージを開始する必要があります。（この場合、クライアントレイヤーはエミュレートサービスです）。同様に、PE1-CE1間の物理リンクが失敗した場合、PE1はCE2のクライアントレイヤーに通知されるように、いくつかのメンテナンスメッセージを開始する必要があります。PE2はこのプロセスに関与する必要があるかもしれません。
In the rare case when a physical wire between two CEs incurs many bit errors, the physical link can be declared "Down" and the client layer at the CEs be notified. Similarly, a PW can incur packet loss, corruption, and out-of-order delivery. These can be considered as "generalized bit error". Upon detection of excessive "generalized bit error", a PW can be declared "Down" and the detecting PE needs to initiate a maintenance message so that the client layer at the CE is notified.
まれに、2つのCES間の物理ワイヤが多くのビットエラーをもたらす場合、物理リンクを「ダウン」と宣言し、CESのクライアントレイヤーに通知することができます。同様に、PWはパケットの損失、腐敗、および秩序外の配達を発生させる可能性があります。これらは「一般化されたビットエラー」と見なすことができます。過剰な「一般化されたビットエラー」を検出すると、PWを「ダウン」と宣言し、検出PEはCEのクライアントレイヤーに通知されるようにメンテナンスメッセージを開始する必要があります。
In general, every emulated service MUST specify: * Under what circumstances PE-initiated maintenance messages are needed, * Format of the maintenance messages, and * How to process the maintenance messages at the remote PE.
一般に、すべてのエミュレートされたサービスは、次のように指定する必要があります。 *どのような状況では、PE開始メンテナンスメッセージが必要であるか、 *メンテナンスメッセージの形式、および *リモートPEでメンテナンスメッセージを処理する方法。
Some monitoring mechanisms are needed for detecting such circumstances, e.g., a PW failure. Such mechanisms can be defined in the PWE3 WG or elsewhere.
このような状況を検出するためには、PWの障害などを検出するためには、いくつかの監視メカニズムが必要です。このようなメカニズムは、PWE3 WGまたは他の場所で定義できます。
Status of a group of emulated circuits may be affected identically by a single network incidence. For example, when the physical link between a CE and a PE fails, all the emulated circuits that go through that link will fail. It is desirable that a single maintenance message be used to notify failure of the whole group of emulated circuits connected to the same remote PE. A PWE3 approach MAY provide some mechanism for notifying status changes of a group of emulated circuits. One possible approach is to associate each emulated circuit with a group ID while setting up the PW for that emulated circuit. In a maintenance message, that group ID can be used to refer to all the emulated circuits in that group.
エミュレートされた回路のグループのステータスは、単一のネットワークの発生率によって同じように影響を受ける可能性があります。たとえば、CEとPEの間の物理的なリンクが失敗すると、そのリンクを通過するすべてのエミュレートされた回路が失敗します。同じリモートPEに接続されたエミュレート回路のグループ全体の障害を通知するために、単一のメンテナンスメッセージを使用することが望ましいです。PWE3アプローチは、エミュレートされた回路のグループのステータス変更を通知するためのいくつかのメカニズムを提供する場合があります。考えられるアプローチの1つは、そのエミュレートされた回路のPWをセットアップしながら、各エミュレートされた回路をグループIDに関連付けることです。メンテナンスメッセージでは、そのグループIDを使用して、そのグループのすべてのエミュレートサーキットを参照できます。
If a PE needs to generate and send a maintenance message to a CE, the PE MUST use a maintenance message of the native service. This is essential in keeping the emulated service transparent to the CEs.
PEがCEにメンテナンスメッセージを生成して送信する必要がある場合、PEはネイティブサービスのメンテナンスメッセージを使用する必要があります。これは、エミュレートされたサービスをCESに透明に保つために不可欠です。
The requirements stated in this section are aligned with the ITU-T maintenance philosophy for telecommunications networks [G805] (i.e., client layer/server layer concept).
このセクションに記載されている要件は、電気通信ネットワークのITU-Tメンテナンス哲学[G805]（つまり、クライアントレイヤー/サーバーレイヤーの概念）と一致しています。
Each PWE3 approach SHOULD provide some mechanisms for network operators to manage the emulated service. These mechanisms can be in the forms described below.
各PWE3アプローチは、ネットワークオペレーターがエミュレートサービスを管理するためのいくつかのメカニズムを提供する必要があります。これらのメカニズムは、以下に説明する形式である可能性があります。
SNMP MIBs [SMIV2] MUST be provided for managing each emulated circuit as well as pseudo-wire in general. These MIBs SHOULD be created with the following requirements.
SNMP MIBS [SMIV2]は、一般的に擬似ワイヤだけでなく、各エミュレートされた回路と擬似ワイヤーを管理するために提供する必要があります。これらのMIBは、次の要件で作成する必要があります。
New MIBs MUST augment or extend where appropriate, existing tables as defined in other existing service-specific MIBs for existing services such as MPLS or L2TP. For example, the ifTable as defined in the Interface MIB [IFMIB] MUST be augmented to provide counts of out-of-order packets. A second example is the extension of the MPLS-TE-MIB [TEMIB] when emulating circuit services over MPLS. Rather than redefining the tunnelTable so that PWE can utilize MPLS tunnels, for example, entries in this table MUST instead be extended to add additional PWE-specific objects. A final example might be to extend the IP Tunnel MIB [IPTUNMIB] in such a way as to provide PWE3- specific semantics when tunnels other than MPLS are used as PSN transport. Doing so facilitates a natural extension of those objects defined in the existing MIBs in terms of management, as well as leveraging existing agent implementations.
新しいMIBは、MPLSやL2TPなどの既存のサービスの他の既存のサービス固有のMIBで定義されているように、必要に応じて既存のテーブルを拡張または拡張する必要があります。たとえば、インターフェイスMIB [IFMIB]で定義されているIFTableは、オーダーアウトパケットのカウントを提供するために拡張する必要があります。2番目の例は、MPLS上で回路サービスをエミュレートするときのMPLS-TE-MIB [TEMIB]の拡張です。たとえば、PWEがMPLSトンネルを使用できるようにトンネルテーブルを再定義するのではなく、このテーブルのエントリを拡張してPWE固有のオブジェクトを追加する必要があります。最後の例は、MPL以外のトンネルがPSN輸送として使用される場合にPWE3固有のセマンティクスを提供するような方法でIPトンネルMIB [Iptunmib]を拡張することです。そうすることで、既存のMIBSで定義されているオブジェクトの自然な拡張が管理の観点から定義され、既存のエージェントの実装を活用します。
An AC MUST appear as an interface in the ifTable.
ACは、IFTableのインターフェイスとして表示する必要があります。
MIB Tables MUST be designed to facilitate configuration and provisioning of the AC.
MIBテーブルは、ACの構成とプロビジョニングを容易にするように設計する必要があります。
The MIB(s) MUST facilitate intra-PSN configuration and monitoring of ACs.
MIB（S）は、ACSの内部構成と監視を促進する必要があります。
MIBs MUST collect statistics for performance and fault management.
MIBSは、パフォーマンスと障害管理のために統計を収集する必要があります。
MIBs MUST provide a description of how existing counters are used for PW emulation and SHOULD not replicate existing MIB counters.
MIBSは、既存のカウンターがPWエミュレーションにどのように使用されるかについての説明を提供する必要があり、既存のMIBカウンターを再現すべきではありません。
Notifications SHOULD be defined where appropriate to notify the network operators of any interesting situations, including faults detected in the AC.
必要に応じて、ACで検出された障害を含む興味深い状況をネットワークオペレーターに通知するために、必要に応じて定義する必要があります。
Objects defined to augment existing protocol-specific notifications in order to add PWE functionality MUST explain how these notifications are to be emitted.
PWE機能を追加するために既存のプロトコル固有の通知を強化するために定義されたオブジェクトは、これらの通知をどのように放出するかを説明する必要があります。
For network management purpose, a connection verification mechanism SHOULD be supported by PWs. Connection verification as well as other alarming mechanisms can alert network operators that a PW has lost its remote connection. It is sometimes desirable to know the exact functional path of a PW for troubleshooting purpose, thus a traceroute function capable of reporting the path taken by data packets over the PW SHOULD be provided.
ネットワーク管理の目的では、接続検証メカニズムをPWSによってサポートする必要があります。接続の検証と他の驚くべきメカニズムは、PWがリモート接続を失ったことをネットワーク演算子に警告することができます。トラブルシューティングの目的のためのPWの正確な機能パスを知ることが望ましい場合があります。したがって、PWを介したデータパケットによって取られたパスを報告できるトレーサー機能を提供する必要があります。
An emulated service SHOULD be as similar to the native service as possible, but NOT REQUIRED to be identical. The applicability statement of a PWE3 service MUST report limitations of the emulated service.
エミュレートされたサービスは、可能な限りネイティブサービスに似ている必要がありますが、同一である必要はありません。PWE3サービスの適用声明は、エミュレートサービスの制限を報告する必要があります。
Some basic requirements on faithfulness of an emulated service are described below.
エミュレートされたサービスの忠実さに関するいくつかの基本的な要件を以下に説明します。
From the perspective of a CE, an emulated circuit is characterized as an unshared link or circuit of the chosen service, although service quality of the emulated service may be different from that of a native one. Specifically, the following requirements MUST be met:
CEの観点から見ると、エミュレートされた回路は選択されたサービスの非共有リンクまたは回路として特徴付けられますが、エミュレートサービスのサービス品質はネイティブのサービスとは異なる場合があります。具体的には、次の要件を満たす必要があります。
1) It MUST be possible to define type (e.g., Ethernet, which is inherited from the native service), speed (e.g., 100Mbps), and MTU size for an emulated circuit, if it is possible to do so for a native circuit.
1) ネイティブ回路の場合は、エミュレート回路の場合、タイプ（ネイティブサービスから継承されるイーサネット）、速度（例：100Mbps）、およびMTUサイズを定義することができなければなりません。
2) If the two endpoints CE1 and CE2 of emulated circuit #1 are connected to PE1 and PE2, respectively, and CE3 and CE4 of emulated circuit #2 are also connected to PE1 and PE2, then the PWs of these two emulated circuits may share the same physical paths between PE1 and PE2. But from each CE's perspective, its emulated circuit MUST appear as unshared. For example, CE1/CE2 MUST NOT be aware of existence of emulated circuit #2 or CE3/CE4.
2) エミュレート回路＃1の2つのエンドポイントCE1とCE2がそれぞれPE1とPE2に接続されており、エミュレートされた回路＃2のCE3とCE4もPE1とPE2に接続されている場合、これら2つのエミュレート回路のPWSは同じを共有する場合があります。PE1とPE2の間の物理的パス。しかし、各CEの観点からは、そのエミュレートされた回路は非共有のように見える必要があります。たとえば、CE1/CE2は、エミュレートされた回路＃2またはCE3/CE4の存在を認識してはなりません。
3) If an emulated circuit fails (either at one of the ACs or in the middle of the PW), both CEs MUST be notified in a timely manner, if they will be notified in the native service (see Section 5.3 for more information). The definition of "timeliness" is service-dependent.
3) エミュレートされた回路が失敗した場合（ACSの1つまたはPWの中央で）、ネイティブサービスで通知される場合、両方のCESにタイムリーに通知する必要があります（詳細についてはセクション5.3を参照）。「適時性」の定義はサービス依存です。
4) If a routing protocol (e.g., IGP) adjacency can be established over a native circuit, it MUST be possible to be established over an emulated circuit as well.
4) ルーティングプロトコル（IGPなど）をネイティブ回路で確立できる場合、エミュレートされた回路でも確立できる必要があります。
It is NOT REQUIRED that an emulated service provide the same service quality as the native service. The PWE3 WG only defines mechanisms for providing PW emulation, not the services themselves. What quality to provide for a specific emulated service is a matter between a service provider (SP) and its customers, and is outside scope of the PWE3 WG.
エミュレートサービスがネイティブサービスと同じサービス品質を提供することは必須ではありません。PWE3 WGは、サービス自体ではなく、PWエミュレーションを提供するためのメカニズムのみを定義します。特定のエミュレートサービスに提供する品質は、サービスプロバイダー（SP）とその顧客の間の問題であり、PWE3 WGの外部範囲です。
Some non-requirements are mentioned in various sections of this document. Those work items are outside scope of the PWE3 WG. They are summarized below:
このドキュメントのさまざまなセクションでは、一部の非追跡が言及されています。これらの作業項目は、PWE3 WGの範囲外です。それらは以下に要約されています：
- Service interworking;
- サービスインターワーキング;
In Service Interworking, the IWF (Interworking Function) between two dissimilar protocols (e.g., ATM & MPLS, Frame Relay & ATM, ATM & IP, ATM & L2TP, etc.) terminates the protocol used in one network and translates (i.e., maps) its Protocol Control Information (PCI) to the PCI of the protocol used in other network for User, Control and Management Plane functions to the extent possible.
サービスインターワーキングでは、2つの異なるプロトコル（ATM＆MPLS、Frame Relay＆ATM、ATM＆IP、ATM＆L2TPなど）のIWF（インターワーキング関数）は、1つのネットワークで使用されるプロトコルを終了し、翻訳します（つまり、マップを翻訳します（つまり、マップ））可能な限り、ユーザー、制御プレーン、および管理プレーンの機能のために他のネットワークで使用されるプロトコルのPCIに対するプロトコル制御情報（PCI）。
- Selection of a particular type of PWs;
- 特定のタイプのPWSの選択。
- To make the emulated services perfectly match their native services;
- エミュレートサービスをネイティブサービスに完全に一致させるため。
- Defining mechanisms for signaling the PSN tunnels;
- PSNトンネルを通知するためのメカニズムの定義。
- Defining how to perform traffic management on packets that carry PW PDUs;
- PW PDUを運ぶパケットでトラフィック管理を実行する方法を定義します。
- Providing any multicast service that is not native to the emulated medium.
- エミュレートされた媒体にないマルチキャストサービスを提供します。
To illustrate this point, Ethernet transmission to a multicast IEEE-48 address is considered in scope, while multicast services like [MARS] that are implemented on top of the medium are out of scope;
この点を説明するために、マルチキャストIEEE-48アドレスへのイーサネット伝送は範囲内で考慮されますが、メディアの上に実装されている[MARS]のようなマルチキャストサービスは範囲外です。
Some native services such as ATM can offer higher service quality than best effort Internet service. QoS is therefore essential for ensuring that emulated services are compatible (but not necessarily identical) to their native forms. It is up to network operators to decide how to provide QoS - They can choose to rely on over-provisioning and/or deploy some QoS mechanisms.
ATMなどの一部のネイティブサービスは、Best Effepect Internet Serviceよりも高いサービス品質を提供できます。したがって、QoSは、エミュレートサービスがネイティブフォームと互換性がある（必ずしも同一ではない）ことを保証するために不可欠です。QoSの提供方法を決定するのはネットワークオペレーター次第です。彼らは、過剰な視力に依存したり、いくつかのQoSメカニズムを展開することを選択できます。
In order to take advantage of QoS mechanisms defined in other working groups, e.g., the traffic management schemes defined in DiffServ WG, it is desirable that some mechanisms exists for differentiating the packets resulted from PDU encapsulation. These mechanisms do not have to be defined in the PWE3 approaches themselves. For example, if the resulted packets are MPLS or IP packets, their EXP or DSCP field can be used for marking and differentiating. A PWE3 approach MAY provide guidelines for marking and differentiating.
他のワーキンググループで定義されているQoSメカニズム、たとえばDiffserv WGで定義されたトラフィック管理スキームを活用するために、PDUカプセル化に起因するパケットを区別するためのメカニズムが存在することが望ましい。これらのメカニズムは、PWE3アプローチで定義する必要はありません。たとえば、結果のパケットがMPLSまたはIPパケットである場合、EXPまたはDSCPフィールドを使用してマークと差別化に使用できます。PWE3アプローチは、マークと差別化のためのガイドラインを提供する場合があります。
The applicability of PWE3 to a particular service depends on the sensitivity of that service (or the CE implementation) to delay/jitter etc and the ability of the application layer to mask them. PWE3 may not be applicable to services that have severe constraints in this respect.
特定のサービスへのPWE3の適用性は、そのサービス（またはCE実装）の遅延/ジッターなどの感度と、それらをマスクするアプリケーション層の能力に依存します。PWE3は、この点で深刻な制約を持つサービスに適用できない場合があります。
PWE is a matter between the PW end-points and is transparent to the network devices between the PW end-points. Therefore, inter-domain PWE is fundamentally similar to intra-domain PWE. As long as PW end-points use the same PWE approach, they can communicate effectively, regardless of whether they are in the same domain. Security may become more important in the inter-domain case and some security measure such as end-point authentication MAY be applied. QoS may become more difficult to deliver too, as one service provider has no control over another service provider's provisioning and traffic management policy. To solve the inter-domain QoS problem, service providers have to cooperate. Once they agree at a contractual level to provider high quality of service to certain traffic (e.g., PWE traffic), the mechanisms defined in other working groups, e.g., Diffserv WG, can be used.
PWEはPWエンドポイント間の問題であり、PWエンドポイント間のネットワークデバイスに対して透明です。したがって、ドメイン間PWEは根本的にドメイン内PWEに似ています。PWエンドポイントが同じPWEアプローチを使用している限り、同じドメインにあるかどうかに関係なく、効果的に通信できます。ドメイン間のケースではセキュリティがより重要になる場合があり、エンドポイント認証などのセキュリティ測定が適用される場合があります。あるサービスプロバイダーは、別のサービスプロバイダーのプロビジョニングおよびトラフィック管理ポリシーを制御できないため、QoSも提供がより困難になる可能性があります。ドメイン間のQoS問題を解決するには、サービスプロバイダーが協力する必要があります。特定のトラフィック（PWEトラフィックなど）に対する高品質のサービスを提供するために契約レベルで契約レベルで同意すると、他のワーキンググループで定義されているメカニズム、例えばDiffserv WGを使用できます。
Inter-domain PSN tunnels are generally more difficult to set up, tear down and maintain than intra-domain ones. But that is an issue for PSN tunneling protocols such as MPLS and L2TPv3 and is outside the scope of PWE3.
ドメイン間のPSNトンネルは、一般に、ドメイン内のトンネルよりもセットアップ、取り壊し、維持がより困難です。しかし、それはMPLSやL2TPV3などのPSNトンネルプロトコルの問題であり、PWE3の範囲外です。
The PW end-point, PW demultiplexing mechanism, and the payloads of the native service can all be vulnerable to attack. PWE3 should leverage security mechanisms provided by the PW Demultiplexer or PSN Layers. Such mechanisms SHOULD protect PW end-point and PW Demultiplexer mechanism from denial-of-service (DoS) attacks and spoofing of the native data units. Preventing unauthorized access to PW end-points and other network devices is generally effective against DoS attacks and spoofing, and can be part of protection mechanism. Protection mechanisms SHOULD also address the spoofing of tunneled PW data. The validation of traffic addressed to the PW Demultiplexer end-point is paramount in ensuring integrity of PW encapsulation. Security protocols such as IPsec [RFC2401] can be used.
PWのエンドポイント、PWの非変化メカニズム、およびネイティブサービスのペイロードはすべて攻撃に対して脆弱です。PWE3は、PW DemultiplexerまたはPSN層によって提供されるセキュリティメカニズムを活用する必要があります。このようなメカニズムは、ネイティブデータユニットのサービス拒否（DOS）攻撃とスプーフィングからPWエンドポイントおよびPW Demultiplexerメカニズムを保護する必要があります。PWエンドポイントやその他のネットワークデバイスへの不正アクセスを防ぐことは、一般にDOS攻撃やスプーフィングに対して効果的であり、保護メカニズムの一部となる可能性があります。保護メカニズムは、トンネルされたPWデータのスプーフィングにも対処する必要があります。PW Demultiplexerのエンドポイントに宛てられたトラフィックの検証は、PWカプセル化の完全性を確保する上で最も重要です。IPSEC [RFC2401]などのセキュリティプロトコルを使用できます。
The authors would like to acknowledge input from M. Aissaoui, M. Bocci, S. Bryant, R. Cohen, N. Harrison, G. Heron, T. Johnson, A. Malis, L. Martini, E. Rosen, J. Rutemiller, T. So, Y. Stein, and S. Vainshtein.
著者は、M。aissaoui、M。Bocci、S。Bryant、R。Cohen、N。Harrison、G。Heron、T。Johnson、A。Malis、L。Martini、E。Rosen、J。Rutemiller、T。So、Y。Stein、およびS. Vainshtein。
[IFMIB] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[Ifmib] McCloghrie、K。およびF. Kastenholz、「The Interfaces Group MIB」、RFC 2863、2000年6月。
[SMIV2] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[SMIV2] McCloghrie、K.、Perkins、D。、およびJ. Schoenwaelder、「管理情報の構造バージョン2（SMIV2）」、STD 58、RFC 2578、1999年4月。
[G805] "Generic Functional Architecture of Transport Networks", ITU-T Recommendation G.805, 2000.
[G805]「輸送ネットワークの一般的な機能アーキテクチャ」、ITU-T推奨G.805、2000。
[IPTUNMIB] Thaler, D., "IP Tunnel MIB", RFC 2667, August 1999.
[Iptunmib] Thaler、D。、「IP Tunnel MIB」、RFC 2667、1999年8月。
[L2TPv3] Lau, J., Townsley, M., and I. Goyret, et al., "Layer Two Tunneling Protocol (Version 3)", Work in Progress, June 2004.
[L2TPV3] Lau、J.、Townsley、M。、およびI. Goyret、et al。、「レイヤー2トンネリングプロトコル（バージョン3）」、2004年6月、進行中の作業。
[MARS] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, November 1996.
[MARS] Armitage、G。、「UNI 3.0/3.1ベースのATMネットワークに対するマルチキャストのサポート」、RFC 2022、1996年11月。
[MPLS] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[MPLS] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocol Label Switching Architecture」、RFC 3031、2001年1月。
[PWE3_ARCH] S. Bryant and P. Pate, et. al., "PWE3 Architecture", Work in Progress, March 2004.
[PWE3_ARCH] S. Bryant and P. Pate、et。al。、「PWE3 Architecture」、2004年3月、進行中の作業。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[TEMIB] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
[Temib] Srinivasan、C.、Viswanathan、A。、およびT. Nadeau、「マルチプロトコルラベルスイッチング（MPLS）トラフィックエンジニアリング（TE）管理情報ベース（MIB）」、2004年6月、RFC 3812。
[UNI3.0] ATM Forum, "ATM User-Network Interface Specification Version 3.0", Sept. 1993.
[UNI3.0] ATMフォーラム、「ATMユーザーネットワークインターフェイス仕様バージョン3.0」、1993年9月。
XiPeng Xiao (Editor) Riverstone Networks 5200 Great America Parkway Santa Clara, CA 95054
Xipeng Xiao（編集者）Riverstone Networks 5200 Great America Parkway Santa Clara、CA 95054
EMail: xxiao@riverstonenet.com
Danny McPherson (Editor) Arbor Networks
Danny McPherson（編集者）アーバーネットワーク
EMail: danny@arbor.net
Prayson Pate (Editor) Overture Networks 507 Airport Boulevard, Suite 111 Morrisville, NC, USA 27560
Prayson Pate（編集者）序曲ネットワーク507 Airport Boulevard、Suite 111 Morrisville、NC、USA 27560
EMail: prayson.pate@overturenetworks.com
Vijay Gill AOL Time Warner
Vijay Gill Aol Time Warner
EMail: vijaygill9@aol.com
Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089
Kireeti Kompella Juniper Networks、Inc。1194 N. Mathilda Ave. Sunnyvale、CA 94089
EMail: kireeti@juniper.net
Thomas D. Nadeau Cisco Systems, Inc. 300 Beaver Brook Drive Boxborough, MA 01719 EMail: tnadeau@cisco.com
Thomas D. Nadeau Cisco Systems、Inc。300 Beaver Brook Drive Boxborough、MA 01719メール：tnadeau@cisco.com
Craig White Level 3 Communications, LLC. 1025 Eldorado Blvd. Broomfield, CO, 80021
Craig White Level 3 Communications、LLC。1025 Eldorado Blvd.コロラド州ブルームフィールド、80021
EMail: Craig.White@Level3.com
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」と貢献者、彼が代表する組織（もしあれば）が後援する組織、インターネット社会、インターネットエンジニアリングタスクフォースがすべての保証を拒否し、表明または、ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。IETFドキュメントの権利に関するIETFの手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。