RFC1246 日本語訳
1246 Experience with the OSPF Protocol. J. Moy. July 1991. (Format: TXT=70441, PS=141924, PDF=84633 bytes) (Also RFC1247, RFC1245) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Moy, Editor Request for Comments: 1246 July 1991
ワーキンググループJ.Moy、コメントを求めるエディタ要求をネットワークでつないでください: 1246 1991年7月
Experience with the OSPF protocol
OSPFプロトコルの経験
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify any Internet standard. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それは少しのインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This is the second of two reports on the OSPF protocol. These reports are required by the IAB/IESG in order for an Internet routing protocol to advance to Draft Standard Status. OSPF is a TCP/IP routing protocol, designed to be used internal to an Autonomous System (in other words, OSPF is an Interior Gateway Protocol).
これはOSPFプロトコルに関する2つのレポートの2番目です。 これらのレポートは、Draft Standard Statusに達するためにインターネットルーティング・プロトコルにおいて、整然としているIAB/IESGによって必要とされます。 OSPFはAutonomous Systemに内部で使用されるように設計されたTCP/IPルーティング・プロトコル(言い換えれば、OSPFはInteriorゲートウェイプロトコルである)です。
OSPF is currently designated as a Proposed Standard. Version 1 of the OSPF protocol was published in RFC 1131. Since then OSPF version 2 has been developed. Version 2 has been documented in RFC 1247. The changes between version 1 and version 2 of the OSPF protocol are explained in Appendix F of RFC 1247. It is OSPF Version 2 that is the subject of this report.
OSPFは現在、Proposed Standardとして指定されます。 OSPFプロトコルのバージョン1はRFC1131で発行されました。 それ以来、OSPFバージョン2を開発してあります。 バージョン2はRFC1247に記録されました。 OSPFプロトコルのバージョン1とバージョン2の間の変化はRFC1247のAppendix Fで説明されます。 それはこのレポートの対象であるOSPFバージョン2です。
This report documents experience with OSPF V2. This includes reports on interoperability testing, field experience, simulations and the current state of OSPF implementations. It also presents a summary of the OSPF Management Information Base (MIB), and a summary of OSPF authentication mechanism.
このレポートはOSPF V2の経験を記録します。 これはOSPF実装の相互運用性テスト、実地経験、シミュレーション、および現状のレポートを含んでいます。 また、それはOSPF Management Information基地(MIB)の概要、およびOSPF認証機構の概要を提示します。
Please send comments to ospf@trantor.umd.edu.
コメントを ospf@trantor.umd.edu に送ってください。
1.0 Introduction
1.0 序論
This document addresses, for OSPF V2, the requirements set forth by the IAB/IESG for an Internet routing protocol to advance to Draft Standard state. This requirements are briefly summarized below. The remaining sections of this report document how OSPF V2 satisfies these requirements:
このドキュメントアドレス、OSPF V2に関して、インターネットルーティング・プロトコルがDraft Standard状態に達するように、要件はIAB/IESGで旅に出ます。 この要件は簡潔に以下へまとめられます。 このレポートの残っているセクションはOSPF V2がどうこれらの要件を満たすかを記録します:
[Moy] [Page 1] RFC 1246 Experience with OSPF July 1991
[Moy] RFC1246が1991年7月にOSPFと共に経験する[1ページ]
o The specification for the routing protocol must be well written such that independent, interoperable implementations can be developed solely based on the specification. For example, it should be possible to develop an interoperable implementation without consulting the original developers of the routing protocol.
o 唯一仕様に基づいて独立していて、共同利用できる実装を開発できるように上手にルーティング・プロトコルのための仕様を書かなければなりません。 例えば、ルーティング・プロトコルのオリジナルの開発者に相談しないで共同利用できる実装を開発するのは可能であるべきです。
o A Management Information Base (MIB) must be written for the protocol. The MIB must be in the standardization process, but does not need to be at the same level of standardization as the routing protocol.
o プロトコルのために、Management Information基地(MIB)を書かなければなりません。 MIBは標準化過程にあるに違いありませんが、同じレベルのルーティング・プロトコルへの標準化にはいる必要はありません。
o The security architecture of the protocol must be set forth explicitly. The security architecture must include mechanisms for authenticating routing messages and may include other forms of protection.
o 明らかにプロトコルのセキュリティー体系について詳しく説明しなければなりません。 セキュリティー体系は、ルーティング・メッセージを認証するためのメカニズムを含まなければならなくて、他の形式の保護を含むかもしれません。
o Two or more interoperable implementations must exist. At least two must be written independently.
o 2つ以上の共同利用できる実装が存在しなければなりません。 独自に少なくとも2を書かなければなりません。
o There must be evidence that all features of the protocol have been tested, running between at least two implementations. This must include that all of the security features have been demonstrated to operate, and that the mechanisms defined in the protocol actually provide the intended protection.
o 少なくとも2つの実装の間で稼働していて、プロトコルのすべての特徴がテストされたという証拠があるに違いありません。 セキュリティ機能のすべてが操作するために示されて、メカニズムが実際にプロトコルで定義したこの必須インクルードは意図している保護を提供します。
o There must be significant operational experience. This must include running in a moderate number routers configured in a moderately complex topology, and must be part of the operational Internet. All significant features of the protocol must be exercised. In the case of an Interior Gateway Protocol (IGP), both interior and exterior routes must be carried (unless another mechanism is provided for the exterior routes). In the case of a Exterior Gateway Protocol (EGP), it must carry the full complement of exterior routes.
o 重要な運用経験があるに違いありません。 これは、ルータが適度に複雑なトポロジーで構成した適度の数へ駆け込むのを含まなければならなくて、操作上のインターネットの一部であるに違いありません。 プロトコルに関するすべての著しい特徴を運動させなければなりません。 Interiorゲートウェイプロトコル(IGP)の場合では、内部の、そして、外の両方のルートを運ばなければなりません(別のメカニズムが外のルートに提供されない場合)。 Exteriorゲートウェイプロトコル(EGP)の場合では、それは外のルートの総定員を運ばなければなりません。
This report is a compilation of information obtained from many people. The reader is referred to specific people when more information on a subject is available. People references are gathered into Section 10.0, in a format similar to that used in [4].
このレポートは多くの人々から得られた情報の編集です。 話題の詳しい情報が利用可能であるときに、読者は特定の人々を参照されます。 人々参照は[4]で使用されるそれと同様の形式でセクション10.0に集められます。
1.1 Acknowledgments
1.1 承認
The OSPF protocol has been developed by the OSPF Working Group of the Internet Engineering Task Force. Many people have contributed to this report. They are listed in Section 10.0 of this report.
OSPFプロトコルはインターネット・エンジニアリング・タスク・フォースのOSPF作業部会によって開発されました。 多くの人々がこのレポートに貢献しました。 それらはこのレポートのセクション10.0に記載されています。
[Moy] [Page 2] RFC 1246 Experience with OSPF July 1991
[Moy] RFC1246が1991年7月にOSPFと共に経験する[2ページ]
2.0 Documentation
2.0 ドキュメンテーション
Version 1 of the OSPF protocol is documented in RFC 1131 [1]. OSPF Version 2, which supersedes Version 1, has been documented in RFC 1247 [2]. The differences between OSPF Version 1 and Version 2 are relatively minor, and are listed in Appendix F of RFC 1247 [2]. All information presented in this report concerns OSPF V2 unless explicitly mentioned otherwise.
OSPFプロトコルのバージョン1はRFC1131[1]に記録されます。 OSPFバージョン2(バージョン1に取って代わります)はRFC1247[2]に記録されました。 OSPFバージョン1とバージョン2の違いは、比較的小さい方であり、RFC1247[2]のAppendix Fに記載されています。 別の方法で明らかに言及されない場合、このレポートに提示されたすべての情報がOSPF V2に関係があります。
The OSPF protocol was developed by the OSPF Working Group of the Internet Engineering Task Force. This Working Group has a mailing list, ospf@trantor.umd.edu, where discussions of protocol features and operation are held. The OSPF Working Group also meets during the quarterly Internet Engineering Task Force conferences. Reports of these meeting are published in the IETF's Proceedings. In addition, two reports on the OSPF protocol have been presented to the IETF plenary (see "Everything You Ever Wanted to Know about OSPFIGP" in [5] and "OSPF Update" in [6]).
OSPFプロトコルはインターネット・エンジニアリング・タスク・フォースのOSPF作業部会によって開発されました。 この作業部会にはメーリングリスト、 ospf@trantor.umd.edu があります。そこでは、プロトコル機能と操作の議論が行われます。 また、OSPF作業部会は四半期のインターネット・エンジニアリング・タスク・フォース会議の間、会合します。 これらのミーティングのレポートはIETFのProceedingsで発表されます。 さらに、OSPFプロトコルに関する2つのレポートがIETFに絶対的な状態で提示されました。([5]と[6])の「OSPFアップデート」で「あなたが今までにOSPFIGPに関して知りたかったすべて」を見てください。
The OSPF protocol began undergoing field trials in Spring of 1990. A mailing list, ospf-tests@seka.cso.uiuc.edu, was formed to discuss how the field trials were proceeding. This mailing list is maintained by Ross Veach of the University of Illinois [rrv]. Archives of this list are also available. There has been quite a bit of discussion on the list concerning OSPF/RIP/EGP interaction.
OSPFプロトコルは1990年のSpringで実地試験を受け始めました。 メーリングリスト( ospf-tests@seka.cso.uiuc.edu )は、実地試験がどう続いていたかについて議論するために形成されました。 このメーリングリストはイリノイ[rrv]大学のロスVeachによって維持されます。 また、このリストのアーカイブも利用可能です。 OSPF/RIP/EGP相互作用に関してかなりの議論がリストにありました。
A OSPF V2 Management Information Base has also been developed and published in [3]. For more information, see Section 3.0 of this report.
また、OSPF V2 Management Information基地は、[3]で開発されて、発行されました。 詳しくは、このレポートのセクション3.0を見てください。
There is a free implementation of OSPF available from the University of Maryland. This implementation was written by Rob Coltun [rcoltun]. Contact Rob for details.
メリーランド大学から利用可能なOSPFの自由な実装があります。 この実装はロブColtun[rcoltun]によって書かれました。 詳細のためにロブに連絡してください。
3.0 MIB
3.0 MIB
An OSPF Management Information Base has been published in RFC 1248 [3]. The MIB was written by Rob Coltun [rcoltun] and Fred Baker [fbaker]. The OSPF MIB appears on the mgmt subtree as SMI standard-mib 13.
OSPF Management Information基地はRFC1248[3]で発行されました。 MIBはロブColtun[rcoltun]とフレッド・ベイカー[fbaker]によって書かれました。 OSPF MIBはSMI標準のmib13として管理下位木に現れます。
The OSPF MIB was originally developed by Rob Coltun of the University of Maryland, under contract to Advanced Computer Communications. A subset of his proposal was implemented to facilitate their development, and represents operational experience of a sort.
OSPF MIBは元々、メリーランド大学のロブColtunによって契約に基づきAdvancedコンピュータCommunicationsに開発されました。 彼の提案の部分集合は、彼らの開発を容易にするために実装されて、種類の運用経験を表します。
The MIB consists of a general variables group and ten tables:
MIBは一般的な変数グループと10個のテーブルから成ります:
TABLE 1. OSPF MIB Organization
1を見送ってください。 OSPF MIB組織
[Moy] [Page 3] RFC 1246 Experience with OSPF July 1991
[Moy] RFC1246が1991年7月にOSPFと共に経験する[3ページ]
Group Name Description
________________________________________________________________
ospfGeneralGroup General Global Variables
ospfAreaTable Area Descriptions
ospfStubAreaTable Default Metrics, by Type of Service
ospfLsdbTable Link State Database
ospfAreaRangeTable Address Range Specifications
ospfHostTable Directly connected Hosts
ospfIfTable OSPF Interface Variables
ospfIfMetricTable Interface Metrics, by Type of Service
ospfVirtIfTable Virtual Links
ospfNbrTable (Non-virtual) OSPF Neighbors
ospfVirtNbrTable Virtual OSPF Neighbors
グループ名記述________________________________________________________________ Service ospfVirtIfTable VirtualリンクスospfNbrTable(非仮想の)OSPFネイバーズospfVirtNbrTable Virtual OSPFネイバーズのTypeごとのospfGeneralGroup Global Variables ospfAreaTable Area記述ospfStubAreaTable Default Metrics司令官
As MIBs go, the OSPF MIB is quite large; 105 objects. The following are some statistics describing the distribution of the MIB's variables:
MIBsが行くとき、OSPF MIBはかなり大きいです。 105個のオブジェクト。 ↓これはMIBの変数の分配について説明するいくつかの統計です:
o 11 define the above Group and Tables
o 11は上のGroupとTablesを定義します。
o 10 define the Entry in a Table
o 10はTableでEntryを定義します。
o 7 are Counters
o 7はCountersです。
o 6 are Gauges
o 6はGaugesです。
o 68 objects mandated by the OSPF Version 2 Specification
o OSPFバージョン2Specificationによって強制された68個のオブジェクト
Section D.2 of the OSPF V2 specification [2] lists a set of required statistics that an implementation must maintain. These statistics have been incorporated into the OSPF MIB. The MIB's thirteen Counters and Gauges enable evaluation of the OSPF protocol's performance in an operational environment. Most of the remainder of the MIB's variables parameterize the many features that OSPF provides the network administrator.
OSPF V2仕様[2]のセクションD.2は実装が維持しなければならない1セットの必要な統計を記載します。 これらの統計をOSPF MIBに組み入れてあります。 MIBの13CountersとGaugesは運用環境における、OSPFプロトコルの性能の評価を可能にします。 MIBの変数の残りの大部分はOSPFがネットワーク管理者に提供する多くの特徴をparameterizeします。
For more information on the MIB contact Fred Baker [fbaker].
MIBの詳しい情報に関しては、フレッド・ベイカー[fbaker]に連絡してください。
4.0 Security architecture
4.0 セキュリティー体系
In OSPF, all protocol packet exchanges are authenticated. The OSPF packet header (which is common to all OSPF packets) contains a 16-bit Authentication type field, and 64-bits of Authentication data. Each particular OSPF area must run a single authentication scheme, as indicated by the Authentication type field. However, authentication keys can be configured by the system administrator on a per-network basis.
OSPFでは、すべてのプロトコルパケット交換が認証されます。 OSPFパケットのヘッダー(すべてのOSPFパケットに共通である)は16ビットのAuthenticationタイプ分野、および64ビットのAuthenticationデータを含みます。 それぞれの特定のOSPF領域はAuthenticationタイプ分野によって示されるようにただ一つの認証体系を実行しなければなりません。 しかしながら、システム管理者は1ネットワークあたり1個のベースで認証キーを構成できます。
[Moy] [Page 4] RFC 1246 Experience with OSPF July 1991
[Moy] RFC1246が1991年7月にOSPFと共に経験する[4ページ]
When an OSPF packet is received from a network, the OSPF router first verifies that it indicates the correct Authentication type. The router then authenticates the packet, running a verification algorithm using the configured authentication key, the 64-bits of Authentication data and the rest of the OSPF packet data as input. The precise algorithm used is dictated by the Authentication type. Packets failing the authentication algorithm are dropped, and the authentication failure is noted in a MIB-accessible variable (see [3]).
ネットワークからOSPFパケットを受け取るとき、OSPFルータは、最初に、正しいAuthenticationがタイプするのを示すことを確かめます。 次に、ルータはパケットを認証します、入力されるように構成された認証キー、Authenticationデータの64ビット、およびOSPFパケットデータの残りを使用することで検証アルゴリズムを実行して。 使用される正確なアルゴリズムはAuthenticationタイプによって決められます。 認証アルゴリズムに失敗するパケットが下げられます、そして、MIBアクセスしやすい変数で認証失敗に注意します。([3])を見てください。
There are currently few Authentication types in use. The current assignments are:
現在、Authenticationタイプがわずかしか使用中にありません。 現在の課題は以下の通りです。
TABLE 2. Current OSPF Authentication types.
2を見送ってください。 現在のOSPF Authenticationはタイプします。
Type code Algorithm ____________________________________________________________________ 0 No authentication performed. 1 Simple (clear) password. 2-255 Reserved for assignment by the IANA (iana@isi.edu) > 255 Available for local (per-AS) definition.
コードAlgorithmをタイプしてください。____________________________________________________________________ 0 認証は全く働きませんでした。 1つの簡単な(明確な)パスワード。 2-255がIANA( iana@isi.edu )による課題のために予約した、gt;、地方(1ASあたりの)の定義のための255Available。
For more information on OSPF's authentication procedures, see Sections 8.1, 8.2, and Appendix E of [2].
OSPFの認証手順の詳しい情報に関しては、セクション8.1、8.2、およびAppendix Eの[2]を見てください。
5.0 Implementations
5.0 実装
The are multiple, interoperable implementations of OSPF currently available. This section gives a brief overview of the five implementations that have participated in at least one round of interoperability testing. (For a detailed discussion of OSPF interoperability testing, see Section 7.0 of this report.) Other implementations do exist, but because of commercial realities (e.g., the product is not yet announced) they unfortunately cannot be listed here.
OSPFの現在利用可能な複数の、そして、共同利用できる実装はそうです。 このセクションは相互運用性テストの少なくとも1ラウンドに参加した5つの実装の簡潔な概要を与えます。 (OSPFの詳細な論議に関して、相互運用性がテストされて、このレポートのセクション7.0を見てください。) 他の実装は存在していますが、商業現実(例えば製品はまだ発表されていない)のために、残念ながら、ここにそれらを記載できません。
The five implementations that have participated in the OSPF interoperability testing are (listed in alphabetical order):
OSPF相互運用性テストに参加した5つの実装が(アルファベット順に記載される)です:
o 3com. This implementation was wholly developed by 3com. It has participated in all three rounds of interoperability testing. It is also the only implementation of OSPF's TOS routing.. The 3com implementation consists of approximately 9000 lines of C code, including comments but excluding user interface and MIB code. Consult Dino Farinacci [dino] for more details.
o 3com。 この実装は3comによって完全に開発されました。 それは相互運用性テストのすべての3ラウンドに参加しました。 また、それはOSPFのTOSルーティングの唯一の実装です。 3com実装はコメントにもかかわらず、ユーザーインタフェースとMIBコードを除くのを含むCコードのおよそ9000の行から成ります。 その他の詳細のためにディーノ・ファリナッチ[恐竜]に相談してください。
[Moy] [Page 5] RFC 1246 Experience with OSPF July 1991
[Moy] RFC1246が1991年7月にOSPFと共に経験する[5ページ]
o ACC. This implementation is based on the University of Maryland code. It participated in the last two rounds of interoperability testing. It also contains the only implementation of (a precursor to) the OSPF MIB (see Section 3.0 for details), which it uses for monitoring and configuration. The ACC implementation consists of approximately 24,000 lines of C code, including its OSPF MIB code. Consult Fred Baker [fbaker] for more details.
o ACC。 この実装はメリーランド大学コードに基づいています。 それは相互運用性テストの最後の2ラウンドに参加しました。 また、唯一の実装を含んでいる、(先駆、)、OSPF MIB(詳細に関してセクション3.0を見ます)。(それはモニターと構成にそのOSPF MIBを使用します)。 ACC実装はOSPF MIBコードを含むCコードのおよそ2万4000の行から成ります。 その他の詳細のために、フレッド・ベイカー[fbaker]に相談してください。
o Proteon. This implementation was wholly developed by Proteon. It has participated in all three rounds of interoperability testing. It is also the only implementation that has a significant amount of field experience (see Section 6.0 for details). The Proteon implementation consists of approximately 9500 lines of C code, including comments but excluding user interface code. Consult John Moy [jmoy] for more details.
o Proteon。 この実装はProteonによって完全に開発されました。 それは相互運用性テストのすべての3ラウンドに参加しました。 また、それはかなりの量の実地経験がある唯一の実装(詳細に関してセクション6.0を見る)です。 Proteon実装はコメントにもかかわらず、ユーザーインタフェースコードを除くのを含むCコードのおよそ9500の行から成ります。 その他の詳細のために、ジョンMoy[jmoy]に相談してください。
o Wellfleet. This implementation has participated in all three rounds of interoperability testing. Consult Jonathan Hsu [jhsu] for more details.
o Wellfleet。 この実装は相互運用性テストのすべての3ラウンドに参加しました。 その他の詳細のために、ジョナサン・シュー[jhsu]に相談してください。
o University of Maryland. This implementation was developed wholly by Rob Coltun at the University of Maryland. It has formed the basis for a number of commercial OSPF implementations, and also participated in the latest round of interoperability testing. The University of Maryland implementation consists of approximately 10,000 lines of C code. Consult Rob Coltun [rcoltun] for more details.
o メリーランド大学。 この実装はメリーランド大学のロブColtunによって完全に開発されました。 それは、多くの商業OSPF実装の基礎を形成して、また、相互運用性テストの最新のラウンドに参加しました。 メリーランド大学実装はCコードのおよそ1万の行から成ります。 その他の詳細のために、ロブColtun[rcoltun]に相談してください。
Note that, as required by the IAB/IESG for Draft Standard status, there are multiple interoperable independent implementations, namely those from 3com, Proteon and the University of Maryland.
Draft Standard状態のために必要に応じてIAB/IESGでそれに注意してください、そして、3com、Proteon、およびメリーランド大学からの複数の共同利用できる独立している実装、すなわち、それらがいます。
6.0 Operational experience
6.0 運用経験
This section discusses operational experience with the OSPF protocol. Version 1 of the OSPF protocol began to be deployed in the Internet in Spring of 1990. The results of this original deployment were reported to the mailing list ospf-tests@seka.cso.uiuc.edu. (Archives of this mailing list are available from Ross Veach [rrv].) No protocol bugs were found in this first deployment, although several additional features were found to be desirable. These new features were added to the protocol in OSPF Version 2.
このセクションはOSPFプロトコルの運用経験について論じます。 1990年のSpringのインターネットでOSPFプロトコルのバージョン1は配布され始めました。 このオリジナルの展開の結果はメーリングリスト ospf-tests@seka.cso.uiuc.edu に報告されました。 (このメーリングリストのアーカイブはロスVeach[rrv]から利用可能です。) いくつかの付加的な機能が望ましいのがわかりましたが、プロトコルバグは全くこの最初の展開では見つけられませんでした。 これらの新機能はOSPFバージョン2におけるプロトコルに追加されました。
The OSPF protocol is now deployed in a number of places in the Internet. In this section we focus on three highly visible systems, namely the NASA Sciences Internet, BARRNet and OARnet. The dimensions of these three OSPF systems is summarized in the following table:
OSPFプロトコルは現在、インターネットの多くの場所で配布されます。 BARRNetとOARnet、このセクションでは、私たちはすなわち、3台の非常に目に見えるシステム、NASA Sciencesインターネットに焦点を合わせます。 これらの3台のOSPFシステムの次元は以下のテーブルにまとめられます:
[Moy] [Page 6] RFC 1246 Experience with OSPF July 1991
[Moy] RFC1246が1991年7月にOSPFと共に経験する[6ページ]
TABLE 3. Three operational OSPF deployments
3を見送ってください。 3つの操作上のOSPF展開
Name Version 1 date Version 2 date # routers
_____________________________________________________
NSI 4/13/90 1/1/91 15
BARRNet 4/90 11/90 14
OARnet 10/15/90 not yet 13
名前バージョン1日付のバージョン2日付#ルータ_____________________________________________________ しかし、13ではなく10/15/90のNSI4/13/90 1/1/91 15BARRNet4/90 11/90 14OARnet
All the above deployments are using the Proteon OSPF implementation. There is one other deployment worth mentioning in this context. 3com has started to deploy OSPF on their corporate network. They have 8 of their routers running OSPF (the 3com implementation), and are planning on cutting over the remaining routers (20 in all). Currently they have two operational routers running OSPF and RIP simultaneously. One converts OSPF data to RIP data, and the other RIP data to OSPF data. For more details, contact Dino Farinacci [dino].
すべての上の展開がProteon OSPF実装を使用しています。 このような関係においては言及する価値がある他の1つの展開があります。 3comはそれらの企業ネットワークでOSPFを配布し始めました。 彼らは、OSPF(3com実装)を実行するそれらの8つのルータを持って、残っているルータ(全部で20)をカットオーバーするのを計画しています。 現在の、彼らには、同時にOSPFとRIPを実行する2つの操作上のルータがあります。 1は、OSPFデータをRIPデータに変換して、他のRIPデータをOSPFデータに変換します。 その他の詳細に関しては、ディーノ・ファリナッチ[恐竜]に連絡してください。
6.1 NSI
6.1 NSI
The NASA Science Internet (NSI) is a multiprotocol network, currently supporting both DECnet and TCP/IP protocols. NSI's mission is to provide reliable high-speed communications to the NASA science community. The NASA Science Internet connects with other national networks including the National Science Foundation's NSFNET, the Department of Energy's ESnet and the Department of Defense's MILNET. NSI also has international connections to Japan, Australia, New Zealand, Chile and several European countries.
現在DECnetとTCP/IPの両方にプロトコルをサポートして、NASA Scienceインターネット(NSI)は「マルチ-プロトコル」ネットワークです。 NSIの任務はNASA科学共同体に信頼できる高速通信を提供することになっています。 NASA Scienceインターネットは国立科学財団のNSFNET、エネルギー省のESnet、および国防総省のMILNETを含んでいる他の全国的なネットワークに接続します。 また、日本、オーストラリア、ニュージーランド、チリ、およびいくつかの欧州諸国にはNSIが国際的な接続がいます。
For more information on NSI, contact Jeffrey Burgan [jeff] or Milo Medin [medin].
NSIの詳しい情報に関しては、ジェフリー・ブルガン[jeff]かミロ・メディン[medin]に接触してください。
6.1.1 NSI's OSPF system
6.1.1 NSIのOSPFシステム
NSI was one of the initial deployment sites for OSPF Version 1, having deployed the protocol in April 1990. NSI has been running OSPF V2 since 1/1/91. They currently have 15 routers in their OSPF system. This system is pictured in Figure 1. It consists of a nationwide collection of serial lines, with ethernets at hub sites. The numbers associated to interfaces/links in Figure1 are the associated OSPF costs. Note that certain links have been weighted so that they are less preferable than others.
1990年4月にプロトコルを配布したので、NSIはOSPFバージョン1のための初期の展開サイトの1つでした。 1/1/91以来NSIは実行しているOSPF V2です。 彼らには、現在、それらのOSPFシステムの15のルータがあります。 このシステムは図1に描写されます。 それはイーサネットがハブサイトにあるシリアル・ラインの全国的な収集から成ります。 Figure1のインタフェース/リンクに関連づけられた数は関連OSPFコストです。 それらが他のものほど望ましくないように、あるリンクが重みを加えられたことに注意してください。
Many of NSI's OSPF routers are speaking either RIP and/or EGP as well as OSPF. Routes from these other routing protocols are selectively imported
NSIのOSPFルータの多くがOSPFと同様にRIP、そして/または、EGPを話しています。 これらの他のルーティング・プロトコルからのルートは選択的にインポートされます。
[Moy] [Page 7] RFC 1246 Experience with OSPF July 1991
[Moy] RFC1246が1991年7月にOSPFと共に経験する[7ページ]
into their OSPF system as externals. The current number of imported externals is 496.
外観としてのそれらのOSPFシステムに。 インポートしている外観の最新号は496です。
All NSI externals are imported as OSPF type 2 metrics. In addition, NSI uses the OSPF external route tag to manage the readvertisement of external routes. For example, a route learned at one edge of the NSI system via EGP can be tagged with the number of the AS from which it was learned. Then, as the OSPF external LSA describing this route is flooded through the OSPF system, this tagging information is distributed to all the other AS boundary routers. A router on the other edge of the NSI can then say that it wants to readvertise (via EGP) routes learned from one particular AS but not routes learned from another AS. This allows NSI to implement transit policies at the granularity of Autonomous Systems, instead of network numbers, which greatly reduces the network's configuration burden.
OSPFが2つの測定基準をタイプするとき、すべてのNSI外観がインポートされます。 さらに、NSIは、外部経路の再広告を管理するのにOSPF外部経路タグを使用します。 例えば、それが学習されたASの数でEGPを通してNSIシステムの1つの縁で学習されたルートにタグ付けをすることができます。 そして、このルートを説明するOSPFの外部のLSAがOSPFシステムを通してあふれるとき、このタグ付け情報は他のすべてのAS境界ルータに分配されます。 そして、NSIのもう片方の縁のルータは、別のASから学習されたルートではなく、1特定のASから学習されたルートの「再-広告を出」したがっている(EGPを通して)と言うことができます。 これで、NSIは、ネットワーク・ナンバーの代わりにネットワークの構成負担を大いに減少させるAutonomous Systemsの粒状でトランジットが方針であると実装することができます。
NSI has also experimented with OSPF stub areas, in order to support routers having a small amount of memory.
また、NSIは、少量の記憶力を持っているルータをサポートするためにOSPFスタッブ領域を実験しました。
6.1.2 NSI - Deployment analysis
6.1.2 NSI--展開分析
NSI ran a couple of experiments after OSPF's deployment to test OSPF's convergence time in the face of network failures, and to compare the level of routing traffic in OSPF with the level of routing traffic in RIP. These experiments were included in NSI status reports to the OSPF plenary.
NSIは、OSPFの展開の後にネットワーク失敗に直面してOSPFの集合時間をテストして、OSPFのルーティングトラフィックのレベルをRIPのルーティングトラフィックのレベルにたとえるために2、3の実験を走らせました。 これらの実験はOSPFに絶対的なNSI現状報告に含まれていました。
The first experiment consisted of running a continuous ICMP ping, and then bringing down one of the links in the ping packet's path. They then timed how long it took OSPF to find an alternate path, by noticing when the pings resumed. The result of this experiment is contained in Milo Medin's "NASA Sciences Internet Report" in [8]. It shows that the interrupted ping resumed in three seconds.
最初の実験はピングパケットの経路に連続したICMPピングを実行して、次に、リンクの1つを降ろすのから成りました。 そして、彼らは、ピングがいつ再開したかに気付くことによって代替パスを見つけるのにどれくらい長い間OSPFを要したように調節しました。 この実験の結果は[8]にミロ・メディンの「NASAの科学インターネットレポート」に含まれています。 それは、中断しているピングが3秒で再開したのを示します。
The second experiment consisted in analyzing the amount of routing protocol traffic that flow over an NSI link. One of the NSI links was installed, but did not have any active users yet. For this reason, all traffic that flowed over the link was routing protocol traffic. The link was instrumented to continuously measure the amount of bandwidth consumed, first in the case where RIP was running, and then in the case of where OSPF was running. The result is shown graphically in Jeffrey Burgan's "NASA Sciences Internet" report in [9]. It shows that OSPF consumes many times less network bandwidth than RIP.
2番目の実験は、NSIリンクの上に流れるルーティング・プロトコルトラフィックの量を分析しながら、存しました。 NSIリンクの1つには、インストールされましたが、どんな活発なユーザもまだいませんでした。 この理由で、リンクの上に流れたすべてのトラフィックがルーティング・プロトコルトラフィックでした。 リンクは、絶え間なく最初にRIPが稼働する予定であった場合、およびそして、OSPFが稼働する予定であったところに関する場合で消費された帯域幅の量を測定するために器具を取り付けられました。 結果は[9]での「NASA科学インターネット」というジェフリー・ブルガンのレポートにグラフィカルに示されます。 それは、OSPFがRIPより多くの倍少ないネットワーク回線容量を消費するのを示します。
[Moy] [Page 8] RFC 1246 Experience with OSPF July 1991
[Moy] RFC1246が1991年7月にOSPFと共に経験する[8ページ]
6.2 BARRNet
6.2 BARRNet
BARRNet is the NSFNet regional network in Northern California. At the present time, it serves approximately 80 member sites in an area stretching from Sacramento in the north-east to Monterey in the in the south-west. Sites are connected to the network at speeds from 9.6Kbps to full T1 using Proteon and cisco routers as well as a Xylogics terminal server. The membership is composed of a mix of university, government, and commercial organizations. BARRNet has interconnections to the NSFNet (peering with both T1 and T3 backbones at Stanford University), ESNet (peering at LLNL, with additional multi-homed sites at LBL, SLAC, and NASA Ames), and DDN national networks (peering at the FIX network at NASA Ames), and to the statewide networks of the University of California (peering at U.C. Berkeley) and the California State University system (peering at San Francisco State and Sacramento State).
BARRNetは北カリフォルニアのNSFNet地域ネットワークです。 現在では、それは東北におけるサクラメントからモントレーまでの領域ストレッチングにおけるおよそ80のメンバーサイトにコネにおける南西に役立ちます。 サイトは、速度でXylogicsターミナルサーバと同様にProteonとコクチマスルータを使用することで9.6Kbpsから完全なT1までネットワークにつなげられます。会員資格は大学、政府、および営利団体のミックスで構成されます。 BARRNetはNSFNet(T1とT3バックボーンの両方がスタンフォード大学にある状態で、じっと見る)にインタコネクトを持っています、ESNet、(追加することでLLNLをじっと見る、マルチ、家へ帰り、LBL、SLAC、およびNASAのエームズのサイト)、DDN同胞は、(NASAのエームズのFIXネットワークのじっと見ること)をネットワークでつないで、カリフォルニア大学の州全体のネットワークにそうします。(U.C.バークレーをじっと見ます。) そして、カリフォルニア州立大学システム(サンフランシスコ州とサクラメント州をじっと見ます)。
Topologically, the network consists of fourteen OSPF-speaking Proteon routers, which as a "core", with six of these redundantly connected into a ring. All "core" sites are interconnected via full T1 circuits. Other member sites attach as "stub" connections to the "core" sites. The bulk of these are connected in a "star" configuration at Stanford University, with lesser numbers at other "core" sites.
位相的に、ネットワークは14のOSPF-話しProteonルータから成ります。(これらの6がある「コア」として、ルータは冗長にリングに接続しました)。 すべての「コア」サイトが完全なT1回路を通してインタコネクトされます。 他のメンバーサイトは「スタッブ」接続として「コア」サイトに付きます。 これらの嵩はスタンフォード大学で「星」構成で他の「コア」サイトの、より少ない数に関連づけられます。
Contact Vince Fuller [vaf] for more information on BARRNet.
BARRNetに関する詳しい情報のために、ビンス・フラー[vaf]に連絡してください。
6.2.1 BARRNet's OSPF system
6.2.1 BARRNetのOSPFシステム
BARRNet was also one of the initial deployment sites for OSPF Version 1, having deployed the protocol in April 1990. BARRNet has been running OSPF V2 since November 1990. They currently have 14 routers in their OSPF system. The BARRNet OSPF system is pictured in Figure 2. It consists of a collection of T1 serial lines, with ethernets at hub sites.
また、1990年4月にプロトコルを配布したので、BARRNetはOSPFバージョン1のための初期の展開サイトの1つでした。 1990年11月以来BARRNetは実行しているOSPF V2です。 彼らには、現在、それらのOSPFシステムの14のルータがあります。 BARRNet OSPFシステムは図2に描写されます。 それはイーサネットがハブサイトにあるT1シリアル・ラインの収集から成ります。
Most of BARRNet's OSPF routers are speaking either RIP and/or EGP as well as OSPF. Routes from these other routing protocols are selectively imported into their OSPF system as externals. A large number of external routes are imported; the current number is1816. The bulk of these are the T1 NSFNet routes, followed by several hundred NSN routes, around 60-80 BARRNet routes from the non-OSPF system, and several dozen from ESNet.
BARRNetのOSPFルータの大部分はOSPFと同様にRIP、そして/または、EGPを話しています。 これらの他のルーティング・プロトコルからのルートは外観として選択的にそれらのOSPFシステムにインポートされます。 多くの外部経路がインポートされます。 最新号is1816。 数個がESNetからこれらの嵩は非OSPFシステムからの60-80 BARRNetルートの周りの数100のNSNルートがいうことになったT1 NSFNetルートであり、ダース離れたところにあります。
All external routes are imported into the BARRNet system as external type 1 metrics. In addition, BARRnet, like NSI, uses the OSPF's external route tagging feature to help manage the readvertisement of external routes via EGP.
すべての外部経路が外部のタイプ1測定基準としてBARRNetシステムにインポートされます。 さらに、NSIのように、BARRnetはEGPを通して外部経路の再広告を管理するのを助けるOSPFの外部経路タグ付け機能を使用します。
[Moy] [Page 9] RFC 1246 Experience with OSPF July 1991
[Moy] RFC1246が1991年7月にOSPFと共に経験する[9ページ]
BARRnet is also using four stub OSPF areas in order to collapse subnet information. These stub areas all consist of a single LAN. They do not contain any OSPF routers in their interiors.
また、BARRnetは、サブネット情報を潰すのに4つのスタッブOSPF領域を使用しています。 これらのスタッブ領域は単一のLANからすべて成ります。 それらは内部にどんなOSPFルータも含んでいません。
6.2.2 BARRNet - Deployment analysis
6.2.2 BARRNet--展開分析
Initial deployment of OSPF Version 1 in BARRNet pointed to the need for two new protocol features that were added to OSPF V2, namely:
すなわち、OSPF V2に加えられた2つの新しいプロトコル機能の必要性に指されたBARRNetでのOSPFバージョン1の初期の展開、:
o Addition of the forwarding address to OSPF external LSAs. This eliminated the extra hops that were being taken in BARRNet when only routers BR5 and BR6 were exchanging EGP information with the NSS (see Figure 2). Without the forwarding address feature, that meant that NSFNet traffic handled by routers BR10, BR16 and BR28 was taking an extra hop to get to the NSS.
o OSPFの外部のLSAsへのフォーワーディング・アドレスの追加。 これはルータだけのBR5とBR6がEGP情報をNSSと交換していたとき(図2を見てください)BARRNetで取られていた付加的なホップを排除しました。 フォーワーディング・アドレス機能がなければ、それは、ルータのBR10、BR16、およびBR28によって扱われたNSFNetトラフィックがNSSを始めるために付加的なホップを取っていたことを意味しました。
o Addition of stub areas. This was an attempt to get OSPF running on some of the BARRNet routers that had insufficient memory to deal with all of BARRNet's external routes.
o スタッブ領域の追加。 これはOSPFにBARRNetの外部経路のすべてに対処するために不十分な記憶力を持っていたBARRNetルータのいくつかで動かせる試みでした。
6.3 OARnet
6.3 OARnet
OARnet, the Ohio Academic Resources Network, is the regional network for the state of Ohio. It serves the entire higher education community, providing Ohio schools access to colleagues worldwide. The Ohio Supercomputer Center and the NSF Supercomputer Centers are reached through OARnet. Libraries, databases, national and international laboratories and research centers are accessible to faculty, helping make Ohio schools competitive.
OARnet、オハイオAcademic Resources Networkはオハイオ州への地域ネットワークです。 世界中で同僚へのアクセスをオハイオ学校に提供して、それは全体の高等教育共同体に役立ちます。 オハイオのSupercomputerセンターとNSF SupercomputerセンターズはOARnetを通して連絡されています。 教授陣にとって、オハイオ学校を競争力があるようにするのを助けて、図書館、データベース、国家的、そして、国際的な実験室、およびリサーチセンターはアクセス可能です。
OARnet was established in 1987 to provide state-wide access to the CRAY at the Ohio Supercomputer Center in Columbus, Ohio. Since then it has evolved into a network supporting all aspects of higher education within Ohio. A primary goal of OARnet is to facilitate collaborative projects and sharing of resources between institutions, including those outside the state. OARnet connections are available to Ohio academic institutions and corporations engaged in research, product development, or instruction. Colleges, universities, and industries currently use OARnet connections to communicate within the state and with colleagues around the country.
OARnetは、1987年にコロンブス(オハイオ)のオハイオのSupercomputerセンターのクレイへの州全体のアクセスを提供するために設立されました。 それ以来、それはオハイオの中で高等教育の全面をサポートするネットワークに発展しています。 OARnetのプライマリ目標は団体の間の共同プロジェクトとリソースの共有を容易にすることです、州外であるそれらを含んでいて。 OARnet接続はオハイオのアカデミックな団体と研究に従事している会社か、商品開発か、指示に手があいています。 大学、大学、および産業は、現在、州以内で同僚が国中で交信するのにOARnet接続を使用します。
OARnet uses the Internet (TCP/IP) and DECNET protocols. OARnet participants using TP/IP protocols are connected to the worldwide Internet, which includes all the major networks open to non-classified research. OARnet is also connected to NSFNet, the national research and
OARnetはインターネット(TCP/IP)とDECNETプロトコルを使用します。 TP/IPプロトコルを使用しているOARnet関係者が世界的なインターネットに接続されます。(それは、非機密研究に開かれているすべての主要なネットワークを含んでいます)。 そしてまた、OARnetがNSFNet、国家の研究に接続される。
[Moy] [Page 10] RFC 1246 Experience with OSPF July 1991
[Moy] RFC1246が1991年7月にOSPFと共に経験する[10ページ]
education network sponsored by the National Science Foundation. It has gateways to BITNET, CSNET, CICNet (a network connecting the Big Ten universities), and the NASA Science Internet.
国立科学財団によって後援された教育ネットワーク。 それはBitnet、CSNET、CICNet(ビッグ10大学を接続するネットワーク)、およびNASA Scienceインターネットにゲートウェイを持っています。
For more information on OARnet, contact Kannan Varadhan [kannan].
OARnetの詳しい情報に関しては、Kannan Varadhan[kannan]に連絡してください。
6.3.1 OARnet's OSPF system
6.3.1 OARnetのOSPFシステム
OARnet has been running OSPF Version 1 since October 15, 1990. They currently have 14 routers in their OSPF system. The OARnet OSPF system is pictured in Figure 3.
OARnetは1990年10月15日以来のOSPFバージョン1を実行しています。 彼らには、現在、それらのOSPFシステムの14のルータがあります。 OARnet OSPFシステムは図3に描写されます。
There are 29 sites connected directly to the OARnet backbone. All 13 of OARnet's OSPF routers act as ASBRs. There are 40 OSPF internal routes on OARnet's network, and they import about 120 routes from RIP. OARnet runs EGP on the DMZnet at Columbus, which connects them to CICNet. The router connecting OARnet to DMZnet (OAR1 in Figure 3) runs EGP on the DMZnet side, and OSPF and RIP on the OARnet backbone. No EGP routes are imported into the OSPF system. The OAR1 router is configured to generate a default when EGP routes are available. The OAR1 router is the keystone for routing on OARnet's network, in that it acts as an intermediary for all of OARnet's RIP centric routers.
直接OARnetバックボーンにつなげられた29のサイトがあります。 OARnetのすべての13のOSPFルータがASBRsとして機能します。 40のOSPFの内部のルートがOARnetのネットワークにあります、そして、それらはRIPからおよそ120のルートをインポートします。 OARnetはコロンブスでEGPをDMZnetに実行します。(コロンブスは、それらをCICNetに接続します)。 DMZnet(図3のOAR1)にOARnetを接続するルータは、DMZnet側でEGPを稼働させていて、OARnetバックボーンでOSPFとRIPを稼働させています。 EGPルートは全くOSPFシステムにインポートされません。 OAR1ルータは、EGPルートが利用可能であるときに、デフォルトを生成するために構成されます。 OAR1ルータはOARnetのネットワークでのルーティングのためのかなめ石です、OARnetのRIPの中心のルータのすべてのための仲介者として機能するので。
OARnet uses the Event Logging System on its Proteon routers to generate traps for "interesting" events related to routing. They have these traps sent to an SNMP management station, where the logs are collected for later perusal.
OARnetは、ルーティングに関連する「おもしろい」イベントのために罠を生成するのにProteonルータでEvent Logging Systemを使用します。 彼らはSNMP管理ステーションにこれらの罠を送らせます。(そこでは、ログが後の熟読のために集められます)。
6.3.2 OARnet - Deployment analysis
6.3.2 OARnet--展開分析
OARnet is monitoring their OSPF system via collection of traps on their SNMP management station. The following is a report on their observations. It has been edited slightly to conform better with the other text and maps presented in this report. For more information, contact Kannan Varadhan [kannan]:
OARnetはそれらのSNMP管理局における罠の収集でそれらのOSPFシステムをモニターしています。 ↓これは彼らの観測に関するレポートです。 それは、より一層このレポートに提示された他のテキストと地図に従うためにわずかに編集されました。 詳しくは、Kannan Varadhan[kannan]は連絡します:
3 of our 10 DS1 circuits are on digital microwave, and these tend to flap occasionally. Our observations indicate that the routers bring up links, and adjacencies, on average, in about 2 seconds. Routes fallback to alternate backup paths instantly. Whole blocks of routes cut over the instant the adjacencies are formed.
デジタル電子レンジの上に私たちの10個のDS1サーキットのうち3があります、そして、これらは時折ばたつく傾向があります。 私たちの観測は、ルータがおよそ2秒以降リンク、および隣接番組を平均的に持って来るのを示します。 即座にバックアップ道を交替するために後退を発送します。 全体のブロックのルートは隣接番組が形成される瞬間をカットオーバーします。
In contrast to this, our RIP routes would take about 3-6 minutes to cutover, and, on occasion, would not cut back to the preferred paths. This was our prime motivation in switching to OSPF.
これと対照して、私たちのRIPルートは、カットオーバにおよそ3-6分かかって、時々、都合のよい経路に切り換え返さないでしょう。 これはOSPFに切り替わることにおいて私たちの主要な動機でした。
[Moy] [Page 11] RFC 1246 Experience with OSPF July 1991
[Moy] RFC1246が1991年7月にOSPFと共に経験する[11ページ]
We attempted to duplicate Milo Medin's ping test to dramatically illustrate the performance of RIP over OSPF. To do this, we selected a host on the farthest point from our workstation, and ran a continuous ping to it. We would then bring down a primary DS1 circuit, and watch the time it took to switch to the fallback route. Following this, we would bring the circuit back up, and study the time it took to re-sync to the new path. With RIP, we were unable to fully complete the experiment, because the farthest point was exactly equal to the new (and preferred) primary path, and therefore, RIP would never choose it on it's own, until the path it was currently using failed. With OSPF, it took about 2 seconds to synchronize over a new, much slower 56kb path, and less than a second when the DS1 circuit came back up.
私たちは、OSPFの上でRIPの性能を劇的に例証するためにミロ・メディンのピングテストをコピーするのを試みました。 私たちは、これをするために、最も遠いポイントの上で私たちのワークステーションからホストを選んで、連続したピングをそれへ走らせました。 私たちは、次に、一次DS1サーキットを降ろして、わざわざそれが後退ルートに切り換えた見るでしょう。 これに続いて、それが新しい経路への再の同時性に始めたとき、私たちは、サーキットを持って来て戻して、研究するでしょう。 RIPには、私たちは実験を完全に終了できませんでした、最も遠いポイントがまさに新しくて(都合のよい)の第一の経路と等しかったです、そして、したがって、RIPはそれのものの上で失敗されて、それが現在使用していた経路まで自己でそれを決して選びません。 OSPFと共に、新しくて、はるかに遅い56kb経路、およびDS1サーキットが来て戻った1秒未満間、連動するにはおよそ2秒かかりました。
Here are some more observations of the OARnet OSPF system's behavior:
ここに、OARnet OSPFシステムの振舞いのそれ以上の観察があります:
o 131.187.36.0 is the 56kb line to Kent State University. Kent also has a DS1 circuit leading into ASP, the Akron Pop. Likewise, UAkron.edu has a similar configuration. A roundabout backup path exists when traffic heads up to Cleveland over a couple of DS1 circuits, and then down a 56kb backup path used by another school in the Cleveland area.
o 131.187.36.0 ケントステート大学には56kb線がありますか? また、ケントはDS1サーキットをASP、アクロンPopに導かせます。 同様に、UAkron.eduには、同様の構成があります。 交通有利なスタートであるときに、回りくどいバックアップ道は2、3のDS1サーキットの上とそして、クリーブランド領域の別の学校によって使用された56kbバックアップ道の下側へのクリーブランドに存在しています。
Some statistical information:
何らかの統計情報:
1. 09:55:17: SPF.37: new route to Net 131.187.36.5,
type SPF cost 32
2. 09:55:18: SPF.37: new route to Net 131.187.36.6,
type SPF cost 22
3. 09:55:20: SPF.21: State Change, nbr 131.187.27.6,
new state <Full>, event 9
4. 09:55:21: SPF.37: new route to Net 131.187.36.5,
type SPF cost 31
5. 09:55:22: SPF.37: new route to Net 131.187.36.6,
type SPF cost 21
6. 09:55:28: SPF.21: State Change, nbr 131.187.21.5,
new state <Full>, event 9
7. 09:55:29: SPF.21: State Change, nbr 131.187.51.6,
new state <Full>, event 9
8. 09:55:31: SPF.37: new route to Net 131.187.36.5,
type SPF cost 22
9. 09:55:33: SPF.37: new route to Net 131.187.36.5,
type SPF cost 11
1. 09:55:17: SPF.37: 新しく、.5、タイプSPF費用32 2をネット131.187.36に発送してください。 09:55:18: SPF.37: 新しく、.6、タイプSPF費用22 3をネット131.187.36に発送してください。 09:55:20: SPF.21: Change、nbr131.187を述べてください。.27 .6、新しい州の<Full>、出来事9 4。 09:55:21: SPF.37: 新しく、.5、タイプSPF費用31 5をネット131.187.36に発送してください。 09:55:22: SPF.37: 新しく、.6、タイプSPF費用21 6をネット131.187.36に発送してください。 09:55:28: SPF.21: Change、nbr131.187を述べてください。.21 .5、新しい州の<Full>、出来事9 7。 09:55:29: SPF.21: Change、nbr131.187を述べてください。.51 .6、新しい州の<Full>、出来事9 8。 09:55:31: SPF.37: 新しく、.5、タイプSPF費用22 9をネット131.187.36に発送してください。 09:55:33: SPF.37: 新しく、.5、タイプSPF費用11をネット131.187.36に発送してください。
The Akron router restarts, and has to re-sync with all the lines. This restart is confirmed when one looks at the traps from gwCSP1. Traps from gwASP1 still do not get through to us, because traps are
アクロンルータは、再開して、すべての線で再同期しなければなりません。 人がgwCSP1から罠を見ると、この再開は確認されます。 罠が通じるので、gwASP1からの罠はまだ私たちに通じていません。
[Moy] [Page 12] RFC 1246 Experience with OSPF July 1991
[Moy] RFC1246が1991年7月にOSPFと共に経験する[12ページ]
sent via UDP, and gwASP1's routing tables are not fully configured yet.
UDP、およびgwASP1のルーティングで送って、テーブルは完全にまだ構成されるというわけではありません。
Events 1 and 2 are route changes routing traffic via Cleveland, across 2 DS1 circuits and a 56kb line.
出来事1と2は2個のDS1サーキットと56kb線の向こう側のクリーブランドを通して交通を発送するルート変化です。
When the DS1 circuit to UAkron came up, routes instantly cut over to use this as a better least cost path. This is shown in events 3, 4 and 5.
UAkronへのDS1サーキットが来たとき、ルートは、より良い最小費用経路として即座に使用にこれをカットオーバーします。 これは出来事3、4、および5で示されます。
In a few seconds, the line to Columbus is the next one up. This is event 6. Event 8 relates to this cutover, and is the best path yet. When the DS1 circuit to Kent is up, the link is used instantly.
数秒たって、コロンブスへの線は上に次のものです。 これは出来事6です。 出来事8は、このカットオーバに関連して、今まで最も良い経路です。 ケントへのDS1サーキットが上がっているとき、リンクは即座に使用されます。
We are able to make such a definitive conclusion of these traps on the basis of the topological information that we have about the network and the means used to monitor them.
私たちは私たちがネットワークに関して持っている位相的な情報とそれらをモニターするのに使用される手段に基づいてこれらの罠のそのような決定的な結論をすることができます。
o To illustrate the time required to fully synchronize a database, we piece together a few adjacency forming traces...
o データベースを完全に同期させるのに必要である時間を例証するために、私たちはいくつかの隣接番組形成跡に継ぎを当てます…
Please bear in mind that these time stamps are the time stamps on the management station, and are not to be taken as the absolute truth. Things we haven't taken into account are transit times of messages, ordering of events (SNMP traps are sent using UDP), loss of event reports (recall that an entire synchronization sequence of gwASP1 on the ASP-CSP link is missing), etc.
これらのタイムスタンプが管理局の上のタイムスタンプであることを覚えておいてください、そして、絶対の真理として取ってはいけなくなってください。 私たちが考慮に入れていないものはメッセージのトランジット倍です、出来事(SNMP罠にUDPを使用させる)、イベントレポート(ASP-CSPリンクの上のgwASP1の全体の同期系列がなくなると思い出す)の損失などを注文して
The trace below corresponds to the Akron router, gwASP1 bring up the link in the previous section. This is as observed on the other end of the line, gwCSP1.
下の跡はアクロンルータに対応している、gwASP1は前項でリンクを持って来ます。 gwCSP1、これは電話の向こう側で観測されるようにあります。
REPORT DATE: 02/26/91 ROUTER: gwcsp1
09:55:06: SPF.15: State Change, ifc 131.187.22.6,
new state <Point-To-Point>, event 1
09:55:06: GW.xxx: Link Up Trap: 09:55:07: SPF.37:
new route to Net 131.187.22.5, type SPF cost 1
09:55:07: SPF.21: State Change, nbr 131.187.22.5,
new state <Init>, event 1
09:55:09: SPF.37: new route to Net 131.187.27.5,
type SPF cost 22
09:55:11: SPF.21: State Change, nbr 131.187.22.5,
new state <ExStart>, event 14
09:55:11: SPF.21: State Change, nbr 131.187.22.5,
new state <2-Way>, event 3
09:55:12: SPF.21: State Change, nbr 131.187.22.5,
new state <Exchange>, event 5
レポート日付: 02/26/91のルータ: gwcsp1 09:55:06: SPF.15: Change、ifcを述べてください、131.187、.22、.6、新しい州の<Pointからポイントへの>、出来事、1、09:55:06、: GW.xxx: 罠をリンクしてください: 09:55:07: SPF.37: 新しさ、.5、タイプSPF費用1 09:55:07をネット131.187.22に発送してください: SPF.21: Change、nbrを述べてください、131.187、.22、.5、新しい州の<Init>、出来事、1、09:55:09、: SPF.37: 新しさ、.5、タイプSPF費用22 09:55:11をネット131.187.27に発送してください: SPF.21: Change、nbrを述べてください、131.187、.22、.5、新しい州の<ExStart>、出来事14 09:55:11: SPF.21: Change、nbrを述べてください、131.187、.22、.5、新しい州の<の2方法の>、出来事、3、09:55:12、: SPF.21: Change、nbr131.187.22を述べてください、.5、新しい州の<Exchange>、出来事5
[Moy] [Page 13] RFC 1246 Experience with OSPF July 1991
[Moy] RFC1246が1991年7月にOSPFと共に経験する[13ページ]
09:55:12: SPF.21: State Change, nbr 131.187.22.5,
new state <Full>, event 9
09:55:12: SPF.21: State Change, nbr 131.187.22.5,
new state <Loading>, event 6
09:55:12: SPF.21: Change、nbrを述べてください、131.187、.22、.5、新しい州の<Full>、出来事、9、09:55:12、: SPF.21: Change、nbr131.187.22を述べてください、.5、新しい州の<Loading>、出来事6
Below, is another trace of the same router restart sequence, where the router is proceeding to bring up other DS1 circuits. Bringing up the first adjacency took about 5 seconds. Subsequent adjacencies take the router less than a second as seen below.
以下に、ルータが他のDS1サーキットを持って来かけるのと同じルータ再開系列が別の跡がありますか? 最初の隣接番組を持って来るのはおよそ5秒取りました。 以下が見られるようにその後の隣接番組は1秒未満のルータを取ります。
REPORT DATE: 02/26/91 ROUTER: gwasp1
09:55:20: SPF.15: State Change, ifc 131.187.27.5,
new state <Point-To-Point>, event 1
09:55:20: GW.xxx: Link Up Trap: 09:55:20: SPF.21:
State Change, nbr 131.187.27.6, new state <Init>, event 1
09:55:20: SPF.21: State Change, nbr 131.187.27.6,
new state <ExStart>, event 14
09:55:20: SPF.21: State Change, nbr 131.187.27.6,
new state <Exchange>, event 5
09:55:20: SPF.21: State Change, nbr 131.187.27.6,
new state <Full>, event 9
09:55:21: SPF.21: State Change, nbr 131.187.27.6,
new state <Loading>, event 6
09:55:24: SPF.21: State Change, nbr 131.187.51.6,
new state <Init>, event 1
09:55:24: SPF.21: State Change, nbr 131.187.21.5,
new state <Init>, event 1
09:55:25: SPF.37: new route to Net 131.187.21.6, type SPF cost 13
09:55:25: SPF.37: new route to Net 131.187.51.5, type SPF cost 22
09:55:28: SPF.21: State Change, nbr 131.187.21.5,
new state <ExStart>, event 14
09:55:28: SPF.21: State Change, nbr 131.187.21.5,
new state <2-Way>, event 3
09:55:28: SPF.21: State Change, nbr 131.187.21.5,
new state <Exchange>, event 5
09:55:28: SPF.21: State Change, nbr 131.187.21.5,
new state <Full>, event 9
09:55:28: SPF.21: State Change, nbr 131.187.21.5,
new state <Loading>, event 6
09:55:29: SPF.37: new route to Net 131.187.51.6, type SPF cost 1
09:55:29: SPF.37: new route to Net 131.187.21.5, type SPF cost 1
09:55:29: SPF.21: State Change, nbr 131.187.51.6,
new state <Exchange>, event 5
09:55:29: SPF.21: State Change, nbr 131.187.51.6,
new state <ExStart>, event 14
09:55:29: SPF.21: State Change, nbr 131.187.51.6,
new state <2-Way>, event 3
09:55:29: SPF.21: State Change, nbr 131.187.51.6,
レポート日付: 02/26/91のルータ: gwasp1 09:55:20: SPF.15: Change、ifcを述べてください、131.187、.27、.5、新しい州の<Pointからポイントへの>、出来事、1、09:55:20、: GW.xxx: 罠をリンクしてください: 09:55:20: SPF.21: Change、nbrを述べてください、131.187、.27、.6、新しい州の<Init>、出来事、1、09:55:20、: SPF.21: Change、nbrを述べてください、131.187、.27、.6、新しい州の<ExStart>、出来事14 09:55:20: SPF.21: Change、nbrを述べてください、131.187、.27、.6、新しい州の<Exchange>、出来事、5、09:55:20、: SPF.21: Change、nbrを述べてください、131.187、.27、.6、新しい州の<Full>、出来事、9、09:55:21、: SPF.21: Change、nbrを述べてください、131.187、.27、.6、新しい州の<Loading>、出来事、6、09:55:24、: SPF.21: Change、nbrを述べてください、131.187、.51、.6、新しい州の<Init>、出来事、1、09:55:24、: SPF.21: Change、nbrを述べてください、131.187、.21、.5、新しい州の<Init>、出来事、1、09:55:25、: SPF.37: 新しさ、.6、タイプSPF費用13 09:55:25をネット131.187.21に発送してください: SPF.37: 新しさ、.5、タイプSPF費用22 09:55:28をネット131.187.51に発送してください: SPF.21: Change、nbrを述べてください、131.187、.21、.5、新しい州の<ExStart>、出来事14 09:55:28: SPF.21: Change、nbrを述べてください、131.187、.21、.5、新しい州の<の2方法の>、出来事、3、09:55:28、: SPF.21: Change、nbrを述べてください、131.187、.21、.5、新しい州の<Exchange>、出来事、5、09:55:28、: SPF.21: Change、nbrを述べてください、131.187、.21、.5、新しい州の<Full>、出来事、9、09:55:28、: SPF.21: Change、nbrを述べてください、131.187、.21、.5、新しい州の<Loading>、出来事、6、09:55:29、: SPF.37: 新しさ、.6、タイプSPF費用1 09:55:29をネット131.187.51に発送してください: SPF.37: 新しさ、.5、タイプSPF費用1 09:55:29をネット131.187.21に発送してください: SPF.21: Change、nbrを述べてください、131.187、.51、.6、新しい州の<Exchange>、出来事、5、09:55:29、: SPF.21: Change、nbrを述べてください、131.187、.51、.6、新しい州の<ExStart>、出来事14 09:55:29: SPF.21: Change、nbrを述べてください、131.187、.51、.6、新しい州の<の2方法の>、出来事、3、09:55:29、: SPF.21: Change、nbr131.187.51を述べてください、.6
[Moy] [Page 14] RFC 1246 Experience with OSPF July 1991
[Moy] RFC1246が1991年7月にOSPFと共に経験する[14ページ]
new state <Full>, event 9
09:55:29: SPF.21: State Change, nbr 131.187.51.6,
new state <Loading>, event 6
新しい州の<Full>、イベント9 09:55:29: SPF.21: Change、nbr131.187.51を述べてください、.6、新しい州の<Loading>、出来事6
A transient fault on a DS1 circuit, causes the line to flap. All routers quickly reroute around the flap, and the router itself takes about 2 seconds to bring up the adjacency once more.
A一時的である、ばたつくためにDS1サーキット、原因で線をとがめてください。 すべてのルータがフラップの周りですぐにコースを変更します、そして、ルータ自体は、もう一度隣接番組を持って来るためにおよそ2秒取ります。
REPORT DATE: 02/26/91 ROUTER: gwasp1
14:33:43: GW.xxx: Link Up Trap:
14:34:19: SPF.15: State Change, ifc 131.187.22.5,
new state <Down>, event 7
14:34:19: GW.xxx: Link Failure Trap:
14:34:19: SPF.47: Net 131.187.22.6 now unreachable
14:34:36: SPF.15: State Change, ifc 131.187.22.5,
new state <Point-To-Point>, event 1
14:34:36: GW.xxx: Link Up Trap:
14:34:37: SPF.37: new route to Net 131.187.22.6, type SPF cost 1
14:34:45: SPF.21: State Change, nbr 131.187.22.6,
new state <2-Way>, event 3
14:34:45: SPF.21: State Change, nbr 131.187.22.6,
new state <Init>, event 1
14:34:46: SPF.21: State Change, nbr 131.187.22.6,
new state <ExStart>, event 14
14:34:46: SPF.21: State Change, nbr 131.187.22.6,
new state <Exchange>, event 5
14:34:47: SPF.21: State Change, nbr 131.187.22.6,
new state <Full>, event 9
14:34:47: SPF.21: State Change, nbr 131.187.22.6,
new state <Loading>, event 6
レポート日付: 02/26/91のルータ: gwasp1 14:33:43: GW.xxx: 罠をリンクしてください: 14:34:19: SPF.15: Change、ifcを述べてください、131.187、.22、.5、新しい州の<Down>、出来事、7、14:34:19、: GW.xxx: 失敗罠をリンクしてください: 14:34:19: SPF.47: ネット、131.187 .22 .6 現在手の届かない14: 34 : 36: SPF.15: Change、ifcを述べてください、131.187、.22、.5、新しい州の<Pointからポイントへの>、出来事、1、14:34:36、: GW.xxx: 罠をリンクしてください: 14:34:37: SPF.37: 新しさ、.6、タイプSPF費用1 14:34:45をネット131.187.22に発送してください: SPF.21: Change、nbrを述べてください、131.187、.22、.6、新しい州の<の2方法の>、出来事、3、14:34:45、: SPF.21: Change、nbrを述べてください、131.187、.22、.6、新しい州の<Init>、出来事、1、14:34:46、: SPF.21: Change、nbrを述べてください、131.187、.22、.6、新しい州の<ExStart>、出来事14 14:34:46: SPF.21: Change、nbrを述べてください、131.187、.22、.6、新しい州の<Exchange>、出来事、5、14:34:47、: SPF.21: Change、nbrを述べてください、131.187、.22、.6、新しい州の<Full>、出来事、9、14:34:47、: SPF.21: Change、nbr131.187.22を述べてください、.6、新しい州の<Loading>、出来事6
o On the amount of time it takes for a router to restart, and become fully synchronized. Taking the logs in the previous instance, we notice that the CSP-ASP link comes up at 9:55:06. The last link is observed to be up at 9:55:29, which is less than a minute.
o 時間に、それは、ルータが再開して、完全に連動するようになるにはかかります。 前の例におけるログを取って、私たちは、CSP-ASPリンクが9:55:06に来るのに気付きます。 最後のリンクは9:55:29に上がるのが観測されます。(29は1分未満です)。
o On the RIP equivalent of the tests, it took us 3 minutes to cutover to the slower speed fallback route, and we lost countless many packets. The routes never cutover to the higher speed paths when available, and we waited well over 30 minutes watching this, wondering why. Unfortu- nately, at this point, we seem to have lost the RIP statistics.
o テストで同等なRIPでは、私たちによるそれには、より遅い速度後退ルートへのカットオーバへの3分かかりました、そして、私たちは無数の状態で負けました。多くのパケット。 ルート、利用可能であるときに、より高いことへのカットオーバは経路を決して促進しません、そして、私たちははるかに30分間以上これを見ながら、待ちました、理由を不思議に思って。 Unfortu- nately、ここに、私たちはRIP統計を失ったように思えます。
On the OSPF version, we have...
OSPFバージョンに関して、私たちはそうしました…
{nisca danw 51}
ping 131.187.25.6 PING 131.187.25.6 (131.187.25.6):
nisca danw51が131.187.25.6PING131.187.25を確認する、.6、(131.187、.25、.6):
[Moy] [Page 15] RFC 1246 Experience with OSPF July 1991
[Moy] RFC1246が1991年7月にOSPFと共に経験する[15ページ]
56 data bytes 64 bytes from 131.187.25.6:
icmp seq=0 ttl(255-ttl)=54(201). time=20 ms
[...]
icmp seq=10 ttl(255-ttl)=54(201). time=20 ms
|| T1 down
icmp seq=14 ttl(255-ttl)=54(201). time=180 ms
icmp seq=15 ttl(255-ttl)=54(201). time=60 ms
[...]
icmp seq=38 ttl(255-ttl)=8(247). time=1300 ms
icmp seq=39 ttl(255-ttl)=54(201). time=820 ms
|| Tl Up
icmp seq=40 ttl(255-ttl)=54(201). time=20 ms
icmp seq=41 ttl(255-ttl)=54(201). time=20 ms
131.187.25.6 PING Statistics
51 packets transmitted, 48 packets received, 5% packet loss
round-trip (ms) min/avg/max = 20/277/1300
131.187から56データ・バイト64バイト、.25、.6: 20ms[…]時間=icmp seq=10 ttl(255-ttl)は54(201)と等しいです。icmp seq=0 ttl(255-ttl)=54(201)時間は20msと等しいです。|| icmp seq=14 ttl(255-ttl)の下側へのT1は54(201)と等しいです。180時間=ms icmp seq=15 ttl(255-ttl)は54(201)と等しいです。時間は60ms[…]icmp seq=38 ttl(255-ttl)=8(247)と等しいです。1300時間=ms icmp seq=39 ttl(255-ttl)は54(201)と等しいです。時間は820msと等しいです。|| Tl Up icmp seq=40 ttl(255-ttl)は54(201)と等しいです。20時間=ms icmp seq=41 ttl(255-ttl)は54(201)と等しいです。.6PING Statistics51のパケットが伝えた20ms131.187時間=.25、48のパケットが受信されました、5%のパケット損失の往復の(ms)分/avg/最大=20/277/1300
6.4 Features exercised during operational deployment
6.4の特徴が操作上の展開の間、運動しました。
In operational environments, all basic mechanisms of the OSPF protocol have been exercised. These mechanisms include:
運用環境では、OSPFプロトコルのすべての基本的機構が運動させられました。 これらのメカニズムは:
o Designated Router election. There have been operational deployments have as many as 8 OSPF routers attached to a single broadcast network.
o Router選挙に指定されます。 操作上の展開がありました。最大8つのOSPFルータをただ一つの放送網に付けさせてください。
o Database synchronization. This includes OSPF's adjacency bringup and reliable flooding procedures. Large operational OSPF link state databases (e.g., BARRNet) have provided a thorough test of these mechanisms.
o データベース同期。 これはOSPFの隣接番組bringupと信頼できる氾濫手順を含んでいます。 大きい操作上のOSPFリンク州のデータベース(例えば、BARRNet)はこれらのメカニズムの徹底的なテストを提供しました。
o Flushing advertisements. The procedure for flushing old or unreachable advertisements (the MaxAge procedure) has been tested operationally. It is interesting to note that flushing of advertisements does occur more during interoperability testing (because of the constant restart- ing of routers) that it does operationally. For example, in a week of BARRNet statistics, 9650 advertisements were flushed, while 688,278 new advertisements were flooded.
o 広告を洗い流します。 古いか手の届かない広告(MaxAge手順)を洗い流すための手順は操作上テストされました。 広告を洗い流すことがそれが操作上する相互運用性テスト(ルータの一定の再開ingによる)の間さらに起こることに注意するのはおもしろいです。 例えば、1週間のBARRNet統計では、9650の広告が洗い流されましたが、68万8278の新しい広告が水につかっていました。
o Import of external routes. All options of external LSAs have been tested operationally: type 1 metrics, type 2 metrics, forwarding addresses and the external route tag.
o 外部経路の輸入。 外部のLSAsのすべてのオプションが操作上テストされました: 1測定基準、タイプ2測定基準、フォーワーディング・アドレス、および外部経路タグをタイプしてください。
o Authentication. The OSPF authentication procedure has been tested operationally.
o 認証。 OSPF認証手順は操作上テストされました。
[Moy] [Page 16] RFC 1246 Experience with OSPF July 1991
[Moy] RFC1246が1991年7月にOSPFと共に経験する[16ページ]
o Equal-cost multipath. Operational deployments have included topologies with equal-cost, redundant paths.
o 等価コストマルチパス。 操作上の展開は等しい費用があるtopologies、冗長パスを含んでいました。
o Stub areas. These have been deployed both in BARRNet and NSI.
o 領域を引き抜いてください。 これらはBARRNetとNSIで配備されました。
6.5 Limitations of operational deployments
6.5 操作上の展開の制限
The following things have not been tested in an operational environment:
以下のものは運用環境でテストされていません:
o Multi-vendor deployments. So far all deployments have used a single implementation. However, extensive interoperability testing of OSPF has been done (see Section 7.0 of this report).
o マルチベンダ展開。 今までのところ、すべての展開がただ一つの実現を使用しました。 しかしながら、OSPFの大規模な相互運用性テストをしました(このレポートのセクション7.0を見てください)。
o Regular OSPF areas. These have however been tested in all three rounds of the OSPF interoperability testing.
o 通常のOSPF領域。 しかしながら、これらはOSPF相互運用性テストのすべての3ラウンドでテストされました。
o Virtual links. These have however been tested in OSPF's interoperability testing.
o 仮想のリンク。 しかしながら、これらはOSPFの相互運用性テストでテストされました。
o Non-broadcast networks. However, OSPF interoperability testing has been performed over X.25 networks.
o 非放送網です。 しかしながら、OSPF相互運用性テストはX.25ネットワークの上で実行されました。
o TOS routing. However, this has been tested in OSPF's interoperability testing.
o TOSルーティング。 しかしながら、これはOSPFの相互運用性テストでテストされました。
6.6 Conclusions
6.6 結論
All basic features of the OSPF protocol have been exercised. Very large OSPF link state databases (e.g., BARRNet's OSPF system) have been deployed, providing a thorough test of OSPF's database synchronization mechanisms. No OSPF protocol problems have been found in operational deployments.
OSPFプロトコルに関するすべての基本的特徴を運動させてあります。 非常に大きいOSPFリンク州のデータベース(例えば、BARRNetのOSPFシステム)は配備されました、OSPFのデータベース同期メカニズムの徹底的なテストを提供して。OSPFプロトコル問題は全く操作上の展開で見つけられていません。
Most of the hassles in operation deployments has to do with the OSPF/RIP interchange. Many of these issues have been ironed out on the ospf-tests mailing list (see Section 2.0). However, the interaction between OSPF, RIP, and EGP continues to be an active area of research.
操作展開における苦労の大部分はOSPF/RIP置き換えと関係があります。 これらの問題の多くがospf-テストメーリングリストで解決されました(セクション2.0を見てください)。 しかしながら、OSPFと、RIPと、EGPとの相互作用はずっと研究の活動領域です。
7.0 Interoperability Testing
7.0 相互運用性テスト
There have been three separate OSPF V2 interoperability testing sessions. Five separate implementations have participated in at least one session: implementations from the companies 3com, ACC, Proteon and Wellfleet, and the publicly available implementation from the University of Maryland.
3つの別々のOSPF V2相互運用性テストセッションがありました。 5つの別々の実現が少なくとも1つのセッションのときに参加しました: 会社の3com、ACC、Proteon、およびWellfleetからの実現、およびメリーランド大学からの公的に利用可能な実現。
[Moy] [Page 17] RFC 1246 Experience with OSPF July 1991
[Moy] RFC1246が1991年7月にOSPFと共に経験する[17ページ]
Each of the testing sessions is described in a succeeding section. For each session, the participants are identified, and the testing topologies are described along with the particular protocol features that were exercised. Any protocol problems that were encountered during the testing are also described. In addition, for the second and third rounds testing reports were sent to the ospf mailing lists. These reports are reproduced in this document.
それぞれのテストセッションは続くセクションで説明されます。 各セッションのために、関係者は特定されます、そして、テストしているtopologiesは運動させられた特定のプロトコル機能と共に説明されます。 また、テストの間に行きあたられたどんなプロトコル問題も説明されます。 さらに、2番目と3番目のラウンドにおいて、ospfメーリングリストに試験的報告書を送りました。 これらのレポートは本書では複製されます。
There is quite a bit of commonality in the features that have been tested from session to session. There are several reasons for this commonality. First, in each testing session an attempt has been made to increase the size of the OSPF system under test. For example, the number of external routes imported has doubled each session. Secondly, the interoperability sessions have been debugging sessions as well as protocol sessions. Many things tested in the third round were to ver- ify that implementations had successfully fixed problems found in earlier sessions. A brief overview of the testing session is presented in the following table:
かなりの共通点がセッションからセッションまでテストされた特徴にあります。 この共通点のいくつかの理由があります。 まず最初に、それぞれのテストセッションのときに、テストでOSPFシステムのサイズを増加させるのを試みをしました。 例えば、輸入された外部経路の数は各セッションのときに倍増しました。 第二に、相互運用性セッションはプロトコルセッションと同様にデバッギング・セッションです。 固定問題が以前のセッションのときに実現で首尾よく設立したver- ifyには3回戦でテストされた多くのものがありました。 テストセッションの簡潔な概観は以下のテーブルに提示されます:
TABLE 4. OSPF interoperability testing at a glance.
4を見送ってください。 一目におけるOSPF相互運用性テスト。
Site Week Routers Externals Implementations _____________________________________________________________________________ Proteon 9/25/90 6 20-30 3com, Proteon, Wellfleet SURAnet 12/17/90 10 96 3com, ACC, Proteon, Wellfleet 3com 2/4/91 16 400 3com, ACC, Proteon, Wellfleet, UMD
サイト週のルータ外観実現_____________________________________________________________________________ Proteon9/25/90 6 20-30 3com、Proteon、Wellfleet SURAnet12/17/90 10 96 3com、ACC、Proteon、2/4/91のWellfleet 3com、16、400 3com、ACC、Proteon、Wellfleet、UMD
For more information on the interoperability testing, the following people can be contacted: Fred Baker [fbaker], Rob Coltun [rcoltun], Dino Farinacci [dino], Jonathan Hsu [jhsu], John Moy [jmoy], and William Streilein [bstreile].
相互運用性テストの詳しい情報に関しては、以下の人々に連絡できます: フレッド・ベイカー[fbaker]、Coltun[rcoltun]、Dinoファリナッチ[恐竜]、ジョナサン・シュー[jhsu]、ジョンMoy[jmoy]、およびウィリアム・ストライリーン[bstreile]から、略奪してください。
7.1 Testing methodology
7.1 テスト方法論
In the interoperability tests, the routers have been interconnected using ethernet, serial lines (PPP and proprietary), X.25 and 802.5 token ring. Monitoring of the routers has been done through connecting terminals (either directly or via telnet) to the router consoles. Each implementation has a different user interface, which makes monitoring somewhat difficult. As explained earlier in this document, there is now an OSPF MIB, which in the future will enable a common monitoring interface to all implementations.
相互運用性テストで、ルータは、イーサネット、シリアル・ライン(PPPの、そして、独占である)、X.25、および802.5トークンリングを使用することでインタコネクトされました。 接続端末(直接かtelnetを通した)を通してルータコンソールにルータのモニターをしました。 各実現には異なったユーザーインタフェースがあります。(それは、モニターをいくらか難しくします)。 より早く本書では説明されるように、現在、OSPF MIBがあります。(OSPF MIBは将来、一般的なモニターしているインタフェースをすべての実現に可能にするでしょう)。
In general, each implementation has an error logging capability, and this is often how problems are discovered. LAN protocol analyzers are
一般に、各実現には、エラー・ロギング能力があります、そして、しばしばこれは問題がどう発見されるかということです。 LANプロトコルアナライザはそうです。
[Moy] [Page 18] RFC 1246 Experience with OSPF July 1991
[Moy] RFC1246が1991年7月にOSPFと共に経験する[18ページ]
also used to capture OSPF protocol packet exchanges that are causing problems. These packet traces are available for analysis either during of after the testing sessions.
また、テストセッションの後に問題を起こすこれらのパケット跡が分析に利用可能であるということであるOSPFプロトコルパケット交換を得るのにおいて使用されています。
Verification of routing was done through visual inspection of implementations' routing table and link state databases (via the console interface), and through network debugging tools such as "ping" and "traceroute".
実現の経路指定テーブルとリンク州のデータベース(コンソールインタフェースを通した)の目視検査を通して「ピング」や「トレースルート」などのネットワークデバッグ用ツールを通してルーティングの検証をしました。
7.2 First round (Proteon, 9/25/90 - 9/29/90)
7.2/1に丸いです。(9/25/90から9/29/90までのProteon)
The first round of OSPF protocol testing took place at Proteon Inc.'s Westborough facility, the week of September 25, 1990. Three implementations participated, from the vendors 3com, Proteon and Wellfleet.
OSPFプロトコルテストの最初のラウンドはProteon株式会社のウェストボーラフ施設、1990年9月25日の週に行われました。 3つの実現が業者の3com、Proteon、およびWellfleetから参加しました。
There were two 3com routers, two Wellfleet routers and two Proteon routers available for testing. These routers were interconnected with ethernets and serial lines. External routes were imported from the Proteon company internet. In addition, during off hours we were able to connect the routers under test to the Proteon company internet, forming one fairly large OSPF system.
2つの3comルータ、2つのWellfleetルータ、およびテストするのに利用可能な2つのProteonルータがありました。 これらのルータはイーサネットとシリアル・ラインでインタコネクトされました。 Proteon会社のインターネットから外部経路を輸入しました。 さらに、オフ時間、私たちはProteon会社のインターネットにルータをテスト中に関連づけることができました、1台のかなり大きいOSPFシステムを形成して。
The testing at Proteon proceeded as follows:
以下の通りProteonでのテストしかけました:
o All routers were connected to a single ethernet. Then, as routers were taken up and down, the Designated Router election algorithm and the Database Description process were tested. Also OSPF's reliable flooding algorithm was tested in this configuration.
o すべてのルータがただ一つのイーサネットに関連づけられました。 そして、上下にルータを取ったとき、Designated Router選挙アルゴリズムとDatabase記述の過程をテストしました。 OSPFのも信頼できる氾濫アルゴリズムはこの構成でテストされました。
o Twenty to thirty external routes were imported into the OSPF system by a Proteon router (which was simultaneously running RIP). It was then verified that these external routes were installed into the router's routing tables.
o Proteonルータ(同時に、RIPを走らせていた)で20〜30個の外部経路をOSPFシステムに輸入しました。 そして、これらの外部経路がルータの経路指定テーブルにインストールされたことが確かめられました。
o One of the 3com routers was configured to originate an OSPF default route. This tested OSPF default route processing, and also tested the behavior of the system when multiple routers were importing external routes.
o 3comルータの1つは、OSPFデフォルトルートを溯源するために構成されました。 これは、OSPFデフォルトルート処理をテストして、また、複数のルータが外部経路を輸入していたとき、システムの働きをテストしました。
o The OSPF system was split into areas. Both regular OSPF areas (non- stub) and stub areas were tested.
o OSPFシステムは領域に分けられました。 通常のOSPF領域(非スタッブの)とスタッブ領域の両方がテストされました。
o The six routers under test were connected to the Proteon company internet (which was also running OSPF), forming an OSPF system of eighteen routers. This configuration was shortlived, due to a disagreement between the 3com and Proteon routers concerning how to
o テスト中の6つのルータがProteon会社のインターネット(また、OSPFを走らせていた)に関連づけられました、18のルータのOSPFシステムを形成して。 この構成は3comとどのようにに関するProteonルータとの不一致のためshortlivedされました。
[Moy] [Page 19] RFC 1246 Experience with OSPF July 1991
[Moy] RFC1246が1991年7月にOSPFと共に経験する[19ページ]
represent an OSPF default route.
OSPFデフォルトルートを表してください。
Unfortunately, incomplete records were kept of this testing, so that no maps of the testing configurations can be reproduced for this document.
残念ながら、不完全な記録はこのテストについてつけられました、このドキュメントのためにテスト構成の地図を全く複製できないように。
7.2.1 Problems found in the First round testing
7.2.1 テストすることにおけるFirstでぐるりと見つけられた問題
A couple of OSPF protocol/specification problems were uncovered in the first round of testing. First, it was noticed that there was a window in the Database Description process where concurrently flooded MaxAge advertisements could prevent database synchronization from completing. This required a change in the specification's handling of MaxAge LSAs.
2、3のOSPFプロトコル/仕様問題がテストの最初のラウンドで発見されました。 まず最初に、窓が同時に水につかっているMaxAge広告が完成からのデータベース同期を防ぐことができたところにDatabase記述の過程にあったのに気付かれました。 これはMaxAge LSAsの仕様の取り扱いにおける変化を必要としました。
Secondly, it was found that the OSPF specification did not specify how the Network Mask field should be set in external LSAs that were advertising the DefaultDestination. This was a minor problem, but caused difficulties because of assumptions made in one implementation on how the mask should be set.
第二に、OSPF仕様がNetwork Mask分野がDefaultDestinationの広告を出していた外部のLSAsにどう設定されるべきであるかを指定しなかったのが見つけられました。 これは、小さな問題でしたが、マスクがどう設定されるべきであるかにおける1つの実現でされた仮定のために困難を引き起こしました。
7.3 Second round (SURAnet, 12/17/90 - 12/21/90)
7.3 2番目のラウンド(12/17/90から12/21/90までのSURAnet)
The second round of OSPF protocol testing took place at SURAnet's College Park facility, the week of December 12, 1990. Four implementations participated, from the vendors 3com, ACC, Proteon and Wellfleet.
OSPFプロトコルテストの2番目のラウンドはSURAnetのカレッジパーク施設、1990年12月12日の週に行われました。 4つの実現が業者の3com、ACC、Proteon、およびWellfleetから参加しました。
There were two 3com routers, two ACC routers, two Wellfleet routers and four Proteon routers available for testing. These routers were interconnected with ethernets, serial lines and token rings. External routes were imported from SURAnet by one of the Proteon routers.
2つの3comルータ、2つのACCルータ、2つのWellfleetルータ、およびテストするのに利用可能な4つのProteonルータがありました。 これらのルータはイーサネット、シリアル・ライン、およびトークンリングでインタコネクトされました。 Proteonルータの1つでSURAnetから外部経路を輸入しました。
The testing at SURAnet proceeded as follows. Initially nine routers were configured as a single backbone area, with six of the routers connected to a single ethernet. This is pictured in Figure 4. In this configuration, the Designated Router transition and database synchronization process were tested. Ninety-six external routes were imported from SURAnet to stress the flooding algorithm. By restarting the router that was importing the routes, the flushing of advertisements from the routing domain was tested. Additionally, variable-length subnets and OSPF's optional TOS routing capability were tested in this configuration.
以下の通りSURAnetでのテストしかけました。 初めは、9つのルータがただ一つの背骨領域としてただ一つのイーサネットに関連づけられる6つのルータによって構成されました。 これは図4に描写されます。 この構成では、Designated Router変遷とデータベース同期の過程はテストされました。 氾濫アルゴリズムを強調するためにSURAnetから96個の外部経路を輸入しました。 ルートを輸入していたルータを再開することによって、経路ドメインからの広告を洗い流すことはテストされました。 さらに、可変長のサブネットとOSPFの任意のTOSルーティング能力はこの構成でテストされました。
Next the routers were configured into four separate OSPF areas, with each area directly connected to the OSPF backbone (which was a single ethernet). There were no virtual links in this configuration. Inter-
次に、ルータは4つの別々のOSPF領域に構成されました、各領域が直接OSPF背骨(ただ一つのイーサネットであった)につなげられている状態で。 この構成にはどんな仮想のリンクもありませんでした。 相互
[Moy] [Page 20] RFC 1246 Experience with OSPF July 1991
[Moy] RFC1246が1991年7月にOSPFと共に経験する[20ページ]
area routing was tested, including having AS boundary routers internal to a non-backbone area. Also tested was the case where a single router was both an area border router and an AS boundary router.
AS境界ルータを非背骨領域に内部にするのを含んでいて、領域ルーティングはテストされました。 また、テストされているのは、ただ一つのルータが境界ルータとAS境界ルータの両方であったケースでした。
For more details of the testing, see the "Official report of the Second Round Testing" listed below.
テストのその他の詳細に関しては、「Second Round Testingに関する公式報告」が以下に記載されているのを見てください。
7.3.1 Official report of the Second round testing
7.3.1 テストの周りのSecondに関する公式報告
The following report was sent to the ospf, ospf-tests, and router- requirements mailing lists after the second round of interoperability tests:
相互運用性テストの2番目のラウンドの後にospf、ospf-テスト、およびルータ要件メーリングリストに以下のレポートを送りました:
The second round of OSPF multi-vendor testing was done in College Park, Maryland the week of 12/17/90. The facilities were provided by SURAnet. Four major router vendors were present, Advanced Computer Communications (ACC), Proteon, 3Com, and Wellfleet. A press conference and presentation was provided for 3 different data communication magazine representatives.
12/17/90の週にカレッジパーク(メリーランド)でOSPFマルチベンダテストの2番目のラウンドをしました。 施設はSURAnetによって提供されました。 4つの一流のルータ業者が、プレゼントと、AdvancedコンピュータCommunications(ACC)と、Proteonと、3Comと、Wellfleetでした。 3人の異なったデータ通信雑誌代表に記者会見とプレゼンテーションを提供しました。
Each vendor provided at least 2 routers. Each vendor had a device connected to a common Ethernet. This Ethernet was configured as the OSPF backbone area. The rest of the routers were attached to the various backbone routers via Ethernet, Token Ring, proprietary serial line, PPP serial line, and X.25 type media. The following test scenarios were performed and completed in the following order:
各業者は少なくとも2つのルータを提供しました。 各業者は一般的なイーサネットに装置を接続させました。 このイーサネットはOSPF背骨領域として構成されました。 ルータの残りはイーサネット、Token Ring、独占シリアル・ライン、PPPシリアル・ライン、およびX.25タイプメディアを通して様々な背骨ルータに付けられました。 以下のテストシナリオは、以下のオーダーで実行されて、完成しました:
o Intra-area routing. All routers were configured to reside in the backbone area. Designated Router election was performed various number of times so each vendor could be designated router for a period of time. Packet data was captured on a Sniffer for later observation.
o イントラ領域ルーティング。 すべてのルータが、背骨領域に住むために構成されました。 Router選挙に指定されているのが、実行された様々な回数であったので、しばらく、各業者をルータに任命できました。 後の観測のためにSnifferでパケットデータを得ました。
o Variable Length Subnet Masks. Some of the serial lines in the configuration were configured to be on the same IP network but with different subnet masks. It was observed that all routers stored routes for the different length subnets.
o 可変長サブネットマスク。 構成のいくつかのシリアル・ラインが、同じIPネットワークにもかかわらず、異なったサブネットマスクでオンになるように構成されました。 すべてのルータが異なった長さのサブネットのためにルートを格納したのが観測されました。
o Import SURAnet routes. The Proteon router was listening for RIP routes generated by the SURAnet routers. These routes were imported into our OSPF test system. 96 external link state advertisements were generated as a result. Many scaling type implementation problems surfaced for each vendor during this exercise.
o SURAnetにルートをインポートしてください。 ProteonルータはSURAnetルータによって生成されたRIPルートの聞こうとしていました。 これらのルートは私たちのOSPFテスト・システムにインポートされました。 96 その結果、外部のリンク州の広告は作られました。 多くのスケーリングタイプ実装問題が各ベンダーのためにこの運動の間、表面化しました。
o Type of Service generation. While the test setup was still configured as a single area, the 3Com router generated Type of Service link
o Service世代のタイプ。 テストセットアップはただ一つの領域としてまだ構成されていましたが、3ComルータはServiceリンクのTypeを生成しました。
[Moy] [Page 21] RFC 1246 Experience with OSPF July 1991
[Moy] RFC1246が1991年7月にOSPFと共に経験する[21ページ]
state advertisements. It was observed how the other vendor implementations reacted to it. Some problems were found.
広告を述べてください。 他のベンダー実装がどのようにそれに反応したかは観測されました。 いくつかの問題が見つけられました。
o Inter-area routing. Multiple areas were configured. Common non- backbone areas were shared by Proteon and Wellfleet and by ACC and 3Com. It was observed that the correct Intra-area and Inter-area routes appeared in each router's routing table. At this point in the test setup, the Proteon router regenerated the 96 SURAnet routes into the configuration. It was observed that the routes were learned and propagated over area boundaries. Some problems occur at this point. More emphasis on this scenario will occur at the next round of testing.
o 相互領域ルーティング。 複数の領域が構成されました。 一般的な非バックボーンの領域はProteonとWellfleetとACCと3Comによって共有されました。 正しいIntra-領域とInter-領域ルートが各ルータの経路指定テーブルに現れたのが観測されました。 ここに、テストセットアップで、Proteonルータは96のSURAnetルートを構成に作り直しました。 ルートがエリアの境界の上で学習されて、伝播されたのが観測されました。 いくつかの問題がここに起こります。 このシナリオへの、より多くの強調がテストの次のラウンドのときに起こるでしょう。
o OSPF over X.25. A point-to-point link was connected between the Proteon router and the 3Com router. The X.25 packet level was configured to run over the link. OSPF was enabled over the link to verify that multi-vendor OSPF over X.25 was performed. Both of these routers were in the same area.
o X.25の上のOSPF。 ポイントツーポイント接続はProteonルータと3Comルータの間で接続されました。 X.25パケット・レベルは、リンクをひくために構成されました。 OSPFはX.25の上のマルチベンダOSPFが実行されたことを確かめるリンクの上に有効にされました。 これらのルータの両方が同じ領域にありました。
o MaxAge advertisements. Link state advertisements were flushed from the routing domain using the MaxAge procedure. We verified that all routers removed the advertisements from their databases, after they were properly acknowledged by the flooding procedure. Some problems were found in this test, although not nearly as many as in the first round of testing.
o MaxAge広告。 リンク州の広告は、経路ドメインからMaxAge手順を用いることで洗い流されました。 それらが氾濫手順によって適切に承認された後に私たちは、すべてのルータがそれらのデータベースから広告を取り除いたことを確かめました。 テストの最初のラウンドと決して同じくらい多くではありませんが、いくつかの問題がこのテストで見つけられました。
Each vendor agreed that this sort of testing was extremely valuable and that it should occur again. 3Com has offered for the third round of testing to occur in Santa Clara sometime in February. 3Com will encourage other OSPF implementations to join in the testing. Items that will be tested are:
各ベンダーはこの種類のテストが非常に貴重であり、それが再び起こるべきであるのに同意しました。 3Comは、テストの3回戦が2月にサンタクララに起こると申し出ました。 3Comは、他のOSPF実装がテストに参加するよう奨励するでしょう。 テストされる項目は以下の通りです。
o Intra-area routing with loops (as well as equal-cost multipath).
o 輪(等価コストマルチパスと同様に)があるイントラ領域ルーティング。
o Inter-area testing including Stub and Transit area support, with both Intra-area and Inter-area loops.
o Stubを含んでいて、テストされる相互領域とTransit領域は、両方でIntra-領域とInter-領域が輪であるとサポートします。
o Virtual link testing in the looped Inter-area configuration.
o 輪にされたInter-領域構成の仮想のリンク・テスティング。
o RIP/OSPF route interchange including testing forwarding address capability in external link state advertisements.
o リップ/OSPFは外部のリンク州の広告にフォーワーディング・アドレス能力をテストするのを含む置き換えを発送します。
o EGP/OSPF router interchange including the use of the route tag field in external link state advertisements.
o 外部のリンク州の広告におけるルートタグ・フィールドの使用を含むEGP/OSPFルータ置き換え。
o More than two routers connected to an X.25 network. We would like to test OSPF's non-broadcast multi-access capabilities by attaching more than two vendor's routers to an X.25 packet switch.
o 2つ以上のルータがX.25ネットワークに接続しました。 2以上ベンダーのルータをX.25パケット交換機に取り付けることによって、OSPFの非放送マルチアクセス能力をテストしたいと思います。
[Moy] [Page 22] RFC 1246 Experience with OSPF July 1991
[Moy] RFC1246が1991年7月にOSPFと共に経験する[22ページ]
o Several vendors running OSPF and RIP simultaneously. This will further test the OSPF/RIP interactions.
o 同時にOSPFとRIPを実行するいくつかのベンダー。 これはさらにOSPF/RIP相互作用をテストするでしょう。
o Test processing of links with cost LSInfinity. These links should be treated as unreachable.
o 費用LSInfinityとのリンクの処理をテストしてください。 これらのリンクは手の届かないとして扱われるべきです。
Furthermore, we hope that in future rounds of testing an OSPF MIB would allow us to also use a network management station to gather test data.
その上、また、私たちがテストデータを集めるのにOSPF MIBをテストする今後のラウンドにおけるそれでネットワークマネージメントステーションを使用できることを願っています。
In summary, the stability of implementations were better this time more so than the first round of testing. No problems with the protocol design were encountered. The exchange of ideas and the cooperation among implementors that occurred during this test effort, continues the spirit that OSPF is truly an open protocol.
概要では、実装の安定性はテストの最初のラウンドよりそうであるさらに良い今回です。 プロトコルデザインに関する問題は全く行きあたられませんでした。 意見の交換とこれの間に起こった作成者の中の協力は取り組みをテストします、と精神が続けています。本当に、OSPFはオープン・プロトコルです。
7.3.2 Problems found in the Second round testing
7.3.2 テストすることにおけるSecondでぐるりと見つけられた問題
No problems were found in the OSPF protocol during the second round of testing.
テストの2番目のラウンドの間、問題は全くOSPFプロトコルで見つけられませんでした。
7.4 Third round (3com, 2/4/91 - 2/8/91)
7.4 3回戦(2/4/91から2/8/91までの3com)
The third round of OSPF protocol testing took place at 3com's Santa Clara facility, the week of February 4, 1991. Five implementations participated, from the vendors 3com, ACC, Proteon and Wellfleet and the publicly available University of Maryland implementation (running on a SUN workstation).
OSPFプロトコルテストの3回戦は3comのサンタクララ施設、1991年2月4日の週に行われました。 5つの実装が参加しました、ベンダー3com、ACC、Proteon、Wellfleet、およびメリーランド実装の公的に利用可能な大学から(SUNワークステーションで動いて)。
There were five 3com routers, four ACC routers, three Wellfleet routers, three Proteon routers and the UMD Sun workstation available for testing (giving a total of 16 routers available). These routers were interconnected with ethernets, serial lines and X.25. External routes were imported from BARRNet by one of the 3com routers.
テストするのに利用可能な5つの3comルータ、4つのACCルータ、3つのWellfleetルータ、3つのProteonルータ、およびUMD Sunワークステーションがありました(合計16のルータを利用可能に与えて)。 これらのルータはイーサネット、シリアル・ライン、およびX.25と共にインタコネクトされました。 外部経路は3comルータの1つによってBARRNetからインポートされました。
The initial testing configuration is shown in Figure 5. Three areas were configured, along with a non-contiguous backbone. The backbone was then joined by configuring two virtual links. In this configuration the following OSPF functionality was tested: inter-area routing and virtual links.
初期のテスト構成は図5に示されます。 3つの領域が非隣接のバックボーンと共に構成されました。 そして、バックボーンは、2個の仮想のリンクを構成することによって、接合されました。 この構成では、以下のOSPFの機能性はテストされました: 相互領域ルーティングと仮想のリンク。
The system was then reconfigured so that twelve of the routers were connected to a single ethernet. This configuration is pictured in Figure 6. By bringing routers up and down, this configuration tested Designated Router election, database synchronization and reliable flooding. To see how this functionality, and also the implementations, scale, 400
次に、システムが再構成されたので、12のルータがただ一つのイーサネットに関連づけられました。 この構成は図6に描写されます。 ルータを上下にもたらすことによって、この構成はDesignated Router選挙、データベース同期、および信頼できる氾濫をテストしました。 この機能性、および実装もどう比例するかを見るために400
[Moy] [Page 23] RFC 1246 Experience with OSPF July 1991
[Moy] RFC1246が1991年7月にOSPFと共に経験する[23ページ]
external routes were imported from BARRNet.
外部経路はBARRNetからインポートされました。
7.4.1 Official report of the Third round testing
7.4.1 テストの周りのThirdに関する公式報告
The following report was sent to the ospf, ospf-tests, and router- requirements mailing lists after the third round of interoperability tests:
相互運用性テストの3回戦の後にospf、ospf-テスト、およびルータ要件メーリングリストに以下のレポートを送りました:
The third round of OSPF interoperability testing was held at 3com Corporation in Santa Clara the week of February 4-8. Four router vendors came to the testing: 3com, ACC, Proteon and Wellfleet. In addition, Rob Coltun brought the University of Maryland implementation, which was run on a Sun Workstation.
OSPF相互運用性テストの3回戦は2月4日〜8日の週にサンタクララで3com社で開催されました。 4つのルータベンダーがテストに来ました: 3com、ACC、Proteon、およびWellfleet。 さらに、ロブColtunはメリーランド大学実装をもたらしました。(それは、サンワークステーションの上で実行されました)。
Testing was performed over ethernet, point-to-point networks (using PPP) and X.25. In all we had 16 routers available: five 3com routers, four ACC routers, three Proteon routers, three Wellfleet routers and Rob's SUN. We also were able to import external routes from BARRNet.
テストはイーサネット、二地点間ネットワーク(PPPを使用する)、およびX.25の上で実行されました。 私たちには、全部で、利用可能な16のルータがありました: 5つの3comルータ、4つのACCルータ、3つのProteonルータ、3つのWellfleetルータ、およびロブの日曜日に、WeもBARRNetから外部経路をインポートすることができます。
Specific tests performed included the following:
実行された特異的な試験は以下を含んでいました:
o Initially we configured the routers into three separate areas and a physically disconnected backbone. The backbone was then reconnected through configuration of several virtual links. These tests verified the generation and processing of summary link advertisements, as well as the operation of virtual links.
o 初めは、私たちは3つの分離した部分と物理的に切断しているバックボーンにルータを構成しました。 そして、バックボーンは数個の仮想のリンクの構成を通して再接続されました。 これらのテストは概要リンク広告の世代と処理、および仮想のリンクの操作について確かめました。
o We connected multiple routers to an X.25 packet switch, testing OSPF's non-broadcast network capability. OSPF was successfully run over the X.25 network, using routers that were both DR eligible and DR ineligible. Some problems were encountered, but they all involved running IP over X.25 (i.e., they were not X.25 specific).
o OSPFの非放送網能力をテストして、私たちは複数のルータをX.25パケット交換機に接続しました。 適任のDRとDR不適格者の両方であったルータを使用して、OSPFは首尾よくX.25ネットワークの上に実行されました。 いくつかの問題が行きあたられましたが、それらは皆、X.25にIPを経営していることを伴いました(すなわち、それらはX.25特有ではありませんでした)。
o We also connected a 3com router, Proteon router, and Rob's SUN to an ethernet, and then treated the ethernet as a non-broadcast network. This allowed us to connect Rob's SUN into the rest of the routing domain without installing the IP multicast modifications to the SUN kernel. It also further tested the OSPF's non-broadcast network capability.
o 私たちは、また、3comルータ、Proteonルータ、およびロブのSUNをイーサネットに接続して、次に、非放送網としてイーサネットを扱いました。 これで、SUNカーネルへのIPマルチキャスト変更をインストールしないで、私たちはロブのSUNを経路ドメインの残りに接続できました。 また、それはさらにOSPFの非放送網能力をテストしました。
o We then reconfigured the OSPF system so that all but three of the routers were connected to a single ethernet. This tested the Designated Router functionality (12 routers were synchronizing with the DR). We then also tested the DR election algorithm, by selectively restarting the DR, or sometimes both the DR and the Backup DR. This also tested OSPF's Database Description process.
o 次に、私たちがOSPFシステムを再構成したので、3つのルータつを除いたすべてがただ一つのイーサネットに関連づけられました。 これはDesignated Routerの機能性をテストしました(12のルータがDRに同期していました)。 次に、また、私たちは選択的にDR、または時々両方を再開するのによるDR選挙アルゴリズム、DR、およびBackup DRをテストしました。また、これはOSPFのDatabase記述プロセスをテストしました。
[Moy] [Page 24] RFC 1246 Experience with OSPF July 1991
[Moy] RFC1246が1991年7月にOSPFと共に経験する[24ページ]
o In this configuration, we then imported 400 external routes from BARRNet (one of the 3com routers ran both OSPF and EGP). Some problems were encountered in implementations' buffer allocation strategies, and problems were also found in the way implementations avoid IP fragmentation. But overall, this system was fairly stable.
o そして、この構成では、私たちはBARRNetから400個の外部経路をインポートしました(3comルータの1つはOSPFとEGPの両方を走らせました)。 実装のバッファ配分戦略でいくつかの問題が行きあたられました、そして、また、問題は実装がIP断片化を避ける方法で見つけられました。 しかし、全体的に見て、このシステムはかなり安定していました。
The following problems we found in the OSPF specification:
私たちがOSPF仕様で見つけた以下の問題:
o The specification should say that the "Network mask" field should not be verified in OSPF Hellos received over virtual links.
o 仕様は、「ネットワークマスク」分野が仮想のリンクの上に受け取られたOSPFハローズで確かめられるべきでないと言うべきです。
o The specification should say that on multi-access networks neighbors are identified by their IP address, and on point-to-point networks and virtual links by their OSPF Router ID. This eliminates confusion when, for example, a router is restarted and comes up with the same IP address but a different Router ID.
o 仕様は、隣人が彼らのIPアドレスの近くと、そして、二地点間ネットワークとそれらのOSPF Router IDのそばの仮想のリンクの上にマルチアクセスネットワークでは、特定されると言うべきです。 これは、例えば、ルータが再開されるとき、混乱を排除して、同じIPアドレスにもかかわらず、異なったRouter IDを思いつきます。
Thanks to 3com for providing the testing facility, cables. terminals, X.25 switch. etc. Also thanks to Vince Fuller of BARRNet for helping us import the BARRNet routes.
ケーブルX.25スイッチ試験施設、端末などを提供するための3comのおかげで また、私たちを助けるためのBARRNetのビンス・フラーへの感謝はBARRNetルートをインポートします。
7.4.2 Problems found in the Third round testing
7.4.2 テストすることにおけるThirdでぐるりと見つけられた問題
A couple of specification/protocol problems were found in the third round of interoperability testing. First, it was noticed that the specification did not specify the setting of the Network Mask field in Hellos sent over virtual links. This caused some initial difficulty in bringing up virtual links between routers belonging to different vendors. Secondly, it was noticed that the specification was not strict enough in defining how OSPF neighbors are identified on multi-access networks. This caused difficulties in one implementation when another vendor's router was restarted with the same IP address but a different OSPF Router ID. This is discussed more fully in the above "Official Report of the Third Round Testing".
2、3の仕様/プロトコル問題が相互運用性テストの3回戦で見つけられました。 まず最初に、仕様が仮想のリンクの上に送られたハローズでNetwork Mask分野の設定を指定しなかったのに気付かれました。 これは、異なったベンダーに属しながら、ルータの間で仮想のリンクを持って来る際に何らかの初期の困難を引き起こしました。 第二に、仕様がOSPF隣人がマルチアクセスネットワークでどう特定されるかを定義するのにおいて十分厳しくないのに気付かれました。 別のベンダーのルータが同じIPアドレスにもかかわらず、異なったOSPF Router IDと共に再開されたとき、これは1つの実装における困難を引き起こしました。 上の「3回戦テストに関する公式報告」でこれについて、より完全に議論します。
7.5 Overall: Features tested
7.5 総合的: 特徴はテストされました。
All significant protocol features and mechanisms have been tested in the three rounds of interoperability testing. In particular, the following basic pieces of the protocol have been tested:
すべての重要なプロトコル機能とメカニズムは相互運用性テストの3ラウンドでテストされました。 特に、プロトコルの以下の基本的な断片はテストされました:
o Designated Router election. With as many as thirteen routers attached to a single LAN, the election of Backup Designated Router and Designated router was verified by bringing routers up and down,
o Router選挙に指定されます。 最大13のルータが単一のLANに付けられている状態で、Backup Designated RouterとDesignatedルータの選挙は、ルータを上下にもたらすことによって、確かめられました。
[Moy] [Page 25] RFC 1246 Experience with OSPF July 1991
[Moy] RFC1246が1991年7月にOSPFと共に経験する[25ページ]
singly and in pairs.
単独と組で。
o Adjacency bringup. The Database Description process was verified, with databases having over 400 LSAs. Adjacency bringup was also verified in times when flooding was taking place simultaneously.
o 隣接番組bringup。 Database記述プロセスは400LSAsを持っているデータベースで確かめられました。 また、隣接番組bringupは氾濫が同時に起こっていた時代で確かめられました。
o Reliable flooding. It was verified that OSPF's flooding algorithm maintains database synchronization, both in the presence of loops in the topology, and with large databases (over 400 LSAs).
o 信頼できる氾濫。 OSPFの氾濫アルゴリズムがデータベース同期を維持することが確かめられました、ともにトポロジー、および大容量データベースがある輪(400LSAs)があるとき。
o Flushing advertisements from routing domain. OSPF's procedure for flushing old or unreachable LSAs from the routing domain was verified, both in the presence of topology loops and with many LSAs being flushed at once. This is also referred to as OSPF's MaxAge procedure.
o 経路ドメインからの広告を洗い流します。 経路ドメインから古いか手の届かないLSAsを洗い流すためのOSPFの手順は確かめられました、トポロジー輪があるとき多くのLSAsがすぐに洗い流されている両方。 また、これはOSPFのMaxAge手順と呼ばれます。
o OSPF routing hierarchy. The OSPF four level routing hierarchy: intra-area, inter-area. type 1 externals and type 2 externals was tested.
o OSPFルーティング階層構造。 OSPF fourはルーティング階層構造を平らにします: 相互領域イントラ領域、タイプ1外観、およびタイプ2外観は検査されました。
o Import of external routing information. The importing of external routes has been tested, with as many as 400 imported at once. Also, the varying options in external LSAs has been tested: type 1 or type 2 metrics and forwarding addresses.escribe all options. In addition, test setups were utilized having AS boundary routers both internal to non-backbone areas and also being simultaneously area border routers.
o 外部のルーティング情報の輸入。 外部経路をインポートすることは400がすぐにインポートしたのと同じくらい多くでテストされました。 また、外部のLSAsの異なったオプションはテストされました: 2つの測定基準をタイプして、1をタイプしてください、またはforwarding addresses.escribeはすべてのオプションをタイプします。 さらに、テストセットアップは、AS境界ルータをともに非バックボーン領域に内部にして、また、同時に境界ルータであるので利用されました。
o Running protocol over various network types. In the test setups, OSPF has been run over ethernet, point-to-point serial lines (both PPP and proprietary), 802.5 token ring and X.25.
o 様々なネットワークタイプでプロトコルを実行します。 テストセットアップで、OSPFはイーサネットの上に実行されました、二地点間シリアル・ライン、(両方、PPPで独占である、)、802.5トークンリングとX.25。
o Non-broadcast, multi-access networks. OSPF has been tested over X.25. Some testing was also done treating ethernet as a non-broadcast network. Two separate situations were tested: when all routers attached to the non-broadcast network were DR-eligible, and when only some of them were.
o 非放送であって、マルチアクセスしているネットワーク。 OSPFはX.25の上でテストされました。 また、いくつかのテストが非放送網としてイーサネットを扱い終わっていました。 2つの別々の状況がテストされました: 非放送網に付けられたすべてのルータがいつDR適任であったか、そして、それらの唯一のいくつかがいつでしたか?
o Authentication. OSPF's authentication procedure was tested for the two current authentication types.
o 認証。 OSPFの認証手順は2つの現在の認証タイプがないかどうかテストされました。
o Equal-cost multipath. Much of the testing was done in configurations with redundant paths, and equal-cost multipath was verified through examination of implementations' routing tables.
o 等価コストマルチパス。 冗長パスで構成でテストの多くのことをしました、そして、実装の経路指定テーブルの試験で等価コストマルチパスについて確かめました。
o Variable-length subnet masks. It was verified that implementations paid attention to the network mask field present in OSPF LSAs.
o 可変長のサブネットマスク。 実装がOSPF LSAsの現在のネットワークマスク分野に注意を向けたことが確かめられました。
[Moy] [Page 26] RFC 1246 Experience with OSPF July 1991
[Moy] RFC1246が1991年7月にOSPFと共に経験する[26ページ]
Testing was also performed on the following pieces of OSPF's Area functionality:
また、テストは以下のOSPFのAreaの機能性に実行されました:
o Extent of advertisements. It was verified that all advertisements except external LSAs were flooded throughout a single area only.
o 広告の範囲。 外部のLSAs以外のすべての広告がただ一つの領域だけ中で水につかっていることが確かめられました。
o Inter-area routing. The generation and processing of summary link LSAs was tested. Also tested were configurations having multiple area border routers attaching to a single area.
o 相互領域ルーティング。 概要リンクLSAsの世代と処理はテストされました。 また、テストされているのは、ただ一つの領域に付く複数の境界ルータを持っている構成でした。
o Virtual links.
o 仮想のリンク。
The following OSPF options were also tested:
また、以下のOSPFオプションはテストされました:
o TOS routing. The interplay between TOS-capable and non-TOS-capable routers was tested, by configuring TOS-specific metrics in the only implementation (3com) supporting TOS routing.
o TOSルーティング。 TOSできることの間の交錯とできる非TOSルータはテストされました、TOSがルーティングであるとサポートしながら唯一の実装(3com)におけるTOS特有の測定基準を構成することによって。
o Stub areas. OSPF's stub area functionality was verified.
o 領域を引き抜いてください。 OSPFのスタッブ領域の機能性は確かめられました。
7.6 Testing conclusions
7.6 テスト結論
The interoperability testing has proven to be very valuable. Many bugs were found (and fixed) in the implementations. Some protocol problems were found (and fixed), and gray areas of the specification were cleared up. Implementations have also been "bullet-proofed" in order to deal with the unexpected behavior of other implementations. All participants in the testing now understand the maxim "be conservative in what you generate, and liberal in what you accept" (if they didn't already).
相互運用性テストは非常に貴重であると判明しました。 多くのバグが実装で見つけられました(そして、修理されています)。 いくつかのプロトコル問題が見つけられました、そして、(そして、修理されています)仕様の暗い領域は解決されました。 また、実装も、他の実装の予期していなかった振舞いに対処するために「弾丸で、検査されています」。 現在のテストのすべての関係者が「あなたが生成することで保守的であって、あなたが受け入れるもので寛容である」という格言を理解しています(彼らが既にそうしなかったなら)。
7.7 Future work
7.7 今後の活動
The one thing that has gone mostly untested at the interoperability sessions is the interaction between OSPF and other routing protocols (such as RIP and EGP). Each interoperability session generally had a router running multiple routing protocols in order to import external routing information into the OSPF system. However, simultaneously running multiple routing protocols between different vendors' routers has not been tested.
相互運用性セッションのときにほとんど試されていなくなった1つのものはOSPFと他のルーティング・プロトコル(RIPやEGPなどの)との相互作用です。 一般に、それぞれの相互運用性セッションには、外部のルーティングが情報であるとOSPFシステムにインポートするために複数のルーティング・プロトコルを実行するルータがありました。 しかしながら、同時に異なったベンダーのルータの間の複数のルーティング・プロトコルを実行するのはテストされていません。
Each vendor has developed a slightly different architecture for the exchange of routing information between differing routing protocols. As the OSPF field testing has also shown, this exchange of routing information is an area of ongoing work and a candidate for future standardization.
各ベンダーは異なったルーティング・プロトコルの間のルーティング情報の交換のためにわずかに異なったアーキテクチャを開発しました。 また、OSPF実地試験が示したように、ルーティング情報のこの交換は、進行中の仕事の領域と今後の標準化の候補です。
[Moy] [Page 27] RFC 1246 Experience with OSPF July 1991
[Moy] RFC1246が1991年7月にOSPFと共に経験する[27ページ]
8.0 Simulation
8.0 シミュレーション
The OSPF protocol has been simulated by the Distributed Systems Research Group at the University of Maryland Baltimore County (UMBC). The two principal investigators for the OSPF simulation project are Dr. Deepinder P. Sidhu of UMBC and Rob Coltun. They have been aided by three graduate students: S. Abdallah, T. Fu and R. Nair. This section attempts to summarize their simulation setup and results. For more information, contact the Distributed Systems Research Group at the following address:
OSPFプロトコルはメリーランド大学ボルチモアカウンティー(UMBC)のDistributed Systems Research Groupによってシミュレートされました。 OSPFシミュレーションプロジェクトの2人の実験責任者がUMBCとロブColtunのDeepinder P.Sidhu博士です。 それらは3人の大学院生によって支援されました: S。 Abdallah、T.フー、およびR.ナイア。 このセクションは、それらのシミュレーションセットアップと結果をまとめるのを試みます。 詳しくは、Distributed Systems Research Groupは以下のアドレスで連絡します:
Dr. Deepinder P. Sidhu
Department of Computer Science
University of Maryland Baltimore County
Baltimore, MD 21228
email: sidhu@umbc3.umbc.edu
Deepinder P.SidhuコンピュータScienceメリーランド大学ボルチモアカウンティーの部ボルチモア博士、MD 21228はメールされます: sidhu@umbc3.umbc.edu
A demo was given of their OSPF simulation at the March 4-8, 1991 IETF in St. Louis. Details of the demo should be available in the IETF proceedings.
セントルイスの1991年3月4日〜8日IETFのときに彼らのOSPFシミュレーションをデモに与えました。 デモの詳細はIETF議事で利用可能であるべきです。
8.1 Simulator setup
8.1 シミュレータセットアップ
The Distributed System Research Group uses a significantly enhanced version of the MIT network simulator. The simulator is event driven, and contains support for both point-to-point networks and ethernet links. It can simulate characteristics of both packet switches and hosts, and can simulate internet behavior under various types of data traffic load (e.g., Poisson, normal, exponential and uniform distributions). This latter ability could be used, for example, to simulate how a routing protocol works in a congested internet. Specific network topologies can be input into the simulator, or pseudo-random network topologies can be generated. Packet loss rates can also be simulated.
Distributed System Research GroupはMITネットワークシミュレータのかなり高められたバージョンを使用します。 シミュレータは、イベントドリブンであり、二地点間ネットワークとイーサネットリンクの両方のサポートを含んでいます。 それは、パケット交換機とホストの両方の特性をシミュレートできて、様々なタイプのデータトラヒック負荷(例えば、ポアソン、正常で、指数の、そして、一定の配)の下でのインターネットの振舞いをシミュレートできます。 例えば、ルーティング・プロトコルが混雑しているインターネットでどう働いているかをシミュレートするのにこの後者の能力を使用できました。 特定のネットワークtopologiesをシミュレータに入力できますか、または擬似ランダムネットワークtopologiesを生成することができます。 また、パケット損失率をシミュレートできます。
To simulate OSPF, Rob Coltun's OSPF implementation was incorporated into the simulator, essentially unchanged.
OSPFをシミュレートするために、ロブColtunのOSPF実装はシミュレータに本質的には変わりがない状態で組み入れられました。
The output of the simulator can be displayed in a graphical manner (it uses X windows). Any variable in the implementation under test can be monitored. In addition, statistical reports can later be produced from logging files produced during the simulation runs.
グラフィカルな方法でシミュレータの出力を表示できます(それはX-windowsを使用します)。 テスト中の実装におけるどんな変数もモニターできます。 さらに、後でシミュレーション下痢の間に作り出された伐採ファイルから統計報告を製作できます。
[Moy] [Page 28] RFC 1246 Experience with OSPF July 1991
[Moy] RFC1246が1991年7月にOSPFと共に経験する[28ページ]
8.2 Simulation results
8.2 シミュレーション結果
The OSPF simulation has been run using the following topologies:
OSPFシミュレーションは以下のtopologiesを使用する走行です:
o The two sample topologies in the OSPF specification (Figure 2 and Figure 6 in [2]). The first of these topologies shows an Autonomous System without areas, the second the same AS with three areas and a virtual link configured.
o 2はOSPF仕様でtopologiesを抽出します。(図2と[2])の図6。 領域のないAutonomous System、3つの領域がある同じ第2AS、および仮想のリンクが構成したこれらのtopologiesショーの1番目。
o The 19-node hub topology from [7].
o [7]からの19ノードのハブトポロジー。
o A large network of over 50 nodes, all attached to a single ethernet.
o 50以上のノードの大きいネットワークであり、すべてがただ一つのイーサネットに付きました。
o A large network of over 50 nodes, containing both ethernets and serial lines, pseudo randomly generated.
o イーサネットとシリアル・ラインの両方を含む50以上のノードの大きいネットワーク、疑似である、無作為である、発生しています。
In these topologies, the correctness of the OSPF database synchronization was verified. This was done through examination of the nodes' OSPF link state databases and the nodes' routing tables. The implementation of multiple OSPF areas was also tested. Also, database convergence time was analyzed as a function of the network components' link speeds.
これらのtopologiesでは、OSPFデータベース同期の正当性は確かめられました。 ノードのOSPFリンク州のデータベースとノードの経路指定テーブルの試験でこれをしました。 また、複数のOSPF領域の実装はテストされました。 また、ネットワーク要素のリンクの機能が疾走するとき、データベース集合時間は分析されました。
Also, some formal analysis of the OSPF protocol was undertaken. The neighbor and interface state machines were analyzed. In addition, the Designated Router election algorithm was verified for certain sets of initial conditions.
また、OSPFプロトコルの何らかの形式的分析が引き受けられました。 隣人と界面準位マシンは分析されました。 さらに、Designated Router選挙アルゴリズムはある初期条件のために確かめられました。
9.0 Reference Documents
9.0 参照ドキュメント
The following documents have been referenced by this report:
以下のドキュメントはこのレポートによって参照をつけられました:
[1] Moy, J., "The OSPF Specification", RFC 1131, October 1989.
[1]Moy、J.、「OSPF仕様」、RFC1131、1989年10月。
[2] Moy, J., "OSPF Version 2", RFC 1247, July 1991.
[2]Moy、J.、「OSPF、バージョン2インチ、RFC1247、1991インチ年7月。
[3] Coltun, R. and Baker, F., "OSPF Version 2 Management Information
Base", RFC 1248, July 1991.
[3]ColtunとR.とベイカー、F.、「OSPFバージョン2管理情報ベース」、RFC1248、1991年7月。
[4] Reynolds, J. and Postel, J., "Assigned Numbers', RFC1060, March
1990.
[4] レイノルズ、J.、およびポステル(J.)は「1990年3月を民数記、RFC1060に割り当てました」。
[5] Corporation for National Research Initiatives, "Proceedings of the
Thirteenth Internet Engineering Task Force", Cocoa Beach, Florida,
April 11-14, 1989.
[5] 国家の研究イニシアチブのための社、「第13インターネット・エンジニアリング・タスク・フォースの議事」、Cocoaビーチ(フロリダ)1989年4月11日〜14日。
[Moy] [Page 29] RFC 1246 Experience with OSPF July 1991
[Moy] RFC1246が1991年7月にOSPFと共に経験する[29ページ]
[6] Corporation for National Research Initiatives, "Proceedings of the
Sixteenth Internet Engineering Task Force", Florida State
University, February 6-9, 1990.
[6] 国家の研究イニシアチブのための社、「第16インターネット・エンジニアリング・タスク・フォースの議事」、フロリダ州立大学、1990年2月6日〜9日。
[7] Gardner, M., et al., "Type-of-service routing: modeling and
simulation," Report 6364, BBN Communications Corporation, January
1987.
[7] ガードナー、M.、他、「以下を掘るサービスのタイプ」 「モデリングシミュレーション」、Report6364、BBN Communications社、1987年1月。
[8] Corporation for National Research Initiatives, "Proceedings of the
Seventeenth Internet Engineering Task Force", Pittsburgh
Supercomputing Center, May 1-4, 1990.
[8] ピッツバーグSupercomputingは、1990年5月1日〜4日の間、国家の研究イニシアチブのための社、「第17インターネット・エンジニアリング・タスク・フォースの議事」と中心に置きます。
[9] Corporation for National Research Initiatives, "Proceedings of the
Eighteenth Internet Engineering Task Force", University of British
Columbia, July 30-August 3, 1990.
[9] 国家の研究イニシアチブ、「第18インターネット・エンジニアリング・タスク・フォースの議事」、ブリティッシュ・コロンビア大学、1990 7月30日〜8月3日の社。
10.0 People
10.0 人々
The following people have contributed information to this report and can be contacted for further information:
以下の人々を、このレポートに情報を寄付して、詳細のために連絡できます:
TABLE 5. People references in this report
5を見送ってください。 このレポートにおける人々参照
Tag Name Affiliation email __________________________________________________________________________________ bstreile William Streilein Wellfleet bstreile@wellfleet.com dino Dino Farinacci 3com dino@buckeye.esd.3com.com fbaker Fred Baker ACC fbaker@acc.com jeff Jeffrey Burgan Sterling Software jeff@nsipo.nasa.gov jhsu Jonathan Hsu Wellfleet jhsu@wellfleet.com jmoy John Moy Proteon jmoy@proteon.com kannan Kannan Varadhan OARnet kannan@oar.net medin Milo Medin Sterling Software medin@nsipo.nasa.gov rcoltun Rob Coltun U. of Maryland rcoltun@umd5.umd.edu rrv Ross Veach U. of Illinois rrv@seka.cso.uiuc.edu vaf Vince Fuller BARRNet vaf@valinor.stanford.edu
タグName Affiliationメール__________________________________________________________________________________ bstreileウィリアムストライリーンWellfleet bstreile@wellfleet.com 恐竜ディーノファリナッチ3com dino@buckeye.esd.3com.com fbakerフレッドベイカーACC fbaker@acc.com jeffジェフリーブルガンSterling Software jeff@nsipo.nasa.gov jhsuジョナサンシューWellfleet jhsu@wellfleet.com jmoyジョンMoy Proteon jmoy@proteon イリノイ rrv@seka.cso.uiuc.edu vafビンスフラーBARRNet vaf@valinor.stanford.edu のメリーランド rcoltun@umd5.umd.edu rrvロスVeach U.のcom kannan Kannan Varadhan OARnet kannan@oar.net medinミロメディンSterling Software medin@nsipo.nasa.gov rcoltunロブColtun U.
[Moy] [Page 30] RFC 1246 Experience with OSPF July 1991
[Moy] RFC1246が1991年7月にOSPFと共に経験する[30ページ]
Security Considerations
セキュリティ問題
The OSPF protocol's security architecture is described in Section 4.0.
OSPFプロトコルのセキュリティー体系はセクション4.0で説明されます。
Author's Address
作者のアドレス
John Moy Proteon Inc. 2 Technology Drive Westborough, MA 01581
Driveウェストボーラフ、ジョンMoy Proteon Inc.2Technology MA 01581
Phone: (508) 898-2800 Email: jmoy@proteon.com
以下に電話をしてください。 (508) 898-2800 メールしてください: jmoy@proteon.com
[Moy] [Page 31]
[Moy][31ページ]
一覧
スポンサーリンク
