Network Working Group O. deSouza Request for Comments: 1586 M. Rodrigues Category: Informational AT&T Bell Laboratories March 1994 Guidelines for Running OSPF Over Frame Relay Networks ｜フレームリレー・ネットワーク上で ｜OSPF を動かすためのガイドライン Status of this Memo ｜このメモの状態 This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. ｜このメモはインターネット・コミュニティに対し情報を提供する。この ｜メモはいかなる類いのインターネット標準をも規定するものではない。 ｜このメモの配布は制限されない。 Abstract ｜要旨 This memo specifies guidelines for implementors and users of the Open Shortest Path First (OSPF) routing protocol to bring about improvements in how the protocol runs over frame relay networks. We show how to configure frame relay interfaces in a way that obviates the "full-mesh" connectivity required by current OSPF implementations. This allows for simpler, more economic network designs. These guidelines do not require any protocol changes; they only provide recommendations for how OSPF should be implemented and configured to use frame relay networks efficiently. ｜このメモはOSPF(Open Shortest Path First)経路制御プロトコルの実装者と ｜ユーザに対し、フレームリレー・ネットワーク上でこのプロトコルをどの ｜ように走らせるかについて、改善するためのガイドラインを示す。我々は ｜現在の OSPF の実装に要求される「フルメッシュ」接続を不要にする方法と ｜して、フレームリレー・インタフェースをどのように設定するかについて示す。 ｜これはより簡単に、より経済的なネットワークの設計を可能にする。これらの ｜ガイドラインはいかなるプロトコルの変更も要求しない;これらは単に、 どの ｜ようにOSPFを実装し、 効率的なフレームリレー・ネットワークを使用するよう ｜設定するかについての推奨を与えるだけである。 Acknowledgements ｜謝辞 This memo is the result of work done in the OSPF Working Group of the IETF. Comments and contributions from several sources, especially Fred Baker of ACC, John Moy of Proteon, and Bala Rajagopalan of AT&T Bell Laboratories are included in this work. ｜このメモはIETFのOSPFワーキング・グループの作業の完了結果で ｜ある。いくつかのソース、特にACCのFred Baker、Proteon の John Moy、 ｜及びAT&Tベル研究所の Bala Rajagopalan、からのコメントや貢献が、 ｜この作業に含まれている。 1. Introduction ｜はじめに A frame relay (FR) network provides virtual circuits (VCs) to interconnect attached devices. Each VC is uniquely identified at each FR interface by a Data Link Connection Identifier (DLCI). RFC 1294 specifies the encapsulation of multiprotocol traffic over FR [1]. The devices on a FR network may either be fully interconnected with a "mesh" of VCs, or partially interconnected. OSPF characterizes FR networks as non-broadcast multiple access (NBMA) because they can support more than two attached routers, but do not have a broadcast capability [2]. Under the NBMA model, the physical FR interface on a router corresponds to a single OSPF interface through which the router is connected to one or more neighbors on the FR network; all the neighboring routers must also be directly connected to each other over the FR network. Hence OSPF implementations that use the NBMA model for FR do not work when the routers are partially interconnected. Further, the topological representation of a multiple access network has each attached router bi-directionally connected to the network vertex with a single link metric assigned to the edge directed into the vertex. ｜フレームリレー(FR)ネットワークは接続されたデバイスを相互接続 ｜する仮想回線(VCs)を提供する。各VCはデータリンク接続識別子 ｜(DLCI)によって各FRインタフェースで一意に識別される。RFC ｜1294では、FRのマルチプロトコル・トラフィックのカプセル化について ｜記述している[1]。FRネットワーク上のデバイスは部分的又は全体的に ｜VCの「メッシュ」で相互接続されている。FRネットワークは2台以上 ｜のルータの接続をサポートするが、しかしブロードキャスト能力を持たな ｜いため、OSPFはこれらをノンブロードキャスト・マルチプルアクセス ｜(NBMA)としてみなす。NBMAモデルの下では、FRネットワーク ｜を通して1つ以上の近隣ルータに接続されたルータにおいて、物理的な ｜FRインタフェースは、単一のOSPFインタフェースに相当する;すべ ｜ての近隣ルータは、FRネットワーク上でお互いに直接に接続されなけれ ｜ばならない。ゆえにFRにNBMAモデルを使用したOSPFの実装は、 ｜ルータが部分的に相互接続されている時は動作しない。更にマルチプル・ ｜アクセス・ネットワークのトポロジー表現は、接続されたルータ毎に、 ｜接点に向かう切片に対して割り当てられた単一のリンク・メトリックを ｜もって、双方向に接続されているネットワーク接点を持つ。 We see that the NBMA model becomes more restrictive as the number of routers connected to the network increases. First, the number of VCs required for full-mesh connectivity increases quadratically with the number of routers. Public FR services typically offer performance guarantees for each VC provisioned by the service. This means that real physical resources in the FR network are devoted to each VC, and for this the customer eventually pays. The expense for full-mesh connectivity thus grows quadratically with the number of interconnected routers. We need to build OSPF implementations that allow for partial connectivity over FR. Second, using a single link metric (per TOS) for the FR interface does not allow OSPF to weigh some VCs more heavily than others according to the performance characteristics of each connection. To make efficient use of the FR network resources, it should be possible to assign different link metrics to different VCs. ｜我々はNBMAモデルがネットワークに接続されたルータ数の増加に対して、 ｜より制約となることを知っている。まず第一に、フルメッシュの接続に必要 ｜となるVCの数はルータの数に対して2次元的に増加する。一般の典型的な ｜FRサービスは、サービスによって提供された各VCに対してパフォーマンス ｜の保証を提供する。これはFRネットワークの実際の物理的資源が各VCに ｜あてがわれ、最終的に利用者がこれに対して支払うことを意味する。それゆえ、 ｜フルメッシュ接続の費用はルータの相互接続数に対して2次元的に増大する。 ｜我々はFRで部分的接続が可能なOSPFの実装を構築することを必要として ｜いる。第二に、FRインタフェースに対する(ToS毎の)単一のリンク・ ｜メトリックの使用は、いくつかのVCがそれぞれのコネクションがパフォー ｜マンス特性によって他のものよりもよりも重くなることを、OSPFに考慮 ｜させることを不可能にする。FRネットワーク資源を効率的に使用させる ｜ためには、異なるVCに対して異なるリンクメトリックを割当てることが ｜可能であるべきである。 These limitations of the current OSPF model for FR become more severe as the network size increases, and render FR technology less cost effective than it could be for large networks. We propose solutions to these problems that do not increase complexity by much and do not require any changes to the OSPF protocol. ｜FRに対する現在のOSPFモデルのこれらの制限は、ネットワーク・サイズ ｜の増大によって、より制限となり、大きなネットワークに対してよりもFR ｜技術のコスト効果を少なくする。我々はそれが増大しても複雑性を増加させる ｜ことなく、更にはOSPFプロトコルにいかなる変更も必要でない、これらの ｜問題の解決策を提案する。 2. Summary of Recommendations ｜推奨の要約 We propose expanding the general view of an OSPF interface to account for its functional type (point-to-point, broadcast, NBMA) rather than its physical type. In most instances, the physical network can only serve one function and can only be defined as one type of OSPF interface. For multiplexed interfaces such as FR however, logical connections between routers can serve different functions. Hence one VC on a FR interface can be viewed distintly from other VCs on the same physical interface. The solution requires that OSPF be able to support logical interfaces (networks) as well as physical interfaces. Each logical network can be either point-to-point, that is, a single VC, or NBMA, that is, a collection of VCs. It is not necessary to define new interface types for logical networks, since the operation of the protocol over logical point-to-point networks and logical NBMA networks remains the same as for the corresponding physical networks. For instance, logical point-to-point links could be numbered or unnumbered. It is only necessary for implementations to provide the hooks that give users the ability to configure an individual VC as a logical point-to-point network or a collection of VCs as a logical NBMA network. ｜我々はOSPFインタフェースの一般的な見解を、その物理的な種別よりも、 ｜むしろその機能種別(ポイント・ツー・ポイント、ブロードキャスト、 ｜NBMA)から拡張することを提案する。大部分のインスタンスで、物理的 ｜なネットワークは1つの機能だけを提供することができ、単にOSPFインタ ｜フェースの1タイプとして定義することができる。しかしながらFRのような ｜マルチプル・インターフェースでは、ルータ間の論理的な接続は異なる機能を ｜提供することができる。従ってFRインタフェースの1VCは、同じ物理 ｜インタフェース上の他のVCから区別して見ることができる。これの解決には、 ｜OSPFが物理インタフェースと同様に、論理インタフェース(ネットワーク) ｜をサポートできることが要求される。それぞれの論理的なネットワークで、 ｜1つのVCをポイント・ツー・ポイントとするのも、あるいはVCの集まり ｜をNBMAとするのも、そのどちらもが可能である。論理的なポイントー・ツー ｜・ポイント・ネットワーク及び論理的なNBMAネットワーク上でのプロトコル ｜の動作は、対応する物理的なネットワークと同一のままであるので、論理的な ｜ネットワークに対して新たなインタフェース種別を定義する必要はない。例えば、 ｜論理的なポイント・ツー・ポイント・リンクは番号付き、又は番号なしにする ｜ことができる。実装にはユーザに個々のVCを論理的なポイント・ツー・ポイント ｜として、又はVCの集まりを論理的なNBMAネットワークとして設定する能力 ｜をユーザに与えるためのフックを提供することのみ必要である。 The NBMA model does provide some economy in OSPF protocol processing and overhead and is the recommended mode of operation for small homogeneous networks. Other than the Designated Router (DR) and the backup Designated Router (BDR), each router maintains only two adjacencies, one each with the DR and BDR, regardless of the size of the NBMA network. When FR VCs are configured as point-to-point links, a router would have many more adjacencies to maintain, resulting in increased protocol overhead. If all VCs were to have comparable performance characteristics as well, there may not be compelling reasons to assign a different link metric to each VC. ｜NBMAモデルはOSPFのプロトコル処理とオーバヘッドをいくらか削減 ｜することを提供し、小規模なネットワークに対して運用が推奨されるモード ｜である。指名ルータ(DR)とバックアップ指名ルータ(BDR)以外の各 ｜ルータは、NBMAネットワークの大きさに関係なく、それぞれDRとBDR ｜の2つとだけ隣接関係を維持する。FRのVCをポイント・ツー・ポイントに ｜設定したならば、ルータはより多くの隣接関係を維持する必要があり、 ｜プロトコルのオーバーヘッドを増加させる結果となる。もし全てのVCが ｜同様に比較可能な性能特性を持っているとしても、各VCに異なるリンク・ ｜メトリックを割り当てる理由として強要されるものではない。 3. Implementing OSPF over FR ｜FRでのOSPFの実装 We recommend that OSPF router implementations be built so that administrators can configure network layer interfaces that consist of one or more FR VCs within a single physical interface. Each logical network interface could then be configured as the appropriate type of OSPF interface, that is, point-to-point for a single VC, or NBMA for a collection of VCs. This capability would allow a router to belong to one or more distinct IP subnets on a single physical FR interface. Thus, it is necessary that the router be able to support multiple IP addresses on a single physical FR interface. As with physical NBMA networks, logical NBMA networks must be full-mesh connected. While logical point-to-point links can be either numbered or unnumbered, we show that it is easier to implement routers to handle numbered logical point-to-point links. ｜我々は、管理者が1つの物理インタフェースに対して1つ以上のFRのVC ｜を含むネットワーク層のインタフェースを設定できるようOSPFルータの ｜実装が構築されることを推奨する。これは論理的な各ネットワーク・インタ ｜フェースをOSPFインタフェースの適切な種別に、つまり、1つのVCを ｜ポイント・ツー・ポイントに、VCの集まりをNBMAに、それぞれ設定 ｜可能にする。この機能はルータの1つの物理インタフェースを1つ以上の ｜異なるIPサブネットに属させることをルータに可能にする。それゆえルータ ｜は1つの物理インタフェースに複数のIPアドレスをサポートできる必要が ｜ある。物理的なNBMAネットワークで、論理的なNBMAネットワークは ｜はフル・メッシュ接続でなければならない。論理的なポイント・ツー・ ｜ポイントのリンクは、番号付きでも番号なしでもよく、我々は番号付きの ｜論理的なポイント・ツー・ポイントのリンクを扱うルータの実装の方が、 ｜より簡単であることを示している。 3.1 Numbered Logical Interfaces ｜番号付き論理インタフェース The router administrator should be able to configure numbered logical interfaces over FR as follows: ｜ルータ管理者は以下のようにFRに番号付き論理インタフェースを設定でき ｜なければならない。 STEP 1: Configure the physical interface specifying relevant parameters such as the slot, connector, and port numbers, physical frame format, encoding, and clock mode. In its internal interface MIB [3], the router should create a new ifEntry in the ifTable, assign the physical interface an ifIndex, and increment the ifNumber by one. ｜ステップ1: ｜スロット、コネクタ及びポート番号、物理的なフレーム・ ｜フォーマット、符号化、及びクロック・モードのような ｜関連するパラメータを指定する物理インタフェースを設定。 ｜その内部インタフェースMIB[3]で、ルータは ifTable に ｜新しい ifEntry を作成し、物理インタフェースに ifIndex を ｜を割り当て、ifNumner を1つずつインクリメントする必要がある。 STEP 2: Configure the data-link layer over the interface, specifying frame relay as the encapsulation method. Parameters such as the DLCI encoding type and length, maximum frame size, management interface (Annex D, LMI), and address resolution procedure (manual, inverse ARP). If a management interface is not supported, FR VCs must be configured manually. ｜ステップ2: ｜カプセル化手段としてフレームリレーを示すよう、インタフェース ｜にデータリンク層を設定。DLCI符号化種別と長さ、最大フレーム ｜長、管理インタフェース(Annex D, LMI)、及び、アドレス解決手段 ｜(手動、逆ARP)のようなパラメータ。もし管理インタフェースが ｜サポートされていないならば、FRのVCは手動で設定しなければ ｜ならない。 STEP 3: Configure the IP network layer for the interface by specifying the number of logical interfaces and the IP address and subnet mask for each numbered logical interface. Specify the VCs (by DLCI) associated with each logical network interface if there is more than one. If an address resolution protocol such as Inverse ARP [4] is being used, it should suffice to specify a list of IP addresses for the FR interface and have Inverse ARP create the DLCI-IP address binding. ｜ステップ3: ｜論理インタフェースの数と、番号付き論理インタフェース毎のIP ｜アドレスとサブネット・マスクを記述する、インタフェースのIP ｜ネットワーク層の設定。もし1つ以上あるならば、各論理インタ ｜フェースに関連した(DLCIによる)VCを指定すること。 ｜逆ARP[4]のような、アドレス解決プロトコルが使用されているの ｜であれば、FRインタフェースに対しIPアドレスのリストを ｜記述すれば十分であり、逆ARPがDLCI-IPアドレスを結び ｜つける。 STEP 4: Configure OSPF to run over each logical interface as appropriate, specifying the necessary interface parameters such as area ID, link metric, protocol timers and intervals, DR priority, and list of neighbors (for the DR). OSPF interfaces consisting of one VC can be treated as point-to-point links while multi-VC OSPF interfaces are treated as NBMA subnets. In its internal OSPF MIB [5], the router should create additional entries in the ospfIfTable each with the appropriate ospfIfType (nbma or pointTopoint). ｜ステップ4: ｜エリア識別子、リンク・メトリック、プロトコル・タイマ及び ｜インターバル、DR優先度、及び(DRのための)近隣ルータ ｜リストといった、必要なインタフェース・パラメータを示して、 ｜各論理インタフェースで適切にOSPFを実行するよう設定。 ｜1VCで構成されるOSPFインタフェースはポイント・ツー・ ｜ポイントのリンクとみなすことができると同時に、複数のVCの ｜OSPFインタフェースはNBMAサブネットとみなすことが ｜できる。内部OSPF・MIB[5]では、ルータは適切な ospfIfType ｜(nbma又はpointTopoint)で、ospfIfTable 内にそれぞれ追加 ｜エントリを作成しなければならない。 3.2 Unnumbered Point-to-Point Logical Interfaces ｜番号なしポイント・ツー・ポイント論理インタフェース OSPF uses the IP address to instance each numbered interface. However, since an unnumbered point-to-point link does not have an IP address, the ifIndex from the interface MIB is used instead [5]. This is straightforward for a physical point-to-point network, since the ifIndex is assigned when the interface is configured. Logical interfaces over FR however, do not have distinct and unique values for ifIndex. To allow OSPF to instance unnumbered logical point-to- point links, it is necessary to assign each such link a unique ifIndex in STEP 3 above. This could lead to some confusion in the interfaces table since a new ifTable entry would have to be created for each logical point-to-point link. This type of departure from the standard practice of creating interface table entries only for physical interfaces could be viewed as an unnecessary complication. ｜OSPFは、番号付きインタフェース毎のインスタンスにIPアドレスを ｜使用する。しかしながら、番号なしポイント・ツー・ポイント・リンクは ｜IPアドレスを持たないので、インタフェースMIBの ifIndex が代わり ｜に使用される[5]。これは、ifIndex はインタフェースが設定された際に ｜割り当てられるので、物理的なポイント・ツー・ポイントのネットワークに ｜素直である。しかしながらFRでの論理インタフェースでは、ifIndex に ｜別の固有の値が割り当てられていない。OSPFで番号なしのポイント・ツー ｜・ポイントのリンクのインスタンスを利用するために、上のSTEP3での ｜ifIndex に固有の値を、そのようなリンクそれぞれに割り当てる必要がある。 ｜これは新しい ifTable エントリが各論理的なポイント・ツー・ポイント・ ｜リンク毎に作成されるので、いくらかのインタフェース表の混乱をまねく。 ｜この物理インタフェースにインタフェース表のエントリだけを作成する ｜標準の作業から逸脱したこのタイプは、不必要な混乱とみなされる。 Alternatively, it is possible to build a private MIB that contains data structures to instance unnumbered logical links. However, making recommendations for the structure and use of such a private MIB is beyond the scope of this work. Even if unnumbered point-to-point logical links were implemented in this manner, it would still be necessary to allow a FR interface to be configured with multiple IP addresses when a router is connected to multiple NBMA subnets through a single physical interface. Hence, while it is possible to define unnumbered logical point-to-point links in OSPF, we find this alternative less attractive than using numbered logical point-to- point links. ｜代わりに、論理的な番号なしリンクのインスタンスのデータ構造を含む ｜プライベートMIBを構築することは可能である。しかしながら、プライ ｜ベートMIBのようなものの構造と使用についての推奨を作成することは、 ｜本作業の範囲を超えている。もし番号なしポイント・ツー・ポイントの ｜論理リンクがこの方法で実装されたとしてもまだ、FRインタフェースに ｜ルータが1つの物理インタフェースを通して複数のNBMAサブネットに ｜接続された場合に、複数のIPアドレスを設定するを可能にすることが ｜必要である。従って、OSPFで番号なし論理ポイント・ツー・ポイント・ ｜リンクの定義を可能にしても、我々はこの代案が番号付き論理ポイント・ ｜ツー・ポイント・リンクを使用することよりも、魅力的でないと考える。 4. Using OSPF over FR ｜FRでのOSPFの使用 The ability to configure distinct logical interfaces over FR gives users a great deal of flexibility in designing FR networks for use with OSPF. Because routers can be partially interconnected over FR, it is possible to design networks more cost-effectively than before. The issues to consider are the price/cost structure for VCs (fixed, distance-sensitive, banded) and ports, performance guarantees provided, traffic distribution (local, long-haul), and protocol efficiency. We have mentioned that the NBMA model provides some economy in OSPF protocol processing and overhead and is recommended for small homogeneous networks. In general, users should configure their networks to contain several small "NBMA clusters," which are in turn interconnected by long-haul VCs. The best choices for the number of routers in each cluster and the size of the long-haul logical point-to-point links depends on the factors mentioned above. If it is necessary to architect a more "flat" network, the ability to assign different link metrics to different (groups of) VCs allows for greater efficiency in using FR resources since VCs with better performance characteristics (throughput, delay) could be assigned lower link metrics. ｜FRで個別の論理インタフェースを設定する能力は、OSPFを使用した ｜FRネットワークの設計においてユーザにかなりの柔軟性を与える。なぜ ｜ならルータはFRで部分的に相互接続することが可能で、これはネット ｜ワーク設計において以前よりもよりコスト効果をよくすることを可能にする。 ｜考慮すべき問題は、VC(固定、距離に敏感、帯域)とポート、与えられた ｜パフォーマンスの保障、トラフィックの配分(ローカル、長距離)、及び ｜プロトコルの有効性に対する価格/コストである。我々はNBMAモデルが ｜OSPFのプロトコル処理とオーバーヘッドのいくらかの削減を提供し、 ｜小規模なネットワークに推奨することについて述べた。一般にユーザは、 ｜自分たちのネットワークにいくらかの小「NBMAクラスタ」を含むよう ｜設定し、これらは順に長距離VCによって相互接続されている。各クラスタ ｜内のルータ数と長距離の論理ポイント・ツー・ポイント・リンクの大きさの ｜最良の選択は、上で述べた要因に依存する。より「平面的な」ネットワークの ｜設定が設計者に必要ならば、異なるリンク・メトリックを異なったVC ｜(のグループ)に割り当てるための能力は、よりよいパフォーマンス特性 ｜(スループット、遅延)のVCを、より低いリンク・メトリックに割り当てる ｜ことができるので、FR資源の利用をより効果的にすることができる。 5. Conclusion ｜終りに We have specified guidelines for OSPF implementors and users to bring about improvements in how the protocol runs over frame relay networks. These recommendations do not require any protocol changes and allow for simpler, more efficient and cost-effective network designs. We recommend that OSPF implementations be able to support logical interfaces, each consisting of one or more virtual circuits and used as numbered logical point-to-point links (one VC) or logical NBMA networks (more than one VC). The current NBMA model for frame relay should continue to be used for small homogeneous networks consisting of a few routers. ｜我々はOSPFの実装者とユーザのために、フレームリレー・ネットワークで ｜プロトコルをどのように動作させるかについて、改善をもたらすための ｜ガイドラインを示した。これらの推奨はいかなるプロトコルの変更も要求 ｜しないで、より簡単により効果的でコスト効果のよいネットワーク設計を ｜可能にする。我々は、それぞれが1以上の仮想回線で構成され、論理的な ｜番号付きポイント・ツー・ポイント・リンク(1VC)あるいは論理的な ｜NBMAネットワーク(2以上のVC)として使用される論理インタフェース ｜をサポートすることが可能なようにOSPFを実装することを推奨する。 ｜フレームリレーのための現在のNBMAモデルは、小数のルータで構成される ｜構成される小規模なネットワークのために使用され続ける 6. References ｜参考 [1] Bradley, T., Brown, C., and A. Malis, "Multiprotocol Interconnect over Frame Relay", RFC 1294, Wellfleet Communications, Inc., BBN Communications, January 1992. [2] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 1994. [3] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based Internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Inc., Performance Systems International, March 1991. [4] Bradley, T., and C. Brown, "Inverse Address Resolution Protocol", RFC 1293, Wellfleet Communications, Inc., January 1992. [5] Baker, F., and R. Coltun, "OSPF Version 2 Management Information Base", RFC 1253, ACC, Computer Science Center, August 1991. Security Considerations ｜セキュリティに関する考察 Security issues are not discussed in this memo. ｜このメモではセキュリティ問題は議論されていない。 7. Authors' Addresses ｜筆者のアドレス Osmund S. deSouza AT&T Bell Laboratories Room 1K-606 101 Crawfords Corner Road Holmdel, NJ 07733 Phone: (908) 949-1393 EMail: osmund.desouza@att.com Manoel A. Rodrigues Room 1K-608 AT&T Bell Laboratories 101 Crawfords Corner Road Holmdel, NJ 07733 Phone: (908) 949-4655 EMail: manoel.rodrigues@att.com -- 訳: O.K.U. ( oku@olive.plala.or.jp ) ( http://kotekote.zatunen.com/rfc/ ) 注: 翻訳内容に関していかなる保障もいたしません。