JPH0793625B2

JPH0793625B2 - セッション確立開始方法およびシステム

Info

Publication number: JPH0793625B2
Application number: JP3231081A
Authority: JP
Inventors: オゥエン・ヒュンホ・チョイ; ジョン・エリス・ドレイク・ジュニア; ジェイムス・コービン・フレッチャー; ジョナサン・ルイス・ハーター; ジェフリー・ゲール・ナウス; ダーク・クラウス・クレイマー; マイケル・アーサー・ラーナー; ジョセフ・リー・マッキノン; リー・マーク・ラファロウ; ウィリアム・エドワード・シダル; メリンダ・ポラード・スタンプ
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1990-09-28
Filing date: 1991-08-20
Publication date: 1995-10-09
Anticipated expiration: 2010-10-09
Also published as: JPH04227145A; EP0478485A2; US5222242A; EP0478485A3

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明はコンピュータ・ネットワ
ークに関するもので、特に、このようなネットワーク中
に、資源（リソース）を配置するに当たり、この資源の
所在および特性の検証を必要としないで配置する方法に
関する。

【０００２】

【従来の技術】一般に、データ通信ネットワークは、ネ
ットワーク・ノードと、エンド・ノードとを通信リンク
を介して相互接続して集合させたものとして規定でき
る。ネットワーク・ノードは、以下のようなデータ処理
システムである。即ち、ネットワーク中に、所定の機
能、例えば、このネットワーク・ノード自身と隣接ノー
ドとの間でメッセージをルーティングしたり、２つのノ
ード間で伝送されるべきメッセージ用のルートを選択し
たり、また、ディレクトリ・サービスを受入れエンド・
ノードに提供するといった機能を供給するシステムであ
る。これらノード間のリンクは、従来のケーブル接続の
ような永久的な通信リンクであったり、または、公衆も
しくは私設電話システムを介してのダイアル・アップ接
続のように、必要な時だけ利用可能な通信リンクであ
る。また、エンド・ノードは、例えばディスプレイ・タ
ーミナル、インテリジェント・ワークステーション等の
デバイスによって実現されるものであるから、このノー
ドによって、ネットワーク中の他のノードに、ルート選
択やディレクトリ・サービスを提供するものではない。
これらエンド・ノードには、ネットワーク・ノードによ
って実行される類いのサービスを提供しないプロセッサ
が含まれうる。これらネットワーク・ノード、エンド・
ノードおよびノード間のリンクを、総合的に、ネットワ
ーク資源と称するものとする。また、種々のノードおよ
びリンクの物理的形態および特性をこのネットワークの
トポロジーと称するものとする。

【０００３】これらノードの各々には、１個またはそれ
以上のネットワークにアドレス可能なユニットが含まれ
ており、各ユニットは、ネットワークを介した通信用の
ソースまたはターゲットを構成できる資源を備えてい
る。以下の説明において、用語「論理ユニット」または
「ＬＵ」は、ネットワークにアドレス可能なユニットに
位置するエンド・ユーザと、このネットワークの残りの
部分との間のインターフェースを識別するものとして使
用する。また、用語“エンド・ユーザ”とは、人的ユー
ザと、ネットワークにアドレス可能なユニットで実行さ
れるコンピュータ・プログラムと、の両方を包含するも
のである。

【０００４】ネットワーク中の異なる論理ユニットにお
ける２個の資源間のルートを選択する、またはこれら２
つの論理ユニット間で論理接続、即ちセッションを確立
するためには、ルート選択やセッションの確立に応答し
得るノードが、両方の資源についての情報を持つことが
要求される。この必要な情報には、各資源の所在および
特性の情報が含まれている。

【０００５】少なくとも理論上、すべての新規な、削除
された、または変更された資源についての情報を単一の
ネットワーク・オペレータに対して通信するようなネッ
トワークを、設立することは可能である。このようなオ
ペレータは、こうした情報のすべてを収集すると共に、
ルート選択またはセッション確立機能を実行するすべて
のノードに対してこの情報を通信しなければならない。
このようなアプローチは、小規模で、比較的静的な（即
ち、変化しない）ネットワークに対してはうまくいくか
もしれない。

【０００６】しかしながら、小規模または静的な特性の
データ通信ネットワークは殆ど存在しない。大部分のネ
ットワークは、大規模であると共に、極めて動的なもの
で、資源が動いたり、追加されたり、削除されたり、ネ
ットワークに残存中に、新たな特性（例えば、利用可能
／利用不可能）をとる。

【０００７】代表的なデータ通信ネットワーク中の資源
における変化の大きさおよび頻度は、単一のネットワー
ク・オペレータを圧倒するものである。この資源変化情
報を受信し、コンパイルし、分配する際の遅延によっ
て、ネットワーク・ノードによる無駄な行為が生じてし
まい、単一のネットワーク・オペレータから受信した古
い情報に基づいてルートが選択されたり、セッションが
確立されたりしてしまう。

【０００８】データ通信ネットワーク中でネットワーク
・ノードがターゲット資源の所在を確認することを可能
にするプロセスが、米国特許第４，９１４，５７１号明
細書に記載されている。この特許技術によれば、ソース
論理ユニットと、ターゲット論理ユニットとの間でセッ
ションを確立する役目を果たすネットワーク・ノードに
よって、所在確認サーチが実行され、これによってこの
ターゲットを動的に所在確認すると共に、このターゲッ
トの特性に関する必要な情報を獲得する。これら所在お
よび特性をネットワーク・ノードによって利用して、こ
れらソースとターゲットの論理ユニット間でセッション
を確立する。

【０００９】前記特許のプロセスの詳細は、本発明の明
細書文中に取り込まれている。ここで重要なことは、前
記特許で教示された所在確認プロセスが、所在確認サー
チを全てのターゲット論理ユニットを有するノードに完
全に伝えることであって、これは、介在するネットワー
ク・ノードがこのターゲット資源に関する蓄積情報を保
有するかどうかに関係なく行われることである。この完
全な所在確認サーチにおいては、すべてのサーチの結果
として、最新の資源の所在または特性情報が得られると
いう利点がある。

【００１０】

【発明が解決しようとする課題】しかしながら、いかな
る場合においても、完全な所在確認サーチを実行すれ
ば、必ず不都合が生じる。例えば、完全な所在確認サー
チが完了するのを待つことによって、セッションの確立
を遅延させてしまう。更に、完全な所在確認サーチに
は、ネットワーク時間が必要であるため、ネットワーク
・トラフィックの「オーバヘッド」が増大してしまう。
こうしたネットワーク時間は、サーチが必要としない場
合には、エンド・ユーザ間のデータの伝送に振り向ける
ことができる。

【００１１】

【課題を解決するための手段】本発明は、ネットワーク
資源を動的に所在確認できるシステムを提供することを
目的とするもので、ここではこの資源の所在および特性
を常時、検証する必要はない。本発明によって実行され
る所在確認サーチは、いかなる場合においても、ターゲ
ット資源まで及ぶものではない。

【００１２】本発明は、エンド・ノード、ネットワーク
・ノードおよびこれらノードの各々と関連する資源を有
するコンピュータ・ネットワークで実施されるものであ
る。各エンド・ノードは、少なくとも１つのネットワー
ク・ノードによってサービスを受ける。ネットワーク・
ノードには、ネットワーク中の資源の少なくとも数個の
所在および特性に関する情報のキャッシュ・ディレクト
リが設けられている。本発明は、あるネットワーク・ノ
ードに関連するソース論理ユニットと、同一または別の
ネットワーク・ノードに関連するターゲット論理ユニッ
トとの間にセッションを確立するための方法またはシス
テムに関するものである。

【００１３】この方法によれば、所在確認要求がソース
論理ユニットで生成される。所在確認要求は、ターゲッ
ト資源を指定するためのものであり、ターゲット資源の
所在および特性を、この要求に応答して検証すべきかど
うかを示すフラグが設けられている。この所在確認要求
は、ソース・ノードにサービスするネットワーク・ノー
ドに伝送され、以下の一連の操作によって処理される。
即ち、ネットワーク・ノードが、ターゲット資源に関す
る何らかのエントリを見つけるためにそれ自身のキャッ
シュ・ディレクトリをサーチする。エントリが見つから
ない場合には、このネットワーク・ノードは、このネッ
トワーク中の他のノードに対しサーチを指示する。エン
トリが見つかった場合には、所在確認要求中のフラグが
チェックされ、検証が必要であるかどうか調べられる。
もし、検証が必要でなければ、所在確認応答が、このネ
ットワークを介して、ソース資源にサービスするネット
ワーク・ノードに戻される。検証が必要であれば、この
所在確認要求を、キャッシュ・エントリ中でターゲット
資源を含むものとして認識されたノードに送る。

【００１４】

【実施例】図１は、代表的なコンピュータ・ネットワー
クを表しており、ここでは、“所在確認プロセス”を利
用して、ターゲット資源の所在をつきとめることができ
る。本発明においてネットワークおよびその構成要素を
記述するために使用される用語は、システム・ネットワ
ーク・アーキテクチャ（ＳＮＡ）と称される周知のコン
ピュータ・アーキテクチャを実施するコンピュータ・ネ
ットワークを記述するために用いられる用語に一致す
る。

【００１５】このＳＮＡアーキテクチャに関する広範な
説明は、多数の文献に見られ、これら文献には、ＩＢＭ
ＳｙｓｔｅｍｓＮｅｔｗｏｒｋＡｒｃｈｉｔｅｃ
ｔｕｒｅ−ＦｏｒｍａｔａｎｄＰｒｏｔｏｃｏｌ
ＲｅｆｅｒｅｎｃｅＭａｎｕａｌ：Ａｒｃｈｉｔｅ
ｃｔｕｒｅＬｏｇｉｃ（ＳＣ３０−３１１２），また
はＳＮＡ：ＩＢＭ’ｓＮｅｔｗｏｒｋｉｎｇＳｏ
ｌｕｔｉｏｎ，ＪａｍｅｓＭａｒｔｉｎおよびＫａｔ
ｈｌｅｅｎＫ．Ｃｈａｐｍａｎ著，Ｐｒｅｎｔｉｃｅ
−Ｈａｌｌ社，ＥｎｇｌｅｗｏｏｄＣｌｉｆｆｓ，Ｎ
Ｊ州，米国がある。このような文献によって、読者はＳ
ＮＡの詳細を知得できるが、これら文献は、本発明を実
施したり理解する上で必要なものではない。従って、こ
れら文献の内容を、参考として本願明細書に組込むこと
はしない。

【００１６】ブロック１０は、第１ネットワークを表
し、このネットワークは、一組のネットワーク・ノード
１２Ａ〜１２Ｅおよびもう一組のエンド・ノード１４Ａ
〜１４Ｍならびにセントラル・ディレクトリ・ノード１
６を有している。

【００１７】ネットワーク１０を、ネットワーク・ノー
ド２０によって部分的に表されたネットワーク１８のよ
うな他のネットワークにリンクすることができる。これ
ら２つのネットワークは、ゲートウェイまたはインタフ
ェース・ノードとして知られている特別なネットワーク
・ノード２２を介してリンクされる。

【００１８】エンド・ユーザは、ソース論理ユニットと
ターゲット論理ユニットとの間で確立されたセッション
を介して行われる会話によって互いに通信を行う。第１
のノードが“ＢＩＮＤ要求”を第２のノードへ送信した
場合に、セッションが確立される。このＢＩＮＤ要求に
よって、セッションの継続時間中、双方のノードが従う
プロトコルを指定する。ＢＩＮＤの送信側は一次論理ユ
ニット又はＰＬＵとして知られ、他方、ＢＩＮＤの受信
側は二次論理ユニット又はＳＬＵとして知られている。

【００１９】セッションを確立するためには、各資源
（ソースおよびターゲット）の所在および特性を最初に
知る必要がある。これら所在および特性の情報を、エン
ド・ノード、ネットワーク・ノードおよびセントラル・
ディレクトリ・ノードにおけるディレクトリに記憶する
ことができる。ゲートウェイ・ノードのように、セント
ラル・ディレクトリ・ノードは特別なネットワーク・ノ
ードである。セントラル・ディレクトリ・ノードは、大
容量のキャッシュ・ディレクトリを有しており、これに
よってネットワーク中に配置された資源についての情報
を記憶する。すべてのノードはそれ自身の資源に関する
情報を含むローカル・ディレクトリを有する。ネットワ
ーク・ノードの場合に、このローカル・ディレクトリ
（“ドメイン・ディレクトリ”とも呼ばれる）には、ネ
ットワーク・ノードの資源に関する情報およびこのネッ
トワーク・ノードがサービスする各エンド・ノードの資
源に関する情報が含まれている。また、一般に、ネット
ワーク・ノードはキャッシュ・ディレクトリまたはクロ
ス・ドメイン・ディレクトリを有しており、このディレ
クトリには、このネットワークまたはゲートウェイ・ノ
ードを介して接続された他のネットワークに配置された
資源に関する情報が含まれている。

【００２０】キャッシュ・エントリを、種々の方法で累
積することもできる。その一方法では、システムまたは
ネットワークが最初に規定されるときに、キャッシュ・
ディレクトリに資源情報をロードする。また別の方法に
よれば、初期のサーチまたは所在確認処理の結果を保持
する。システムの規定中に初期に設けられたキャッシュ
・エントリは、次の所在確認処理の結果として変更また
は削除することもできる。更に、所在確認処理によっ
て、キャッシュ・ディレクトリにシステムの規定時には
存在しなかった資源を追加することもできる。

【００２１】所在確認処理は、所在確認メッセージを利
用することによって実行され、これらメッセージは、Ｓ
ＮＡ基本リンク・ユニットまたはＳＮＡフレームを用い
て送信される。図２は、一般的なＳＮＡフレームのフォ
ーマットを示し、このフォーマットには多重フィールド
またはユニットが含まれている。各フレームには、デー
タ・リンク・コントロール（ＤＬＣ）ヘッダ２４、伝送
ヘッダ（ＴＨ）２６、要求／応答ヘッダ（ＲＨ）２８、
要求／応答ユニット（ＲＵ）３０、およびＤＬＣトレイ
ラ３２が含まれている。簡単に説明すれば、ＤＬＣヘッ
ダ２４とＤＬＣトレイラ３２を用いて、隣接する２つの
ノード間で、これらノードを接続する特定の物理的メデ
ィアを介してフレームが伝送されるのを制御すると共
に、伝送中に発生する可能性のあるエラーから回復する
ようにする。一方、伝送ヘッダ２６には、このフレーム
をマルチノード・パスを介して伝送するのに必要なパス
制御情報と、ソースおよびデスティネーション・アドレ
ス情報が含まれている。要求／応答ヘッダ２８には、次
の要求／応答ユニット３０に関する制御情報が含まれて
おり、これによってフレーム中で生成される要求または
応答を規定する。フレーム中の各々に関する詳細につい
ては、前述した参考文献中に記載されている。

【００２２】この明細書は、時々、所在確認要求フレー
ムまたは所在確認応答フレームに言及する。ここで留意
すべきことは、こうした言及は特別なフレームの存在を
示すものではなく、所在確認要求または所在確認応答を
たまたま含んだ従来のフレームを言及するための簡単な
方法であることに留意すべきである。

【００２３】図３は、ネットワーク資源をサーチするた
めに生成された所在確認要求（ＬＯＣＲＱ）を搬送する
ＳＮＡフレームを表すものである。この所在確認要求の
特徴部分は、フレームを所在確認要求フレームとして認
識する要求／応答ユニット・フィールド３４である。フ
ィールド３４にはＶＮＲ（検証不要：ＶｅｒｉｆｙＮｏ
ｔＲｅｑｕｉｒｅｄ）フィールドまたはＶＮＲフラグ
が含まれ、これらは本発明を実施するために必要であ
る。この検証不要フラグは、所在確認要求フレームを受
信するあらゆるネットワーク・ノードに対する表示であ
り、この要求をターゲット資源を保有するノードに送る
ことによって、ターゲット資源の所在および特性を必ず
しも検証する必要はないということを示すものである。
ネットワーク・ノードが、このターゲット資源に関する
キャッシュ・エントリを有する場合には、このノードは
所在確認要求に直接応答することができる。所在確認要
求がその検証不要フラグをセットした状態で生成される
条件、およびネットワーク・ノードが検証なしで所在確
認応答（ＬＯＣＲＰ）を与える条件について、図を参照
しながら説明する。

【００２４】図４は、所在確認応答に好適なＳＮＡフレ
ームを示す。この所在確認応答フレームの特徴は、ター
ゲット資源およびＶＮＰ（検証不実行：Ｖｅｒｉｆｙ
ＮｏｔＰｅｒｆｏｒｍｅｄ）フラグに関する情報を有
する要求／応答ユニット３６がこのフレーム中に含まれ
ていることである。検証不実行フラグが所在確認応答に
セットされると、この所在確認応答を受信するノード
は、この所在確認応答がネットワーク・ノードによって
生成される前に、ターゲット資源の所在および特徴が検
証されなかったことを認識する。

【００２５】図５は、所在確認プロセスのハイレベル・
フローチャートである。基本的な所在確認処理は、前述
した米国特許第４，９１４，５７１号明細書に説明され
ている。基本的な所在確認処理と本発明に係るオペレー
ションとの間の差異は図面の説明に組込まれている。

【００２６】本発明によれば、所在確認要求を生成する
ノードは、検証不要フラグをセットして要求を生成し、
検証は常時必要とされないことを指示する。この検証不
要フラグがセットされる条件は図６を参照しながら後述
する。

【００２７】所在確認要求がエンド・ノードに配置され
た資源によって生成されると、所在確認プロセス中の初
期オペレーションはフローチャートのオペレーション３
８であり、ここでは所在確認要求中で指定されたターゲ
ット資源についての情報用のローカル・ディレクトリ
を、エンド・ノードがサーチする。エンド・ノードの各
々には、それ自身の資源についてのみの情報が含まれて
おり、エンド・ノードはこれら資源の所有者であると考
えられる。ソース資源およびターゲット資源が同じエン
ド・ノードによって保有される場合には、所在確認要求
中の検証不要フラグがセットされたかどうかは重要なこ
とでない。

【００２８】ターゲット資源がソース資源と同じエンド
・ノードにおいて存在しないと仮定すると、この所在確
認要求がネットワーク・ノードに送られ、このノードか
ら、生成元エンド・ノードに指示が与えられる。次に、
オペレーション４０において、ネットワーク・ノード
は、ターゲット資源に関するエントリを見つけるために
ドメイン・ディレクトリをサーチする。このドメイン・
ディレクトリには、ネットワーク・ノードによって直接
保有された資源についてのエントリと、このネットワー
ク・ノードに直接付加されたエンド・ノードによって保
有されるものであると判っている資源についてのエント
リとが含まれている。ターゲット資源についてのエント
リがドメイン・ディレクトリ中に見つかり、検証不要フ
ラグが所在確認要求にセットされている場合、ネットワ
ーク・ノードは、適切であれば、検証不実行フラグをセ
ットして、所在確認応答を生成元ノードに直接返す。こ
れはターゲット資源を保有するノードに所在確認応答が
送られず、従ってターゲット資源の所在および特性が検
証されなかったことを表す。

【００２９】ターゲット資源エントリが生成元ネットワ
ーク・ノードのドメイン・ディレクトリ中に見つからな
い場合には、クロス・ドメイン・ディレクトリをオペレ
ーション４２でサーチする。このサーチは、他のノード
のドメイン・ディレクトリ中に存在する資源に関するキ
ャッシュ・エントリを見つけるためのものである。この
クロス・ドメイン・サーチによって、ターゲット資源に
関するエントリを見つけた場合には、検証を必要としな
いものと判定されたならば、所在確認応答を生成元エン
ド・ノードに戻すこともできる。ターゲット資源に関す
るエントリが見つからなければ、この生成元のネットワ
ーク・ノードによって、所在確認要求をそのドメイン中
のエンド・ノードの各々に同報通信し（オペレーション
４４中に）、これによって所在確認処理がサポートでき
るようになる。コンピュータ・ネットワーク中のすべて
のエンド・ノードが必ずしも同一能力を保存する必要は
ない。いくつかのエンド・ノード、特に古いノードは、
所在確認処理をサポートすることができないので、前記
の要求をそのようなノードに同報通信することは無駄な
ことになる。

【００３０】ターゲット資源が、ドメイン中のエンド・
ノードをサポートするための同報通信サーチの後に、見
つかった場合には、所在確認応答がこの資源を保有する
エンド・ノードによって生成される。所在確認応答中の
検証不実行フラグを、ターゲット資源に関する情報が検
証されたことを示すようにリセットする。

【００３１】オペレーション４４で、ドメイン中のター
ゲット資源を見つけられなかった場合に、セントラル・
ディレクトリ・ノードがネットワーク中に規定されたも
のと仮定して、オペレーション４６でこのサーチをセン
トラル・ディレクトリ・ノードに対して行う。このセン
トラル・ディレクトリ・ノードがターゲット資源につい
てのキャッシュ・エントリを有するならば、このセント
ラル・ディレクトリ・ノードは必要に応じネットワーク
を介して、検証不実行フラグをセットして所在確認応答
を戻すことができる。

【００３２】このターゲット資源がセントラル・ディレ
クトリ中に見つからないものと仮定すると、次のオペレ
ーション４８では、所在確認サーチ要求が、ネットワー
ク中の他のネットワーク・ノードに同報通信されるよう
に要求される。このような同報通信オペレーションが存
在する場合に、これは、セントラル・ディレクトリ・ノ
ードによって実行される。セントラル・ディレクトリ・
ノードが規定されていない場合には、ソース資源を含む
ノードにサービスするネットワーク・ノードによって、
この同報通信オペレーションが実行される。

【００３３】ネットワーク・ノードがターゲット資源に
ついてのキャッシュ・エントリを有しており、かつ検証
が必要でない場合、同報通信サーチを受けるネットワー
ク・ノードは、所在確認応答を直接戻すことができる。

【００３４】本発明の一実施例によれば、ソース資源ま
たはターゲット資源にサービスするネットワーク・ノー
ドのみが、検証なしで所在確認応答を戻すことができ
る。また他の実施例によれば、適当なキャッシュ・エン
トリを有するネットワーク・ノードも検証なしでこの所
在確認応答を戻すことができる。このノードが検証なし
で所在確認応答を戻したとしても、これとは別にこのノ
ードは、所在確認要求を隣接のネットワーク・ノードに
与えて、隣接ネットワーク・ノードに自分自身ノデータ
を確認させ、応答を返すようにさせることが出来る。検
証無しで所在確認応答を受けたソース資源は一応それを
信頼するが、事実はそれに反することもある。もっと
も、実際には信頼に反しないことの方が大いにあり得る
ことである。従って、隣接ネットワーク・ノードに確認
させてその結果を確かめることにより誤った信頼状態を
回避することができる。

【００３５】前述した同報通信サーチの結果、ネットワ
ーク中にターゲット資源がネットワーク・ノードによっ
て見つからない場合には、オペレーション５０におい
て、所在確認要求をゲートウェイ・ノードを介して第２
のネットワークへ送る。このゲートウェイ・ノードに直
結されている第２のネットワーク内のネットワーク・ノ
ードがターゲット資源についてのキャッシュ・エントリ
を有しており、かつ検証が必要でないものと判定した場
合に、このネットワーク・ノードによって所在確認応答
を生成し、これをゲートウェイ・ノードを介して、第１
ネットワーク中の生成元ネットワーク・ノードに戻す。
そうでなければ、この所在確認要求を、第１のネットワ
ーク中で実行したオペレーションと同一または類似の一
連のオペレーションを用いて第２ネットワークを経て伝
送する。

【００３６】図６は、本発明により、所在確認要求を生
成するノードで実施されるステップのフローチャートで
ある。このノードはソース資源をサポートするエンド・
ノードまたはネットワーク・ノードである。同一の基本
的ステップが行われると、いずれのタイプのノードにお
いても所在確認要求が生成される。

【００３７】所在確認要求が必要とされると仮定する
と、一次論理ユニット、即ちＰＬＵによって開始される
セッションを確立する場合に、この要求が用いられるか
どうかを調べるチェック５２が実行される。ある限定さ
れた条件の下で、二次論理ユニット、即ちＳＬＵによっ
てセッションの確立が要求されることもある。本例では
重要でない理由によって、ＳＬＵによって開始されるセ
ッションに対しては資源検証が常時必要となる。

【００３８】次のセッションがＰＬＵによって開始され
ることが分かるとこのセッションは、ＢＩＮＤ失敗を許
容できるタイプのものであるかどうかのチェック５４が
実行される。ＢＩＮＤ失敗とは、セッションを首尾よく
確立することができない失敗のことである。あるタイプ
のセッションがこのＢＩＮＤ失敗を許容するものと考え
られるが、これには、サーチ・オペレーション用に使用
されるセッション、オペレーション開始に使用されるセ
ッションおよび開始又は待ち行列の操作に使用されるセ
ッションが含まれる。

【００３９】セッションがＢＩＮＤ失敗を許容できない
か、または、セッションがＰＬＵで開始されない場合
に、検証不要フラグがリセット値を有する所在確認要求
が、オペレーション５８で発行される。次の所在確認プ
ロセスは、米国特許第４，９１４，５７２号明細書に記
載されているように実質的に実行される。通常のセッシ
ョン確立プロセス６０が続いて行われる。

【００４０】オペレーション５２と５４がＹＥＳなら
ば、検証が生成元ノードによって要求されない。オペレ
ーション６２において、検証不要フラグＶＮＲが所在確
認要求ＬＯＣＲＱ中にセットされ、この要求がネットワ
ーク・ノードに与えられ、ここでは所在確認要求がエン
ド・ノードで生成される。この要求がネットワーク・ノ
ードで直接生成される場合に、この要求を送るステップ
は明らかに必要としないものである。

【００４１】次に、この生成元ノードは、要求したセッ
ションを確立するための次のステップをとる前に、ブロ
ック６４によって示されるように所在確認応答ＬＯＣＲ
Ｐを待つようになる。オペレーション６６が、受信した
所在確認応答はセッションの確立をサポートしないこと
を表す場合には、このプロセスは終了したことになる。
セッションの確立をサポートしない所在確認応答には、
ターゲットが見つからないか、または見つかったが現在
アクセスできないことを表す応答が含まれている。しか
しながら、所在確認応答がセッションの確立をサポート
する場合には、通常のセッション確立プロセスがオペレ
ーション６８で続行される。

【００４２】もしセッションの確立が成功しなならば、
失敗がＢＩＮＤプロセスに起因したものであるかのチェ
ック７０が行われる。もし起因したならば、初期の所在
確認応答中の検証不実行（ＶＮＰ）フラグの状態がオペ
レーション７１でチェックされる。このフラグ状態によ
って、ターゲット資源に関する情報が所在確認プロセス
中に検証されたことを表す場合には、このほかに何も行
われない。しかし、ターゲット資源情報が、初期の所在
確認プロセス中で検証されなかったことがわかった場合
には、オペレーション７２で、所在確認要求中の検証不
要フラグが生成元ノードによってリセットされると共
に、所在確認要求が再発行される。この再発行された所
在確認要求がターゲット資源の所在および特性を検証す
ることを要求する。チェック７０によって、ＢＩＮＤが
ＶＮＦ機能の利用以外の他の理由のために失敗したこと
を表す場合に、このセッションを確立するためのあらゆ
る試みが中止されると共に、このプロセスが終了する。

【００４３】図７，図８は、所在確認要求を受信するネ
ットワーク・ノードで実行されるステップのフローチャ
ートである。この受信用ネットワーク・ノードによっ
て、所在確認要求中のソース情報が利用され、これによ
ってオペレーション７４でソースについてのキャッシュ
・エントリを生成または更新する。次に、ターゲット資
源がネットワーク・ノードのドメイン・ディレクトリ中
にあるかどうかのチェック７６が実行される。

【００４４】オペレーション７６において、ドメイン・
ディレクトリがターゲットについてのエントリを持たな
い場合には、そのようなエントリがネットワーク・ノー
ドのクロス・ドメイン・ディレクトリ中に存在するかど
うかのチェック８０が実行される。ターゲット資源につ
いてのエントリがクロス・ドメイン・ディレクトリ中に
存在しない場合に、所在確認要求はオペレーション８２
で、所在確認要求をサポートするドメイン中のエンド・
ノードに同報通信される。次に、ネットワーク・ノード
は、これらエンド・ノードからの応答ＬＯＣＲＰを待
つ。チェック８４によって、これらエンド・ノードの１
つが、ターゲット資源の所有者として応答したことを確
認する場合、ネットワーク・ノードはオペレーション８
６で、ターゲット資源に関する情報をそれ自身のドメイ
ン・ディレクトリ中に蓄えると共に、所在確認応答を要
求を送ったノードに与えるようになる。

【００４５】ターゲット資源をドメイン中に見つけられ
ないと、同報通信サーチがオペレーション８８で開始さ
れると共に、同報通信ノードがこれらノードからの所在
確認応答を待つようになる。前述したように、所在確認
要求が直ぐ隣りのノードを越えて同報通信される。ま
た、セントラル・ディレクトリ・ノードがネットワーク
中に規定されない場合に、同報通信サーチがソース資源
にサービスするネットワーク・ノードによって実行され
る。セントラル・ディレクトリ・ノードが規定される場
合には、このノードによって同報通信サーチが開始され
る。

【００４６】チェック９０によって、同報通信ノードが
少なくとも１つの肯定所在確認応答を受信できたことが
表されると、即ち、ターゲット資源が見つかったことが
表されると、この所在確認応答中の情報を利用してオペ
レーション９２でキャッシュ・エントリを生成する。ノ
ードは、多数の肯定応答を受信することがある。最初の
応答の後のすべての応答をノードによって無視する。次
に、所在確認応答を要求を送ったノードへ送る。ターゲ
ット資源が見つかった事実は、現在、資源が利用できる
ものであることを必ずしも表すものではない。これは、
資源は存在するが、一時的にアクセス不可能なものであ
ることを意味することもある。

【００４７】ターゲット資源がネットワーク中のいずれ
のノードに対しても知られていないということがあり得
る。一般に、未知の資源とは、一度存在していた資源で
あるが、ある理由によってネットワークより除外してし
まった資源である。チェック９０によって、同報通信の
結果として、肯定所在確認応答が受信されないことが示
されると、未知のターゲットを表す否定キャッシュ・エ
ントリをオペレーション９４で生成すると共に、適当な
センス・コードまたは値を有する所在確認応答を要求を
送ったノードへ与える。オペレーション９２または９４
の完了によって、所在確認プロセス内でのネットワーク
・ノードの参加が終了する。

【００４８】オペレーション７６と８０に戻り、いずれ
かのオペレーションによってネットワーク・ノードにお
けるディレクトリにターゲット資源についてのエントリ
を含むことが示されると、このディレクトリ・エントリ
の“古さ”をオペレーション９６でチェックする必要が
ある。資源についてのディレクトリ・エントリには、こ
のエントリの生成または更新時に、タイマ値が割当てら
れる。このタイマ値は、エントリ中の情報が有効である
とみなされる時間を表している。この時間が、エントリ
のアクセス前に経過したならば、このエントリは、古過
ぎて信頼できないものとみなされる。

【００４９】このエントリのタイマが経過してしまって
いるならば、ネットワーク・ノードはキャッシュ・エン
トリ中の情報を利用して、所在確認要求（オペレーショ
ン９８）を、ターゲット資源を所有するものとして認識
されたノードへ与える。この所在確認要求は、検証不要
フラグを変更することなく、指示されたサーチに向けて
送り出される。前記ノードは、この指示されたサーチに
対しての応答を待たねばならない。

【００５０】所在確認応答が受信されると、ディレクト
リ・エントリがオペレーション１００で更新される。所
在確認応答を、この応答中の検証不実行フラグを変更す
ることなく、要求を送ったノードに与える。オペレーシ
ョン１００は、所在確認プロセスにおけるネットワーク
・ノードの参加を終了する。

【００５１】オペレーション９６に戻り、このオペレー
ションによってディレクトリ・エントリ・タイマが経過
していないことが示されると、チェック１０２が実行さ
れ、このディレクトリ・エントリは、同一ターゲットに
対してなされた以前の所在確認処理が、資源を見つける
ことに失敗したことを示すかどうかが調べられる。即
ち、この資源が未知であるものとして前もって認識され
ていたかどうかが調べられる。“未知資源”のディレク
トリ・エントリが見つかると、否定所在確認応答が適当
なセンス・コードと共に要求を送ったノードに戻され
る。この結果、ネットワーク・ノードの所在確認プロセ
ス中での参加が完了する。

【００５２】しかしながら、チェック１０２によって、
資源が知られていることが示されると、更に、チェック
１０６が実行され、資源がエントリによってアクセス不
能として認識されるかどうかを調べる。例えば、資源が
すでに利用されていれば、恐らく、他のセッションに対
して利用できない（アクセス不能である）。資源がアク
セス不能と認識されると、所在確認応答をオペレーショ
ン１０８で適切なセンス・コードで要求を送ったノード
に戻す。オペレーション１０８の完了によって、このノ
ードでの所在確認プロセスが終了する。

【００５３】一方、チェック１０６によって資源がアク
セス不能として認識されない場合には、本発明の実施例
では、所在確認要求を処理するネットワーク・ノード
が、ソース・ノードまたはターゲット・ノードに対して
指定されたネットワーク・ノードであるかどうか決定す
るチェック１０７が含まれている。所在確認要求を処理
するネットワーク・ノードが指定されたネットワーク・
ノードであれば、これは所在確認要求をオペレーション
１１０でチェックして、検証不要フラグがセットされた
かどうかを調べる。このフラグがセットされていること
が判ると、ターゲット資源についてのディレクトリ・エ
ントリをオペレーション１１２の所在確認応答に組込ん
で、ソースにサービスするネットワーク・ノードへ、ル
ートおよびセッション情報を与える。つまり、このよう
な指定されたネットワーク・ノードが所在確認要求を処
理するときには、このようなノードはそれがサービスす
るソース・ノードまたはターゲット・ノードを直接支配
しているので、要求が検証不要であるなら検証不実行の
応答を直接返すことが出来る。

【００５４】この所在確認応答を検証不実行フラグと共
に戻すことによって、ネットワーク・ノードについての
所在確認プロセスを完了する。この処理用ネットワーク
・ノードが中間ノードである場合、キャッシュに蓄積さ
れた情報をオペレーション１１４で利用して、この所在
確認要求を適当なノードへ、検証不要フラグの状態に拘
らず与える。このような中間ノードは所在確認要求を上
流のノードから下流のノードへ通過させるだけで自分自
身この要求を処理する立場にない。従って、このような
中間ノードは下流のノードから応答を受けるまで上流ノ
ードに応答を返すことが出来ない。

【００５５】オペレーション１１０に戻り、所在確認要
求中の検証不要フラグがリセットされているものとわか
ると、ネットワーク・ノードは、この要求を、ターゲッ
ト資源として所有しているものとして認識されるノード
に与え（オペレーション１１４）、次に、応答を待つ。
オペレーション１１６によって、ターゲット資源がター
ゲット・ノードに存在することが示されると、資源につ
いてのキャッシュ・エントリを更新する。所在確認応答
をオペレーション１１８で要求を送ったノードに検証不
実行フラグをリセットして戻し、このノードによってタ
ーゲット資源の所在および特性が検証されたことを示
す。

【００５６】オペレーション１１６によって、ターゲッ
ト資源が指示されたサーチ内で見つからない場合には、
このプロセスは、オペレーション８２によって開始され
た通常のネットワーク・サーチ論理を再開する。

【００５７】上述より明らかなように、ネットワーク全
体を包括する所在確認サーチは、すべての事例において
必要とするものではない。ある条件の下で、ネットワー
ク・ノードは所在確認要求を受信すると共に、この要求
に対して直ちに蓄えた情報を利用して応答することがで
きる。検証動作を実行する能力によって、所在確認メッ
セージ専用のネットワーク・トラフィックの量を選択的
に減少できる。

【００５８】図９，図１０，図１１は、ネットワーク中
で実行される所在確認プロセス中に行われる行動を、時
間に基準を置いて表すチャートである。このネットワー
クは、所在確認要求のソースを含む第１エンド・ノード
１２０と、このエンド・ノード１２０にネットワーク・
サービスを提供する第１ネットワーク・ノード１２２
と、ターゲット・ソースを有する第２エンド・ノード１
２４と、このエンド・ノード１２４にサービスを与える
第２ネットワーク・ノード１２６と、更に、第３または
中間ネットワーク・ノード１２８とを有するものとす
る。また、セントラル・ディレクトリ・ノードをこのネ
ットワークに対して規定しないものとする。垂直時間軸
が、図の左隅に描かれており、２０の異なった時間スロ
ットが設定され、これらにおいて、所在確認プロセス中
のステップが実行される。

【００５９】時間Ｔ１において、エンド・ノード１２０
は、所在確認要求を、サービスするネットワーク・ノー
ド１２２に送る。この所在確認要求には、伝送グループ
・ベクトル（ＴＧＶｓ）が含まれており、これらベクト
ルを最小ウェイト・ルート選択プロセス中で利用する。
このルート選択プロセスは、本発明の一部ではないの
で、これ以上詳述しない。時間Ｔ２において、ネットワ
ーク・ノード１２２によって、ターゲット資源がそれ自
身のドメイン中で知られていないことを決定する。ネッ
トワーク・ノード１２２は、所在確認要求をノード１２
８を含んだ隣接のネットワーク・ノードに同報通信す
る。この要求は結局、エンド・ノード１２４に伝送され
る。時間Ｔ３において、エンド・ノード１２４は、資源
が存在するがある期間だけアクセス不能であることを表
す所在確認応答を生成する。この所在確認応答には、エ
ンド・ノード１２４とネットワーク・ノード１２６との
間のリンク用の伝送グループ・ベクトルを含む。ネット
ワーク・ノード１２６が選択的検証を支持する場合に、
このノード１２６によってターゲット資源についての情
報を蓄えると共に、時間Ｔ４において、所在確認応答を
ネットワーク・ノード１２８を介して、ネットワーク・
ノード１２２に与える。また、ネットワーク・ノード１
２８は、この応答中に含まれた情報を蓄える。時間Ｔ５
において、ネットワーク・ノード１２２は、この情報を
蓄えると共に、所在確認応答をソースのエンド・ノード
１２０に戻す。この応答は、ターゲット資源がアクセス
不能であることを表す。

【００６０】その後の時間Ｔ６において、エンド・ノー
ド１２０は所在確認要求を更新すると共に、これをサー
ビス・ネットワーク・ノード１２２に与える。ネットワ
ーク・ノード１２２は、現在、ターゲット資源がアクセ
ス不能であることを表すキャッシュ・エントリを有する
ので、このノードによって否定所在確認応答を時間Ｔ７
にエンド・ノード１２０に戻す。ネットワーク・ノード
１２２は、エンド・ノード１２０に応答する前に、その
キャッシュ・ディレクトリ内に含まれる情報を検証する
ことはない。

【００６１】次に、時間Ｔ８において、エンド・ノード
１２０は同一ターゲット資源に対してもう１つの所在確
認要求を送る。この時間Ｔ８までに、タイマは、ネット
ワーク・ノード１２２のキャッシュ・エントリに対して
満了したものとする。ネットワーク・ノード１２２は、
時間Ｔ９に、サーチをこのキャッシュ・エントリで認識
したエンド・ノード１２４に対して指示することによっ
て、新しい所在確認要求に応じる。このターゲット資源
が利用可能となると、エンド・ノード１２４は、時間Ｔ
１０において、ベクトルと共に、肯定所在確認応答を生
成する。このベクトルは、資源が利用できる期待時間の
長さを表す。所在確認応答が時間Ｔ１１にネットワーク
を介して伝わるので、ネットワーク・ノードの各々は、
応答中に含まれる情報（時間情報を含む）を蓄えるよう
になる。他に問題が生じないものと仮定して、セッショ
ンをエンド・ノード１２０と１２４との間に確立する。
これは、所在確認応答が時間Ｔ１２にエンド・ノード１
２０に到達した時に行われる。

【００６２】同一の所在確認要求が後の時間Ｔ１３に生
成された場合に、検証不要フラグによって、検証が生成
元ノードによって要求されないことを表示する。この所
在確認要求を、サービスするネットワーク・ノード１２
２で受信すると、このノードは、蓄えた情報を用いて、
時間Ｔ１４に直ちに応答するようになる。検証不実行フ
ラグをこの応答中にセットする。

【００６３】資源がアクセス不可能となったために、時
間Ｔ１５に、次のＢＩＮＤが失敗するものとする。所在
確認要求を時間Ｔ１６で再発行すると、発行元エンド・
ノード１２０によって、この要求中の検証不要フラグを
リセットする。リセットされた検証不要フラグに応答し
て、ネットワークはその通常のネットワーク・サーチ・
ロジックを、時間Ｔ１７，Ｔ１８，Ｔ１９およびＴ２０
で実行する一連のステップにおいて実行するようにな
る。通常のネットワーク・サーチ論理によって、所在確
認要求がエンド・ノード１２４に伝わるように要求さ
れ、これによってターゲット資源の所在と特性とを検証
することができる。

【００６４】前述した実施例において、ソース・ノード
またはターゲット・ノードにサービスするネットワーク
・ノードは、所在確認応答を検証なしで戻すことができ
る。本発明の他の実施例によれば、ターゲット・ノード
についてのキャッシュ・エントリを有するネットワーク
・ノードであれば、どのネットワーク・ノードでもその
ような応答を戻すことができる。このように検証してい
ない応答を戻すようにするプロセスには、図７および図
８を参照して説明したプロセスに僅かな変更が含まれて
いる。この変更が図１２に図示されており、ここにおい
て、この変更が行われたプロセスの一部分のみが表され
ている。図１２にはオペレーション・ブロック１０
６′，１０８′，１１０′，１１２′および１１４′が
含まれており、これらブロックは、図７および図８の同
様の番号が付されたブロックに対応する。しかしなが
ら、図１２において、所在確認要求を処理するネットワ
ーク・ノードは、ソース・ノードまたはターゲット・ノ
ード用の指定されたネットワーク・ノードであるかどう
かをチェックしない。換言すれば、オペレーション１０
７に相当する動作は、本例では実行しない。適当なキャ
ッシュ・エントリを有するネットワーク・ノードであれ
ば、どのネットワーク・ノードでも検証していない所在
確認応答を提供できるものとする。

【図面の簡単な説明】

【図１】コンピュータネットワークの物理的構成要素の
ブロック図である。

【図２】コンピュータ・ネットワークの好適な形態中の
ノード間に伝送されるフレームまたは基本リンク・ユニ
ットの標準フォーマットを示す図である。

【図３】所在確認要求を含むフレームを示す図である。

【図４】所在確認応答を含むフレームを示す図である。

【図５】本発明を実施する所在確認プロセスのハイレベ
ル・フローチャートである。

【図６】本発明によって所在確認要求を生成するソース
・ノードにおいて実行されるステップのフローチャート
である。

【図７】本発明によって発生させた所在確認要求を受信
した時に、ネットワーク・ノードで実行されるステップ
のフローチャートである。

【図８】本発明によって発生させた所在確認要求を受信
した時に、ネットワーク・ノードで実行されるステップ
のフローチャートである。

【図９】図１０と図１１の配置を示す図である。

【図１０】本発明による所在確認サーチを実行するオペ
レーションの例を示す図である。

【図１１】本発明による所在確認サーチを実行するオペ
レーションの例を示す図である。

【図１２】本発明の他の実施例における変化を表す、図
８のフローチャートの一部を示す図である。

【符号の説明】１０，１８ネットワーク１２Ａ〜１２Ｅ，２０ネットワーク・ノード１６セントラル・ディレクトリ・ノード２２ゲートウェイ２４ＤＬＣヘッダ２６伝送ヘッダ２８要求／応答ヘッダ３０要求／応答ユニット３２ＤＬＣトレイラ

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号庁内整理番号ＦＩ技術表示箇所Ｈ０４Ｌ 12/46 (72)発明者ジェイムス・コービン・フレッチャーアメリカ合衆国ノースキャロライナ州ケリーエコーウッドレーン 102 (72)発明者ジョナサン・ルイス・ハーターアメリカ合衆国ノースキャロライナ州ラレイブリッジポートドライブ 1809 (72)発明者ジェフリー・ゲール・ナウスアメリカ合衆国ノースキャロライナ州ラレイホワイトバッドドライブ 5914 (72)発明者ダーク・クラウス・クレイマーアメリカ合衆国ノースキャロライナ州ラレイセントメリーズストリート 2704 (72)発明者マイケル・アーサー・ラーナーアメリカ合衆国ノースキャロライナ州ラレイハーバーロード 8609 (72)発明者ジョセフ・リー・マッキノンアメリカ合衆国ノースキャロライナ州ラレイヒルブロウレーン 1421 (72)発明者リー・マーク・ラファロウアメリカ合衆国ノースキャロライナ州チャペルヒルパウダーミルロード 4512 (72)発明者ウィリアム・エドワード・シダルアメリカ合衆国ノースキャロライナ州チャペルヒルオールドポストロード 942 (72)発明者メリンダ・ポラード・スタンプアメリカ合衆国ノースキャロライナ州ケリーロシュサイドドライブ 313 (56)参考文献特開昭61−136336（ＪＰ，Ａ) 米国特許4914571（ＵＳ，Ａ)

Claims

【特許請求の範囲】

【請求項１】複数個のエンド・ノードと、これらエンド
・ノードの各々にサービスする少なくとも１つのネット
ワーク・ノードと、前記エンド・ノード及び前記ネット
ワーク・ノードに関連する資源とを有し、ネットワーク
・ノードの各々が、ネットワーク中の前記資源の少なく
とも幾つかについて所在および特性に関する情報のキャ
ッシュ・ディレクトリを有するコンピュータ・ネットワ
ークにおいて、前記エンド・ノード及びネットワーク・
ノードの１つにあるネットワーク資源に関連するソース
論理ユニットと、前記エンド・ノード及びネットワーク
・ノードの他の１つにあるネットワーク資源に関連する
ターゲット論理ユニットとの間にセッションの確立を開
始する方法において、（ａ）前記ソース論理ユニットにおいて所在確認要求を
生成するステップであって、前記要求が、前記ターゲッ
ト論理ユニットにあるターゲット資源を指定すると共
に、前記要求への応答中で前記ターゲット資源の所在お
よび特性を検証する必要があるかどうかを示すフラグを
有する如きステップと、（ｂ）前記所在確認要求を、前記ソース論理ユニットを
含むノードに対する前記ネットワーク・ノードに送信す
るステップと、（ｃ）前記ネットワーク・ノードで前記所在確認要求を
処理するステップと、を含むセッション確立開始方法で
あって、前記処理ステップ（ｃ）が、（１）前記ターゲット資源に関する何らかのエントリを
見つけるためにネットワーク・ノードのキャッシュ・デ
ィレクトリをサーチするステップと、（２）前記サーチされたディレクトリ中にエントリが見
つからない場合に、サーチ要求を前記ネットワーク中の
他のノードに与えることによって、このネットワーク内
の他の場所でターゲット資源のサーチを開始するステッ
プと、（３）前記サーチされたディレクトリ中にエントリが見
つかった場合に、この所在確認要求中の前記フラグをチ
ェックして、前記資源の所在および特性が検証されるべ
きであるかを決定するステップと、（４）前記フラグが検証が不要であることを示す場合
に、前記ディレクトリ・エントリの内容に基づく所在確
認応答を前記ソース論理ユニットを含む前記ノードに戻
すステップと、（５）前記フラグが検証が必要であることを示す場合
に、前記ディレクトリ・エントリ中で前記ターゲット資
源を含むものと識別されたノードに前記所在確認要求を
与え、前記ディレクトリ・エントリ中で識別されたノー
ドから前記ディレクトリ・エントリ中の内容を検証した
ものに基づく所在確認応答を受取り、前記ソース論理ユ
ニットを含むノードに前記所在確認応答を戻すステップ
と、を含むことを特徴とするセッション確立開始方法。
【請求項２】前記ソース・ノードにおける所在確認要求
生成ステップ（ａ）が、更に、前記セッションが１次論理ユニットによって開始されよ
うとしているかどうかを調べるステップと、前記セッションが、セッション確立の試みにおいて失敗
を許容できるタイプのものであるかどうかを調べるステ
ップと、前記２つの調べるステップが肯定的な結果を生じた場合
にのみ、前記所在確認要求中に検証不要フラグをセット
するステップと、を含むことを特徴とする請求項１記載のセッション確立
開始方法。
【請求項３】複数個のノードを有するデータ処理ネット
ワークであって、前記ノードの各々が１個またはそれ以
上の関連する資源を有し、前記ノードの少なくとも幾つ
かが、１個またはそれ以上の資源に関する情報を備えた
キャッシュ・ディレクトリを有するデータ処理ネットワ
ークにおいて、前記ノードの２つの間のセッションの確
立を開始する方法であって、（ａ）第１ノードにおいて所在確認要求を生成するステ
ップであって、この所在確認要求がターゲット資源を指
定し、更に、この要求がこの要求への応答中で、ターゲ
ット資源に関する情報を検証すべきであるかどうかを示
すフラグを有する如きステップと、（ｂ）この要求を、キャッシュ・ディレクトリを有する
少なくとも１つの予め決められたノードに伝送するステ
ップと、（ｃ）前記予め決められたノードにおける所在確認要求
を処理するステップとを含み、前記処理ステップ（ｃ）が、更に、（１）前記ターゲット資源に関するエントリを見つける
ために前記予め決められたノードのキャッシュ・ディレ
クトリをサーチするステップと、（２）前記ターゲット資源に関するエントリが見つかっ
た場合に、かつ検証フラグが検証を必要であることを示
す時に、ターゲット資源を含むノードに前記所在確認要
求を送り、ターゲット資源を含むノードで生成されかつ
検証を示す所在確認応答を受取り、該所在確認応答を第
１のノードに送り、検証フラグが検証が必要でないこと
を示す時に、所在確認応答を生成してこれを前記第１ノ
ードへ戻すステップと、（３）ターゲット資源に関するエントリが見つからない
場合に、サーチ照会をネットワーク中の他のノードに与
えることによってターゲット資源を見つけるためのサー
チを開始するステップと、を含むことを特徴とするセッション確立開始方法。
【請求項４】前記予め決められたノードが、前記第１ノ
ードにサービスするネットワーク・ノード、またはター
ゲット資源を含むノードにサービスするネットワークで
あることを特徴とする、請求項３記載のセッション確立
開始方法。
【請求項５】前記第１ノードにおける所在確認要求生成
ステップ（ａ）が、更に、前記セッションが１次論理ユニットによって開始されよ
うとしているかどうかを調べるステップと、前記セッションが、セッション確立の試みにおいて失敗
を許容できるタイプのものであるかどうかを調べるステ
ップと、前記２つの調べるステップが肯定的な結果を生じた場合
にのみ、前記所在確認要求中に検証不要フラグをセット
するステップと、を含むことを特徴とする請求項３または４記載のセッシ
ョン確立開始方法。
【請求項６】複数個のエンド・ノードを含み、各エンド
・ノードが１又は複数の関連する資源を有し、前記ノー
ドの少なくとも幾つかが１又は複数の資源についての情
報を含むキャッシュ・ディレクトリを有するデータ処理
ネットワークにおいて、前記ノードの２つの間にセッシ
ョンの確立を開始するシステムであって、（ａ）第１のノードにおいて所在確認要求を生成する手
段であって、前記要求が、ターゲット資源を指定すると
共に、前記要求への応答中で前記ターゲット資源に関す
る情報を検証する必要があるかどうかを示す検証フラグ
を有する如き手段と、（ｂ）前記所在確認要求を、キャッシュ・ディレクトリ
を有する所定のノードに送信する手段と、（ｃ）前記所定のノードで前記所在確認要求を処理する
手段と、を含み、前記処理手段（ｃ）が、（１）前記ターゲット資源に関する何らかのエントリを
見つけるために前記所定のノードのキャッシュ・ディレ
クトリをサーチする手段と、（２）前記ターゲット資源に関するエントリが見つかっ
た場合に、かつ検証フラグが検証を必要であることを示
す時に、ターゲット資源を含むノードに前記所在確認要
求を送り、ターゲット資源を含むノードで生成されかつ
検証を示す所在確認応答を受取る手段と、（３）前記ターゲット資源に関するエントリが見つかっ
た場合に、かつ検証フラグが検証が必要でないことを示
す時に、所在確認応答を生成する手段と、（４）前記ターゲット資源に関するエントリが見つかっ
た場合に、前記第１ノードに所在確認応答を送信する手
段と、（５）ターゲット資源に関するエントリが見つからない
場合に、前記ネットワーク中の他のノードに所在確認要
求を送ることによって、ターゲット資源のサーチを開始
する手段と、を含むことを特徴とするセッション確立開始システム。
【請求項７】前記予め決められたノードが、前記第１ノ
ードにサービスするネットワーク・ノード、またはター
ゲット資源を含むノードにサービスするネットワーク・
ノードであることを特徴とする、請求項６記載のセッション確立開始システム。
【請求項８】前記第１ノードにおける所在確認要求生成
手段が、更に、前記セッションが１次論理ユニットによって開始されよ
うとしているかどうかを調べる手段と、前記セッションが、セッション確立の試みにおける失敗
を許容できるタイプのものであるかどうかを調べる手段
と、前記２つの決定手段が肯定的な結果を生じた場合にの
み、前記所在確認要求中に検証不要フラグをセットする
手段と、を有することを特徴とする請求項６または７記載のセッ
ション確立開始システム。