JPH10500272A - データ通信 - Google Patents

Abstract

(57)【要約】 本発明は、通信ネットワークのノード間のメッセージの経路指定に関する情報がすべてのネットワーク・ノードからアクセス可能な（ＤＣＥディレクトリ・サービスなどの）ディレクトリ・サービスによって供給される、データ通信システムおよび方法を提供する。ディレクトリ・サービスによってこのように情報を供給することにより、ネットワーク・ノードのそれぞれで経路指定テーブルをセットアップし、管理する必要性がなくなり、この管理では、動的に変化するネットワーク内の相当なネットワーク・トラフィックと、不整合データが様々なノードで保持されるという問題を含むことができる。また、本発明では、メッセージ経路決定で使用するためにディレクトリ・サービスにどのような最小限のネットワーク構成情報を保持しなければならないかを識別し、各ノードの最も近い隣接ノードのみのリストを格納するディレクトリ・サービスを使用する、経路決定のシステムおよび方法を提供する。

Description

【発明の詳細な説明】 データ通信 発明の説明 本発明は、データ通信に関し、より具体的にはデータ通信ネットワーク内のプ ロセス間の通信のための方法およびシステムに関する。 分散データ処理システムは、通常、データ通信ネットワータによって相互接続 されたいくつかのデータ・プロセッサから構成される。分散システムでは、デー タとそのデータを処理するためのプログラムは、それらが最も一般的にアクセス されるネットワーク位置の近くにそれらを配置することを目的として、複数のネ ットワーク・サイトに格納することができる。このため、すべての処理機能を提 供する単一の中央プロセッサへの依存が回避され、通信ネットワーク内でのデー タ・トラフィックと通信遅延を低減することができる。複数プロセッサからなる 分散ネットワークは、あらゆるレベルのシステムで強力なプロセスを提供する（ たとえば、強力なプロセッサを備えたワークステーションは、現在では、極めて 複雑なアプリケーションを実行することができる）際ならびにこのようなプロセ スが協調できるようにするための通信ネットワークを提供する際の多大なる技術 的進歩のために、ま すます有力なものになっている。 また、同一顧客に対応し、それぞれがそれぞれの企業内データ通信機能を備え ている可能性がある各種企業間などで、情報システムの関連ユーザが情報を共用 する潜在的可能性の増加により、分散処理の重要性はさらに増している。世界的 に、通信ネットワークはどのようなサイズと複雑さにもすることができる（すべ てのノードが単一中央ノードに直接接続されるか、またはあらゆるノードが他の あらゆるノードに直接接続されるような単純なネットワーク構成は、どのような 重大なサイズのネットワークでも実現不可能である）。 コンピュータ・ネットワーキングは生産性および効率の点で利益をもたらした が、異なる通信ネットワークおよび動作プラットフォーム（様々なベンダによっ て作成される可能性がある）が相互運用され、複数の企業がそれぞれのデータ処 理資源をすべて統合できるようにするために、そのような通信ネットワーク間お よび動作プラットフォーム間の協調をどのようにして可能にするかという問題も もたらした。 分散データ処理システムの重要な要件は、様々なネットワーク位置に配置可能 な協調プロセス間の通信について効率のよい経路指定を行うことである。実際に 、有効な経路指定は、どのような通信ネットワークでも必要である。既存のネッ トワーキング・ソフトウェアは、様々なやり方で経路指定機能を実行するが、一 般に各ネットワーク・ノードに保持されている大量のネットワーク構成データを 必要とする。ネットワ ーク・ノードという用語は、ここでは、データ通信の経路指定元または経路指定 先になりうるネットワーク・エンティティであって、特定のハードウェア装置に インストールされた１つまたは複数のコンピュータ・プログラムを含み、定義済 みの名前またはアドレスあるいはその両方とネットワーク内の特定の位置を有す るネットワーク・エンティティを指すものとして使用する。 先行技術の経路指定技法は、ソース経路指定技法と宛先経路指定技法に分ける ことができる。ソース経路指定では、ネットワーク内の各ノードは、可能なすべ ての宛先にメッセージを送信するために使用する正確な経路を把握している。こ の事前計算経路情報は、その行程を開始するときにメッセージまたはデータ・パ ケットに含まれる。事前定義経路に沿った各介入ノードは、転送判断を行うため にメッセージ内の経路定義を使用する。この手法、特に、ネットワーク・トポロ ジが動的に変化するメッセージベースのシステムに関する問題は、どのようにし て経路の情報をノードに授与するかである。（「メッセージ」という用語は、以 降、プロセス間で転送されるデータの単位を一般的に指しているものとして使用 するので、すべてのメッセージおよびデータ・パケットと、そのデータがアプリ ケーション処理用であるかまたはシステム管理または監視に関連するかにかかわ らず、プロセス間で伝送されるすべてのデータ単位を含む。） ソース経路指定は、たとえば、国際公開第９３／１６５３ ９号に開示されている。各装置は、ネットワーク内の他の各装置への好ましい通 信パスを示す経路指定リストを管理している。ネットワークの動的再構成は、各 装置が定期的に他のすべての装置にビーコン・メッセージを送信し、それらの装 置にネットワーク内での各装置の存在を通知することによって処理される。各ノ ードには、パス長が最も短い通信パスが格納される。ビーコン・メッセージには オペレータの入力を必要としないという利点があるが、（ビーコンがあらゆる変 化に応答するのではなく定期的に行われる、国際公開第９３／１６５３９号のよ うに）特に大規模かつ複雑なネットワークでは、ネットワーク状況に関する不完 全な情報を受け入れない限り、ネットワーク・トラフィックがかなり増加すると いう問題もある。経路指定の判定に古い情報を使用する場合、使用不能なノード またはリンクを含む経路を作成しようと試みると、ネットワーク資源が浪費され 、通信遅延がもたらされることになる。 宛先経路指定では、この場合も各ノードは経路指定テーブルを管理するが、特 定のメッセージ伝送用の完全なソース／宛先間経路が事前計算され、メッセージ に追加されることはない。むしろ、ソースと宛先との間の経路に沿った各ノード は、宛先に向かうその行程のどこで次にメッセージを送信すべきかを一般に判定 する。次のように、数通りの手法が知られている。 ローカル静的経路指定は、静的テーブルが各ノードのシス テム管理者によってネットワーク内の全ノードで管理されることを含む。静的と いう用語は、そのテーブルがプログラム式アルゴリズムによって更新されないこ とを暗示する。人間の介入の必要性は、複雑で動的に変化するネットワークの弱 点の１つである。 集中静的経路指定は、様々なネットワーク・ノードのテーブルが中央「制御点 」（ＰＯＣ）ノードに位置するシステム管理者によって更新されることを含む。 この手法では、ＰＯＣは被制御ノードへの遠隔アクセスが可能であると想定して いる。 集中適応経路指定は、アルゴリズムがノード経路指定テーブルを自動的に更新 することを含む。集中技法では、そのローカル・ネットワーク・リンクの状態に 関する情報がネットワーク内のすべてのノードから宛先ＰＯＣに送信されると想 定している。ＰＯＣは、まず、この情報を使用してネットワーク全体のトポロジ ・モデルを構築し、次に、そのローカル経路指定テーブルを構築するためにそれ が必要とする情報をネットワークの各ノードに送信する。この手法では、いつで も動作可能なＰＯＣノードに著しく依存している。 ローカル適応経路指定は、ローカル・ヒューリスティックを使用する発信リン クの選択を含む。例としては、メッセージ待ち行列長、ランダム選択、あふれ（ 複数のリンク上でのメッセージの複製）、あるいは監視または到着パターンに基 づいて経路指定するアルゴリズムがある。 上記のいずれの経路指定技法も、それぞれのネットワーク・ノードが保持する 情報を更新する際の大量のオーバヘッドとともに、相互接続したノード同士が整 合性のある情報を確実に保持する必要性と、更新が行われている間またはＰＯＣ が使用不能の間は通信が待機しなければならない場合に発生する処理遅延を回避 する必要性のために、ネットワーク構成が動的に変化する環境では十分に機能し ない。ネットワーク自体が再構成可能である可能性のために何らかの備えが必要 な場合、経路指定のために各ノードが管理する情報は、確実に更新可能でなけれ ばならない。 欧州特許第０２５８６５４号では、中央コンピュータが格納した料金データに アクセスすることができ、これを使用し、各発信ノードおよび各宛先に固有な経 路指定命令として後でネットワーク・ノードに伝送される経路指定方針を他のノ ードのために決定するような、ネットワーク・トラフィック経路指定およびネッ トワーク管理システムを開示している。 分散適応経路指定は、先行技術から分かっているもう１つの技法である。欧州 特許第０５１０８２２号では、循環状況テーブル（ＣＳＴ）がネットワーク内に 接続されたすべてのノードに転送され、各ノードがそのリンクおよび状況情報に よってＣＳＴを更新し、ＣＳＴから獲得し、ネットワークに関する最新の更新済 み構成情報を格納する分散技法を開示している。したがって、ネットワーク・ト ポロジを監視する機能はネットワークの各ノード間に分散され、各ノードに常駐 するモニタ・ソフトウェアは、ＣＳＴによって定期的に更新されたローカル格納 情報からそのノードとその通信リンクに関する状況情報の提供を担当する。この 解決法は、大規模ネットワークまたは再構成が頻繁に行われるネットワークでは 厳密な制限を有する。というのは、ＣＳＴは、すべてのネットワーク・ノードに 達する前に古くなってしまう可能性があり、容認できないほど長期間の間、様々 なノードが整合性のない情報を有する可能性があるからである。 欧州特許第０５６８７３７号では、適応および分散経路指定用の経路指定論理 を開示している。経路指定の選択は、ローカル伝送遅延情報と宛先ノードまでの 「ホップ距離」（その経路に沿ったノードの数）とを組み合わせて使用して行わ れる。ローカル伝送遅延情報は、データ伝送の前に信号発信によりソースと宛先 との間の部分経路をソース・ノードで評価することによって推定される。ホップ 距離は、データ・パケット伝送用の特定の経路を選択する際に使用するために計 算され、その計算が行われた特定のノードのテーブルにコンパイルされる。ホッ プ距離はほとんどの形式のトポロジ情報ほど動的ではないパラメータなので、多 大な信号発信なしでホップ距離パラメータの信頼性の想定が行われるので、経路 全体の評価を必要とする論理に比べ、信号発信と処理のオーバヘッドが低減され る。 欧州特許第０４２６９１１号では、複数のマシンＩＤと各ＩＤごとにそのマシ ン用のメッセージが向けられるネットワ ーク内の次の場所とを含む動的経路指定テーブルが各ノードに含まれている、経 路指定管理システム例を開示している。欧州特許第０４２６９１１号のシステム では、各マシンごとの更新および経路指定情報を含む、マシン・リストのデータ ベースが必要である。この更新情報は、その項目の変更に応答してその動的経路 指定テーブルの更新が必要になるようなノードに関する情報を含み、マシンのデ ータベース項目の特定の部分を更新した場合に整合性を維持するために更新する 必要があるシステムの各部を識別するものである。すべての関連ノードには、更 新した経路指定情報が送信される。各ノードによって保持しなければならない情 報の量と、その情報を更新する際のオーバヘッドは、どちらも相当な量になる。 以降の参照のために、複数ネットワークの階層化アーキテクチャ構造について 言及することは、ここでは望ましいことである。情報技術および通信のすべての ユーザ向けの共通性および異種インタオペラビリティを促進するために、国際ア ーキテクチャ規格がすでに開発され、現在も開発中である。このような規格の重 要な態様は、開放型システム間相互接続（ＯＳＩ）およびシステム・ネットワー ク体系（ＳＮＡ）に関する国際規格である。ＯＳＩおよびＳＮＡはどちらも７層 通信アーキテクチャを定義しており、各層はすぐ下の層のサービスを使用し、す ぐ上の層にサービスを提供する。この階層化アーキテクチャ構造は、第１図（R ．J．シプサー（Cypser）著「Communications for Cooperating Systems - OSI ， SNA，and TCP/IP」、Addison-Wesley、１９９１年、４８ページから抜粋）のよ うに表すことができる。同図では、ＯＳＩの名前を使用しているが、一般にＯＳ ＩまたはＳＮＡに適用可能である。（ＳＮＡとＯＳＩの層との間でいくらか異な る名前とだいたいの関係については、Cypserによって上記の参考文献の４７ペー ジ、Cypserの図３．２に表されている。） ＯＳＩおよびＳＮＡ通信アーキテタチャの下部３層（「トランスポート・サー ビス・プロバイダ」）は、Ｘ．２５パケット交換ネットワーク、ＬＡＮ、ＩＳＤ Ｎ、ＷＡＮ、その他のネットワークなどの伝送サブネットワークと、リンク層プ ロトコルとを含む。一般に、サブネットワークはネットワーク全体から「セル」 と呼ばれる個別の管理ユニットに分割可能であり、セル名は一般にセル間通信に とって重要なものである。ネットワークは非常に複雑になっている可能性があり 、ソース・ノードと宛先ノードとの間のデータ伝送には多くの中間ノードが含ま れる。 アーキテクチャの層１は、隣接ノード間の物理接続であり、電気信号が通過す るワイヤである。層２は、固定パス構成（２地点間接続、分岐接続、ＬＡＮ）と 、おそらくリンク層のフロー制御とリンク層のエラー回復とを提供するデータ・ リンク制御層である。また、層２は、中間ノード間の複数パス経路指定も提供す ることができる。層３は、ソース・ノードと宛先ノードとの間の複数パス経路指 定用のサブネットワーク（たとえば、ＬＡＮ、ＩＳＤＮ）を提供し、そのサブネ ットワーク内のフロー制御を行う（たとえば、多重化、セグメント化）。また、 層３は、サブネットワーク間のインタネットワーキング・リンクも提供する。 トランスポート制御層４は、基礎となる複数のトランスポート機能間の通信を 監督する。ソース／宛先間のトランスポートの信頼性（たとえば、データの暗号 化または順序番号付けによる）とフロー制御は層４から得られる。ＯＳＩの層４ （および層３の最上部）は、端末間の信頼性のあるストリーム送達のプロバイダ である、ＴＣＰ／ＩＰ（伝送制御プロトコル／インタネット・プロトコルという プロトコルのセット）とＮｅｔＢＩＯＳなどの共通通信プロトコルの階層化構造 内の位置に対応する。 層５は、データ交換の同期化と調整のために複数アプリケーションが使用する １組の共通信号を提供するデータ交換層である。層６は、プレゼンテーション・ サービス層であり、ＡＰＩ動詞を解釈し、通信エンド・ユーザが異なる構文とフ ォーマットを必要とする場合にデータを変換する。 層７は、アプリケーションに即時サービス・サポートを提供する層である（Ｏ ＳＩではアプリケーション・サービス層と呼ばれ、ＳＮＡではトランザクション ・サービス層と呼ばれる）。層７は、ファイル転送、ディレクトリ・サービス、 蓄積交換メッセージ、システム管理を可能にする。ディレクトリは情報用のリポ ジトリであり、ディレクトリ・サービスは名前付き資源を突き止めるためにリポ ジトリ情報を使用す るようなプロセス（すなわち、名前の解決）とリポジトリとの組合せである。デ ィレクトリ・サービスは、元々はクライアント・プロセスが同一ネットワーク・ セル内の適当なサーバと接触できるようにするためにのみ作成されたものである が、最近は即時セル外の探索アクセスなど、他の名前解決機能を提供するように 開発されている。現在では、セル内解決のためのディレクトリに加え、各種セル 間での名前解決用にグローバル・ディレクトリ・サービスも用意されている。ノ ードは名前付き資源を突き止めるためにまずローカル・ディレクトリ・サービス に接触し、ローカル・ディレクトリが特定の資源名を含んでいない場合は、グロ ーバル・ディレクトリ・サービスに接触し、必要な資源を突き止めるための情報 を有する他のローカル・ディレクトリ・サービス（一般にセル名解決を使用する ）を指し示す。また、当技術分野では、分散ディレクトリ・サービスも既知のも のであるが、ディレクトリ情報はそれが一般に必要とされるネットワーク・サイ トに配置されている。 以降の説明では、ネットワーク・アーキテタチャの各種の層を識別するために ＯＳＩの用語を使用する。このように特定の階層化ネットワーク・アーキテクチ ャ・モデルに固有の用語を使用するのは、単純化と、理解を支援するためであり 、本発明の適用性の制限と解釈してはならない。発明の概要 本発明は、プロセス間の効率のよい経路指定のために各ネットワーク・ノード で保持しなければならないデータの量を最小限にし、それにより、ネットワーク が変化した場合にこの情報を管理し更新するためのオーバヘッドを低減しようと するものである。 本発明は、分散通信ネットワークのノード間の通信用の経路を決定するデータ 通信システムおよび方法を提供し、ノード間の通信用の経路を決定するための情 報は１つのノードがそれから通信を送信するために経路の決定を必要とするとき に前記ノードに供給され、前記ノードは前記供給された情報を使用して通信用の 経路を決定し、前記情報は各ネットワーク・ノードからアクセス可能なディレク トリ・サービス情報ベースを含む分散ディレクトリ・サービスによって供給され 、そのディレクトリ・サービスは各ネットワーク・ノードごとにネットワーク構 成情報を管理することを特徴とする。 構成情報は、他のどのネットワーク・ノードが各ノードに直接接続されている かを示すリストを含むことが好ましい。このコンテキストでは、「直接接続」の 意味は、論理的にノード同士がすぐ隣同士であるということである。「直接接続 」のノード間に必ずしも専用同期通信セッションが存在する必要はないが、これ らのノードは次にメッセージが渡され、そこからメッセージが受信されるノード である。「直接接続」 という句は、ノード間の物理リンクが単純な直接接続であることを暗示するため のものではない。というのは、基礎となる物理ネットワークは通信プロセスにと って透過になる場合が多いからである。 経路指定決定のためにその情報が必要なときに（定期的またはネットワーク構 成が変化するたびではなく）ディレクトリ・サービスからノードに情報を供給す ると、メッセージ経路指定のために各ネットワーク・ノードでネットワーク構成 テーブルを管理する必要性が回避される。各ノードごとにディレクトリに保持さ れる情報が最小限になった場合、メッセージ経路指定のためのディレクトリの情 報の管理は、直接接続ノードのその構成を変更したときだけ、各ネットワーク・ ノードがディレクトリを変更することを含むことができる。しかし、経路決定を 繰り返すときに労力の重複を回避するため、ディレクトリ・サービスからそれが 供給された後で何らかの経路指定情報をノードに保持することができる（このよ うな情報を保持するかどうかという判断は、システム・パフォーマンスを改善す るかどうかによって判定されるので、特定のネットワークによって決まるもので ある）。プロセス間の経路決定のために情報を供給するためにディレクトリ・サ ービスを使用することは、先行技術では既知になっていないものである。 ディレクトリ・サービスへのアクセスは、アプリケーション・レベルのプログ ラム間リンクとは無関係のネットワーク ・リンクを介して各ネットワーク・ノードから行われることが好ましい。具体的 には、アプリケーション・レベルの経路指定を実現するための情報を得るために 、ディレクトリ・サービスにアクセスするためにＴＣＰ／ＩＰから得られるよう な下位レベルの経路指定に頼ることもできる。アプリケーション・レベルの経路 指定とＴＣＰ／ＩＰの経路指定はどちらもネットワーク・レベルの経路指定を利 用する。ディレクトリ・サービスにアクセスする際に含まれる経路指定に使用す るリンクは、アプリケーション・メッセージ経路指定に含まれるのと同一リンク である必要はない。説明のため、メッセージ経路指定はネットワークのノード間 （またはアプリケーション・プログラムをサポートする通信管理プログラムによ りアプリケーション・プログラム間）で行われ、メッセージ経路指定のために定 義されたノードの論理ネットワークの一部ではないネットワーク・ハードウェア は、物理接続レベルではその通信を可能にするためにその存在が不可欠である場 合でも一般に通信プロセスにとって見えない状態になっている。ディレクトリへ のアクセスは、関連ノード間のアプリケーション・レベル・リンクが現在使用可 能であるかどうかにかかわらず、基礎となるＴＣＰ／ＩＰまたはＳＮＡリンクな どを介して得られる。 したがって、本発明の好ましい実施例によれば、ディレクトリ・サービスから 経路指定情報を得るために、アプリケーション間リンクがノードとそのノード用 のディレクトリ・サ ービスのネットワーク位置との間で動作可能になっている必要はない。代わりに 使用可能な基礎となるトランスポート機能を使用することにより、ディレクトリ ・サービスへの動作可能なアプリケーションレベル・リンクの存在に依存するこ とを回避すると、どのノードでもディレクトリ・サービスにアクセスできる能力 を想定できるように、ディレクトリ・サービス・アクセスの信頼性が高まる。こ の想定により、すべての経路指定情報を供給するために個々のノードがディレク トリ・サービスを頼れるようになり、その結果、ノード自体で情報を複製する必 要がなくなる。（各ノードが使用可能なディレクトリ・サービスとのアプリケー ションレベルの通信セッションに頼っている場合、ディレクトリ・サービスへの 経路指定はより複雑なものになり、このようなセッションを獲得し損なうと経路 指定が不可能になるはずである。）このようなディレクトリ・サービスの使い方 は、経路指定テーブルの複製を上回る主な利点を表している。というのは、これ によって、構成変更によってそのメッセージ経路指定が影響を受けそうなあらゆ るノードにネットワーク構成更新を伝播する必要性が回避され、所与の実施態様 では、すべてのノードにはいつでも整合性のある情報が存在することを自動的に 確認されるからである（ただし、自動整合性は、一部の情報が個々のノードにキ ャッシュされる本発明の実施態様の重要な特徴ではない）。 ディレクトリ・サービスへのアクセスを想定できるという 上記の説明は、アクセスがいつでもすべてのノードから可能であることを意味す るのではなく、メッセージ経路指定用のシステムの設計でこの想定を使用しても 、通信システムのパフォーマンスが受け入れがたいものになることはないことを 意味するためのものである。 また、経路指定決定を必要とするすべてのノードからアクセス可能なディレク トリ・サービスを設けると、複数ネットワーク・ノードでの複製を回避するだけ でなく、格納しなければならない経路指定情報のタイプの点でも、経路指定を容 易にするために使用可能にする必要がある全情報の最小化も可能になる。本発明 によるデータ伝送ユニットの経路指定のために所与のノードについて格納する必 要がある最小限の情報は、そのノードが直接接続される残りのノードのリストで ある。本発明の第２の態様は、ネットワーク・ノード間のデータ伝送用の経路を 決定する方法であり、その方法は直接接続されたノードのこの情報だけを必要と する。 本発明の第２の態様によれば、どのネットワーク・ノードが他のどのネットワ ーク・ノードに直接接続されているかに関する情報を格納する分散ディレクトリ ・サービスにすべてのノードがアクセスできる通信ネットワーク内のソース・ノ ードと宛先ノードとの間の通信用の経路を決定するための方法が提供されるが、 この方法は、 ソース・ノードまたは宛先ノードのうちの第１のもの（開始ノード）から開始 し、どのネットワーク・ノード（第１の 隣接ノード）が開始ノードに直接接続されているかをディレクトリから識別し、 第１の隣接ノードが前記ソースおよび宛先ノードのうちの第２のもの（終了ノー ド）であるかどうかを判定するステップと、 前記判定による否定的な結果に応答して、開始ノード以外のどのネットワーク ・ノード（第２の隣接ノード）が前記第１の隣接ノードのそれぞれに直接接続さ れているかをディレクトリから識別し、第２の隣接ノードが終了ノードであるか どうかを判定するステップと、 経路決定プロセスが終了ノードに直接接続されているノードを識別するまで、 中間接続ノードを介する部分経路についてこの進行的評価を続行し、それにより 、ソース・ノードと宛先ノードとの間の通信用の完全な経路を決定するステップ とを含む。このディレクトリは、そのノードの直接接続ノードの組が変更される 各ノードごとにディレクトリの格納済み構成情報を更新することにより、ネット ワーク構成が変化したときに更新される。 通信用の適切な経路を決定するための情報を供給するためにディレクトリ・サ ービスにアクセスすると、経路を発見するための信号発信への依存が回避される ことは明らかである（このコンテキストでは、「信号発信」とは、ソース・ノー ドと宛先ノードとの間の経路を決定するためにそれらの間で実際のネットワーク ・トラフィックを発生し、メッセージ・データ伝送用の経路を見つけだすために 特殊メッセージを使 用することを意味する）。本発明の経路決定プロセスでは、経路指定決定を必要 とするノードとディレクトリ・サービスとの通信が必要であるが、その妥当性を 判定するために潜在的な経路に沿って実際のメッセージを送信する必要はない。 本発明によるディレクトリ・サービスを使用した通信用経路の識別コードは、 ソース経路指定方法でも使用することができる。すなわち、各データ伝送ユニッ トには、データ伝送ユニットを受け入れる各ノードがその経路を検査し、適切に データを転送できるように、経路定義情報が供給される。しかし、この事前計算 経路はデータ伝送ユニットがその宛先に到着する前に無効になる可能性があるの で（たとえば、永続的に除去されたリンクの１つによる）、本発明の好ましい実 施例では、経路に沿った次のノードのみを決定するための情報を供給するために 経路に沿った各中間ノードがディレクトリ・サービスを使用するという宛先経路 指定を含む。すなわち、ノードで行われる経路決定プロセスは、完全な経路を決 定するが、メッセージ経路指定に使用するその経路に沿った次のノードの識別コ ードのみを出力する。 本発明の経路決定プロセスは探索プロセスを含むことが好ましく、そのプロセ スは経路指定決定を必要とするネットワークのノードで実行され、ローカル・セ ル用のネットワーク構成情報を保持するローカル・ディレクトリ・サービスにア クセスする。宛先ノードがローカル・セル内にないとローカル探索によって判定 された場合（または、たとえば、セル名 を指定することによって、ローカル探索を開始する前にこれが示された場合）、 適切な経路を決定するためにグローバル・ディレクトリ・サービスを使用して宛 先ノードのローカル・セルを突き止める。したがって、本発明の好ましい実施例 では、分散ディレクトリ・サービスを利用する。すなわち、このディレクトリ・ サービスは、名前によってディレクトリから値を取り出すことが可能な分散アプ リケーションである。図面の簡単な説明 次に、以下の添付図面に関連して、例証としてのみ、本発明をより詳しく説明 する。 第１図は、名前と様々な層で実行される機能を示す、ＯＳＩネットワーク・ア ーキテクチャの階層化構造の概略表現である。 第２図は、本発明の一実施例により各ネットワーク・ノードがディレクトリ・ サービスにアクセスできる、通信ネットワークの概略表現である。 第３図は、本発明の一実施例によりディレクトリ・サービスに保持されたネッ トワーク構成情報の一例を示す図である。 第４図は、ディレクトリ・サービスにアクセスする際に含まれるシステム構成 要素の概略表現である。 第５図は、本発明の一実施例による経路決定のプロセスの流れ図である。 第６図は、本発明の一実施例による経路発見の反復ステップの一例を示す図で ある。具体的な説明 通信ネットワークの概略を第２図に示す。全体的なネットワーク５０内には、 セルと呼ばれる複数の管理サブネットワーク・ユニット６０、６５が存在する。 各セルは、複数のネットワーク・ノード７０を含むことができる。一例として、 ネットワーク・ノードは、ＩＢＭのＡＳ／４００コンピュータ（ＯＳ／４００オ ペレーティング・システム・ソフトウェアを実行する）などの計算装置上で動作 する、航空座席予約サービスなどのサーバ・プロセスである可能性もある。また 、ノードは、いずれも同一ネットワーク内にある、ＯＳ／２オペレーティング・ システム・ソフトウェアを実行するＩＢＭのＰＳ／２パーソナル・コンピュータ 上またはＡＩＸを実行するＩＢＭのＲＩＳＣシステム／６０００上で動作するプ ロセスなども含むことができる。分散処理のクライアント／サーバ・モデルでは 、これらのノードのうちの一部は、クライアント・プロセスが配置されている計 算装置への通信のために接続されたサーバ・プロセスになる（たとえば、ＡＳ／ ４００コンピュータはそれに接続された複数のワークステーションを備えること ができる）。一部のクライアント・プロセスは、特定のサーバへの通信アクセス を必要とする以外にネ ットワーク経路指定に含める必要はなく、このようなプロセスは経路指定ディレ クトリ・サービスへのアクセスを必要とするノードではない。表示端末、ワーク ステーション、プリンタなど、経路指定決定を必要としない装置は、ネットワー ク・ノードに接続することができる（これらについては第２図に示していない） 。単一コンピュータには、複数のクライアントおよびサーバ・プロセスとともに 、それらのプロセスがネットワーク内の他の場所に位置するプロセスと一緒に機 能するようにするために必要なネットワーキング・ソフトウェアがそれにインス トールされている可能性がある。（ＩＢＭ、ＡＳ／４００、ＯＳ／４００、ＰＳ ／２、ＯＳ／２、ＲＩＳＣシステム／６０００、ＡＩＸはＩＢＭの商標である。 ） それにより様々なプロセスが相互運用される通信ネットワークは、上記の説明 で言及したネットワーク・アーキテクチャの階層化構造により、複数のレベルで 表示することができる。最下位レベルには、ノード間をリンクする物理接続、す なわち、それに沿って電気信号が伝送されるワイヤが存在する。ＴＣＰ／ＩＰ、 ＮｅｔＢＩＯＳ、またはＳＮＡ ＴＣ／ＰＣなどの共通通信機能は、信頼性のあ るデータ送達を確実にするために、基礎となる物理リンクの上に設けられている （それらを利用している）。一部のネットワークでは、ＴＣＰ／ＩＰ機能の１つ 上の層として、Open Software Foundation（ＯＳＦ）の分散コンピューティング 環境（ＤＣＥ）が用意されているが、これは異種動作環境である程度の透過計算 を可能にする共通通信プロトコル、システム管理、データ・サービスである。Ｄ ＣＥについては、R．J.シプサー（Cypser）の上記の参考文献「Communications for Cooperating Systems - OSI，SNA，and TCP/IP」、Addison-Wesley、１９９ １年に記載されている。また、ＤＣＥとは無関係に、ネットワーク層より高いネ ットワークの上位レベルには、ノード間の論理リンク８０、すなわち、プロセス 間の通信パスが存在する。 ＤＣＥは、位置、システムまたはローカル命名規則とは無関係に情報の共用使 用を可能にするためにディレクトリ・サービスを提供する。ＤＣＥは、確かに、 ディレクトリ・サービスが使用可能な環境であるだけでなく、ＤＣＥディレクト リ・サービスは現在、既知の代替方法より高機能である。ディレクトリ・サービ スは、第２図には、各ネットワーク・ノードからアクセス可能な資源として表さ れ、そのサービスは全体的なネットワーク内の各セルごとに個別に表されている 。実際には、ディレクトリ・サービスは、本発明の好ましい実施例では各セルご とに単一の指定制御点（ＰＯＣ）にあるリポジトリとして実現されている（たと えば、セル６０用のディレクトリ・サービスは実際にはノードＮ１に配置されて いるはずである）。代替方法として、ＰＯＣの障害から保護するために必要と思 われる場合には、複数のセル・ノードにわたってディレクトリ・サービスを分散 するまたは重複させることも可能である。ディレクトリ・サービスは、それが区 分 されている実施態様においても、すべてのノードに対してネットワークの単一の 論理表示を提示する。 各ノードとそのディレクトリ・サービスとの間に第２図に示したアクセス線９ ０は、単にアクセスの可用性を表したものにすぎないことが分かるだろう。各ノ ードからディレクトリ・サービスへのアクセスは、実際には、基礎となるネット ワーク・リンクを介して行われ、このようなリンク上で使用可能な通信サービス （ＴＣＰ／ＩＰなど）を利用するが、ＤＣＥは、ネットワークのＴＣＰ／ＩＰレ ベルからある程度の透過性を提供する。ノードとディレクトリ・サービス位置と の間のアクセス線９０は、ノード間の論理リンク８０から独立したものとして表 されている。というのは、ネットワーク・ノード（プロセス）と通信することに よって表示されるネットワークは、使用可能なＤＣＥサービスのネットワークと は異なる可能性があるからである。すなわち、アプリケーション・レベルのネッ トワーク・トポロジは、ＤＣＥにより明らかなトポロジとは異なるように見える 可能性がある。ネットワーク・ノードはネットワークを複数のノードおよびそれ らの間の通信パスと見なす（たとえば、Ｎ１はＮ２を介してＮ３にメッセージを 送信できると認識する）が、基礎となるネットワーク（非常に複雑である可能性 がある）は透過である。この透過性は、各ネットワーク・ノードにインストール されたアプリケーション実用化ソフトウェアの特徴の１つである。 必ずしもアプリケーションレベルの通信パスとして使用可能になっているわけ ではないネットワーク・リンクを介してディレクトリ・サービスに接触可能であ ること（すなわち、アプリケーション・プログラムと通信することによって表示 さえるネットワーク・リンクのトポロジがディレクトリ・サービスと接触するた めに使用するネットワーク・リンクとは異なる可能性があること）を認識したう えで、メッセージ経路指定情報を獲得するためのものではないが、ディレクトリ ・サービスにアクセスする方法は当技術分野で既知のものであることに留意され たい。ＤＣＥディレクトリ・サービスを使用する、本発明の好ましい実施態様に よりディレクトリ・サービスにアクセスする方法については、以下に説明する。 ディレクトリ・サービスには共用アクセスが必要な大量の情報を設けることが できるが、本発明の好ましい実施例では、ディレクトリ・サービスによって保持 される構成情報は最小限のものである。すなわち、ディレクトリ・サービスは、 最初に各登録済み（以下を参照）ネットワーク・ノードごとにセル内でそのノー ドのすぐ隣の隣接ノード（プロセス間通信のために特定のノードが直接接続する ノード）のリスト１１５を保持し、他の構成情報は一切保持しない。第３図は、 セル６０のディレクトリ・サービス１００によって管理される構成情報の表（テ ーブル１１０）を示している。ただし、セルのローカル・ディレクトリ・サービ スは、セル外の通信に関する情報１２０（たとえば、ノードＮ１がノードＮ８に 直 接接続するという情報、またはノードＮ８で使用可能なサービス用のセル名）を 保持できることに留意されたい。好ましい実施例のローカル・ディレクトリ・サ ービスは、経路決定プロセスがローカル・セル外の接続に関する情報を必要とす るときにグローバル・ディレクトリ・サービスに接触して接続情報を供給するよ うに起動される。グローバル・ディレクトリ・サービスは、経路決定プロセスを 続行するために適切なディレクトリ・サービスへの接続を可能にする情報を供給 する（すなわち、グローバル・ディレクトリ・サービスは、ネットワーク全体に 関するネットワーク構成情報を保持するリポジトリではなく、むしろ、必要な情 報の位置を可能にするベクトル化エージェントである）。 ネットワーク・ノードは、ネットワークに加わるとき（たとえば、ネットワー ク・ノード装置の電源がオフになっている期間後の始動時、またはネットワーク 内にノードを「作成する」とき）に、それ自体を名前で識別し、その直接接続ノ ードと特定のノードでどのサービスが使用可能であるかなどの特性をリストして 、ディレクトリ・サービスに登録する。その他のノードは、その後、特定のサー ビスが必要なときにディレクトリに接触し、接触すべきノードの名前を見つける ことができる。ディレクトリ情報は、各ノードによって自動的に管理され、その ローカル構成の変更が行われたときは必ずディレクトリ・サービスに通知する。 ローカル・ネットワーク接続を定義するのに必要なもの以上の管理は一切不要で ある。 本発明をＤＣＥで実現すると、所与のノードに関するディレクトリ項目は、そ のノードが属すセルのＤＣＥディレクトリ・サービスに保持される。各ノードの ディレクトリ・サービスは、そのノードの完全修飾ＤＣＥ名（すなわち、そのノ ード用のネットワーク内の固有名）によって識別される。項目の名前は、ノード の名前から計算可能である。標準化された階層ディレクトリ構造を使用する。デ ィレクトリ構造を区分して、様々な種類の項目を互いに分離することは、ＤＣＥ では既知のことである。セル・ルート下の特定のサブディレクトリは、通常、各 セルごとに作成され、そのセル内のノードはこのサブディレクトリ内の項目とし て現れる。したがって、名前の最下位部分によって所与のセル内の個々のノード が区別される。 ディレクトリ項目は、属性として、それが直接接続されているノードの完全修 飾ＤＣＥ名を含む。ディレクトリ属性は、ディレクトリ項目に格納可能なデータ 要素である。この属性は、所与のノードに関するディレクトリ項目から取り出す ことができる。 完全修飾名の使用により、ディレクトリ・サービスは、そのノードの情報が格 納されているセルにかかわらず、しかも照会元のセルとは無関係に、名前によっ て任意のノードの項目を突き止めることができる。これは、グローバルＤＣＥデ ィレクトリ・サービスの既知の特性の１つである。 別のネットワーク・ノードにメッセージを送信するために経路の決定を必要と するネットワーク・ノードは（たとえば、ノードＮ１のクライアント・プロセス がノードＮ６のサーバ・プロセスによる何らかのアクションを要求したい場合） 、まず、そのローカル・セル・ディレクトリ・サービスにアクセスする。第４図 に概略で表したように、ディレクトリ・サービス情報３００へのアクセスは、各 ノードのディレクトリ・アクセス・エージェント３１０によって行われる。ディ レクトリ・アクセス・エージェントは、一般に、ネットワーク内のデータ処理シ ステム３６０上にインストールされた通信マネージャ３５０と一体の構成要素に なる。アクセス・エージェントは、ディレクトリ・サービス情報が配置されてい るネットワーク・エンティティ３３０内に仲介物、すなわち、ディレクトリ・シ ステム・エージェント３２０を構築する。一般に、ネットワーク・エンティティ ３３０は、ネットワーク内の通信用に接続されたすべてのコンピュータ・システ ムから選択されたものである。すべてのアプリケーション・プロセス３４０は、 ディレクトリ・アクセス・エージェント３１０を使用してディレクトリ・システ ム・エージェント３２０に接触するが、これらの構成要素は相俟ってディレクト リ・サービス情報ベース３００からの情報にアクセスするための手段を形成する 。ディレクトリ・システム・エージェントは、ディレクトリ探索用の定義済みプ ロトコルを理解する。アクセス・エージェントは、ディレクトリ・プロトコルを 理 解し、ディレクトリ・サービス自体の詳細からアプリケーションをシールドする 。１つのプロトコルは、互いにやりとりするために（ディレクトリ情報の様々な 部分が配置されている可能性のある）分散ネットワークの様々なノード内のディ レクトリ・システム・エージェント用として使用するが、第２のプロトコルは、 ディレクトリの情報に対する更新を送信し、ディレクトリ・システム・エージェ ントからの情報を要求するために、ディレクトリ・アクセス・エージェント用と して定義される。 ディレクトリ・サービスは、複数のネットワーク・ノード間に分散されている ことが好ましい。具体的には、そのノードに全ディレクトリ・サービス情報ベー スのローカル部分が配置されている、分散セル構造化ネットワークの各セル内に 指定のノードが１つずつ存在する可能性がある。このような分散ディレクトリ・ サービス構造では、経路決定プロセスは以下に記載するように実行され、それに 関する情報がローカル・ディレクトリ情報ベース内に保持されるノード間の接続 の評価が行われる。それに関する情報がローカル・ディレクトリ・サービス情報 ベースに保持されていないノードに関する接続情報が必要な場合は、ローカル・ ディレクトリ・サービスが自動的にグローバル・ディレクトリ・サービスを使用 し、経路決定に必要な情報を入手可能な適切な他のセルのディレクトリ・サービ スを識別する。したがって、このような他のセルのディレクトリ・サービスは、 経路決定プロセスの 継続部分としてアクセスされる（したがって、ローカル・ディレクトリ・サービ ス情報サービスのみから完全な経路決定情報を得ることはできないことを現行ノ ードに通知するための要件は一切存在しない）。 経路決定プロセスの諸ステップは、第５図に概略で表されている。現行ノード で実行中の経路決定プロセスによる要求に応じて、ディレクトリから現行ノード に関する項目が取り出される（ステップ１５０）。この項目は、ローカル・セル のディレクトリ・サービス内に入ることになる。属性は、その項目自体とともに 取り出される。このような属性は、直接接続ノード（最も近い隣接ノード）のリ ストを含む。次に、経路決定プロセスは、直接接続ノードのうちのいずれかがタ ーゲット・ノード（本明細書の例ではＮ６）であるかどうかを検査する（１６０ ）。この検査の結果が否定である場合、経路決定プロセスは、リスト内の各ノー ドに問い合わせて（ステップ１８０〜２１０）その接続ノードを発見することに より、最も近い隣接ノードのいずれかがターゲット・ノードに直接接続されてい るかどうかを評価する（１８０、１９０、２００）。最も近い隣接ノードのそれ ぞれに関するディレクトリ項目の取出しによって（例のように）ターゲット・ノ ードへの直接接続が識別されない場合、経路決定プロセスは次に、最も近い隣接 ノードに直接接続されたノードに関するディレクトリサービス項目情報を取り出 す。すなわち、ソース・ノードから順に次のステップ（２２０）をたどる。デ ィレクトリ項目に問い合わせるたびに、その属性も取り出され、経路指定アルゴ リズムは上記のように進行することができる。ディレクトリ項目の属性により、 有効経路を求める現在の探索にすでに含まれているもの以外に最も近い隣接ノー ドが一切存在しないことが分かった場合、伝播経路評価のその分岐に沿って有効 な経路は一切存在せず、特定の部分経路の評価が終了する（１８０）。 したがって、このプロセスは、（ステップ２００で）ターゲット・ノードに直 接接続されたノードが発見されるまで、そのすぐ隣の隣接ノードのそれぞれを介 し、このような即時接続ノードに直接接続された追加ノードのそれぞれを介する 、ソース・ノードからの部分経路を並行して評価する。完全な経路が見つかり、 経路情報が出力される（１７０）か、または有効経路が一切存在しないことが判 明する（すなわち、すべての部分経路評価が終了する）と、経路決定プロセスは 終了する（１７５）。属性内のノード項目は完全修飾名なので、それがローカル ・セル外にあっても、ディレクトリ・サービスはデータを突き止めることができ る。すなわち、ディレクトリ・サービス内のすべての情報はどのノードにも使用 可能である。 完全修飾ＤＣＥ名（すなわち、ネットワークに固有の名前）の使用により、Ｄ ＣＥディレクトリ・サービスのグローバルに分散した各種の特徴を完全に活用す ることができる。本発明の代替実施例では、より単純なディレクトリ・サービス を 使用することもできる。唯一の要件は、各項目が関連項目のリストを含むことが でき、その関連項目のそれぞれが問合せ可能であるということである。 経路の正常決定後に出力される（ステップ１７０）経路情報は、宛先ノードへ の途中でメッセージを送信すべきソース・ノードからの次のノードの識別コード である。この経路指定情報を使用してこのようなメッセージが新しいノードに転 送されると、受信側ノードが宛先ノードではない場合、それは、メッセージの前 方転送のために経路指定決定を必要とする新しいソース・ノードになる。したが って、その新しいソース・ノードのために経路決定プロセスが繰り返され、プロ セスは完全な経路を識別するが、メッセージの前方伝送のために次のノードの識 別コードのみを使用する。 上記の説明では、経路決定プロセスは、ソース・ノード（現行ノード）から開 始し、宛先に向かう諸ステップで部分経路を評価している。経路決定プロセスは 、ターゲット・ノードから同様に開始することもできる（というのは、経路決定 プロセスを開始するときに、現行ノードとターゲット・ノードのそれぞれを入力 しなければならないからである）。メッセージ経路指定のためにターゲットから 始まる評価については第６図に例示するが、この場合も第２図と、Ｎ６への経路 を必要とするＮ１の例とを参照する。第１に、Ｎ６用のディレクトリ項目が取り 出される。Ｎ６がＮ１に直接接続されていないと分かると、経路決定プロセスは 、ディレクトリ項 目属性からＮ６に直接接続されたノードを選択する。これらはＮ５とＮ７である 。順に選択されたＮ５とＮ７のそれぞれについて、ディレクトリ・サービス項目 （各ノードの属性としてローカル・ネットワーク構成情報を含む）が取り出され 、直接接続ノードが決定される。これらは、それぞれＮ４とＮ３である（Ｎ６は すでに上記の評価に参加しているので、Ｎ６への分岐は無視される）。これらの ノードのいずれもＮ１に直接接続されていないので、Ｎ４とＮ３に関するディレ クトリ項目が順に取り出される。Ｎ４がＮ１に直接接続されていることが判明す る。したがって、Ｎ１からＮ４、Ｎ５、Ｎ６へ続く経路が識別される。Ｎ４を介 してＮ６に向けられるメッセージを経路指定するようにＮ１が指示されるように 、経路決定プロセスは（ステップ２００で）ノード名Ｎ４を出力する。 上記の例（第２図および第６図を参照する）では、経路決定プロセスを続行し た場合、Ｎ７およびＮ３を介して調査中の経路も最終的に完了するはずである。 しかし、第１の経路（この場合はＮ５とＮ４を介する短い方の経路）が発見され ると、経路評価は終了する。 上記のように、所与のノード（ソース・ノードという）に関する経路決定プロ セスの出力は、本発明の好ましい実施例では、単にターゲット・ノードへの途中 でメッセージを送信すべき次のノードの識別コードにすぎない。したがって、本 発明のこのような実施態様に関する出力は経路全体に関する 情報ではない。所与のソース・ノードのために経路決定を実行した後、そのノー ドからメッセージを転送することができる。次に、受信側ノードは、メッセージ の前方経路指定のために経路決定を行う必要がある現行ノードになる。メッセー ジを送信すべき次のノードを決定するために、もう一度、経路決定プロセスが開 始され、使用される。この経路決定方法には、複雑な経路情報をメッセージ・ト ラフィックに追加する必要がないという利点があり、それぞれの決定によって、 その宛先に向かうメッセージの次のネットワーク・ホップのための次のノードだ けが識別される。第２の利点は、構成変更が頻繁に行われる大規模ネットワーク では特に重要であるが、メッセージがソースと宛先との間を移動中の間にネット ワークが変化した場合に第１の決定から続く反復次ノード決定によって異なる次 ノード（すなわち、異なる経路）を識別できるように、第１の経路決定後は識別 された経路が一定ではないという点である。 経路全体の識別コードを出力するのではなく、次ノードの識別コードのみを出 力する場合の欠点は、当然のことながら、経路に沿った各ノードごとに経路決定 プロセスが繰り返されることである。再構成があまり頻繁ではないネットワーク の場合、メッセージを受信するノードによる経路指定のためにそれを読み取って 使用できるように、経路全体の識別コードを出力し、その情報をメッセージ伝送 に追加することによって、より高いパフォーマンスが達成される。このようにメ ッ セージ伝送内に完全な経路に関する経路指定情報を含めることは、多くのネット ワークにとって最適の本発明の実施態様になる。 上記の単純なプロセスの限界は、大規模かつ複雑なネットワークでは、評価の ためにディレクトリから取り出さなければならないノード項目の数が過剰になる 可能性がある点である。本発明は、所与の経路に沿ってトラフィックを送信する たびに経路発見用の完全なアルゴリズムを実行する必要がないように、ディレク トリ・サービス探索によって識別された経路をネットワーク・ノードでキャッシ ュすることによって、この問題を解決する。したがって、経路決定によって出力 される経路情報はローカル・キャッシュ記憶域（すなわち、ネットワーク内の同 一物理位置にあり、現行ノードと論理的に関連するキャッシュ記憶域）内に置か れる。経路情報は、メッセージ経路指定に使用した後もこのローカル・キャッシ ュ内にとどまっているので、現行ノードがその後、同一ターゲット・ノードへの 経路の決定を必要とする場合の再使用に使用可能である。キャッシュした情報の 保存方針は、それを超えるとキャッシュした項目が無効と想定され、再使用され なくなるという時間制限の設定を含む。 このキャッシュ技法は、ネットワークの変更（および、その結果、ディレクト リ内の情報の変更）によって想定した妥当性のための時間制限が切れる前にキャ ッシュした情報が無効になるという可能性をもたらし、その結果、無効経路が選 択されるという可能性が残る。これを回避するために、経路検証プロセスが実行 される。この経路検証プロセスは、キャッシュした経路の一部を形成するネット ワーク・ノードに関するディレクトリ・サービス情報だけを取り出し、現行ディ レクトリ・サービス情報からその接続がまだ有効であることを検証する。この検 証プロセスは、ソースと宛先の間の指定の中間ノードだけが調査される、通常の 経路決定プロセスの限定パフォーマンスを含むものと見なすことができる。キャ ッシュした経路が無効であると判明した場合、またはキャッシュした情報の想定 妥当性の時間制限が切れた場合、通常の経路決定プロセスが開始される。 キャッシュした経路情報が無効になるという潜在的な問題に対する代替解決法 は、上記の経路検証方法より検証オーバヘッドが少なくなるが、経路が無効にな るような状況から回復するために使用可能な技法を用意するためにのみキャッシ ュした情報を使用する方法である。この解決法では、経路検証方法よりオーバヘ ッドが少なくなるが、キャッシュした経路が無効になったときの回復時間は長く なる。本発明の好ましい回復技法は、送信側ノードによって伝送されたメッセー ジの送信側ノードでファイルを管理し、各メッセージが「未確定」（または「非 コミット」）状況を有し、送信側のファイルから削除されないが、ターゲット・ ノードでの正常受信の確認が送信側ノードで受信されるまで、考えられる再送信 のために保存されることを含む。送達できないメッセージに ついては通知が作成される。この蓄積交換技法は、ＩＢＭから市販されているMQ Seriesという市販のメッセージ製品のように、プロセス間メッセージ待ち行列化 で実現される。（MQSeriesはＩＢＭの商標である。）メッセージ待ち行列化通信 については、ＩＢＭの資料番号GC33-0805-00、「IBM Messaging and Queuing Se ries: An Introduction To Messaging and Queuing」と、ＩＢＭの資料番号SC33 -0850-00、「IBM Messaging and Queuing Series Technical Reference」に記載 されているが、これらの資料は参照により本明細書に組み込まれる。 無効な経路を発見したノードが発信ノードにメッセージ・トラフィックを返す など、代替の「ロールバック」技法は当技術分野では既知のものである。しかし 、この手法には、経路の無効性を発見したノードが、発信ノードに戻る経路が一 切ないことも発見した場合に、メッセージを喪失する可能性がある。これは、い くつかのネットワーク変更を同時に行った場合に起こりうることである。また、 この手法では、発信ノードに戻る経路を識別するための何らかの機構も必要であ る。メッセージ伝送が完全な経路の識別コードを含まないような本発明の実施態 様の場合、発信ノードを突き止めるには、経路決定プロセスの個別の操作または 識別された経路の情報の追加キャッシュの使用が必要になる。 経路の無効性が発見されたときのメッセージ伝送のロールバックに続いて、経 路発見プロセスを先頭から開始するか、 経路発見プロセスを使用して識別した新しい部分経路とともにキャッシュした経 路の有効部分を使用することもできる。したがって、経路決定のオーバヘッドを 低減するための回復ベースの手法は、非同期メッセージ待ち行列化を支援するＩ ＢＭのMQSeries製品による場合など、あまり頻繁に変更されず、「蓄積交換」機 能が設けられている安定したネットワークに最も適している。経路検証技法は、 信頼性が高くないか急速に変化するネットワークの方が適している。一般に、本 発明は、ディレクトリ・サポートとネットワーキングが所定の位置にあることが 必要なので、ミドルウェア（すなわち、アプリケーション実用化ソフトウェア） 経路指定に最も適しており、特に、本発明は、メッセージのネットワーク間経路 指定のためにＩＢＭのMQSeries待ち行列マネージャ・ミドルウェア製品のネット ワークで有利に実現される。このような実施態様では、本発明は、個々のMQSeri es製品がメッセージ通信用の経路を決定する必要性を防止し、その結果、ローカ ル経路決定の要件になりうる個別管理の必要性を回避する。 様々な論理ネットワーク・トポロジがネットワークの様々なレベルで目に見え るという上記の説明は、必ずしもネットワーク内のすべての処理システムで待ち 行列マネージャが実行されているわけではないメッセージ待ち行列化ネットワー クで例証される。通信ノードのネットワークは待ち行列マネージャのネットワー クであるが、（同一または異なる物理ネットワーク・サイトに位置する）ネット ワーク内には、特定 の待ち行列マネージャ・プロセスへの通信アクセスのみを必要とするクライアン ト・プロセスがさらに存在する可能性がある。この例では、待ち行列マネージャ ・プロセスだけがディレクトリ・サービスに登録し（すなわち、待ち行列マネー ジャのクライアントは登録しない）、その登録は待ち行列マネージャがネットワ ーク内で作成されたときに行われる（インストールおよび構成後であるが、待ち 行列マネージャが実際に動作するまで待つわけではない）。この段階での登録が 必要である理由は、待ち行列マネージャ自体が使用不能の場合でも待ち行列マネ ージャで経路指定が必要になる可能性があることである。上記のノード命名規則 を参照すると、ノードが待ち行列マネージャ・プロセスである場合、ディレクト リ・サービス名の最下位部分（セル内でそのノードを区別するために使用するも の）が待ち行列マネージャ名になる。 本発明の好ましい実施例に関する上記の説明では経路決定が必要なネットワー ク内の現行ノードで実行する経路決定プロセスに言及しているが、各セルが単一 の特定のノードを有し、そのノードにそのセル用のディレクトリ・サービスが配 置され、決定を必要とする各セルが最初にそのローカル・ディレクトリ・サービ スに接触するような本発明の実施例では、ディレクトリ・サービス・ノードで実 行される経路決定プロセスを同様に含む可能性があることに留意されたい。これ は、要求側ノードのためにディレクトリ・サービス・ノードがすべての経路指定 決定を実行することを意味するはずである。 探索を実行したときに経路が使用可能ではない可能性を処理するため、経路決 定内で所与の最小期間または最大ネットワーク・ホップ数に探索を限定すること ができる。設定した時間またはその他の事前設定限界内に経路が決定されない場 合、決定を必要とするノードに対して「経路使用不能」という応答が行われる。 このような限定は、特定の経路決定内の探索ループがエンドレス探索になるのを 防止するために使用することもできるが、特定の経路決定で第１回目に参加した ノードに続くノードの接続を探索プロセスが再評価するのを防止することによっ てループを回避する方が好ましい。

Claims (1)

1. 【特許請求の範囲】 １．分散通信ネットワーク（５０）のノード間の通信用の経路を決定する方法に おいて、ノード間の通信用の経路を決定するための情報は１つのノード（７０） がそれから通信を送信するために経路の決定を必要とするときに前記ノードに供 給され、前記ノードは前記供給された情報を使用して通信用の経路を決定し、前 記情報は各ネットワーク・ノードからアクセス可能なディレクトリ・サービス情 報ベース（３００）を含む分散ディレクトリ・サービス（１００）によって供給 され、そのディレクトリ・サービスは各ネットワーク・ノードごとにネットワー ク構成情報を管理することを特徴とする方法。 ２．前記ディレクトリ・サービスによって管理され、通信経路決定のために使用 される前記ネットワーク構成情報が、各ネットワーク・ノードの直接接続ネット ワーク・ノードの組の識別コードのみを含むことを特徴とする、請求項１に記載 の方法。 ３．ディレクトリ・サービス情報ベース（３００）は、ネットワーク構成が変化 したときに、直接接続ノードのそれぞれの組が変更されたノードに関するディレ クトリの格納済みネットワーク構成情報だけを更新することによって更新される ことを特徴とする、請求項２に記載の方法。 ４．ディレクトリ・サービスへのアクセスは、アプリケーシ ョン・レベルのプログラム間通信とは無関係のネットワーク・リンクを介して行 われることを特徴とする、請求項１ないし３のいずれかに記載の方法。 ５．ディレクトリ・サービスによってネットワーク・ノードに供給される、通信 の経路指定のための情報は、その後、そのノードから通信経路指定が必要になっ たときに使用するために前記ノードにキャッシュされることを特徴とする、請求 項１ないし４のいずれかに記載の方法。 ６．その後の通信経路指定のために前記キャッシュした経路指定情報を再利用す るために、経路妥当性検査プロセスが行われることを特徴とする、請求項５に記 載の方法。 ７．通信を送信すべき経路に沿った次のノードを識別するために、ディレクトリ ・サービスによってネットワーク・ノードに供給された情報が前記ノードによっ て使用され、次のノードの識別コードが前記ノードによって実行される経路決定 の出力になることを特徴とする、請求項１ないし６のいずれかに記載の方法。 ８．現行ノードから宛先ノードへの通信のための完全な経路を決定するために、 ディレクトリ・サービスによってネットワーク・ノードに供給された情報が前記 ノードによって使用され、通信を送信すべき次のノードを識別するために経路に 沿った後続ノードで通信を受信したときに使用するために経路識別情報が通信内 に含まれることを特徴とする、請求項１ないし６のいずれかに記載の方法。 ９．ディレクトリ・サービスが、複数の個別のネットワーク・セルとして構造化 されたネットワークでの使用に適した分散階層構造ディレクトリ・サービスであ り、それぞれのネットワーク・セルについて前記情報を個別に格納するように、 ネットワーク構成情報がディレクトリ・サービス内で区分されることを特徴とす る、請求項１ないし８のいずれかに記載の方法。 10．各ノード（７０）が分散ディレクトリ・サービス（１００）にアクセスでき る通信ネットワーク（５０）内のソース・ノードと宛先ノードとの間の通信用の 経路を決定する方法において、前記ディレクトリ・サービスが、どのネットワー ク・ノードが他のどのネットワーク・ノードに直接接続されているかに関する情 報（１１５）を格納することを特徴とし、この方法が、 （ｉ）前記ソース・ノードおよび宛先ノードのうちの第１のもの（開始ノード ）から開始し、どのノード（第１の隣接ノード）が開始ノードに直接接続されて いるかをディレクトリ・サービスから識別し（１５０）、これらのノードのいず れかが前記ソースおよび宛先ノードのそれぞれの相手側（終了ノード）であるか どうかを判定する（１６０）ステップと、 （ii）前記第１の隣接ノードのいずれも終了ノードではないという判定に応答 して、どのノード（第２の隣接ノード）が第１の隣接ノードのそれぞれに直接接 続されているかをディレクトリ・サービスから識別し（１９０）、前記第２の隣 接ノードのいずれかが終了ノードであるかどうかを判定する（２００）ステップ と、 （iii）終了ノードに直接接続されているノードが識別されるまで、Ｎ番目の 隣接ノード（Ｎ＝２、３、４・・・）が一切終了ノードに直接接続されていない と判定されるたびに、その判定に続いて（Ｎ＋１）番目の隣接ノードについてス テップ（ii）の前記識別ステップと判定ステップを繰り返すステップと、 （iv）終了ノードに直接接続されているノードの識別（１６０、２００）に応 答し、それにより、終了ノードに直接接続された識別済みノードを介して開始ノ ードと終了ノードとの間の経路を決定し、メッセージ伝送で使用するために少な くともソース・ノードに直接接続された前記経路上のノードの識別コードを供給 する（１７０）ステップとを含むことを特徴とする方法。 11．通信ネットワーク（５０）のノード（７０）に位置するプロセス（３４０） がネットワーク・リンク（８０）によるメッセージの転送によって互いにやりと りするネットワーク内で使用するためのデータ通信システムにおいて、このシス テムが、メッセージ転送のための所定の経路に応じてプロセス間のメッセージの 転送を制御するための手段（３５０）を含み、このシステムが、 ネットワークの分散ディレクトリ・サービス（１００）にアクセスするための 手段（３１０）であって、前記システム 上に位置するプロセスからのメッセージ転送のために経路決定が必要になったと きに、メッセージ転送のための前記経路の決定のために情報を獲得するために、 その分散ディレクトリ・サービスがディレクトリ・サービス情報ベース（３００ ）内にネットワーク構成情報を管理する手段と、 獲得した前記情報を使用して通信用の経路を決定するための手段とを含むこと を特徴とする、データ通信システム。 12．その後、前記システム上に位置するプロセスからメッセージ経路指定が必要 になったときに使用するためにディレクトリ・サービスから獲得した前記情報を キャッシュするための手段を含むことを特徴とする、請求項１１に記載のシステ ム。 13．複数のネットワーク・ノード（７０）と、そのノード間の通信用の相互接続 ネットワーク・リンク（８０）とを含む通信ネットワークにおいて、このネット ワークが、 前記ネットワーク・ノードが前記ノードからのネットワーク通信用の経路の決 定を必要とするときにネットワーク通信の経路指定に関する情報をネットワーク ・ノードに供給するために、ネットワーク構成情報を格納するディレクトリ・サ ービス情報ベース（３００）を含む、分散ディレクトリ・サービス（１００）と 、 前記ノードからのネットワーク通信を経路指定するために経路決定が必要にな ったときに経路指定情報を獲得するためにディレクトリ・サービス情報ベースに アクセスし、獲得し た前記情報を使用して経路を決定するための、ネットワークの各ノードに関連す る手段（３１０、３２０）とを含むことを特徴とする、通信ネットワーク。 14．ディレクトリ・サービス情報ベースにアクセスするための前記手段が、ネッ トワークの構成が変更されたときにディレクトリ・サービス情報ベースを更新す るための手段を提供することを特徴とする、請求項１３に記載の通信ネットワー ク。