Network Working Group T. Przygienda
Request for Comments: 2844 Siara
Category: Experimental P. Droz
R. Haas
IBM
May 2000
OSPF over ATM and Proxy-PAR
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This memo specifies, for OSPF implementors and users, mechanisms describing how the protocol operates in ATM networks over PVC and SVC meshes with the presence of Proxy-PAR. These recommendations require no protocol changes and allow simpler, more efficient and cost-effective network designs. It is recommended that OSPF implementations should be able to support logical interfaces, each consisting of one or more virtual circuits and used either as numbered logical point-to-point links (one VC), logical NBMA networks (more than one VC) or Point-to-MultiPoint networks (more than one VC), where a solution simulating broadcast interfaces is not appropriate. PAR can help distribute across the ATM cloud configuration setup and changes of such interfaces when OSPF capable routers are (re-)configured. Proxy-PAR can in turn be used to exchange this information between the ATM cloud and the routers connected to it.
このメモは、OSPFの実装とユーザーのために、プロトコルは、PVCとSVCプロキシ-PARの存在と噛合上ATMネットワークで動作する方法を説明するメカニズムを指定します。これらの推奨事項には、プロトコルの変更を必要とせず、単純に、より効率的で費用対効果の高いネットワーク設計を可能にします。 OSPFの実装は、論理インターフェイスをサポートすることができなければならないことが推奨される各1つ以上の仮想回線からなり、使用のいずれかの論理的なポイントツーポイントリンク（1つのVC）、論理NBMAネットワーク（複数のVC）またはポイント番号として溶液は、ブロードキャストインターフェースをシミュレート-toマルチネットワーク（複数のVC）は、適切ではありません。 PARは、OSPF可能なルータが（再）構成されている場合、ATMクラウドの構成設定およびそのようなインターフェイスの変更を横切って配信することができます。プロキシ-PARは、順番にATMクラウドとそれに接続されたルータ間でこの情報を交換するために使用することができます。
1 Introduction
1はじめに
Proxy-PAR and PAR have been accepted as standards by the ATM Forum in January 1999 [1]. A more complete overview of Proxy-PAR than in the section below is given in [2].
プロキシ-PARとPARは、1999年1月にATMフォーラムによって標準規格として承認された[1]。以下のセクションでよりプロキシPARのより完全な概要は、[2]に示されています。
Proxy-PAR [1] is an extension that allows different ATM attached devices (like routers) to interact with PAR-capable switches and to query information about non-ATM services without executing PAR themselves. The Proxy-PAR client side in the ATM attached device is much simpler in terms of implementation complexity and memory requirements than a complete PAR protocol stack (which includes the full PNNI [3] protocol stack) and should allow easy implementation, e.g. in existing IP routers. In addition, clients can use Proxy-PAR to register the various non-ATM services and protocols they support. Proxy PAR has consciously been omitted as part of ILMI [4] due to the complexity of PAR information passed in the protocol and the fact that it is intended for integration of non-ATM protocols and services only. A device that executes Proxy-PAR does not necessarily need to execute ILMI or UNI signaling, although this normally will be the case.
プロキシPAR [1]（ルータのような）異なるATM接続されたデバイスを可能にする拡張PAR対応スイッチと相互作用するとPAR自体を実行することなく、非ATMサービスに関する情報を照会することです。 ATMにおけるプロキシPARクライアント側デバイスは、例えば、（完全PNNI [3]プロトコルスタックを含む）完全なPARプロトコルスタックよりも実装の複雑さとメモリ要件の点ではるかに単純であり、容易な実装を可能にすべきである添付しました既存のIPルータインチまた、クライアントがサポートするさまざまな非ATMサービスとプロトコルを登録するプロキシ-PARを使用することができます。プロキシPARは、意識的に[4]によるプロトコルと、それが唯一の非ATMプロトコルとサービスの統合のために意図されているという事実に渡されたPAR情報の複雑さにILMIの一部として省略されています。これは通常の場合であろうがプロキシPARを実行するデバイスは、必ずしも、ILMIまたはUNIシグナリングを実行する必要はありません。
The protocol in itself does not specify how the distributed service registration and data delivered to the client is supposed to drive other protocols. Hence OSPF routers, for instance, that find themselves through Proxy-PAR could use this information in a Classical IP and ARP over ATM [5] fashion, forming a full mesh of point-to-point connections to interact with each other to simulate broadcast interfaces. For the same purpose, LANE [6] or MARS [7] could be used. As a byproduct, Proxy-PAR could provide the ATM address resolution for IP-attached devices, but such resolution can be achieved by other protocols under specification at the IETF as well, e.g. [8]. Last but not least, it should be mentioned here that the protocol coexists with and complements the ongoing work in IETF on server detection via ILMI extensions [9,10,11].
それ自体のプロトコルは、クライアントに配信分散型サービス登録とデータが他のプロトコルを駆動するようになっている方法を指定しません。従ってOSPFルータは、例えば、それは、ブロードキャストをシミュレートするために互いに相互作用するポイントツーポイント接続のフルメッシュを形成し、ATM [5]ファッション上クラシカルIPおよびARPにこの情報を使用することができるプロキシPARを介して自分自身を見つけますインタフェース。同じ目的のために、レーン[6]またはMARS [7]を使用することができます。副産物として、プロキシPARは、IP接続装置のATMアドレス解決を提供することができ、そのような解像度は、例えば、同様にIETFで仕様の下で他のプロトコルによって達成することができます[8]。少なくとも最後のではなく、[9,10,11]プロトコルはと共存し、ILMI拡張を介してサーバの検出にIETFで進行中の作業を補完することをここで言及されるべきです。
Any information registered through Proxy-PAR is flooded only within a defined scope that is established during registration and is equivalent to the PNNI routing level. As no assumption can be made about the information distributed (e.g. IP addresses bound to NSAPs are not assumed to be aligned with them in any respect such as encapsulation or functional mapping), it cannot be summarized. This makes a careful handling of scopes necessary to preserve the scalability. More details on the usage of scope can be found in [2].
プロキシPARを介して登録された情報のみを登録時に確立され、PNNIルーティングレベルに相当している定義された範囲内にフラッディングされます。いかなる仮定は分散情報（たNSAPsに結合し、例えばIPアドレスが、このようなカプセル化または機能的マッピングなどの任意の点でそれらと整列されると仮定されていない）について行うことができないように、それが要約することができません。これは、拡張性を維持するために必要なスコープの慎重な取り扱いになります。スコープの使用方法の詳細は、[2]に見出すことができます。
OSPF (Open Shortest Path First) is an Interior Gateway Protocol (IGP) and described in [12] from which most of the following paragraphs has been taken almost literally. OSPF distributes routing information between routers belonging to a single Autonomous System. The OSPF protocol is based on link-state or SPF technology. It was developed by the OSPF working group of the Internet Engineering Task Force. It has been designed expressly for the TCP/IP internet environment, including explicit support for IP subnetting, and the tagging of externally-derived routing information. OSPF also utilizes IP multicast when sending/receiving the updates. In addition, much work has been done to produce a protocol that responds quickly to topology changes, yet involves small amounts of routing protocol traffic.
OSPF（オープンショーテストパスファースト）はインテリアゲートウェイプロトコル（IGP）と次の段落のほとんどはほぼ文字通り取らされた[12]に記載されています。 OSPFは、単一の自律システムに属するルータ間のルーティング情報を配信します。 OSPFプロトコルはリンクステートまたはSPF技術に基づいています。これは、インターネットエンジニアリングタスクフォースのOSPFワーキンググループによって開発されました。これは、明示的なIPサブネットのサポート、および外部由来のルーティング情報のタグ付けを含め、TCP / IPインターネット環境のために特別に設計されています。更新を受信/送信するときにOSPFは、IPマルチキャストを利用しています。また、多くの仕事は、トポロジの変更に迅速に応答プロトコルを生成するために行われ、まだプロトコルのトラフィックをルーティングを少量含まれています。
To cope with the needs of NBMA and demand-circuit-capable networks such as Frame Relay or X.25, [13] has been made available. It standardizes extensions to the protocol that allow efficient operation over on-demand circuits.
そのようなフレームリレーまたはX.25などのNBMAのニーズと需要回路可能なネットワークに対応する、[13]は利用可能にされています。これは、オンデマンド回線上で効率的な動作を許可するプロトコルの拡張を標準化しています。
OSPF supports three types of networks today:
OSPFは、今日のネットワークの3種類をサポートしています。
+ Point-to-point networks: A network that joins a single pair of routers. Point-to-point networks can either be numbered or unnumbered. In the latter case the interfaces do not have IP addresses nor masks. Even when numbered, both sides of the link do not have to agree on the IP subnet.
+ポイントツーポイントネットワーク：ルータの単一の対を結合するネットワーク。ポイントツーポイントネットワークでは、番号または番号なしすることができます。後者の場合のインタフェースは、IPアドレスやマスクを持っていません。番号を付けた場合でも、リンクの両側には、IPサブネットに同意する必要はありません。
+ Broadcast networks: Networks supporting many (more than two) attached routers, together with the capability of addressing a single physical message to all of the attached routers (broadcast). Neighboring routers are discovered dynamically on these networks using the OSPF Hello Protocol. The Hello Protocol itself takes advantage of the broadcast capability. The protocol makes further use of multicast capabilities, if they exist. An Ethernet is an example of a broadcast network.
一緒に接続されたルータ（ブロードキャスト）の全てに単一の物理メッセージに対処する能力を有する、多くの（二つ以上）接続されたルータをサポートするネットワーク：+放送ネットワーク。隣接ルータはOSPF Helloプロトコルを使用して、これらのネットワーク上で動的に発見されています。 Helloプロトコル自体は、ブロードキャスト機能を利用しています。それらが存在する場合、プロトコルは、マルチキャスト機能のさらなる利用します。イーサネットは、ブロードキャストネットワークの一例です。
+ Non-broadcast networks: Networks supporting many (more than two) attached routers, but having no broadcast capability. Neighboring routers are maintained on these nets using OSPF's Hello Protocol. However, due to the lack of broadcast capability, some configuration information is necessary for the correct operation of the Hello Protocol. On these networks, OSPF protocol packets that are normally multicast need to be sent to each neighboring router, in turn. An X.25 Public Data Network (PDN) is an example of a non-broadcast network.
+非ブロードキャストネットワーク：ネットワークは、多くの（以上2）接続されたルータをサポートしますが、何の放送機能を有していません。隣接ルータはOSPFのHelloプロトコルを使用してこれらのネット上で維持されています。しかし、ブロードキャストの能力が不足しているため、一部の構成情報は、Helloプロトコルの正しい操作のために必要です。通常は順番に、各隣接ルータに送信するマルチキャスト必要なこれらのネットワークでは、OSPFプロトコルパケット。 X.25公衆データネットワーク（PDN）は、非ブロードキャストネットワークの一例です。
OSPF runs in one of two modes over non-broadcast networks. The first mode, called non-broadcast multi-access (NBMA), simulates the operation of OSPF on a broadcast network. The second mode, called Point-to-MultiPoint, treats the non-broadcast network as a collection of point-to-point links. Non-broadcast networks are referred to as NBMA networks or Point-to-MultiPoint networks, depending on OSPF's mode of operation over the network.
OSPFは非ブロードキャストネットワーク上の2つのモードのいずれかで実行されます。マルチアクセス（NBMA）非ブロードキャストと呼ばれる第1のモードは、ブロードキャストネットワーク上でOSPFの動作をシミュレートします。ポイント・ツー・マルチポイントと呼ばれる第2のモードは、ポイントツーポイントリンクの集まりとして非ブロードキャストネットワークを扱います。非ブロードキャストネットワークは、ネットワーク上での動作OSPFのモードに応じて、NBMAネットワークやポイント・ツー・マルチポイントネットワークと呼ばれています。
2 OSPF over ATM
ATM上の2 OSPF
Contrary to broadcast-simulation-based solutions such as LANE [6] or Classical IP and ARP over ATM [5], this document elaborates on how to handle virtual OSPF interfaces over ATM such as NBMA, Point-to-MultiPoint or point-to-point and allow for their auto-configuration in the presence of Proxy-PAR. One advantage is the circumvention of server solutions that often present single points of failure or hold large amounts of configuration information.
例えばLANEとして逆放送シミュレーションベースの解決策[6]又はクラシカルIPおよび[5]、このドキュメントは、そのようなポイント・ツー・マルチポイント又はポイント・ツーNBMA、としてATM上の仮想OSPFインタフェースを処理する方法について詳しく説明ATM上ARP - ポイントとプロキシ-PARの存在下で、彼らの自動設定が可能になります。一つの利点は、多くの場合、単一障害点を提示したり、構成情報を大量に保持するサーバソリューションの迂回です。
The other main benefit is the capability of executing OSPF on top of NBMA and Point-to-MultiPoint ATM networks, and still benefit from the automatic discovery of OSPF neighbors. As opposed to broadcast networks, broadcast-simulation-based networks (such as LANE or Classical IP and ARP over ATM), and point-to-point networks, where an OSPF router dynamically discovers its neighbors by sending Hello packets to the All-SPFRouters multicast address, this is not the case on NBMA and Point-to-MultiPoint networks. On NBMA networks, the list of all other attached routers to the same NBMA network has to be manually configured or discovered by some other means: Proxy-PAR allows this configuration to be automated. Also on Point-to-MultiPoint networks, the set of routers that are directly reachable can either be manually configured or dynamically discovered by Proxy-PAR or mechanisms such as Inverse ATMARP. In an ATM network, (see 8.2 in [5]) Inverse ATMARP can be used to discover the IP address of the router at the remote end of a given PVC, whether or not its ATM address is known. But Inverse ATMARP does not return, for instance, whether the remote router is running OSPF, unlike Proxy-PAR.
その他の主な利点は、NBMAとポイント・ツー・マルチポイントATM網の上でOSPFを実行する機能であり、さらにOSPFネイバーの自動検出の恩恵を受ける。ネットワークを放送することとは対照的に、OSPFルータが動的にすべての-SPFRoutersにhelloパケットを送信することにより、その隣人を発見し、ポイントツーポイントネットワーク、（例えばLANEやクラシカルIPおよびATM上のARPなど）のネットワークをブロードキャスト・シミュレーションベースマルチキャストアドレスは、これはNBMAとポイント・ツー・マルチポイントネットワーク上のケースではありません。 NBMAネットワークでは、同じNBMAネットワークへの他のすべての添付のルータのリストを手動でいくつかの他の手段によって構成されるか、または発見されなければならない：プロキシ-PARは、この構成を自動化することを可能にします。また、ポイントツーマルチポイントネットワークで、直接到達可能なルータのセットは、手動で設定されるか、または動的プロキシPAR又は逆ATMARPなどのメカニズムによって発見します。 ATMネットワークでは、そのATMアドレスが知られているか否かを、所定のPVCのリモートエンドにあるルータのIPアドレスを発見するために使用することができる逆ATMARP（[5]に8.2を参照）。しかし、逆ATMARPは、リモートルータがプロキシPARとは異なり、OSPFを実行しているかどうか、例えば、戻りません。
Parallel to [14], which describes the recommended operation of OSPF over Frame Relay networks, a similar model is assumed where the underlying ATM network can be used to model single VCs as point-to-point interfaces or collections of VCs as non-broadcast interfaces, whether in NBMA or Point-to-MultiPoint mode. Such a VC or collection of VCs is called a logical interface and specified through its type (either point-to-point, NBMA or Point-to-MultiPoint), VPN ID (the
基礎となるATMネットワークは非ブロードキャストとしてVCの単一のポイントツーポイントインターフェイスとしてVCSまたはコレクションをモデル化するために使用することができる場合に同様のモデルが想定され、フレームリレーネットワーク上でOSPFの推奨動作を説明する[14]に平行、インターフェイス、NBMAまたはポイントツーマルチポイントモードにするかどうか。そのようなVCまたはVCのコレクションは、論理インタフェースと呼ばれ、その種類（いずれかのポイント・ツー・ポイント、NBMAまたはポイントツーマルチポイント）、VPN IDによって指定されます（
Virtual Private Network to which the interface belongs), address and mask. Layer 2 specific configurations such as the address resolution method, class and quality of service of circuits used, and others, must also be included. As a logical consequence thereof, a single, physical interface could encompass multiple IP subnets or even multiple VPNs. Contrary to layer 2 and IP addressing information, when running Proxy-PAR, most of the OSPF information needed to operate such a logical interface does not have to be configured into routers statically but can be provided through Proxy-PAR queries. This allows much more dynamic configuration of VC meshes in OSPF environments than, for example, Frame Relay solutions do.
インタフェースが属する仮想プライベートネットワーク）、アドレスとマスク。そのようなアドレス解決方法、クラス及び使用される回路、および他のサービスの品質などのレイヤ2つの特定の構成は、も含まれなければなりません。その論理的結果として、単一の物理インターフェイスは、複数のIPサブネットあるいは複数のVPNを包含することができました。プロキシPARを実行するレイヤ2とIPアドレス情報、に反して、そのような論理インターフェイスを操作するために必要なOSPF情報の大部分は静的ルータに設定する必要はなく、プロキシPARクエリを介して提供することができます。これは、VCのはるかに動的な構成は、例えば、フレーム・リレー・ソリューションが行う、よりOSPF環境で噛み合うことができます。
Proxy-PAR queries can also be issued with a subnet address set to 0.0.0.0, instead of a specific subnet address. This type of query returns information on all OSPF routers available in all subnets within the scope specified in the query. This can be used for instance when the IP addressing information has not been configured.
プロキシPARクエリはまた、代わりに特定のサブネットアドレスで、0.0.0.0に設定サブネットアドレスを発行することができます。このタイプのクエリは、クエリで指定した範囲内でのすべてのサブネットで使用可能なすべてのOSPFルータに関する情報を返します。 IPアドレス情報が設定されていないとき、これは、インスタンスのために使用することができます。
To achieve the goal of simplification of VC mesh reconfiguration, Proxy-PAR allows the router to learn automatically most of the configuration that has to be provided to OSPF. Non-broadcast and point-to-point interface information can be learned across an ATM cloud as described in the ongoing sections. It is up to the implementation to possibly allow for a mixture of Proxy-PAR autoconfiguration and manual configuration of neighbor information. Moreover, manual configuration could, for instance, override or complement information derived from a Proxy-PAR client. In addition, OSPF extensions to handle on-demand circuits [13] can be used to allow the graceful tearing down of VCs not carrying any OSPF traffic over prolonged periods of time. The various interactions are described in sections 2.2.1, 2.2.2 and 2.2.3.
VCメッシュの再構成の簡素化の目標を達成するために、プロキシ-PARは、ルータが自動的にOSPFに提供する必要がある設定のほとんどを学ぶことができます。進行中のセクションで説明したように非ブロードキャストおよびポイントツーポイントインターフェース情報は、ATMクラウドを横切って学習することができます。それはおそらく、プロキシ-PARの自動設定やネイバー情報の手動設定の混合を可能にするために実装次第です。また、手動設定は、例えば、上書きまたはプロキシPARクライアントから導出された情報を補完することができました。また、オンデマンド回路を処理するOSPF拡張[13]長期間にわたって任意OSPFトラフィックを搬送しないVCの下優雅な引き裂きを可能にするために使用することができます。様々な相互作用は、セクション2.2.1、2.2.2および2.2.3に記載されています。
Even after autoconfiguration of interfaces has been provided, the problem of VC setups in an ATM network is unsolved because none of the normally used mechanisms such as Classical IP and ARP over ATM [5] or LANE [6] are assumed to be present. Section 2.5 describes the behavior of OSPF routers necessary to allow for router connectivity.
インターフェイスの自動設定が提供された後でも、このようなATM [5]またはLANE上クラシカルIPおよびARPなどの通常使用される機構のいずれもが[6]に存在することが想定されていないので、ATMネットワークにおけるVCのセットアップの問題が未解決です。 2.5節では、ルータの接続を可能にするために必要なOSPFルータの動作について説明します。
2.2.1 Autoconfiguration of Non-Broadcast Multiple-Access (NMBA) Interfaces
2.2.1非ブロードキャストマルチアクセスの自動設定（NMBA）インタフェース
Proxy-PAR allows the autoconfiguation of the list of all routers residing on the same IP network in the same VPN by simply querying the Proxy-PAR server. Each router can easily obtain the list of all OSPF routers on the same subnet with their router priorities and corresponding ATM addresses. This is the precondition for OSPF to work properly across such logical NBMA interfaces. Note that this member list, when learned through Proxy-PAR queries, can dynamically change with PNNI (in)stability and general ATM network behavior. Relying on an OSPF mechanism to discover a lack of reachability in the overlaying logical IP network could alleviate the risk of thrashing DR elections and excessive information flooding. Once the DR election has been completed and the router has not been elected DR or BDR, an implementation of [13] can ignore the fact that all routers on the specific NBMA subnet are available in its configuration because it only needs to maintain VCs to the DR and BDR. Note that this information can serve other purposes, such as the forwarding of data packets (see section 2.4).
プロキシ-PARは、単にプロキシPARサーバーを照会することにより、同じVPN内の同じIPネットワーク上に存在するすべてのルータのリストのautoconfiguationすることができます。各ルータは、簡単に自分のルータの優先順位と対応するATMアドレスと同じサブネット上のすべてのOSPFルータのリストを取得することができます。これは、OSPFは、論理NBMAインタフェースを横切って適切に動作するための前提条件です。プロキシ-PARクエリを通じて知ったとき、このメンバーリストは、動的PNNI安定性および一般的なATMネットワークの挙動（中）に変更することができることに注意してください。 OSPFメカニズムに依存することはスラッシングDR選挙と過度な情報氾濫の危険性を軽減することができ重ねる論理IPネットワークにおける到達可能性の欠如を発見します。 DRの選出が完了し、ルータがDRまたはBDR、[13]の実装は、それだけにVCを維持する必要があるため、特定のNBMAサブネット上のすべてのルータがその構成で利用可能であるという事実を無視することができ選出されていなかったたらDRとBDR。この情報は（セクション2.4を参照）は、データパケットの転送のような他の目的を果たすことができることに留意されたいです。
Traditionally, router configuration for a NBMA network provides the list of all neighboring routers to allow for proper protocol operation. For stability purposes, the user may choose to provide a list of neighbors through such static means but also enable the operation of Proxy-PAR protocol to complete the list. It is left up to specific router implementations to determine whether to use the manual configuration in addition to the information provided by Proxy-PAR, to use the manual configuration to filter dynamic information, or whether a concurrent mode of operation is prohibited. In any case it should be obvious that allowing for more flexibility may facilitate operation but provides more possibilities for misconfiguration as well.
伝統的に、NBMAネットワークのルータの設定は、適切なプロトコルの動作を可能にするために、すべての隣接ルータのリストを提供します。安定性のために、ユーザは、静的手段を介してネイバーのリストを提供するだけでなく、リストを完了するためにプロキシPARプロトコルの動作を可能にするために選択することができます。動的な情報をフィルタリングするために手動設定を使用するように、プロキシPARによって提供される情報に加えて、手動設定を使用するかどうかを決定するために、特定のルータの実装に任されている、又は動作の同時モードが禁止されているかどうか。いずれの場合では、操作を容易にすることができるより多くの柔軟性を可能にするが、同様に誤設定のためのより多くの可能性を提供することは明らかであるべきです。
Point-to-MultiPoint interfaces in ATM networks only make sense if no VCs can be set up dynamically because an SVC-capable ATM network normally presents a NBMA cloud to OSPF. This is for example the case if OSPF executes over a network composed of a partial PVC or SPVC mesh or predetermined SVC meshes. Such a network could be modeled using the Point-to-MultiPoint OSPF interface and the neighbor detection could be provided by Proxy-PAR or other means. In the Proxy-PAR case the router queries for all OSPF routers on the same network in the same VPN but it installs in the interface configuration only routers that are already reachable through existing PVCs. The underlying assumption is that a router knows the remote ATM address of a PVC and can compare it with appropriate Proxy-PAR registrations. If the remote ATM address of the PVC is unknown, it can be discovered by such mechanisms as Inverse ARP [15].
SVC対応のATMネットワークは正常にOSPFにNBMAクラウドを提供するため、何のVCを動的に設定することができない場合ATMネットワークにおけるポイント・ツー・マルチポイントのインターフェイスにのみ意味をなします。 OSPFは、SVCのメッシュをメッシュ又は所定の部分PVCまたはSPVCからなるネットワークを介して実行される場合、これは、例えば場合です。そのようなネットワークは、ポイントツーマルチポイントOSPFインタフェースを使用してモデル化することができ、隣接検出がプロキシPAR又は他の手段によって提供することができます。プロキシ-PARの場合は、同じネットワーク上のすべてのOSPFルータのルータクエリー同じVPNでのそれは、インターフェイスコンフィギュレーションに既存のPVCを通じて、すでに届いているルータだけをインストールします。根本的な前提は、ルータがPVCのリモートATMアドレスを知っているし、適切なプロキシ-PARの登録とそれを比較することができるということです。 PVCのリモートATMアドレスが未知である場合、それは逆ARP [15]のようなメカニズムによって発見することができます。
Proxy-PAR provides a true OSPF neighbor detection mechanism, whereas a mechanism like Inverse ARP only returns addresses of directly reachable routers (which are not necessarily running OSPF), in the Point-to-Multi-Point environment.
逆ARPのような機構が唯一のポイント・ツー・マルチポイント環境において、（必ずしもOSPFを実行していない）に直接到達可能なルータのアドレスを返し、一方、プロキシPARは、真OSPFネイバー検出メカニズムを提供します。
OSPF point-to-point links do not necessarily have an IP address assigned and even if they do, the mask is undefined. As a precondition to successfully register a service with Proxy-PAR, an IP address and a mask are required. Therefore, if a router desires to use Proxy-PAR to advertise the local end of a point-to-point link to the router with which it intends to form an adjacency, an IP address has to be provided as well as a netmask set or a default of 255.255.255.252 (this gives as the default case a subnet with two routers on it) assumed. To allow the discovery of the remote end of the interface, IP address of the remote side has to be provided and a netmask set or a default of 255.255.255.252 assumed. Obviously the discovery can only be successful when both sides of the interface are configured with the same network mask and are within the same IP network. The situation where more than two possible neighbors are discovered through queries and the interface type is set to point-to-point presents a configuration error.
OSPFポイントツーポイントリンクは必ずしもIPアドレスが割り当てられていないと、彼らがそうしても、マスクが定義されていません。成功したプロキシ-PARでサービスを登録するための前提として、IPアドレスとマスクが必要とされています。ルータは、それが隣接関係を形成しようれるルータへのポイントツーポイントリンクのローカルエンドをアドバタイズするプロキシPARを使用したい場合したがって、IPアドレスが提供されなければならないだけでなく、ネットマスクセットまたは255.255.255.252のデフォルト（これはデフォルトのケースとして、それに2つのルータとサブネットを与える）を想定しました。インターフェースのリモートエンドの検出を可能にするために、リモート側のIPアドレスが提供されなければならないとネットマスクのセットまたは255.255.255.252のデフォルトを想定しました。インタフェースの両側が同じネットワークマスクを使用して構成し、同じIPネットワーク内にあるとき、明らかに発見が唯一の成功することができます。二つ以上の可能な隣人は、クエリによって発見され、インターフェイスタイプをポイントツーポイントに設定されている状況は、構成エラーを示します。
Sending multicast Hello packets on the point-to-point links allows OSPF neighbors to be discovered automatically. On the other hand, using Proxy-PAR instead avoids sending Hello messages to routers that are not necessarily running OSPF.
ポイントツーポイントリンク上のマルチキャストHelloパケットを送信すると、OSPFネイバーを自動的に発見することができます。一方、使用してプロキシPARではなく、必ずしもOSPFを実行していないルータにhelloメッセージを送信しません。
For reasons given in [14], the use of unnumbered point-to-point interfaces with Proxy-PAR is not a very attractive alternative because the lack of an IP address prevents efficient registration and retrieval of configuration information. Relying on the numbering method based on MIB entries generates conflicts with the dynamic nature of creation of such entries and is beyond the scope of this work.
IPアドレスの不足は、効率的な登録および構成情報の取得を防止するため、[14]で与えられた理由のために、プロキシ-PARとの無数のポイントツーポイントインタフェースの使用は、非常に魅力的な選択肢ではありません。 MIBのエントリに基づいて番号付け方式に依存することは、そのようなエントリの作成の動的性質との競合を生成し、この作業の範囲を超えています。
To allow other routers to discover an OSPF interface automatically, the IP address, mask, Area ID, interface type and router priority information given must be registered with the Proxy-PAR server at an appropriate scope. A change in any of these parameters has to force a reregistration with Proxy-PAR.
他のルータが自動的にOSPFインタフェースを発見することを可能にするために、与えられたIPアドレス、マスク、エリアID、インタフェースタイプとルータ優先度情報は、適切なスコープでプロキシPARサーバに登録されなければなりません。これらのパラメータの任意の変化は、Proxy-PARとの再登録を強制しなければなりません。
It should be emphasized here that because the registration information can be used by other routers to resolve IP addresses against NSAPs as explained in section 2.4, the entire IP address of the router must be registered. It is not sufficient to indicate the subnet up to the mask length; all address bits must be provided.
また、登録情報は、セクション2.4で説明したようにのNSAPsに対してIPアドレスを解決するために他のルータで使用することができるので、ルータの全体のIPアドレスが登録されなければならないことをここで強調すべきです。マスク長までのサブネットを示すのに十分ではありません。すべてのアドレスビットが提供されなければなりません。
For an NBMA interface the appropriate parameters are available and can be registered through Proxy-PAR without further complications.
NBMAインタフェースするための適切なパラメータが利用可能であり、更なる合併症なしでプロキシPARを介して登録することができます。
In the case of a Point-to-MultiPoint interface the router registers its information in the same fashion as in the NBMA case, except that the interface type is modified accordingly.
ポイント・ツー・マルチポイントの場合、ルータは、インターフェイスタイプがそれに応じて変更されることを除いて、NBMAの場合と同様に、その情報を登録するインタフェース。
In the case of point-to-point numbered interfaces the address mask is not specified in the OSPF configuration. If the router has to use Proxy-PAR to advertise its capability, a mask must be defined or a default value of 255.255.255.252 used.
ポイント・ツー・ポイント番号インターフェイスの場合に、アドレスマスクはOSPF設定で指定されていません。ルータがその機能をアドバタイズするためにプロキシ-PARを使用している場合は、マスクを定義または255.255.255.252のデフォルト値を使用する必要があります。
Owing to the lack of a configured IP address and difficulties generated by this fact as described earlier, registration of unnumbered point-to-point interfaces is not covered in this document.
設定されたIPアドレスと前述したように、このことによって生成される問題の欠如のために、無数のポイントツーポイントインターフェイスの登録は、この文書で覆われていません。
As a byproduct of Proxy-PAR presence, an OSPF implementation could use the information in registrations for the resolution of IP addresses to ATM NSAPs on a subnet without having to use static data or mechanisms such as ATMARP [5]. This again should allow a drastic simplification of the number of mechanisms involved in operating OSPF over ATM to provide an IP overlay.
プロキシPARの存在の副産物として、OSPFの実装は、ATMARP静的データまたは機構を使用することなく、サブネット上のATMたNSAPsにIPアドレスの解決のために登録の情報を使用することができる[5]。これは、再びIPオーバーレイを提供するために、ATM上でOSPFを動作させるに関与するメカニズムの数の大幅な簡素化を可能にしなければなりません。
From a system perspective, the OSPF component, the Proxy-PAR client, the IP to NSAP address resolution table, and the ATM circuit manager can be depicted as in Figure 1. Figure 1 shows an example of component interactions triggered by a Proxy-PAR query from the Proxy-PAR client.
システムの観点から、OSPFコンポーネント、プロキシPARクライアント、NSAPアドレス解決テーブルにIP、およびATM回路マネージャは、図のように示すことができる。図1は、Proxy-PARによって誘発成分の相互作用の一例を示す図プロキシ-PARクライアントからのクエリ。
This section describes the OSPF behavior in an ATM network under various assumptions in terms of signaling capabilities and preset connectivity.
このセクションでは、シグナリング機能及びプリセット接続性の面で様々な仮定の下でATMネットワークにおけるOSPFの動作を説明しています。
In environments where only partial PVCs (or SPVCs) meshes are available and modeled as Point-to-MultiPoint interfaces, the routers see reachable routers through autodiscovery provided by Proxy-PAR. This leads to expected OSPF behavior. In cases where a full mesh of PVCs is present, such a network should preferably be modeled as NBMA. Note that in such a case, PVCs failures will translate into not-so-obvious routing failures.
一部のみのPVC（またはSPVCの）メッシュが利用可能であり、ポイントツーマルチポイントインターフェイスとしてモデル化される環境では、ルータは、Proxy-PARによって提供される自動検出を介して到達可能なルータを参照してください。これは、OSPFの動作を期待してしまいます。 PVCのフルメッシュが存在する場合には、そのようなネットワークは、好ましくは、NBMAとしてモデル化されるべきです。このような場合には、PVCの障害はそれほど明白ではないルーティングの失敗につながることに注意してください。
__________ _________
| | | |
| OSPF |<-------------------|Proxy-PAR|<---(Proxy-PAR query)
|__________| notify | client |
^ neighbor changes |_________|
| |
send and | | maintain Proxy-PAR
receive | | entries in table
OSPF msg | |
| |
| |
____V____ ____V_____
| ATM | | |
| circuit |-------------------->|IP to NSAP|
| manager | check | table |
|_________| IP to NSAP bindings |__________|
Figure 1: System perspective of typical components interactions.
図1：一般的なコンポーネントの相互作用のシステムの観点。
+ + +
| +---+ | |
+--+ |---|RTA|---| +-------+ | +--+
|H1|---| +---+ | | ATM | |---|H2|
+--+ | | +---+ | Cloud | +---+ | +--+
|LAN Y |---|RTB|-------------|RTC|---|
+ | +---+ | PPAR | +---+ |
+ +-------+ +
Figure 2: Simple topology with Router B and Router C operating across NBMA ATM interfaces with Proxy-PAR.
図2：ルータBとルータCは、プロキシPARとNBMA ATMインターフェイスを横切って動作するシンプルなトポロジー。
In SVC-capable environments the routers can initiate VCs after having discovered the appropriate neighbors, preferably driven by the need to send data such as Hello packets. This can lead to race conditions where both sides can open a VC simultaneously. It is generally desirable to avoid wasting this valuable resource: if the router with lower IP address (i.e., the IP address of the OSPF interface registered with Proxy-PAR) detects that the VC initiated by the other side is bidirectional, it is free to close its own VC and use the detected one. Note that this either requires the OSPF implementation to be aware of the VCs used to send and receive Hello messages, or the component responsible of managing VCs to be aware of the usage of particular VCs.
SVC対応の環境では、ルータは、好ましくは、Helloパケットなどのデータを送信するために必要で駆動適切な隣人を、発見した後にVCを開始することができます。これは、両側が同時にVCを開くことができ、競合状態につながることができます。この貴重な資源の浪費を避けることが一般的に望ましい：下のIPアドレス（すなわち、プロキシ-PARに登録OSPFインターフェイスのIPアドレス）を持つルータが相手側によって開始VCは双方向であることを検出した場合、それはに無料です独自のVCを閉じて、検出された1つを使用します。これは、Helloメッセージを送受信するために使用するVCを認識することがOSPFの実装を必要とする、または特定のVCの使用を意識するのVCを管理する責任を負うコンポーネントに留意されたいです。
Observe that this behavior operates correctly in case OSPF over Demand Circuits extensions are used [13] over SVC capable interfaces.
この動作は[13]上SVC可能なインターフェイスを使用しているオンデマンド回路の拡張上ケースOSPFで正しく動作することを観察します。
Most of the time, it is possible to avoid the setup of redundant VCs by delaying the sending of the first OSPF Hello from the router with the lower IP address by an amout of time greater than the interval between the queries from the Proxy-PAR client to the server. Chances are that the router with the higher IP address opens the VC (or use an already existing VC) and sends the OSPF Hello first if its interval between queries is shorter than the Hello delay of the router with the lower IP address. As this interval can vary depending on particular needs and implementations, the race conditions described above can still be expected to happen, albeit presumably less often.
時間のほとんどは、プロキシ-PARクライアントからのクエリ間の間隔よりも長い時間のAMOUT低いIPアドレスを持つルータから最初のOSPFのHelloの送信を遅延させることにより、冗長VCの設定を回避することが可能ですサーバーへ。チャンスは高いIPアドレスを持つルータ（または既存のVCを使用）VCを開き、クエリの間の間隔が小さいIPアドレスを持つルータのハロー遅延よりも短い場合は、最初のOSPFのHelloを送信していることです。この間隔は、特定のニーズや実装に応じて変えることができるように、上述の競合状態はまだ、おそらくあまりにもかかわらず、起こることが期待できます。
The existence of VCs used for OSPF exchanges is orthogonal to the number and type of VCs the router chooses to use within the logical interface to forward data to other routers. OSPF implementations are free to use any of these VCs (in case they are aware of their existence) to send packets if their end points are adequate and must accept Hello packets arriving on any of the VCs belonging to the logical interface even if OSPF operating on such an interface is not aware of their existence. An OSPF implementation may ignore connections being initiated by another router that has not been discovered by Proxy-PAR. In any case, the OSPF implementation will ignore a neighbor whose Proxy-PAR registration indicates that it is not adjacent.
OSPF交換に使用されるVCの存在は、ルータが他のルータへデータを転送するために論理インターフェイス内で使用することを選択したVCの数およびタイプに直交しています。 OSPFの実装は、そのエンドポイントが適切であるとOSPFが動作しても、論理インターフェイスに属するVCのいずれかで到着Helloパケットを受け入れなければならない場合は、パケットを送信するために（場合には、彼らはその存在を認識している）これらのVCのいずれかを自由に使用することがそのようなインタフェースは、その存在を認識しません。 OSPFの実装は、プロキシ-PARによって発見されていない別のルータによって開始された接続を無視することができます。いずれの場合においても、OSPFの実装は、そのプロキシPAR登録それは隣接していないことを示している隣人を無視します。
As an example consider the topology in Figure 2 where router RTB and RTC are connected to a common ATM cloud offering Proxy-PAR services. Assuming that RTB's OSPF implementation is aware of SVCs initiated on the interface and that RTC only makes minimal use of Proxy-PAR information, the following sequence could develop, illustrating some of the cases described above:
一例として、ルータRTBとRTCは、プロキシPARのサービスを提供し、共通のATMクラウドに接続されている図2のトポロジーを検討してください。 RTBのOSPFの実装は、インターフェイス上およびRTCのみプロキシPAR情報の最小使用することを開始したSVCを認識していると仮定すると、次のシーケンスでは、上記の例いくつかを示す、開発することもできます：
1. RTC and RTB register with ATM cloud as Proxy-PAR capable and discover each other as adjacent OSPF routers.
1. RTCとRTBは、Proxy-PARできるようATMクラウドに登録し、隣接OSPFルータとして互いを発見します。
2. RTB sends a Hello, which forces it to establish a SVC connection to RTC.
2. RTBはRTCへのSVC接続を確立するためにそれを強制こんにちは、送信します。
3. RTC sends a Hello to RTB, but disregards the already existing VC and establishes a new VC to RTB to deliver the packet.
3. RTCは、RTBにこんにちはを送りますが、既存のVCを無視し、パケットを提供するRTBに新しいVCを確立します。
4. RTB sees a new bidirectional VC and, assuming here that RTC's IP address is higher, closes the VC originated in step 2.
4. RTBはRTCのIPアドレスが高いこと、VCはステップ2で発祥閉じここで仮定して、新しい双方向のVCを見て。
5. Host H1 sends data to H2 and RTB establishes a new data SVC between itself and RTC.
5.ホストH1はH2にデータを送信し、RTBは、それ自体とRTCとの間の新たなデータのSVCを確立します。
6. RTB sends a Hello to RTC and decides to do so using the newly establish data SVC. RTC must accept the Hello despite the minimal implementation.
6. RTBはRTCへのHelloを送信し、新たにデータSVCを確立使用して、そうすることを決定しました。 RTCは、最小限の実装にもかかわらず、こんにちはを受け入れる必要があります。
3 Acknowledgments
3つの謝辞
Comments and contributions from several sources, especially Rob Coltun, Doug Dykeman, John Moy and Alex Zinin are included in this work.
いくつかのソース、特にロブColtun、ダグDykeman、ジョン・モイおよびアレックスジニンからのコメントと貢献は、この作品に含まれています。
4 Security Considerations
4つのセキュリティの考慮事項
Several aspects are to be considered in the context of the security of operating OSPF over ATM and/or Proxy-PAR. The security of registered information handed to the ATM cloud must be guaranteed by the underlying PNNI protocol. The registration itself through Proxy-PAR is not secured, and are thus appropriate mechanisms for further study. However, even if the security at the ATM layer is not guaranteed, OSPF security mechanisms can be used to verify that detected neighbors are authorized to interact with the entity discovering them.
いくつかの態様は、ATMおよび/またはプロキシ-PAR上でOSPFを動作させるのセキュリティのコンテキストで考慮されるべきです。 ATMクラウドに渡さ登録情報のセキュリティは、基礎となるPNNIプロトコルによって保証されなければなりません。プロキシPARを通して登録自体は固定され、従って、さらなる研究のための適切なメカニズムであるれていません。しかし、ATM層でのセキュリティが保証されていない場合でも、OSPFのセキュリティメカニズムは、隣人がエンティティがそれらを発見すると対話することが許可されている検出されたものを確認するために使用することができます。
5 Bibliography
5参考文献
[1] ATM Forum, "PNNI Augmented Routing (PAR) Version 1.0." ATM Forum af-ra-0104.000, January 1999.
[1] ATMフォーラム、 "おばさんは、ルーティング（牛乳）、バージョン1.0をagmented。"の-ATMフォーラム-0104.000 1月1999インチ
[2] Droz, P. and T. Przygienda, "Proxy-PAR", RFC 2843, May 2000.
[2]ドロー、P.およびT. Przygienda、 "プロキシ-PAR"、RFC 2843、2000年5月。
[3] ATM-Forum, "Private Network-Network Interface Specification Version 1.0." ATM Forum af-pnni-0055.000, March 1996.
[3] ATM-フォーラムを、 "プライベートネットワーク - ネットワークインターフェイス仕様バージョン1.0。" ATMフォーラムのaf-PNNI-0055.000、1996年3月。
[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] ATM-Forum, "LAN Emulation over ATM 1.0." ATM Forum af-lane-0021.000, January 1995.
[6] ATMフォーラム、 "ATM 1.0オーバーLANエミュレーション。" ATMフォーラムのレーン-0021.000、1995年1月。
[7] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, November 1996.
[7]アーミテージ、G.、 "UNI 3.0 / 3.1以上のマルチキャストのサポートベースのATMネットワーク"、RFC 2022、1996年11月。
[8] Coltun, R., "The OSPF Opaque LSA Option", RFC 2328, July 1998.
[8] Coltun、R.、 "OSPFオペークLSAオプション"、RFC 2328、1998年7月。
[9] Davison, M., "ILMI-Based Server Discovery for ATMARP", RFC 2601, June 1999.
[9]ダビソン、M.、 "ATMARPためILMIベースのサーバの検出"、RFC 2601、1999年6月。
[10] Davison, M., "ILMI-Based Server Discovery for MARS", RFC 2602, June 1999.
[10]デイヴィソン、M.、 "MARSのためのILMIベースのサーバディスカバリー"、RFC 2602、1999年6月。
[11] Davison, M., "ILMI-Based Server Discovery for NHRP", RFC 2603, June 1999.
[11]ダビソン、M.、 "NHRP用ILMIベースのサーバの検出"、RFC 2603、1999年6月。
[12] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[12]モイ、J.、 "OSPFバージョン2"、RFC 2328、1998年4月。
[13] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995.
[13]モイ、J.、RFC 1793、1995年4月 "オンデマンド・サーキットをサポートするためのOSPFの拡張"。
[14] deSouza, O. and M. Rodrigues, "Guidelines for Running OSPF Over Frame Relay Networks", RFC 1586, March 1994.
[14] deSouza、O.およびM.ロドリゲス、 "フレームリレーネットワーク上でOSPFを実行するためのガイドライン"、RFC 1586、1994年3月。
[15] Bradley, A. and C. Brown, "Inverse Address Resolution Protocol", RFC 2390, September 1999.
[15]ブラッドリー、A.およびC.ブラウン、 "逆アドレス解決プロトコル"、RFC 2390、1999年9月。
Authors' Addresses
著者のアドレス
Tony Przygienda Siara Systems Incorporated 1195 Borregas Avenue Sunnyvale, CA 94089 USA
トニーPojhijandaシアラシステムズ株式会社1195 Boarriges Avenuaサニーベール、94089それ
EMail: prz@siara.com
メールアドレス：prz@siara.com
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
Robert Haas IBM Research Zurich Research Laboratory Saumerstrasse 4 8803 Ruschlikon Switzerland
ロバート・ハースIBMリサーチチューリッヒ研究所Saumerstrasse 4 8803リュシュリコンスイス
EMail: rha@zurich.ibm.com
メールアドレス：rha@zurich.ibm.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機能のための基金は現在、インターネット協会によって提供されます。