JP3996577B2 - 様々な発見技術の分割によるトポロジ発見 - Google Patents

Description

本発明は、全般的にはネットワークに関し、詳細には、ネットワークまたは経路指定トポロジを判定する方法および装置に関する。

分散処理ネットワークは、我々の情報化社会においてますます重要性を増している。図１は、単純なデータ・ネットワークのネットワーク・トポロジを示す。ネットワーク１００は、複数のルータ１０４ａ〜ｇ、中継ネットワーク１０８、およびスタブ・ネットワーク１１２を含み、すべてがリンク１１６ａ〜ｉによって相互接続される。ルータとは、着信データまたはパケットを適切なネットワーク／ノードに経路指定する、２つ以上のネットワークを接続する装置であり、中継ネットワークとは、１つ以上のルータを含むネットワークであり、スタブ・ネットワークとは、ネットワークを介してあるルータから別のルータにパケットを中継するように構成されないネットワークであり、リンクとは、２つ以上のノードの間の通信チャネルであることが理解されよう。ルータはそれぞれ、通常はインターフェース１２０ａ〜ｎなどの１つまたは複数のインターフェースを介してリンクに接続される。図１の単純なネットワークは、２つの領域の間の境界である破線１２４で２つのプロトコル領域に分けられる。ルータ１０４ｃは境界１２４上に位置して本明細書では区域境界ルータと呼ばれ、他のルータ１０４ａ〜ｂおよびｄ〜ｇは区域境界ルータではない。１つまたは複数のプロトコル領域はしばしば、自律システムである。自律システムとは、単一の管理権限によって制御されるネットワークの集合体である。

パケット交換ネットワークでは、相互接続されたネットワークを介してパケットを経路指定するのに使われる技術は、経路指定プロトコルによって決まる。ほとんどのプロトコルは、以下の２つのカテゴリのうちの１つである。つまり、距離ベクタ・アルゴリズム（送信元ネットワークから宛先ネットワークまで、パケットが途中で横断するルータのホップ数を計算することによって、送信元ノードと宛先ノードの間の距離を判定する）、およびリンク状態アルゴリズム（ルータがネットワーク内のリンクについて知らされるようにするために、リンク状態広告すなわちＬＳＡ（ルータの隣接ルータの名前および様々なコスト算出法を含む）を使う）である。実際の経路を格納する（距離ベクタ・アルゴリズムの場合）だけでなく、リンク状態アルゴリズムは、このような経路を生成するのに必要な情報を格納する。距離ベクタ・アルゴリズムを使うルータ・プロトコルの例にはＲＩＰおよびＲＩＰ−２があり、リンク状態アルゴリズムを使うルータ・プロトコルの例には、最適経路制御プロトコルすなわちＯＳＰＦ、ＯＳＩのＩＳ−ＩＳ、ＥＩＧＲＰ、およびＮｅｔｗａｒｅのリンク・サービス・プロトコル（ＮＬＳＰ）がある。

ルータおよび他のネットワーク構成要素は通常、ネットワーク管理システムを用いて管理される。ネットワーク管理システムは、ネットワークの保守を実施し、ネットワークにおける潜在的な安全性の問題を識別し、機器、モジュール、サブアセンブリ、およびカードの故障を位置決めし、回路停止を検出し、性能レベル（たとえば、ビット・エラー・レートすなわちＢＥＲ、同期の喪失など）を監視し、ネットワークの使用およびトラフィック・レベルの高速かつ正確な限定を許可する。上述の作業を実施するために使われるネットワーク管理システムの例には、ヒューレット・パッカードのＯｐｅｎＶｉｅｗ（商標）、ＩＢＭのＮｅｔｖｉｅｗ（商標）、およびディジタル・イクイップメント・コーポレーションの企業管理アーキテクチャすなわちＥＭＡ（商標）がある。

ネットワーク管理システムの最適動作のために、ネットワークまたはＯＳＩレイヤ３トポロジの正確で詳細なマップが一般に必要とされる。このようなマップは、ネットワーク管理システムの動作を容易にするだけでなく、新規に接続されたホストが（ネットワーク性能への悪影響を避けるために）ネットワークにとって適切に配置され構成されることも、既存のホストが、新規に接続されたホストにとって適切に配置されることも可能にする。通常の実施では、ネットワークのトポロジの詳細なマップは、全体的にも部分的にも、ネットワーク管理担当者には利用不可能である。このことは、記録の保存の乏しさ、一部のネットワークの大規模性および複雑さ、ならびにネットワークがいくつかの自律システムまたは企業を含む場合などのネットワークの中央管理の欠如によるものである場合がある。

ネットワーク層トポロジを自動的に発見する簡易ネットワーク管理プロトコル、すなわちＳＮＭＰアルゴリズムが、多くのネットワーク管理ツールにおいて使われる。ＳＮＭＰアルゴリズムは、いくつかの手法を取ることができる。「ホップバイホップ」手法として知られる一手法では、このアルゴリズムは、各ルータ内の標準経路指定ＳＮＭＰの管理情報ベースすなわちＭＩＢ情報にホップバイホップ・ベースでアクセスする。本明細書で使用する「ホップ」とは、中間ノードをもたない経路の一部分を指し、「ＭＩＢ」とは、ＳＮＭＰによって定義されたように管理することができる、管理されるオブジェクトまたは変数の組である。ＭＩＢオブジェクトまたは変数は通常、管理情報構造すなわちＳＭＩとして知られる規則の組によって定義される。ＭＩＢ情報は、どのＳＮＭＰルータのメモリにも格納されることが理解されよう。別の手法では、ベンダ独自の固有アルゴリズムが、トポロジを生成するのに使用される。このような解決法の一例は、シスコ・システムズによるＣＤＰ（商標）である。このような固有アルゴリズムは通常、標準ＳＮＭＰのＭＩＢへのベンダ独自の拡張に依拠し、こうした拡張は、マルチベンダ・ネットワークにおいては全般的に有用ではない。

ＳＮＭＰネットワーク・トポロジ発見アルゴリズムは通常、ネットワーク内のルータが異なる経路指定プロトコルをサポートしかつ／または交信不可能であるとき、レイヤ３トポロジを確認することができない。ルータは、不正な証明の使用、交信されたインターフェースの動作不能状態、ルータ内のアクセス不可能なまたは存在しないＳＮＭＰエージェントなど様々な理由で交信不可能になり得る。こうした問題は、図２によって示される。図２を参照すると、ルータ２００は、経路指定情報プロトコルすなわちＲＩＰをサポートし、ＳＮＭＰ交信可能であり、ルータ２０４、２０８、および２１２は、最適経路制御プロトコルすなわちＯＳＰＦプロトコルをサポートし、ＳＮＭＰ交信可能であり、ルータ２１６は、ＯＳＰＦをサポートするがＳＮＭＰ交信可能ではなく、最後に、ルータ２２０は、ＯＳＰＦおよびＲＩＰをサポートし、ＳＮＭＰ交信可能である。トポロジ発見アルゴリズムは、最初にルータ２００と交信する場合は、ホップバイホップ手法により、ルータ２００、２２０および２１６と交信することができる。アルゴリズムがルータ２１６と交信すると、このルータはＳＮＭＰ交信可能ではないので、アルゴリズムはルータ２０４、２０８、および２１２と交信することができない。アルゴリズムがルータ２１６にあるＭＩＢ情報にアクセスすることができず、それによってアルゴリズムはこうしたルータの存在を知ることを妨げられるので、このようなことになる。
ＲＦＣ１８５０ ＩＥＴＦのＲＦＣ１２１３標準 Ｇｏｒｉｎｇｅらの米国特許出願第１０／１２７，９６７号「ＵＳＩＮＧ ＬＩＮＫ ＳＴＡＴＥ ＩＮＦＯＲＭＡＴＩＯＮ ＴＯ ＤＩＳＣＯＶＥＲ ＩＰ ＮＥＴＷＯＲＫ ＴＯＰＯＬＯＧＹ」 Ｇｏｒｉｎｇｅらの米国特許仮出願第６０／３１７，７１９号「ＵＳＩＮＧ ＬＩＮＫ ＳＴＡＴＥ ＩＮＦＯＲＭＡＴＩＯＮ ＴＯ ＤＩＳＣＯＶＥＲ ＩＰ ＮＥＴＷＯＲＫ ＴＯＰＯＬＯＧＹ」

こうしたおよび他の必要性は、本発明の様々な実施形態および構成によって対処される。全般的には、本発明のアーキテクチャは、ネットワーク・トポロジを発見するのに様々なトポロジ発見技術を使う。こうした異なる発見技術は、ネットワーク管理プロトコルに特有かつ／または経路指定プロトコルに特有である場合がある。ネットワーク管理プロトコル特有の発見アルゴリズムを使うと、アルゴリズムの発見を認知できない（またはそれに反応しない）場合がある。

企業ネットワークまたは自律システムにとって特に有用な一実施形態では、ホップバイホップの発見アルゴリズム、たとえばＳＮＭＰトポロジ発見技術が、他の１つまたは複数の発見アルゴリズム、たとえばＯＳＰＦ発見アルゴリズム、独自の標準に基づく発見アルゴリズム、およびベンダ独自のトポロジ発見アルゴリズムと組み合わされて、トポロジ発見を実施する。こうしたトポロジ発見機構は通常、経路指定プロトコルに反応するように設計される。このことは、ホップバイホップの手法によって可能となる。この手法では、各ルータが交信されて、交信されたルータに既知である、ネットワーク内の他のエンティティを見つけ出す。各ルータは交信され、次いで様々なネットワーク・エンティティおよびそのトポロジ接続に関するデータベースを構築する。

ルータは、ホップバイホップ方法によって発見されると常に、その経路テーブルを定義するのにどのプロトコルが使われたか識別するために問合わせを受ける。こうしたプロトコルが、関連づけられた特定の発見アルゴリズムを有する場合、対応する発見アルゴリズムが実行される。見つけられたどの追加データも、ネットワーク・モデルに追加され、発見されたどの追加ルータも、さらなる探索のためにホップバイホップ・アルゴリズムにとって利用可能となる。代替発見アルゴリズム（群）を用いて発見されたルータは、図２のルータ２１６などの交信不可能なルータを「飛び越える」のに使うことができる。図２を参照すると、ＳＮＭＰ発見アルゴリズムに加えてＯＳＰＦトポロジ発見アルゴリズムを使うことにより、ルータ２０４、２０８、２１２、および２１６のどれにあるＯＳＰＦ領域情報も開示することになる。領域情報は、交信不可能なルータ２１６が存在することを識別するが、他の情報を演繹することはできない。

別の実施形態では、本アーキテクチャは、いくつかの発見エージェントを用いて、異なる様々な経路指定プロトコルを実行する異種ネットワークを発見する。各発見エージェントは、１つまたは複数の経路指定プロトコルによって定義されたルータ情報と相互作用するように構成される。こうした様々な発見エージェントは、個別のフェーズにおいて、並列にまたはルータバイルータ・ベースで動作することができる。

本発明のアーキテクチャには、いくつかの利点があり得る。たとえば、異なる発見技術の使用により、ネットワーク構成要素が様々なプロトコルをサポートするとしても、ネットワーク構成要素を位置決めすることができる。この利点は、ＭＩＢおよびＯＳＰＦ発見技術の両方を使うアーキテクチャの構成を参照して示すことができる。本明細書では、「ＭＩＢ」は管理情報ベースのすべてのバージョンを指し、「ＳＮＭＰ」は簡易ネットワーク管理プロトコルのすべてのバージョンを指し、「ＯＳＰＦ」はＯＳＰＦプロトコルのすべてのバージョンを指すものとみなす。ＭＩＢ発見の利点は、どのような経路指定プロトコルが存在するかに関わらず、ＩＰネットワーク・トポロジが発見されることである。この手法の欠点は、ネットワーク全体を発見するためにＭＩＢ発見エージェントがネットワーク内の各ルータを訪れなければならないことである。図２を参照して上述したように、ルータがＳＮＭＰを介して交信することができない場合、ＭＩＢ発見エージェントは、ネットワークのサブセットのみを発見する。ＯＳＰＦ発見のみを使うと、ＯＳＰＦ経路指定プロトコルを実行しているネットワークの部分が発見されるだけである。ただし、ＯＳＰＦ発見技術は、少数のルータ（たとえば、区域境界ルータ）と交信するだけでネットワークの大部分の領域を素早く識別することができ、そうすることによって、このような技術は交信不可能なルータを横断しないようになる。したがって、ＯＳＰＦは各ルータを訪れることなくネットワーク・トポロジを判定することができるので、ＯＳＰＦ発見は、ＭＩＢ発見では見つけることができなかったルータを見つけることができる。具体的には、ＯＳＰＦは、図２を参照して上述したように、ＭＩＢ発見を阻止する交信不可能なルータにより到達不可能なネットワークの一部を発見することができる。２つの発見技術を併せて使うことにより、ＭＩＢ発見は、ネットワークに存在する経路指定プロトコルに関わらず、ネットワーク内のすべての交信可能なルータおよび交信不可能なルータを見つけることが可能になる。交信可能でないネットワーク部分はしばしば、ＭＩＢ発見による後の発見のために交信不可能なルータを「飛び越える（ｈｏｐ ｏｖｅｒ）」ＯＳＰＦ発見を使って発見することができる。
こうしたおよび他の利点は、本明細書に含まれる本発明（群）の開示によって明らかになるであろう。

上述した実施形態および構成は完全なものでも、網羅するものでもない。本発明の他の実施形態は、上述したまたは以下で詳細に述べる特徴の１つまたは複数を、単独でまたは組み合わせて使用することによって可能となることが理解されよう。

様々な経路指定プロトコルが存在するネットワークのトポロジを発見するために、フェーズ式の発見手法が利用される。３つの主なフェーズが、ネットワーク・トポロジを発見するのに必要とされる。初期ゲートウェイ検出フェーズでは、アーキテクチャは、シード・ルータと交信して発見処理を開始する。ＭＩＢまたはＭＩＢ２発見フェーズでは、アーキテクチャは、企業ネットワーク内のルータそれぞれと交信して、ルータ内の選択されたＭＩＢ情報をダウンロードする。ＯＳＰＦ発見フェーズでは、アーキテクチャは、ＯＳＰＦをサポートするルータと交信して、ＯＳＰＦルータ内のリンク状態広告データベースからリンク状態広告をダウンロードする。

データ収集／分析エージェント２０８の動作を説明する前に、多くの経路指定プロトコルの特定の特徴を理解されたい。ルータは、特定のプロトコルの場合には一義的なルータＩＤによって識別することができ、一義的な領域ＩＤに関連づけることができる。ルータは通常、それ自体ではＩＰアドレスをもたない。インターフェースは、リンクの接続ポイントであるというよりは、ルータなどのホストに属す論理装置である。一般に、インターフェースは、ゼロまたは１つのＩＰアドレスをもち、ネットワークに属す。インターフェースは、通常はインターフェース番号およびネットワーク・マスクを有する。リンクは、送信元インターフェースの２つ以上の束縛および算出法またはコストを含む。リンクは、経路指定プロトコルに特有であるとともにパケットがインターフェースから離れるためのコストを表す算出法の表現によってテンプレートされる。リンクは通常、コスト算出法および経路指定プロトコル識別子に関連づけられる。ネットワーク・オブジェクトとは、データ・ネットワークまたはサブネットを表す。このオブジェクトは、アドレスおよびマスクを有し、１組のホストが含まれるアドレス空間を表す。ネットワーク・オブジェクトは、メンバーであるインターフェースからそのアドレスおよび／またはマスクを導き出すことができる。

ネットワーク・トポロジ発見システム
以上のことを念頭に置き、図３は、本発明の実施形態によるネットワーク・トポロジ発見システム３００を示す。システム３００は、コンピュータ・ネットワークのアクセス・ポイント、たとえばスタブ・ネットワーク１１２に接続されるように、かつホスト、通常はルータとの間で送受信を行うように構成される。システム３００は、３つのフェーズそれぞれの実行を適切な順序で監督していつ発見処理が完了したか判定するように構成されたフェーズ・コントローラ３０４と、ＭＩＢ発見フェーズにおいて、交信可能な各ルータ内のＭＩＢ情報にアクセスしてネットワーク・トポロジの一部を記述するＭＩＢ出力を生成するように構成されたＭＩＢ発見エージェント３０８と、ＯＳＰＦ発見エージェント３１０とを備え、ＯＳＰＦ発見エージェント３１０は、ＯＳＰＦ発見フェーズにおいて、所望の各経路指定領域中の選択されたルータと交信することによって、ネットワーク・トポロジに関する選択された情報を集めるように構成されたＯＳＰＦデータ収集エージェント３１２と、ＯＳＰＦ発見フェーズにおいて、ＯＳＰＦデータ収集エージェント３１２によって集められた情報を分析してネットワーク・トポロジの一部を記述するＯＳＰＦ出力を生成するように構成されたＯＳＰＦデータ分析エージェント３１６とを含む。

トポロジ発見の間、システム３００は、計算の重複を避けるためにいくつかの一覧（未確定リスト、完了リスト、初期ゲートウェイ・リスト、区域境界ルータ・テーブル（図示せず）、およびリンク状態広告テーブル（図示せず））を維持する。未確定リスト３２０（図１２）は、まだ交信されていない候補ホストの（インターフェース）アドレス１２００を列挙する。ＭＩＢ発見フェーズおよびＯＳＰＦ発見フェーズの間、新規のルータのインターフェース・アドレスが発見されると、未確定アドレス・リスト３２０に追加される。ＭＩＢ発見フェーズは通常、未確定リストから第１のアドレスをはずし、そのインターフェース・アドレスが接続されるルータを探索する。完了リスト３２４（図１３）は、交信されたことがあり、再度交信する必要がないホストの（インターフェース）アドレス１３００を列挙する。未確定アドレス・リストにあるルータ・インターフェースが処理された後、対応するルータのインターフェース・アドレスは、未確定リストから完了リストに移される。初期ゲートウェイ・リスト３２８（図１１）は、ＭＩＢ発見エージェント３０８の動作中に発見される、（以下で説明するルータ・テーブル中の該当するルータ・エントリへのポインタによって）ＯＳＰＦルータ１１００、および（以下で説明するインターフェース・テーブル中の該当するインターフェース・エントリへのポインタによって）対応するインターフェース（群）１１０４を列挙する。こうしたルータは、ＯＳＰＦ発見フェーズ中に探索される。区域境界ルータ・テーブルは、ＯＳＰＦ発見エージェント３１０の動作中に発見されたＯＳＰＦ区域境界ルータを列挙し、各ルータ・エントリごとに、ルータが交信されたことがあるかどうかという指示と、交信されたことがある場合にはその結果とを含む。最後に、リンク状態広告テーブルは、ＯＳＰＦデータ収集エージェント３１２によって出力され、交信されたＯＳＰＦルータ内のリンク状態データベースから取得されたリンク状態広告すなわちＬＳＡの一覧である。リンク状態データベースは、ＯＳＰＦプロトコルによって定義されるように、各リンクが、そのリンクに関連づけられたエンド・ポイントおよびコスト算出法によって定義されるリンクの一覧であることが理解されよう。経路指定領域内部の各区域境界ルータは、その境界上にルータが位置する（または区域境界ルータが関連づけられる）すべての領域に対してデータベースの完全なコピーを有する。しかし、１つの経路指定領域内部の非区域境界ルータは通常、そのルータが置かれた領域においてデータベースの完全なコピーを有し、異なる経路指定領域内のルータと同じリンク状態データベースはもたない。

システム３００は、ＭＩＢ発見フェーズが完了した後でＭＩＢ発見エージェント３０８によって出力されるいくつかの出力テーブル、すなわちルータ・テーブル３３２、ネットワーク・インターフェース・テーブル３３６、およびインターフェース・テーブル３４０と、ＯＳＰＦ発見フェーズが完了した後でＯＳＰＦ発見エージェント３１０によって出力される、ルータ・リスト３４４、リンク・リスト３４８、ネットワーク・リスト３５２、およびインターフェース・リスト３５６とを提供する。図８を参照すると、ルータ・テーブル３３２は、発見された各ルータ８００ごとに、対応するプロトコル識別子８０４、および１つまたは複数の対応する接続されたインターフェース８０８（通常、インターフェース・テーブル３４０中の対応するエントリへのポインタによって識別される）を含む。図９を参照すると、インターフェース・テーブル３４０は、各インターフェース９００ごとに、対応するＩＰアドレス９０４、１つまたは複数の対応する属性９０８（たとえば、インターフェースが交信可能であったか、速度、インターフェースのタイプ、コスト算出法、動作可能／不可能状況など）、およびインターフェースを所有する対応するルータ９１２（通常、ルータ・テーブル３３２中の対応するエントリへのポインタによって識別される）を含む。図１０を参照すると、ネットワーク・インターフェース・テーブル３３６は、各ネットワーク・アドレス１０００（または他のタイプのネットワーク識別子）ごとに、ネットワークに接続される１つまたは複数の対応するインターフェース１００４（通常、インターフェース・テーブル３４０中の対応するエントリへのポインタによって識別される）を列挙する。図１４を参照すると、ルータ・リスト３４４は、企業ネットワークまたは自律システムにおいて指定され接続されたルータ１４００の包括的な一覧を含む。こうしたルータは、ルータＩＤ１４０４（および／またはルータのインターフェースのＩＰアドレス（図示せず）の１つによって）、関連づけられた領域識別子１４０８、および／またはインターフェース・リスト中の関連づけられたインターフェースを指す１つまたは複数のポインタ１４１２によって識別される。区域境界ルータは複数の領域ＩＤを有し、非区域境界ルータはただ１つのＩＤを有し、ルータは、１つまたは複数の関連づけられたインターフェースを有することができることが理解されよう。図１５を参照すると、リンク・リスト３４８は、発見されたリンクを列挙する。リンク１５００は、エンド・ポイント１５０４として、２つのルータ、または１つのルータおよび１つのネットワーク（スタブまたは中継）をもつことができる。ルータは、ルータＩＤおよび／またはインターフェースのＩＰアドレスによって識別することができ、ネットワークは、マスクおよび／または１つもしくは複数のＩＰアドレスによって識別することができる。図１６を参照すると、ネットワーク・リスト３５２は、ネットワーク１６００（スタブまたは中継）の一覧である。ネットワーク１６００は、ネットワーク・アドレスならびにネットワーク・マスク、および／またはネットワークに接続される１つもしくは複数のＩＰアドレスによって識別される。各ネットワークは、関連づけられた１組のルータ・インターフェース１６０４（通常、インターフェース・リスト中の対応するルータ・インターフェースへのポインタによって示される）、および関連づけられた指定ルータ１６０８（通常、ルータ・リスト中の対応するルータへのポインタによって示される）を有する。最後に図１７を参照すると、インターフェース・リスト３５６は、ＩＰアドレス、インターフェース番号、および／またはネットワーク・マスクによって識別されるインターフェース１７００を列挙する。各インターフェース１７００は、ルータ１７０４に関連づけられる。関連づけられたルータ１７０４は通常、ルータ・リスト３４４中の対応するルータへのポインタによって示される。

こうしたテーブルはまとまって、ネットワークの経路指定トポロジ、およびそこで表されるネットワーク要素の属性を提供する。「経路指定トポロジ」は、ある特定の経路指定プロトコルによって記述される論理的なネットワーク・トポロジを指すことが理解されよう。経路指定トポロジのマップまたはモデルは、ルータ・テーブル、インターフェース・テーブル、ネットワーク・インターフェース・テーブル、ルータ・リスト、リンク・リスト、ネットワーク・リスト、およびインターフェース・リストに基づいて、自動的にまたは手作業で生成することができる。複数の経路指定プロトコルが使われる場合、複数の異なる経路指定トポロジがあり得る。経路指定トポロジは、物理的なネットワーク・トポロジとはかなり異なり得ることが理解されよう。

フェーズ・コントローラの動作
ここで、図４を参照してフェーズ・コントローラ３０４の動作を説明する。
ステップ４００でのフェーズ・コントローラ３０４の作成後、フェーズ・コントローラ３０４は、ステップ４０４で初期ゲートウェイ検出を実施する。フェーズ・コントローラは通常、１つまたは複数のシードＩＰアドレスを使ってホスト・ルータと交信する。フェーズ・コントローラ３０４によって最初に交信されたルータ（群）は通常、ゲートウェイ・ルータ（群）と呼ばれる。好ましい実装形態では、ただ１つのシードＩＰアドレスが利用される。ユーザがある特定のルータを初期ゲートウェイとして使うようにフェーズ・コントローラを構成しなかった場合、シード・ルータは自動的に決定することができる。この決定を行う方法は、プラットフォーム依存である。すべてのプラットフォームに対して、ゲートウェイは、有効なゲートウェイ・フィールドを有する第１の経路指定テーブル・エントリから取り出される。ゲートウェイ・ルータと交信するのに使われる簡易ネットワーク管理プロトコルすなわちＳＮＭＰ技術は、経路指定プロトコルに特有でよい。たとえば、ＲＦＣ１８５０は、ＯＳＰＦプロトコルを用いてルータと交信するための仕様を提供する。フェーズ・コントローラ３０４は、ステップ４０８で、初期ゲートウェイ・ルータと交信しようと試みる。

判断ブロック４１２で、フェーズ・コントローラ３０４は、ＳＮＭＰ技術を用いてゲートウェイ・ルータがうまく交信されたか判定する。交信の試みが成功しなかった場合、フェーズ・コントローラは、ステップ４１６で動作を終了し、ユーザに誤りを通知してさらにシード・ルータを要求する。交信の試みが成功した場合、フェーズ・コントローラはステップ４２０で、初期ゲートウェイ・ルータ内のＭＩＢ情報にアクセスし、ステップ４２４で、未確定リストおよび完了リストを初期化して、ゲートウェイ・ルータの交信可能インターフェースのインターフェース・アドレスを、ＭＩＢ発見フェーズにおいて後で使うために未確定リストに追加する。

フェーズ・コントローラは次いで、ステップ４２８で、ＭＩＢ発見エージェント３０８を呼び出し、エージェントにＭＩＢ発見フェーズを実施させる。ＭＩＢ発見エージェントの動作は、図５および６を参照して以下で説明する。

ＭＩＢ発見フェーズが完了すると、フェーズ・コントローラは、ステップ４３２でＯＳＰＦ発見エージェント３１０を呼び出して（または最初にＯＳＰＦデータ収集エージェント３１２を、次いでＯＳＰＦデータ分析エージェント３１６を直接呼び出して）、ＯＳＰＦ発見フェーズを実施する。こうしたエージェントの動作は、図７を参照して以下で説明する。フェーズ・コントローラは、オブザーバ・パターンを用いてＭＩＢ発見エージェントおよびＯＳＰＦ発見エージェントの進行を監視することができる（または、ＯＳＰＦデータ収集エージェントおよびＯＳＰＦデータ分析エージェントを直接呼び出す）。

ＯＳＰＦ発見フェーズが完了すると、フェーズ・コントローラは、判断ブロック４３６で未確定リスト３２０が空であるか判定する。候補エントリ１２００が未確定リスト３２０に残っている場合、フェーズ・コントローラは、ステップ４２８および４３２を繰り返す。候補エントリ１２００が未確定リスト３２０に残っていない場合、フェーズ・コントローラは、ステップ４４０に進んで動作を終了させる。

ＭＩＢ発見エージェントの動作
ここで、ＭＩＢ発見エージェント３０８の動作を、図５および６を参照して説明する。全般的には、ＭＩＢ発見エージェント３０８は、次のインターフェース・アドレスを未確定リスト３２０から反復して取り出し、そのインターフェース・アドレスに対応するルータと交信し、ルータの経路指定テーブルを処理し、次いでインターフェース・アドレスを未確定リスト３２０から完了リスト３２４に移動させる。不必要なネットワーク・トラフィックおよび計算資源の浪費を避けるために、ＭＩＢ発見エージェントは好ましくは、ルータのある１つのインターフェースがうまく交信されると、そのルータの他のインターフェースがその後でＭＩＢ発見エージェントによって交信されないように構成される。

ＭＩＢ発見エージェント３０８は、ステップ５００で作成される。判断ブロック５０４で、ＭＩＢ発見エージェント３０８は、未確定リスト３２０が空であるか判定する。リスト３２０が空である場合、エージェント３０８は動作をやめ、フェーズ・コントローラはＯＳＰＦデータ収集エージェント３１２を作成する。リスト３２０が空でない場合、エージェント３０８はステップ５０８に進み、未確定リスト３２０にある次のインターフェース・アドレスを入手する。

ステップ５１２で、エージェント３０８はインターフェース・アドレスに交信し、判断ブロック５１６で、エージェント３０８はそのアドレスが交信可能であったか判定する。アドレスが交信可能でなかった場合、エージェントはステップ５２０に進み、そこでインターフェース・アドレスが未確定リスト３２０から完了リスト３２４に移され、エージェントは判断５０４に戻ってループを再度反復する。アドレスがうまく交信されると、エージェント３０８は、図６を参照してさらに説明するように、ステップ５２４でルータを処理する。

ここで、図６を参照して、ＭＩＢ発見エージェントによるルータの処理を説明する。
ステップ６００で、ＭＩＢ発見エージェント３０８は、アドレスがうまく交信されたことを示す、インターフェース・アドレスに関連づけられたフラグをセットする。このフラグは、未確定リストに含めることができる。

ステップ６０４で、エージェント３０８は、交信されたインターフェース・アドレスに対応するルータに接続されたインターフェース・アドレスのリストを取り出す。この情報は、ルータのＳＮＭＰテーブルに含まれる。エージェントによって取り出されたＳＮＭＰテーブルは、ＩＥＴＦのＲＦＣ１２１３標準において定義されるｉｐＡｄｄｒテーブル、ｉｐＡｄｄｒＴａｂｌｅテーブル、ｉｐＲｏｕｔｅＴａｂｌｅテーブル、およびｉｐＲｏｕｔｅＥｎｔｒｙテーブル（「テーブル」）である。ｉｐＡｄｄｒテーブルは、ルータのインターフェースのＩＰアドレスを列挙することが理解されよう。ｉｐＲｏｕｔｅＴａｂｌｅテーブルは、現在のルータにおける各インターフェースが、どのようにしてネットワーク内の別のルータにおけるインターフェース（次のホップのインターフェースとも呼ばれる）に接続されるか判定するのに使うことができる。このテーブルはまた、２つのルータ・インターフェースの間のリンク上に存在するＯＳＰＦなどの経路指定プロトコルを記述する。

ステップ６０８で、エージェントは、（処理中の）ルータに対応する次のインターフェース・アドレスを、処理するために取り出す。このアドレスを処理する前に、エージェントは、判断ブロック６１２で、取り出されたアドレスが未確定リスト３２０にあるか判定する。取り出されたアドレスが未確定リスト３２０にある場合、このアドレスは、ステップ６１６で、未確定リスト３２０から完了リスト３２４に移される。この後で、または取り出されたアドレスが未確定リスト３２０にない場合は、エージェント３０８は次いで、ステップ６２０に進む。

ステップ６２０で、エージェント３０８は、処理中のルータの現在のインターフェースに接続された、次のホップのインターフェースのアドレスを取り出す。次のホップのインターフェースに関連づけられた情報に基づいて、１つまたは複数のエントリが、ネットワーク・インターフェース・テーブル３３６、インターフェース・テーブル３４０、および／またはルータ・テーブル３３２に追加される。初期化が済んでいない場合、テーブルはエントリの追加の前に初期化される。

ステップ６２４でテーブル中の次のホップのインターフェース・アドレスを処理するために使われる技術は、ＳＮＭＰを熟知している当業者には公知であろう。ｉｐＡｄｄｒＴａｂｌｅ：：ｉｐＡｄＥｎｔＩｆＩｎｄｅｘは、ｉｐＡｄｄｒＴａｂｌｅテーブル中の各インターフェース・アドレスの列挙へのキーとして作用することが理解されよう。図２４に示すように、ｉｐＲｏｕｔｅＥｎｔｒｙテーブルは、（ｉｐＲｏｕｔｅＥｎｔｒｙ：：Ｉｎｓｔａｎｃｅにおいて）ｉｐＲｏｕｔｅＥｎｔｒｙ：：ｉｐＲｏｕｔｅＩｆＩｎｄｅｘを外部キーとして用いて、ｉｐＡｄｄｒＴａｂｌｅテーブルに結合される。この関係は、ｉｐＡｄｄｒＴａｂｌｅとｉｐＲｏｕｔｅＥｎｔｒｙテーブルの間の１対多の関係を表す。各ｉｆＡｄｄｒＥｎｔｒｙごとに、どのネットワークにインターフェースが接続されるか、およびそのネットワークに到達するのにどのインターフェースが使われるかを（ｉｐＲｏｕｔｅＥｎｔｒｙ：：ｉｐＲｏｕｔｅＮｅｘｔＨｏｐを用いて）記述する、０以上のｉｐＲｏｕｔｅＥｎｔｒｙがある。ｉｐＲｏｕｔｅＥｎｔｒｙがない場合、そのインターフェースは使われていない。

テーブルは、転送ネットワークとスタブ・ネットワークを区別するのに使うことができる。パケットが、交信されたインターフェースからそのネットワークに直接移ることができる（またはインターフェースがネットワークに直接接続される（これは、ｉｐＲｏｕｔｅＴｙｐｅフィールドの「ｄｉｒｅｃｔ」という指定によって確認される））場合、そのネットワークは、スタブ・ネットワークであると仮定される。パケットが、別のネットワークに到達するために、交信されたインターフェースからネットワークを介して移らなければならない（または、そのインターフェースが、ｉｐＡｄｄｒＴａｂｌｅテーブル中に列挙されたエンド・ポイント・ネットワークに間接的に接続される（これは、ｉｐＲｏｕｔｅＴｙｐｅフィールドの「ｉｎｄｉｒｅｃｔ」という指定によって確認される））場合、その中間にあるネットワークは転送ネットワークである。

番号のついていないインターフェースも検討しなければならない。番号のついていないインターフェースの場合、ｉｐＴａｂｌｅ中に表れるがｉｐＡｄｄｒｅｓｓＴａｂｌｅ中に表れず、ｉｐＴａｂｌｅ中に「動作可能」状況をもち、イーサネット（登録商標）・インターフェースではないという基準を満たさなければならない。番号のついていないインターフェースは、ポイント−リンク間を用いて別のルータに、および次のルータの番号のついていない別のインターフェースに常に接続される。この場合、現在のルータにおけるｉｐＲｏｕｔｅＴａｂｌｅは、次のルータの任意の（番号つきの）インターフェース・アドレスとして、番号のついていないインターフェースの次のホップのアドレスをもつ。

図１８〜２１は、ｉｐＡｄｄｒＴａｂｌｅテーブル、ｉｐＲｏｕｔｅＥｎｔｒｙテーブル、およびｉｐＲｏｕｔｅＴａｂｌｅテーブルを示す。図１８は、ｉｐＡｄｄｒＴａｂｌｅテーブルであり、各インスタンス１８００ごとに、ｉｐＡｄＥｎｔＡｄｄｒ（ＩＤＸ）１８０４、ｉｐＡｄＥｎｔＩｆＩｎｄｅｘ１８０６およびｉｐＡｄＥｎｔＮｅｔＭａｓｋ１８０８を含む。「インスタンス」とは、インターフェースのＩＰアドレスの出現を指すことが理解されよう。図１９は、ｉｐＲｏｕｔｅＥｎｔｒｙテーブルであり、各インスタンス１９００ごとに、ｉｐＲｏｕｔｅＤｅｓｔ（ＩＤＸ）１９０４、ｉｐＲｏｕｔｅＩｆＩｎｄｅｘ１９０８、ｉｐＲｏｕｔｅＮｅｘｔＨｏｐ１９１２、ｉｐＲｏｕｔｅＴｙｐｅ１９１６、ｉｐＲｏｕｔｅＰｒｏｔｏ１９２０すなわち対象のインターフェースと次のホップのアドレス１９１２の間の接続によってサポートされる経路指定プロトコル、およびｉｐＲｏｕｔｅＭａｓｋ１９２４を含む。図２０は、ｉｐＡｄｄｒテーブルであり、各インスタンス２０００ごとに、図１８のｉｐＡｄｄｒＴａｂｌｅテーブルと同じ変数を含む。最後に、図２１は、ｉｐＲｏｕｔｅＴａｂｌｅテーブルであり、各インスタンス２１００ごとに、ｉｐＲｏｕｔｅＥｎｔｒｙテーブルと同じ変数を含む。

上記のテーブルの使い方を説明するために、ここでいくつかの例を図１８〜２１のテーブルに基づいて説明する。ｉｆＡｄｄｒＥｎｔｒｙテーブル（図１８）中のインターフェース・アドレス１９２．１６８．３４．１すなわちインスタンス１８１２は、４という索引をもち、ｉｐＲｏｕｔｅＥｎｔｒｙテーブル（図１９）中の３つの結合されたエントリ１９０２、１９２８および１９２９をもつ。エントリ１９２８を見ると、ネットワーク１９２．１６８．３４．０は、１９２．１６８．３４．１インターフェースから到達できることを示す。このことは、このインターフェース・アドレスが３４．１で終わるクラスＣアドレスであり、ｉｐＲｏｕｔｅＴｙｐｅフィールドの値「Ｄｉｒｅｃｔ（３）」によって確認されるので論理的である。このインターフェースはしたがって、１９２．１６８．３４．０ネットワークに直接接続され、それ以上の情報なしで、このネットワークはスタブ・ネットワークであると仮定される。第３のエントリ１９２９は、ネットワーク１９２．１６８．３５．０は、インターフェース１９２．１６８．３４．２を介して到達することができるが、エントリ１９１６で示されるように、ｉｐＲｏｕｔｅＴｙｐｅフィールド「ｉｎｄｉｒｅｃｔ（４）」によって指定されるように間接的にしか接続されないことを示す。このネットワークへの第１のホップであるルータは、ｉｐＲｏｕｔｅＮｅｘｔＨｏｐフィールドによって指定されるように、次のホップのインターフェース１９２．１６８．３４．２によって到達することができる。１９２．１６８．３５．０ネットワークに到達するためには、パケットは１９２．１６８．３４．０ネットワークを介して移らなければならず、１９２．１６８．３４．０ネットワークは転送ネットワークと定義される。３４．０ネットワークはスタブ・ネットワークであると以前に仮定されたので、ここで転送ネットワークであると更新する必要がある。インターフェース１９２．１６８．３４．２を有するルータにおけるｉｆＡｄｄｒＥｎｔｒｙテーブル（図２０を参照）およびｉｆＲｏｕｔｅＥｎｔｒｙテーブル（図２１を参照）の検査において、ルータは、１９２．１６８．３５．１インターフェースを介して１９２．１６８．３５．０ネットワークに接続される（図２１の最後のエントリを参照）ことがわかる。これは、ｉｆＡｄｄｒＥｎｔｒｙ中の１９２．１６８．３５．１インターフェース（図２０のエントリ２００２）およびｉｆＲｏｕｔｅＥｎｔｒｙ（ｉｐＲｏｕｔｅＩｎｄｅｘ＝７）（図２１のエントリ１９０８）中の対応する行によって判定される。ｉｐＲｏｕｔｅＴｙｐｅフィールド１９１６は、この接続は「ｄｉｒｅｃｔ（３）」であると指定し、このインターフェースが３５．０ネットワークに直接接続されることを示す。１９２．１６８．３４．２ルータ・テーブル（図２１）も、このルータはインターフェース１９２．１６８．１７．２を介して１７．０ネットワーク（図２１の上から３番目のエントリを参照）に直接接続されることを示す。

図１８に戻ると、やはり探索可能な他の３つのインターフェースがある。これらは、１９２．１６８．１６．１００（オリジナル・ゲートウェイ・インターフェース）、１９２．１６８．１９．２および１９２．１６８．２９．２インターフェースである。こうしたインターフェース用に結合される図１９のｉｐＲｏｕｔｅＥｎｔｒｙテーブルのエントリは、このルータが、（ｉ）１９２．１６８．１６．１００インターフェースを介して直接１９２．１６８．１６．０ネットワークに、（ｉｉ）１９２．１６８．１９．２．インターフェースを介して直接１９２．１６８．１９．０ネットワークに、（ｉｉｉ）１９２．１６８．１９．２インターフェースを介して間接的に１９２．１６８．１８．０ネットワークに（また、次のホップのインターフェースは新規に発見されたルータの１９２．１６８．１９．１である）、および（ｉｖ）１９２．１６８．２９．２インターフェースを介して直接１９２．１６８．２９．０ネットワークにも接続されることを示す。
図１８〜２１の上述の分析に基づくネットワーク・トポロジを、図２２に示す。

図６に再度戻ると、エージェント３０８は、ステップ６２８で、現在のインターフェースと次のホップのアドレスの間の接続がＯＳＰＦを使うかどうか判定する。これは、図１９および／または２１のｉｐＲｏｕｔｅＰｒｏｔｏ１９２０エントリに基づいて判定される。接続がＯＳＰＦをサポートする場合、ステップ６２９でＯＳＰＦプロトコル識別子がルータ・テーブル３３２に追加され、ステップ６３０でインターフェース・アドレスが、ＯＳＰＦ発見フェーズにおける以降の探索のために初期ゲートウェイ・リスト３２８に追加される。どちらのイベントでも、エージェント３０８は次に判断ブロック６３２に進む。

判断ブロック６３２で、エージェント３０８は、次のホップのアドレスが未確定リスト３２０または完了リスト３２４にあるか判定する。次のホップのアドレスがどちらのリストにもない場合、次のホップのアドレスはステップ６３６で未確定リスト３２０に追加される。どちらのイベントでも、エージェント３０８は判断ブロック６４０に進む。

判断ブロック６４０で、エージェント３０８は、交信されるルータに接続された、まだ検討されていない別のインターフェース・アドレスがあるか判定する。別のアドレスがまだ検討されていない場合、エージェント３０８はステップ６０８に戻り、上記のステップをそのアドレスに対して繰り返す。検討すべきアドレスが残っていない場合、エージェント３０８は図５のステップ５２０に進む。

ＯＳＰＦデータ収集エージェントおよびデータ分析エージェントの動作
ここで、ＯＳＰＦ分析収集エージェント３１２およびデータ発見エージェント３１６の動作を、図７を参照して説明する。一般に、初期ゲートウェイ・リスト３２８中のインターフェース・アドレスはそれぞれ、ＯＳＰＦ発見フェーズにおいて、ＯＳＰＦデータ収集エージェント３０８用の初期ゲートウェイの開始点として使われる。前のＯＳＰＦ発見の実行によって発見されたＯＳＰＦルータは、後に続くＯＳＰＦデータ収集エージェント３１２の実行における初期ゲートウェイの開始点として使う必要はない。

図７を参照すると、フェーズ・コントローラ３０４は、ステップ７００で初期ゲートウェイ・リスト３２８を取り出し、ステップ７０４で、ＯＳＰＦ発見において処理するための、リスト３２８にある次のルータ（またはこのルータに接続された第１のインターフェース・アドレス）を入手する。フェーズ・コントローラは次いで、ステップ７０８でＯＳＰＦ発見の初期ゲートウェイを第１のインターフェース・アドレスに設定し、ステップ７１２でＯＳＰＦデータ収集エージェント３１２を作成し、次いでステップ７１６でＯＳＰＦデータ分析エージェント３１６を作成する。データ収集エージェント３１２およびデータ分析エージェント３１６の動作は、どちらも参照によって本明細書に組み込まれる、本出願と同時に出願されたＧｏｒｉｎｇｅらの米国特許出願第１０／１２７，９６７号「ＵＳＩＮＧ ＬＩＮＫ ＳＴＡＴＥ ＩＮＦＯＲＭＡＴＩＯＮ ＴＯ ＤＩＳＣＯＶＥＲ ＩＰ ＮＥＴＷＯＲＫ ＴＯＰＯＬＯＧＹ」、および２００１年９月６日出願のＧｏｒｉｎｇｅらの同じタイトルの米国特許仮出願第６０／３１７，７１９号で説明されている。

上記の出願において説明されているように、データ収集エージェント３１２は、シード・インターフェースＩＰアドレスを使って選択された経路指定領域内のホスト・ルータと交信する、交信されたホスト・ルータのリンク状態データベース中のｏｓｐｆＬｓｄｂテーブルをダウンロードし、対象領域（群）の外のどのリンク状態広告も破棄し、区域境界ルータに関連づけられた各インターフェースのＩＰアドレスを区域境界ルータ・テーブルに追加し、対象領域（群）用のどのＬＳＡもリンク状態広告テーブルに追加する。こうしたステップは、各区域境界ルータごとに繰り返される。

データ分析エージェント３１６は、リンク状態広告テーブルを横断してタイプ１およびタイプ２以外のすべてのリンク状態広告を破棄し、タイプ１およびタイプ２のリンク状態広告を使ってルータ・リスト３４４（図１４）（これは、対象領域において発見されたすべてのＯＳＰＦルータを含む）、リンク・リスト３４８（図１５）、ネットワーク・リスト３５２（図１６）、および／またはインターフェース・リスト３５６（図１７）を形成する。

データ収集エージェント３１２およびデータ分析エージェント３１６の動作が完了した後、フェーズ・コントローラ３０４は、ステップ７２０で、発見されたすべてのＯＳＰＦルータを初期ゲートウェイ・リスト３２８から削除する。データ収集エージェント３１２は、発見された各ＯＳＰＦルータごとに、フラグをセットできることが理解されよう。

ステップ７２４で、フェーズ・コントローラは、データ収集エージェント３１２およびデータ分析エージェント３１６によって見つけられたすべてのルータ・インターフェース・アドレスを取り出して、ＭＩＢ発見フェーズ動作がさらに必要か確かめる。この判定は、ＯＳＰＦ発見中に発見されＭＩＢ発見では発見されなかったどのルータ・インターフェース・アドレスのＭＩＢ発見エージェント３０８による検討も確実にするために行われる。この目的のために、フェーズ・コントローラ３０４は、ステップ７２８で、取り出した次のインターフェース・アドレスを入手し、ステップ７３２で、取り出したインターフェース・アドレスが未確定リスト３２０または完了リスト３２４にあるか判定する。アドレスが未確定リスト３２０にも完了リスト３２４にもない場合、ステップ７３６で、コントローラはそのアドレスを未確定リストに追加する。判断ブロック７４０で、コントローラ３０４は次いで、検討するインターフェース・アドレスがさらにあるか判定する。ある場合、コントローラはステップ７２８に戻って上記のステップを繰り返す。ない場合、コントローラは判断ブロック７４４に進み初期ゲートウェイ・リスト３２８中にさらにＯＳＰＦルータがあるかどうか判定する。リスト３２８中にさらにＯＳＰＦルータがある場合、コントローラはステップ７０４に戻り、さらにＯＳＰＦ発見フェーズ動作を行う。リスト３２８中にそれ以上ルータがない場合、コントローラは図４のステップ４３６に進む。

様々な出力テーブルおよびリストは、いくつかの方法でマージして統合ネットワーク・トポロジ・モデルを形成することができる。「標準的な（ａｓ ｙｏｕ ｇｏ）」手法では、ネットワーク・モデルは知識リポジトリである。発見アルゴリズムは命題方法によってそうしたモデルを扱う。すなわち、アルゴリズムがモデルに、アルゴリズムが何を見つけたか知らせ、それをどうするかはモデルに任せる。ネットワークやルータなどに関する以前取得された情報は不完全であることを示す情報がプロトコルから受け取られると、付加情報がモデルに追加される。すべての情報は、競合する情報の識別を助けるためにどのプロトコルが提供されるか、印をつけられる。異なる２つのプロトコルからの情報が矛盾する場合、ＭＩＢ２経路指定テーブルからのトポロジ情報が好まれる。この情報は、適切な経路指定プロトコルによって矛盾するとの印がつけられ、経路指定プロトコル情報が保存される。

本発明のいくつかの変形形態および変更形態を使うことができる。本発明の他の特徴を示さずに、一部の特徴を示すことが可能であろう。
たとえば一代替実施形態では、ＯＳＰＦ以外のプロトコル、共通管理情報プロトコルすなわちＣＭＩＰなどの非ＳＮＭＰネットワーク管理プロトコル、および／またはＭＩＢ情報のアクセスに依拠しない発見技術に対してアルゴリズムが使われる。こうしたアルゴリズムはどの距離ベクタ経路指定プロトコルもリンク状態経路指定プロトコルもサポートするどのルータも発見するのに使うことができる。

別の代替実施形態では、アルゴリズムは、複数の経路指定プロトコルに対して同時に使われる。図２３は、本実施形態を示す。ステップ２４００（ゲートウェイ・ルータが交信されるとき）で、システム３００は、ターゲット・ネットワーク上で使われている経路指定プロトコルを検出する。一部の構成では、ゲートウェイ・ルータは複数の経路指定プロトコルを使っていてよい。ステップ２４０４、２４０８および２４１２で、検出された各経路指定プロトコルごとに異なるアルゴリズムを用いてトポロジ発見が実施される。図２３では、ＯＳＰＦ、ＲＩＰ、およびＥＩＧＲＰ経路指定プロトコルそれぞれに対して異なるアルゴリズムが使用される。ＲＩＰおよびＥＩＧＲＰ用のアルゴリズムは上で説明したアルゴリズムを変更した形であるが、この変更は当業者には明らかであろう。複数の経路指定プロトコルが使われている場合、複数の経路指定トポロジがあり得る。本発明のネットワーク・モデルは、異なる経路指定トポロジを共通モデルにマージすることはできない。その場合、各経路指定トポロジは単一のデータ構造で同時に表される。

別の代替実施形態では、どのような経路指定プロトコルをルータがサポートするかに依存して、様々な発見エージェントがルータバイルータ・ベースで呼び出される。たとえば、トポロジ発見の間、ＯＳＰＦは第１のＯＳＰＦルータを発見することができ、次いでＲＩＰエージェントが呼び出されて、ＲＩＰをサポートするがＯＳＰＦをサポートしない次のルータを発見することができる。

別の代替実施形態では、ＭＩＢ発見フェーズおよびＯＳＰＦ発見フェーズを逆の順序で実施することができる。すなわち、ＯＳＰＦ発見をＭＩＢ発見の前に実施することができる。

別の代替実施形態では、ＭＩＢ発見フェーズおよびＯＳＰＦ発見フェーズは、並行してまたは同時に行われる。
別の実施形態では、上で説明したソフトウェア・モジュールはどれも、全体的にまたは部分的に、特定用途向け集積回路または他のどのタイプの論理回路としても実施することができる。

本発明は、様々な実施形態において、本明細書で十分に示し説明した構成要素、方法、処理、システムおよび／または機器を含み、様々な実施形態、その下位組合せおよびサブセットを含む。本開示を理解すれば、本発明の作成法および使用法が当業者には理解されよう。本発明は、様々な実施形態において、本明細書またはその様々な実施形態で示さなかったかつ／または説明しなかった項目がないとき、たとえば以前の装置または処理において使うことができたこのような項目がないときに、たとえば性能を向上し、簡便さを達成し、および／又は実装コストを削減する装置および処理の提供を含む。

以上、本発明を例示および説明の目的で説明した。上記の説明は、本明細書で開示した形に本発明を限定することを意図するものではない。本明細書の説明は１つまたは複数の実施形態および特定の変形形態および変更形態の説明を含むが、たとえば当該分野における技術および知識の範囲内であるように、本開示を理解すれば他の変形形態および変更形態も本発明の範囲内である。代替実施形態を許容される範囲まで含み、代替的な、互いに交換可能なかつ／又は等価な構造、機能、範囲またはステップが本明細書で開示されるかどうかに関わらず、このような代替的な、互いに交換可能なかつ／または等価な構造、機能、範囲またはステップを特許請求の範囲に含む権利の取得を意図するものであり、どの特許可能な対象も公に特定用途とすることを意図していない。

従来技術による単純なネットワーク・トポロジを示す図である。 従来技術による別の単純なネットワーク・トポロジを示す図である。 本発明の実施形態による計算機アーキテクチャを示すブロック図である。 フェーズ・コントローラの動作を示すフロー図である。 ＭＩＢ発見エージェントの動作を示すフロー図である。 ＭＩＢ発見エージェントの動作を示す別のフロー図である。 ＯＳＰＦ発見エージェントの動作を示すフロー図である。 ＭＩＢ発見エージェントによって出力されるルータ・テーブルを示す図である。 ＭＩＢ発見エージェントによって出力されるインターフェース・テーブルを示す図である。 ＭＩＢ発見エージェントによって出力されるネットワーク・インターフェース・テーブルを示す図である。 フェーズ・コントローラによって維持される初期ゲートウェイ・リストを示す図である。 フェーズ・コントローラによって維持される未確定リストを示す図である。 フェーズ・コントローラによって維持される完了リストを示す図である。 ＯＳＰＦ発見エージェントによって出力されるルータ・リストを示す図である。 ＯＳＰＦ発見エージェントによって出力されるリンク・リストを示す図である。 ＯＳＰＦ発見エージェントによって出力されるネットワーク・リストを示す図である。 ＯＳＰＦ発見エージェントによって出力されるインターフェース・リストを示す図である。 典型的なｉｐＡｄｄｒＴａｂｌｅテーブルを示す図である。 典型的なｉｐＲｏｕｔｅＥｎｔｒｙテーブルを示す図である。 典型的なｉｐＡｄｄｒテーブルを示す図である。 典型的なｉｐＲｏｕｔｅテーブルを示す図である。 図１８〜１９および２１のｉｐＡｄｄｒＴａｂｌｅ、ｉｐＲｏｕｔｅＥｎｔｒｙ、およびｉｐＲｏｕｔｅテーブルにおいて選択されたエントリに基づくネットワーク・トポロジを示す図である。 本発明の別の実施形態による複数経路指定プロトコル・アーキテクチャを示すフロー図である。 ｉｐＡｄｄｒＥｎｔｒｙテーブルとｉｐＲｏｕｔｅＥｎｔｒｙテーブルの間の関係を示す図である。

Claims (16)

1. 分散処理ネットワークのトポロジを発見する方法であって、
   （ａ）第１の組のルータから、前記第１の組のルータの各ルータに格納された第１のタイプの情報を取り出すステップと、
   （ｂ）第２の組のルータから、前記第２の組のルータの各ルータに格納された第２のタイプの情報を取り出すステップであって、前記第１および第２の組のルータが異なり、前記第１および第２のタイプの情報が異なるようなステップと、を含み、前記ステップ（ａ）は、
   （ａ１）選択されたルータおよび／又はインターフェースに関連づけられた次のホップのインターフェース・アドレスを取り出すサブステップと、
   （ａ２）前記次のホップのアドレスによってサポートされる経路指定プロトコルを判定するサブステップと、
   （ａ３）前記選択されたルータおよび／またはインターフェースと前記次のホップのインターフェース・アドレスとの少なくとも１つに、前記経路指定プロトコルを指すプロトコル識別子を割り当てるサブステップとを含む方法。
2. 前記第１の組のルータが前記第２の組のルータの少なくともいくつかのルータを含み、
   前記第１のタイプの情報が管理情報ベース中の１つまたは複数の変数を含み、前記第２のタイプの情報が経路指定プロトコルによって定義される１つまたは複数の変数を含む、請求項１に記載の方法。
3. （ｃ）交信するステップ（ａ）および（ｂ）の間に、交信されていないルータおよび／またはルータ・インターフェースの未確定リストを維持するステップと、
   （ｄ）前記交信する工程（ａ）および（ｂ）の間に、交信されたルータおよび／またはルータ・インターフェースの完了リストを維持するステップと、
   （ｅ）交信するステップ（ｂ）において使用するために、交信するステップ（ａ）中に初期ゲートウェイ・リストを維持するステップと、をさらに含む、請求項１に記載の方法。
4. 前記取り出すステップ（ａ）が、
   （ａ４）共通の自主的なシステムの一部である前記第１の組のルータ内の各ルータと交新するサブステップと、
   （ａ５）前記第１の組のルータ内の交信されたルータについて、ネットワーク管理プロトコルによって定義される第１の組の管理されたオブジェクトおよび／又は変数から成る前記第１のタイプの情報にアクセスするサブステップであって、各インターフェース・アドレスが別のルータの次のホップ・インターフェースにどのように接続されるかに関する、前記交信されたルータに対応するインターフェース・アドレスの一覧表、および前記交信されたルータと、前記対応する次のホップ・インターフェースの間の各リンク上に存在する内部ゲートウェイ・ルーティング・プロトコルを識別する内部ゲートウェイ・ルーティング・プロトコル識別子からなるようなサブステップと、
   （ａ６）前記第１の組のルータ内の各交信されたルータについて、前記第１の組の管理されたオブジェクトおよび／又は変数を処理して、各次のホップ・インターフェースについて識別し、前記交信されたルータに対応するインターフェースがどのように選択された次のホップ・インターフェースに接続されるかを識別し、および前記交信されたルータの対応するインターフェースと、前記選択された次のホップ・インターフェースの間の各リンク上の内部ゲートウェイを識別する内部ゲートウェイ・ルーティング・プロトコル識別子を処理するサブステップと、
   （ａ７）前記第１の組の管理されたオブジェクトおよび／又は変数に基づいて、第１の内部ゲートウェイ・ルーティング・プロトコルを用いて自律システムである前記第２の組のルータを決定するサブステップとを含み、前記ステップ（ｂ）が
   （ｂ１）前記第２の組のルータ内の各ルータと交信するサブステップと、
   （ｂ２）前記第２の組のルータ内の各交信された各ルータについて、前記第２の組のタ イプの情報において、前記第１の内部ゲートウェイ・ルーティング・プロトコルにより定義された、前記第２の組のルータに対応するインターフェース・リンクおよび／又はネットワーク・アドレスの一覧表から成る第２の組のオブジェクトおよび／又は変数にアクセスするサブステップとを含み、そして前記方法が、さらに
   （ｃ）前記第１の組の管理されたオブジェクトおよび／又は変数に基づいて、前記第１の内部ゲートウェイ・ルーティング・プロトコルとは異なる第２の内部ゲートウェイ・ルーティング・プロトコルを用いて、自律システム内にある第３の組のルータを決定するステップと、
   （ｄ）前記第３のセットのルータ内の各ルータと交信するステップと、
   （ｅ）前記第３の組のルータ内の各交信されたルータについて、前記第２の内部ゲートウェイ・ルーティング・プロトコルにより定義される第３の組の管理されたオブジェクトおよび／又は変数であって、前記第３の組のルータのメンバーに対応するインターフェース、リンクおよび／又はネットワーク・アドレスの一覧から成る第３の組の管理されたオブジェクトおよび／又は変数をアクセスするステップと、を含み、このステップ（ｅ）において前記第１、第２および第３の組のオブジェクトおよび／又は変数が処理されて、ネットワーク・トポロジ・モデルを提供し、前記第１および第２のルータのメンバーが異なっている請求項１に記載の方法。
5. 前記第１および第２のタイプの情報の少なくとも１つに基づいて、前記分散処理ネットワークに関連づけられたインターフェース・オブジェクト、ルータ・オブジェクト、およびネットワーク・オブジェクトの１つまたは複数を識別するステップをさらに含み、
   取り出しステップ（ａ）において、前記第１のタイプの情報がネットワーク管理プロトコルによって定義され、取り出しステップ（ｂ）において、前記第２のタイプの情報が経路指定プロトコルによって定義される、請求項１に記載の方法。
6. （ｃ）前記第１の組のルータの前記ルータの少なくとも１つを処理するステップをさらに含み、
   （ｄ）前記処理されたルータに格納されたインターフェース・アドレスのリストを取り出すステップであって、インターフェース・アドレスの前記リスト中の各インターフェース・アドレスごとに、
   （ｉ）選択されたインターフェース・アドレスに接続された次のホップのインターフェースのアドレスを選択するステップと、
   （ｉｉ）前記選択されたインターフェース・アドレスに関連づけられたルータ・オブジェクト、インターフェース・オブジェクト、ネットワーク・オブジェクト、およびリンク・オブジェクトの少なくとも１つを識別するステップと、
   （ｉｉｉ）前記選択された次のホップのインターフェースに関連づけられたプロトコルを識別するステップと、
   （ｉｖ）前記選択されたインターフェース・アドレスに関連づけられた次の各ホップのインターフェースごとに、ステップ（ｉ）〜（ｉｉｉ）を繰り返すステップとを反復して実施するステップを少なくとも実施することによって前記処理が行われる、請求項１に記載の方法。
7. （ｃ）前記企業ネットワークで使われる少なくとも１つの経路指定プロトコルを識別するステップと、
   （ｄ）ステップ（ａ）および（ｂ）の少なくとも１つにおいてネットワーク・トポロジ情報を集めるために、前記識別された経路指定プロトコルに基づいて、複数のデータ収集エージェントから１つのデータ収集エージェントを選択するステップであって、前記複数のデータ収集エージェントがそれぞれ、異なる経路指定プロトコルをサポートするように構成されるステップとをさらに含む、請求項１に記載の方法。
8. （ｃ）ネットワーク情報の前記第１の組を第１のネットワーク・モデルに形成し、ネットワーク情報の前記第２の組を第２の異なるネットワーク・モデルに形成するステップと、
   （ｄ）前記第１および第２のネットワーク・モデルを単一のネットワーク・モデルにマージするステップをさらに含む、請求項７に記載の方法。
9. （ａ）第１の組のルータから、前記第１の組のルータの各ルータに格納された第１のタイプの情報を取り出す第１の手段と、
   （ｂ）前記第１の組のルータとは異なる第２の組のルータから、前記第２の組のルータの各ルータに格納された第２のタイプの情報を取り出す第２に手段と、
   （ｃ）前記第１および第２のタイプの情報のうちの少なくとも１つに基づいて、前記分散処理ネットワークと関連づけられた１つもしくはそれより多くのインターフェース・オブジェクト、ルータ・オブジェクトおよびネットワーク・オブジェクトを識別する第３の手段と、を備え、
   前記第１のタイプの情報がネットワーク管理プロトコルにより定義され、および前記第２のタイプの情報がルーティング・プロトコルにより定義されるものである、分散処理ネットワークのトポロジを発見するシステム。
10. 前記第１の組のルータが前記第２の組のルータの少なくともいくつかのルータを含み、
    前記第１のタイプの情報が管理情報ベース中の１つまたは複数の変数を含み、前記第２のタイプの情報が経路指定プロトコルによって定義される１つまたは複数の変数を含む、請求項９に記載のシステム。
11. 前記第１および第２の手段によって実施される交信動作中に、交信されていないルータおよび／またはルータ・インターフェースの未確定リストを維持する第４の手段と、
    前記第１および第２の手段によって実施される交信動作中に、交信されたルータおよび／またはルータ・インターフェースの完了リストを維持する第５の手段と、
    前記第１および第２の手段によって実施される前記交信動作中に、初期ゲートウェイ・リストを維持する第６の手段とをさらに備える、請求項９に記載のシステム。
12. 選択されたルータおよび／またはインターフェースに関連づけられた次のホップのインターフェース・アドレスを取り出す第４の手段と、
    前記次のホップのアドレスによってサポートされる経路指定プロトコルを判定する第５の手段と、
    前記選択されたルータおよび／またはインターフェースと前記次のホップのインターフェース・アドレスとの少なくとも１つに、前記経路指定プロトコルを指すプロトコル識別子を割り当てる第６の手段とをさらに含む、請求項９に記載のシステム。
13. 前記第１のおよび／又は第３の手段が、
    （ｉ）自律システムである前記第１の組のルータ内の各ルータと交信し、
    （ｉｉ）前記第１の組のルータ内の各交信されたルータについて、ネットワーク管理プロトコルにより定義される第１の組の管理されたオブジェクトおよび／又は変数であって、各インターフェース・アドレスが別のルータの次のホップ・インターフェースにどのように接続されるかに関する前記交信されたルータに対応するインターフェース・アドレスの一覧表、および前記交信されたループのインターフェースと、前記対応する次のホップ・インターフェースの間の各リンク上に存在する内部ゲートウェイ・ルーティング・プロトコルを識別する内部ゲートウェイ・ルーティング・プロトコル識別子から成る第１の組の管理されたオブジェクトおよび／又は変数から成る前記第１のタイプの情報をアクセスし、
    （ｉｉｉ）前記第１の組のルータ内の各交信したルータについて、前記第１の組の管理されたオブジェクトおよび／又は変数を処理して、各次のホップ・インターフェースについて前記交信したルータの対応するインターフェースがどのように選択された次のホップ・インターフェースに接続されるかを識別し、および前記交信したルータの前記対応するインターフェースと、前記選択された次のホップ・インターフェースの間の各リンク上に存在する内部ゲートウェイ・ルーティング・プロトコルを識別する内部ゲートウェイ・ルーティング・プロトコル識別子を処理し、
    （ｉｖ）前記第１の組の管理されたオブジェクトおよび／又は変数に基づいて、第１の内部ゲートウェイ・ルーティング・プロトコルを用いて自律システム内にある前記第２の組のルータを決定するよう動作するものであり、前記第２の手段が
    （ｉ）前記第２の組のルータ内の各ルータと交信し、
    （ｉｉ）前記第２の組のルータ内の各交信されたルータについて、該第１の内部ゲートウェイ・ルーティング・プロトコルにより定義される第２の組のオブジェクトおよび／又は変数であって、前記第２の組のルータのメンバーに対応するインターフェース、リンクおよび／又はネットワーク・アドレスから成る第２の組の管理されたオブジェクトおよび／又は変数を、前記第２のタイプの情報内においてアクセスし、
    （ｉｉｉ）前記第１の組の管理されたオブジェクトおよび／又は変数に基づいて、該第１の内部ゲートウェイ・ルーティング・プロトコルとは異なる第２の内部ゲートウェイ・ルーティング・プロトコルを用いて自律システム内の第３のルータを決定し、
    （ｉｖ）前記第３の組のルータ内の各ルータと交信し、および
    （ｖ）前記第３のルータ内の各交信されたルータについて、該第２の内部ゲートウェイ・ルーティング・プロトコルにより定義される第３の組のオブジェクトおよび／又は変数であって、前記第３の組のルータのメンバーに対応するインターフェース、リンクおよび／又はネットワーク・アドレスの一覧表である第３の組のオブジェクトおよび／又は変数をアクセスするよう動作し、前記第１、第２および第３の組のオブジェクトおよび／又は変数が処理された、ネットワーク・トポロジ・モデルを提供するようにし、前記第１および第２のルータのメンバーシップが異なるものである請求項９に記載のシステム。
14. （ｃ）前記第１の組のルータの前記ルータの少なくとも１つを処理する第４の手段をさらに含み、
    前記処理されたルータに格納されたインターフェース・アドレスのリストを取り出す動作であって、インターフェース・アドレスの前記リスト中の各インターフェース・アドレスごとに、
    （ｉ）選択されたインターフェース・アドレスに接続された次のホップのインターフェースのアドレスを選択する部分動作と、
    （ｉｉ）前記選択されたインターフェース・アドレスに関連づけられたルータ・オブジェクト、インターフェース・オブジェクト、ネットワーク・オブジェクト、およびリンク・オブジェクトの少なくとも１つを識別する部分動作と、
    （ｉｉｉ）前記選択された次のホップのインターフェースに関連づけられたプロトコルを識別する部分動作と、
    （ｉｖ）前記選択されたインターフェース・アドレスに関連づけられた次の各ホップのインターフェースごとに、部分動作（ｉ）〜（ｉｉｉ）を繰り返す部分動作とを反復して実施する部分動作を少なくとも実施する動作によって前記処理が行われる、請求項９に記載のシステム。
15. （ｄ）前記企業ネットワークで使われる少なくとも１つの経路指定プロトコルを識別する第４の手段、ならびに
    前記識別された経路指定プロトコルに基づいて、前記処理（ａ）および（ｂ）の少なくとも１つのネットワーク・トポロジ情報を収集するために複数のデータ収集エージェントから１つのデータ収集エージェントを選択する第５の手段をさらに含み、前記複数のデータ収集エージェントがそれぞれ、異なる経路指定プロトコルをサポートするように構成される、請求項９に記載のシステム。
16. 前記第１の組のネットワーク情報を第１のネットワーク・モデルに形成し、前記第２の組のネットワーク情報を第２の異なるネットワーク・モデルに形成する第６の手段と、
    （ｇ）前記第１および第２のネットワーク・モデルを単一のネットワーク・モデルにマージする第７の手段とをさらに含む、請求項１５に記載のシステム。

Images