[要約] RFC 2843は、Proxy-PAR（Proxy Password Authentication Realm）プロトコルに関する仕様であり、プロキシサーバーとクライアント間の認証と認可を提供することを目的としています。この仕様は、セキュリティとアクセス制御の向上を目指しています。
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.
Copyright（c）The Internet Society（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.
Proxy-Parは、PAR（PNNI拡張ルーティング）の最小限のバージョンであり、ATM（PNNI拡張ルーティング）が、PARを完全にサポートする必要なくPNNIデバイスと対話する機能を提供します。Proxy-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が付属しているデバイスが提供するサービスの登録と自動発見のために、PNNIが提供する洪水メカニズムを使用できるようにすることです。PARの最初のバージョンは、主にIPv4で利用可能なプロトコルに対応しています。しかし、PNNIの洪水にアクセスするための一般的なインターフェイスも含まれています。さらに、Proxy-Par-Capableサーバーは、VPN ID [1]、IPプロトコル、アドレスプレフィックスに基づいてフィルタリングを提供します。これにより、たとえば、OSPFを実行している特定のVPNのルーターが同じサブネットで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ワーキンググループと呼ばれていたルーティングとアドレス指定（RA）ワーキンググループの作業項目として「PARの最小限のサブセットとしてのプロキシ-PAR貢献」を受け入れました[2]。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].
このドキュメントの意図は、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.
Proxy-Parは、さまざまなATM（ATMおよび非ATMデバイス）がPAR対応スイッチと対話して、PAR自身を実行せずに非ATMサービスに関する情報を交換できるプロトコルです。クライアント側は、完全なPARインスタンスよりも、実装の複雑さとメモリの要件の点ではるかに簡単です。これにより、IPルーターなどの既存のIPデバイスに簡単に実装できるようになります。さらに、クライアントはProxy-Parを使用して、さまざまな非ATMサービスとサポートするプロトコルを登録できます。プロトコルは、プロトコルで渡された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 VCの完全なメッシュを確立するか、RFC1793 [6]を使用して相互作用する可能性があります。レーン[7]または火星[8]は、同じ目的に使用できます。特定のプロトコルがどのようにプロキシ-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 attachedデバイスのATMアドレス解像度を提供する機能がありますが、そのような解像度は、IETFの仕様に基づく他のプロトコルによっても実現できます。[10]。繰り返しますが、プロトコルの主な目的は、ATMクラウド上のデバイスの自動検出を分散型ファッションで許可し、サーバーベースのソリューションの通常の落とし穴を省略することです。最後になりましたが、ここでは、プロトコルがILMIエクステンションを介したサーバー検出に関するIETFで行われた作業を補完し、共存することも言及する必要があります[11,12,13]。
2 Proxy-PAR Operation and Interaction with PNNI
2 PNNIとのプロキシ-PAR操作と相互作用
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隣接が確立された後に実行されます。クライアントは、登録メッセージをサーバーに送信することにより、独自のサービスを登録できます。クライアントは、クエリメッセージをサーバーに送信することにより、関心のある情報を取得します。クライアントが登録されたプロトコルのセットを変更する必要がある場合、サーバーに再登録する必要があります。クライアントは、NULLセットのサービスを登録することにより、すべての登録サービスを引き出すことができます。サーバー側が新しい情報をクライアントにプッシュしないことに注意することが重要です。また、サーバーは、クライアントが受け取った情報を説明する状態を維持していません。適切な時間間隔でクエリと登録を発行することにより、その情報を更新および更新したり、他のクライアントに関する保存された情報を更新したりすることは、クライアントの責任です。これにより、プロトコルが簡素化されますが、クライアントが大量のデータを保存して要求しないことを前提としています。サーバーの主な責任は、潜在的なクライアントがお互いを発見できるように、PNNIクラウドを介して登録情報をあふれさせることです。Proxy-Par Server側は、VPNと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:
プロキシ-PAR拡張は、PNNIプロトコルによる情報の適切な洪水に依存しています。クライアント側がProxy-Parを通じて新しいサービスを登録または再登録すると、抽象的なメンバーシップ範囲をサービスに関連付けます。サーバー側は、このメンバーシップスコープを洪水を制限するPNNIルーティングレベルにマッピングします。これにより、クライアントの再構成なしでPNNIルーティングレベルの変更が可能になります。さらに、サーバーはマッピングテーブルを設定して、クライアントが特定のレベルでのみ情報を浸水できるようにすることができます。PNNIネットワーク内のノードは、浸水時に関連する情報の範囲を考慮に入れます。したがって、さまざまなレベルの階層で異なるプロトコルを発表することにより、PNNIルーティング階層を悪用することが可能です。OSPFは特定のピアグループ内で実行できますが、BGPはOSPFを実行しているピアグループのセット間で実行できます。PNNI階層への非ATMプロトコルのこのようなアラインメントまたはマッピングは、プロキシ-PARサービスのスケーラビリティと柔軟性を大幅に向上させることができます。図1は、このようなシナリオを視覚化するのに役立ちます。このトポロジの場合、次の登録が発行されます。
+-+
| | PNNI peer group # PPAR capable @ PNNI capable * Router
+-+ switch switch
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：Proxy-Par Autodection（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は、SCOPE 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は、SCOPE 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
3. R3は、SCOPE 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は、Scope 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は、AS101内でスコープ40を使用して、IPインターフェイス1.1.3.1およびサブネット1.1/16で実行されているBGP4プロトコルを登録します
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は、AS100内でスコープ40を備えたIPインターフェイス1.1.3.2およびサブネット1.1/16で実行されるとBGP4プロトコルを登録します
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 # | # |
| # #
######### ##########
Figure 2: OSPF and BGP scalability with Proxy-PAR autodetection (IP topology).
図2：Proxy-Par Autodection（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.
上記の声明を異なる方法で表現すると、プロキシパー情報の範囲がピアグループの境界を超えた分布が必要であることを示している場合、ピアグループのリーダーはそのような情報を収集し、それをより高い層に伝播します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)
r登録Qはクエリuを介して使用されています（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ハロープロトコルは、[2]で指定されたハロープロトコルと密接に関連しています。同じパケットヘッダーとバージョンのネゴシエーション方法を使用します。簡単にするために、プロキシ-PARとは無関係な状態は、元のPNNIハロープロトコルから削除されました。Proxy-Par Helloプロトコルの目的は、登録メッセージとクエリメッセージの交換をサポートするクライアントとサーバーの間のプロキシ-PAR隣接を確立および維持することです。プロトコルが同じサーバーとクライアントペアの間の複数の並列リンクにわたって実行されている場合、個々の登録とクエリセッションは特定のリンクに関連付けられています。登録とクエリセッションをさまざまな通信インスタンスに割り当てることは、クライアントとサーバーの責任です。PROXY-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に加えて、サーバーからクライアントに移動するプロキシパルロスは、サーバーが登録情報に割り当てる寿命についてクライアントに通知します。クライアントは、Hello Packetからこの間隔を取得し、サーバーによる登録情報の老化を避けるために、その更新間隔を取得した時間間隔以下に設定する必要があります。
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>はVPN AのOSPFインターフェイスについて説明します。IPスコープに加えて、プロトコル自体に関するより詳細な情報を含むさらなるパラメーターを登録できます。上記の例では、これはエリアIDやルーターの優先度などのOSPF固有の情報です。ただし、Proxy-Parサーバーは、質問された情報を取得する際にATMおよびIP固有の情報のみを考慮します。プロトコル固有の情報は、プロキシパーサーバーによって検討されることはありません。
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などのサービス固有の情報に基づいて返されたデータをフィルタリングする必要がある場合、受信した情報を解析して解釈する必要があります。サーバーは、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]でscopeすることができます。この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.
ほとんどの場合、クライアントとサーバーの間でプロキシ-PARを使用する場合、最適なVPNサポートを提供できます。このようにして、クライアントから実際のPNNIトポロジを隠すことができるからです。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およびProxy-PARで使用されるVPN IDは、ATMフォーラムおよびIETFの他のプロトコルで使用されるVPN IDと一致しています。VPN IDは、3バイトのOUIと4バイトインデックス、つまり4バイトのインデックス、つまり2つの部分に構造化されています。
6 Interoperation with ILMI based Server Discovery
6 ILMIベースのサーバー発見との相互操作
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または直接的な相互作用を介して実現できます。手動構成も可能です。たとえば、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.
サービスレジストリMIBに追加のMIB変数があるPAR対応デバイスは、PAR経由で情報を取得するときにこれらの変数を設定できます。必要なすべての情報は、IPバージョンなど、PARに含まれるか、静的です。
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.
このドキュメントでは、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] Fox、B。およびB. Gleeson、「仮想プライベートネットワーク識別子」、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-Forum、「プライベートネットワークネットワークインターフェイス仕様バージョン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.
[3] ATM-Forum、「PNNI拡張ルーティング（PAR）バージョン1.0。」ATMフォーラムAF-RA-0104.000、1999年1月。
[4] ATM-Forum, "Interim Local Management Interface, (ILMI) Specification 4.0." ATM Forum af-ilmi-0065.000, September 1996.
[4] ATM-Forum、「暫定ローカル管理インターフェイス、（ILMI）仕様4.0。」ATMフォーラムAF-ILMI-0065.000、1996年9月。
[5] Laubach, J., "Classical IP and ARP over ATM", RFC 2225, April 1998.
[5] Laubach、J。、「ATM上の古典的なIPとARP」、RFC 2225、1998年4月。
[6] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995.
[6] Moy、J。、「需要回路をサポートするためにOSPFを拡張」、RFC 1793、1995年4月。
[7] ATM-Forum, "LAN Emulation over ATM 1.0." ATM Forum af-lane-0021.000, January 1995.
[7] ATM-Forum、「ATM 1.0を超えるLANエミュレーション」。ATMフォーラムAF-LANE-0021.000、1995年1月。
[8] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, November 1996.
[8] Armitage、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] Droz、P.、Haas、R。、およびT. Przygienda、「ATM Over ATM and Proxy Par」、RFC 2844、2000年5月。
[10] Coltun, R., "The OSPF Opaque LSA Option", RFC 2328, July 1998.
[10] Coltun、R。、「OSPF Opaque LSAオプション」、RFC 2328、1998年7月。
[11] Davison, M., "ILMI-Based Server Discovery for ATMARP", RFC 2601, June 1999.
[11] Davison、M。、「IlmiベースのサーバーディスカバリーフォーAtmarp」、RFC 2601、1999年6月。
[12] Davison, M., "ILMI-Based Server Discovery for MARS", RFC 2602, June 1999.
[12] Davison、M。、「Ilmiベースのサーバーディスカバリーフォーマーズ」、RFC 2602、1999年6月。
[13] Davison, M., "ILMI-Based Server Discovery for NHRP", RFC 2603, June 1999.
[13] Davison、M。、「NHRPのILMIベースのサーバー発見」、RFC 2603、1999年6月。
Authors' Addresses
著者のアドレス
Patrick Droz IBM Research Zurich Research Laboratory Saumerstrasse 4 8803 Ruschlikon Switzerland
パトリックドロズIBM研究チューリッヒ研究研究所ソーマーストラス4 8803ラッシュリコンスイス
EMail: dro@zurich.ibm.com
Tony Przygienda Siara Systems Incorporated 1195 Borregas Avenue Sunnyvale, CA 94089 USA
Tony Przygienda Siara Systems Incorporated 1195 Borregas Avenue Sunnyvale、CA 94089 USA
EMail: prz@siara.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。