RFC2844 日本語訳
2844 OSPF over ATM and Proxy-PAR. T. Przygienda, P. Droz, R. Haas. May 2000. (Format: TXT=32146 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Przygienda
Request for Comments: 2844 Siara
Category: Experimental P. Droz
R. Haas
IBM
May 2000
Przygiendaがコメントのために要求するワーキンググループT.をネットワークでつないでください: 2844年のSiaraカテゴリ: 実験的なP.ドローR.ハースIBM2000年5月
OSPF over ATM and Proxy-PAR
気圧でのOSPFとプロキシ平価
Status of this Memo
この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.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
このメモは指定します、Proxy-PARの存在があるOSPF作成者、ユーザ、プロトコルがPVCの上のATMネットワークでどう作動するかを説明するメカニズム、およびSVCメッシュのために。 これらの推薦は、プロトコル変化を全く必要としないで、よりより簡単で、効率的でより費用効果的なネットワークデザインを許容します。 OSPF実装が放送インタフェースをシミュレートするソリューションが適切でない1個以上の仮想の回路からそれぞれ成って、番号付の論理的なポイントツーポイントが(1VC)、論理的なNBMAネットワーク(1VC)またはPointからMultiPointへのネットワーク(1VC)をリンクするので使用される論理的なインタフェースをサポートすることができるのは、お勧めです。 OSPFのできるルータが助けるとき、PARが、ATM雲の向こう側にそのようなインタフェースの構成セットアップと変化を広げるのを助けることができる、(再、)、構成されています。 ATM雲とそれに接続されたルータの間でこの情報を交換するのに順番にプロキシ-PARを使用できます。
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月の[1]にATM Forumによって認められました。 [2]でProxy-PARの下のセクションより多くの完全な概要を与えます。
Przygienda, et al. Experimental [Page 1] RFC 2844 OSPF over ATM and Proxy-PAR May 2000
Przygienda、他 気圧での実験的な[1ページ]RFC2844OSPFとプロキシ平価2000年5月
1.1 Introduction to Proxy-PAR
1.1 プロキシ平価への序論
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]はPARできるスイッチと対話して、PARを実行することのない非ATMサービス自体の情報について質問するために、デバイス(ルータのような)を異なった添付のATMに許容する拡大です。 ATMの付属デバイスのProxy-PARクライアント側は、完全なPARプロトコル・スタック(完全なPNNI[3]プロトコル・スタックを含んでいる)よりはるかに実装の複雑さとメモリ要件で簡単であり、簡単な実装を許容するはずです、例えば、既存のIPルータで。 さらに、クライアントは、それらがサポートする様々な非ATMサービスとプロトコルを登録するのにProxy-PARを使用できます。 PAR情報の複雑さによるILMI[4]の一部がプロトコルと非ATMプロトコルの、そして、サービスだけの統合のために意図するという事実を通ったので、プロキシPARは意識して省略されました。 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を通しているOSPFルータはATM[5]ファッションの上でClassical IPとARPのこの情報を使用するかもしれません、放送インタフェースをシミュレートするために互いに対話するために二地点間接続の完全なメッシュを形成して。 同じ目的のために、レイン[6]か火星[7]を使用できました。 副産物として、Proxy-PARはIPが付属しているデバイスのためのATMアドレス解決を提供できましたが、他のプロトコルでまた、IETFの仕様に基づきそのような解決を達成できます、例えば、[8]。 最後、しかし、特に、プロトコルがサーバ検出のときにIETFでILMI拡張子[9、10、11]で進行中の仕事と共存して、補足となるとここに言及されるべきです。
1.1.1 Proxy-PAR Scopes
1.1.1 プロキシ平価範囲
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].
Proxy-PARを通して登録されたどんな情報も、登録の間に確立される定義された範囲だけの中で水につかって、PNNIルーティングレベルに同等です。 分配された情報に関して仮定を全くすることができないので(例えばNSAPsに縛られたIPアドレスによってカプセル化か機能的マッピングなどのどんな点でも彼らに並べられるのは思われません)、それをまとめることができません。 これで、範囲の慎重な取り扱いはスケーラビリティを保存するのに必要になります。 [2]で範囲の使用法に関するその他の詳細を見つけることができます。
Przygienda, et al. Experimental [Page 2] RFC 2844 OSPF over ATM and Proxy-PAR May 2000
Przygienda、他 気圧での実験的な[2ページ]RFC2844OSPFとプロキシ平価2000年5月
1.2 Introduction to OSPF
1.2 OSPFへの紹介
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(開いているShortest Path First)はプロトコル(IGP)であって以下のパラグラフの大部分がほとんど文字通り取られた[12]で説明されたInteriorゲートウェイです。 OSPFは独身のAutonomous Systemに属すルータの間にルーティング情報を分配します。 OSPFプロトコルはリンク状態かSPF技術に基づいています。 それはインターネット・エンジニアリング・タスク・フォースのOSPFワーキンググループによって開発されました。 それはTCP/IPインターネット環境のために明白に設計されています、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.
Frame Relayか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.
+ 二地点間ネットワーク: 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プロトコル自体は放送能力を利用します。 存在しているなら、プロトコルはさらにマルチキャスト能力を利用します。 イーサネットは放送網に関する例です。
+ 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 Public Data Network(PDN)は非放送網に関する例です。
Przygienda, et al. Experimental [Page 3] RFC 2844 OSPF over ATM and Proxy-PAR May 2000
Przygienda、他 気圧での実験的な[3ページ]RFC2844OSPFとプロキシ平価2000年5月
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つのモードの1つへ駆け込みます。 非放送マルチアクセス(NBMA)と呼ばれる最初のモードは放送網におけるOSPFの操作をシミュレートします。 PointからMultiPointと呼ばれる2番目のモードはポイントツーポイント接続の収集として非放送網を扱います。 ネットワークの上でOSPFの運転モードによって、非放送網はNBMAネットワークかPointからMultiPointへのネットワークと呼ばれます。
2 OSPF over ATM
2 気圧でのOSPF
2.1 Model
2.1 モデル
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.
ATM[5]の上のレイン[6]かClassical IPやARPなどの放送シミュレーションベースのソリューションとは逆に、このドキュメントはNBMA、PointからMultiPointまたはポイントツーポイントなどのATMの上で仮想のOSPFインタフェースを扱って、Proxy-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.
もう片方の主な利益はOSPF隣人の自動発見からNBMAとPointからMultiPoint ATMへのネットワークの上のOSPFを実行して、それでも、利益を実行する能力です。 放送網、放送シミュレーションを拠点とするネットワーク(ATMの上のレインかClassical IPやARPなどの)、および二地点間ネットワークと対照的に、これは、NBMAの上のそうとPointからMultiPointへのネットワークではありません。そこでは、OSPFルータが、パケットをHelloに送ることによって、All-SPFRoutersマルチキャストアドレスにダイナミックに隣人を発見します。 NBMAネットワークでは、同じNBMAネットワークへの他のすべての付属ルータのリストは、ある他の手段で手動で構成されなければならないか、または発見されなければなりません: プロキシ-PARは、この構成が自動化されているのを許容します。 PointからMultiPointへのネットワークでも、直接届いているルータのセットは、手動で構成しているか、またはInverse ATMARPなどのProxy-PARかメカニズムでダイナミックに発見できます。 ATMネットワークで(与えられたPVCのリモートエンドでルータのIPアドレスを発見するのに[5]) 逆さのATMARPの8.2を使用できるのを確実にしてください、ATMアドレスが知られているか否かに関係なく。 しかし、例えば、リモートルータがProxy- PARと異なってOSPFを実行しているか否かに関係なく、Inverse ATMARPは戻りません。
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
[14]に平行です、同様のモデルは非放送インタフェースとしてVCsのポイントからポイントへのインタフェースか収集として独身のVCsをモデル化するのに基本的なATMネットワークを使用できるところで思われます、NBMAかPointからMultiPointへのモードにかかわらず。([14]はFrame Relayネットワークの上でOSPFのお勧めの操作について説明します)。 VCsのそのようなVCか収集が、論理的なインタフェースと呼ばれて、タイプ(Pointからポイントツーポイント、NBMAかMultiPointのどちらか)で指定されます、VPN ID、(
Przygienda, et al. Experimental [Page 4] RFC 2844 OSPF over ATM and Proxy-PAR May 2000
Przygienda、他 気圧での実験的な[4ページ]RFC2844OSPFとプロキシ平価2000年5月
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.
インタフェースが属する仮想の兵士のNetwork)、アドレスとマスク。 また、回路のアドレス解決メソッドや、クラスやサービスの質などの2つの特定の構成が使用した層、および他のものを含まなければなりません。 必然の結果としてそれについて、単一の、そして、物理的なインタフェースは複数のIPサブネットか複数のVPNsさえ取り囲むかもしれません。 Proxy-PARを実行するとき情報を扱う層2とIPとは逆に、情報がそのような論理的なインタフェースを操作する必要があったOSPFの大部分を静的にルータに構成する必要はありませんが、Proxy-PAR質問で提供できます。 これは例えばソリューションがするFrame Relayより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.
また、アドレスが0.0に設定するサブネットでプロキシ-PAR質問を発行できます。.0 .0 特定のサブネットアドレスの代わりに。 このタイプの質問は質問で指定された範囲の中のすべてのサブネットで利用可能なすべてのOSPFルータの情報を返します。 例えば、IPアドレス指定情報が構成されていないとき、これを使用できます。
2.2 Configuration of OSPF interfaces with Proxy-PAR
2.2 Proxy-PARとのOSPFインタフェースの構成
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雲の向こう側に非放送であって二地点間のインターフェース情報について学習できます。 ことによると隣人情報のProxy-PAR自動構成と手動の構成の混合物を考慮するのは実装まで達しています。 そのうえ、例えば、手動の構成は、Proxy-PARクライアントから得られた情報の、くつがえすか、または補足となるかもしれません。 さらに、時間の長期の間に少しのOSPFトラフィックも運ばないVCsの優雅な疾走を許すのに要求次第の回路[13]を扱うOSPF拡張子を使用できます。 説明されたコネセクション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]かレイン[6]の上のClassical IPやARPなどの通常、使用されたメカニズムのどれかを存在させているのは思われないので、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
プロキシ-PARは同じVPNの同じIPネットワークに単にProxy-PARサーバについて質問することによってあるすべてのルータのリストのautoconfiguationを許容します。各ルータは同じサブネットでそれらのルータプライオリティと対応するATMアドレスで容易にすべてのOSPFルータのリストを得ることができます。 これはOSPFのための前提条件です。
Przygienda, et al. Experimental [Page 5] RFC 2844 OSPF over ATM and Proxy-PAR May 2000
Przygienda、他 気圧での実験的な[5ページ]RFC2844OSPFとプロキシ平価2000年5月
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).
そのような論理的なNBMAインタフェースの向こう側に適切に働いてください。 Proxy-PAR質問で学習されるとこのメンバーリストがダイナミックにPNNI (in)の安定性と一般的なATMネットワークの振舞いを交換できることに注意してください。 かぶせることにおける、可到達性の不足を発見するためにOSPFメカニズムを当てにして、論理的なIPネットワークはDR選挙と過度の情報氾濫を打たせる危険を軽減できました。 いったんDR選挙が終了して、ルータがDRかBDRに選出されていないと、[13]の実装はDRとBDRにVCsを維持するのが必要であるだけであるので、特定のNBMAサブネットに関するすべてのルータが構成で利用可能であるという事実を無視できます。この情報がデータ・パケットの推進などの他の目的に役立つことができることに注意してください(セクション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ネットワークのためのルータ構成は、適切なプロトコル操作を考慮するためにすべての隣接しているルータのリストを提供します。 安定性目的のために、ユーザは、そのような静的な手段で隣人のリストを提供しますが、Proxy-PARプロトコルの操作がリストを完成するのをまた可能にするのを選ぶかもしれません。 それは動的情報をフィルターにかけるのに手動の構成を使用するためにProxy-PARによって提供された情報に加えて手動の構成を使用するかどうか、または操作の同時発生のモードが禁止されているかどうか決定するのが特定のルータ実装に任せられます。 どのような場合でも、より多くの柔軟性を考慮すると、また、misconfigurationに操作が容易にされるかもしれませんが、より多くの可能性が供給されるのは、明白であるべきです。
2.2.2 Autoconfiguration of Point-to-MultiPoint Interfaces
2.2.2 ポイントツーマルチポイントインタフェースの自動構成
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ネットワークが通常NBMA雲をOSPFに提示するのでダイナミックにVCsを全くセットアップできない場合にだけ、ATMネットワークにおけるポイントからMultiPointへのインタフェースは理解できます。 例えば、OSPFが部分的なPVCで構成されたネットワーク、SPVCメッシュまたは予定されたSVCの上でメッシュを実行するなら、これはそうです。 PointからMultiPoint OSPFへのインタフェースを使用することでそのようなネットワークをモデル化できるでしょう、そして、Proxy-PARか他の手段で隣人検出を提供できるでしょう。 Proxy-PAR場合では、ルータはすべてのOSPFのために同じVPNの同じネットワークでルータについて質問しますが、それは既存のPVCsを通して既に届いているルータだけをインタフェース構成にインストールします。 基本的な仮定はルータがPVCのリモートATMアドレスを知って、適切なProxy-PAR登録証明書とそれを比べることができるということです。 PVCのリモートATMアドレスが未知であるなら、Inverse ARP[15]のようなメカニズムはそれを発見できます。
Przygienda, et al. Experimental [Page 6] RFC 2844 OSPF over ATM and Proxy-PAR May 2000
Przygienda、他 気圧での実験的な[6ページ]RFC2844OSPFとプロキシ平価2000年5月
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.
プロキシ-PARは正しいOSPF隣人検出メカニズムを提供しますが、Inverse ARPのようなメカニズムは直接届いているルータ(必ずOSPFを実行しているというわけではない)のアドレスを返すだけです、PointからマルチPointへの環境で。
2.2.3 Autoconfiguration of Numbered Point-to-Point Interfaces
2.2.3 番号付の二地点間インタフェースの自動構成
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アドレスとマスクが必要です。 したがって、同じくらい良いならIPアドレスがネットマスクがセットしたからでなければならないルータが、それが隣接番組を形成するつもりであるルータにポイントツーポイント接続の地方の端の広告を出すのにProxy-PARを使用することを望んでいるか、255.255のデフォルトが.252(2つのルータがそれにある状態で、これは不履行格としてサブネットを与える)が仮定した.255であるなら。 255.255のインタフェースでは、遠隔地側のIPアドレスを提供しなければならないというリモートエンドの発見とネットマスクセットかデフォルトに.252が仮定した.255を許容するために。 インタフェースの両側は同じネットワークマスクで構成されて、同じ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.
マルチキャストHelloパケットをポイントツーポイント接続に送るのは、OSPF隣人が自動的に発見されるのを許容します。 他方では、Proxy-PARを使用するのは、代わりに必ずOSPFを実行しているというわけではないルータへのメッセージをHelloに送るのを避けます。
2.2.4 Autoconfiguration of Unnumbered Point-to-Point Interfaces
2.2.4 無数の二地点間インタフェースの自動構成
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エントリーに基づく付番メソッドを当てにするのは、そのようなエントリーの作成のダイナミックな本質で闘争を生成して、この仕事の範囲を超えています。
2.3 Registration of OSPF interfaces with Proxy-PAR
2.3 Proxy-PARとのOSPFインタフェースの登録
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アドレス、マスク、Area ID、インターフェース型、およびルータ優先権情報を適切な範囲のProxy-PARサーバに示さなければなりません。 これらのパラメタのどれかにおける変化はProxy-PARと共に再登録を強制しなければなりません。
Przygienda, et al. Experimental [Page 7] RFC 2844 OSPF over ATM and Proxy-PAR May 2000
Przygienda、他 気圧での実験的な[7ページ]RFC2844OSPFとプロキシ平価2000年5月
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アドレスを登録しなければならないと強調されるべきです。 サブネットをマスクの長さまで示すのは十分ではありません。 すべてのアドレスビットを提供しなければなりません。
2.3.1 Registration of Non-Broadcast Multiple-Access Interfaces
2.3.1 非放送複数のアクセスインタフェースの登録
For an NBMA interface the appropriate parameters are available and can be registered through Proxy-PAR without further complications.
NBMAインタフェースに関しては、適切なパラメタは、利用可能であり、Proxy-PARを通してさらなる複雑さなしで示すことができます。
2.3.2 Registration of Point-to-Multipoint Interfaces
2.3.2 ポイントツーマルチポイントインタフェースの登録
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.
PointからMultiPointへのインタフェースの場合では、ルータはNBMAケースのように同じファッションによる情報を登録します、インターフェース型がそれに従って、変更されるのを除いて。
2.3.3 Registration of Numbered Point-to-Point Interfaces
2.3.3 番号付の二地点間インタフェースの登録
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構成で指定されません。 ルータが能力の広告を出すProxy-PARを使用しなければならないなら、マスクは、定義されていて255.255のデフォルト値であるに違いありません。.255 .252 使用されます。
2.3.4 Registration of Unnumbered Point-to-Point Interfaces
2.3.4 無数の二地点間インタフェースの登録
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アドレスと、より早く説明されるようにこの事実によって作られた困難の不足のために、無数の二地点間インタフェースの登録は本書ではカバーされていません。
2.4 IP address to NSAP Resolution Using Proxy-PAR
2.4 NSAP Resolution Using Proxy-PARへの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.
Proxy-PAR存在の副産物として、ATMARP[5]などの静的なデータかメカニズムを使用する必要はなくて、OSPF実装はIPアドレスの解決にサブネットで登録証明書にATM NSAPsに情報を使用するかもしれません。 これで、ATMの上でOSPFを操作するのにかかわるメカニズムの数の抜本的な簡素化は再びIPオーバレイを提供できるべきです。
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.
システム見解から、図1のようにOSPFの部品、Proxy-PARクライアント、NSAPアドレス解決テーブルへのIP、およびATM回路マネージャについて表現できます。 図1はProxy-PARクライアントからのProxy-PAR質問で引き起こされたコンポーネント相互作用に関する例を示しています。
Przygienda, et al. Experimental [Page 8] RFC 2844 OSPF over ATM and Proxy-PAR May 2000
Przygienda、他 気圧での実験的な[8ページ]RFC2844OSPFとプロキシ平価2000年5月
2.5 Connection Setup Mechanisms
2.5 接続設定メカニズム
This section describes the OSPF behavior in an ATM network under various assumptions in terms of signaling capabilities and preset connectivity.
このセクションは、シグナリング能力に関してATMネットワークで様々な仮定でOSPFの振舞いについて説明して、接続性をあらかじめセットします。
2.5.1 OSPF in PVC Environments
2.5.1 PVC環境における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.
PointからMultiPointが連結するとき、部分的なPVCs(または、SPVCs)メッシュだけが利用可能であってモデル化されている環境で、ルータはProxy-PARによって提供されたautodiscoveryで届いているルータを見ます。 これは予想されたOSPFの振舞いに通じます。 望ましくは、PVCsの完全なメッシュが出席している場合では、そのようなネットワークは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 |__________|
__________ _________ | | | | | OSPF| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|プロキシ平価| <、-、--(プロキシ-PAR質問) |__________| 通知してください。| クライアント| ^隣人変化|_________| | | そして発信。| | Proxy-PARが受信すると主張してください。| | テーブルOSPF msgのエントリー| | | | | | ____V____ ____V_____ | 気圧| | | | 回路|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|NSAPへのIP| | マネージャ| チェック| テーブル| |_________| NSAP結合へのIP|__________|
Figure 1: System perspective of typical components interactions.
図1: 典型的なコンポーネント相互作用のシステム見解。
Przygienda, et al. Experimental [Page 9] RFC 2844 OSPF over ATM and Proxy-PAR May 2000
Przygienda、他 気圧での実験的な[9ページ]RFC2844OSPFとプロキシ平価2000年5月
2.5.2 OSPF in SVC Environments
2.5.2 SVC環境におけるOSPF
+ + +
| +---+ | |
+--+ |---|RTA|---| +-------+ | +--+
|H1|---| +---+ | | ATM | |---|H2|
+--+ | | +---+ | Cloud | +---+ | +--+
|LAN Y |---|RTB|-------------|RTC|---|
+ | +---+ | PPAR | +---+ |
+ +-------+ +
+ + + | +---+ | | +--+ |---|RTA|---| +-------+ | +--+ |H1|---| +---+ | | 気圧| |---|H2| +--+ | | +---+ | 雲| +---+ | +--+ |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がNBMA ATMの向こう側に作動している簡単なトポロジーはProxy-PARに連結します。
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パケットなどのデータを送る必要性によって駆り立てられた適切な隣人を発見した後に、ルータはVCsを開始できます。 これは両側が同時にVCを開くことができる競合条件に通じることができます。 一般に、この貴重なリソースを浪費するのを避けるのは望ましいです: 低いIPアドレス(すなわち、OSPFインタフェースのIPアドレスはProxy-PARとともに記名した)があるルータがそれを検出するなら反対側によって開始されたVCが双方向である、それはそれ自身のVCを閉じて、自由に検出されたものを使用できます。 これが、OSPF実装がHelloメッセージを送って、受け取るのに使用されるVCs、または特定のVCsの使用法を意識しているためにVCsを管理するのにおいて原因となるコンポーネントを意識しているのを必要とすることに注意してください。
Observe that this behavior operates correctly in case OSPF over Demand Circuits extensions are used [13] over SVC capable interfaces.
この振舞いがDemand Circuits拡張子の上のOSPFがSVCのできるインタフェースの上の中古の[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.
たいてい、質問の間には、間隔より大きい時間のamoutによるProxy-PARクライアントからサーバまでの低いIPアドレスがある状態でルータから最初のOSPF Helloの発信を遅らせることによって余分なVCsのセットアップを避けるのは可能です。より高いIPアドレスがあるルータは、多分、低いIPアドレスと共にVC(既に既存のVCを使用する)を開いて、最初に、質問の間隔がルータのHello遅れより短いなら、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
ルータが他のルータにデータを転送するのに論理的なインタフェースの中で使用するのを選ぶVCsの数とタイプにおいて、OSPF交換に使用されるVCsの存在は直交しています。 OSPF実現はそれらのエンドポイントが適切であるか、そして、必須がVCs属のいずれにも到着するHelloパケットを受け入れるパケットを送るこれらのVCs(彼らが彼らの存在を知っているといけないので)からいずれも自由に使用できます。
Przygienda, et al. Experimental [Page 10] RFC 2844 OSPF over ATM and Proxy-PAR May 2000
Przygienda、他 気圧での実験的な[10ページ]RFC2844OSPFとプロキシ平価2000年5月
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がそれらの存在を知らないでも、連結してください。 OSPF実現はProxy-PARによって発見されていない別のルータによって開始される接続を無視するかもしれません。 どのような場合でも、OSPF実現はProxy-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がサービスをProxy-PARに提供する一般的なATM雲に接続される図2のトポロジーを考えてください。 RTBのOSPF実現がインタフェースで開始されたSVCsを意識していて、RTCがProxy-PAR情報の最小量の使用をするだけであると仮定する場合、以下の系列は展開するかもしれません、以下の上で説明されたケースのいくつかを例証して
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はHelloを送ります。(それはHelloによってやむを得ずSVC接続をRTCに確立します)。
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は、HelloをRTBに送りますが、既に既存の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アドレスが、より高いと仮定して、ステップ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が、HelloをRTCに送って、そう使用すると決める、データ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.
いくつかのソース、特にロブColtun、ダグDykeman、ジョンMoy、およびアレックス・ジニンからのコメントと貢献はこの仕事に含まれています。
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
いくつかの局面はATM、そして/または、Proxy-PARの上で操作OSPFのセキュリティの文脈で考えられることです。 基本的なPNNIプロトコルでATM雲に手渡された登録された情報のセキュリティを保証しなければなりません。 Proxy- PARを通した登録自体は保証されません、そして、さらなる研究にはその結果適切な手段がありますか? しかしながら、ATM層のセキュリティが保証されないでも、それについて確かめるのにOSPFセキュリティー対策を使用できます。
Przygienda, et al. Experimental [Page 11] RFC 2844 OSPF over ATM and Proxy-PAR May 2000
Przygienda、他 気圧での実験的な[11ページ]RFC2844OSPFとプロキシ平価2000年5月
detected neighbors are authorized to interact with the entity discovering them.
検出された隣人が彼らを発見する実体と対話するのに権限を与えられます。
5 Bibliography
5 図書目録
[1] ATM Forum, "PNNI Augmented Routing (PAR) Version 1.0." ATM
Forum af-ra-0104.000, January 1999.
[1]、気圧フォーラム、「(平価)バージョン1.0を発送するのを増大するPNNI。」 1999年1月のATM Forum af-ra-0104.000。
[2] Droz, P. and T. Przygienda, "Proxy-PAR", RFC 2843, May 2000.
[2] ドロー、P.、およびT.Przygienda(「プロキシ平価」、RFC2843)は2000がそうするかもしれません。
[3] ATM-Forum, "Private Network-Network Interface Specification
Version 1.0." ATM Forum af-pnni-0055.000, March 1996.
[3]気圧フォーラム、「個人的なネットワークネットワーク・インターフェース仕様バージョン1.0。」 1996年3月のATM Forum af-pnni-0055.000。
[4] ATM-Forum, "Interim Local Management Interface, (ILMI)
Specification 4.0." ATM Forum af-ilmi-0065.000, September 1996.
[4]気圧フォーラム、「当座の現地管理職者インタフェース、(ILMI)仕様4.0。」 1996年9月のATM Forum af-ilmi-0065.000。
[5] Laubach, J., "Classical IP and ARP over ATM", RFC 2225, April
1998.
[5]Laubachと、J.と、「気圧での古典的なIPとARP」、RFC2225、4月1998日
[6] ATM-Forum, "LAN Emulation over ATM 1.0." ATM Forum af-lane-
0021.000, January 1995.
[6]気圧フォーラム、「気圧1.0でのLANエミュレーション。」 1995年1月のATM Forum af車線-0021.000。
[7] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM
Networks", RFC 2022, November 1996.
[7] アーミテージ、G.、「UNI3.0/3.1の上のMulticastのサポートはATM Networksを基礎づけた」RFC2022、1996年11月。
[8] Coltun, R., "The OSPF Opaque LSA Option", RFC 2328, July 1998.
[8]Coltun、1998年7月のR.、「OSPFの不明瞭なLSAオプション」RFC2328。
[9] Davison, M., "ILMI-Based Server Discovery for ATMARP", RFC 2601,
June 1999.
[9] デイヴィソン、1999年6月、M.、「ATMARPのためのILMIベースのサーバディスカバリー」RFC2601。
[10] Davison, M., "ILMI-Based Server Discovery for MARS", RFC 2602,
June 1999.
[10] デイヴィソン、1999年6月、M.、「火星のためのILMIベースのサーバディスカバリー」RFC2602。
[11] Davison, M., "ILMI-Based Server Discovery for NHRP", RFC 2603,
June 1999.
[11] デイヴィソン、1999年6月、M.、「NHRPのためのILMIベースのサーバディスカバリー」RFC2603。
[12] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[12]Moy、J.、「OSPF、バージョン2インチ、RFC2328、1998インチ年4月。
[13] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793,
April 1995.
[13]Moy、J.、「要求サーキットを支えるためにOSPFを広げています」、RFC1793、1995年4月。
[14] deSouza, O. and M. Rodrigues, "Guidelines for Running OSPF Over
Frame Relay Networks", RFC 1586, March 1994.
[14]deSouzaとO.とM.ロドリーグ、「フレームリレーネットワークの上でOSPFを走らせるためのガイドライン」、RFC1586、1994年3月。
[15] Bradley, A. and C. Brown, "Inverse Address Resolution Protocol",
RFC 2390, September 1999.
[15]ブラッドリーとA.とC.ブラウン、「逆さのアドレス解決プロトコル」、RFC2390、1999年9月。
Przygienda, et al. Experimental [Page 12] RFC 2844 OSPF over ATM and Proxy-PAR May 2000
Przygienda、他 気圧での実験的な[12ページ]RFC2844OSPFとプロキシ平価2000年5月
Authors' Addresses
作者のアドレス
Tony Przygienda Siara Systems Incorporated 1195 Borregas Avenue Sunnyvale, CA 94089 USA
トニーPrzygienda Siara Systemsは1195Borregas Avenueカリフォルニア94089サニーベル(米国)を法人組織にしました。
EMail: prz@siara.com
メール: prz@siara.com
Patrick Droz IBM Research Zurich Research Laboratory Saumerstrasse 4 8803 Ruschlikon Switzerland
パトリックドローIBM研究チューリッヒ研究所Saumerstrasse4 8803Ruschlikonスイス
EMail: dro@zurich.ibm.com
メール: dro@zurich.ibm.com
Robert Haas IBM Research Zurich Research Laboratory Saumerstrasse 4 8803 Ruschlikon Switzerland
ロバートハースIBM研究チューリッヒ研究所Saumerstrasse4 8803Ruschlikonスイス
EMail: rha@zurich.ibm.com
メール: rha@zurich.ibm.com
Przygienda, et al. Experimental [Page 13] RFC 2844 OSPF over ATM and Proxy-PAR May 2000
Przygienda、他 気圧での実験的な[13ページ]RFC2844OSPFとプロキシ平価2000年5月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Przygienda, et al. Experimental [Page 14]
Przygienda、他 実験的[14ページ]
一覧
スポンサーリンク
