Network Working Group P. Droz
Request for Comments: 2843 IBM
Category: Informational T. Przygienda
Siara
May 2000
Proxy-PAR
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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は、ATM接続デバイスを完全にPARをサポートする必要なしPNNIデバイスと相互作用する能力を与えるPAR（PNNIルーティング増補）の最小バージョンです。プロキシ-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.
プロキシPARの目的は、非ATMデバイスが登録し、ATM接続されたデバイスが提供するサービスの自動検出のためにPNNIによって提供フラッディングメカニズムを使用できるようにすることです。 PARの最初のバージョンは、主にIPv4の利用可能なプロトコルに対応しています。しかし、それはまた、PNNIの洪水にアクセスするための汎用的なインタフェースが含まれています。また、プロキシ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フォーラムは、ルーティングのワークアイテムとして及びアドレッシング以前PNNIワーキンググループ[2]と呼ばれた（RA）ワーキンググループ、「最小PARのサブセットとしてプロキシPAR寄与」を受け入れました。 PAR [3]仕様は、ステートマシンおよびパケットフォーマットを含むプロトコルの詳細な説明を提供します。
The intention of this document is to provide general information about Proxy-PAR. For the detailed protocol description we refer the reader to [3].
このドキュメントの意図は、プロキシ-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はPAR自体を実行せずに、非ATMサービスに関する情報を交換するためにPAR対応スイッチと相互作用する様々なATM接続装置（ATMおよび非ATMデバイス）を可能にするプロトコルです。クライアント側は、完全なPARインスタンスより実装の複雑さとメモリ要件の面ではるかに簡単です。これは、IPルータなどの既存のIPデバイス上の簡単な実装を可能にしなければなりません。さらに、クライアントは、様々な非ATMサービスとそれらがサポートするプロトコルを登録するプロキシPARを使用することができます。プロトコルは、故意ためのプロトコルと、それが唯一の非ATMプロトコルおよびサービスの統合のために意図されているという事実に渡さPAR情報の複雑[4] ILMIから省略されています。これは通常の場合であろうがプロキシ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.
プロトコルは、クライアントが接続を確立するために取得した情報を利用する方法を指定しません。例えば、プロキシ-PARを介して自分自身を見つけるOSPFルータは、RFC2225 [5]を用いてP2P VCのフルメッシュを確立する、またはRFC1793 [6]が互いに相互作用するように使用することができます。レーンは、[7]またはMARS [8]と同じ目的のために使用することができます。特定のプロトコルは、プロキシPARを利用することができる方法を定義ガイドラインが適切なワーキンググループまたは特定のプロトコルを担当する標準化団体によって生成されるべきであると期待されています。追加のRFCは、[9]この文書と一緒に公開されているプロキシ-PARと一緒にOSPFを実行する方法を説明します。
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クラウド上のデバイスの自動検出を可能にすることです。少なくとも最後のではなく、それは[11,12,13]と同様のプロトコルを補完し、ILMI拡張を介してサーバ検出にIETFで行われた作業と共存することをここで言及されなければなりません。
2 Proxy-PAR Operation and Interaction with PNNI
2プロキシPAR運用とPNNIとの相互作用
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 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ハロープロトコルに非常に類似しており、開始し、隣接するクライアントとサーバ間の通信を維持するために使用されます。プロキシ-PARの隣接関係が確立された後、登録・更新部分が実行されます。クライアントは、サーバに登録メッセージを送信することにより、独自のサービスを登録することができます。クライアントは、サーバーにクエリーメッセージを送信することにより、に興味がある情報を得ます。クライアントが登録されたプロトコルのセットを変更する必要があるときは、サーバーに再登録する必要があります。クライアントは、サービスの零集合を登録することによって、すべての登録されたサービスを撤回することができます。サーバ側がクライアントに新しい情報をプッシュしていないことに注意することは重要ではありません、どちらもサーバーは、クライアントが受信した情報記述した任意の状態を維持しません。クライアントの責任で更新し、その情報を更新し、新たな顧客を発見したり、適切な時間間隔でクエリや登録を発行することにより、他のクライアントについてその保存された情報を更新するようにすることです。これは、プロトコルを簡素化しますが、クライアントが保存し、大量のデータを要求しないことを前提としています。サーバーの主な責任は、潜在的な顧客が互いを発見することができるように、PNNIクラウドを通じて登録情報をあふれさせることです。プロキシPARサーバ側もVPNとIPサブネットをサポートするために、フィルタリング機能を提供します。ポーリングとさわやかな間隔が比較的長いことができるように、プロキシ-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:
プロキシ-PARの拡張子は、PNNIプロトコルによる情報の適切な洪水に依存しています。クライアント側のレジスタまたはプロキシ-PARによる新サービスを再登録すると、それがサービスに抽象メンバーシップの範囲を関連付けます。サーバ側では洪水を制限PNNIルーティングレベルにこのメンバーシップの範囲をマッピングします。これは、クライアントの再設定せずにPNNIルーティングレベルの変更を可能にします。また、サーバは、クライアントが唯一の特定のレベルに情報をあふれさせることができるように、マッピングテーブルを設定することができます。それが浸水したときPNNIネットワーク内のノードは、アカウントへの情報の関連する範囲を取ります。例えば、階層の異なるレベルで異なるプロトコルを発表しPNNIルーティング階層を利用することが可能ですBGPは、OSPFを実行して、ピア - 基の組との間に実行することができたのに対し、OSPFは、特定のピアグループ内で実行することができます。 PNNI階層に非ATMプロトコルのようなアラインメントまたはマッピングが大幅プロキシPARサービスの拡張性と柔軟性を高めることができます。図1は、このようなシナリオを視覚化するのに役立ちます。このトポロジでは、次の登録が発行されています。
+-+ | | PNNI peer group # PPAR capable @ PNNI capable * Router +-+ switch switch
+ - + | |可能PNNI @可能PNNIピア・グループ＃PPAR *ルータ+ - +スイッチを切り替えます
Level 40
+---------------------------+
| |
| |
| @ ---- @ ---- @ |
| | | |
+----- | ----------- | -----+
| |
Level 60 | |
+------------- | ---+ +-- | --------------+
| | | | | |
R1* ------#-P1------@ | | @---------P3-#------- * R3
| | | | | |
R2* ------#-P2------+ | | +---------P4-#------- * R4
| | | |
+-------------------+ +-------------------+
Figure 1: OSPF and BGP scalability with Proxy-PAR autodetection (ATM topology).
図1：OSPFとBGPプロキシPARの自動検出（ATMトポロジー）とスケーラビリティ。
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は、スコープ60とIPインタフェース1.1.1.1とサブネット1.1.1 / 24上で実行されているようにOSPFプロトコルを登録します
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は、スコープ60とIPインタフェース1.1.1.2とサブネット1.1.1 / 24上で実行されているようにOSPFプロトコルを登録します
3. R3 registers OSPF protocol as running on the IP interface 1.1.2.1 and subnet 1.1.2/24 with scope 60
前記R3はスコープ60とIPインタフェース1.1.2.1とサブネット1.1.2 / 24上で実行されているようにOSPFプロトコルを登録します
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は、スコープ60とIPインタフェース1.1.2.2とサブネット1.1.2 / 24上で実行されているようにOSPFプロトコルを登録します
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は、IPインタフェース1.1.3.1とサブネット上で実行されているようにBGP4プロトコルを登録AS101内スコープ40 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は、IPインタフェース1.1.3.2とサブネット上で実行されているようにBGP4プロトコルを登録AS100内スコープ40 1.1 / 16
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ルーティングレベルは、クライアントが「ローカル」と「1 +ローカル」抽象メンバーシップのスコープを使用する代わりに、これら2つの値の60と40である、指定されています。また、すべての登録情報は、同じ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 # | # |
| # #
######### ##########
Figure 2: OSPF and BGP scalability with Proxy-PAR autodetection (IP topology).
図2：プロキシPARの自動検出（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.
異なる上記のステートメントを表す、一方がプロキシPAR情報の範囲は、ピアグループの境界を越えて分布が必要であることを示す場合、ピアグループのリーダーは、このような情報を収集し、より高い層にそれを伝搬すると言うことができPNNI階層。範囲値以外に仮定は、正規分布情報（AESAのに結合し、例えばIPアドレスが任意の点でそれらと整列されると仮定されていない）について行うことができないように、そのような情報をまとめることができません。これは、上述したようなアプローチのスケーラビリティを維持するために必要なスコープの慎重な取り扱いになります。
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
R registered
Q seen through query
U used (implies Q)
Table 1: Flooding scopes of Proxy-PAR registrations.
表1：プロキシ-PAR登録のフラッディングスコープ。
3 Proxy-PAR Protocols
3プロキシPARプロトコル
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.
プロキシPAR Helloプロトコル[2]で指定されたハロープロトコルに密接に関連しています。これは、同じパケットヘッダとバージョン交渉方法を使用しています。簡略化のため、プロキシ-PARとは無関係である状態は、元のPNNIハロープロトコルから除去されています。プロキシ-PARのHelloプロトコルの目的は、登録や問い合わせメッセージの交換をサポートするクライアントとサーバ間のプロキシPAR隣接関係を確立し、維持することです。プロトコルが同じサーバとクライアントのペアの間に複数のパラレルリンクを介して実行された場合は、個々の登録とクエリセッションは、特定のリンクに関連付けられています。様々な通信インスタンスに登録して、クエリセッションを割り当てるために、クライアントとサーバーの責任です。プロキシ-PARは、[4]仮想リンクとVPトンネルをサポートするために、ILMIと同じ粒度で実行することができます。
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こんにちはに加えて、サーバからクライアントへの旅行代理-PARハローズは、サーバが登録された情報に割り当てる寿命についてクライアントに通知します。クライアントは、Helloパケットからこの間隔を取得し、サーバーによって登録された情報のうち、老化を避けるために取得した時間間隔以下の値にそのリフレッシュ間隔を設定する必要があります。
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 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アドレス空間を意味します。例えば、<Aは、194.194.1.01は、255.255.255.0は、OSPFは>プロトコル自体に関する詳細情報を含む登録することができるIPの範囲、さらにパラメータに加えてVPN AのOSPFインタフェースを記述する。上記の例では、これは、このようなエリアIDまたはルータの優先順位としてOSPF固有の情報であろう。クエリされた情報を取得するときただし、プロキシPARサーバのアカウントにのみATMおよびIP固有の情報を取ります。プロトコル固有の情報は、Proxy-PARサーバによって見れることはありません。
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.
登録プロトコルは可能な限りリンクステートルーティングプロトコルで使用される標準的な初期トポロジデータベース交換プロトコルと整列されます。これは、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洪水への汎用インタフェースを提供しています。いわゆるシステム機能情報グループの他の情報を用いて独自のまたは実験的な実装のために使用することができる分配することができます。
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.
現在、表2に示したプロトコルが含まれています。プロトコルのために「はい」と記ささらに、付加的な情報はそれが彼らの操作のために有益である指定されています。プロトコルの多くは、追加情報を必要としません。彼らがサポートされている知っているのに十分であるとそれらが結合されているアドレスにいます。
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に基づいて、個々のVPNを分離することができます。特定の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トポロジを非表示にすることも可能であるため、プロキシ-PARは、クライアントとサーバー間で使用されたときにほとんどの場合、最良のVPNのサポートを提供することができます。 PARできるサーバは、実際のPNNIルーティングレベルに抽象メンバーシップの範囲から変換されます。このように、本当のPNNIトポロジは、クライアントから隠されていると、サーバは、PNNIスコープに制限を適用することができます。例えば、サーバ缶は、メンバーシップスコープ「グローバル」そのマッピングは、特定のVPNにアクセスを持っている最も高いレベルのピアグループにマッピングされています。このように、メンバーシップスコープは、特定のVPN内の階層構造として見ることができます。このようなマッピングを使用してネットワークプロバイダは、クライアントを再構成することなくマッピングを変更することができます。
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の実装のために、また、サーバ側でVPNのIDフィルタを実装する必要があります。このように、クライアントはVPN IDの特定のセット（通常は1）に制限することができます。その後、サーバーはのみ許可されたVPN内にあるクライアントからの照会や登録を許可します。このようにして、独自の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
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とプロキシPARで使用されるVPN IDは、ATMフォーラムとIETFから他のプロトコルによって使用されるVPN IDと位置合わせされます。 VPN IDは、2つの部分、すなわち、3バイト長OUIプラス4バイトインデックスに構成されています。
6 Interoperation with ILMI based Server Discovery
ILMIベースのサーバーの検出と6の相互運用性
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.
PARは、[11,12,13]で指定されるようにILMIを介してサーバディスカバリを補完するために使用することができます。 PNNIネットワーク上で情報の氾濫を提供するために使用することができます。この目的のために、サーバは、PAR対応デバイスに登録する必要があります。これは、プロキシ-PARまたは直接PAR相互作用を介して達成することができます。手動設定も可能です。例えばATMARPサーバがプロキシ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を介して情報を取得するときに、サービスレジストリ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.
プロキシ-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.
この文書では、ATMフォーラムの本体内に指定されたプロキシ-PARの基本的な機能について説明します。プロトコルの主な目的は、ATMクラウド上の非ATMデバイスの自動検出および構成を提供することです。
In the future, support for further protocols and address families may be added to widen the scope of applicability of Proxy-PAR.
今後は、さらにプロトコルとアドレスファミリのサポートは、プロキシ-PARの適用範囲を広げるために添加してもよいです。
9 Bibliography
9参考文献
[1] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier", RFC 2685, September 1999.
[1]フォックス、B.及びB.グリーソン、 "仮想プライベートネットワーク識別子"、RFC 2685、1999年9月。
[2] ATM-Forum, "Private Network-Network Interface Specification Version 1.0." ATM Forum af-pnni-0055.000, March 1996.
[2] ATM-フォーラムを、 "プライベートネットワーク - ネットワークインターフェイス仕様バージョン1.0。" ATMフォーラムのaf-PNNI-0055.000、1996年3月。
[3] ATM-Forum, "PNNI Augmented Routing (PAR) Version 1.0." ATM Forum af-ra-0104.000, January 1999.
[三] ATM-フォーラムは、 "おばさんは（牛乳）、バージョン1.0をルーティングagmented。"の-ATMフォーラム-0104.000 1月1999インチ
[4] ATM-Forum, "Interim Local Management Interface, (ILMI) Specification 4.0." ATM Forum af-ilmi-0065.000, September 1996.
[4] ATM-フォーラム、 "暫定ローカル管理インターフェイス（ILMI）仕様4.0を。" ATMフォーラムのaf-ILMI-0065.000、1996年9月。
[5] Laubach, J., "Classical IP and ARP over ATM", RFC 2225, April 1998.
[5]ラウバッハ、J.、 "クラシカルIPおよびATM上のARP"、RFC 2225、1998年4月。
[6] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995.
[6]モイ、J.、RFC 1793、1995年4月 "オンデマンド・サーキットをサポートするためのOSPFの拡張"。
[7] ATM-Forum, "LAN Emulation over ATM 1.0." ATM Forum af-lane-0021.000, January 1995.
[7] ATMフォーラム、 "ATM 1.0オーバーLANエミュレーション。" ATMフォーラムのレーン-0021.000、1995年1月。
[8] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, November 1996.
[8]アーミテージ、G.、 "UNI 3.0 / 3.1以上のマルチキャストのサポートベースのATMネットワーク"、RFC 2022、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、 "ATMとプロキシPARオーバーOSPF"、RFC 2844、2000年5月。
[10] Coltun, R., "The OSPF Opaque LSA Option", RFC 2328, July 1998.
[10] Coltun、R.、 "OSPFオペークLSAオプション"、RFC 2328、1998年7月。
[11] Davison, M., "ILMI-Based Server Discovery for ATMARP", RFC 2601, June 1999.
[11]ダビソン、M.、 "ATMARPためILMIベースのサーバの検出"、RFC 2601、1999年6月。
[12] Davison, M., "ILMI-Based Server Discovery for MARS", RFC 2602, June 1999.
[12]デイヴィソン、M.、 "MARSのためのILMIベースのサーバディスカバリー"、RFC 2602、1999年6月。
[13] Davison, M., "ILMI-Based Server Discovery for NHRP", RFC 2603, June 1999.
[13]ダビソン、M.、 "NHRP用ILMIベースのサーバの検出"、RFC 2603、1999年6月。
Authors' Addresses
著者のアドレス
Patrick Droz IBM Research Zurich Research Laboratory Saumerstrasse 4 8803 Ruschlikon Switzerland
パトリック・ドローIBMリサーチチューリッヒ研究所Saumerstrasse 4 8803リュシュリコンスイス
EMail: dro@zurich.ibm.com
メールアドレス：dro@zurich.ibm.com
Tony Przygienda Siara Systems Incorporated 1195 Borregas Avenue Sunnyvale, CA 94089 USA
トニーPojhijandaシアラシステムズ株式会社1195 Boarriges Avenuaサニーベール、94089それ
EMail: prz@siara.com
メールアドレス：prz@siara.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。