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