RFC2843 日本語訳
2843 Proxy-PAR. P. Droz, T. Przygienda. May 2000. (Format: TXT=27891 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Droz
Request for Comments: 2843 IBM
Category: Informational T. Przygienda
Siara
May 2000
コメントを求めるワーキンググループP.ドローの要求をネットワークでつないでください: 2843年のIBMカテゴリ: 情報のT.Przygienda Siara2000年5月
Proxy-PAR
プロキシ平価
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 (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
Proxy-PAR is a minimal version of PAR (PNNI Augmented Routing) that gives ATM-attached devices the ability to interact with PNNI devices without the necessity to fully support PAR. Proxy-PAR is designed as a client/server interaction, of which the client side is much simpler than the server side to allow fast implementation and deployment.
プロキシ-PARはPARを完全にサポートする必要性なしでPNNIデバイスと対話する能力をATMが付属しているデバイスに与えるPAR(PNNI Augmentedルート設定)の最小量のバージョンです。 プロキシ-PARはクライアント/サーバ相互作用として設計されています。(クライアント側は速い実装と展開を許すのはサーバ側よりはるかにそれで簡単です)。
The purpose of Proxy-PAR is to allow non-ATM devices to use the flooding mechanisms provided by PNNI for registration and automatic discovery of services offered by ATM attached devices. The first version of PAR primarily addresses protocols available in IPv4. But it also contains a generic interface to access the flooding of PNNI. In addition, Proxy-PAR-capable servers provide filtering based on VPN IDs [1], IP protocols and address prefixes. This enables, for instance, routers in a certain VPN running OSPF to find OSPF neighbors on the same subnet. The protocol is built using a registration/query approach where devices can register their services and query for services and protocols registered by other clients.
Proxy-PARの目的が非ATMデバイスがPNNIによって登録に提供された氾濫メカニズムを使用するのを許容することであり、自動ATMによって提供されたサービスの発見はデバイスを取り付けました。 PARの最初のバージョンは主としてIPv4で利用可能なプロトコルを扱います。 しかし、また、それはPNNIの氾濫にアクセスするジェネリックインタフェースを含んでいます。 さらに、Proxy-PARできるサーバは、VPNに基づいてID[1]、IPプロトコル、およびアドレス接頭語をフィルターにかけながら、提供されます。 これは、例えば、あるVPN実行しているOSPFのルータが同じサブネットでOSPF隣人を見つけるのを可能にします。 登録/質問アプローチを使用するのはデバイスが他のクライアントによって登録されたサービスとプロトコルのための彼らのサービスと質問を登録できるところにプロトコルに建てられます。
1 Introduction
1つの序論
In June of 1996, the ATM Forum accepted the "Proxy-PAR contribution as minimal subset of PAR" as a work item of the Routing and Addressing (RA) working group, which was previously called the PNNI working group [2]. The PAR [3] specification provides a detailed description of the protocol including state machines and packet formats.
1996年6月に、ATM Forumはルート設定とAddressing(RA)ワーキンググループの仕事項目として「PARの最小量の部分集合としてのプロキシ-PAR貢献」を認めました。(ワーキンググループは、以前に、PNNIワーキンググループ[2]と呼ばれました)。 PAR[3]仕様は州のマシンとパケット・フォーマットを含むプロトコルの詳述を提供します。
Droz & Przygienda Informational [Page 1] RFC 2843 Proxy-PAR May 2000
[1ページ]RFC2843プロキシ平価2000年5月の情報のドローとPrzygienda
The intention of this document is to provide general information about Proxy-PAR. For the detailed protocol description we refer the reader to [3].
このドキュメントの意志はProxy-PARに関して一般情報を提供することです。 詳細なプロトコル記述について、私たちは読者を[3]に差し向けます。
Proxy-PAR is a protocol that allows various ATM-attached devices (ATM and non-ATM devices) to interact with PAR-capable switches to exchange information about non-ATM services without executing PAR themselves. The client side is much simpler in terms of implementation complexity and memory requirements than a complete PAR instance. This should allow an easy implementation on existing IP devices such as IP routers. Additionally, clients can use Proxy-PAR to register various non-ATM services and the protocols they support. The protocol has deliberately been omitted from ILMI [4] because of the complexity of PAR information passed in the protocol and the fact that it is intended for the integration of non-ATM protocols and services only. A device executing Proxy-PAR does not necessarily need to execute ILMI or UNI signalling, although this will normally be the case.
プロキシ-PARは様々なATMが付属しているデバイス(ATMと非ATMデバイス)がPARを実行することのない非ATMサービス自体に関して情報交換するためにPARできるスイッチと対話できるプロトコルです。 クライアント側は完全なPARインスタンスよりはるかに実装の複雑さとメモリ要件で簡単です。 これはIPルータなどの既存のIPデバイスで簡単な実装を許容するべきです。 さらに、クライアントは、様々な非ATMサービスとそれらがサポートするプロトコルを登録するのにProxy-PARを使用できます。 プロトコルはプロトコルで通過されたPAR情報の複雑さと非ATMプロトコルの、そして、サービスだけの統合のために意図するという事実のために故意にILMI[4]から省略されました。 Proxy-PARを実行するデバイスは、必ずILMIかUNI合図を実行する必要があるというわけではありません、これが通常そうになるでしょうが。
The protocol does not specify how a client should make use of the obtained information to establish connectivity. For example, OSPF routers finding themselves through Proxy-PAR could establish a full mesh of P2P VCs by means of RFC2225 [5], or use RFC1793 [6] to interact with each other. LANE [7] or MARS [8] could be used for the same purpose. It is expected that the guidelines defining how a certain protocol can make use of Proxy-PAR should be produced by the appropriate working group or standardization body responsible for the particular protocol. An additional RFC [9] describing how to run OSPF together with Proxy-PAR is published together with this document.
プロトコルはクライアントが接続性を証明するのにどう得られた情報を利用するべきであるかを指定しません。 例えば、気付くとProxy-PARを通しているOSPFルータは、RFC2225[5]によってP2P VCsの完全なメッシュを設立するか、または互いに対話するのにRFC1793[6]を使用するかもしれません。 同じ目的にレイン[7]か火星[8]を使用できました。 あるプロトコルがどうProxy-PARを利用できるかを定義するガイドラインが特定のプロトコルに原因となる適切なワーキンググループか標準化本体によって作り出されるべきであると予想されます。 Proxy-PARと共にOSPFを実行する方法を説明する追加RFC[9]はこのドキュメントと共に発行されます。
The protocol has the ability to provide ATM address resolution for IP-attached devices, but such resolutions can also be achieved by other protocols under specification in the IETF, e.g. [10]. Again, the main purpose of the protocol is to allow the automatic detection of devices over an ATM cloud in a distributed fashion, omitting the usual pitfalls of server-based solutions. Last but not least, it should be mentioned here as well that the protocol complements and coexists with the work done in the IETF on server detection via ILMI extensions [11,12,13].
プロトコルには、IPが付属しているデバイスのためのATMアドレス解決を提供する能力がありますが、また、他のプロトコルはIETF(例えば、[10])の仕様に基づきそのような解決を達成できます。 一方、プロトコルの主な目的はATM雲の上で分配されたファッションでデバイスの自動検出を許すことです、サーバベースのソリューションのよくある落とし穴を省略して。 また、最後、しかし、特に、プロトコルがサーバ検出のときにIETFでILMI拡張子[11、12、13]で行われた仕事の補足となって、共存するとここに言及されるべきです。
2 Proxy-PAR Operation and Interaction with PNNI
PNNIとの2のプロキシ平価操作と相互作用
The protocol is asymmetric and consists of a discovery and query/registration part. The discovery is very similar to the existing PNNI Hello protocol and is used to initiate and maintain communication between adjacent clients and servers. The registration and update part execute after a Proxy-PAR adjacency has been established. The client can register its own services by sending
プロトコルは、非対称であり、発見と質問/登録部分から成ります。 発見は、既存のPNNI Helloプロトコルと非常に同様であり、隣接しているクライアントとサーバとのコミュニケーションを開始して、維持するのに使用されます。 Proxy-PAR隣接番組が確立された後に部分が実行する登録とアップデート。 クライアントは、発信することによって、それ自身のサービスを登録できます。
Droz & Przygienda Informational [Page 2] RFC 2843 Proxy-PAR May 2000
[2ページ]RFC2843プロキシ平価2000年5月の情報のドローとPrzygienda
registration messages to the server. The client obtains information it is interested in by sending query messages to the server. When the client needs to change its set of registered protocols, it has to re-register with the server. The client can withdraw all registered services by registering a null set of services. It is important to note that the server side does not push new information to the client, neither does the server keep any state describing which information the client received. It is the responsibility of the client to update and refresh its information and to discover new clients or update its stored information about other clients by issuing queries and registrations at appropriate time intervals. This simplifies the protocol, but assumes that the client will not store and request large amounts of data. The main responsibility of the server is to flood the registered information through the PNNI cloud such that potential clients can discover each other. The Proxy-PAR server side also provides filtering functions to support VPNs and IP subnetting. It is assumed that services advertised by Proxy-PAR will be advertised by a relatively small number of clients and be fairly stable, so that polling and refreshing intervals can be relatively long.
. クライアントがそれが発信することによって興味を持っている情報を得るというサーバへの登録メッセージはサーバにメッセージについて質問します。クライアントが、登録されたプロトコルのセットを変える必要があると、それはサーバに再登録されなければなりません。クライアントは、サービスの零集合を登録することによって、すべての登録されたサービスを引き下がらせることができます。 サーバ側がクライアントに新情報を押さないことに注意するのが重要であり、クライアントがどの情報を受け取ったかを説明するいずれも述べるサーバ生活費もそうしません。 他のクライアントに関して適切な時期間隔を置いて質問と登録証明書を発行することによって情報をアップデートして、リフレッシュして、新しいクライアントを発見するか、または記憶された情報をアップデートするのが、クライアントの責任です。 これは、プロトコルを簡素化しますが、クライアントが多量のデータを保存して、要求しないと仮定します。 サーバの主な責任は可能なクライアントが互いを発見できるようにPNNI雲を通して登録された情報をあふれさせることです。 また、Proxy-PARサーバ側はサポートVPNsとIPサブネッティングにフィルタ機能を供給します。 Proxy-PARによって広告に掲載されたサービスが比較的少ない数のクライアントによって広告を出されて、かなり安定すると思われます、世論調査と壮快な間隔が比較的長くなるように。
The Proxy-PAR extensions rely on appropriate flooding of information by the PNNI protocol. When the client side registers or re-registers a new service through Proxy-PAR, it associates an abstract membership scope with the service. The server side maps this membership scope into a PNNI routing level that restricts the flooding. This allows changes of the PNNI routing level without reconfiguration of the client. In addition, the server can set up the mapping table such that a client can flood information only to a certain level. Nodes within the PNNI network take into account the associated scope of the information when it is flooded. It is thus possible to exploit the PNNI routing hierarchy by announcing different protocols on different levels of the hierarchy, e.g. OSPF could be run inside certain peer groups, whereas BGP could be run between the set of peer -groups running OSPF. Such an alignment or mapping of non-ATM protocols to the PNNI hierarchy can drastically enhance the scalability and flexibility of Proxy-PAR service. Figure 1 helps visualize such a scenario. For this topology the following registrations are issued:
Proxy-PAR拡張子はPNNIプロトコルで情報の適切な氾濫を当てにします。 クライアント側がProxy-PARを通した新しいサービスを登録するか、または再登録するとき、それは抽象的な会員資格範囲をサービスに関連づけます。 サーバ側は氾濫を制限するPNNIルーティングレベルにこの会員資格範囲を写像します。 これはクライアントの再構成なしでPNNIルーティングレベルの変化を許容します。 さらに、サーバは、クライアントが、あるレベルだけへ情報をあふれさせることができるように、マッピングテーブルをセットアップできます。 PNNIネットワークの中のノードはそれがいつ水につかっているかという情報の関連範囲を考慮に入れます。 その結果、階層構造の異なったレベルの異なったプロトコル、例えば、あるピアグループでOSPFを実行できましたが、BGPで稼働できたと発表することによってPNNIルーティング階層構造を利用するために、同輩のセットが実行しているOSPFから構成されているのは、可能です。 PNNI階層構造への非ATMプロトコルに関するそのような整列かマッピングがProxy-PARサービスのスケーラビリティと柔軟性を抜本的に高めることができます。 図1は、そのようなシナリオを想像するのを助けます。 このトポロジーに関しては、以下の登録証明書は発行されます:
Droz & Przygienda Informational [Page 3] RFC 2843 Proxy-PAR May 2000
[3ページ]RFC2843プロキシ平価2000年5月の情報のドローとPrzygienda
+-+
| | PNNI peer group # PPAR capable @ PNNI capable * Router
+-+ switch switch
+-+ | | できるPNNIできる*ルータ++スイッチピアグループ#PPAR@PNNIスイッチ
Level 40
+---------------------------+
| |
| |
| @ ---- @ ---- @ |
| | | |
+----- | ----------- | -----+
| |
Level 60 | |
+------------- | ---+ +-- | --------------+
| | | | | |
R1* ------#-P1------@ | | @---------P3-#------- * R3
| | | | | |
R2* ------#-P2------+ | | +---------P4-#------- * R4
| | | |
+-------------------+ +-------------------+
レベル40 +---------------------------+ | | | | | @ ---- @ ---- @ | | | | | +----- | ----------- | -----+ | | レベル60| | +------------- | ---+ +-- | --------------+ | | | | | | R1*------#-P1------@ | | @---------P3-#------- * R3| | | | | | R2*------#-P2------+ | | +---------P4-#------- * R4| | | | +-------------------+ +-------------------+
Figure 1: OSPF and BGP scalability with Proxy-PAR autodetection
(ATM topology).
図1: Proxy-PAR autodetection(ATMトポロジー)があるOSPFとBGPスケーラビリティ。
1. R1 registers OSPF protocol as running on the IP interface
1.1.1.1 and subnet 1.1.1/24 with scope 60
1. R1レジスタOSPFはIPインタフェース1.1.1で範囲60で.1とサブネット1.1.1/24を実行するとして議定書を作ります。
2. R2 registers OSPF protocol as running on the IP interface
1.1.1.2 and subnet 1.1.1/24 with scope 60
2. R2レジスタOSPFはIPインタフェース1.1.1で範囲60で.2とサブネット1.1.1/24を実行するとして議定書を作ります。
3. R3 registers OSPF protocol as running on the IP interface
1.1.2.1 and subnet 1.1.2/24 with scope 60
3. R3レジスタOSPFはIPインタフェース1.1.2で範囲60で.1とサブネット1.1.2/24を実行するとして議定書を作ります。
4. R4 registers OSPF protocol as running on the IP interface
1.1.2.2 and subnet 1.1.2/24 with scope 60
4. R4レジスタOSPFはIPインタフェース1.1.2で範囲60で.2とサブネット1.1.2/24を実行するとして議定書を作ります。
and
そして
1. R1 registers BGP4 protocol as running on the IP interface
1.1.3.1 and subnet 1.1/16 with scope 40 within AS101
1. R1レジスタBGP4はAS101の中でIPインタフェース1.1.3で範囲40で.1とサブネット1.1/16を実行するとして議定書を作ります。
2. R3 registers BGP4 protocol as running on the IP interface
1.1.3.2 and subnet 1.1/16 with scope 40 within AS100
2. R3レジスタBGP4はAS100の中でIPインタフェース1.1.3で範囲40で.2とサブネット1.1/16を実行するとして議定書を作ります。
Droz & Przygienda Informational [Page 4] RFC 2843 Proxy-PAR May 2000
[4ページ]RFC2843プロキシ平価2000年5月の情報のドローとPrzygienda
For simplicity the real PNNI routing level have been specified, which are 60 and 40. Instead of these two values the clients would use an abstract membership scope "local" and "local+1". In addition, all registered information would be part of the same VPN ID.
簡単さとして、レベルを発送する本当のPNNI(60と40歳である)は指定されました。 これらの2つの値の代わりに、クライアントは「地方抽象的な会員資格範囲の」と「地方の+1」を使用するでしょう。 さらに、すべての登録された情報が同じVPN IDの一部でしょう。
Table 1 describes the resulting distribution and visibility of registrations and whether the routers not only see but also utilize the received information. After convergence of protocols and the building of necessary adjacencies and sessions, the overlying IP topology is illustrated in Figure 2.
テーブル1は登録証明書とルータが見るだけではなく、受信された情報を利用もするかどうかに関して結果として起こる分配と目に見えることについて説明します。 プロトコルの集合と必要な隣接番組とセッションのビルの後に、付加IPトポロジーは図2で例証されます。
AS101 DMZ AS100
######### ##########
# #
| # | # |
+-- R1 ---------+ # R4 --+
| # | # |
| # | BGP4 on # OSPF on |
| OSPF on # | subnet # subnet |
| subnet # | 1.1/16 # 1.1.2/24 |
| 1.1.1/24 # | # |
| # +------------------- R3 --+
+-- R2 # | # |
| # #
######### ##########
AS101非武装地帯AS100#####################| # | # | +--R1---------+ #R4--+| # | # | | # | #OSPFでの存在BGP4| | #のOSPF| サブネット#サブネット| | サブネット#| 1.1/16 # 1.1.2/24 | | 1.1.1/24 # | # | | # +------------------- R3--+ +--R2#| # | | # # ######### ##########
Figure 2: OSPF and BGP scalability with Proxy-PAR autodetection
(IP topology).
図2: Proxy-PAR autodetection(IPトポロジー)があるOSPFとBGPスケーラビリティ。
Expressing the above statements differently, one can say that if the scope of the Proxy-PAR information indicates that a distribution beyond the boundaries of the peer group is necessary, the leader of a peer group collects such information and propagates it into a higher layer of the PNNI hierarchy. As no assumptions except scope values can normally be made about the information distributed (e.g. IP addresses bound to AESAs are not assumed to be aligned with them in any respect), such information cannot be summarized. This makes a careful handling of scopes necessary to preserve the scalability of the approach as described above.
上の声明を異なって表して、人は、Proxy-PAR情報の範囲が、ピアグループの限界を超えた分配が必要であることを示すなら、ピアグループのリーダーがPNNI階層構造の、より高い層の中にそのような情報を集めて、それを伝播すると言うことができます。 分配された情報に関して通常範囲値以外の仮定を全くすることができないので(例えばAESAsに縛られたIPアドレスによってどんな点でも彼らに並べられるのは思われません)、そのような情報をまとめることができません。 これで、範囲の慎重な取り扱いは上で説明されるようにアプローチのスケーラビリティを保存するのに必要になります。
Droz & Przygienda Informational [Page 5] RFC 2843 Proxy-PAR May 2000
[5ページ]RFC2843プロキシ平価2000年5月の情報のドローとPrzygienda
Reg# 1. 2. 3. 4. 5. 6.
Router#
-----------------------------
R1 R U R U
R2 U R Q Q
R3 R U R U
R4 U R Q Q
レッジ#1。 2. 3. 4. 5. 6. ルータ#----------------------------- R1R U R U R2U R Q Q R3R U R U R4U R Q Q
R registered
Q seen through query
U used (implies Q)
RはUが使用した質問が乗り切られたQを登録しました。(Qを含意します)
Table 1: Flooding scopes of Proxy-PAR registrations.
テーブル1: Proxy-PAR登録証明書の範囲をあふれさせます。
3 Proxy-PAR Protocols
3 プロキシ平価プロトコル
3.1 Hello Protocol
3.1に、こんにちは、プロトコル
The Proxy-PAR Hello Protocol is closely related to the Hello protocol specified in [2]. It uses the same packet header and version negotiation methods. For the sake of simplicity, states that are irrelevant to Proxy-PAR have been removed from the original PNNI Hello protocol. The purpose of the Proxy-PAR Hello protocol is to establish and maintain a Proxy-PAR adjacency between the client and server that supports the exchange of registration and query messages. If the protocol is executed across multiple, parallel links between the same server and client pair, individual registration and query sessions are associated with a specific link. It is the responsibility of the client and server to assign registration and query sessions to the various communication instances. Proxy-PAR can be run in the same granularity as ILMI [4] to support virtual links and VP tunnels.
Proxy-PAR Helloプロトコルは密接に[2]で指定されたHelloプロトコルに関連します。 それは同じパケットのヘッダーとバージョン交渉メソッドを使用します。 簡単にするために、オリジナルのPNNI HelloプロトコルからProxy-PARと無関係の州を取り除きました。 Proxy-PAR Helloプロトコルの目的は、クライアントとサーバの間の登録と質問メッセージの交換をサポートするProxy-PAR隣接番組を確立して、維持することです。 プロトコルが同じサーバとクライアント組との複数の、そして、平行なリンクの向こう側に実行されるなら、個々の登録と質問セッションは特定のリンクに関連しています。 様々なコミュニケーションインスタンスに登録を割り当てて、セッションについて質問するのは、クライアントとサーバの責任です。 プロキシ-PARは仮想のリンクとVPがトンネルであるとサポートするためにILMI[4]と同じ粒状に立候補することであるかもしれません。
In addition to the PNNI Hello, the Proxy-PAR Hellos travelling from the server to the client inform the client about the lifetime the server assigns to registered information. The client has to retrieve this interval from the Hello packet and set its refresh interval to a value below the obtained time interval in order to avoid the aging out of registered information by the server.
PNNI Helloに加えて、サーバからクライアントまで旅行するProxy-PARハローズはサーバが登録された情報に割り当てるおよそ生涯クライアントに知らせます。 クライアントがHelloパケットからのこの間隔を検索して、セットしなければならない、それ、サーバで登録された情報からの年をとることを避けるために得られた時間間隔の下の値に間隔をリフレッシュしてください。
3.2 Registration/Query Protocol
3.2 登録/質問プロトコル
The registration and query protocols enable the client to announce and learn about protocols supported by the clients. All query/register operations are initiated by the clients. The server never tries to push information to the client. It is the client's responsibility to register and refresh the set of protocols supported
登録と質問プロトコルは、クライアントがクライアントによってサポートされたプロトコルに関して発表して、学ぶのを可能にします。 すべての質問/レジスタ操作がクライアントによって開始されます。 サーバはクライアントに情報を決して押そうとしません。 サポートされたプロトコルのセットを登録して、リフレッシュするのは、クライアントの責任です。
Droz & Przygienda Informational [Page 6] RFC 2843 Proxy-PAR May 2000
[6ページ]RFC2843プロキシ平価2000年5月の情報のドローとPrzygienda
and to re-register them when changes occur. In the same sense, the client must query the information from the server at appropriate time intervals if it wishes to obtain the latest information. It is important to note that neither client nor server is supposed to cache any state information about the information stored by the other side.
そして、変化であるときに、それらを再登録するには、起こってください。 同じ意味で、適切な時期間隔を置いて、最新情報を得たいなら、クライアントはサーバからの情報について質問しなければなりません。 クライアントもサーバも反対側によって保存された情報のどんな州の情報もキャッシュするべきでないことに注意するのは重要です。
Registered information is associated with an ATM address and scope inside the PNNI hierarchy. From the IP point of view, all information is associated with a VPN ID, IP address, subnet mask, and IP protocol family. In this context, each VPN refers to a completely separated IP address space. For example <A, 194.194.1.01, 255.255.255.0, OSPF> describes an OSPF interface in VPN A. In addition to the IP scope further parameters can be registered that contain more detailed information about the protocol itself. In the above example this would be OSPF-specific information such as the area ID or router priority. However, Proxy-PAR server takes only the ATM and IP- specific information into account when retrieving information that was queried. Protocol specific information is never looked at by a Proxy-PAR server.
登録された情報はPNNI階層構造でATMアドレスと範囲に関連しています。 IP観点から、すべての情報がVPN ID、IPアドレス、サブネットマスク、およびIPプロトコルファミリーに関連しています。 このような関係においては、各VPNは完全に切り離されたIPアドレス空間について言及します。 OSPF>はVPN A.でOSPFインタフェースについて説明します。例えば、<A、194.194 .1 .01 255.255 .255 .0 IPへのIn追加は、プロトコル自体の、より詳細な情報を含むパラメタを示すことができるのをさらに見ます。 上記の例では、これは領域IDかルータ優先権などのOSPF-特殊情報でしょう。 しかしながら、質問された情報を検索するとき、Proxy-PARサーバはATMとIP特殊情報だけをアカウントに取ります。 特殊情報がProxy-PARサーバによって決して見られないプロトコル。
3.2.1 Registration Protocol
3.2.1 登録プロトコル
The registration protocol enables a client to register the protocols and services it supports. All protocols are associated with a specific AESA and membership scope in the PNNI hierarchy. As the default scope, implementations should choose the local scope of the PNNI peer group. In this way, manual configuration can be avoided unless information has to cross PNNI peer group boundaries. PNNI is responsible for the correct flooding either in the local peer group or across the hierarchy.
登録プロトコルは、クライアントがそれがサポートするプロトコルとサービスを登録するのを可能にします。 すべてのプロトコルがPNNI階層構造で特定のAESAと会員資格範囲に関連しています。 デフォルト範囲として、実装はPNNIピアグループの地方の範囲を選ぶべきです。 このように、情報がPNNIピアグループ限界に交差する必要はないなら、手動の構成を避けることができます。 PNNIはローカルのピアグループか階層構造の向こう側に正しい氾濫に責任があります。
The registration protocol is aligned with the standard initial topology database exchange protocol used in link-state routing protocols as far as possible. It uses a window size of one. A single information element is registered at a time and must be acknowledged before a new registration packet can be sent. The protocol uses ' initialization' and 'more' bits in the same manner PNNI and OSPF do. Any registration on a link unconditionally overwrites all registration data previously received on the same link. By means of a return code the server indicates to the client whether the registration was successful.
登録プロトコルはLinkState方式プロトコルにできるだけ使用される標準の初期のトポロジーデータベース交換プロトコルに並べられます。 それは1のウィンドウサイズを使用します。 新規登録パケットを送ることができる前に、ただ一つの情報要素は、一度に、登録していて、承認していなければなりません。 プロトコルはPNNIとOSPFがする同じ方法で'初期化'と'より多く'のビットを使用します。 リンクにおけるどんな登録も無条件に以前に同じリンクの上に受け取られたすべての登録データを上書きします。 復帰コードによって、サーバは、登録がうまくいったかどうかをクライアントに示します。
Apart form the IP-related information, the protocol also offers a generic interface to the PNNI flooding. By means of so-called System Capabilities Information Groups other information can be distributed that can be used for proprietary or experimental implementations.
IP関連の情報が離れて形成されて、また、プロトコルはジェネリックインタフェースをPNNI氾濫に提供します。 いわゆるSystem Capabilities情報Groupsによって、独占であるか実験的な実装に使用できる他の情報を分配できます。
Droz & Przygienda Informational [Page 7] RFC 2843 Proxy-PAR May 2000
[7ページ]RFC2843プロキシ平価2000年5月の情報のドローとPrzygienda
3.2.2 Query Protocol
3.2.2 質問プロトコル
The client uses the query protocol to obtain information about services registered by other clients. The client requests services registered within a specific membership scope, VPN and IP address prefix. It is always the client's task to request information, the server never makes an attempt to push information to the client. If the client needs to filter the returned data based on service- specific information, such as BGP AS, it must parse and interpret the received information. The server never looks beyond the IP scope.
クライアントは、他のクライアントによって登録されたサービスの情報を得るのに質問プロトコルを使用します。 クライアントは、サービスが特定の会員資格範囲、VPN、およびIPアドレス接頭語の中に登録されたよう要求します。 いつも情報を要求するのが、クライアントのタスクである、サーバはクライアントに情報を押す試みを決してしません。 クライアントが、返されたデータをフィルターにかける必要があるなら、BGP ASなどのサービス特殊情報に基づいて、それは、受信された情報を分析して、解釈しなければなりません。 サーバは決してIP範囲の先を見ません。
The more generic interface to the flooding is supported in a similar manner as the registration protocol.
氾濫への、より多くのジェネリックインタフェースが同じように登録プロトコルとしてサポートされます。
4 Supported Protocols
4 サポートしているプロトコル
Currently the protocols indicated in Table 2 have been included. Furthermore, for protocols marked 'yes', additional information has been specified that is beneficial for their operation. Many of the protocols do not need additional information; it is sufficient to know they are supported and to which addresses they are bound.
現在の、Table2で示されたプロトコルは含まれています。 その上、'はい'であるとマークされたプロトコルとして、彼らの操作に、有益な追加情報は指定されました。 プロトコルの多くが追加情報を必要としません。 それらがサポートされて、どのアドレスであるかに縛られるのを知るのは十分です。
To include other information in an experimental manner the generic information element can be used to carry such information.
ジェネリック情報要素が使用されている場合がある実験方法に他の情報を含むには、そのような情報を運んでください。
5 VPN Support
5 VPNサポート
To implement virtual private networks all information distributed via PAR can be scoped under a VPN ID [1]. Based on this ID, individual VPNs can be separated. Inside a certain VPN further distinctions can be made according to IP-address-related information and/or protocol type.
仮想私設網がすべて、PARを通して分配された情報であると実装するのをVPN ID[1]の下で見ることができます。 このIDに基づいて、個々のVPNsを切り離すことができます。 あるVPNの中では、IPアドレス関連の情報、そして/または、プロトコルタイプに従ってさらなる区別をすることができます。
In most cases the best VPN support can be provided when Proxy-PAR is used between the client and server because in this way it is possible to hide the real PNNI topology from the client. The PAR capable server translates from the abstract membership scope into the real PNNI routing level. In this way the real PNNI topology is hidden from the client and the server can apply restrictions in the PNNI scope. The server can for instance have a mapping such that the membership scope "global" is mapped to the highest level peer group to which a particular VPN has access. Thus the membership scopes can be seen as hierarchical structuring inside a certain VPN. With such mappings a network provider can also change the mapping without having to reconfigure the clients.
本当のPNNIトポロジーをクライアントから隠すのがこのように可能であるのでクライアントとサーバの間でProxy-PARを使用するとき、多くの場合最も良いVPNサポートを提供できます。 PARのできるサーバは抽象的な会員資格範囲から本当のPNNIルーティングレベルに翻訳されます。 本当のPNNIトポロジー隠されるこのように、クライアントとサーバはPNNI範囲で制限を当てはまることができます。 例えば、サーバがマッピングを持つことができるので、会員資格範囲「グローバル」は特定のVPNがアクセサリーを持っている最高水準ピアグループに写像されます。 したがって、あるVPNの中で会員資格範囲を階層構造形成と考えることができます。 また、そのようなマッピングで、クライアントを再構成する必要はなくて、ネットワーク内の提供者はマッピングを変えることができます。
Droz & Przygienda Informational [Page 8] RFC 2843 Proxy-PAR May 2000
[8ページ]RFC2843プロキシ平価2000年5月の情報のドローとPrzygienda
For more secure VPN implementations it will also be necessary to implement VPN ID filters on the server side. In this way a client can be restricted to a certain set (typically one) of VPN IDs. The server will then allow queries and registrations only from the clients that are in the allowed VPNs. In this way it is possible to avoid an attached client from finding devices that are outside of its own VPN. There is even room for further restriction in terms of not allowing wildcard queries by a client. In terms of security, some of the protocols have their own methods, so PAR is only used for the discovery of the counterparts. For instance OSPF has an authentication that can be used during the OSPF operation. Hence even in the case where two wrong partners find each other, they will not communicate because they will not be able to authenticate each other.
また、サーバ側でVPN IDにフィルタを実装するのは、より安全なVPN実装に、必要になるでしょう。 このように、クライアントはあるVPN ID(通常1)に制限される場合があります。 そして、サーバは単に許容VPNsにいるクライアントから質問と登録証明書を許容するでしょう。 デバイスがそれであることがわかるので付属クライアントを避けるのが可能であるこのように、それ自身の外に、VPNがあります。 クライアントによるワイルドカード質問を許さないことに関してさらなる制限の余地さえあります。 セキュリティに関して、プロトコルのいくつかにはそれら自身のメソッドがあるので、PARは対応者の発見に使用されるだけです。 例えば、OSPFには、OSPF操作の間に使用できる認証があります。 したがって、2人の間違ったパートナーが互いを見つける場合ではさえ、彼らは、互いを認証できないので、交信しないでしょう。
Protocol Additional Info
追加インフォメーションについて議定書の中で述べてください。
-------------------------------
OSPF yes
RIP
RIPv2
BGP3
BGP4 yes
EGP
IDPR
MOSPF yes
DVMRP
CBT
PIM-SM
IGRP
IS-IS
ES-IS
ICMP
GGP
BBN SPF IGP
PIM-DM
MARS
NHRP
ATMARP
DHCP
DNS yes
------------------------------- OSPFはいRIP RIPv2 BGP3 BGP4はいEGP IDPR MOSPFはいDVMRP CBT PIM-SM IGRP IS IS ES IS ICMP GGP BBN SPF IGP PIM-DM MARS NHRP ATMARP DHCP DNSはい
Table 2: Additional protocol information carried in PAR and PPAR.
テーブル2: 追加議定書情報はPARとPPARで運ばれました。
The VPN ID used by PAR and Proxy-PAR is aligned with the VPN ID used by other protocols from the ATM Forum and IETF. The VPN ID is structured into two parts, namely the 3-byte-long OUI plus a 4-byte index.
PARとProxy-PARによって使用されたVPN IDは他のプロトコルによってATM ForumとIETFから使用されるVPN IDに並べられます。 VPN IDは2つの部品に構造化されて、すなわち、長さ3バイトのOUIプラスは4バイトのインデックスです。
Droz & Przygienda Informational [Page 9] RFC 2843 Proxy-PAR May 2000
[9ページ]RFC2843プロキシ平価2000年5月の情報のドローとPrzygienda
6 Interoperation with ILMI based Server Discovery
6 ILMIとInteroperationはServerディスカバリーを基礎づけました。
PAR can be used to complement the server discovery via ILMI as specified in [11,12,13]. It can be used to provide the flooding of information across the PNNI network. For this purpose a server has to register with a PAR-capable device. This can be achieved via Proxy- PAR or a direct PAR interaction. Manual configuration would also be possible. For instance the ATMARP server could register its service via Proxy-PAR. A direct interaction with PAR will be required in order to provide an appropriate flooding scope.
[11、12、13]における指定されるとしてのILMIを通してサーバ発見の補足となるのにPARを使用できます。 PNNIネットワークの向こう側に情報の氾濫を供給するのにそれを使用できます。 このためにサーバはPARできるデバイスとともに記名しなければなりません。 Proxy- PARかダイレクトPAR相互作用を通してこれを達成できます。 また、手動の構成も可能でしょう。 例えば、ATMARPサーバはProxy-PARを通してサービスを登録するかもしれません。 PARがある直接的な相互作用が、適切な氾濫範囲を提供するのに必要でしょう。
A PAR-capable device that has the additional MIB variables in the Service Registry MIB can set these variables when getting information via PAR. All required information is either contained in PAR or is static, such as the IP version.
PARを通して情報を得るとき、Service Registry MIBに追加MIB変数を持っているPARできるデバイスはこれらの変数を設定できます。 すべての必須情報が、PARに含まれているか、またはIPバージョンなどのように静的です。
7 Security Consideration
7 警備上の配慮
The Proxy-PAR protocol itself does not have its own security concepts. As PAR is an extension of PNNI, it has all the security features that come with PNNI. In addition, the protocol is mainly used for automatic discovery of peers for certain protocols. After the discovery process the security concepts of the individual protocol are used for the bring-up. As explained in the section about VPN support, the only security considerations are on the server side, where access filters for VPN IDs can be implemented and restrictive membership scope mappings can be configured.
Proxy-PARプロトコル自体には、それ自身のセキュリティ概念がありません。 PARがPNNIの拡大であるので、それには、PNNIと共に来るすべてのセキュリティ機能があります。 さらに、プロトコルはあるプロトコルのための同輩の自動発見に主に使用されます。 発見の後に、個々のプロトコルの概念が使用されるセキュリティは処理されています。上をもたらします。 VPNサポートに関するセクションで説明されるように、唯一のセキュリティ問題がサーバ側にあります。VPN IDのためのアクセスフィルタを実装することができて、側で制限している会員資格範囲マッピングを構成できます。
8 Conclusion
8結論
This document describes the basic functions of Proxy-PAR, which has been specified within the ATM Forum body. The main purpose of the protocol is to provide automatic detection and configuration of non- ATM devices over an ATM cloud.
このドキュメントはProxy-PARの基本機能について説明します。(Proxy-PARはATM Forumボディーの中で指定されました)。 プロトコルの主な目的は非ATMのデバイスの自動検出と構成をATM雲の上に提供することです。
In the future, support for further protocols and address families may be added to widen the scope of applicability of Proxy-PAR.
将来、さらなるプロトコルとアドレスファミリーのサポートは、Proxy-PARの適用性の範囲を広くするために加えられるかもしれません。
Droz & Przygienda Informational [Page 10] RFC 2843 Proxy-PAR May 2000
[10ページ]RFC2843プロキシ平価2000年5月の情報のドローとPrzygienda
9 Bibliography
9 図書目録
[1] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier",
RFC 2685, September 1999.
[1]フォックスとB.とB.グリーソン、「仮想私設網識別子」、RFC2685、1999年9月。
[2] ATM-Forum, "Private Network-Network Interface Specification
Version 1.0." ATM Forum af-pnni-0055.000, March 1996.
[2]気圧フォーラム、「個人的なネットワークネットワーク・インターフェース仕様バージョン1.0。」 1996年3月のATM Forum af-pnni-0055.000。
[3] ATM-Forum, "PNNI Augmented Routing (PAR) Version 1.0." ATM
Forum af-ra-0104.000, January 1999.
[3]、気圧フォーラム、「PNNI増大しているルート設定(平価)バージョン1.0。」 1999年1月のATM Forum af-ra-0104.000。
[4] ATM-Forum, "Interim Local Management Interface, (ILMI)
Specification 4.0." ATM Forum af-ilmi-0065.000, September 1996.
[4]気圧フォーラム、「当座の現地管理職者インタフェース、(ILMI)仕様4.0。」 1996年9月のATM Forum af-ilmi-0065.000。
[5] Laubach, J., "Classical IP and ARP over ATM", RFC 2225, April
1998.
[5]Laubachと、J.と、「気圧での古典的なIPとARP」、RFC2225、4月1998日
[6] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793,
April 1995.
[6]Moy、J.、「要求サーキットを支えるためにOSPFを広げています」、RFC1793、1995年4月。
[7] ATM-Forum, "LAN Emulation over ATM 1.0." ATM Forum af-lane-
0021.000, January 1995.
[7]気圧フォーラム、「気圧1.0でのLANエミュレーション。」 1995年1月のATM Forum af車線-0021.000。
[8] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM
Networks", RFC 2022, November 1996.
[8] アーミテージ、G.、「UNI3.0/3.1の上のMulticastのサポートはATM Networksを基礎づけた」RFC2022、1996年11月。
[9] Droz, P., Haas, R. and T. Przygienda, "OSPF over ATM and Proxy
PAR", RFC 2844, May 2000.
[9] ドロー、P.、ハース、R.、およびT.Przygienda(「気圧とプロキシ平価の上のOSPF」、RFC2844)は2000がそうするかもしれません。
[10] Coltun, R., "The OSPF Opaque LSA Option", RFC 2328, July 1998.
[10]Coltun、1998年7月のR.、「OSPFの不明瞭なLSAオプション」RFC2328。
[11] Davison, M., "ILMI-Based Server Discovery for ATMARP", RFC 2601,
June 1999.
[11] デイヴィソン、1999年6月、M.、「ATMARPのためのILMIベースのサーバディスカバリー」RFC2601。
[12] Davison, M., "ILMI-Based Server Discovery for MARS", RFC 2602,
June 1999.
[12] デイヴィソン、1999年6月、M.、「火星のためのILMIベースのサーバディスカバリー」RFC2602。
[13] Davison, M., "ILMI-Based Server Discovery for NHRP", RFC 2603,
June 1999.
[13] デイヴィソン、1999年6月、M.、「NHRPのためのILMIベースのサーバディスカバリー」RFC2603。
Droz & Przygienda Informational [Page 11] RFC 2843 Proxy-PAR May 2000
[11ページ]RFC2843プロキシ平価2000年5月の情報のドローとPrzygienda
Authors' Addresses
作者のアドレス
Patrick Droz IBM Research Zurich Research Laboratory Saumerstrasse 4 8803 Ruschlikon Switzerland
パトリックドローIBM研究チューリッヒ研究所Saumerstrasse4 8803Ruschlikonスイス
EMail: dro@zurich.ibm.com
メール: dro@zurich.ibm.com
Tony Przygienda Siara Systems Incorporated 1195 Borregas Avenue Sunnyvale, CA 94089 USA
トニーPrzygienda Siara Systemsは1195Borregas Avenueカリフォルニア94089サニーベル(米国)を法人組織にしました。
EMail: prz@siara.com
メール: prz@siara.com
Droz & Przygienda Informational [Page 12] RFC 2843 Proxy-PAR May 2000
[12ページ]RFC2843プロキシ平価2000年5月の情報のドローとPrzygienda
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Droz & Przygienda Informational [Page 13]
ドローとPrzygienda情報です。[13ページ]
一覧
スポンサーリンク
