Network Working Group S. Bryant, Ed.
Request for Comments: 3985 Cisco Systems
Category: Informational P. Pate, Ed.
Overture Networks, Inc.
March 2005
Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture
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 (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document describes an architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It discusses the emulation of services such as Frame Relay, ATM, Ethernet, TDM, and SONET/SDH over packet switched networks (PSNs) using IP or MPLS. It presents the architectural framework for pseudo wires (PWs), defines terminology, and specifies the various protocol elements and their functions.
この文書は、擬似ワイヤエミュレーションエッジ・ツー・エッジ（PWE3）のためのアーキテクチャを説明しています。これは、IPまたはMPLSを使用してパケット交換ネットワーク上に、フレームリレー、ATM、イーサネット、TDM、およびSONET / SDHのようなサービス（のPSN）のエミュレーションを論じています。これは、疑似ワイヤ（PWの）のためのアーキテクチャフレームワークを提示する用語を定義し、様々なプロトコル要素及びその機能を指定します。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Pseudo Wire Definition. . . . . . . . . . . . . . . . . 2
1.2. PW Service Functionality. . . . . . . . . . . . . . . . 3
1.3. Non-Goals of This Document. . . . . . . . . . . . . . . 4
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . 4
2. PWE3 Applicability. . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Layering Model . . . . . . . . . . . . . . . . . . . 6
3.1. Protocol Layers . . . . . . . . . . . . . . . . . . . . 7
3.2. Domain of PWE3. . . . . . . . . . . . . . . . . . . . . 8
3.3. Payload Types . . . . . . . . . . . . . . . . . . . . . 8
4. Architecture of Pseudo Wires. . . . . . . . . . . . . . . . . 11
4.1. Network Reference Model . . . . . . . . . . . . . . . . 12
4.2. PWE3 Pre-processing . . . . . . . . . . . . . . . . . . 12
4.3. Maintenance Reference Model . . . . . . . . . . . . . . 16
4.4. Protocol Stack Reference Model. . . . . . . . . . . . . 17
4.5. Pre-processing Extension to Protocol Stack Reference
Model . . . . . . . . . . . . . . . . . . . . . . . . . 17
5. PW Encapsulation. . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Payload Convergence Layer . . . . . . . . . . . . . . . 19
5.2. Payload-independent PW Encapsulation Layers . . . . . . 21
5.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . 24
5.4. Instantiation of the Protocol Layers. . . . . . . . . . 24
6. PW Demultiplexer Layer and PSN Requirements . . . . . . . . . 27
6.1. Multiplexing. . . . . . . . . . . . . . . . . . . . . . 27
6.2. Fragmentation . . . . . . . . . . . . . . . . . . . . . 28
6.3. Length and Delivery . . . . . . . . . . . . . . . . . . 28
6.4. PW-PDU Validation . . . . . . . . . . . . . . . . . . . 28
6.5. Congestion Considerations . . . . . . . . . . . . . . . 28
7. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1. Set-up or Teardown of Pseudo Wires. . . . . . . . . . . 29
7.2. Status Monitoring . . . . . . . . . . . . . . . . . . . 30
7.3. Notification of Pseudo Wire Status Changes. . . . . . . 30
7.4. Keep-alive. . . . . . . . . . . . . . . . . . . . . . . 31
7.5. Handling Control Messages of the Native Services. . . . 32
8. Management and Monitoring . . . . . . . . . . . . . . . . . . 32
8.1. Status and Statistics . . . . . . . . . . . . . . . . . 32
8.2. PW SNMP MIB Architecture. . . . . . . . . . . . . . . . 33
8.3. Connection Verification and Traceroute. . . . . . . . . 36
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
10. Security Considerations . . . . . . . . . . . . . . . . . . . 37
11. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 38
12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 38
12.1. Normative References . . . . . . . . . . . . . . . . . 38
12.2. Informative References . . . . . . . . . . . . . . . . 39
13. Co-Authors. . . . . . . . . . . . . . . . . . . . . . . . . . 40
14. Editors' Addresses. . . . . . . . . . . . . . . . . . . . . . 41
Full Copyright Statement. . . . . . . . . . . . . . . . . . . 42
This document describes an architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3) in support of [RFC3916]. It discusses the emulation of services such as Frame Relay, ATM, Ethernet, TDM, and SONET/SDH over packet switched networks (PSNs) using IP or MPLS. It presents the architectural framework for pseudo wires (PWs), defines terminology, and specifies the various protocol elements and their functions.
この文書は、擬似ワイヤエミュレーションエッジ・ツー・エッジ（PWE3）[RFC3916]をサポートするためのアーキテクチャが記載されています。これは、IPまたはMPLSを使用してパケット交換ネットワーク上に、フレームリレー、ATM、イーサネット、TDM、およびSONET / SDHのようなサービス（のPSN）のエミュレーションを論じています。これは、疑似ワイヤ（PWの）のためのアーキテクチャフレームワークを提示する用語を定義し、様々なプロトコル要素及びその機能を指定します。
PWE3 is a mechanism that emulates the essential attributes of a telecommunications service (such as a T1 leased line or Frame Relay) over a PSN. PWE3 is intended to provide only the minimum necessary functionality to emulate the wire with the required degree of faithfulness for the given service definition. Any required switching functionality is the responsibility of a forwarder function (FWRD). Any translation or other operation needing knowledge of the payload semantics is carried out by native service processing (NSP) elements. The functional definition of any FWRD or NSP elements is outside the scope of PWE3.
PWE3は、PSN上（例えばT1専用回線やフレームリレーのような）通信サービスの本質的な特性をエミュレートする機構です。 PWE3は、所定のサービス定義の忠実の必要な程度を有するワイヤをエミュレートするために最低限必要な機能を提供することを目的とします。任意の必要なスイッチング機能は、フォワーダ機能（FWRD）の責任です。ペイロードセマンティクスの任意の翻訳または他の操作が必要な知識は、ネイティブサービス処理（NSP）の要素によって行われます。任意FWRDまたはNSP要素の機能的な定義は、PWE3の範囲外です。
The required functions of PWs include encapsulating service-specific bit streams, cells, or PDUs arriving at an ingress port and carrying them across an IP path or MPLS tunnel. In some cases it is necessary to perform other operations such as managing their timing and order, to emulate the behavior and characteristics of the service to the required degree of faithfulness.
PWの必要な機能は、サービス固有のビットストリーム、細胞、またはPDUの入力ポートに到着すると、IPパスまたはMPLSトンネルを横切ってそれらを運ぶをカプセル化が挙げられます。場合によっては、忠実の必要な程度に、サービスの挙動および特性をエミュレートするために、それらのタイミングおよび順序を管理などの他の操作を行う必要があります。
From the perspective of Customer Edge Equipment (CE), the PW is characterized as an unshared link or circuit of the chosen service. In some cases, there may be deficiencies in the PW emulation that impact the traffic carried over a PW and therefore limit the applicability of this technology. These limitations must be fully described in the appropriate service-specific documentation.
カスタマエッジ機器（CE）の観点から、PWは、選択されたサービスの非共有リンク又は回路として特徴付けられます。いくつかのケースでは、PWの上に運ばトラフィックに影響を与え、したがって、この技術の適用可能性を制限PWエミュレーションで不備があるかもしれません。これらの制限は、完全に適切なサービス固有のマニュアルに記載されている必要があります。
For each service type, there will be one default mode of operation that all PEs offering that service type must support. However, optional modes may be defined to improve the faithfulness of the emulated service, if it can be clearly demonstrated that the additional complexity associated with the optional mode is offset by the value it offers to PW users.
各サービスタイプの場合、そのサービスの種類を提供するすべてのPEがサポートしなければならない操作の1つのデフォルトモードが存在します。明らかに、オプションモードに関連する追加の複雑さは、それがPWユーザに提供する値だけオフセットされていることを証明できる場合は、任意のモードは、エミュレートされたサービスの忠実性を改善するために定義されてもよいです。
PWs provide the following functions in order to emulate the behavior and characteristics of the native service.
PWSがネイティブサービスの動作や特性をエミュレートするために、以下の機能を提供します。
o Encapsulation of service-specific PDUs or circuit data arriving
at the PE-bound port (logical or physical).
o Carriage of the encapsulated data across a PSN tunnel.
o Establishment of the PW, including the exchange and/or
distribution of the PW identifiers used by the PSN tunnel
endpoints.
o Managing the signaling, timing, order, or other aspects of the
service at the boundaries of the PW.
o Service-specific status and alarm management.
The following are non-goals for this document:
この文書の非目標は以下のとおりです。
o The on-the-wire specification of PW encapsulations. o The detailed definition of the protocols involved in PW setup and maintenance.
PWカプセル化のオン・ワイヤー仕様O。 PWのセットアップやメンテナンスに関わるプロトコルの詳細な定義O。
The following are outside the scope of PWE3:
以下は、PWE3の範囲外です。
o Any multicast service not native to the emulated medium. Thus, Ethernet transmission to a "multicast" IEEE-48 address is in scope, but multicast services such as MARS [RFC2022] that are implemented on top of the medium are not. o Methods to signal or control the underlying PSN.
O任意のマルチキャストサービスエミュレート培地にネイティブではありません。したがって、「マルチキャスト」IEEE-48アドレスへのイーサネット伝送がスコープ内にあるが、媒体上に実装されているようなMARS [RFC2022]などのマルチキャストサービスではありません。 O方法は、信号や基本的なPSNを制御します。
This document uses the following definitions of terms. These terms are illustrated in context in Figure 2.
このドキュメントは、以下の用語の定義を使用しています。これらの用語は、図2に文脈に示されています。
Attachment Circuit The physical or virtual circuit attaching (AC) a CE to a PE. An attachment Circuit may be, for example, a Frame Relay DLCI, an ATM VPI/VCI, an Ethernet port, a VLAN, a PPP connection on a physical interface, a PPP session from an L2TP tunnel, or an MPLS LSP. If both physical and virtual ACs are of the same technology (e.g., both ATM, both Ethernet, both Frame Relay), the PW is said to provide "homogeneous transport"; otherwise, it is said to provide "heterogeneous transport".
アタッチメント回路の物理的または仮想回線に取り付ける（AC）PEとCE。アタッチメント回路は、フレームリレーDLCI、ATM VPI / VCI、イーサネットポート、VLAN、物理インタフェース、L2TPトンネルからのPPPセッション、またはMPLS LSP上のPPP接続、例えば、であってもよいです。両方の物理および仮想ACSが同一の技術（例えば、両方のATM、イーサネット（登録商標）の両方、両方のフレーム・リレー）である場合、PWは「均質輸送」を提供すると言われています。それ以外の場合は、「異種の輸送」を提供すると言われています。
CE-bound The traffic direction in which PW-PDUs are received on a PW via the PSN, processed, and then sent to the destination CE.
CE-結合PW-PDUは、PSNを介してPW上で受信処理され、次いで、宛先CEに送信されたトラフィックの方向。
CE Signaling Messages sent and received by the CE's control plane. It may be desirable or even necessary for the PE to participate in or to monitor this signaling in order to emulate the service effectively.
CEのコントロールプレーンによって送受信されるシグナリングメッセージをCE。 PEが参加したり、効果的サービスをエミュレートするためにこのシグナリングを監視することが望ましいあるいは必要であるかもしれません。
Control Word (CW) A four-octet header used in some encapsulations to carry per-packet information when the PSN is MPLS.
制御ワード（CW）PSNがMPLSである場合、パケット単位の情報を運ぶために、いくつかのカプセル化に使用される4オクテットのヘッダ。
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は、それがエミュレートされたサービスではなく、ネイティブのサービスを使用していることを認識していません。
Forwarder (FWRD) A PE subsystem that selects the PW to use in order to transmit a payload received on an AC.
フォワーダ（FWRD）AC上で受信されたペイロードを送信するために使用するPWを選択PEサブシステム。
Fragmentation The action of dividing a single PDU into multiple PDUs before transmission with the intent of the original PDU being reassembled elsewhere in the network. Packets may undergo fragmentation if they are larger than the MTU of the network they will traverse.
フラグメンテーションの他の場所ネットワークで再構築され、元のPDUの目的で送信する前に、複数のPDUに単一のPDUを分割するアクション。彼らが横断するネットワークのMTUよりも大きい場合にパケットが断片化を受けることができます。
Maximum Transmission The packet size (excluding data link header) unit (MTU) that an interface can transmit without needing to fragment.
インタフェースは、断片することなく送信できる最大送信パケットサイズ（データ・リンク・ヘッダを除く）単位（MTU）。
Native Service Processing of the data received by the PE Processing (NSP) from the CE before presentation to the PW for transmission across the core, or processing of the data received from a PW by a PE before it is output on the AC. NSP functionality is defined by standards bodies other than the IETF, such as ITU-T,ANSI, or ATMF.)
それはACに出力される前にコアを横切って伝送するためのPWへの提示、またはPEがPWから受信したデータの処理の前にCEからPE処理（NSP）によって受信されたデータのネイティブサービス処理。 NSP機能は、ITU-T、ANSI、またはATMFとしてIETF以外の標準化団体によって定義されます。）
Packet Switched Within the context of PWE3, this is a Network (PSN) network using IP or MPLS as the mechanism for packet forwarding.
PWE3の文脈においてパケット交換は、これはパケット転送のためのメカニズムとして、IPまたはMPLSを使用してネットワーク（PSN）ネットワークです。
PE-Bound The traffic direction in which information from a CE is adapted to a PW, and PW-PDUs are sent into the PSN.
CEからの情報は、PWに適合されたトラフィックの方向をPE-バウンド、およびPW-PDUは、PSNに送られます。
PE/PW Maintenance Used by the PEs to set up, maintain, and tear down the PW. It may be coupled with CE Signaling in order to manage the PW effectively.
PE / PWメンテナンス、設定、維持、およびPWを取り壊すするのPEによって使用されます。これは、効果的にPWを管理するためにCEシグナリングを結合することができます。
Protocol Data The unit of data output to, or received Unit (PDU) from, the network by a protocol layer.
プロトコルデータへのデータ出力、または受信ユニット（PDU）の単位、プロトコル層によってネットワーク。
Provider Edge (PE) A device that provides PWE3 to a CE.
プロバイダエッジ（PE）CEにPWE3を提供する装置。
Pseudo Wire (PW) A mechanism that carries the essential elements of an emulated service from one PE to one or more other PEs over a PSN.
疑似ワイヤ（PW）PSNを介して1つまたは複数の他のPEへの1つのPEからエミュレートされたサービスの本質的な要素を搬送機構。
Pseudo Wire A mechanism that emulates the essential Emulation Edge to attributes of service (such as a T1 leased Edge (PWE3) line or Frame Relay) over a PSN.
擬似ワイヤPSN上（例えばT1専用エッジ（PWE3）ラインまたはフレーム・リレーのような）サービスの属性に必須のエミュレーションエッジをエミュレートする機構。
Pseudo Wire PDU A PDU sent on the PW that contains all of (PW-PDU) the data and control information necessary to emulate the desired service.
擬似ワイヤPDU A PDUは（PW-PDU）の全含有PWデータを送信し、所望のサービスをエミュレートするために必要な情報を制御します。
PSN Tunnel A tunnel across a PSN, inside which one or more PWs can be carried.
PSNトンネルの一の以上のPWを実施することができる内部PSNを横切るトンネル、。
PSN Tunnel Used to set up, maintain, and tear down the Signaling underlying PSN tunnel.
PSNトンネルは、設定、維持、およびPSNトンネルの基礎となるシグナリングを取り壊すために使用します。
PW Demultiplexer Data-plane method of identifying a PW terminating at a PE.
PEでPWの終端を識別するPWデマルチプレクサデータプレーン方法。
Time Domain Time Division Multiplexing. Frequently used Multiplexing (TDM) to refer to the synchronous bit streams at rates defined by G.702.
タイムドメイン時分割多重。頻繁G.702によって定義された速度で同期ビットストリームを参照するために多重化（TDM）を使用しました。
Tunnel A method of transparently carrying information over a network.
トンネル透過ネットワークを介して情報を運ぶ方法。
The PSN carrying a PW will subject payload packets to loss, delay, delay variation, and re-ordering. During a network transient there may be a sustained period of impaired service. The applicability of PWE3 to a particular service depends on the sensitivity of that service (or the CE implementation) to these effects, and on the ability of the adaptation layer to mask them. Some services, such as IP over FR over PWE3, may prove quite resilient to IP and MPLS PSN characteristics. Other services, such as the interconnection of PBX systems via PWE3, will require more careful consideration of the PSN and adaptation layer characteristics. In some instances, traffic engineering of the underlying PSN will be required, and in some cases the constraints may make the required service guarantees impossible to provide.
PWを運ぶPSNは損失、遅延、遅延変動、及び再整列にペイロードパケットをかけるであろう。ネットワークの過渡時には障害者サービスの持続期間があるかもしれません。特定のサービスへPWE3の適用は、これらの効果へのサービス（またはCE実装）の感度で、それらをマスクするアダプテーション層の能力に依存します。このようPWE3を超えるFRオーバーIPなどの一部のサービスは、IPおよびMPLS PSNの特性に非常に弾力性を証明することがあります。このようPWE3経由でPBXシステムの相互接続などの他のサービスは、PSNとアダプテーション層の特性をより慎重に検討する必要があります。いくつかの例では、基本的なPSNのトラフィックエンジニアリングが必要となり、場合によっては制約が必要なサービスを提供することは不可能保証ことがあります。
The PWE3 protocol-layering model is intended to minimize the differences between PWs operating over different PSN types. The design of the protocol-layering model has the goals of making each PW definition independent of the underlying PSN, and of maximizing the reuse of IETF protocol definitions and their implementations.
PWE3プロトコル・レイヤリングモデルが異なるPSNタイプ上で動作するPWの間の違いを最小限にするためのものです。プロトコル・レイヤリングモデルの設計は、基本的なPSNの各PW定義は独立して行うこと、およびIETFプロトコルの定義とその実装の再利用を最大化するという目標を持っています。
The logical protocol-layering model required to support a PW is shown in Figure 1.
PWをサポートするために必要な論理プロトコルレイヤリングモデルは、図1に示されています。
+---------------------------+
| Payload |
+---------------------------+
| Encapsulation | <==== may be empty
+---------------------------+
| PW Demultiplexer |
+---------------------------+
| PSN Convergence | <==== may be empty
+---------------------------+
| PSN |
+---------------------------+
| Data-Link |
+---------------------------+
| Physical |
+---------------------------+
Figure 1. Logical Protocol Layering Model
図1.論理プロトコルの階層化モデル
The payload is transported over the Encapsulation Layer. The Encapsulation Layer carries any information, not already present within the payload itself, that is needed by the PW CE-bound PE interface to send the payload to the CE via the physical interface. If no further information is needed in the payload itself, this layer is empty.
ペイロードは、カプセル化層の上に移送されます。封入層は、物理インターフェイスを介してCEへのペイロードを送信するためにPWのCE-PE結合のインターフェースによって必要とされるペイロード自体内に存在しない既に、任意の情報を運びます。それ以上の情報は、ペイロード自体に必要とされていない場合、この層は空です。
The Encapsulation Layer also provides support for real-time processing, and if needed for sequencing.
封入層は、リアルタイム処理のためのサポートを提供し、場合シーケンシングのために必要。
The PW Demultiplexer layer provides the ability to deliver multiple PWs over a single PSN tunnel. The PW demultiplexer value used to identify the PW in the data plane may be unique per PE, but this is not a PWE3 requirement. It must, however, be unique per tunnel endpoint. If it is necessary to identify a particular tunnel, then that is the responsibility of the PSN layer.
PWデマルチプレクサ層は、単一のPSNトンネルを介して複数のPWを送達する能力を提供します。データプレーン内のPWを識別するために使用されるPWデマルチプレクサ値はPEごとに一意であってもよいが、これはPWE3の要件ではありません。しかし、トンネルエンドポイントごとに一意である必要があります。それは、特定のトンネルを識別する必要がある場合、それはPSN層の責任です。
The PSN Convergence layer provides the enhancements needed to make the PSN conform to the assumed PSN service requirement. Therefore, this layer provides a consistent interface to the PW, making the PW independent of the PSN type. If the PSN already meets the service requirements, this layer is empty.
PSNコンバージェンス層はPSNが想定さPSNのサービス要件に適合させるために必要な拡張機能を提供します。したがって、この層は、PSN型のPWの独立を作る、PWへの一貫したインターフェースを提供します。 PSNは、すでにサービスの要件を満たしている場合、この層は空です。
The PSN header, MAC/Data-Link, and Physical Layer definitions are outside the scope of this document. The PSN can be IPv4, IPv6, or MPLS.
PSNヘッダー、MAC /データリンク、および物理層の定義は、この文書の範囲外です。 PSNは、IPv4、IPv6の、またはMPLSすることができます。
PWE3 defines the Encapsulation Layer, the method of carrying various payload types, and the interface to the PW Demultiplexer Layer. It is expected that the other layers will be provided by tunneling methods such as L2TP or MPLS over the PSN.
PWE3は、封入層、さまざまなペイロードタイプを搬送する方法、及びPWデマルチプレクサレイヤへのインタフェースを定義します。他の層は、PSNを介してこのようなL2TPまたはMPLSのようなトンネリング方法により提供されることが期待されます。
The payload is classified into the following generic types of native data units:
ペイロードは、ネイティブのデータ単位以下の一般的な種類に分類されています。
o Packet
o Cell
o Bit stream
o Structured bit stream
Within these generic types there are specific service types:
これらの一般的なタイプの内の特定のサービスの種類があります。
Generic Payload Type PW Service
-------------------- ----------
Packet Ethernet (all types), HDLC framing,
Frame Relay, ATM AAL5 PDU.
Cell ATM.
セルのATM。
Bit stream Unstructured E1, T1, E3, T3.
ビットストリーム非構造化E1、T1、E3、T3。
Structured bit stream SONET/SDH (e.g., SPE, VT, NxDS0).
構造化されたビットストリームSONET / SDH（例えば、SPE、VT、のNxDS0）。
A packet payload is a variable-size data unit delivered to the PE via the AC. A packet payload may be large compared to the PSN MTU. The delineation of the packet boundaries is encapsulation specific. HDLC or Ethernet PDUs can be considered examples of packet payloads. Typically, a packet will be stripped of transmission overhead such as HDLC flags and stuffing bits before transmission over the PW.
パケットペイロードは、ACを介してPEに送達可変サイズのデータ単位です。パケットペイロードは、PSN MTUに比べて大きくしてもよいです。パケット境界の描写は、カプセル化固有のものです。 HDLCまたはイーサネットPDUは、パケットのペイロードの例を考えることができます。典型的には、パケットは、PWを介して送信する前に、そのようなHDLCフラグおよびスタッフィングビットとして伝送オーバーヘッドを剥奪します。
A packet payload would normally be relayed across the PW as a single unit. However, there will be cases where the combined size of the packet payload and its associated PWE3 and PSN headers exceeds the PSN path MTU. In these cases, some fragmentation methodology has to be applied. This may, for example, be the case when a user provides the service and attaches to the service provider via Ethernet, or when nested pseudo-wires are involved. Fragmentation is discussed in more detail in section 5.3.
パケットペイロードは、通常、単一のユニットとしてPWを横切って中継されることになります。しかし、パケットペイロードおよびその関連PWE3とPSNヘッダの合計サイズが、PSNパスMTUを超える場合があります。これらのケースでは、いくつかの断片化の方法論を適用する必要があります。ネストされた擬似ワイヤが関与している場合、ユーザはサービスを提供し、イーサネットを介してサービスプロバイダに取り付ける場合、またはこれは、例えば、場合であってもよいです。断片化は、セクション5.3で詳しく説明されています。
A packet payload may need sequencing and real-time support.
パケットペイロードは、シーケンシングおよびリアルタイムのサポートが必要な場合があります。
In some situations, the packet payload may be selected from the packets presented on the emulated wire on the basis of some sub-multiplexing technique. For example, one or more Frame Relay PDUs may be selected for transport over a particular pseudo wire based on the Frame Relay Data-Link Connection Identifier (DLCI), or, in the case of Ethernet payloads, by using a suitable MAC bridge filter. This is a forwarder function, and this selection would therefore be made before the packet was presented to the PW Encapsulation Layer.
いくつかの状況では、パケットのペイロードは、いくつかのサブ多重化技術に基づいてエミュレートされたワイヤ上に提示パケットから選択することができます。例えば、1つ以上のフレームリレーPDUが適切なMACブリッジフィルタを使用して、イーサネットペイロードの場合には、フレームリレーデータリンク接続識別子（DLCI）に基づいて、特定の疑似ワイヤ上を輸送のために選択され、又はされてもよいです。これは、フォワーダ機能であり、パケットがPWカプセル層に提示される前に、この選択は、したがって行われることになります。
A cell payload is created by capturing, transporting, and replaying groups of octets presented on the wire in a fixed-size format. The delineation of the group of bits that comprise the cell is specific to the encapsulation type. Two common examples of cell payloads are ATM 53-octet cells, and the larger 188-octet MPEG Transport Stream packets [DVB].
セルペイロードは、捕捉輸送、及び固定サイズの形式でワイヤ上に提示されたオクテットのグループを再生することによって作成されます。セルを含むビットのグループの描写は、カプセル化タイプに特異的です。セルペイロードの二つの一般的な例は、ATM 53オクテットの細胞であり、より大きな188オクテットMPEGトランスポートストリームパケット[DVB]。
To reduce per-PSN packet overhead, multiple cells may be concatenated into a single payload. The Encapsulation Layer may consider the payload complete on the expiry of a timer, after a fixed number of cells have been received or when a significant cell (e.g., an ATM OAM cell) has been received. The benefit of concatenating multiple PDUs should be weighed against a possible increase in packet delay variation and the larger penalty incurred by packet loss. In some cases, it may be appropriate for the Encapsulation Layer to perform some type of compression, such as silence suppression or voice compression.
毎PSNパケットのオーバーヘッドを減らすために、複数のセルは、単一のペイロードに連結されてもよいです。細胞の固定数が受信された後、または有意な細胞（例えば、ATM OAMセル）を受信した場合の封止層は、タイマーの満了にペイロードが完全に考慮することができます。複数のPDUを連結することの利点は、パケット遅延変化、パケット損失によって被る大きなペナルティの可能な増加と比較検討されなければなりません。封入層は、無音抑圧又は音声圧縮として、圧縮のいくつかの種類を実行するためのいくつかのケースでは、それが適切であり得ます。
The generic cell payload service will normally need sequence number support and may also need real-time support. The generic cell payload service would not normally require fragmentation.
一般的なセルペイロードサービスは、通常のシーケンス番号のサポートが必要になりますし、また、リアルタイムのサポートが必要な場合があります。一般的なセルペイロードサービスが正常に断片化を必要としません。
The Encapsulation Layer may apply some form of compression to some of these sub-types (e.g., idle cells may be suppressed).
封入層は、これらのサブタイプ（例えば、アイドルセルを抑制することができる）の一部に圧縮いくつかの形態を適用することができます。
In some instances, the cells to be incorporated in the payload may be selected by filtering them from the stream of cells presented on the wire. For example, an ATM PWE3 service may select cells based on their VCI or VPI fields. This is a forwarder function, and the selection would therefore be made before the packet was presented to the PW Encapsulation Layer.
いくつかの例では、ペイロードに組み込まれるべき細胞は、ワイヤ上に提示する細胞の流れからそれらをフィルタリングすることによって選択することができます。例えば、ATM PWE3サービスは、それらのVCIまたはVPIフィールドに基づいてセルを選択してもよいです。これは、フォワーダ機能であり、パケットがPWカプセル層に提示された前の選択がゆえ行われることになります。
A bit stream payload is created by capturing, transporting, and replaying the bit pattern on the emulated wire, without taking advantage of any structure that, on inspection, may be visible within the relayed traffic (i.e., the internal structure has no effect on the fragmentation into packets).
ビットストリーム・ペイロードを検査に、中継トラフィック内で見ることができる、任意の構造を利用することなく、捕捉輸送、及びエミュレートされたワイヤ上のビットパターンを再生することによって作成される（すなわち、内部構造に影響を及ぼしませんパケットにフラグメンテーション）。
In some instances it is possible to apply suppression to bit streams. For example, E1 and T1 send "all-ones" to indicate failure. This condition can be detected without any knowledge of the structure of the bit stream, and transmission of packetized can be data suppressed.
いくつかの例では、ビットストリームに抑制を適用することが可能です。例えば、E1およびT1は、失敗を示すために、「すべてのもの」を送信します。この状態は、ビットストリームの構造の知識なしに検出することができ、パケットの送信は、データを抑制することができます。
This service will require sequencing and real-time support.
このサービスは、シーケンシングおよびリアルタイムのサポートを必要とします。
A structured bit stream payload is created by using some knowledge of the underlying structure of the bit stream to capture, transport, and replay the bit pattern on the emulated wire.
構造化ビットストリーム・ペイロードは、キャプチャするためにビットストリームの基本構造のいくつかの知識を使用して作成した輸送、及びエミュレートされたワイヤ上のビットパターンを再生します。
Two important points distinguish structured and unstructured bit streams:
二つの重要なポイントは、構造化および非構造化ビットストリームを区別する：
o Some parts of the original bit stream may be stripped in the
PSN-bound direction by an NSP block. For example, in
Structured SONET the section and line overhead (and possibly
more) may be stripped. A framer is required to enable such
stripping. It is also required for frame/payload alignment for
fractional T1/E1 applications.
o The PW must preserve the structure across the PSN so that the CE-bound NSP block can insert it correctly into the reconstructed unstructured bit stream. The stripped information (such as SONET pointer justifications) may appear in the encapsulation layer to facilitate this reconstitution.
CE-バインドNSPブロックが再構築された非構造化ビットストリームに正しく挿入できるように、O PWはPSNの向こう構造を保持しなければなりません。 （例えば、SONETポインタ位置調整など）剥離情報は、この再構成を容易にするために、封入層に表示されてもよいです。
As an option, the Encapsulation Layer may also perform silence/idle suppression or similar compression on a structured bit stream.
オプションとして、封入層はまた、構造化されたビットストリームに無音/アイドル抑制又は同様の圧縮を実行することができます。
Structured bit streams are distinguished from cells in that the structures may be too long to be carried in a single packet. Note that "short" structures are indistinguishable from cells and may benefit from the use of methods described in section 3.3.2.
構造化ビットストリームは、構造が単一のパケットで運ばれるにはあまりにも長くてもよいことで細胞から区別されます。 「短い」構造は細胞から区別できないし、セクション3.3.2に記載された方法を使用することから利益を得ることができることに留意されたいです。
This service requires sequencing and real-time support.
このサービスは、シーケンシングおよびリアルタイムのサポートが必要です。
To minimize the scope of information, and to improve the efficiency of data flow through the Encapsulation Layer, the payload should be transported as received, with as few modifications as possible [RFC1958].
受信した情報の範囲を最小限にするために、および封入層を介してデータフローの効率を向上させるために、ペイロードが可能[RFC1958]のように、いくつかの修正を加えて、輸送されるべきです。
This minimum intervention approach decouples payload development from PW development and requires fewer translations at the NSP in a system with similar CE interfaces at each end. It also prevents unwanted side effects due to subtle misrepresentation of the payload in the intermediate format.
この最小介入アプローチは、PWの開発からペイロードの開発を分離し、各端部に同様のCEインターフェイスを持つシステムでNSPに少なく翻訳を必要とします。それはまた、中間フォーマットのペイロードの微妙詐称による望ましくない副作用を防止します。
An approach that does intervene can be more wire efficient in some cases and may result in fewer translations at the NSP whereby the CE interfaces are of different types. Any intermediate format effectively becomes a new framing type, requiring documentation and assured interoperability. This increases the amount of work for handling the protocol that the intermediate format carries and is undesirable.
介入しないアプローチは、いくつかのケースでは、より効率的なワイヤであることができ、CEインターフェイスは、異なるタイプのものであることにより、NSPでの少ない翻訳をもたらすことができます。任意の中間フォーマットは、効果的に文書化し、確実な相互運用性を必要とする、新しいフレーミングタイプになります。これは、中間フォーマットを担持して望ましくないプロトコルを処理するための作業の量を増加させます。
This section describes the PWE3 architectural model.
このセクションでは、PWE3アーキテクチャモデルについて説明します。
Figure 2 illustrates the network reference model for point-to-point PWs.
図2は、ポイントツーポイントのPWのネットワーク参照モデルを示す図です。
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudo Wire ------>| |
| | | |
| | |<-- 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 2. PWE3 Network Reference Model
図2. PWE3ネットワークリファレンスモデル
The two PEs (PE1 and PE2) have to provide one or more PWs on behalf of their client CEs (CE1 and CE2) to enable the client CEs to communicate over the PSN. A PSN tunnel is established to provide a data path for the PW. The PW traffic is invisible to the core network, and the core network is transparent to the CEs. Native data units (bits, cells, or packets) arrive via the AC, are encapsulated in a PW-PDU, and are carried across the underlying network via the PSN tunnel. The PEs perform the necessary encapsulation and decapsulation of PW-PDUs and handle any other functions required by the PW service, such as sequencing or timing.
2個のPE（PE1およびPE2）はPSNを介して通信するためにクライアントのCEを有効にするには、彼らのクライアントのCE（CE1とCE2）に代わって、一の以上のPWを提供する必要があります。 PSNトンネルがPWのためのデータパスを提供するために確立されています。 PWトラフィックは、コアネットワークには見えないし、コアネットワークは、CEに透過的です。ネイティブ・データ・ユニット（ビット、細胞、またはパケット）ACを介して到着する、PW-PDUにカプセル化され、そしてPSNトンネルを介して、基礎となるネットワークを介して行われます。 PEはPW-PDUの必要なカプセル化およびカプセル化解除を実行し、そのような配列決定またはタイミングとしてPWサービスによって要求される任意の他の機能を扱います。
Some applications have to perform operations on the native data units received from the CE (including both payload and signaling traffic) before they are transmitted across the PW by the PE. Examples include Ethernet bridging, SONET cross-connect, translation of locally-significant identifiers such as VCI/VPI, or translation to another service type. These operations could be carried out in external equipment, and the processed data could be sent to the PE over one or more physical interfaces. In most cases, could be in undertaking these operations within the PE provides cost and operational benefits. Processed data is then presented to the PW via a virtual interface within the PE. These pre-processing operations are included in the PWE3 reference model to provide a common reference point, but the detailed description of these operations is outside the scope of the PW definition given here.
一部のアプリケーションは、それらがPEがPWを介して送信される前に（ペイロードおよびシグナリングトラフィックの両方を含む）CEから受信したネイティブ・データ・ユニットの操作を実行しなければなりません。例としては、イーサネットブリッジング、SONETクロスコネクト、そのようなVCI / VPIとして局所的に有意識別子の翻訳、または別のサービスタイプへの変換を含みます。これらの操作は、外部装置で行うことができ、処理されたデータは、1つ以上の物理インターフェイス上にPEに送信することができます。ほとんどの場合、PE内でこれらの業務の運用可能性があり、コストや運用上の利点を提供します。処理されたデータは、その後、PE内の仮想インタフェースを介してPWに提示されます。これらの前処理操作は、共通の基準点を提供するために、PWE3参照モデルに含まれるが、これらの動作の詳細な説明はここで与えられたPWの定義の範囲外であるれます。
PW
End Service
|
|<------- Pseudo Wire ------>|
| |
| |<-- PSN Tunnel -->| |
V V V V PW
+-----+----+ +----+ End Service
+-----+ |PREP | PE1|==================| PE2| | +-----+
| | | |............PW1.............|----------| |
| CE1 |----| | | | | | | CE2 |
| | ^ | |............PW2.............|----------| |
+-----+ | | | |==================| | | ^ +-----+
| +-----+----+ +----+ | |
| ^ | |
| | | |
| |<------- Emulated Service ------->| |
| | |
| Virtual physical |
| termination |
| ^ |
CE1 native | CE2 native
service | service
|
CE2 native
service
Figure 3. Pre-processing within the PWE3 Network Reference Model
PWE3ネットワークリファレンスモデル内の図3.前処理
Figure 3 shows the interworking of one PE with pre-processing (PREP), and a second without this functionality. This reference point emphasizes that the functional interface between PREP and the PW is that represented by a physical interface carrying the service. This effectively defines the necessary inter-working specification.
図3は、前処理（PREP）を有する1個のPEのインターワーキングを示しており、この機能はなく、第2。この基準点はPREPとPWとの間の機能的なインターフェイスはサービスを搬送する物理インタフェースで表されることがあることを強調しています。これは、効果的に必要なインターワーキングの仕様を定義します。
The operation of a system in which both PEs include PREP functionality is also supported.
両方のPEがPREP機能が含まれているシステムの動作もサポートされています。
The required pre-processing can be divided into two components:
必要な前処理は、2つの成分に分けることができます。
o Forwarder (FWRD)
o Native Service Processing (NSP)
Some applications have to forward payload elements selectively from one or more ACs to one or more PWs. In such cases, there will also be a need to perform the inverse function on PWE3-PDUs received by a PE from the PSN. This is the function of the forwarder.
一部のアプリケーションでは、一の以上のPWへの1つのまたは複数のACSから選択ペイロード要素を転送する必要があります。このような場合にも、PSNからPEによって受信PWE3-のPDUに逆関数を実行する必要があるだろう。これは、フォワーダの関数です。
The forwarder selects the PW based on, for example, the incoming AC, the contents of the payload, or some statically and/or dynamically configured forwarding information.
フォワーダは、例えば、に基づいて、PWを選択し、入力AC、ペイロードのコンテンツ、またはいくつかの静的および/または動的に構成された転送情報。
+----------------------------------------+
| PE Device |
+----------------------------------------+
Single | | |
AC | | Single | PW Instance
<------>o Forwarder + PW Instance X<===========>
| | |
+----------------------------------------+
Figure 4a. Simple Point-to-Point Service
図4a。シンプルなポイントツーポイントサービス
+----------------------------------------+
| PE Device |
+----------------------------------------+
Multiple| | Single | PW Instance
AC | + PW Instance X<===========>
<------>o | |
| |----------------------|
<------>o | Single | PW Instance
| Forwarder + PW Instance X<===========>
<------>o | |
| |----------------------|
<------>o | Single | PW Instance
| + PW Instance X<===========>
<------>o | |
+----------------------------------------+
Figure 4b. Multiple AC to Multiple PW Forwarding
図4b。複数のPW転送への複数のAC
Figure 4a shows a simple forwarder that performs some type of filtering operation. Because the forwarder has a single input and a single output interface, filtering is the only type of forwarding operation that applies. Figure 4b shows a more general forwarding situation where payloads are extracted from one or more ACs and directed to one or more PWs. In this case filtering, direction, and combination operations may be performed on the payloads. For example, if the AC were Frame Relay, the forwarder might perform Frame Relay switching and the PW instances might be the inter-switch links.
図4aは、フィルタリング動作のいくつかの種類を実行する単純なフォワーダを示しています。フォワーダは、単一入力単一出力インターフェースを有しているため、フィルタリングが適用される転送動作の唯一のタイプです。図4bは、ペイロードは、1つ以上のACSからの抽出および1つのまたは複数のPWに向けられ、より一般的な転送状況を示しています。この場合、フィルタリング、方向、および組合せ操作がペイロード上で実行されてもよいです。 ACは、フレームリレーた場合たとえば、フォワーダは、フレームリレースイッチングを行う可能性があり、PWインスタンスは、スイッチ間リンクであるかもしれません。
Some applications required some form of data or address translation, or some other operation requiring knowledge of the semantics of the payload. This is the function of the Native Service Processor (NSP).
一部のアプリケーションでは、データやアドレス変換のいくつかのフォーム、またはペイロードのセマンティクスの知識を必要とする他のいくつかの操作が必要でした。これは、ネイティブのサービスプロセッサ（NSP）の関数です。
The use of the NSP approach simplifies the design of the PW by restricting a PW to homogeneous operation. NSP is included in the reference model to provide a defined interface to this functionality. The specification of the various types of NSP is outside the scope of PWE3.
NSPアプローチの使用は均質運転にPWを制限することによってPWの設計を簡素化します。 NSPは、この機能に定義されたインタフェースを提供するために、参照モデルに含まれています。 NSPの様々なタイプの仕様は、PWE3の範囲外です。
+----------------------------------------+
| PE Device |
Multiple+----------------------------------------+
AC | | | Single | PW Instance
<------>o NSP # + PW Instance X<===========>
| | | |
|------| |----------------------|
| | | Single | PW Instance
<------>o NSP #Forwarder + PW Instance X<===========>
| | | |
|------| |----------------------|
| | | Single | PW Instance
<------>o NSP # + PW Instance X<===========>
| | | |
+----------------------------------------+
Figure 5. NSP in a Multiple AC to Multiple PW Forwarding PE
複数PW転送PEに複数のACで図5 NSP
Figure 5 illustrates the relationship between NSP, forwarder, and PWs in a PE. The NSP function may apply any transformation operation (modification, injection, etc.) on the payloads as they pass between the physical interface to the CE and the virtual interface to the forwarder. These transformation operations will, of course, be limited to those that have been implemented in the data path, and that are enabled by the PE configuration. A PE device may contain more than one forwarder.
図5は、PEでNSP、フォワーダ、およびPWの関係を示す図です。彼らはCEへの物理インタフェースとフォワーダに仮想インタフェース間を通過するようにNSP機能は、ペイロード上の任意の変換操作（変更、注射など）を適用することができます。これらの変換操作は、当然のことながら、データ・パス内に実装されたものに限定され、それはPEの構成で有効になっています。 PEデバイスは、複数のフォワーダを含んでいてもよいです。
This model also supports the operation of a system in which the NSP functionality includes terminating the data-link, and the application of Network Layer processing to the payload.
このモデルはまた、NSP機能がデータリンク、およびペイロードのネットワーク層処理のアプリケーションを終了含む、システムの動作をサポートします。
Figure 6 illustrates the maintenance reference model for PWs.
図6は、のPWのメンテナンス参照モデルを示す図です。
|<------- CE (end-to-end) Signaling ------>|
| |<---- PW/PE Maintenance ----->| |
| | |<-- PSN Tunnel -->| | |
| | | Signaling | | |
| V V (out of scope) V V |
v +-----+ +-----+ v
+-----+ | PE1 |==================| PE2 | +-----+
| |-----|.............PW1..............|-----| |
| CE1 | | | | | | CE2 |
| |-----|.............PW2..............|-----| |
+-----+ | |==================| | +-----+
+-----+ +-----+
Customer Provider Provider Customer
Edge 1 Edge 1 Edge 2 Edge 2
Figure 6. PWE3 Maintenance Reference Model
図6. PWE3メンテナンスリファレンスモデル
The following signaling mechanisms are required:
以下のシグナル伝達機構が必要とされています。
o The CE (end-to-end) signaling is between the CEs. This
signaling could be Frame Relay PVC status signaling, ATM SVC
signaling, TDM CAS signaling, etc.
o The PW/PE Maintenance is used between the PEs (or NSPs) to set up, maintain, and tear down PWs, including any required coordination of parameters.
O PW / PEメンテナンス、設定、維持、およびパラメータの必要な連携を含む、のPWを切断するPES（又はなNSP）との間で使用されています。
o The PSN Tunnel signaling controls the PW multiplexing and some elements of the underlying PSN. Examples are L2TP control protocol, MPLS LDP, and RSVP-TE. The definition of the information that PWE3 needs signaled is within the scope of PWE3, but the signaling protocol itself is not.
O PSNトンネルシグナリングは、PWの多重化と、基礎となるPSNのいくつかの要素を制御します。例としては、L2TP制御プロトコル、MPLS LDP、およびRSVP-TEです。 PWE3ニーズが通知する情報の定義は、PWE3の範囲内であるが、シグナリングプロトコル自体ではありません。
Figure 7 illustrates the protocol stack reference model for PWs.
図7は、PWsのためのプロトコルスタック参照モデルを示す図です。
+-----------------+ +-----------------+
|Emulated Service | |Emulated Service |
|(e.g., TDM, ATM) |<==== Emulated Service ===>|(e.g., TDM, ATM) |
+-----------------+ +-----------------+
| Payload | | Payload |
| Encapsulation |<====== Pseudo Wire ======>| Encapsulation |
+-----------------+ +-----------------+
|PW Demultiplexer | |PW Demultiplexer |
| PSN Tunnel, |<======= PSN Tunnel ======>| PSN Tunnel, |
| PSN & Physical | | PSN & Physical |
| Layers | | Layers |
+-------+---------+ ___________ +---------+-------+
| / \ |
+===============/ PSN \===============+
\ /
\_____________/
Figure 7. PWE3 Protocol Stack Reference Model
図7. PWE3プロトコルスタック参照モデル
The PW provides the CE with an emulated physical or virtual connection to its peer at the far end. Native service PDUs from the CE are passed through an Encapsulation Layer at the sending PE and then sent over the PSN. The receiving PE removes the encapsulation and restores the payload to its native format for transmission to the destination CE.
PWは、遠端でそのピアにエミュレートされた物理または仮想接続でCEを提供します。 CEからネイティブサービスPDUが送信PEに封入層を通過した後、PSNを介して送信されます。受信PEは、カプセル化を除去し、宛先CEへの送信のためにそのネイティブフォーマットにペイロードを復元します。
Figure 8 illustrates how the protocol stack reference model is extended to include the provision of pre-processing (forwarding and NSP). This shows the placement of the physical interface relative to the CE.
図8は、プロトコルスタックの参照モデルは、前処理（転送及びNSP）の提供を含むように拡張されている様子を示しています。これは、CEに対する物理インタフェースの配置を示しています。
/======================================\
H Forwarder H<----Pre-processing
H----------------======================/
H Native Service H | |
H Processing H | |
\================/ | |
| | | Emulated |
| Service | | Service |
| Interface | | (TDM, ATM, |
| (TDM, ATM, | | Ethernet, |<== Emulated Service ==
| Ethernet, | | Frame Relay, |
| Frame Relay, | | etc.) |
| etc.) | +-----------------+
| | | Payload |
| | | Encapsulation |<=== Pseudo Wire ======
| | +-----------------+
| | |PW Demultiplexer |
| | | PSN Tunnel, |
| | | PSN & Physical |<=== PSN Tunnel =======
| | | Headers |
+----------------+ +-----------------+
| Physical | | Physical |
+-------+--------+ +-------+---------+
| |
| |
| |
| |
| |
| |
To CE <---+ +---> To PSN
Figure 8. Protocol Stack Reference Model with Pre-processing
前処理と図8.プロトコルスタック参照モデル
The PW Encapsulation Layer provides the necessary infrastructure to adapt the specific payload type being transported over the PW to the PW Demultiplexer Layer used to carry the PW over the PSN.
PWカプセル化層は、PSN上PWを運ぶために使用PWデマルチプレクサ層にPWを介して転送されている特定のペイロードタイプを適合させるために必要なインフラストラクチャを提供します。
The PW Encapsulation Layer consists of three sub-layers:
PWカプセル化層は、以下の3つのサブレイヤーで構成されています。
o Payload Convergence
o Timing
o Sequencing
The PW Encapsulation sub-layering and its context with the protocol stack are shown in Figure 9.
PWカプセル化サブレイヤリングとプロトコルスタックとのコンテキストが図9に示されています。
+---------------------------+
| Payload |
/===========================\ <------ Encapsulation
H Payload Convergence H Layer
H---------------------------H
H Timing H
H---------------------------H
H Sequencing H
\===========================/
| PW Demultiplexer |
+---------------------------+
| PSN Convergence |
+---------------------------+
| PSN |
+---------------------------+
| Data-Link |
+---------------------------+
| Physical |
+---------------------------+
Figure 9. PWE3 Encapsulation Layer in Context
コンテキスト図9. PWE3カプセル化レイヤ
The Payload Convergence sub-layer is highly tailored to the specific payload type. However grouping a number of target payload types into a generic class, and then providing a single convergence sub-layer type common to the group, reduces the number of payload convergence sub-layer types. This decreases implementation complexity. The provision of per-packet signaling and other out-of-band information (other than sequencing or timing) is undertaken by this layer.
ペイロード収束サブ層は高度に特異的なペイロードタイプに合わせて調整されます。しかし、一般的なクラスにターゲット・ペイロード・タイプの数をグループ化し、グループに共通の単一の収束副層型を提供する、ペイロードコンバージェンスサブレイヤタイプの数を減少させます。これは、実装の複雑さを減少させます。パケットごとのシグナリングおよび（配列決定またはタイミング以外の）他の帯域外情報の提供は、この層によって行われます。
The Timing and Sequencing Layers provide generic services to the Payload Convergence Layer for all payload types that require them.
タイミングとシーケンスレイヤーは、それらを必要とするすべてのペイロードタイプのためのペイロードのコンバージェンスレイヤに汎用的なサービスを提供しています。
The primary task of the Payload Convergence Layer is the encapsulation of the payload in PW-PDUs. The native data units to be encapsulated may contain an L2 header or L1 overhead. This is service specific. The Payload Convergence header carries the additional information needed to replay the native data units at the CE-bound physical interface. The PW Demultiplexer header is not considered part of the PW header.
ペイロードコンバージェンスレイヤの主な仕事は、PW-PDUのペイロードのカプセル化したものです。カプセル化されるネイティブ・データ・ユニットは、L2ヘッダ又はL1オーバーヘッドを含んでいてもよいです。これは、サービス固有のものです。ペイロード収束ヘッダは、CE-結合物理インターフェースでネイティブデータユニットを再生するのに必要な追加情報を搬送します。 PWデマルチプレクサヘッダはPWヘッダの一部とは見なされません。
Not all the additional information needed to replay the native data units have to be carried in the PW header of the PW PDUs. Some information (e.g., service type of a PW) may be stored as state information at the destination PE during PW set up.
ネイティブのデータユニットを再生するために必要でないすべての追加情報は、PW PDUのPWヘッダで運ばなければなりません。 PWがセットアップ中に、いくつかの情報（例えば、PWのサービスタイプ）は、宛先PEの状態情報として格納することができます。
The PW Encapsulation Layer and its associated signaling require one or more of the following types of channels from its underlying PW Demultiplexer and PSN Layers (channel type 1 plus one or more of channel types 2 through 4):
PWカプセル化層とその関連するシグナルは、基礎となるPWデマルチプレクサとPSNレイヤー（チャネル1型プラスチャネルタイプ2〜4の一つ以上）からチャネルの以下のタイプの一つ以上を必要とします。
1. A reliable control channel for signaling line events, status indications, and, in exceptional cases, CE-CE events that must be translated and sent reliably between PEs. PWE3 may need this type of control channel to provide faithful emulation of complex data-link protocols.
1.ラインイベント、状態表示、及び、PE間を確実に翻訳され、送信されなければならない例外的な場合において、CE-CEイベントをシグナリングするための信頼性の高い制御チャネル。 PWE3は、複雑なデータ・リンク・プロトコルの忠実なエミュレーションを提供するために、制御チャネルのこのタイプが必要な場合があります。
2. A high-priority, unreliable, sequenced channel. A typical use is for CE-to-CE signaling. "High priority" may simply be indicated via the DSCP bits for IP or the EXP bits for MPLS, giving the packet priority during transit. This channel type could also use a bit in the tunnel header itself to indicate that packets received at the PE should be processed with higher priority [RFC2474].
2.優先度の高い、信頼性のない、配列決定したチャネル。典型的な使用は、CE-に-CEシグナリングのためです。 「高優先度」を単に通過中のパケットの優先度を与え、IPまたはMPLSのためのEXPビットのDSCPビットを介して表示されてもよいです。このチャネル・タイプはまた、PEで受信パケットが優先度の高い[RFC2474]で処理されるべきであることを示すために、トンネルヘッダ自体のビットを使用することができます。
3. A sequenced channel for data traffic that is sensitive to packet reordering (one classification for use could be for any non-IP traffic).
3. Aは、リオーダリングパケット（使用するための1つの分類は、任意の非IPトラフィック用であってもよい）に敏感であるデータトラフィック用チャネルを配列決定しました。
4. An unsequenced channel for data traffic insensitive to packet order.
4.パケットの順序の影響を受けないデータトラフィック用unsequencedチャンネル。
The data channels (2, 3, and 4 above) should be carried "in band" with one another to as much of a degree as is reasonably possible on a PSN.
PSN上で合理的に可能であるように、データチャネル（上記2、3、及び4）は、度をできるだけ多くするために互いに「帯域内」実施すべきです。
Where end-to-end connectivity may be disrupted by address translation [RFC3022], access-control lists, firewalls, etc., the control channel may be able to pass traffic and setup the PW, while the PW data traffic is blocked by one or more of these mechanisms. In these cases unless the control channel is also carried "in band", the signaling to set up the PW will not confirm the existence of an end-to-end data path. In some cases there is a need to synchronize CE events with the data carried over a PW. This is especially the case with TDM circuits (e.g., the on-hook/off-hook events in PSTN switches might be carried over a reliable control channel whereas the associated bit stream is carried over a sequenced data channel).
エンドツーエンド接続は、アドレス変換[RFC3022]、アクセス制御リスト、ファイアウォール等によって破壊することができる場合PWデータトラフィックを1ブロックされている間、制御チャネルは、トラフィックと設定PWを通過することができるかもしれませんこれらのメカニズムの以上。制御チャネルはまた、「帯域内」実施されていない限り、これらのケースでは、PWをセットアップするためのシグナリングは、エンドツーエンドのデータパスの存在を確認しないであろう。いくつかのケースではPW上で搬送されるデータを持つCEのイベントを同期させる必要があります。これは、特にTDM回路（例えば、関連するビットストリームを配列決定データチャネルを介して行われるのに対し、オンフック/ PSTNスイッチのオフフックイベントが信頼性の高い制御チャネルを介して運ばれるかもしれない）の場合です。
PWE3 channel types that are not needed by the supported PWs need not be included in such an implementation.
サポートPWをによって必要とされていないPWE3チャネルの種類は、このような実装に含まれる必要がありません。
Where possible, it is desirable to employ mechanisms to provide PW Quality of Service (QoS) support over PSNs.
可能であれば、サービスのPW品質（QoS）のPSNの上にサポートを提供するためのメカニズムを採用することが望ましいです。
Two PWE3 Encapsulation sub-layers provide common services to all payload types: Sequencing and Timing. These services are optional and are only used if a particular PW instance needs them. If the service is not needed, the associated header may be omitted in order to conserve processing and network resources.
シーケンシングおよびタイミング：二つのPWE3カプセル化サブ層は、すべてのペイロードタイプに共通のサービスを提供しています。これらのサービスはオプションであり、特定のPWインスタンスがそれらを必要とする場合にのみ使用されます。サービスが必要とされない場合、関連するヘッダを処理し、ネットワークリソースを節約するために省略されてもよいです。
Sometimes a specific payload type will require transport with or without sequence and/or real-time support. For example, an invariant of Frame Relay transport is the preservation of packet order. Some Frame Relay applications expect delivery in order and may not cope with reordering of the frames. However, where the Frame Relay service is itself only being used to carry IP, it may be desirable to relax this constraint to reduce per-packet processing cost.
時には、特定のペイロードタイプは、シーケンスの有無にかかわらず輸送および/またはリアルタイムのサポートが必要になります。例えば、フレームリレー輸送の不変は、パケット順序の保存です。いくつかのフレームリレーアプリケーションが順番に配信を期待してフレームの並べ替えには対応しない場合があります。フレームリレーサービスは、それ自体であるところだけIPを運ぶために使用されているしかし、パケットあたりの処理コストを削減するために、この制約を緩和することが望ましいことがあります。
The guiding principle is that, when possible, an existing IETF protocol should be used to provide these services. When a suitable protocol is not available, the existing protocol should be extended or modified to meet the PWE3 requirements, thereby making that protocol available for other IETF uses. In the particular case of timing, more than one general method may be necessary to provide for the full scope of payload timing requirements.
指針となる原則は、可能な場合、既存のIETFプロトコルは、これらのサービスを提供するために使用されなければならない、ということです。適切なプロトコルが利用できない場合、既存のプロトコルは、それによって他のIETFの用途のためにそのプロトコルが利用できるように、PWE3の要件を満たすように拡張または修正されるべきです。タイミングの特定の場合では、複数の一般的な方法は、ペイロードのタイミング要件の全範囲を提供する必要があるかもしれません。
The sequencing function provides three services: frame ordering, frame duplication detection, and frame loss detection. These services allow the emulation of the invariant properties of a physical wire. Support for sequencing depends on the payload type and may be omitted if it is not needed.
フレーム順序、フレームの重複検出、およびフレーム損失検出：シーケンシング機能は3つのサービスを提供します。これらのサービスは、物理的な配線の不変の性質のエミュレーションを可能にします。シークエンシングのためのサポートは、ペイロードタイプに依存し、それが必要とされない場合は省略することができます。
The size of the sequence-number space depends on the speed of the emulated service, and on the maximum time of the transient conditions in the PSN. A sequence number space greater than 2^16 may therefore be needed to prevent the sequence number space from wrapping during the transient.
シーケンス番号空間のサイズは、エミュレートされたサービスの速度に依存し、PSNでの過渡状態の最大時間に。 2 ^ 16は、従って、過渡時に包装からシーケンス番号空間を防止するために必要とされ得るよりも大きなシーケンス番号空間。
When packets carrying the PW-PDUs traverse a PSN, they may arrive out of order at the destination PE. For some services, the frames (control frames, data frames, or both) must be delivered in order. For these services, some mechanism must be provided for ensuring in-order delivery. Providing a sequence number in the sequence sub-layer header for each packet is one possible approach. Alternatively, it can be noted that sequencing is a subset of the problem of delivering timed packets, and that a single combined mechanism such as [RFC3550] may be employed.
PW-PDUを運ぶパケットはPSNを横断するとき、それらは先PEで順不同で到着することができます。いくつかのサービスのために、フレーム（制御フレーム、データフレーム、またはその両方）が順番に送達されなければなりません。これらのサービスのために、いくつかのメカニズムは、順序どおりの配信を確保するために提供されなければなりません。各パケットのシーケンス副層ヘッダ内のシーケンス番号を提供する一つの可能なアプローチです。あるいは、配列決定は、タイミングパケットを配信する問題のサブセットであり、そしてそのような[RFC3550]などの単一の結合機構が採用されてもよいことに留意することができます。
There are two possible misordering strategies:
2つの可能な誤った順序戦略があります。
o Drop misordered PW PDUs.
OドロップPW PDUをmisordered。
o Try to sort PW PDUs into the correct order.
O正しい順序にPW PDUを並べ替えるようにしてください。
The choice of strategy will depend on
戦略の選択はに依存します
o how critical the loss of packets is to the operation of the PW
(e.g., the acceptable bit error rate),
o the speeds of the PW and PSN,
PWとPSNの速度O、
o the acceptable delay (as delay must be introduced to reorder), and
許容される遅延O（遅延が並べ替えるために導入されなければならないように）、および
o the expected incidence of misordering.
誤った順序の予想発生率、O。
In rare cases, packets traversing a PW may be duplicated by the underlying PSN. For some services, frame duplication is not acceptable. For these services, some mechanism must be provided to ensure that duplicated frames will not be delivered to the destination CE. The mechanism may be the same as that used to ensure in-order frame delivery.
まれに、PWを通過するパケットは、基礎となるPSNによって複製されてもよいです。一部のサービスでは、フレームの重複は許されません。これらのサービスのために、いくつかのメカニズムが重複したフレームは、宛先CEに配信されないことを確実にするために提供されなければなりません。機構は、インオーダーフレーム配信を確実にするために使用されるものと同じであってもよいです。
A destination PE can determine whether a frame has been lost by tracking the sequence numbers of the PW PDUs received.
PEはPW PDUのシーケンス番号を追跡することによって、フレームが失われたかどうかを判定することができる宛先は、受信されました。
In some instances, if a PW PDU fails to arrive within a certain time, a destination PE will have to presume that it is lost. If a PW-PDU that has been processed as lost subsequently arrives, the destination PE must discard it.
PW PDUが一定時間内に到着しなかった場合いくつかの例では、宛先PEは、それが失われたと推定しなければなりません。その後失われたように処理されたPW-PDUが到着した場合は、送信先PEは、それを破棄しなければなりません。
A number of native services have timing expectations based on the characteristics of the networks they were designed to travel over. The emulated service may have to duplicate these network characteristics as closely as possible: e.g., in delivering native traffic with bitrate, jitter, wander, and delay characteristics similar to those received at the sending PE.
ネイティブサービスの数は、それらが上を移動するように設計されたネットワークの特性に基づいてタイミング期待を持っています。送信PEで受信したものと同様のビットレート、ジッタ、ワンダ、および遅延特性を有するネイティブトラフィックを配信するに、例えば：エミュレートされたサービスは、可能な限り厳密にこれらのネットワーク特性を複製する必要があります。
In such cases, the receiving PE has to play out the native traffic as it was received at the sending PE. This relies on timing information either sent between the two PEs, or in some cases received from an external reference.
このような場合には、受信したPEは、それが送信PEで受信されたとして、ネイティブのトラフィックをプレイしています。これは、いずれかの2つのPE間で送信されるタイミング情報に依存して、またはいくつかのケースでは、外部参照から受け取りました。
Therefore, Timing Sub-layer must support two timing functions: clock recovery and timed payload delivery. A particular payload type may require either or both of these services.
クロックリカバリ及び時限ペイロード送達：したがって、サブ層タイミングは、2つのタイミング機能をサポートしなければなりません。特定のペイロードタイプは、これらのサービスのいずれかまたは両方を必要とするかもしれません。
Clock recovery is the extraction of output transmission bit timing information from the delivered packet stream, and it requires a suitable mechanism. A physical wire carries the timing information natively, but extracting timing from a highly jittered source, such as packet stream, is a relatively complex task. Therefore, it is desirable that an existing real-time protocol such as [RFC3550] be used for this purpose, unless it can be shown that this is unsuitable or unnecessary for a particular payload type.
クロックリカバリが配信パケットストリームからタイミング情報を出力伝送ビットの抽出され、それは適切な機構を必要とします。物理的ワイヤはネイティブタイミング情報を搬送するが、このようなパケットストリームとして、高いジッタソースからタイミングを抽出し、比較的複雑な作業です。したがって、これが特定のペイロードタイプには適さない又は不要であることを示すことができない限り、このような[RFC3550]などの既存のリアルタイムプロトコルは、この目的のために使用されることが望ましいです。
Timed delivery is the delivery of non-contiguous PW PDUs to the PW output interface with a constant phase relative to the input interface. The timing of the delivery may be relative to a clock derived from the packet stream received over the PSN clock recovery, or to an external clock.
時限送達は、入力インタフェースに対して一定の位相を有するPW出力インターフェイスに非連続PW PDUの送達です。送達のタイミングは、PSNのクロックリカバリを介して受信したパケットストリームから、または外部クロックに由来するクロックに対してであってもよいです。
Ideally, a payload would be relayed across the PW as a single unit. However, there will be cases where the combined size of the payload and its associated PWE3 and PSN headers will exceed the PSN path MTU. When a packet size exceeds the MTU of a given network, fragmentation and reassembly have to be performed for the packet to be delivered. Since fragmentation and reassembly generally consume considerable network resources, as compared to simply switching a packet in its entirety, the need for fragmentation and reassembly throughout a network should be reduced or eliminated to the extent possible. Of particular concern for fragmentation and reassembly are aggregation points where large numbers of PWs are processed (e.g., at the PE).
理想的には、ペイロードは、単一のユニットとしてPWを横切って中継されることになります。しかしながら、ペイロードの合計サイズとそれに関連するPWE3とPSNヘッダーはPSNパスMTUを超える場合があります。パケットサイズが指定されたネットワークのMTUを超えた場合に、フラグメンテーション及び再組み立てが配信されるパケットのために実行されなければなりません。断片化と再アセンブリは、一般に、かなりのネットワークリソースを消費するので、単にその全体がパケットスイッチングに比べて、ネットワーク全体の断片化と再アセンブリの必要性が低減または可能な程度まで除去されるべきです。断片化と再アセンブリのために特に重要でのPWの多数は、（例えば、PEで）処理される集約点です。
Ideally, the equipment originating the traffic sent over the PW will have adaptive measures in place (e.g., [RFC1191], [RFC1981]) that ensure that packets needing to be fragmented are not sent. When this fails, the point closest to the sending host with fragmentation and reassembly capabilities should attempt to reduce the size of packets to satisfy the PSN MTU. Thus, in the reference model for PWE3 (Figure 3), fragmentation should first be performed at the CE if possible. Only if the CE cannot adhere to an acceptable MTU size for the PW should the PE attempt its own fragmentation method.
理想的には、PWを介して送信されるトラフィックを発信する機器が断片化される必要パケットが送信されないような場所に適応措置（例えば、[RFC1191]、[RFC1981]）を有するであろう。これが失敗すると、断片化と再構築機能を備えた送信ホストに最も近いポイントはPSN MTUを満たすために、パケットのサイズを小さくしようとしなければなりません。このように、PWE3（図3）のための参照モデルにおいて、断片は、最初CE可能な場合に行われるべきです。 CEは、PWのために許容されるMTUサイズに付着することができない場合にのみ、PEは、それ自身の断片化方法を試みるべきです。
In cases where MTU management fails to limit the payload to a size suitable for transmission of the PW, the PE may fall back to either a generic PW fragmentation method or, if available, the fragmentation service of the underlying PSN.
MTUの管理は、PWの伝送に適した大きさにペイロードを制限するために失敗した場合には、PEは、バック汎用PWフラグメンテーション法または基礎PSNの、利用可能な場合、断片化サービスのいずれかに落下することができます。
It is acceptable for a PE implementation not to support fragmentation. A PE that does not will drop packets that exceed the PSN MTU, and the management plane of the encapsulating PE may be notified.
PE実装は断片化をサポートしないことが許容されます。 PSN MTUを超えるパケットをドロップしますないPE、およびPEカプセル化の管理プレーンに通知してもよいです。
If the length of a L2/L1 frame, restored from a PW PDU, exceeds the MTU of the destination AC, it must be dropped. In this case, the management plane of the destination PE may be notified.
PW PDUから復元L2 / L1フレームの長さは、先ACのMTUを超えた場合、それは廃棄されなければなりません。この場合、先のPEの管理プレーンに通知してもよいです。
This document does not address the detailed mapping of the Protocol Layering model to existing or future IETF standards. The instantiation of the logical Protocol Layering model is shown in Figure 9.
この文書では、既存または将来のIETF標準にプロトコルレイヤリングモデルの詳細なマッピングに対応していません。論理プロトコルレイヤリングモデルのインスタンスは、図9に示されています。
The protocol definition of PWE3 over an IP PSN should employ existing IETF protocols where possible.
可能な場合はIP PSN経由PWE3のプロトコル定義は、既存のIETFプロトコルを採用する必要があります。
+---------------------+ +-------------------------+
| Payload |------------->| Raw payload if possible |
/=====================\ +-------------------------+
H Payload Convergence H-----------+->| Flags, seq #, etc. |
H---------------------H / +-------------------------+
H Timing H---------/--->| RTP |
H---------------------H / +-------------+ |
H Sequencing H----one of | |
\=====================/ \ | +-----------+
| PW Demultiplexer |---------+--->| L2TP, MPLS, etc. |
+---------------------+ +-------------------------+
| PSN Convergence |------------->| Not needed |
+---------------------+ +-------------------------+
| PSN |------------->| IP |
+---------------------+ +-------------------------+
| Data-Link |------------->| Data-link |
+---------------------+ +-------------------------+
| Physical |------------->| Physical |
+---------------------+ +-------------------------+
Figure 10. PWE3 over an IP PSN
IPのPSNの上に図10 PWE3
Figure 10 shows the protocol layering for PWE3 over an IP PSN. As a rule, the payload should be carried as received from the NSP, with the Payload Convergence Layer provided when needed. However, in certain circumstances it may be justifiable to transmit the payload in some processed form. The reasons for this must be documented in the Encapsulation Layer definition for that payload type.
図10は、IP PSN上PWE3ため積層プロトコルを示します。必要なときに提供されるペイロードコンバージェンス層と、NSPから受信した原則として、ペイロードを搭載しなければなりません。しかし、特定の状況では、いくつかの処理された形態でペイロードを伝送するために正当化することができます。この理由は、そのペイロードタイプのためのカプセル化層の定義に文書化されなければなりません。
Where appropriate, explicit timing is provided by RTP [RFC3550], which, when used, also provides a sequencing service. When the PSN is UDP/IP, the RTP header follows the UDP header and precedes the PW control field. For all other cases the RTP header follows the PW control header.
適切な場合、明示的なタイミングは、使用される場合、また、シークエンシングサービスを提供するRTP [RFC3550]、によって提供されます。 PSNはUDP / IPである場合、RTPヘッダがUDPヘッダの後に続き、PW制御フィールドに先行します。他のすべての場合のためのRTPヘッダは、PW制御ヘッダの後に続きます。
The encapsulation layer may additionally carry a sequence number. Sequencing is to be provided either by RTP or by the PW encapsulation layer, but not by both.
封入層は、さらに、シーケンス番号を搬送することができます。配列決定は、RTPによって、またはPWカプセル化層によって、両方ではなくいずれかによって提供されます。
PW Demultiplexing is provided by the PW label, which may take the form specified in a number of IETF protocols; e.g., an MPLS label [MPLSIP], an L2TP session ID [RFC3931], or a UDP port number [RFC768]. When PWs are carried over IP, the PSN Convergence Layer will not be needed.
PW逆多重化は、IETFプロトコルの数で指定された形態をとることができるPWラベル、によって提供されます。例えば、MPLSラベル[MPLSIP]、L2TPセッションID [RFC3931]、またはUDPポート番号[RFC768]。 PWををIP上で実行されている場合は、PSNコンバージェンスレイヤが必要とされることはありません。
As a special case, if the PW Demultiplexer is an MPLS label, the protocol architecture of section 5.4.2 can be used instead of the protocol architecture of this section.
PWデマルチプレクサはMPLSラベルである場合、特殊な場合として、セクション5.4.2のプロトコルアーキテクチャではなく、このセクションのプロトコルアーキテクチャを使用することができます。
The MPLS ethos places importance on wire efficiency. By using a control word, some components of the PWE3 protocol layers can be compressed to increase this efficiency.
MPLSの精神は、ワイヤー効率を重視します。制御ワードを使用して、PWE3プロトコル層のいくつかの構成要素は、この効率を高めるために圧縮することができます。
+---------------------+
| Payload |
/=====================\
H Payload Convergence H--+
H---------------------H | +--------------------------------+
H Timing H--------->| RTP |
H---------------------H | +--------------------------------+
H Sequencing H--+------>| Flags, Frag, Len, Seq #, etc |
\=====================/ | +--------------------------------+
| PW Demultiplexer |--------->| PW Label |
+---------------------+ | +--------------------------------+
| PSN Convergence |--+ +--->| Outer Label or MPLS-in-IP encap|
+---------------------+ | +--------------------------------+
| PSN |-----+
+---------------------+
| Data-Link |
+---------------------+
| Physical |
+---------------------+
Figure 11. PWE3 over an MPLS PSN Using a Control Word
コントロールワードを使用してMPLS PSN上図11 PWE3
Figure 11 shows the protocol layering for PWE3 over an MPLS PSN. An inner MPLS label is used to provide the PW demultiplexing function. A control word is used to carry most of the information needed by the PWE3 Encapsulation Layer and the PSN Convergence Layer in a compact format. The flags in the control word provide the necessary payload convergence. A sequence field provides support for both in-order payload delivery and a PSN fragmentation service within the PSN Convergence Layer (supported by a fragmentation control method). Ethernet pads all frames to a minimum size of 64 bytes. The MPLS header does not include a length indicator. Therefore, to allow PWE3 to be carried in MPLS to pass correctly over an Ethernet data-link, a length correction field is needed in the control word. As with an IP PSN, where appropriate, timing is provided by RTP [RFC3550].
図11は、MPLS PSN上PWE3ため積層プロトコルを示します。内側のMPLSラベルは、PW逆多重化機能を提供するために使用されます。制御ワードは、PWE3の封入層とコンパクトな形式でPSNコンバージェンスレイヤに必要な情報のほとんどを運ぶために使用されています。制御ワードのフラグが必要なペイロードのコンバージェンスを提供します。シーケンスフィールドは、インオーダーペイロード送達および（フラグメンテーション制御方法でサポートされている）PSN収束層内のPSN断片化サービスの両方のサポートを提供します。イーサネット・パッド64バイトの最小サイズにすべてのフレーム。 MPLSヘッダは、長さインジケータを含んでいません。したがって、PWE3イーサネットデータリンクを介して正しく通過するMPLSで実施することができるように、長補正フィールドは、制御ワードに必要とされます。適切なタイミングは、RTP [RFC3550]により提供されるIP PSNとします。
In some networks, it may be necessary to carry PWE3 over MPLS over IP. In these circumstances, the PW is encapsulated for carriage over MPLS as described in this section, and then a method of carrying MPLS over an IP PSN (such as GRE [RFC2784], [RFC2890]) is applied to the resultant PW-PDU.
いくつかのネットワークでは、IP上でMPLS上のPWE3を運ぶために必要があるかもしれません。このセクションで説明したようにこのような状況では、PWは、MPLS上にキャリッジのためにカプセル化され、その後、IP PSN上MPLS搬送方法（例えば、GRE [RFC2784]としては、[RFC2890]）は、得られたPW-PDUに適用されます。
For MPLS PSNs, there is an additional constraint on the PW packet format. Some label switched routers detect IP packets based on the initial four bits of the packet content. To facilitate proper functioning, these bits in PW packets must not be the same as an IP version number in current use.
MPLSのPSNについて、PWパケットフォーマットの追加の制約があります。いくつかのラベルは、ルータがパケットの内容の最初の4ビットに基づいてIPパケットを検出するスイッチ。適切な機能を容易にするために、PWパケット内のこれらのビットは、現在使用中のIPバージョン番号と同じであってはなりません。
PWE3 places three service requirements on the protocol layers used to carry it across the PSN:
PWE3はPSNを渡ってそれを運ぶために使用されるプロトコル層の上に3つのサービスの要件を課します。
o Multiplexing
o Fragmentation
o Length and Delivery
The purpose of the PW Demultiplexer Layer is to allow multiple PWs to be carried in a single tunnel. This minimizes complexity and conserves resources.
PWデマルチプレクサ層の目的は、複数のPWが単一のトンネルで運ばれるようにすることです。これは、複雑さを最小限に抑え、資源を節約します。
Some types of native service are capable of grouping multiple circuits into a "trunk"; e.g., multiple ATM VCs in a VP, multiple Ethernet VLANs on a physical media, or multiple DS0 services within a T1 or E1. A PW may interconnect two end-trunks. That trunk would have a single multiplexing identifier.
ネイティブサービスの種類によっては、「トランク」に複数の回線をグループ化することができます。例えば、VP内の複数のATM VCで、T1またはE1内の物理メディア、または複数のDS0サービス上の複数のイーサネットVLAN。 PWは、2つのエンドトランクを相互接続することができます。そのトランクは、単一の多重化識別子を持っているでしょう。
When a MPLS label is used as a PW Demultiplexer, setting of the TTL value [RFC3032] in the PW label is application specific.
MPLSラベルがPWデマルチプレクサとして使用する場合、PWラベルにTTL値[RFC3032]の設定はアプリケーション固有です。
If the PSN provides a fragmentation and reassembly service of adequate performance, it may be used to obtain an effective MTU that is large enough to transport the PW PDUs. See section 5.3 for a full discussion of the PW fragmentation issues.
PSNは、十分なパフォーマンスのフラグメンテーション及び再組み立てサービスを提供する場合、PW PDUを輸送するのに十分な大きさの有効なMTUを取得するために使用されてもよいです。 PWの断片化の問題の完全な議論については5.3節を参照してください。
PDU delivery to the egress PE is the function of the PSN Layer.
出口PEへのPDUの送達がPSN層の機能です。
If the underlying PSN does not provide all the information necessary to determine the length of a PW-PDU, the Encapsulation Layer must provide it.
根本的なPSNはPW-PDUの長さを決定するために必要な全ての情報を提供していない場合は、封入層は、それを提供する必要があります。
It is a common practice to use an error detection mechanism such as a CRC or similar mechanism to ensure end-to-end integrity of frames. The PW service-specific mechanisms must define whether the packet's checksum shall be preserved across the PW or be removed from PE-bound PDUs and then be recalculated for insertion in CE-bound data.
フレームのエンドツーエンドの完全性を保証するために、このようなCRCあるいは同様の機構などのエラー検出機構を使用するのが一般的です。 PWサービス固有のメカニズムは、パケットのチェックサムがPWを横切って保存されなければならない、またはPE結合のPDUから除去すること、次いで、CE-結合データに挿入するために再計算されるかどうかを定義しなければなりません。
The former approach saves work, whereas the latter saves bandwidth. For a given implementation, the choice may be dictated by hardware restrictions, which may not allow the preservation of the checksum.
後者は、帯域幅を節約する一方、前者のアプローチは、作業を保存します。所与の実装のために、選択は、チェックサムの保存を許可しないことがあり、ハードウェアの制限によって決定されてもよいです。
For protocols such as ATM and FR, the scope of the checksum is restricted to a single link. This is because the circuit identifiers (e.g., FR DLCI or ATM VPI/VCI) only have local significance and are changed on each hop or span. If the circuit identifier (and thus checksum) were going to change as part of the PW emulation, it would be more efficient to strip and recalculate the checksum.
ATMやFRなどのプロトコルの場合は、チェックサムの範囲は、単一のリンクに制限されています。回路識別子（例えば、FR DLCIまたはATM VPI / VCI）は、ローカルな意味を有し、各ホップまたはスパンに変更されたためです。回路識別子（したがって、チェックサム）はPWエミュレーションの一部として変更しようとしていた場合、ストリップとチェックサムを再計算する方が効率的でしょう。
The service-specific document for each protocol must describe the validation scheme to be used.
各プロトコルのサービス固有のドキュメントは、使用する検証スキームを記述しなければなりません。
The PSN carrying the PW may be subject to congestion. The congestion characteristics will vary with the PSN type, the network architecture and configuration, and the loading of the PSN.
PWを運ぶPSNは混雑を受けることができます。輻輳特性はPSNのタイプ、ネットワークアーキテクチャおよび構成、及びPSNのローディングに応じて変化します。
If the traffic carried over the PW is known to be TCP friendly (by, for example, packet inspection), packet discard in the PSN will trigger the necessary reduction in offered load, and no additional congestion avoidance action is necessary.
PW上で伝送されるトラフィックは優しいTCP（によって、例えば、パケットインスペクション）であることが知られている場合は、PSNでのパケット廃棄は、与えられた負荷に必要な減少が引き金になり、追加の輻輳回避アクションは必要ありません。
If the PW is operating over a PSN that provides enhanced delivery, the PEs should monitor packet loss to ensure that the requested service is actually being delivered. If it is not, then the PE should assume that the PSN is providing a best-effort service and should use the best-effort service congestion avoidance measures described below.
PWが強化された配信を提供してPSN上で動作している場合、PEは要求されたサービスが実際に配信されていることを保証するために、パケット損失を監視する必要があります。そうでない場合は、PEは、PSNはベストエフォート型のサービスを提供していることを前提とすべきであると下記のベストエフォート型のサービスの輻輳回避策を使用する必要があります。
If best-effort service is being used and the traffic is not known to be TCP friendly, the PEs should monitor packet loss to ensure that the loss rate is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path and experiencing the same network conditions would achieve an average throughput, measured on a reasonable timescale, not less than that which the PW flow is achieving. This condition can be satisfied by implementing a rate-limiting measure in the NSP, or by shutting down one or more PWs. The choice of which approach to use depends upon the type of traffic being carried. Where congestion is avoided by shutting down a PW, a suitable mechanism must be provided to prevent it from immediately returning to service and causing a series of congestion pulses.
ベストエフォート型のサービスが使用されていると、トラフィックがTCPフレンドリーであることが知られていない場合は、PEは損失率が許容パラメータの範囲内であることを保証するために、パケット損失を監視する必要があります。 TCPは、同じネットワーク・パスを横切って流れると同じネットワークの状態を経験すると、PW流が達成されるものよりも小さくない合理的な時間スケール上に測定された平均スループットを達成する場合は、パケット損失が許容されると考えられます。この条件は、1つのまたは複数のPWをシャットダウンすることにより、NSPにおける速度制限措置を実施することにより、満足させることができます。使用するアプローチその選択が行われているトラフィックの種類に依存します。輻輳がPWをシャットダウンすることにより回避される場合には、適切な機構は、すぐにサービスに復帰し、輻輳一連のパルスを発生することを防ぐために提供されなければなりません。
The comparison to TCP cannot be specified exactly but is intended as an "order-of-magnitude" comparison in timescale and throughput. The timescale on which TCP throughput is measured is the round-trip time of the connection. In essence, this requirement states that it is not acceptable to deploy an application (using PWE3 or any other transport protocol) on the best-effort Internet, which consumes bandwidth arbitrarily and does not compete fairly with TCP within an order of magnitude. One method of determining an acceptable PW bandwidth is described in [RFC3448].
TCPとの比較を正確に指定することはできませんが、タイムスケールとスループットの「桁違い」の比較として意図されています。 TCPのスループットが測定されているタイムスケールは、接続のラウンドトリップ時間です。本質的には、この要件は、任意の帯域幅を消費し、桁以内TCPと公平に競合しないベストエフォート型インターネット、上（PWE3または任意の他のトランスポートプロトコルを使用して）アプリケーションをデプロイすることは受け入れられないと述べています。許容されるPW帯域幅を決定する1つの方法は、[RFC3448]に記載されています。
This section describes PWE3 control plane services.
このセクションでは、PWE3制御プレーンサービスについて説明します。
A PW must be set up before an emulated service can be established and must be torn down when an emulated service is no longer needed.
エミュレートされたサービスを確立することができ、エミュレートされたサービスが不要になったときに取り壊されてはならない前に、PWを設定する必要があります。
Setup or teardown of a PW can be triggered by an operator command, from the management plane of a PE, by signaling set-up or teardown of an AC (e.g., an ATM SVC), or by an auto-discovery mechanism.
PWのセットアップまたはティアダウンは、PEの管理面から、AC（例えば、ATM SVC）のセットアップまたはティアダウンをシグナリングすることによって、または自動発見メカニズムによって、オペレータコマンドによってトリガすることができます。
During the setup process, the PEs have to exchange information (e.g., learn each other's capabilities). The tunnel signaling protocol may be extended to provide mechanisms that enable the PEs to exchange all necessary information on behalf of the PW.
セットアッププロセス中に、PEは（例えば、互いの能力を学ぶ）情報を交換する必要があります。トンネルシグナリングプロトコルは、PWの代わりにすべての必要な情報を交換するためのPEを有効に機構を提供するように拡張することができます。
Manual configuration of PWs can be considered a special kind of signaling and is allowed.
PW手動による構成は、シグナリングの特別な種類と考えることができ、許可されています。
Some native services have mechanisms for status monitoring. For example, ATM supports OAM for this purpose. For these services, the corresponding emulated services must specify how to perform status monitoring.
いくつかのネイティブサービスは、状態監視のための機構を有しています。例えば、ATMは、この目的のためにOAMをサポートしています。これらのサービスのために、対応するエミュレートされたサービスは、状態監視を実行する方法を指定する必要があります。
If a native service requires bi-directional connectivity, the corresponding emulated service can only be signaled as being up when the PW and PSN tunnels (if used), are functional in both directions.
ネイティブサービスが双方向接続を必要とする場合、対応するエミュレートされたサービスは、PWとPSNトンネルが（使用する場合）、両方向に機能的である場合に最大であるとしてシグナリングすることができます。
Because the two CEs of an emulated service are not adjacent, a failure may occur at a place so that one or both physical links between the CEs and PEs remain up. For example, in Figure 2, if the physical link between CE1 and PE1 fails, the physical link between CE2 and PE2 will not be affected and will remain up. Unless CE2 is notified about the remote failure, it will continue to send traffic over the emulated service to CE1. Such traffic will be discarded at PE1. Some native services have failure notification so that when the services fail, both CEs will be notified. For these native services, the corresponding PWE3 service must provide a failure notification mechanism.
エミュレートされた2つのサービスCEが隣接していないので、CEとPE間の一方または両方の物理リンクがアップ残るように、故障の場所で起こり得ます。 CE1とPE1間の物理リンクに障害が発生した場合、例えば、図2において、CE2およびPE2間の物理リンクには影響されず、アップ残ります。 CE2は、リモート障害について通知されない限り、それはCE1にエミュレートされたサービス上のトラフィックを送信し続けます。このようなトラフィックはPE1で破棄されます。サービスが失敗した場合、両方のCEが通知されるようにいくつかのネイティブサービスは、障害通知を持っています。これらのネイティブサービスの場合、対応するPWE3サービスは、障害通知メカニズムを提供しなければなりません。
Similarly, if a native service has notification mechanisms so that all the affected services will change status from "Down" to "Up" when a network failure is fixed, the corresponding emulated service must provide a similar mechanism for doing so.
同様に、ネイティブサービスは通知メカニズムを持っている場合、影響を受けるすべてのサービスは、ネットワーク障害が固定されている場合、対応するエミュレートされたサービスは、そうするために、同様のメカニズムを提供しなければならないと「アップ」「ダウン」からステータスを変更するように。
These mechanisms may already be built into the tunneling protocol. For example, the L2TP control protocol [RFC2661] [RFC3931] has this capability, and LDP has the ability to withdraw the corresponding MPLS label.
これらのメカニズムは、既にトンネリングプロトコルに組み込まれていてもよいです。例えば、L2TP制御プロトコル[RFC2661]、[RFC3931]はこの能力を有しており、LDPは、対応するMPLSラベルを撤回する能力を有します。
With PWE3, misconnection and payload type mismatch can occur. Misconnection can breach the integrity of the system. Payload mismatch can disrupt the customer network. In both instances, there are security and operational concerns.
PWE3で、誤接続およびペイロードタイプの不整合が発生する可能性があります。誤接続は、システムの整合性を破ることができます。ペイロードの不一致は、顧客のネットワークを混乱させることができます。どちらの場合も、セキュリティや運用懸念があります。
The services of the underlying tunneling mechanism and its associated control protocol can be used to mitigate this. As part of the PW setup, a PW-TYPE identifier is exchanged. This is then used by the forwarder and the NSP to verify the compatibility of the ACs.
下地トンネリングメカニズムとそれに関連する制御プロトコルのサービスは、これを緩和するために使用することができます。 PWのセットアップの一環として、PW-TYPE識別子が交換されます。これは、その後のACの互換性を確認するために、フォワーダとNSPによって使用されます。
A PW can incur packet loss, corruption, and out-of-order delivery on the PSN path between the PEs. This can affect the working condition of an emulated service. For some payload types, packet loss, corruption, and out-of-order delivery can be mapped either to a bit error burst, or to loss of carrier on the PW. If a native service has some mechanism to deal with bit error, the corresponding PWE3 service should provide a similar mechanism.
PWは、PE間のPSN経路上のパケット損失、破損、及びアウトオブオーダー配信を被ることができます。これは、エミュレートされたサービスの作業条件に影響を与えることができます。いくつかのペイロードタイプ、パケット損失、破損、及びアウトオブオーダーの送達のためのビット誤りバーストに、またはPW上のキャリアの損失のいずれかにマッピングすることができます。ネイティブサービスは、ビットエラーに対処するためのいくつかのメカニズムを持っている場合は、該当するPWE3サービスは、同様のメカニズムを提供する必要があります。
A PWE3 approach may provide a mechanism for other status notifications, if any are needed.
いずれかが必要な場合はPWE3アプローチは、他のステータス通知するためのメカニズムを提供することができます。
The status of a group of emulated services may be affected identically by a single network incident. For example, when the physical link (or sub-network) between a CE and a PE fails, all the emulated services that go through that link (or sub-network) will fail. It is likely that a group of emulated services all terminate at a remote CE. There may also be multiple such CEs affected by the failure. Therefore, it is desirable that a single notification message be used to notify failure of the whole group of emulated services.
エミュレートされたサービスのグループの状態は、単一のネットワーク入射によって同様に影響を受ける可能性があります。例えば、CEおよびPE間の物理リンク（またはサブネットワーク）が失敗した場合、そのリンク（またはサブネットワーク）を通過するすべてのエミュレートされたサービスが失敗します。エミュレートされたサービスのグループは、すべてのリモートCEで終了する可能性が高いです。また、障害の影響を受けたような複数のCEがあるかもしれません。したがって、単一の通知メッセージがエミュレートされたサービスのグループ全体の故障を通知するために使用することが望ましいです。
A PWE3 approach may provide a mechanism for notifying status changes of a group of emulated circuits. One possible method is to associate each emulated service with a group ID when the PW for that emulated service is set up. Multiple emulated services can then be grouped by associating them with the same group ID. In status notification, this group ID can be used to refer all the emulated services in that group. The group ID mechanism should be a mechanism provided by the underlying tunnel signaling protocol.
PWE3アプローチは、エミュレートされた回路のグループの状態変化を通知するためのメカニズムを提供することができます。一つの可能な方法は、エミュレートされたサービスのためのPWがセットアップされるとき、グループIDと各エミュレートされたサービスを関連付けることです。複数のエミュレートされたサービスは、同じグループIDを関連付けてグループ化することができます。ステータス通知では、このグループIDは、そのグループ内のすべてのエミュレートのサービスを参照するために使用することができます。グループIDメカニズムは、基礎となるトンネルシグナリングプロトコルによって提供されるメカニズムであるべきです。
If a native service has a keep-alive mechanism, the corresponding emulated service must provide a mechanism to propagate it across the PW. Transparently transporting keep-alive messages over the PW would follow the principle of minimum intervention. However, to reproduce the semantics of the native mechanism accurately, some PWs may require an alternative approach, such as piggy-backing on the PW signaling mechanism.
ネイティブサービスは、キープアライブメカニズムを持っている場合は、対応するエミュレートされたサービスは、PW全体に伝播するメカニズムを提供しなければなりません。透過的PWの上にキープアライブメッセージを輸送することは最低限の介入の原則に従います。しかし、正確ネイティブ機構の意味を再現するために、いくつかのPWは、PWシグナリング機構にピギーバッキングのように、別のアプローチを必要とし得ます。
Some native services use control messages for circuit maintenance. These control messages may be in-band (e.g., Ethernet flow control, ATM performance management, or TDM tone signaling) or out-of-band, (e.g., the signaling VC of an ATM VP, or TDM CCS signaling).
いくつかのネイティブサービスは、回路のメンテナンスのための制御メッセージを使用します。これらの制御メッセージは、（ATM VP、またはTDM CCSシグナリングのシグナリングVC、例えば）、帯域内（例えば、イーサネット（登録商標）フロー制御、ATMパフォーマンス管理、またはTDMトーンシグナリング）またはアウトオブバンドであってもよいです。
Given the principle of minimum intervention, it is desirable that the PEs participate as little as possible in the signaling and maintenance of the native services. This principle should not, however, override the need to emulate the native service satisfactorily.
最小介入の原則を考えると、PEがネイティブサービスのシグナリングおよびメンテナンスにできるだけ参加することが望ましいです。この原則は、しかし、十分ネイティブサービスをエミュレートする必要性をオーバーライドするべきではありません。
If control messages are passed through, it may be desirable to send them by using either a higher priority or a reliable channel provided by the PW Demultiplexer layer. See Section 5.1.2, PWE3 Channel Types.
制御メッセージが通過している場合、高い優先度やPWデマルチプレクサ層により提供される信頼性の高いチャネルのいずれかを使用してそれらを送信することが望ましい場合があります。セクション5.1.2、PWE3チャネルタイプを参照してください。
This section describes the management and monitoring architecture for PWE3.
このセクションでは、PWE3のための管理と監視のアーキテクチャについて説明します。
The PE should report the status of the interface and tabulate statistics that help monitor the state of the network and help measure service-level agreements (SLAs). Typical counters include the following:
PEは、インターフェイスのステータスを報告し、ネットワークの状態を監視し、測定サービスレベル契約（SLA）を助ける助ける統計を集計する必要があります。典型的なカウンタは次のものがあります。
o Counts of PW-PDUs sent and received, with and without errors.
o Counts of sequenced PW-PDUs lost.
o Counts of service PDUs sent and received over the PSN, with and
without errors (non-TDM).
o Service-specific interface counts.
o One-way delay and delay variation.
These counters would be contained in a PW-specific MIB, and they should not replicate existing MIB counters.
これらのカウンタはPW-固有のMIBに含まれることになる、と彼らは既存のMIBカウンターを複製してはなりません。
This section describes the general architecture for SNMP MIBs used to manage PW services and the underlying PSN. The intent here is to provide a clear picture of how all the pertinent MIBs fit together to form a cohesive management framework for deploying PWE3 services. Note that the names of MIB modules used below are suggestions and do not necessarily require that the actual modules used to realize the components in the architecture be named exactly so.
このセクションでは、PWサービスと基本的なPSNを管理するために使用されるSNMP MIBのための一般的なアーキテクチャについて説明します。ここでの意図は、すべての適切なMIBがPWE3サービスを展開するための粘着性の管理フレームワークを形成するために一緒に収まる方法の明確なイメージを提供することです。以下で使用するMIBモジュールの名前は提案であり、必ずしもアーキテクチャのコンポーネントを実現するために使用される実際のモジュールが正確にそのように命名されることを必要としないことに注意してください。
The SNMP MIBs created for PWE3 should fit the architecture shown in Figure 12. The architecture provides a layered modular model into which any supported emulated service can be connected to any supported PSN type. This model fosters reuse of as much functionality as possible. For instance, the emulated service layer MIB modules do not redefine the existing emulated service MIB module; rather, they only associate it with the pseudo wires used to carry the emulated service over the configured PSN. In this way, the PWE3 MIB architecture follows the overall PWE3 architecture.
PWE3のために作成SNMP MIBは、図12のアーキテクチャは、任意のサポートされているエミュレートサービスがサポートされている任意のPSNタイプに接続することが可能に層状モジュラーモデルを提供するに示すアーキテクチャに適合しなければなりません。このモデルは、できるだけ多くの機能の再利用を促進します。たとえば、エミュレートされたサービス層のMIBモジュールは、既存のエミュレートされたサービスMIBモジュールを再定義していません。むしろ、彼らは構成PSN上にエミュレートされたサービスを運ぶために使用される擬似ワイヤに関連付け。このように、PWE3 MIBアーキテクチャは、全体的なPWE3アーキテクチャに従っています。
The architecture does allow for the joining of unsupported emulated service or PSN types by simply defining additional MIB modules to associate new types with existing ones. These new modules can subsequently be standardized. Note that there is a separate MIB module for each emulated service, as well as one for each underlying PSN. These MIB modules may be used in various combinations as needed.
アーキテクチャは、単に既存のものと新しいタイプを関連付けるために、追加のMIBモジュールを定義することによって、サポートされていないエミュレートされたサービスやPSNタイプの接合を可能ありません。これらの新しいモジュールは、その後に標準化することができます。別MIBの各エミュレートされたサービスのためのモジュール、ならびに各基礎となるPSNのための1つが存在することに留意されたいです。必要に応じて、これらのMIBモジュールは、様々な組み合わせで使用することができます。
Native
Service MIBs ... ... ...
| | |
+-----------+ +-----------+ +-----------+
Service | CEP | | Ethernet | | ATM |
Layer |Service MIB| |Service MIB| ... |Service MIB|
+-----------+ +-----------+ +-----------+
\ | /
\ | /
- - - - - - - - - - - - \ - - - | - - - - / - - - - - - -
\ | /
+-------------------------------------------+
Generic PW | Generic PW MIBs |
Layer +-------------------------------------------+
/ \
- - - - - - - - - - - - / - - - - - - - - \ - - - - - - -
/ \
/ \
+--------------+ +----------------+
PSN VC |L2TP VC MIB(s)| | MPLS VC MIB(s) |
Layer +--------------+ +----------------+
| |
Native +-----------+ +-----------+
PSN |L2TP MIB(s)| |MPLS MIB(s)|
MIBs +-----------+ +-----------+
Figure 12. MIB Module Layering Relationship
図12. MIBモジュールの階層化の関係
Figure 13 shows an example for a SONET PW carried over MPLS Traffic Engineering Tunnel and an LDP-signaled LSP.
図13は、SONET PWは、MPLSトラフィックエンジニアリングトンネルとLDP-LSPシグナリングを介して搬送するための一例を示しています。
+-----------------+
| SONET MIB | RFC3592
+-----------------+
|
+------------------------------+
Service | Circuit Emulation Service MIB|
Layer +------------------------------+
- - - - - - - - - - - - - | - - - - - - - - - - - - -
+-----------------+
Generic PW | Generic PW MIB |
Layer +-----------------+
- - - - - - - - - - - - - | - - - - - - - - - - - - -
+-----------------+
PSN VC | MPLS VC MIBs |
Layer +-----------------+
| |
+-----------------+ +------------------+
| MPLS-TE-STD-MIB | | MPLS-LSR-STD-MIB |
+-----------------+ +------------------+
Figure 13. SONET PW over MPLS PSN Service-Specific Example
MPLS PSNサービス固有オーバー図13 SONET PW例
This conceptual layer in the model contains MIB modules used to represent the relationship between emulated PWE3 services such as Ethernet, ATM, or Frame Relay and the pseudo-wire used to carry that service across the PSN. This layer contains corresponding MIB modules used to mate or adapt those emulated services to the generic pseudo-wire representation these are represented in the "Generic PW MIB" functional block in Figure 13 above. This working group should not produce any MIB modules for managing the general service; rather, it should produce just those modules used to interface or adapt the emulated service onto the PWE3 management framework as shown above. For example, the standard SONET-MIB [RFC3592] is designed and maintained by another working group. The SONET-MIB is designed to manage the native service without PW emulation. However, the PWE3 working group is chartered to produce standards that show how to emulate existing technologies such as SONET/SDH over pseudo-wires rather than reinvent those modules.
モデルでは、この概念の層は、エミュレートされ、イーサネット（登録商標）、ATM、またはフレームリレーなどPWE3サービスとPSNを横切るそのサービスを運ぶために使用される疑似ワイヤとの間の関係を表すために使用されるMIBモジュールを含んでいます。この層は、これらは、上記図13の「汎用PW MIB」機能ブロックで表されている一般的な擬似ワイヤ表現にそれらのエミュレートされたサービスを嵌合または適合させるために使用される対応するMIBモジュールを含んでいます。このワーキンググループは、一般的なサービスを管理するための任意のMIBモジュールを生成してはなりません。むしろ、それはインターフェースまたは上記のようにPWE3管理フレームワーク上にエミュレートされたサービスを適応させるために使用されるだけで、これらのモジュールを生成しなければなりません。例えば、標準のSONET-MIB [RFC3592]は、別のワーキンググループによって設計され、維持されます。 SONET-MIBは、PWエミュレーションなしでネイティブサービスを管理するように設計されています。しかし、PWE3ワーキンググループは、擬似ワイヤオーバーSONET / SDHのように既存の技術をエミュレートするのではなく、それらのモジュールを改革する方法を示す基準を生成するためにチャーターされています。
The middle layer in the architecture is referred to as the Generic PW Layer. MIBs in this layer are responsible for providing pseudo-wire specific counters and service models used for monitoring and configuration of PWE3 services over any supported PSN service. That is, this layer provides a general model of PWE3 abstraction for management purposes. This MIB is used to interconnect the MIB modules residing in the Service Layer to the PSN VC Layer MIBs (see section 8.2.4).
アーキテクチャの中間層は、一般的なPW層と呼ばれます。この層でのMIBがサポートされている任意のPSNのサービスを介してPWE3サービスの監視と設定に使用疑似ワイヤー固有のカウンターやサービスモデルを提供する責任があります。つまり、この層は、管理目的のためにPWE3抽象化の一般的なモデルを提供します。このMIBは、PSN VCレイヤのMIBへのサービス層に存在するMIBモジュールを相互接続するために使用される（セクション8.2.4を参照してください）。
The third layer in the PWE3 management architecture is referred to as the PSN VC Layer. It is composed of MIBs that are specifically designed to associate pseudo-wires onto those underlying PSN transport technologies that carry the pseudo-wire payloads across the PSN. In general, this means that the MIB module provides a mapping between the emulated service that is mapped to the pseudo-wire via the Service Layer and the Generic PW MIB Layer onto the native PSN service. For example, in the case of MPLS, for example, it is required that the general VC service be mapped into MPLS LSPs via the MPLS-LSR-STD-MIB [RFC3813] or Traffic-Engineered (TE) Tunnels via the MPLS-TE-STD-MIB [RFC3812]. In addition, the MPLS-LDP-STD-MIB [RFC3815] may be used to reveal the MPLS labels that are distributed over the MPLS PSN in order to maintain the PW service. As with the native service MIB modules described earlier, the MIB modules used to manage the native PSN services are produced by other working groups that design and specify the native PSN services. These MIBs should contain the appropriate mechanisms for monitoring and configuring the PSN service that the emulated PWE3 service will function correctly.
PWE3管理アーキテクチャの第3層がPSN VC層と呼ばれます。これは特に、PSNを横切って擬似ワイヤペイロードを運ぶそれらの基礎となるPSN輸送技術に擬似ワイヤを関連付けるように設計されたMIBから構成されています。一般に、これは、MIBモジュールは、サービス層とネイティブPSNサービスへの一般的なPW MIB層を介して擬似ワイヤにマッピングされ、エミュレートサービスとの間のマッピングを提供することを意味します。例えば、MPLSの場合には、例えば、一般的なVCサービスを介したMPLSのLSPにマッピングする必要があるMPLS-LSR-STD-MIB [RFC3813]またはトラフィック・エンジニア（TE）MPLS-TEを介してトンネル-std-MIB [RFC3812]。加えて、MPLS-LDP-STD-MIB [RFC3815]はPWサービスを維持するためにMPLS PSNの上に分配されるMPLSラベルを明らかにするために使用することができます。前述のネイティブサービスMIBモジュールと同様に、ネイティブのPSNのサービスを管理するために使用されるMIBモジュールは、ネイティブのPSNのサービスを指定して設計し、他のワーキンググループによって製造されています。これらのMIBは、エミュレートPWE3サービスが正しく機能しますPSNのサービスを監視し、設定するための適切なメカニズムが含まれている必要があります。
A connection verification mechanism should be supported by PWs. Connection verification and other alarm mechanisms can alert the operator that a PW has lost its remote connection. The opaque nature of a PW means that it is not possible to specify a generic connection verification or traceroute mechanism that passes this status to the CEs over the PW. If connection verification status of the PW is needed by the CE, it must be mapped to the native connection status method.
接続検証メカニズムはPWをによってサポートされる必要があります。接続検証や他の警報メカニズムはPWがリモート接続を失ったことをオペレータに警告することができます。 PWの不透明な性質は、PWの上にCEにこの状態を渡し、一般的な接続検証やtracerouteのメカニズムを指定することはできないことを意味します。 PWの接続検証ステータスがCEで必要とされている場合は、ネイティブ接続状態メソッドにマッピングする必要があります。
For troubleshooting purposes, it is sometimes desirable to know the exact functional path of a PW between PEs. This is provided by the traceroute service of the underlying PSN. The opaque nature of the PW means that this traceroute information is only available within the provider network; e.g., at the PEs.
トラブルシューティングの目的のために、PE間のPWの正確な機能的経路を知ることが望ましい場合があります。これは、基礎となるPSNのtracerouteのサービスによって提供されます。 PWの不透明な性質は、このトレースルート情報は、プロバイダ・ネットワーク内でのみ使用可能であることを意味します。例えば、のPEで。
IANA considerations will be identified in the PWE3 documents that define the PWE3 encapsulation, control, and management protocols.
IANAの考慮はPWE3カプセル化、制御、および管理プロトコルを定義PWE3ドキュメントで識別されます。
PWE3 provides no means of protecting the integrity, confidentiality, or delivery of the native data units. The use of PWE3 can therefore expose a particular environment to additional security threats. Assumptions that might be appropriate when all communicating systems are interconnected via a point-to-point or circuit-switched network may no longer hold when they are interconnected with an emulated wire carried over some types of PSN. It is outside the scope of this specification to fully analyze and review the risks of PWE3, particularly as these risks will depend on the PSN. An example should make the concern clear. A number of IETF standards employ relatively weak security mechanisms when communicating nodes are expected to be connected to the same local area network. The Virtual Router Redundancy Protocol [RFC3768] is one instance. The relatively weak security mechanisms represent a greater vulnerability in an emulated Ethernet connected via a PW.
PWE3は、ネイティブ・データ・ユニットの完全性、機密性、または送達保護のない手段を提供しません。 PWE3の使用は、したがって、追加のセキュリティ脅威に特定の環境を公開することができます。全ての通信システムを介して互いに接続されている場合に適切であるかもしれない仮定のポイントツーポイントまたはそれらはPSNのいくつかのタイプを介して搬送されるエミュレートされたワイヤと相互接続されたとき、もはや保持しない可能性が回線交換網。これは、これらのリスクがPSNに依存し、特にとして、完全にPWE3のリスクを分析し、確認するために、この仕様書の範囲外です。例では、懸念を明確にする必要があります。 IETF規格の数は、通信ノードが同じローカルエリアネットワークに接続されることが予想される比較的弱いセキュリティメカニズムを使用します。仮想ルータ冗長プロトコル[RFC3768]は1つのインスタンスです。比較的弱いセキュリティメカニズムはPWを介して接続されたエミュレートされたイーサネット（登録商標）においてより大きな脆弱性を表します。
Exploitation of vulnerabilities from within the PSN may be directed to the PW Tunnel end point so that PW Demultiplexer and PSN tunnel services are disrupted. Controlling PSN access to the PW Tunnel end point is one way to protect against this. By restricting PW Tunnel end point access to legitimate remote PE sources of traffic, the PE may reject traffic that would interfere with the PW Demultiplexing and PSN tunnel services.
PSN内の脆弱性の悪用は、PWデマルチプレクサとPSNトンネルサービスが中断されるように、PWトンネルエンドポイントに向けることができます。 PWトンネルエンドポイントへのPSNへのアクセスを制御することは、この保護するための一つの方法です。トラフィックの正当リモートPEソースへPWトンネルエンドポイントへのアクセスを制限することにより、PEはPW逆多重化とPSNトンネルサービスを妨害するトラフィックを拒否することができます。
Protection mechanisms must 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] may be used by the PW Demultiplexer Layer in order provide authentication and data integrity of the data between the PW Demultiplexer End-points.
保護メカニズムはまた、トンネリングPWデータのなりすましに対処しなければなりません。トラフィックの検証は、PWデマルチプレクサのエンドポイントに宛てPWカプセル化の整合性を確保する上で非常に重要です。そのようなIPSecの[RFC2401]などのセキュリティプロトコルは、PWデマルチプレクサエンドポイント間のデータの認証およびデータ保全性を提供するためにPWデマルチプレクサレイヤによって使用されてもよいです。
IPSec may provide authentication, integrity, and confidentiality, of data transferred between two PEs. It cannot provide the equivalent services to the native service.
IPSecは2つのPE間で転送されるデータの認証、整合性、および機密性を提供することができます。これは、ネイティブのサービスと同等のサービスを提供することはできません。
Based on the type of data being transferred, the PW may indicate to the PW Demultiplexer Layer that enhanced security services are required. The PW Demultiplexer Layer may define multiple protection profiles based on the requirements of the PW emulated service. CE-to-CE signaling and control events emulated by the PW and some data types may require additional protection mechanisms. Alternatively, the PW Demultiplexer Layer may use peer authentication for every PSN packet to prevent spoofed native data units from being sent to the destination CE.
転送されるデータの種類に基づいて、PWは、強化されたセキュリティサービスが必要とされているPWデマルチプレクサレイヤに示すことができます。 PWデマルチプレクサレイヤはPWエミュレートされたサービスの要件に基づいて複数の保護プロファイルを定義することもできます。 PWおよび一部のデータ型によってエミュレートCEツーCEシグナリングおよび制御イベントは、追加の保護メカニズムを必要とし得ます。あるいは、PWデマルチプレクサレイヤは、宛先CEに送信され、スプーフィングされたネイティブ・データ・ユニットを防止するために、すべてのPSNパケットのピア認証を使用することができます。
The unlimited transformation capability of the NSP may be perceived as a security risk. In practice the type of operation that the NSP may perform will be limited to those that have been implemented in the data path. A PE designed and managed to best current practice will have controls in place that protect and validate its configuration, and these will be sufficient to ensure that the NSP behaves as expected.
NSPの無制限の変換機能は、セキュリティ上のリスクとして認識することができます。実際には、NSPが実行できる操作の種類は、データパスに実装されたものに限定されます。現在のベストプラクティスに設計され、管理PEは保護し、その構成を検証場所にコントロールを持つことになり、これらは予想通りNSPが動作することを保証するのに十分であろう。
We thank Sasha Vainshtein for his work on Native Service Processing and advice on bit stream over PW services and Thomas K. Johnson for his work on the background and motivation for PWs.
私たちは、PWのための背景や動機上の彼の仕事のためのネイティブサービス処理とPWサービス上のビットストリーム上のアドバイスやトーマス・K.ジョンソン上の彼の仕事のためにサーシャVainshteinに感謝します。
We also thank Ron Bonica, Stephen Casner, Durai Chinnaiah, Jayakumar Jayakumar, Ghassem Koleyni, Danny McPherson, Eric Rosen, John Rutemiller, Scott Wainner, and David Zelig for their comments and contributions.
我々はまた、彼らのコメントと貢献のためにロンBonica、スティーブンCasner、Durai Chinnaiah、Jayakumar Jayakumar、Ghassem Koleyni、ダニー・マクファーソン、エリック・ローゼン、ジョンRutemiller、スコット・ワイナー、およびデビッド・カメレオンマンに感謝します。
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3), RFC 3931, March 2005.
[RFC3931]ラウ、J.、Townsley、M.、およびI. Goyret、「レイヤ2トンネリングプロトコル - バージョン3（L2TPv3の）、RFC 3931、2005年3月。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC768]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[RFC3592] Tesink, K., "Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Type", RFC 3592, September 2003.
[RFC3592] Tesink、K.、RFC 3592、2003年9月 "同期光ネットワーク/同期デジタル階層（SONET / SDH）インタフェースタイプのための管理オブジェクトの定義"。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2661] Townsley、W.、バレンシア、A.、ルーベンス、A.、ポール、G.、ツォルン、G.、およびB. Palter、 "レイヤ2トンネリングプロトコル "L2TP""、RFC 2661、1999年8月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、D.、およびP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 2784、2000年3月。
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000.
[RFC2890] Dommety、G.、 "GREのキーと一連番号拡大"、RFC 2890、2000年9月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、 "MPLSラベルスタックエンコーディング"、RFC 3032、2001年1月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[DVB] EN 300 744 Digital Video Broadcasting (DVB); Framing structure, channel coding and modulation for digital terrestrial television (DVB-T), European Telecommunications Standards Institute (ETSI).
[DVB] EN 300 744デジタルビデオ放送（DVB）。地上デジタルテレビジョン（DVB-T）、欧州電気通信標準化協会（ETSI）のフレーミング構造、チャネル符号化及び変調。
[RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June 2004.
[RFC3815] Cucchiara、J.、Sjostrand、H.、およびJ.ルチアーニは、 "マルチプロトコルラベルのための管理オブジェクトの定義は、スイッチング（MPLS）、ラベル配布プロトコル（LDP）"、RFC 3815、2004年6月。
[RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004.
[RFC3813]スリニバサン、C.、Viswanathanの、A.、およびT.ナドーは、 "マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチングルータ（LSR）管理情報ベース（MIB）"、RFC 3813、2004年6月。
[MPLSIP] Rosen et al, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", Work in Progress, March 2004.
[MPLSIP]ローゼンら、「IPまたは総称ルーティングカプセル化（GRE）でカプセル化MPLS」、進歩、2004年3月での作業。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]大工、B.、 "インターネットの建築原則"、RFC 1958、1996年6月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]マッキャン、J.、デアリング、S.、およびJ.ムガール人、RFC 1981、1996年8月 "IPバージョン6のパスMTUディスカバリー"。
[RFC2022] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, November 1996.
[RFC2022]アーミテージ、G.、RFC 2022、1996年11月 "ATM網をベースUNI 3.0 / 3.1以上のマルチキャストのサポート"。
[RFC3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", RFC 3768, April 2004.
[RFC3768] HindenとR.、 "仮想ルータ冗長プロトコル（VRRP）"、RFC 3768、2004年4月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022] Srisuresh、P.とK. Egevang、 "伝統的なIPネットワークアドレス変換（NAT繁体字）"、RFC 3022、2001年1月。
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[RFC3448]ハンドレー、M.、フロイド、S.、Padhye、J.、およびJ.ウィトマー、 "TCPフレンドリーレート制御（TFRC）：プロトコル仕様"、RFC 3448、2003年1月。
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
[RFC3812]スリニバサン、C.、Viswanathanの、A.、およびT.ナドー、 "マルチプロトコルラベルスイッチング（MPLS）トラフィックエンジニアリング（TE）管理情報ベース（MIB）"、RFC 3812、2004年6月。
[RFC3916] Xiao, X., McPherson, D., and P. Pate, Eds, "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004.
[RFC3916]シャオ、X.、マクファーソン、D.、およびP.パテ、編、 "疑似ワイヤー・エミュレーション・エッジ・ツー・エッジ（PWE3）の要件"、RFC 3916、2004年9月。
The following are co-authors of this document:
このドキュメントの共著者は次のとおりです。
Thomas K. Johnson Litchfield Communications
トーマス・K.ジョンソンリッチフィールドコミュニケーションズ
Kireeti Kompella Juniper Networks, Inc.
Kireeti Kompellaジュニパーネットワークス株式会社
Andrew G. Malis Tellabs
アンドリューG. Malisテラブス
Thomas D. Nadeau Cisco Systems
トーマスD.ナドーシスコシステムズ
Tricci So Caspian Networks
Tricciだから、カスピアン・ネットワーク
W. Mark Townsley Cisco Systems
W.マークTownsleyシスコシステムズ
Craig White Level 3 Communications, LLC.
クレイグ・ホワイトレベル3コミュニケーションズ、LLC。
Lloyd Wood Cisco Systems
ロイド・ウッドシスコシステムズ
Stewart Bryant Cisco Systems 250, Longwater Green Park Reading, RG2 6GB, United Kingdom
スチュワートブライアントシスコシステムズ250、Longwaterグリーンパーク読書、RG2 6ギガバイト、イギリス
EMail: stbryant@cisco.com
メールアドレス：stbryant@cisco.com
Prayson Pate Overture Networks, Inc. 507 Airport Boulevard Morrisville, NC, USA 27560
Praysonパテ序曲ネットワークス株式会社507空港大通りモリスビル、NC、USA 27560
EMail: prayson.pate@overturenetworks.com
メールアドレス：prayson.pate@overturenetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。