RFC3985 日本語訳
3985 Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture. S.Bryant, Ed., P. Pate, Ed.. March 2005. (Format: TXT=95062 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Bryant, Ed.
Request for Comments: 3985 Cisco Systems
Category: Informational P. Pate, Ed.
Overture Networks, Inc.
March 2005
ワーキンググループS.ブライアント、エドをネットワークでつないでください。コメントのために以下を要求してください。 3985年のシスコシステムズカテゴリ: エド情報のP.頭、序曲ネットワークInc.行進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).
Copyright(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.
このドキュメントはPseudo Wire Emulation Edgeから縁への(PWE3)のために構造について説明します。 それは、パケット交換網(PSNs)の上でIPかMPLSを使用することでFrame Relayや、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
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. 疑似ワイヤ定義。 . . . . . . . . . . . . . . . . 2 1.2. PWは機能性を修理します。 . . . . . . . . . . . . . . . 3 1.3. このドキュメントの非目標。 . . . . . . . . . . . . . . 4 1.4. 用語. . . . . . . . . . . . . . . . . . . . . . 4 2。 PWE3の適用性。 . . . . . . . . . . . . . . . . . . . . . 6 3. モデル. . . . . . . . . . . . . . . . . . . 6 3.1を層にして、議定書を作ってください。 層. . . . . . . . . . . . . . . . . . . . 7 3.2について議定書の中で述べてください。 PWE3のドメイン。 . . . . . . . . . . . . . . . . . . . . 8 3.3. 有効搭載量は.8 4をタイプします。 疑似ワイヤの構造。 . . . . . . . . . . . . . . . . 11 4.1. 規範モデル. . . . . . . . . . . . . . . . 12 4.2をネットワークでつないでください。 PWE3前処理. . . . . . . . . . . . . . . . . . 12 4.3。 メンテナンス規範モデル. . . . . . . . . . . . . . 16 4.4。 スタック規範モデルについて議定書の中で述べてください。 . . . . . . . . . . . . 17 4.5. スタック規範モデル. . . . . . . . . . . . . . . . . . . . . . . . . 17 5について議定書の中で述べるために拡大を前処理します。 PWカプセル化。 . . . . . . . . . . . . . . . . . . . . . . 18
Bryant & Pate Standards Track [Page 1] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[1ページ]。
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
5.1. 有効搭載量集合層. . . . . . . . . . . . . . . 19 5.2。 有効搭載量から独立しているPWカプセル化は.215.3を層にします。 断片化. . . . . . . . . . . . . . . . . . . . . 24 5.4。 プロトコルの具体化は層にされます。 . . . . . . . . . 24 6. PWデマルチプレクサ層とPSN要件. . . . . . . . . 27 6.1。 マルチプレクシング。 . . . . . . . . . . . . . . . . . . . . . 27 6.2. 断片化. . . . . . . . . . . . . . . . . . . . . 28 6.3。 長さと配送. . . . . . . . . . . . . . . . . . 28 6.4。 PW-PDU合法化. . . . . . . . . . . . . . . . . . . 28 6.5。 混雑問題. . . . . . . . . . . . . . . 28 7。 飛行機. . . . . . . . . . . . . . . . . . . . . . . . 29 7.1を制御してください。 疑似ワイヤのセットアップか分解。 . . . . . . . . . . 29 7.2. 状態モニター. . . . . . . . . . . . . . . . . . . 30 7.3。 疑似ワイヤ状態の通知は変化します。 . . . . . . 30 7.4. 生かします。 . . . . . . . . . . . . . . . . . . . . . . 31 7.5. ネイティブのサービスに関するコントロールメッセージを扱います。 . . . 32 8. 管理とモニター. . . . . . . . . . . . . . . . . . 32 8.1。 状態と統計. . . . . . . . . . . . . . . . . 32 8.2。 PW SNMP MIB構造。 . . . . . . . . . . . . . . . 33 8.3. 接続検証とトレースルート。 . . . . . . . . 36 9. IANA問題. . . . . . . . . . . . . . . . . . . . . 37 10。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 37 11。 承認。 . . . . . . . . . . . . . . . . . . . . . . 38 12. 参照。 . . . . . . . . . . . . . . . . . . . . . . . . . 38 12.1. 引用規格. . . . . . . . . . . . . . . . . 38 12.2。 有益な参照. . . . . . . . . . . . . . . . 39 13。 共著者。 . . . . . . . . . . . . . . . . . . . . . . . . . 40 14. エディタのアドレス。 . . . . . . . . . . . . . . . . . . . . . 41 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . 42
1. Introduction
1. 序論
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.
このドキュメントはPseudo Wire Emulation Edgeから縁への(PWE3)のために[RFC3916]を支持して構造について説明します。 それは、パケット交換網(PSNs)の上でIPかMPLSを使用することでFrame Relayや、ATMや、イーサネットや、TDMや、Sonet/SDHなどのサービスのエミュレーションについて議論します。 それは、疑似ワイヤ(PWs)のために建築枠組みを提示して、用語を定義して、様々なプロトコル要素とそれらの機能を指定します。
1.1. Pseudo Wire Definition
1.1. 疑似ワイヤ定義
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
PWE3はPSNの上でテレコムサービス(T1専用線かFrame Relayなどの)の不可欠の属性を見習うメカニズムです。 PWE3が与えられたサービス定義のために必要な度の忠実でワイヤを見習うために最小の必要な機能性だけを提供することを意図します。 どんな必要な切り換えの機能性も混載業者機能の責任です。
Bryant & Pate Standards Track [Page 2] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[2ページ]。
(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.
(FWRD。) ペイロード意味論に関する知識を必要とするどんな翻訳や他の操作もネイティブのサービス処理(NSP)要素によって行われます。 PWE3の範囲の外にどんなFWRDやNSP要素の機能定義もあります。
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の必要な機能は、イングレスポートに到着して、IP経路かMPLSトンネルの向こう側に彼らを運びながらサービス特有のビットストリーム、セル、またはPDUsをカプセルに入れるのを含んでいます。 いくつかの場合、必要な度の忠実に対するサービスの振舞いと特性を見習うために彼らのタイミングと注文を管理などなどの他の操作を実行するのが必要です。
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.
Customer Edge Equipment(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.
それぞれのサービスタイプのために、そのサービスを提供するすべてのPEsが支持しなければならないのをタイプする1つのデフォルト運転モードがあるでしょう。 しかしながら、任意のモードは見習われたサービスの忠実を改良するために定義されるかもしれません、任意のモードに関連している追加複雑さがそれがPWユーザに提供する値によって相殺されるのを明確に示すことができるなら。
1.2. PW Service Functionality
1.2. PWサービスの機能性
PWs provide the following functions in order to emulate the behavior and characteristics of the native service.
PWsは、ネイティブのサービスの振舞いと特性を見習うために以下の機能を提供します。
o Encapsulation of service-specific PDUs or circuit data arriving
at the PE-bound port (logical or physical).
o Carriage of the encapsulated data across a PSN tunnel.
o Establishment of the PW, including the exchange and/or
distribution of the PW identifiers used by the PSN tunnel
endpoints.
o Managing the signaling, timing, order, or other aspects of the
service at the boundaries of the PW.
o Service-specific status and alarm management.
o 要約のデータの. o CarriageはPSNトンネルの向こう側にサービス特有のPDUsかPE行きに届くサーキットデータのカプセル化は移植されます(論理的であるか物理的な)。PWのo特権階級、PW識別子の交換、そして/または、分配を含んでいると、PSNトンネル終点o Managingのそばのシグナリング、タイミング(オーダーの、または、他のPWの境界でのサービスの局面)は使用されました。o Service特有の状態とアラーム管理。
Bryant & Pate Standards Track [Page 3] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[3ページ]。
1.3. Non-Goals of This Document
1.3. このドキュメントの非目標
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カプセル化○ プロトコルの詳細な定義ワイヤに関する仕様はセットアップと維持に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アドレスへのイーサネット送信はしかし、範囲、媒体の上で実行されているのが、基本的なPSNを合図するか、または制御する. o Methodsであるということである火星[RFC2022]などのマルチキャストサービス中です。
1.4. Terminology
1.4. 用語
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".
PEへの付属Circuit物理的であるか仮想のサーキット付く(西暦)a CE。 例えば、付属CircuitはFrame Relay DLCI、ATM VPI/VCI、イーサネットポート、VLAN、物理インターフェースにおけるPPP接続、L2TPトンネルからのPPPセッション、またはMPLS LSPであるかもしれません。 物理的なものと同様に仮想のACsが同じ技術のものである、(例えば、ATM、両方のイーサネットの両方、両方、Frame Relay)、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行き、処理されたPSNを通してPWにどのPW-PDUsを受け取るか、そして、その時の交通指示は目的地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 Signaling MessagesはCEの制御飛行機で発信して、受信しました。 これが、合図して、PEがモニターするか、モニターに参加するのが有効にサービスを見習うのが、望ましいか、または必要でさえあるかもしれません。
Control Word (CW) A four-octet header used in some encapsulations
to carry per-packet information when the PSN is
MPLS.
4八重奏のヘッダーがいつPSNがMPLSであるかという1パケットあたりの情報を運ぶのにいくつかのカプセル化に使用したWord(CW)を制御してください。
Bryant & Pate Standards Track [Page 4] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[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.
サービスの片端が由来する、そして/または、終わる顧客Edge(CE)A装置。 CEはネイティブであるというよりむしろ意識している見習われたサービスを利用しているのをサービスではありません。
Forwarder (FWRD) A PE subsystem that selects the PW to use in
order to transmit a payload received on an AC.
それが、PWがペイロードを伝えるのに使用するのを選択する混載業者(FWRD)A 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を複数のPDUsに分割する動作。 それらがそれらが横断するネットワークのMTUより大きいなら、パケットは断片化を受けるかもしれません。
Maximum Transmission The packet size (excluding data link header)
unit (MTU) that an interface can transmit without needing
to fragment.
最大のTransmission、インタフェースが断片化する必要はなくて送ることができるパケットサイズ(データ・リンクヘッダーを除いた)単位(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.)
データのネイティブのService Processingがトランスミッションのためにコアの向こう側にPE Processing(NSP)のそばでプレゼンテーションの前のCEからPWまで受信したか、またはそれが西暦における出力であることの前にデータの処理はPEのそばでPWから受信されました。 NSPの機能性はIETF以外のITU-T、ANSI、またはATMFなどの標準化団体によって定義されます。)
Packet Switched Within the context of PWE3, this is a
Network (PSN) network using IP or MPLS as the mechanism for
packet forwarding.
パケットSwitched Within、PWE3の文脈、これはパケット推進にメカニズムとしてIPかMPLSを使用するNetwork(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.
PW、および適合させられたCEからPW-PDUsまでの情報がどれであるかで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.
PWをセットアップして、維持して、取りこわすPEsによるPE/PW Maintenance Used。 それは、有効にPWを管理するためにCE Signalingに結びつけられるかもしれません。
Protocol Data The unit of data output to, or received Unit (PDU) from, the network by a protocol layer.
Dataについて議定書の中で述べてください、Unit(PDU)が出力されるか、または受け取られたデータのユニット、プロトコル層のそばのネットワーク。
Provider Edge (PE) A device that provides PWE3 to a CE.
PWE3をCEに供給するプロバイダーEdge(PE)A装置。
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.
見習われたあるPEから他の1PEsまでのサービスの必須元素をPSNの上に乗せる疑似Wire(PW)Aメカニズム。
Bryant & Pate Standards Track [Page 5] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[5ページ]。
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賃貸されたEdge(PWE3)線かFrame Relayなどの)の属性に不可欠のEmulation Edgeを見習う疑似Wire Aメカニズム。
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.
疑似Wire PDU A PDUは(PW-PDU)データと必要なサービスを見習うのに必要な制御情報のすべてを含むPWを転送しました。
PSN Tunnel A tunnel across a PSN, inside which one or more
PWs can be carried.
PSN Tunnel AはPSNの向こう側にトンネルを堀ります。そこでは、1PWsを運ぶことができます。
PSN Tunnel Used to set up, maintain, and tear down the Signaling underlying PSN tunnel.
Signalingの基本的なPSNをセットアップして、維持して、取りこわすPSN Tunnel Usedはトンネルを堀ります。
PW Demultiplexer Data-plane method of identifying a PW
terminating at a PE.
PEで終わるPWを特定するPW Demultiplexer Data-飛行機方法。
Time Domain Time Division Multiplexing. Frequently used
Multiplexing (TDM) to refer to the synchronous bit streams at rates
defined by G.702.
時間領域時分割多重化。 シンクロナスビットについて言及する頻繁に使用されたMultiplexing(TDM)はG.702によって定義された速度で流れます。
Tunnel A method of transparently carrying information
over a network.
透明にネットワークの上まで情報を運ぶA方法にトンネルを堀ってください。
2. PWE3 Applicability
2. PWE3の適用性
The PSN carrying a PW will subject payload packets to loss, delay, delay variation, and re-ordering. During a network transient there may be a sustained period of impaired service. The applicability of PWE3 to a particular service depends on the sensitivity of that service (or the CE implementation) to these effects, and on the ability of the adaptation layer to mask them. Some services, such as IP over FR over PWE3, may prove quite resilient to IP and MPLS PSN characteristics. Other services, such as the interconnection of PBX systems via PWE3, will require more careful consideration of the PSN and adaptation layer characteristics. In some instances, traffic engineering of the underlying PSN will be required, and in some cases the constraints may make the required service guarantees impossible to provide.
PWを運ぶPSNは損失、遅れ、遅れ変化、および再注文への対象のペイロードパケットがそうするでしょう。 そこで一時的なネットワークの間、持続している期間の損なわれたサービスはそうです。 特定のサービスへのPWE3の適用性はこれらの効果に対するそのサービス(または、CE実現)の感度と、そして、それらにマスクをかける適合層の能力に依存します。 PWE3の上のFRの上のIPなどのいくつかのサービスがIPとMPLS PSNの特性にかなり弾力があると判明するかもしれません。 PWE3を通したPBXシステムのインタコネクトなどの他のサービスはPSNと適合層の特性の、より慎重な考慮を必要とするでしょう。 ある場合に、基本的なPSNの交通工学が必要でしょう、そして、いくつかの場合、規制は必要なサービス保証を提供するのを不可能にするかもしれません。
3. Protocol Layering Model
3. プロトコルレイヤリングモデル
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タイプで作動するPWsの違いを最小にすることを意図します。 プロトコルを層にするモデルのデザインには、基本的なPSNの如何にかかわらず各PWを定義にして、IETFプロトコル定義と彼らの実現の再利用を最大にするという目標があります。
Bryant & Pate Standards Track [Page 6] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[6ページ]。
3.1. Protocol Layers
3.1. プロトコル層
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 |
+---------------------------+
+---------------------------+ | 有効搭載量| +---------------------------+ | カプセル化| <== +を空にすることであるかもしれません。---------------------------+ | PWデマルチプレクサ| +---------------------------+ | PSN集合| <== +を空にすることであるかもしれません。---------------------------+ | PSN| +---------------------------+ | データ・リンク| +---------------------------+ | 物理的| +---------------------------+
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.
ペイロードはEncapsulation Layerの上で輸送されます。 Encapsulation Layerはペイロードの中に既にそれ自体を提示するのではなく、どんな情報も運んで、それは、物理インターフェースを通してペイロードをCEに送るためにPW CE行きのPEインタフェースによって必要とされます。 詳細は全くペイロード自体で必要でないなら、この層が空です。
The Encapsulation Layer also provides support for real-time processing, and if needed for sequencing.
また、リアルタイムの処理、配列に必要であるなら、Encapsulation Layerはサポートを提供します。
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トンネルにわたって複数のPWsを届ける能力を提供します。 データ飛行機でPWを特定するのに使用されるPWデマルチプレクサ価値はPE単位でユニークであるかもしれませんが、これはPWE3要件ではありません。 しかしながら、それはトンネル終点単位でユニークであるに違いありません。 特定のトンネルを特定するのが必要であるなら、それはPSN層の責任です。
The PSN Convergence layer provides the enhancements needed to make the PSN conform to the assumed PSN service requirement. Therefore, this layer provides a consistent interface to the PW, making the PW independent of the PSN type. If the PSN already meets the service requirements, this layer is empty.
PSN Convergence層はPSNに想定されたPSNサービス要件に従わせるのに必要である増進を提供します。 したがって、PSNの如何にかかわらずPWにタイプさせて、この層は一貫したインタフェースをPWに供給します。 PSNが既にサービス要件を満たすなら、この層は空です。
Bryant & Pate Standards Track [Page 7] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[7ページ]。
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/リンク、およびPhysical Layer定義があります。 PSNはIPv4、IPv6、またはMPLSであるかもしれません。
3.2. Domain of PWE3
3.2. PWE3のドメイン
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はEncapsulation Layer、様々なペイロードタイプを運ぶ方法、およびPW Demultiplexer Layerへのインタフェースを定義します。 他の層がL2TPかMPLSなどのトンネリング方法でPSNの上に提供されると予想されます。
3.3. Payload Types
3.3. 有効搭載量タイプ
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 Cell o Bit流れのo Structuredビットストリーム
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.
一般的な有効搭載量タイプPWサービス-------------------- ---------- パケットイーサネット(すべてのタイプ)、HDLC縁どり、Frame Relay、ATM AAL5 PDU。
Cell ATM.
セル気圧。
Bit stream Unstructured E1, T1, E3, T3.
ビットストリームUnstructured E1、T1、E3、T3。
Structured bit stream SONET/SDH (e.g., SPE, VT, NxDS0).
ビットストリームSonet/SDH(例えば、SPE、バーモントNxDS0)を構造化しました。
3.3.1. Packet Payload
3.3.1. パケット有効搭載量
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.
パケットペイロードは西暦を通してPEに渡された可変サイズデータ単位です。 PSN MTUと比べて、パケットペイロードは大きいかもしれません。 パケット境界の輪郭描写はカプセル化特有です。 パケットペイロードに関する例であるとHDLCかイーサネットPDUsを考えることができます。 パケットは、通常、HDLC旗などのトランスミッションオーバーヘッドが奪い取られて、PWの上のトランスミッションの前にビットを詰めるでしょう。
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
通常、パケットペイロードは単一の単位としてPWの向こう側にリレーされるでしょう。 しかしながら、ケースがそのパケットペイロード、関連PWE3、およびPSNヘッダーの結合したサイズがPSN経路MTUを超えているところにあるでしょう。 これらの場合では、何らかの断片化方法論が適用されなければなりません。 ユーザが提供するとき、例えば、これはそうであるかもしれません。
Bryant & Pate Standards Track [Page 8] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[8ページ]。
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.
イーサネットを通したサービスプロバイダーかそれとも入れ子にされて、疑似ワイヤがいつかかわるかまでのサービスと大使館員。 さらに詳細にセクション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.
いくつかの状況で、パケットペイロードは何らかのサブマルチプレクシングのテクニックに基づいて見習われたワイヤの上に提示されたパケットから選択されるかもしれません。 例えば、1Frame Relay PDUsがまたはイーサネットペイロードの場合でFrame Relay Data-リンクConnection Identifier(DLCI)に基づく特定の疑似ワイヤの上の輸送のために選択されるかもしれません、適当なMAC橋のフィルタを使用することによって。 これは混載業者機能です、そして、したがって、PW Encapsulation Layerにパケットを提示する前にこの選択をするでしょう。
3.3.2. Cell Payload
3.3.2. セル有効搭載量
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八重奏のセルと、より大きい188八重奏のMPEG Transport Streamパケット[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.
1PSNあたりのパケットオーバーヘッドを下げるために、複数のセルがただ一つのペイロードに連結されるかもしれません。 Encapsulation Layerは、タイマの満期にペイロードが完全であると考えるかもしれません、固定数のセルを受け取った後か重要なセル(例えば、ATM OAMセル)を受け取ったときに時。 複数のPDUsを連結する利益はパケット遅れ変化の可能な増加とパケット損失で被られたより大きい刑罰に比較考量されるべきです。 いくつかの場合、Encapsulation Layerがタイプの要約を実行するのは、適切であるかもしれません、沈黙抑圧や声の圧縮のように。
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).
Encapsulation Layerはこれらの何人かのサブタイプに何らかの形式の圧縮を適用するかもしれません(例えば活動していないセルは抑圧されるかもしれません)。
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 Encapsulation Layerにパケットを提示する前に選択をするでしょう。
Bryant & Pate Standards Track [Page 9] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[9ページ]。
3.3.3. Bit Stream
3.3.3. ビットストリーム
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.
ある場合にそれは抑圧をビットストリームに適用するのにおいて可能です。例えば、1EとT1は、失敗を示すために「オールもの」を送ります。 ビットストリームの構造に関する少しも知識なしでこの状態を検出できます、そして、packetizedされることのトランスミッションは抑圧されたデータであるかもしれません。
This service will require sequencing and real-time support.
このサービスは配列とリアルタイムのサポートを必要とするでしょう。
3.3.4. Structured Bit Stream
3.3.4. 構造化されたビットストリーム
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 オリジナルのビットストリームのいくつかの部分をPSN行きの方向にNSPブロック剥取るかもしれません。 例えば、Structured Sonetでは、セクションと線オーバーヘッド(ことによるとさらに)を剥取るかもしれません。 喧嘩早い人が、そのようなストリップを可能にするのに必要です。 また、それが断片的な1T1/ユーロのアプリケーションのためのフレーム/ペイロード整列に必要です。
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.
また、オプションとして、Encapsulation Layerは沈黙/無駄な抑圧か同様の圧縮を構造化されたビットストリームに実行するかもしれません。
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.
このサービスは配列とリアルタイムのサポートを必要とします。
Bryant & Pate Standards Track [Page 10] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[10ページ]。
3.3.5. Principle of Minimum Intervention
3.3.5. 最小の介入の原則
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].
情報の範囲を最小にして、Encapsulation Layerを通してデータフローの効率を高めるために、ペイロードは受け取るように輸送されるべきです、同じくらいわずかな変更が可能な状態で[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.
この最小の介入アプローチは、各端の同様のCEインタフェースがあるシステムでPW開発からペイロード開発の衝撃を吸収して、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の、より少ない翻訳をもたらすかもしれません。 ドキュメンテーションと確実な相互運用性を必要として、事実上、どんな中間的形式も新しい縁どりタイプになります。 これは、中間的形式が運ぶプロトコルを扱うために仕事量を増加させて、望ましくありません。
4. Architecture of Pseudo Wires
4. 疑似ワイヤの構造
This section describes the PWE3 architectural model.
このセクションはPWE3の建築モデルについて説明します。
Bryant & Pate Standards Track [Page 11] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[11ページ]。
4.1. Network Reference Model
4.1. ネットワーク規範モデル
Figure 2 illustrates the network reference model for point-to-point PWs.
図2はポイントツーポイントPWsのためにネットワーク規範モデルを例証します。
|<-------------- 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
| <。-------------- 見習われたサービス---------------->|、|、|、| | <、-、-、-、-、-、-- 疑似ワイヤ------>|、|、|、|、|、|、|、| | <-- PSNはトンネルを堀ります-->|、|、|、| V V V V| V西暦+----+ +----+ 西暦対+-----+ | | PE1|==================| PE2| | +-----+ | |----------|............PW1…|----------| | | CE1| | | | | | | | CE2| | |----------|............PW2…|----------| | +-----+ ^ | | |==================| | | ^ +-----+ ^ | +----+ +----+ | | ^ | | 1つのプロバイダー縁のプロバイダー縁2| | | | | | 顧客| | 顧客縁1| | 縁2| | | | ネイティブのサービスネイティブのサービス
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.
2PEs(PE1とPE2)が、クライアントCEsがPSNの上で交信するのを可能にするために彼らのクライアントCEs(CE1とCE2)を代表して1PWsを提供しなければなりません。 PSNトンネルは、データ経路をPWに供給するために確立されます。 PW交通はコアネットワークに目に見えません、そして、コアネットワークはCEsに見え透いています。 ネイティブのデータ単位(ビット、セル、またはパケット)は、西暦を通して到着して、PW-PDUで要約されて、PSNトンネルを通って基本的なネットワークの向こう側に運ばれます。 PEsはPW-PDUsの必要なカプセル化と被膜剥離術を実行して、PWサービスで必要であるいかなる他の機能も扱います、配列やタイミングのように。
4.2. PWE3 Pre-processing
4.2. PWE3前処理
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
いくつかのアプリケーションがそれらがPWの向こう側にPEによって伝えられる前にCE(ペイロードとシグナリング交通の両方を含んでいる)から受け取られたネイティブのデータ単位に操作を実行しなければなりません。 例はイーサネットの橋を架けるSonet十字接続、VCI/VPI、または翻訳などの局所的に重要な識別子に関する翻訳を別のサービスタイプに含んでいます。 外部の設備でこれらの操作を行うことができました、そして、処理データをPEに送ることができました。
Bryant & Pate Standards Track [Page 12] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[12ページ]。
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.
1つ以上の物理インターフェース。 多くの場合、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
PW終わりのサービス| | <、-、-、-、-、-、-- 疑似ワイヤ------>|、|、|、| | <-- PSNはトンネルを堀ります-->|、| V V V V PW+-----+----+ +----+ 終わりのサービス+-----+ |予習| PE1|==================| PE2| | +-----+ | | | |............PW1…|----------| | | CE1|----| | | | | | | CE2| | | ^ | |............PW2…|----------| | +-----+ | | | |==================| | | ^ +-----+ | +-----+----+ +----+ | | | ^ | | | | | | | | <、-、-、-、-、-、-- 見習われたサービス------->|、|、|、|、|、| 仮想の身体検査| | 終了| | ^ | CE1ネイティブ| CE2のネイティブのサービス| サービス| CE2のネイティブのサービス
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秒がある1PEを織り込むことを示しています。 この基準点は、PREPとPWとの機能的なインタフェースがサービスを提供する物理インターフェースによってそんなに表されると強調します。 事実上、これは必要な織り込む仕様を定義します。
The operation of a system in which both PEs include PREP functionality is also supported.
また、両方のPEsがPREPの機能性を含んでいるシステムの操作は支持されます。
Bryant & Pate Standards Track [Page 13] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[13ページ]。
The required pre-processing can be divided into two components:
必要な前処理を2つのコンポーネントに分割できます:
o Forwarder (FWRD)
o Native Service Processing (NSP)
o 混載業者(FWRD)oネイティブのService Processing(NSP)
4.2.1. Forwarders
4.2.1. 混載業者
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.
いくつかのアプリケーションが1ACsから1PWsまで選択的にペイロード要素を進めなければなりません。 また、そのような場合、PEによってPSNから受け取られたPWE3-PDUsに逆さの機能を実行する必要があるでしょう。 これは混載業者の機能です。
The forwarder selects the PW based on, for example, the incoming AC, the contents of the payload, or some statically and/or dynamically configured forwarding information.
混載業者は例えば、入って来る西暦、ペイロードのコンテンツ、または何らかの静的ダイナミックに構成された推進情報に基づくPWを選択します。
+----------------------------------------+
| PE Device |
+----------------------------------------+
Single | | |
AC | | Single | PW Instance
<------>o Forwarder + PW Instance X<===========>
| | |
+----------------------------------------+
+----------------------------------------+ | PE装置| +----------------------------------------+ シングル| | | 西暦| | シングル| PW例の<。------>o 混載業者+PW例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 | |
+----------------------------------------+
+----------------------------------------+ | PE装置| +----------------------------------------+ 倍数| | シングル| PW例の西暦| + PW例Xの<。===========><。------>o | | | |----------------------| <、-、-、-、-、-->o | シングル| PW例| 混載業者+PW例Xの<。===========><。------>o | | | |----------------------| <、-、-、-、-、-->o | シングル| PW例| + PW例Xの<。===========><。------>o | | +----------------------------------------+
Figure 4b. Multiple AC to Multiple PW Forwarding
図4b。 複数の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
図4aはタイプの濾過手術を実行する純真な混載業者を見せています。 混載業者にはただ一つの入力と単一の出力インタフェースがあるので、フィルタリングは唯一のタイプの推進です。
Bryant & Pate Standards Track [Page 14] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[14ページ]。
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.
適用される操作。 図4bは、ペイロードがどこに1ACsから抽出されて、1PWsに向けられるかをより一般的な推進状況に示します。 この場合、フィルタリング、指示、および組み合わせ操作はペイロードに実行されるかもしれません。 例えば、混載業者は西暦がFrame Relayであるなら、Frame Relayの切り換えを実行するでしょうに、そして、PW例は相互スイッチリンクであるかもしれません。
4.2.2. Native Service Processing
4.2.2. ネイティブのサービス処理
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).
いくつかのアプリケーションが何らかのフォームのデータかアドレス変換、またはペイロードの意味論に関する知識を必要とするある他の操作を必要としました。 これはネイティブのService Processor(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は、定義されたインタフェースをこの機能性に提供するために規範モデルに含まれています。 PWE3の範囲の外にNSPの様々なタイプの仕様があります。
+----------------------------------------+
| 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<===========>
| | | |
+----------------------------------------+
+----------------------------------------+ | PE装置| 複数の+----------------------------------------+ 西暦| | | シングル| PW例の<。------>o NSP#+PW例Xの<。===========>|| | | |------| |----------------------| | | | シングル| PW例の<。------>o NSP#混載業者+PW例Xの<。===========>|| | | |------| |----------------------| | | | シングル| PW例の<。------>o NSP#+PW例Xの<。===========>|| | | +----------------------------------------+
Figure 5. NSP in a Multiple AC to Multiple PW Forwarding PE
図5。 複数の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と、混載業者と、PWsとの関係を例証します。 CEへの物理インターフェースと混載業者への仮想インターフェースの間を通るとき、NSP機能はペイロードにおけるどんな変化操作(変更、注射など)も適用するかもしれません。 これらの変化操作はもちろんデータ経路で実行されて、PE構成によって可能にされるものに制限されるでしょう。 PE装置は1人以上の混載業者を含むかもしれません。
Bryant & Pate Standards Track [Page 15] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[15ページ]。
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の機能性がデータ・リンクを終えるのを含んでいるシステムの操作、およびNetwork Layer処理の応用をペイロードに支持します。
4.3. Maintenance Reference Model
4.3. メンテナンス規範モデル
Figure 6 illustrates the maintenance reference model for PWs.
図6はPWsのためにメンテナンス規範モデルを例証します。
|<------- 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
| <。------- Ce(終わるには、終わる)シグナリング------>|、| | <、-、-、-- PW/PE維持----->|、|、|、| | <-- PSNはトンネルを堀ります-->|、|、|、|、|、| シグナリング| | | | V V(範囲からの)V V| +に対して-----+ +-----+ +に対して-----+ | PE1|==================| PE2| +-----+ | |-----|.............PW1…|-----| | | CE1| | | | | | CE2| | |-----|.............PW2…|-----| | +-----+ | |==================| | +-----+ +-----+ +-----+ 1つの縁の1つの顧客プロバイダープロバイダー顧客縁の縁の2縁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 CEsの間には、CE(終わるには、終わる)シグナリングがあります。 このシグナリングはFrame Relay 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 MaintenanceはPWsをセットアップして、維持して、取りこわすのにPEs(または、NSPs)の間で使用されます、パラメタのどんな必要なコーディネートも含んでいて。
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 TunnelシグナリングはPWマルチプレクシングと基本的なPSNのいくつかの要素を制御します。 例は、L2TP制御プロトコルと、MPLS LDPと、RSVP-TEです。 PWE3の範囲の中にPWE3の必要性が合図したという情報の定義がありますが、それ自体はシグナリングプロトコルではありません。
Bryant & Pate Standards Track [Page 16] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[16ページ]。
4.4. Protocol Stack Reference Model
4.4. プロトコル・スタック規範モデル
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 \===============+
\ /
\_____________/
+-----------------+ +-----------------+ |見習われたサービス| |見習われたサービス| |(例えば、TDM、気圧) |<== 見習われたサービス===>|(例えば、TDM、気圧) | +-----------------+ +-----------------+ | 有効搭載量| | 有効搭載量| | カプセル化|<=== 疑似ワイヤ======>| カプセル化| +-----------------+ +-----------------+ |PWデマルチプレクサ| |PWデマルチプレクサ| | PSNはトンネルを堀ります。|<==== PSNトンネル======>| PSNはトンネルを堀ります。| | PSN的で物理的です。| | PSN的で物理的です。| | 層| | 層| +-------+---------+ ___________ +---------+-------+ | / \ | +===============/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からのネイティブのサービスPDUsを発信しているPEをEncapsulation Layerを通り抜けて、次に、PSNの上に送ります。 受信PEはカプセル化を移して、目的地CEへの伝送のためネイティブの形式にペイロードを返します。
4.5. Pre-processing Extension to Protocol Stack Reference Model
4.5. スタック規範モデルについて議定書の中で述べるために拡大を前処理します。
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.
エイト環はプロトコル・スタック規範モデルが(推進とNSP)を前処理する支給を含むようにどう広げられるかを例証します。 これはCEに比例して物理インターフェースのプレースメントを示しています。
Bryant & Pate Standards Track [Page 17] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[17ページ]。
/======================================\
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
/======================================\H混載業者H<。----前処理H----------------======================/HネイティブのサービスH| | H処理H| | \================/ | | | | | 見習われます。| | サービス| | サービス| | インタフェース| | (| | (| | TDM、ATM、| イーサネット、<=Emulated Service=| | | イーサネット、フレームRelay| | | | フレームRelayなど)| | TDM、ATMなど) | +-----------------+ | | | 有効搭載量| | | | カプセル化|<== 疑似ワイヤ====== | | +-----------------+ | | |PWデマルチプレクサ| | | | PSNはトンネルを堀ります。| | | | PSN的で物理的です。|<== PSNトンネル======= | | | ヘッダー| +----------------+ +-----------------+ | 物理的| | 物理的| +-------+--------+ +-------+---------+ | | | | | | | | | | | | Ce<に---+ +---PSNへの>。
Figure 8. Protocol Stack Reference Model with Pre-processing
エイト環。 前処理のプロトコル・スタック規範モデル
5. PW Encapsulation
5. PWカプセル化
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 Encapsulation Layerは、PWの上でPSNの上までPWを運ぶのに使用されるPW Demultiplexer Layerに輸送される特定のペイロードタイプを適合させるために必要なインフラを提供します。
The PW Encapsulation Layer consists of three sub-layers:
PW Encapsulation Layerは3つの副層から成ります:
o Payload Convergence
o Timing
o Sequencing
o 有効搭載量Convergence o Timing o Sequencing
The PW Encapsulation sub-layering and its context with the protocol stack are shown in Figure 9.
PW Encapsulationサブレイヤリングとプロトコル・スタックがあるその文脈は図9に示されます。
Bryant & Pate Standards Track [Page 18] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[18ページ]。
+---------------------------+
| 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 |
+---------------------------+
+---------------------------+ | 有効搭載量| /===========================\<。------ カプセル化H有効搭載量集合H層H---------------------------H HタイミングH H---------------------------H H配列H\===========================/ | PWデマルチプレクサ| +---------------------------+ | PSN集合| +---------------------------+ | PSN| +---------------------------+ | データ・リンク| +---------------------------+ | 物理的| +---------------------------+
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.
有効搭載量Convergence副層は特定のペイロードタイプに非常に合わせます。 しかしながら、多くの目標ペイロードタイプを一般的なクラスに分類して、次に、グループに共通の単独の集合副層のタイプを提供すると、ペイロード集合副層のタイプの数は減少します。 これは実現の複雑さを減少させます。 1パケットあたりのシグナリングと他のバンドで出ている情報(配列かタイミングを除いた)の支給はこの層によって引き受けられます。
The Timing and Sequencing Layers provide generic services to the Payload Convergence Layer for all payload types that require them.
TimingとSequencing Layersは彼らを必要とするすべてのペイロードタイプに有効搭載量Convergence Layerに対する一般的なサービスを提供します。
5.1. Payload Convergence Layer
5.1. 有効搭載量集合層
5.1.1. Encapsulation
5.1.1. カプセル化
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.
有効搭載量Convergence Layerの第一のタスクはPW-PDUsのペイロードのカプセル化です。 要約されるべきネイティブのデータ単位はL2ヘッダーかL1オーバーヘッドを含むかもしれません。 これはサービス特有です。 有効搭載量ConvergenceヘッダーはCE行きの物理インターフェースでネイティブのデータ単位を再演するのに必要である追加情報を運びます。 PW DemultiplexerヘッダーはPWヘッダーの一部であると考えられません。
Bryant & Pate Standards Track [Page 19] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[19ページ]。
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 PDUsのPWヘッダーで運ばれるために持っている再生に必要であるというわけではないすべての追加情報。 PWの間の目的地PEの州の情報がセットアップされたので、何らかの情報(例えば、PWのサービスタイプ)が格納されるかもしれません。
5.1.2. PWE3 Channel Types
5.1.2. PWE3チャンネル種別
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 Encapsulation Layerとその関連シグナリングはその基本的なPW DemultiplexerとPSN Layersから以下のタイプのチャンネルのより多くのひとりを必要とします(チャンネルタイプ1足す1か一層のチャンネルが2〜4にタイプします):
1. A reliable control channel for signaling line events, status
indications, and, in exceptional cases, CE-CE events that must be
translated and sent reliably between PEs. PWE3 may need this type
of control channel to provide faithful emulation of complex data-
link protocols.
1. シグナリング線イベント、状態指摘、および例外的な場合における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から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. パケット再命令(どんな非IP交通にはも使用のための1つの分類があるかもしれない)に敏感なデータ通信量のための配列されたチャンネル。
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
終わりから終わりへの接続性がアドレス変換[RFC3022]、アクセスコントロールリスト、ファイアウォールなどによって混乱させられるかもしれないところでは、制御チャンネルは、交通を通り過ぎて、PWをセットアップできるかもしれません、PWデータ通信量はこれらのメカニズムの1つ以上によって妨げられますが。これらの場合では、また、制御チャンネルが「バンド」で運ばれないと、PWに設定するシグナリングは終わりまでの端のデータ経路の存在を確認しないでしょう。 いくつかの場合、PWの上まで運ばれるデータにCE出来事を連動させる必要があります。 これは特にそうです。
Bryant & Pate Standards Track [Page 20] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[20ページ]。
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).
TDMサーキット(例えばPSTNスイッチのオフオンフック/フック出来事は高信頼の制御チャンネルの上まで運ばれるかもしれませんが、関連ビットストリームは配列されたデータ・チャンネルの上まで運ばれる)で。
PWE3 channel types that are not needed by the supported PWs need not be included in such an implementation.
支持されたPWsによって必要とされないPWE3チャンネル種別はそのような実現に含まれる必要はありません。
5.1.3. Quality of Service Considerations
5.1.3. サービスの質問題
Where possible, it is desirable to employ mechanisms to provide PW Quality of Service (QoS) support over PSNs.
可能であるところでは、Service(QoS)サポートのPW QualityをPSNsの上に供給するのにメカニズムを使うのが望ましいです。
5.2. Payload-Independent PW Encapsulation Layers
5.2. 有効搭載量から独立しているPWカプセル化層
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 Encapsulation副層がすべてのペイロードタイプへの共益サービスを提供します: 配列とタイミング。 特定の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.
時々、特定のペイロードタイプは系列、そして/または、リアルタイムのサポートのあるなしにかかわらず輸送を必要とするでしょう。 例えば、Frame Relay輸送の不変式はパケットオーダーの保存です。 いくつかのFrame Relayアプリケーションは、オーダーで荷渡しを予期して、フレームを再命令しながら、対処されないかもしれません。 しかしながら、Frame RelayサービスがIPを運ぶのに利用されているだけであるところでは、1パケットあたりの加工費を下げるというこの規制を弛緩するのは望ましいかもしれません。
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必要条件を満たすように広げられるべきであるか、または変更されるべきです、その結果、そのプロトコルを他のIETF用途に利用可能にします。 タイミングの特定の場合では、1つ以上の一般的な方法が、ペイロードタイミング要件の完全な範囲に備えるのに必要であるかもしれません。
5.2.1. Sequencing
5.2.1. 配列
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つのサービスを提供します: 注文を縁どってください、そして、複製検出を縁どってください、そして、損失検出を縁どってください。 これらのサービスは物理的なワイヤの不変な特性のエミュレーションを許容します。 配列のサポートは、ペイロードタイプに頼っていて、それは必要でないなら、省略されるかもしれません。
Bryant & Pate Standards Track [Page 21] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[21ページ]。
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より大きい一連番号スペースが、一時的の間、ラッピングから一連番号スペースを防ぐのに必要であるかもしれません。
5.2.1.1. Frame Ordering
5.2.1.1. フレーム注文
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つの可能なmisordering戦略があります:
o Drop misordered PW PDUs.
o misordered PW PDUsを落としてください。
o Try to sort PW PDUs into the correct order.
o PW PDUsを正しいオーダーに分類するようにしてください。
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 misorderingの予想された発生。
5.2.1.2. Frame Duplication Detection
5.2.1.2. フレーム複製検出
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に渡されないのを保証するために何らかのメカニズムを提供しなければなりません。 メカニズムはオーダーにおけるフレーム配送を確実にするのに使用されるそれと同じであるかもしれません。
Bryant & Pate Standards Track [Page 22] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[22ページ]。
5.2.1.3. Frame Loss Detection
5.2.1.3. フレーム損失検出
A destination PE can determine whether a frame has been lost by tracking the sequence numbers of the PW PDUs received.
フレームがPW PDUsの一連番号を追跡することによってなくされたか否かに関係なく、PEが決定できる目的地は受信されました。
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.
ある場合にそれが無くなると推定するためにPEにはある目的地PW PDUが、ある時以内に到着しないなら。 次に失われているように処理されたPW-PDUが到着するなら、目的地PEはそれを捨てなければなりません。
5.2.2. Timing
5.2.2. タイミング
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.
多くのネイティブのサービスで、それらが設計されたネットワークの特性に基づくタイミング期待は. 見習うことのサービスができるだけ密接にこれらのネットワークの特性をコピーするために持っているかもしれない上を旅行します: 例えば、bitrate、ジターに伴う固有の交通を提供する際に、さまよってください、そして、発信している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にそれを受け取ったように固有の交通を展開しなければなりません。 これは2PEsの間に送るか、外部参照から受け取られたいくつかのケースのどちらかの中のタイミング情報を当てにします。
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.
したがって、Timing Sub-層は2つのタイミング機能を支持しなければなりません: 回復と調節されたペイロード配送の時間を計ってください。 特定のペイロードタイプはこれらのサービスのどちらかか両方を必要とするかもしれません。
5.2.2.1. Clock Recovery
5.2.2.1. 時計回復
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.
時計回復は渡されたパケットの流れからの情報を調節する出力トランスミッションビットの抽出です、そして、それは適当なメカニズムを必要とします。 物理的なワイヤはネイティブにタイミング情報を運びますが、パケットの流れなどの非常にjitteredされた源からタイミングを抽出するのは、比較的複雑なタスクです。 したがって、[RFC3550]などの既存のリアルタイムのプロトコルがこのために使用されるのは、望ましいです、特定のペイロードタイプに、これが不適当であるか、または不要であることを示すことができないなら。
5.2.2.2. Timed Delivery
5.2.2.2. 調節された配送
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 PDUsの配送です。 配送のタイミングはPSN時計回復の上、または、外部クロックに受けられたパケットの流れから得られた時計に比例しているかもしれません。
Bryant & Pate Standards Track [Page 23] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[23ページ]。
5.3. Fragmentation
5.3. 断片化
Ideally, a payload would be relayed across the PW as a single unit. However, there will be cases where the combined size of the payload and its associated PWE3 and PSN headers will exceed the PSN path MTU. When a packet size exceeds the MTU of a given network, fragmentation and reassembly have to be performed for the packet to be delivered. Since fragmentation and reassembly generally consume considerable network resources, as compared to simply switching a packet in its entirety, the need for fragmentation and reassembly throughout a network should be reduced or eliminated to the extent possible. Of particular concern for fragmentation and reassembly are aggregation points where large numbers of PWs are processed (e.g., at the PE).
理想的に、ペイロードは単一の単位としてPWの向こう側にリレーされるでしょう。 しかしながら、ケースがそのペイロードの結合したサイズ、関連PWE3、およびPSNヘッダーがPSN経路MTUを超えているところにあるでしょう。 パケットサイズが与えられたネットワークのMTUを超えているとき、断片化と再アセンブリは、パケットを届けるために実行されなければなりません。 単にパケットを全体として切り換えると比べて、断片化と再アセンブリが一般にかなりのネットワーク資源を消費するので、断片化の必要性とネットワーク中の再アセンブリは可能な範囲内で減少するべきであるか、または排除されるべきです。 特定では、断片化に関する心配と再アセンブリは多くのPWsが処理される(例えば、PEで)集合ポイントです。
Ideally, the equipment originating the traffic sent over the PW will have adaptive measures in place (e.g., [RFC1191], [RFC1981]) that ensure that packets needing to be fragmented are not sent. When this fails, the point closest to the sending host with fragmentation and reassembly capabilities should attempt to reduce the size of packets to satisfy the PSN MTU. Thus, in the reference model for PWE3 (Figure 3), fragmentation should first be performed at the CE if possible. Only if the CE cannot adhere to an acceptable MTU size for the PW should the PE attempt its own fragmentation method.
理想的に、交通がPWの上で送った設備由来は断片化される必要があるパケットが送られないのを確実にする適所にある適応型の測定(例えば、[RFC1191]、[RFC1981])を持つでしょう。 これが失敗すると、送付ホストに断片化について最も近くて再アセンブリな能力が試みるべきであるポイントは、PSN MTUを満たすためにパケットのサイズを減少させます。 したがって、できれば、PWE3(図3)の規範モデルでは、断片化は最初に、CEで実行されるべきです。 CEがPWのために許容できるMTUサイズを固く守ることができない場合にだけ、PEはそれ自身の断片化方法を試みるはずですか?
In cases where MTU management fails to limit the payload to a size suitable for transmission of the PW, the PE may fall back to either a generic PW fragmentation method or, if available, the fragmentation service of the underlying PSN.
MTU経営者側がペイロードをPWのトランスミッションに適したサイズに制限しない場合では、PEは基本的なPSNの一般的なPW断片化方法か断片化サービスのどちらかへ利用可能であるなら後ろへ下がるかもしれません。
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フレームの長さが目的地西暦のMTUを超えているなら、それを落とさなければなりません。 この場合、目的地PEの管理飛行機は通知されるかもしれません。
5.4. Instantiation of the Protocol Layers
5.4. プロトコル層の具体化
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.
このドキュメントはプロトコルLayeringモデルの詳細なマッピングを存在か将来のIETF規格に記述しません。 論理的なプロトコルLayeringモデルの具体化は図9に示されます。
Bryant & Pate Standards Track [Page 24] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[24ページ]。
5.4.1. PWE3 over an IP PSN
5.4.1. IP PSNの上のPWE3
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 |
+---------------------+ +-------------------------+
+---------------------+ +-------------------------+ | 有効搭載量|、-、-、-、-、-、-、-、-、-、-、-、--、>| 生のペイロード、できれば。| /=====================\ +-------------------------+ H有効搭載量集合H-----------+->| 旗、seq#など | H---------------------H/+-------------------------+HタイミングH---------/--->| RTP| H---------------------H/+-------------+ | Hを配列するH----1つ| | \=====================/ \ | +-----------+ | PWデマルチプレクサ|---------+--->| L2TP、MPLSなど | +---------------------+ +-------------------------+ | PSN集合|、-、-、-、-、-、-、-、-、-、-、-、--、>| 必要ではありません。| +---------------------+ +-------------------------+ | PSN|、-、-、-、-、-、-、-、-、-、-、-、--、>| IP| +---------------------+ +-------------------------+ | データ・リンク|、-、-、-、-、-、-、-、-、-、-、-、--、>| データ・リンク| +---------------------+ +-------------------------+ | 物理的|、-、-、-、-、-、-、-、-、-、-、-、--、>| 物理的| +---------------------+ +-------------------------+
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は、プロトコルがPWE3のためにIP PSNの上で層にされるのを示します。 原則として、ペイロードは必要であると提供された有効搭載量Convergence Layerと共にNSPから受け取るように運ばれるべきです。 しかしながら、ある特定の状況ではそれは何らかの処理フォームでペイロードを伝えるのにおいて正当であるかもしれません。 そのペイロードタイプのためにこの理由をEncapsulation Layer定義に記録しなければなりません。
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]によって提供されます。(使用されると、また、RTPは配列サービスを提供します)。 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カプセル化層のそばで提供しますが、両方で提供するというわけではないことです。
Bryant & Pate Standards Track [Page 25] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[25ページ]。
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ラベルはPW Demultiplexingを提供します。(それは、多くのIETFプロトコルで指定された形を取るかもしれません)。 例えば、MPLSラベル[MPLSIP]、L2TPセッションID[RFC3931]、またはUDPが数[RFC768]を移植します。 PWsがIPの上まで運ばれるとき、PSN Convergence Layerは必要でないでしょう。
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 DemultiplexerがMPLSラベルであるなら、このセクションのプロトコル構造の代わりにセクション5.4.2のプロトコル構造を使用できます。
5.4.2. PWE3 over an MPLS PSN
5.4.2. MPLS PSNの上のPWE3
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 | +---------------------+
+---------------------+ | 有効搭載量| /=====================\H有効搭載量集合H--+ H---------------------H| +--------------------------------+HタイミングH--------->| RTP| H---------------------H| +--------------------------------+ Hを配列するH--+------>| 弛んで、破片手榴弾で殺傷する、レン、Seq#など| \=====================/ | +--------------------------------+ | PWデマルチプレクサ|、-、-、-、-、-、-、-、--、>| PWラベル| +---------------------+ | +--------------------------------+ | PSN集合|--+ +--->| 外側のLabelかIPにおけるMPLS encap| +---------------------+ | +--------------------------------+ | PSN|-----+ +---------------------+ | データ・リンク| +---------------------+ | 物理的| +---------------------+
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
図11は、プロトコルがPWE3のためにMPLS PSNの上で層にされるのを示します。 内側のMPLSラベルは、PW逆多重化機能を提供するのに使用されます。 規制単語は、コンパクトな形式でPWE3 Encapsulation LayerとPSN Convergence Layerによって必要とされた情報の大部分を運ぶのに使用されます。 規制単語による旗は必要なペイロード集合を提供します。 系列分野はPSN Convergence Layer(断片化コントロール方法で、支持される)の中のオーダーにおけるペイロード配送とPSN断片化サービスの両方のサポートを提供します。 イーサネットは64バイトの最小規模にすべてのフレームを水増しします。 MPLSヘッダーは長さのインディケータを入れません。 したがって、PWE3を許容します。
Bryant & Pate Standards Track [Page 26] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[26ページ]。
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].
正しくイーサネットデータ・リンクを通り過ぎるためにMPLSで運ばれるために、長さの修正分野が規制単語で必要です。 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.
いくつかのネットワークでは、IPの上でMPLSの上までPWE3を運ぶのが必要であるかもしれません。 こういう事情ですから、PWはキャリッジのためにこのセクションで説明されるようにMPLSの上に要約されます、そして、次に、IP PSN(GRE[RFC2784]、[RFC2890]などの)の上までMPLSを運ぶ方法は結果のPW-PDUに適用されます。
5.4.3. PW-IP Packet Discrimination
5.4.3. PW-IPパケット区別
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 PSNsのために、追加規制がPWパケット・フォーマットにあります。 いくつかのラベルの切り換えられたルータがパケット含有量の初期の4ビットに基づくIPパケットを検出します。 適切な機能を容易にするために、PWパケットのこれらのビットは現在の使用でのIPバージョン番号と同じであるはずがありません。
6. PW Demultiplexer Layer and PSN Requirements
6. PWデマルチプレクサ層とPSN要件
PWE3 places three service requirements on the protocol layers used to carry it across the PSN:
PWE3はPSNの向こう側にそれを運ぶのに使用されるプロトコル層に3つのサービス要件を置きます:
o Multiplexing
o Fragmentation
o Length and Delivery
o マルチプレクシングoのFragmentation oのLengthとDelivery
6.1. Multiplexing
6.1. マルチプレクシング
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 Demultiplexer Layerの目的は複数のPWsが単一のトンネルで運ばれるのを許容することです。 これは、複雑さを最小にして、資源を節約します。
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 VCs、物理的なメディアの複数のイーサネットVLANs、またはT1か1Eの中の複数の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]の設定はアプリケーション特有です。
Bryant & Pate Standards Track [Page 27] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[27ページ]。
6.2. Fragmentation
6.2. 断片化
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 PDUsを輸送できるくらい大きい有効なMTUを入手するのに使用されるかもしれません。 PW断片化問題の十分な議論に関してセクション5.3を見てください。
6.3. Length and Delivery
6.3. 長さと配送
PDU delivery to the egress PE is the function of the PSN Layer.
出口PEへのPDU配送はPSN Layerの機能です。
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の長さを測定するためにすべての必要情報を提供するというわけではないなら、Encapsulation Layerはそれを提供しなければなりません。
6.4. PW-PDU Validation
6.4. 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行きのPDUsから取り除かれて、または次に、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エミュレーションの一部として変化するなら、それは、より効率的であるだろうに、剥取るrecalculateはチェックサムです。
The service-specific document for each protocol must describe the validation scheme to be used.
各プロトコルのためのサービス特有のドキュメントは、使用されるために合法化計画について説明しなければなりません。
6.5. Congestion Considerations
6.5. 混雑問題
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でのパケット破棄は提供された負荷の必要な減少の引き金となるでしょう、そして、どんな追加輻輳回避動作も必要ではありません。
Bryant & Pate Standards Track [Page 28] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[28ページ]。
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好意的であることが知られないなら、PEsは、許容できるパラメタの中に損失率があるのを保証するためにパケット損失をモニターするはずです。 同じネットワーク経路と同じネットワーク状態を経験することの向こう側のTCP流動が平均した妥当なスケールで測定されたスループットに、少なくともPW流動が実現しているそれを実現するなら、パケット損失は許容できると考えられます。 NSPでレートを制限する政策を実施するか、または1PWsを止めることによって、この状態を満たすことができます。 選択はどのアプローチを使用するかを運ばれる交通のタイプに頼っています。 混雑が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との比較は、まさに指定できませんが、スケールとスループットにおける1「桁」比較として意図します。 TCPスループットが測定されるスケールは接続の往復の時間です。 本質では、この要件は、1桁以内で任意に帯域幅を消費して、TCPと公正に競争しないベストエフォート型インターネットでアプリケーション(PWE3を使用するか、いかなる他のトランスポート・プロトコルも)を配備するのが許容できないと述べます。 許容できるPW帯域幅を決定する1つの方法が[RFC3448]で説明されます。
7. Control Plane
7. 制御飛行機
This section describes PWE3 control plane services.
このセクションはPWE3コントロール飛行機サービスについて説明します。
7.1. Setup or Teardown of Pseudo Wires
7.1. 疑似ワイヤのセットアップか分解
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.
オペレータコマンド、PEの管理飛行機、西暦(例えば、ATM SVC)のシグナリングセットアップか分解、または自動発見メカニズムはPWのセットアップか分解を引き起こすことができます。
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.
セットアップの過程の間、PEsは情報交換しなければなりません(例えば、互いの能力を学んでください)。 トンネルシグナリングプロトコルは、PEsがPWを代表してすべての必要事項を交換するのを可能にするメカニズムを提供するために広げられるかもしれません。
Bryant & Pate Standards Track [Page 29] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[29ページ]。
Manual configuration of PWs can be considered a special kind of signaling and is allowed.
PWsの手動の構成は、特別な種類のシグナリングであると考えることができて、許されています。
7.2. Status Monitoring
7.2. 状態モニター
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を支持します。 これらのサービスとして、対応する見習われたサービスは状態モニターを実行する方法を指定しなければなりません。
7.3. Notification of Pseudo Wire Status Changes
7.3. 疑似ワイヤ状態変化の通知
7.3.1. Pseudo Wire Up/Down Notification
7.3.1. /下に通知への疑似ワイヤ
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.
見習われたサービスの2CEsが隣接していないので、失敗はCEsとPEsとのとてもそれ、または、ともに物理的なリンクが上がり続ける場所に起こるかもしれません。 例えば、図2では、CE1とPE1との物理的なリンクが失敗すると、CE2とPE2との物理的なリンクは、影響を受けないで、上がり続けられるでしょう。 CE2がリモート失敗に関して通知されないと、それは、CE1に対する見習われたサービスの上に交通を送り続けるでしょう。 そのような交通はPE1で捨てられるでしょう。 いくつかのネイティブのサービスには、失敗通知が、サービスが失敗すると、両方のCEsが通知されるように、あります。 これらのネイティブのサービスのために、対応する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.
同様に、ネットワーク失敗が固定されているとき、すべての影響を受けるサービスが状態を“Down"から“Up"に変えるようにネイティブのサービスに通知メカニズムがあるなら、対応する見習われたサービスは同様のメカニズムをそうするのに提供しなければなりません。
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]には、この能力があります、そして、自由民主党には、対応するMPLSラベルを引っ込める能力があります。
7.3.2. Misconnection and Payload Type Mismatch
7.3.2. タイプがミスマッチする付け違いと有効搭載量
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と共に、タイプがミスマッチする付け違いとペイロードは現れることができます。 付け違いはシステムの保全を破ることができます。 有効搭載量ミスマッチは顧客ネットワークを混乱させることができます。 両方の例には、セキュリティと操作上の関心があります。
Bryant & Pate Standards Track [Page 30] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[30ページ]。
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識別子を交換します。 そして、これは、ACsの互換性について確かめるのに混載業者とNSPによって使用されます。
7.3.3. Packet Loss, Corruption, and Out-of-Order Delivery
7.3.3. パケット損失、不正、および不適切な配送
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はPEsの間のPSN経路でパケット損失、不正、および不適切な配送を被ることができます。 これは見習われたサービスに関する労働条件に影響できます。 何人かのペイロードタイプにおいて、しばらく誤り炸裂、または、PWにおけるキャリヤーの損失にパケット損失、不正、および不適切な配送を写像できます。 ネイティブのサービスに誤りがビットを取扱う何らかのメカニズムがあるなら、対応するPWE3サービスは同様のメカニズムを提供するべきです。
7.3.4. Other Status Notification
7.3.4. 他の状態通知
A PWE3 approach may provide a mechanism for other status notifications, if any are needed.
いずれか必要であるなら、PWE3アプローチは他の状態通知にメカニズムを提供するかもしれません。
7.3.5. Collective Status Notification
7.3.5. 集合的な状態通知
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で終わりそうです。 また、失敗で影響を受けるそのような倍数CEsがあるかもしれません。 したがって、ただ一つの通知メッセージが見習われたサービスの全体のグループの失敗に通知するのに使用されるのは、望ましいです。
A PWE3 approach may provide a mechanism for notifying status changes of a group of emulated circuits. One possible method is to associate each emulated service with a group ID when the PW for that emulated service is set up. Multiple emulated services can then be grouped by associating them with the same group ID. In status notification, this group ID can be used to refer all the emulated services in that group. The group ID mechanism should be a mechanism provided by the underlying tunnel signaling protocol.
PWE3アプローチは見習われたサーキットのグループの状態変化に通知するのにメカニズムを提供するかもしれません。 それがサービスを見習ったのでPWがセットアップされるとき、可能な方法が関連づけることになっている1つはそれぞれグループIDとのサービスを見習いました。 そして、同じグループIDにそれらを関連づけることによって、複数の見習われたサービスを分類できます。 状態通知では、そのグループですべての見習われたサービスを参照するのにこのグループIDを使用できます。 グループIDメカニズムは基本的なトンネルシグナリングプロトコルによって提供されたメカニズムであるべきです。
7.4. Keep-Alive
7.4. 生きている生活費
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
ネイティブのサービスに生きている生活費メカニズムがあるなら、対応する見習われたサービスは、PWの向こう側にそれを伝播するためにメカニズムを提供しなければなりません。 PWの上で透明に生きている生活費メッセージを輸送すると、最小の介入の原則は従われるでしょう。 しかしながら、再生します。
Bryant & Pate Standards Track [Page 31] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[31ページ]。
the semantics of the native mechanism accurately, some PWs may require an alternative approach, such as piggy-backing on the PW signaling mechanism.
正確に、いくつかのPWsがそうする固有のメカニズムの意味論は代替的アプローチを必要とします、PWシグナル伝達機構の上で便乗するのなどように。
7.5. Handling Control Messages of the Native Services
7.5. ネイティブのサービスに関する取り扱いコントロールメッセージ
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、またはTDM CCSシグナリングの例えば、シグナリングVC)に調子を変えさせます。
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.
最小の介入の原則を考えて、PEsができるだけ少ししかネイティブのサービスのシグナリングと維持に参加しないのは、望ましいです。 しかしながら、この原則は満足にネイティブのサービスを見習う必要性をくつがえすべきではありません。
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層で提供されたより高い優先度か高信頼のチャンネルのどちらかを使用することによってそれらを送るのは望ましいかもしれません。 PWE3チャンネル種別はセクション5.1.2を見てください。
8. Management and Monitoring
8. 管理とモニター
This section describes the management and monitoring architecture for PWE3.
このセクションはPWE3のために管理とモニターしている構造について説明します。
8.1. Status and Statistics
8.1. 状態と統計
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-PDUsのカウントは、発信して、受信されました、誤りのあるなしにかかわらず。○ サービスPDUsのカウンツは、PSNの上で発信して、受信しました、誤り(非TDM)o Service特有のインタフェースカウントo One-道の遅れと遅れ変化のあるなしにかかわらず。○ 配列されたPW-PDUsのカウンツは損をしました。
These counters would be contained in a PW-specific MIB, and they should not replicate existing MIB counters.
これらのカウンタはPW特有のMIBに含まれるでしょう、そして、それらは既存のMIBカウンタを模写するべきではありません。
Bryant & Pate Standards Track [Page 32] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[32ページ]。
8.2. PW SNMP MIB Architecture
8.2. PW SNMP 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サービスを管理するのに使用されるSNMP MIBsと基本的なPSNのために一般的な構造について説明します。 ここの意図はすべての適切なMIBsがPWE3サービスを配備するために粘着性がある管理枠組みを形成するためにどう一緒に合うかに関する鮮明な映像を提供することです。 以下で使用されたMIBモジュールの名前が、提案であり、必ず構造でコンポーネントがわかるのに使用される実際のモジュールが命名されるのを必要とするというわけではないことに注意してください。然り。
8.2.1. MIB Layering
8.2.1. 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 MIBsは図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.
構造がサポートされない見習われたサービスの接合を考慮するか、またはPSNは、新しいタイプを既存のものに関連づけるために単に追加MIBモジュールを定義することによって、タイプします。 次に、これらの新しいモジュールを標準化できます。 それぞれの見習われたサービスのための別々のMIBモジュール、およびそれぞれの基本的なPSNあたり1つがあることに注意してください。 これらのMIBモジュールは必要に応じて様々な組み合わせに使用されるかもしれません。
Bryant & Pate Standards Track [Page 33] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[33ページ]。
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 +-----------+ +-----------+
ネイティブのサービスMIBs… ... ... | | | +-----------+ +-----------+ +-----------+ サービス| ケフェウス座| | イーサネット| | 気圧| 層|サービスMIB| |サービスMIB| ... |サービスMIB| +-----------+ +-----------+ +-----------+ \ | / \ | / - - - - - - - - - - - - \ - - - | - - - - / - - - - - - - \ | / +-------------------------------------------+ 一般的なPW| 一般的なPW MIBs| 層+-------------------------------------------+ / \ - - - - - - - - - - - - / - - - - - - - - \ - - - - - - - / \ / \ +--------------+ +----------------+ PSN VC|L2TP VC MIB(s)| | MPLS VC MIB(s)| 層+--------------+ +----------------+ | | ネイティブ+-----------+ +-----------+ PSN|L2TP MIB(s)| |MPLS MIB(s)| MIBs+-----------+ +-----------+
Figure 12. MIB Module Layering Relationship
図12。 MIBモジュールレイヤリング関係
Bryant & Pate Standards Track [Page 34] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[34ページ]。
Figure 13 shows an example for a SONET PW carried over MPLS Traffic Engineering Tunnel and an LDP-signaled LSP.
図13は、SONET PWのための例がMPLS Traffic Engineering Tunnelと自由民主党によって合図されたLSPを引き継いだのを示します。
+-----------------+
| SONET MIB | RFC3592
+-----------------+
|
+------------------------------+
Service | Circuit Emulation Service MIB|
Layer +------------------------------+
- - - - - - - - - - - - - | - - - - - - - - - - - - -
+-----------------+
Generic PW | Generic PW MIB |
Layer +-----------------+
- - - - - - - - - - - - - | - - - - - - - - - - - - -
+-----------------+
PSN VC | MPLS VC MIBs |
Layer +-----------------+
| |
+-----------------+ +------------------+
| MPLS-TE-STD-MIB | | MPLS-LSR-STD-MIB |
+-----------------+ +------------------+
+-----------------+ | Sonet MIB| RFC3592+-----------------+ | +------------------------------+ サービス| サーキットエミュレーションサービスMIB| 層+------------------------------+ - - - - - - - - - - - - - | - - - - - - - - - - - - - +-----------------+ 一般的なPW| 一般的なPW MIB| 層+-----------------+ - - - - - - - - - - - - - | - - - - - - - - - - - - - +-----------------+ PSN VC| MPLS VC MIBs| 層+-----------------+ | | +-----------------+ +------------------+ | MPLS Te STD-MIB| | MPLS-LSR-STD-MIB| +-----------------+ +------------------+
Figure 13. SONET PW over MPLS PSN Service-Specific Example
図13。 MPLS PSNのサービス特有の例の上のSonet PW
8.2.2. Service Layer MIB Modules
8.2.2. サービス層のMIBモジュール
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、またはFrame Relayなどの見習われたPWE3サービスとPSNの向こう側にそのサービスを提供するのに利用された疑似ワイヤの間に関係を表すのに使用されるMIBモジュールを含んでいます。 この層は上の図13の「一般的なPW MIB」機能ブロックに表された状態で一般的な疑似ワイヤ表現に対するそれらの見習われたサービスを噛み合わせるか、または適合させるのに使用される対応するMIBモジュールを含んでいます。 このワーキンググループは一般的なサービスを管理するためのどんなMIBモジュールも作成するべきではありません。 むしろ、それは上に示されるようにまさしく見習われたサービスを連結するか、または適合させるのに使用されるそれらのモジュールをPWE3管理枠組みに作成するべきです。 例えば、標準のSonet-MIB[RFC3592]は別のワーキンググループによって設計されていて、維持されます。 Sonet-MIBは、PWエミュレーションなしでネイティブのサービスを管理するように設計されています。 しかしながら、PWE3ワーキンググループは、それらのモジュールを再発明するより疑似ワイヤの上にどのようにむしろSonet/SDHなどの既存の技術を見習うかを示す規格を生産するためにチャーターされます。
Bryant & Pate Standards Track [Page 35] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[35ページ]。
8.2.3. Generic PW MIB Modules
8.2.3. 一般的なPW MIBモジュール
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).
構造の中間層はGeneric PW Layerと呼ばれます。 この層のMIBsは疑似ワイヤの特定のカウンタとPWE3サービスのモニターと構成に使用されるサービスモデルをどんな支持されたPSNサービスの上にも提供するのに責任があります。 すなわち、この層は管理目的のためのPWE3抽象化の一般的なモデルを提供します。 このMIBは、Service LayerにPSN VC Layer MIBsにあるMIBモジュールとインタコネクトするのに使用されます(セクション8.2.4を見てください)。
8.2.4. PSN VC Layer MIB Modules
8.2.4. PSN VC層のMIBモジュール
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 Layerと呼ばれます。 それはPSNの向こう側に疑似ワイヤペイロードを運ぶそれらの基本的なPSN輸送技術に疑似ワイヤを関連づけるように明確に設計されているMIBsで構成されます。 一般に、これは、MIBモジュールがService Layerを通して疑似ワイヤに写像される見習われたサービスとGeneric PW MIB Layerの間のマッピングをネイティブのPSNサービスに提供することを意味します。 例えば、MPLSの場合では、例えば、一般的なVCサービスがMPLS-TE-STD-MIB[RFC3812]を通してMPLS-LSR-STD-MIB[RFC3813]かTrafficによって設計された(TE)Tunnelsを通してMPLS LSPsに写像されるのが必要です。 さらに、MPLS自由民主党STD-MIB[RFC3815]は、PWサービスを維持するためにMPLS PSNの上に分配されるMPLSラベルを明らかにするのに使用されるかもしれません。 より早く説明された、固有のサービスMIBモジュールのように、ネイティブのPSNサービスを管理するのに使用されるMIBモジュールはネイティブのPSNサービスを設計して、指定する他のワーキンググループによって作成されます。 これらのMIBsはモニターのための適切な手段を含むはずです、そして、見習われたPWE3が修理するPSNサービスを構成するのは正しく機能するでしょう。
8.3. Connection Verification and Traceroute
8.3. 接続検証とトレースルート
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.
接続検証メカニズムはPWsによってサポートされるはずです。 接続検証と他のアラームメカニズムは、PWがリモート接続を失ったとオペレータに警告できます。 PWの不明瞭な自然は、PWの上のCEsにこの状態を通過する一般的な接続検証かトレースルートメカニズムを指定するのが可能でないことを意味します。 PWの接続検証状態がCEによって必要とされるなら、固有の接続形態方法にそれを写像しなければなりません。
For troubleshooting purposes, it is sometimes desirable to know the exact functional path of a PW between PEs. This is provided by the traceroute service of the underlying PSN. The opaque nature of the PW means that this traceroute information is only available within the provider network; e.g., at the PEs.
トラブルシューティング目的のために、PEsの間のPWの正確な機能的な経路を知るのは時々望ましいです。 基本的なPSNのトレースルートサービスでこれを提供します。 PWの不明瞭な自然は、このトレースルート情報がプロバイダーネットワークの中で利用可能であるだけであることを意味します。 例えば、PEsで。
Bryant & Pate Standards Track [Page 36] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[36ページ]。
9. IANA Considerations
9. IANA問題
IANA considerations will be identified in the PWE3 documents that define the PWE3 encapsulation, control, and management protocols.
IANA問題はPWE3カプセル化、コントロール、および管理プロトコルを定義するPWE3ドキュメントで特定されるでしょう。
10. Security Considerations
10. セキュリティ問題
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の何人かのタイプで運ばれている状態でそれらがインタコネクトされるとき、すべての交信システムがポイントツーポイントか回路交換ネットワークを通してインタコネクトされるとき適切であるかもしれない仮定はもう成立しないかもしれません。 PWE3の危険を完全に分析して、見直すために、この仕様の範囲の外にそれはあります、特にこれらの危険がPSNによるとき。 例は関心を明らかにするべきです。 交信ノードによって同じローカル・エリア・ネットワークに関連づけられると予想されるとき、多くのIETF規格が比較的弱いセキュリティー対策を使います。 Virtual Router Redundancyプロトコル[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 Tunnelエンドポイントに向けられるかもしれないので、PW DemultiplexerとPSNトンネルサービスは中断します。 PW TunnelエンドポイントへのPSNアクセスを制御するのはこれから守ることにおいて一方通行です。 交通の正統のリモートPE源へのPW Tunnelエンドポイントアクセスを制限することによって、PEはPW Demultiplexingを妨げる交通と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 Demultiplexerエンドポイントに記述された交通の合法化はPWカプセル化の保全を確実にすることにおいて最高のです。 IPSec[RFC2401]などのセキュリティプロトコルは、PW Demultiplexer End-ポイントの間にデータの認証とデータ保全を提供するのにPW Demultiplexer Layerによって使用されるかもしれません。
IPSec may provide authentication, integrity, and confidentiality, of data transferred between two PEs. It cannot provide the equivalent services to the native service.
IPSecは2PEsの間に移されたデータの認証、保全、および秘密性を提供するかもしれません。 それはネイティブのサービスに対する同等なサービスを提供できません。
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,
移されるデータのタイプに基づいて、PWは、警備の強化サービスが必要であることをPW Demultiplexer Layerに示すかもしれません。 PW Demultiplexer LayerはPWの要件に基づく多重防護プロフィールを定義するかもしれません。サービスを見習いました。 CEへのCEシグナリングとPWといくつかのデータ型によって見習われたコントロールイベントが追加保護メカニズムを必要とするかもしれない、代わりに。
Bryant & Pate Standards Track [Page 37] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[37ページ]。
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.
あらゆるPSNパケットが、だまされたネイティブのデータ単位が目的地CEに送られるのを防ぐのにPW Demultiplexer Layerは同輩認証を使用するかもしれません。
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が予想されるように振る舞うのを保証するために十分です。
11. Acknowledgements
11. 承認
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.
私たちはバックグラウンドに対する彼の仕事とPWsに関する動機のためにPWサービスとトーマス・K.ジョンソンの上でネイティブのService Processingへの彼の作業とビットストリームに関するアドバイスについてサシャVainshteinに感謝します。
We also thank Ron Bonica, Stephen Casner, Durai Chinnaiah, Jayakumar Jayakumar, Ghassem Koleyni, Danny McPherson, Eric Rosen, John Rutemiller, Scott Wainner, and David Zelig for their comments and contributions.
また、私たちはロンBonicaに感謝します、スティーブンCasner、Durai Chinnaiah、Jayakumar Jayakumar、Ghassem Koleyni、ダニーMcPherson、エリック・ローゼン、ジョンRutemiller、スコット。Wainner、および彼らのコメントと貢献のためのデヴィッドZelig。
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two
Tunneling Protocol - Version 3 (L2TPv3), RFC 3931, March
2005.
[RFC3931] ラウ、J.、Townsley、M.、およびI.Goyretは「2005年3月にバージョン3(L2TPv3)、RFC2トンネリングプロトコル--3931を層にします」。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC768] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.
[RFC2474] ニコルズ、K.、ブレーク、S.、ベイカー、F.、およびD.黒、「IPv4とIPv6ヘッダーとの微分されたサービス分野(DS分野)の定義」、RFC2474(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)のための管理オブジェクトの定義はタイプを連結します」、RFC3592、2003年9月。
Bryant & Pate Standards Track [Page 38] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[38ページ]。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, August 1999.
[RFC2661]Townsley、W.、バレンシア、A.、ルーベン、A.、祭服、G.、ゾルン、G.、およびB.はあしらいます、「層Twoはプロトコル"L2TP"にトンネルを堀っ」て、RFC2661、1999年8月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
2000年3月の[RFC2784]ファリナッチとD.と李とT.とハンクスとS.とマイヤー、D.とP.Traina、「一般ルーティングのカプセル化(GRE)」RFC2784。
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, September 2000.
[RFC2890] Dommety、G.、「GREへのキーと一連番号拡大」、RFC2890、2000年9月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3032] ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、「MPLSラベルスタックコード化」、RFC3032(2001年1月)。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
12.2. Informative References
12.2. 有益な参照
[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)を放送する[DVB]アン300 744デジタルビデオ。 地上波デジタル・テレビジョン(DVB-T)、ヨーロッパのTelecommunications Standards Institute(ETSI)のために構造、チャンネル・コーディング、および変調を縁どっています。
[RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani,
"Definitions of Managed Objects for the Multiprotocol
Label Switching (MPLS), Label Distribution Protocol
(LDP)", RFC 3815, June 2004.
[RFC3815] Cucchiara、J.、シェストランド、H.、およびJ.Luciani、「Multiprotocolラベル切り換え(MPLS)のための管理オブジェクトの定義、ラベル分配は(自由民主党)について議定書の中で述べます」、RFC3815、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.ナドー、「Multiprotocolはラベル切り換えルータ(LSR)管理情報ベース(MIB)と切り換え(MPLS)をラベルします」、RFC3813、2004年6月。
[MPLSIP] Rosen et al, "Encapsulating MPLS in IP or Generic Routing
Encapsulation (GRE)", Work in Progress, March 2004.
[MPLSIP] ローゼン他、「IPか一般ルーティングのカプセル化(GRE)でMPLSを要約します」、Progress、2004年3月のWork。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC1191] ムガール人とJ.とS.デアリング、「経路MTU探索」、RFC1191、1990年11月。
[RFC1958] Carpenter, B., "Architectural Principles of the
Internet", RFC 1958, June 1996.
[RFC1958] 1996年6月の大工、B.、「インターネットの建築プリンシプルズ」RFC1958。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU
Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] マッキャン、J.、デアリング、S.、およびJ.ムガール人、「IPのための経路MTUディスカバリー、バージョン6インチ、RFC1981、1996インチ年8月。
Bryant & Pate Standards Track [Page 39] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[39ページ]。
[RFC2022] Armitage, G., "Support for Multicast over UNI 3.0/3.1
based ATM Networks", RFC 2022, November 1996.
[RFC2022] アーミテージ、G.、「UNI3.0/3.1の上のMulticastのサポートはATM Networksを基礎づけた」RFC2022、1996年11月。
[RFC3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)",
RFC 3768, April 2004.
[RFC3768]Hinden、2004年4月のR.、「仮想のルータ冗長プロトコル(VRRP)」RFC3768。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January
2001.
[RFC3022] SrisureshとP.とK.Egevang、「伝統的なIPネットワークアドレス変換機構(伝統的なNAT)」、RFC3022、2001年1月。
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification",
RFC 3448, January 2003.
[RFC3448] ハンドレー、M.、フロイド、S.、Padhye、J.、およびJ.ウィトマー、「TCPの好意的なレートは(TFRC)を制御します」。 「プロトコル仕様」、RFC3448、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.ナドー、「Multiprotocolは交通工学(Te)管理情報ベース(MIB)と切り換え(MPLS)をラベルします」、RFC3812、2004年6月。
[RFC3916] Xiao, X., McPherson, D., and P. Pate, Eds, "Requirements
for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916,
September 2004.
2004年9月の[RFC3916]XiaoとX.とマクファーソン、D.とP.頭、Eds、「疑似ワイヤエミュレーション縁から縁への(PWE3)のための要件」RFC3916。
13. Co-Authors
13. 共著者
The following are co-authors of this document:
↓これはこのドキュメントの共著者です:
Thomas K. Johnson Litchfield Communications
トーマスK.ペニスリッチフィールドコミュニケーション
Kireeti Kompella Juniper Networks, Inc.
Kireeti Kompella杜松はInc.をネットワークでつなぎます。
Andrew G. Malis Tellabs
アンドリューG.Malis Tellabs
Thomas D. Nadeau Cisco Systems
トーマスD.ナドーシスコシステムズ
Tricci So Caspian Networks
Tricciのとてもカスピ海のネットワーク
W. Mark Townsley Cisco Systems
W.マークTownsleyシスコシステムズ
Bryant & Pate Standards Track [Page 40] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[40ページ]。
Craig White Level 3 Communications, LLC.
クレイグ白レベル3 コミュニケーション、LLC。
Lloyd Wood Cisco Systems
ロイドWoodシスコシステムズ
14. Editors' Addresses
14. エディタのアドレス
Stewart Bryant Cisco Systems 250, Longwater Green Park Reading, RG2 6GB, United Kingdom
スチュワートブライアントシスコシステムズ250、Longwaterグリーンパーク読書、RG2 6GB、イギリス
EMail: stbryant@cisco.com
メール: stbryant@cisco.com
Prayson Pate Overture Networks, Inc. 507 Airport Boulevard Morrisville, NC, USA 27560
Prayson頭のオーバーチュアはMorrisville、NC米国 Inc.507空港並木街27560をネットワークでつなぎます。
EMail: prayson.pate@overturenetworks.com
メール: prayson.pate@overturenetworks.com
Bryant & Pate Standards Track [Page 41] RFC 3985 PWE3 Architecture March 2005
ブライアントと頭の規格は2005年のPWE3構造行進のときにRFC3985を追跡します[41ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Bryant & Pate Standards Track [Page 42]
ブライアントと頭の標準化過程[42ページ]
一覧
スポンサーリンク
