[要約] RFC 3985は、Pseudo Wire Emulation Edge-to-Edge（PWE3）アーキテクチャに関する標準化ドキュメントです。その目的は、異なるネットワーク間で仮想的な回線をエミュレートするためのフレームワークを提供することです。
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
擬似ワイヤ エミュレーション エッジツーエッジ (PWE3) アーキテクチャ
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (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を使用して、パケットスイッチネットワーク（PSNS）を介して、フレームリレー、ATM、イーサネット、TDM、SONET/SDHなどのサービスのエミュレーションについて説明します。擬似ワイヤ（PWS）のアーキテクチャフレームワークを提示し、用語を定義し、さまざまなプロトコル要素とその機能を指定します。
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.
この文書は、[RFC3916] をサポートする擬似ワイヤ エミュレーション エッジツーエッジ (PWE3) のアーキテクチャについて説明します。IP または MPLS を使用したパケット交換ネットワーク (PSN) 上のフレーム リレー、ATM、イーサネット、TDM、SONET/SDH などのサービスのエミュレーションについて説明します。これは、疑似ワイヤ (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.
PWSの必要な機能には、サービス固有のビットストリーム、セル、または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.
PW は、ネイティブ サービスの動作と特性をエミュレートするために、次の機能を提供します。
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.
o PEバインドポート（論理または物理）に到着するサービス固有のPDUまたは回路データのカプセル化。o PSNトンネルを横切るカプセル化されたデータのキャリッジ。o PSNトンネルエンドポイントで使用されるPW識別子の交換および/または分布を含むPWの確立。o PWの境界でのサービスのシグナル、タイミング、順序、またはその他の側面の管理。oサービス固有のステータスとアラーム管理。
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.
o PW カプセル化のオンザワイヤ仕様。o PW のセットアップとメンテナンスに関連するプロトコルの詳細な定義。
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".
接続回線 CE を PE に接続 (AC) する物理回線または仮想回線。接続回路は、たとえば、フレーム リレー DLCI、ATM VPI/VCI、イーサネット ポート、VLAN、物理インターフェイス上の PPP 接続、L2TP トンネルからの PPP セッション、または MPLS LSP などです。物理 AC と仮想 AC の両方が同じテクノロジー (たとえば、両方の 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.)
ネイティブ サービス コアを介して送信するために PW に提示する前に CE から PE 処理 (NSP) によって受信されたデータの処理、または AC に出力される前に PE によって PW から受信されたデータの処理。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.
PEバウンドCEからの情報がPWに適合し、PW-PDUがPSNに送信されるトラフィック方向をPEバウンドします。
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.
PESがPWをセットアップ、維持、削減するために使用するPE/PWのメンテナンス。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）PWE3をCEに提供するデバイス。
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.
PSEUDOワイヤ（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 目的のサービスをエミュレートするために必要なデータと制御情報のすべて (PW-PDU) を含む、PW 上で送信される PDU。
PSN Tunnel A tunnel across a PSN, inside which one or more PWs can be carried.
PSN トンネル PSN を横切るトンネル。内部で 1 つ以上の PW を伝送できます。
PSN Tunnel Used to set up, maintain, and tear down the
Signaling underlying PSN tunnel.
PW Demultiplexer Data-plane method of identifying a PW terminating at a PE.
PW デマルチプレクサ PE で終端する 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 実装) の感度と、それらをマスクするアダプテーション層の能力に依存します。IP over FR over PWE3 などの一部のサービスは、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の違いを最小限に抑えることを目的としています。プロトコルレイアリングモデルの設計には、各PW定義を基礎となるPSNとは独立させ、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.
ペイロードは、カプセル化層の上に輸送されます。カプセル化レイヤーには、PW CEバウンドPEインターフェイスが必要とするペイロード自体内にまだ存在していない情報が、物理インターフェイスを介してペイロードをCEに送信します。ペイロード自体にそれ以上の情報が必要ない場合、このレイヤーは空です。
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 Demultiplexerレイヤーは、単一のPSNトンネルを介して複数のPWを提供する機能を提供します。データプレーンのPWを識別するために使用されるPW Demultiplexer値は、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 サービス要件に適合させるために必要な機能強化を提供します。したがって、この層は PW に一貫したインターフェイスを提供し、PW を PSN タイプから独立させます。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 Demultiplexerレイヤーへのインターフェイスを定義します。他の層は、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
o パケットOセルOビットストリームo構造化ビットストリーム
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.
状況によっては、パケットペイロードは、いくつかのサブマルチプレックス技術に基づいて、エミュレートされたワイヤに表示されるパケットから選択される場合があります。たとえば、フレームリレーデータリンク接続識別子（DLCI）、またはイーサネットペイロードの場合、適切なMACブリッジフィルターを使用して、特定の擬似ワイヤを介して輸送するために、1つ以上のフレームリレーPDUを選択できます。これはフォワーダー関数であるため、この選択はパケットが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].
セルペイロードは、固定サイズの形式でワイヤに表示されたオクテットのグループをキャプチャ、輸送、およびリプレイすることによって作成されます。セルを構成するビットのグループの描写は、カプセル化タイプに固有です。細胞ペイロードの2つの一般的な例は、ATM 53-OCTETセルと、より大きな188-OCTET 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:
構造化ビット ストリームと非構造化ビット ストリームを区別する 2 つの重要な点があります。
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 元のビットストリームの一部は、NSPブロックによってPSNバインド方向に剥がすことができます。たとえば、構造化されたソネットでは、セクションとラインのオーバーヘッド（およびおそらくそれ以上）が剥がされる場合があります。そのようなストリッピングを有効にするためにフレーマーが必要です。また、分数T1/E1アプリケーションのフレーム/ペイロードアライメントにも必要です。
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.
o PWは、CEバウンドNSPブロックが再構築された非構造化ビットストリームに正しく挿入できるように、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) は、クライアント CE (CE1 と CE2) が PSN 経由で通信できるようにするために、クライアント CE (CE1 と CE2) に代わって 1 つ以上の 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
図 3. PWE3 ネットワーク参照モデル内の前処理
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がプレップ機能を含むシステムの動作もサポートされています。
The required pre-processing can be divided into two components:
必要な前処理は、2つのコンポーネントに分けることができます。
o Forwarder (FWRD) o Native Service Processing (NSP)
o フォワーダー（FWRD）oネイティブサービス処理（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.
一部のアプリケーションでは、1つ以上のACSから1つ以上のPWに選択的にペイロード要素を転送する必要があります。そのような場合、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.
フォワーダーは、たとえば、受信 AC、ペイロードの内容、または静的および/または動的に構成された転送情報に基づいて PW を選択します。
+----------------------------------------+
| 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。複数のACから複数のPW転送
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 は、ある種のフィルタリング操作を実行する単純なフォワーダーを示しています。フォワーダーには 1 つの入力インターフェイスと 1 つの出力インターフェイスがあるため、適用される転送操作の種類はフィルタリングのみです。図 4b は、ペイロードが 1 つまたは複数の AC から抽出され、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
図 5. 複数の AC から複数の PW への転送 PE 内の 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 間の関係を示しています。NSP 機能は、ペイロードが CE への物理インターフェイスとフォワーダーへの仮想インターフェイスの間を通過するときに、ペイロードに任意の変換操作 (変更、挿入など) を適用できます。もちろん、これらの変換操作は、データ パスに実装されており、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 CE（エンドツーエンド）シグナル伝達はCESの間にあります。このシグナル伝達は、フレームリレーPVCステータスシグナル伝達、ATM SVCシグナル伝達、TDM CASシグナル伝達などです。
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のメンテナンスは、PES（またはNSP）の間で使用され、パラメーターの必要な調整を含むPWSをセットアップ、維持、および取り壊します。
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 カプセル化層は、PW を介して転送される特定のペイロード タイプを、PSN を介して PW を搬送するために使用される PW デマルチプレクサ層に適合させるために必要なインフラストラクチャを提供します。
The PW Encapsulation Layer consists of three sub-layers:
PWカプセル化レイヤーは、3つのサブレイヤーで構成されています。
o Payload Convergence o Timing o Sequencing
o ペイロード収束oタイミングoシーケンス
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-PDUSのペイロードのカプセル化です。カプセル化されるネイティブデータユニットには、L2ヘッダーまたはL1オーバーヘッドが含まれている場合があります。これはサービス固有です。ペイロードコンバージェンスヘッダーには、CEに縛られた物理インターフェイスでネイティブデータユニットを再生するために必要な追加情報が搭載されています。PW Demultiplexerヘッダーは、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 つ以上必要です (チャネル タイプ 1 とチャネル タイプ 2 ～ 4 の 1 つ以上)。
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. シグナリングラインイベント、ステータス表示、および例外的な場合、PES間で確実に送信する必要がある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 間シグナリングです。「高優先度」は、IP の場合は DSCP ビット、MPLS の場合は EXP ビットを介して単に示され、送信中にパケットに優先順位が与えられます。このチャネル タイプは、トンネル ヘッダー自体のビットを使用して、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. パケットの並べ替えに敏感なデータトラフィックのシーケンスされたチャネル（使用のための1つの分類は、IP以外のトラフィックの場合があります）。
4. An unsequenced channel for data traffic insensitive to packet order.
4. パケットの順序に影響されない、データ トラフィック用の順序のないチャネル。
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.
データチャネル（上記の2、3、および4）は、PSNで合理的に可能な限り、互いに「バンド」で「バンド」を掲載する必要があります。
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をセットアップできる場合があり、PWデータトラフィックは1つでブロックされます。またはこれらのメカニズムの多く。これらの場合、制御チャネルが「バンドで」運ばれない限り、PWを設定するためのシグナルは、エンドツーエンドのデータパスの存在を確認しません。場合によっては、CEイベントをPWを介して運ばれたデータと同期する必要があります。これは特にTDM回路の場合です（たとえば、PSTNスイッチのオンフック/オフフックイベントは、信頼できる制御チャネルに掲載される可能性がありますが、関連するビットストリームはシーケンスされたデータチャネルに掲載されます）。
PWE3 channel types that are not needed by the supported PWs need not be included in such an implementation.
サポートされているPWSに必要でないPWE3チャネルタイプは、このような実装に含める必要はありません。
Where possible, it is desirable to employ mechanisms to provide PW Quality of Service (QoS) support over PSNs.
可能であれば、PSN 上で PW サービス品質 (QoS) サポートを提供するメカニズムを採用することが望ましいです。
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.
2つの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プロトコルを使用してこれらのサービスを提供する必要があるということです。適切なプロトコルが利用できない場合、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-PDUSを運ぶパケットはPSNをトラバースする場合、宛先PEで故障して到着する場合があります。一部のサービスでは、フレーム（コントロールフレーム、データフレーム、またはその両方）を適切に配信する必要があります。これらのサービスでは、注文の配信を確保するためにいくつかのメカニズムを提供する必要があります。各パケットのシーケンスサブレイヤーヘッダーにシーケンス番号を提供することは、1つの可能なアプローチです。あるいは、シーケンスは時限パケットを配信する問題のサブセットであり、[RFC3550]などの単一の組み合わせメカニズムが採用される可能性があることに注意することができます。
There are two possible misordering strategies:
2つの誤った戦略があります。
o Drop misordered PW PDUs.
o 誤った誤ったpw pdusをドロップします。
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 パケットの喪失がPWの操作にどれほど重要であるか（たとえば、許容されるビットエラー率など）、
o the speeds of the PW and PSN,
o PWとPSNの速度、
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 PATH 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で断片化を実行する必要があります。PEが独自の断片化方法を試みた場合、CEがPWの許容可能なMTUサイズに準拠できない場合のみ。
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 実装がフラグメンテーションをサポートしないことは許容されます。そうでない PE は PSN MTU を超えるパケットをドロップし、カプセル化している 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 を超える場合は、フレームをドロップする必要があります。この場合、宛先ＰＥの管理プレーンに通知されてもよい。
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
図 10. IP PSN 上の 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 DemultiplexingはPWラベルによって提供されます。PWラベルは、多くのIETFプロトコルで指定されたフォームを採用する場合があります。たとえば、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
図 11. 制御ワードを使用した MPLS PSN 上の 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 ヘッダーには長さインジケーターは含まれません。したがって、MPLS で伝送される PWE3 がイーサネット データリンク上で正しく通過できるようにするには、制御ワード内に長さ補正フィールドが必要です。IP PSN と同様に、必要に応じて、タイミングは RTP [RFC3550] によって提供されます。
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.
一部のネットワークでは、PWE3 over MPLS over IP を伝送する必要がある場合があります。このような状況では、このセクションで説明するように、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 上で PWE3 を伝送するために使用されるプロトコル層に 3 つのサービス要件を課します。
o Multiplexing o Fragmentation o Length and Delivery
o 多重化、断片化、長さと配信
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 を 1 つのトンネル内で伝送できるようにすることです。これにより、複雑さが最小限に抑えられ、リソースが節約されます。
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、物理メディアの複数のイーサネットVLAN、またはT1またはE1内の複数のDS0サービス。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 Demultiplexerとして使用される場合、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で動作している場合、PESはパケットの損失を監視して、要求されたサービスが実際に配信されていることを確認する必要があります。そうでない場合、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 フローが達成しているスループット以上の平均スループットを達成する場合、パケット損失は許容できると見なされます。この条件は、NSP にレート制限措置を実装するか、1 つ以上の PW をシャットダウンすることによって満たされます。どのアプローチを使用するかは、伝送されるトラフィックのタイプによって異なります。PW をシャットダウンすることで輻輳を回避する場合、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スループットが測定されるタイムスケールは、接続の往復時間です。本質的に、この要件は、帯域幅をarbitrarily意的に消費し、順序で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など）、または自動発見メカニズムによって、オペレーターコマンド、またはACのセットアップまたは分解によってトリガーできます。
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 は情報を交換する必要があります (たとえば、互いの機能を学習する)。トンネル シグナリング プロトコルは、PE が PW に代わって必要なすべての情報を交換できるメカニズムを提供するように拡張できます。
Manual configuration of PWs can be considered a special kind of signaling and is allowed.
PWSの手動構成は、特別な種類のシグナル伝達と見なされ、許可されます。
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 の間の物理リンクの一方または両方が稼働したままになる場合があります。たとえば、図 2 では、CE1 と PE1 の間の物理リンクに障害が発生しても、CE2 と PE2 の間の物理リンクは影響を受けず、稼働したままになります。CE2 にリモート障害が通知されない限り、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 識別子が交換されます。これは、フォワーダーと NSP によって AC の互換性を確認するために使用されます。
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 アプローチは、エミュレートされた回路のグループのステータス変更を通知するためのメカニズムを提供する可能性があります。考えられる 1 つの方法は、エミュレートされたサービスの 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 パフォーマンス管理、または TDM トーン シグナリング) または帯域外 (例: ATM VP のシグナリング VC、または TDM CCS シグナリング) の場合があります。
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 Demultiplexerレイヤーによって提供されるより高い優先度または信頼できるチャネルのいずれかを使用して、それらを送信することが望ましい場合があります。セクション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.
o エラーの有無にかかわらず、送信および受信したPW-PDUのカウント。o失われたシーケンスされたPW-PDUのカウント。oエラー（非TDM）の有無にかかわらず、PSNを介して送信および受信したサービスPDUのカウント（非TDM）。oサービス固有のインターフェイスカウント。o一元配置遅延および遅延変動。
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 モジュールが存在することに注意してください。これらの 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は、MPLSトラフィックエンジニアリングトンネルとLDP署名LSPを搭載したSONET PWの例を示しています。
+-----------------+
| 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
図 13. SONET PW over MPLS PSN サービス固有の例
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 モジュールが含まれています。この層には、エミュレートされたサービスを汎用擬似ワイヤ表現に結合または適合させるために使用される対応する MIB モジュールが含まれています。これらは、上の図 13 の「汎用 PW 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 は、サービス層に存在する MIB モジュールを PSN VC 層 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-LSR-STD-MIB [RFC3813] を介して MPLS LSP にマッピングされるか、MPLS-TE を介してトラフィック エンジニアリング (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 に渡す一般的な接続検証またはトレースルート メカニズムを指定できないことを意味します。CE が PW の接続検証ステータスを必要とする場合、ネイティブ接続ステータス メソッドにマッピングする必要があります。
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 トンネル エンド ポイントに向けられ、PW デマルチプレクサと PSN トンネル サービスが中断される可能性があります。PW トンネル エンド ポイントへの PSN アクセスを制御することは、これを防ぐ 1 つの方法です。PW トンネル エンド ポイントのアクセスを正当なリモート PE のトラフィック ソースに制限することにより、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 カプセル化の整合性を確保する上で最も重要です。PW デマルチプレクサ エンドポイント間のデータの認証とデータ整合性を提供するために、IPSec [RFC2401] などのセキュリティ プロトコルが 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 Demultiplexerレイヤーに示す場合があります。PW Demultiplexerレイヤーは、PWエミュレートサービスの要件に基づいて複数の保護プロファイルを定義する場合があります。PWと一部のデータ型によってエミュレートされたCE-CE-CE-CE-CESのシグナル伝達および制御イベントには、追加の保護メカニズムが必要になる場合があります。あるいは、PW Demultiplexerレイヤーは、PSNパケットごとにピア認証を使用して、スプーフィングされたネイティブデータユニットが宛先CEに送信されないようにする場合があります。
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 サービス上のビット ストリームに関するアドバイスについては Sasha Vainshtein 氏、PW の背景と動機に関する取り組みについては Thomas K. Johnson 氏に感謝します。
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.
また、Ron Bonica 氏、Stephen Casner 氏、Durai Chinnaiah 氏、Jayakumar Jahakumar 氏、Ghassem Koleyni 氏、Danny McPherson 氏、Eric Rosen 氏、John Rutemiller 氏、Scott Wainner 氏、David Zelig 氏のコメントと貢献にも感謝いたします。
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3), RFC 3931, March 2005.
[RFC3931] Lau, 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] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent, S. および R. Atkinson、「インターネット プロトコルのセキュリティ アーキテクチャ」、RFC 2401、1998 年 11 月。
[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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「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.、「同期光ネットワーク/同期デジタル階層 (SONET/SDH) インターフェイス タイプの管理対象オブジェクトの定義」、RFC 3592、2003 年 9 月。
[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.、Valencia, A.、Rubens, A.、Pall, G.、Zorn, 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] Farinacci, D.、Li, T.、Hanks, S.、Meyer, D.、および P. Traina、「Generic Routing Encapsulation (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] Rosen, E.、Tappan, D.、Fedorkow, G.、Rekhter, Y.、Farinacci, D.、Li, T.、および A. Conta、「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.、Frederick, R.、および V. Jacobson、「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)。欧州電気通信標準協会 (ETSI) の地上波デジタル テレビ (DVB-T) のフレーミング構造、チャネル コーディングおよび変調。
[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.、Sjostrond, H.、および J. Luciani、「マルチプロトコル ラベル スイッチング (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] Srinivasan, C.、Viswanathan, A.、および T. Nadeau、「マルチプロトコル ラベル スイッチング (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] Rosen et al、「IP または Generic Routing Encapsulation (GRE) での MPLS のカプセル化」、進行中の作業、2004 年 3 月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul, J. および S. Deering、「パス MTU 発見」、RFC 1191、1990 年 11 月。
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958] Carpenter, 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] McCann, J.、Deering, S.、および J. Mogul、「IP バージョン 6 のパス MTU 検出」、RFC 1981、1996 年 8 月。
[RFC2022] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, November 1996.
[RFC2022] Armitage, G.、「UNI 3.0/3.1 ベースの ATM ネットワーク上のマルチキャストのサポート」、RFC 2022、1996 年 11 月。
[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] Handley, M.、Floyd, S.、Padhye, J.、および J. Widmer、「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] Srinivasan, C.、Viswanathan, A.、および T. Nadeau、「マルチプロトコル ラベル スイッチング (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] Xiao, X.、McPherson, D.、および P. Pate 編、「擬似ワイヤ エミュレーション エッジツーエッジ (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・マリス・テラブス
Thomas D. Nadeau Cisco Systems
トーマス D. ナドー シスコシステムズ
Tricci So Caspian Networks
トリッチ・ソー・カスピアン・ネットワークス
W. Mark Townsley Cisco Systems Craig White Level 3 Communications, LLC.
W. マーク タウンズリー Cisco Systems Craig White Level 3 Communications, LLC.
Lloyd Wood Cisco Systems
ロイド・ウッド・シスコシステムズ
Stewart Bryant Cisco Systems 250, Longwater Green Park Reading, RG2 6GB, United Kingdom
Stewart Bryant Cisco Systems 250、ロングウォーター グリーン パーク リーディング、RG2 6GB、英国
EMail: stbryant@cisco.com
Prayson Pate Overture Networks, Inc. 507 Airport Boulevard Morrisville, NC, USA 27560
Prayson Pate Overture Networks, Inc. 507 Airport Boulevard Morrisville, NC, USA 27560
EMail: 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.
この文書およびここに含まれる情報は「現状のまま」で提供され、寄稿者、寄稿者が代表または後援する組織（存在する場合）、インターネット協会およびインターネット エンジニアリング タスク フォースは、明示的または明示的または明示的に、すべての保証を否認します。ここに記載された情報の使用がいかなる権利も侵害しないことの黙示的な保証、または商品性や特定の目的への適合性の黙示的な保証を含みますが、これに限定されません。
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.
IETF 事務局に提出された IPR 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ http://www.ietf.org/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 (ietf-ipr@ietf.org) に送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC エディター機能の資金は現在、インターネット協会によって提供されています。