[要約] RFC 2844は、OSPFプロトコルをATMネットワークとProxy-PARに拡張するための仕様です。目的は、ATMネットワーク上でのOSPFルーティングとProxy-PARの統合を可能にすることです。
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
ATM上のOSPFおよび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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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メッシュを介したATMネットワークでプロトコルがどのように動作するかを説明するメカニズムを指定します。これらの推奨事項は、プロトコルの変更を必要とせず、よりシンプルで効率的で費用対効果の高いネットワーク設計を可能にします。OSPF実装は、それぞれが1つ以上の仮想回路で構成される論理インターフェイスをサポートし、番号付きの論理ポイントツーポイントリンク（1つのVC）、論理NBMAネットワーク（複数のVC）またはポイントとして使用できるようにすることをお勧めします。-To-MultiPointネットワーク（複数のVC）。ブロードキャストインターフェイスをシミュレートするソリューションが適切ではありません。PARは、OSPF対応ルーターが（再）構成されている場合、ATMクラウド構成のセットアップとそのようなインターフェイスの変更に分配するのに役立ちます。Proxy-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].
PROXY-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.
Proxy-Par [1]は、異なるATM接続デバイス（ルーターなど）がPAR対応スイッチと対話し、PAR自身を実行せずに非ATMサービスに関する情報をクエリできるようにする拡張機能です。ATM接続デバイスのプロキシ-PARクライアント側は、完全なPARプロトコルスタック（完全なPNNI [3]プロトコルスタックを含む）よりも実装の複雑さとメモリの要件の点ではるかに簡単であり、簡単な実装を可能にする必要があります。既存のIPルーターで。さらに、クライアントはProxy-Parを使用して、サポートするさまざまな非ATMサービスとプロトコルを登録できます。プロキシPARは、プロトコルで渡されたPAR情報の複雑さと、それが非ATMプロトコルとサービスのみの統合のみを目的としているという事実により、ILMI [4]の一部として意識的に省略されています。Proxy-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].
プロトコル自体は、クライアントに配信される分散サービス登録とデータが他のプロトコルを駆動することになっている方法を指定していません。したがって、たとえば、Proxy-Parを通じて自分自身がこの情報を使用してATMを超えてこの情報を使用していることに気づくOSPFルーター[5]ファッションで、ポイントツーポイント接続の完全なメッシュを形成して相互に対話してブロードキャストをシミュレートすることができます。インターフェイス。同じ目的で、レーン[6]または火星[7]を使用できます。副産物として、Proxy-PARはIP attachedデバイスのATMアドレス解像度を提供できますが、IETFでの仕様に基づく他のプロトコルによって、そのような解像度を実現できます。[8]。最後になりましたが、ここでは、プロトコルがILMIエクステンションを介したサーバー検出に関するIETFで進行中の作業を共存し、補完することをここで言及する必要があります[9,10,11]。
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ルーティングレベルに相当する定義された範囲内でのみ浸水します。分散された情報（たとえば、NSAPにバインドされた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（最初にOpenest Path First）は、インテリアゲートウェイプロトコル（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.
NBMAのニーズとフレームリレーやX.25などのデマンドサーキット対応ネットワーク[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.
+ ポイントツーポイントネットワーク：1つのペアのルーターを結合するネットワーク。ポイントツーポイントネットワークには、番号を付けたり、番号を付けたりすることができます。後者の場合、インターフェイスには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.
+ ブロードキャストネットワーク：多くの（2つ以上）接続されたルーターをサポートするネットワークと、接続されたすべてのルーター（ブロードキャスト）に単一の物理メッセージに対処する機能。隣接するルーターは、OSPF Helloプロトコルを使用してこれらのネットワークで動的に発見されます。Hello Protocol自体は、ブロードキャスト機能を活用しています。このプロトコルは、存在する場合、マルチキャスト機能をさらに使用します。イーサネットは、ブロードキャストネットワークの例です。
+ 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 Protocolを使用して、これらのネットに隣接するルーターが維持されます。ただし、ブロードキャスト機能が不足しているため、ハロープロトコルの正しい操作には構成情報が必要です。これらのネットワークでは、通常マルチキャストである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）と呼ばれる最初のモードは、ブロードキャストネットワークでのOSPFの動作をシミュレートします。Point-to-Multipointと呼ばれる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]やClassical IPおよびARP over ATM [5]などの放送シミュレーションベースのソリューションとは反対に、このドキュメントは、NBMA、ポイントツーマルチポイント、ポイントツーなどのATM上の仮想OSPFインターフェイスを処理する方法について詳しく説明しています。 - プロキシParの存在下での自動構成をポイントし、許可します。利点の1つは、障害の単一ポイントを提示することが多い、または大量の構成情報を保持するサーバーソリューションの回転です。
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.
もう1つの主な利点は、NBMAおよびポイントツーマルチポイントATMネットワークの上でOSPFを実行する能力であり、OSPF隣人の自動発見の恩恵を受けることです。ブロードキャストネットワークとは対照的に、ブロードキャストシミュレーションベースのネットワーク（レーンまたはクラシックIPやATMを介したARPなど）、およびポイントツーポイントネットワークでは、OSPFルーターがハローパケットをオールSPFRouterに送信して近隣を動的に発見します。マルチキャストアドレス、これはNBMAおよびポイントツーマルチポイントネットワークではそうではありません。NBMAネットワークでは、他のすべてのNBMAネットワークへの他のすべての接続されたルーターのリストを手動で構成または発見する必要があります。プロキシ-PARにより、この構成を自動化できます。また、ポイントツーマルチポイントネットワークでは、直接到達可能なルーターのセットは、プロキシ-PARまたは逆ATMARPなどのメカニズムによって手動で構成または動的に発見されます。ATMネットワークでは（[5]の8.2を参照）逆ATMARPを使用して、ATMアドレスがわかっているかどうかにかかわらず、特定のPVCのリモートエンドでルーターのIPアドレスを発見できます。ただし、逆の雰囲気は、Proxy-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 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.
[14]と並行して、フレームリレーネットワークを介したOSPFの推奨操作を説明していますが、基礎となるATMネットワークを使用して、単一のVCをポイントツーポイントインターフェイスとしてモデル化することができる場合、VCのコレクションを非広場としてモデル化できます。NBMAであろうとポイントツーマルチポイントモードであろうと、インターフェイス。このようなVCまたはVCSのコレクションは、論理インターフェイスと呼ばれ、そのタイプ（ポイントツーポイント、NBMAまたはポイントツーマルチポイント）、VPN ID（インターフェイスが属する仮想プライベートネットワーク）、アドレス、およびアドレス、およびマスク。レイヤー2アドレス解決方法、使用される回路のクラスとサービスの品質などの特定の構成も含める必要があります。その論理的な結果として、単一の物理インターフェイスは、複数のIPサブネットまたは複数のVPNを含む可能性があります。レイヤー2およびIPアドレス指定情報に反して、プロキシPARを実行する場合、このような論理インターフェイスを操作するために必要なOSPF情報のほとんどは、静的にルーターに構成する必要はありませんが、プロキシ-Parクエリを通じて提供できます。これにより、たとえばフレームリレーソリューションよりも、OSPF環境でのVCメッシュのより動的な構成が可能になります。
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.
Proxy-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メッシュ再構成の簡素化の目標を達成するために、Proxy-Parを使用すると、ルーターはOSPFに提供する必要がある構成のほとんどを自動的に学習できます。進行中のセクションで説明されているように、ATMクラウド全体で、非ブロードキャストおよびポイントツーポイントインターフェイス情報を学習できます。プロキシ-PAR Autoconfigurationと近隣情報の手動構成の混合を可能にすることは、実装次第です。さらに、たとえば、手動構成は、プロキシParクライアントから派生した情報をオーバーライドまたは補完する可能性があります。さらに、オンデマンド回路[13]を処理するOSPF拡張は、長期にわたって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ネットワークでのVCセットアップの問題は解決されていません。なぜなら、ATM [5]やレーン[6]上の古典的なIPやARPなどの通常使用されるメカニズムは存在しないと想定されているためです。セクション2.5では、ルーターの接続を可能にするために必要なOSPFルーターの動作について説明します。
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).
Proxy-Parを使用すると、Proxy-Parサーバーをクエリするだけで、同じVPNの同じIPネットワークに存在するすべてのルーターのリストを自動確認できます。各ルーターは、ルーターの優先順位と対応するATMアドレスを備えた同じサブネット上のすべてのOSPFルーターのリストを簡単に取得できます。これは、OSPFがこのような論理NBMAインターフェイス全体で適切に機能するための前提条件です。このメンバーリストは、プロキシ-PARクエリを介して学習した場合、PNNI（in）の安定性と一般的なATMネットワークの動作により動的に変化する可能性があることに注意してください。OSPFメカニズムに依存して、論理IPネットワークのオーバーレイに到達可能性の欠如を発見すると、選挙博士と過度の情報の洪水を打ち負かすリスクを軽減する可能性があります。博士選挙が完了し、ルーターがDRまたはBDRが選出されなかった後、[13]の実装は、特定のNBMAサブネット上のすべてのルーターがその構成で利用可能であるという事実を無視できます。博士と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プロトコルの操作がリストを完成させることもできます。Proxy-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].
ATMネットワークのポイントツーマルチポイントインターフェイスは、SVC対応ATMネットワークが通常NBMAクラウドをOSPFに提示するため、VCSが動的にセットアップできない場合にのみ意味があります。これは、OSPFが部分的なPVCまたはSPVCメッシュまたは事前に決められたSVCメッシュで構成されるネットワークを介して実行される場合の場合です。このようなネットワークは、Point-to-Multipoint OSPFインターフェイスを使用してモデル化でき、隣接検出はProxy-Parまたはその他の手段で提供できます。プロキシパーの場合、同じVPNの同じネットワーク上のすべてのOSPFルーターのルータークエリは、既存の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.
Proxy-PARは真のOSPF隣接検出メカニズムを提供しますが、逆ARPのようなメカニズムは、ポイントツーマルチポイント環境で直接到達可能なルーター（必ずしも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アドレスが割り当てられているわけではなく、たとえマスクが未定義です。Proxy-Parでサービスを正常に登録する前提条件として、IPアドレスとマスクが必要です。したがって、ルーターがプロキシ-PARを使用して、隣接を形成しようとするルーターへのポイントツーポイントリンクのローカルエンドを宣伝したい場合、IPアドレスを提供する必要があり、ネットマスクセットまたは255.255.255.252のデフォルト（これにより、デフォルトのケースとして2つのルーターが付いたサブネットが与えられます）が想定されます。インターフェイスのリモートエンドの発見を可能にするには、リモート側のIPアドレスを提供し、ネットマスクセットまたはデフォルトの255.255.255.252を想定する必要があります。明らかに、インターフェイスの両側が同じネットワークマスクで構成され、同じIPネットワーク内にある場合にのみ、発見は成功することができます。クエリを通じて2人以上の可能な隣人が発見され、インターフェイスタイプがポイントツーポイントに設定されている状況は、構成エラーを提示します。
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.
ポイントツーポイントリンクにマルチキャストのハローパケットを送信すると、OSPFの隣人を自動的に発見することができます。一方、代わりにProxy-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.
[14]に示されている理由により、IPアドレスがないために効率的な登録と構成情報の取得を防ぐため、Proxy-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、インターフェイスタイプ、および指定されたルーターの優先情報を適切な範囲でProxy-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で説明されているように、NSAPに対する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.
プロキシパーの存在の副産物として、OSPF実装は、静的データまたはATMARPなどのメカニズムを使用することなく、サブネット上のATM NSAPへの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クライアント、IPからNSAPアドレス解像度テーブル、およびATM回路マネージャーを図1のように描くことができます。図1はProxy-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としてモデル化する必要があります。そのような場合、PVCS障害はそれほど明確でないルーティング障害につながることに注意してください。
__________ _________
| | | |
| 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：Router BとRouter Cを備えた単純なトポロジーは、Proxy-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対応環境では、ハローパケットなどのデータを送信する必要があることにより、適切な隣人を発見した後、ルーターはVCを開始できます。これにより、両側がVCを同時に開くことができる人種条件につながる可能性があります。一般に、この貴重なリソースを無駄にすることを避けることが望ましいです。低いIPアドレスを持つルーター（つまり、Proxy-Parに登録されているOSPFインターフェイスのIPアドレス）が反対側によって開始されたVCが双方向であることを検出する場合、自由にできます。独自のVCを閉じて、検出されたVCを使用します。これには、Helloメッセージを送信および受信するために使用されるVCを認識するためにOSPFの実装が必要な場合、または特定のVCの使用を認識するためにVCSを管理する責任のあるコンポーネントを必要とすることに注意してください。
Observe that this behavior operates correctly in case OSPF over Demand Circuits extensions are used [13] over SVC capable interfaces.
SVC対応インターフェイスでOSPFオーバーデマンドサーキット拡張機能[13]が使用されている場合、この動作は正しく動作することを観察します。
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.
ほとんどの場合、Proxy-Parクライアントからのクエリ間の間隔よりも大きい時間によって、低い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の実装は、これらのVCのいずれかを自由に使用できます（存在を認識している場合は）エンドポイントが適切である場合はパケットを送信し、OSPFが動作していても論理インターフェイスに属するVCに到着するハローパケットを受け入れる必要がありますそのようなインターフェイスは、その存在を認識していません。OSPFの実装は、Proxy-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:
例として、Router RTBとRTCがProxy-Parサービスを提供する一般的なATMクラウドに接続されている図2のトポロジーを検討します。RTBのOSPF実装がインターフェイスで開始されたSVCSを認識しており、RTCがプロキシPar情報を最小限に抑えているだけであると仮定すると、次のシーケンスが開発され、上記のいくつかのケースを示しています。
1. RTC and RTB register with ATM cloud as Proxy-PAR capable and discover each other as adjacent OSPF routers.
1. RTCおよびRTBは、ATMクラウドにプロキシパルが有能に登録し、隣接するOSPFルーターとしてお互いを発見します。
2. RTB sends a Hello, which forces it to establish a SVC connection to RTC.
2. RTBはHelloを送信します。これにより、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にHelloを送信しますが、既存のVCを無視し、新しいVCをRTBに確立してパケットを配信します。
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は新しい双方向VCを見ており、ここでRTCのIPアドレスが高くなっていると仮定すると、VCはステップ2で閉鎖されます。
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は、最小限の実装にもかかわらず、Helloを受け入れる必要があります。
3 Acknowledgments
3謝辞
Comments and contributions from several sources, especially Rob Coltun, Doug Dykeman, John Moy and Alex Zinin are included in this work.
いくつかの情報源からのコメントと貢献、特にロブ・コルトン、ダグ・ディークマン、ジョン・モイ、アレックス・ジニンはこの作業に含まれています。
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プロトコルによって保証されなければなりません。Proxy-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フォーラム、「PNNI拡張ルーティング（PAR）バージョン1.0」。ATMフォーラムAF-RA-0104.000、1999年1月。
[2] Droz, P. and T. Przygienda, "Proxy-PAR", RFC 2843, May 2000.
[2] Droz、P。and T. Przygienda、「Proxy-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-Forum、「プライベートネットワークネットワークインターフェイス仕様バージョン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-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] ATM-Forum, "LAN Emulation over ATM 1.0." ATM Forum af-lane-0021.000, January 1995.
[6] ATM-Forum、「ATM 1.0を超えるLANエミュレーション」。ATMフォーラムAF-LANE-0021.000、1995年1月。
[7] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, November 1996.
[7] Armitage、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 Opaque LSAオプション」、RFC 2328、1998年7月。
[9] Davison, M., "ILMI-Based Server Discovery for ATMARP", RFC 2601, June 1999.
[9] Davison、M。、「IlmiベースのサーバーディスカバリーフォーAtmarp」、RFC 2601、1999年6月。
[10] Davison, M., "ILMI-Based Server Discovery for MARS", RFC 2602, June 1999.
[10] Davison、M。、「Ilmiベースのサーバーディスカバリーフォーマーズ」、RFC 2602、1999年6月。
[11] Davison, M., "ILMI-Based Server Discovery for NHRP", RFC 2603, June 1999.
[11] Davison、M。、「NHRPのILMIベースのサーバー発見」、RFC 2603、1999年6月。
[12] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[12] Moy、J。、「OSPFバージョン2」、RFC 2328、1998年4月。
[13] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995.
[13] Moy、J。、「需要回路をサポートするためにOSPFを拡張」、RFC 1793、1995年4月。
[14] deSouza, O. and M. Rodrigues, "Guidelines for Running OSPF Over Frame Relay Networks", RFC 1586, March 1994.
[14] Desouza、O。およびM. Rodrigues、「フレームリレーネットワークを介してOSPFを実行するためのガイドライン」、RFC 1586、1994年3月。
[15] Bradley, A. and C. Brown, "Inverse Address Resolution Protocol", RFC 2390, September 1999.
[15] Bradley、A。and C. Brown、「逆住所解像度プロトコル」、RFC 2390、1999年9月。
Authors' Addresses
著者のアドレス
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
Patrick Droz IBM Research Zurich Research Laboratory Saumerstrasse 4 8803 Ruschlikon Switzerland
パトリックドロズIBM研究チューリッヒ研究研究所ソーマーストラス4 8803ラッシュリコンスイス
EMail: dro@zurich.ibm.com
Robert Haas IBM Research Zurich Research Laboratory Saumerstrasse 4 8803 Ruschlikon Switzerland
Robert Haas IBM Research Zurich Research Laboratory Saumerstrasse 4 8803 Ruschlikon Switzerland
EMail: rha@zurich.ibm.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エディター機能の資金は現在、インターネット協会によって提供されています。