JPH0720132B2 - データ通信ネツトワークの制御方法 - Google Patents

Description

【発明の詳細な説明】 A.産業上の利用分野 本発明はデータ通信に関し、さらに詳しくはデータ通信
ネットワーク内の制限付資源（limited resource）セッ
ションをコントロールすることにより、かかるセッショ
ンによって会話を提供する必要がもはやなくなったにも
かかわらずかかるセッションが活動状態（アクティブ）
であり続ける時間を減らす方法に関する。

B.以下の説明のため、通信ネットワークは通信リンクを
介して相互に接続されたノードの集まりだと定義でき
る。ノードはエンド・ノードまたはネットワーク・ノー
ドとして特徴づけられる。ネットワーク・ノードは、ネ
ットワーク内にあって機能を提供するデータ処理システ
ムである。機能の例としては、自分自身と近隣ノードと
の間のメッセージのルーティング、ネットワーク・ノー
ドと直に接続されたエンド・ノードとの間で転送される
メッセージのルートの選択等の提供があげられる。エン
ド・ノードもデータ処理システムであるけれども、普通
その提供する機能はネットワーク・ノードよりも少な
い。エンド・ノードは、ユーザとネットワークの残余と
の間のインターフェースを提供する。ノード間のリンク
は、自己所有またはリース（借用）の回線といったパー
マネント・リンクであってもよいし、必要なときだけ使
用可能になる一時的なリンク（テンポラリ・リンク）で
あってもよい。テンポラリ・リンクの例は、私設または
公共の電話網を介する電話接続である。

セッションが確立するとユーザはネットワークを介しデ
ータをやりとりできる。セッションは、ネットワークを
通るパス（経路）上に存在する。一対のノードに接続さ
れた様々なユーザが、様々なときにセッションを使用す
ることができる。あるときに２つの特定のユーザがセッ
ションを使用しているならそのユーザは会話に関係して
いると言われる。

ネットワーク・ユーザは、普通にはターミナルの所にい
る人間のオペレータだと考えることができる。しかし、
ネットワークの観点から見ると、ネットワーク・ユーザ
は実際にはプログラムである。このようなプログラム
は、ネットワークに接続されたその他のプログラムとの
間でデータのやりとりを行う。ユーザとネットワークと
の間のインターフェースは、ロジカル・ユニットまたは
LUと呼ばれるコンポーネントである。LUはハードウエア
として実行してもよいし、ソフトウエアとして実行して
もよい。あるいは両者の組合せでもよい。特定のユーザ
がセッションを活動化させたり、あるいは非活動化させ
るとき、当該ユーザとネットワークとの間のインターフ
ェースとしてはたらくLUは、１次LUとして識別される。
他方のユーザに関連するLUは、２次LUとして識別され
る。

セッション自体をLUの観点からながめることもできる。
あるLUがセッションの活動化及び非活動化をコントロー
ルするとき（つまり１次LUである）、該セッションはLU
の観点から競合勝者（contention-winner）セッション
として特徴づけられる。他方の、つまり２次LUの観点か
らは、該セッションは競合敗者（contention-loser）セ
ッションとして特徴づけられる。

重要な術語があと２つある。１つは“コントロール・ポ
イント”である。コントロール・ポイントは、ネットワ
ーク構築時に与えられる資源定義文に基づいて、ネット
ワーク資源を活動化する。コントロール・ポイントは、
各ノードに与えられたリンク・ステーションを通じて、
リンクをコントロールし、活動化させ、そして非活動化
させる。もう１つの重要な術語は“コントロール・オペ
レータ”である。これは特殊なタイプのプログラムであ
り、普通は２つのパートナーLU間の活動中のセッション
の数をコントロールしたり、LU−LUセッションの活動化
・非活動化及びLUについてのオペレーティング・パラメ
ータの定義・修正・検査・削除においてLUをアシストす
る機能を営む。

上記の述語は、システム・ネットワーク・アーキテクチ
ャ（SNA）として知られるアーキテクチャを用いるネッ
トワークを記述するのに普通用いられる。アーキテクチ
ャ及び上記述語についてのもっともわかりやすい説明
が、出願人の発刊する以下のマニュアルに載っている。
かっこ内はマニュアル・ナンバーである。Systems Netw
ork Architecture Technicical Overview（GC30-3073-
2）、Systems Network Architecture Concepts and Pro
ducts（GC30-3073-3）、Systems Network Architecture
-Format and Protocol Reference Manual:Architecture
Logic for Type 2.1 nodes（SC30-3422-0）、Systems
Network Architecture-Transaction Programmer's Refe
rence Manual for LU tYPE6.2（GC30-3084-2） LU-LUセッションが確立され終了するプロセスはよく知
られている。プロセスは、ユーザがALLOCATE（割当）命
令を自身のLUに送ることから始まる。このALLOCATE命令
には一定のパラメータが与えられる。パラメータには、
リモート・ユーザの位置にあるリモートLUの名前、２つ
のユーザ間での会話に割り当てられるセッションの特
性、及びリモート・ユーザの名前、等を含む。一次LUは
ALLOCATION命令に応答して、自己開始リクエスト（INIT
−SELF）をコントロール・ポイントに送る。ALLOCATE命
令に与えられたパラメータは、コントロール・ポイント
へ渡される。コントロール・ポイントは、ローカル及び
リモートのユーザ間の会話を提供するのにネットワーク
資源が使用可能であるとこを確め、ネットワークを貫く
ルートを算出し、コントロール・イニシエイトつまりCI
NITレスポンスの形でルート情報を一次LUへ返す。

ネットワークが２ユーザ間の会話を提供できる場合、一
次LUはBINDリクエストを出し、ネットワークを介してリ
モートLUに伝える。BINDリクエストは、セッションのた
めに提案されたパラメータを運ぶ。リモートLUは、提案
されたパラメータを受諾することで応答してもよいし、
あるいは代替パラメータを提案することで応答してもよ
い。元の、または代りのパラメータが両方のLUにとって
受諾可能なものであるならば、１次LUはローカル・ユー
ザにALLOCATEリターン・コードを送り、ローカル・ユー
ザに対して会話がセッションに割り当てられたことを知
らせる。しかる後、２つのユーザは使用可能なデータ・
プロトコールを用いてデータを交換する。ユーザの一方
はDEALLOCATE（割当解除）命令を出して会話を終わらせ
る。当該ユーザのLUは、該命令に対して、他方のユーザ
に送られる最後のデータ・ユニットのヘッダにCEBフィ
ールドを含めることによって応答する。CEBフィールド
は、該セッションが２つのユーザの間の会話を提供する
のにもはや必要とされないことを表示する。

それにもかかわらず、セッションはネットワーク・コン
トロール・オペレータがDEACTIVATE SESSION（セッショ
ン非活動化）リクエストを出すまで活動中であり続け
る。DEACTIVATE SESSIONリクエストを受け取ると、１次
LUはUNBIND SESSION（セッション・バインド解除）リク
エストをリモートLUに送る。

C.解決すべき問題点 現在のセッション活動化・非活動化プロセスには、セッ
ションに対するニーズ（需要）が実際に終了してからし
ばらくしないとネットワーク・コントロール・オペレー
タ・アクションが生じないという問題点がある。セッシ
ョンを提供するリンクが、自己所有またはリース（借
用）の回線であるならば、現実に必要とされる時間より
も長くセッションを維持しても大した問題ではない。し
かしながら、リンクが交換式（Switched）リンクのよう
な制限付資源リンクであるならば、ニーズがなくなった
後もこれらのリンクを介してセッションを維持すること
は、ネットワークに負担をかけることになる。

負担がどのようなものになるかは、リンクのタイプ次第
である。制限付資源リンクが交衆の交換式電話網を通る
交換式リンクであるならば、負担は不必要な料金、ある
いはその他の所望のセッションを提供する電話網施設
（ファシリティ）の使用不可能という形をとるだろう。
制限付資源リンクのその他のタイプとしてはX.21、X.25
及びトークン・リング・リンクがあり、これらは共用ア
クセス・リンクとして特徴づけられる。これらのリンク
がもはや会話を提供するのに使われていないのにセッシ
ョンに専用されているならば、該リンクを別のノードに
再割当することができない。

D.問題点を解決するための手段 本発明は、ユーザとネットワークの間にさしはさまれた
ロジカル・ユニットがユーザまたはセッションをコント
ロールするコントロール・オペレータからのリクストに
応答するように構成されたデータ通信ネットワークで実
行される方法の形で具現化される。ユーザは、セッショ
ンを介して会話に関係し、データを交換する。各セッシ
ョンは、シリアルにつながれたリンクとノードを横断し
てデータ・パスを形成する。本発明法によれば、ロジカ
ル・ユニットが、制限付資源リンクを用いて伝えられる
セッションの非活動化をコントロールできるようにな
る。

活動時において、各セッションは、当該セッションに所
定の特性を持つリンクが１つ以上具備される場合には第
１のタイプとして表示される一方、当該セッションが上
記所定の特性を持つリンクを全く持たない場合には第２
のタイプとして表示される。セッションを第１のタイプ
または第２のタイプとして表示することを除いて、セッ
ションの活動化は公知のプロトコール及び手順に従って
行われる。セッションがユーザ間の会話にとってもはや
必要でないと判断されると、１次ローカル・ユニット
は、ネットワーク・コントロール・オペレータからのリ
クエストを待たずに、第１のタイプの何れのセッション
をも終了させることができる。セッションが第２のタイ
プならば、該セッションは、ロジカル・ユニットではな
くてネットワーク・コントロール・オペレータのアクシ
ョンに応答して非活動化する。

E.実施例 第１図は、データ通信ネットワークの主要なコンポーネ
ントを示す。ネットワークは、いくつかのノード10、1
2、14、16及び18を含む。各ノードは、データ処理シス
テムとして実行される。これらのノードはデータ・パス
（経路）に含め得るものである。ユーザ20、22はかかる
データ・パスを通じて、ネットワークを介してのデータ
交換を行う。ノードとノードの間はリンクによって結ば
れる。例えば、ノード10と18の間のリンク24の如しであ
る。ネットワーク内の各リンクは、リンク・コネクショ
ン及びそれぞれが接続対象ノード内にあるリンク・ステ
ーションのペアから構成される。図面を参照して説明す
ると、リンク24は物理的メディア26、例えば電話線やマ
イクロウエーブ・ビームを含んでいる。また、ノード10
にはリンク・ステーション28があり、ノード18には別の
リンク・ステーション30がある。

データ通信ネットワークの機能は、例えばユーザ20、22
がネットワークを介してデータをやり取りできるよう
な、経路あるいはパスを確立し、維持することである。
人間の観点からは、ネットワークのユーザは、ワークス
テーションを操作している個人であってもよいし、プロ
グラムであってもよい。ネットワークの観点からは、常
にユーザはプログラムによって表すことができる。とい
うのは、個人がネットワークによって対話するために
は、ユーザのワークステーションで走っているプログラ
ムを介さなければならないからである。各ユーザは、ロ
ジカル・ユニット、つまりLUによって結ばれている。LU
は、データ交換を管理する。詳しくは、LU32はユーザ20
にとってのインターフェースを提供し、LU34はユーザ22
にとってのインターフェースを提供する。

２つのユーザの間でデータを交換するためには、セッシ
ョンと呼ばれる論理状態をセット・アップしなければな
らない。システムの観点からは、ユーザ間のデータ交換
を可能たらしめるセッションは、LU−LUセッションと呼
べる。同じ２つのユーザー間であっても、時が違えば、
セッションに含まれるノードやリンクが違うこともあ
る。例えば、あるセッションでは、ユーザー20と22が、
ノード10、リンク24、及びノード18からなるデータ・パ
スを介してデータをやり取するかもしれない。別の時点
では、同じユーザが、ノード10、12、14、16、18及び各
々の間でのノード間リンクによってセット・アップされ
たセッションを利用することもある。ユーザがデータ交
換のために実際にセッションを使うことを、会話と言
う。

第２図は、本発明によるセッションの活動化及び非活動
化のプロセスを示す。この図では、様々な物理的なまた
は論理的（ロジカル）なコンポーネントが、図の上部に
ブロックとして描かれている。ユーザは、ローカル・プ
ログラム36とリモート・プログラム38である。プログラ
ム36にとってのインターフェースはロジカル・ユニット
40である。ロジカル・ユニット42は、プログラム38にと
ってのネットワークに対するインターフェースを提供す
る。どのSNAネットワークにおいても、コントロール・
ポイント44の如きコントロール・ポイントが含まれてい
る。コントロール・ポイントは協力してネットワークを
管理する。コントロール・ポイントの機能は参考文献に
詳しく説明されているので、本発明の理解にとって重要
なものだけを後で説明する。セッションは、中間のノー
ドとリンクを利用する（ブロック46）。

セッション・セット・アップの第１ステップは、ローカ
ル・ユーザが割当（ALLOCATE）リクエストをローカルLU
40に出すことによって行われる。一般に受け入れられる
術語法では、ALLOCATEリクエストは命令と呼ばれる。AL
LOCATE命令は、リモート・ユーザの名前及び該リモート
・ユーザの所に位置するLUの名前を指定する。もちろ
ん、リモート・ユーザは、ローカル・ユーザと同じLUに
位置していてもよい。ALLOCATE命令はまた、割り当てら
れるセッションについての特性（Property）を示すモー
ド名を指定する。ネットワーク特性の内容は、例えば使
用されるサービス・クラス、データを暗号化すべきか否
か、あるいは送り出す前にデータをASCIIキャラクター
に変換すべきかといったことである。

ローカルLU40は、２つのユーザ間で適当なセッションが
既に存在するか否かをチェックすることにより、割当リ
クエストに応答する。セッションが存在しているけれど
も活動中の会話には用いられていないならば、該セッシ
ョンを用いて現在の割当リクエストを満足させることが
可能である。適当なセッションが存在しないならば、ロ
ーカルLU40は、自己開始（INIT−SELF）リクエストをコ
ントロール・ポイント44へ送る。INIT−SELFリクエスト
は、ALLOCATE命令によって与えられたパラメータを含
む。コントロール・ポイント44は登録簿をサーチして、
INIT−SELFリクエストを満足させるのに必要な様々な資
源を突き止める。コントロール・ポイント33はまた、該
セッションのためにネットワークを貫く適当なルートを
算出する。ルートには、２つのエンド・ノード間の連絡
を形成するために求められる様々なノード及びリンクの
アイデンティティが含まれる。この情報は、コントロー
ル・イニシエイト（CINIT）リクエストの形でローカルL
U40に戻される。

CINITはリクエストであると考えられる。なぜなら、CIN
ITは、機能的にはローカルLUに対してLU−LUセッション
の活動化を試みられるようリクエストするものだからで
ある。このセッションのために、CINITリクエストを受
け取るLUは該セッションについての１次LUとして識別さ
れる。CINITリクエストの中で名をあげられたLUは、２
次LUと呼ばれる。

CINITリクエストは、ローカル・ノードと最初の中間ノ
ードの間のリンクについてのリンク定義を含む。リンク
定義中のパラメータの１つは、制限付資源表示子（LR
I）である。このパラメータは、当該リンクが交換式リ
ンクのような制限付の資源であることを示す。制限付資
源表示子の使用については、以下でより詳しく説明す
る。

ローカルLU40はCINITリクエストに応答して、BIND SESS
ION（バインド・セッション）、つまりBINDリクエスト
をリモート（２次）LUに送信する。BINDリクエストはメ
ッセージ・ユニット（MU）内に含まれ、セッションのた
めに提案されたパラメータを運ぶとともに、LRIフィー
ルドを含んでいる。

BINDリクエストが中間ノードのうちの最初のものへ送信
されるとき、LRIフィールドはローカル・ノードと最初
の中間ノードの間のリンクの定義のみを反映している。
BINDリクエストは中間ノードの各々で処理されてから、
次のノードへ渡される。各ノードで入力BINDリクエスト
が検査され、該ノードの上流のリンクの１つが制限付資
源リンクであることを表示すべくLRI表示がセットされ
ているか否かを判断する。ノードはまた自身がストアし
ている上流と下流両方のリンクの定義をチェックし、当
該ノードにおいて何れかのリンクが制限付資源リンクと
して定義されているか否かを調べる。入力BINDリクエス
トまたはストアしているリンク定義の何れかで制限付資
源が識別されているならば、BINDリクエストが後続のノ
ードに渡される前に、当該ノードにてBINDリクエストの
LRIフィールドがセットされる。（あるいは、既にセッ
ト済であるなら、その状態が維持される。） リモートLU42はBINDリクエストに対してRSP（BIND）レ
スポンスでもって応答する。RSP（BIND）レスポンスが
ノード・バイ・ノードでLU40へ戻される際、上述のよう
な方法によるRSP（BIND）中のLRIフィールドの処理が継
続する。BINDリクエストがリモートLUにとって受諾可能
なものであるならば、BINDレスポンスはセッション・パ
ラメータの完全なセットを含んでいる。パラメータは、
BINDリクエストとともに受信したものとマッチするかも
しれないし、相違するかもしれない。パラメータが相違
するならば、ローカルLUはリモートLUの提案するパラメ
ータを受諾しなければならない。さもないと、セッショ
ンは確立されない。セッションのために受諾可能なパラ
メータのセットが確立可能であると仮定すると、ローカ
ルLU40はポジティブなBINDレスポンスに応答して、ポジ
ティブALLOCATE（割当肯定）リターン・コードをローカ
ル・ユーザに送る。ポジティブ・リターン・コードは、
セッションが確立されたこと、及びユーザ36と38の間で
の会話つまりデータ交換を開始できることを表示する。
ユーザ36と38は、公知のデータ・プロトコールを使って
データ交換を行う。

ローカル・ユーザ36がその最後のデータ・ユニットを送
信すると、ユーザ36はDEALLOCATE（割当解除）命令を出
す。ローカルLUは、この命令に対して、最終データ・ユ
ニットのヘッダにCEBフィールドを含めることによって
応答する。セッションが制限付資源リンクを持つものと
して識別されている場合には、ローカルLU40は直ちにリ
モートLUに対してUNBIND（バイント解除）リクエストを
送る。このリクエストによって、LUは、コントロール・
ポイント44からのアクションあるいはリクエストを待つ
ことないしに、確立されていたLU−LUセッションを非活
動化することが可能になった。セッションが制限付資源
リンクを有するものとして識別されていなかったなら
ば、ローカルLU40は、UNBIND処理を始める前に、普通に
コントロール・ポイント44からのアクションまたはリク
エストを持つことになる。

第３図は、BINDリクエストまたはBINDレスポンス処理に
おいて、どのようにして制限付資源セッションが識別さ
れるかについて、詳細に説明している。第３図におい
て、ノードＡがローカル・ノードであり、ノードＤがリ
モート・ノードである。ノードＡとＢの間のリンク及び
ノードＣとＤの間のリンクは、リース（された）回線で
ある。定義上当然に、リース回線は制限付資源であるこ
とは考えられない。他方、ノードＢとＣの間のリンクは
交換リンクであり、ネットワーク構成者の好きなよう
に、制限付資源として定義してよい。

セッションがセット・アップされるときにBINDリクエス
トつまりBRQがノードＡにて生成される。ストアされて
いるリンクABの定義により、ノードＡは該リンクが制限
付資源であるか否かを決定する。リンクABはリース回線
なので、これは制限付資源ではなく、したがってBINDリ
クエスト中のLRIビットは、BINDリクエストがノードＢ
に送られる前にゼロにセットされる。ノードＢはBINDリ
クエストを検査して、LRIビットの状態を判断する。ノ
ードＢまたはローカルにストアされているリクエストA
B、BCの両方の定義を見て、何れかのリンクがノードＢ
にて制限付資源リンクとして定義されているか否かを判
断する。リンクBCが交換式、つまり制限付資源リンクで
あるので、ノードＢはBINDリクエスト中のLRIビットを
１にセットしてから、BINDリクエストをノードＣへ送信
する。ノードＣはノードＢと同じ基本処理を繰り返し、
受信したBINDリクエストまたはローカルにストアされた
リンクBCまたはCDの定義の何れかが制限付資源を表示し
ているならば、LRIビットを１にセットする。

リモート・ノードにてBINDリクエストが受信されると、
該ノードはBINDレスポンス（BRP）を生成する。BINDレ
スポンスもLRIビットを含んでおり、受信BINDリクエス
ト中のLRIビットが値１を有していた場合、またはノー
ドＤにおけるデータ・ベースがリンクCDを制限付資源と
して定義していた場合に、BRPのLRIビットは１にセット
される。BINDレスポンスがノードＣに送られると、ノー
ドＣは、最初にBINDリクエストに対して反応したのと同
じようにしてBINDレスポンスに対して反応する。すなわ
ち、ノードＣはノードＤから受け取ったメッセージ・ユ
ニットが値１を有するか、もしくはノードＣがリンクBC
またはCDを制限付資源として定義していた場合に、BIND
レスポンス中のLRIビットを１にセットする。その後、B
INDレスポンスはノードＢに渡され、ノードＢはBINDレ
スポンス・メッセージ・ユニットを同様に処理してから
ノードＡに渡す。ノードＡは、ノードＢから受け取った
メッセージ・ユニット及び自身でストアするリンクABの
定義の関数（図面ではｆとして示す）として、LRIビッ
トをセットする。その後、ノードＡはLRI表示子をセッ
ション・コントロール・ブロックにストアする。ストア
されたLRI表示子は、セッションが非活動化されるとき
に用いられる。

恐らく上述のプロセスはかなり冗長であることが明らか
であろう。この冗長性は望ましいものである。なぜな
ら、ネットワークの任意のノードが“ダウン・レベル”
のノード、つまり特定のリンクが制限付資源であるか否
かを表示する貯蔵（ストアド）リンク定義を必ずしもサ
ポートしないノードであるかもしれないからである。上
述した冗長性は、ダウン・レベル・ノードが誤ってLRI
表示子をゼロにセットすることを防止する。

第４図は、第３図で一般的な説明をしたプロセスにおい
て、各ノードで実行されるステップのフロー・チャート
である。もちろん、該プロセスを実行するノードは、上
流ノードからBINDリクエストつまりBRQを受け取る（オ
ペレーション48）。受信ノードはBRQのLRI表示子を検査
して、LRIビットが値１を有するか否かを判断する（オ
ペレーション50）。LRIビットがゼロに等しい場合、ノ
ードは、自身のトポロジー・データ・ベース（DB）が上
流リンクを制限付資源（LR）として定義しているか否か
を判断する（オペレーション52）。上流リンクが制限付
資源でないならば、ノードはまた該トポロジーDBをチェ
ックして、下流リンクLRとして定義されているか否かを
判断する（オペレーション54）。判断ブロック50、52、
54のすべてにおいてネガティブ（否定的）な結果を得た
ならば、BINDリクエストのLRIビットはゼロにセットさ
れ（オペレーション56）、BINDリクエストは下流ノード
へ転送される（オペレーション58）。

他方、判断ブロック50、52、54の何れかでポジティブな
結果が得られたなら、BINDリクエストのLRIビットが１
にセットされ（オペレーション60）、その後、BINDリク
エストは下流ノードへ発信される（オペレーション5
8）。

第５図は、ローカルとリモートのユーザ間での会話が終
わるときに、ローカルつまり１次LUにて実行されるステ
ップのフロー・チャートである。１次LUはユーザからDE
ALLOCATE命令を捜す。DEALLOCATE命令を受け取ると（6
2）、LUはタイマを始動させてよい（オペレーション6
4）。このタイムの機能は単純である。現在のユーザ間
で会話がもはや必要とされないかもしれないとき、他の
ユーザが同じ２つのLU間での会話に関係することを望む
可能性が常にある。オペレーション64で始動したオプシ
ョナル・タイマーによって、潜在的なセッション・ユー
ザが簡単に該セッションの使用をリクエストできるよう
になった。後で延べる理由により、オペレーション64の
直後に、時間が経過したか否かについてのチェック74が
行われる。次いで、LUは、会話リクエスト、つまり２つ
のパートナーLU間のセッション使用リクエストが存在す
るか否かを判断する（オペレーション64）。もしかかる
リクエストがあるなら、LUは現在セッションが該リクエ
ストの何れかをまかなえるのか否かの判断をさらに行
う。現在セッションのパラメータが潜在ユーザーによっ
てリクエストされたパラメータと一致しない場合、現在
セッションは常にリクエストを満足できるわけではな
い。例えば、潜在ユーザは暗号化セッションを必要とす
るのに、現在セッションは非暗号化データの交換しか提
供しないこともある。オペレーション68によって現在セ
ッションが存在する会話リクエストをまかなえると判断
されたなら、セッション非活動化プロセスは終了し、該
セッションは待機中のユーザによってひき続き使用され
ることになる。

しかしながら、オペレーション66によって待機中の会話
リクエストの不存在が示された場合、またはオペレーシ
ョン68によってセッションが会話リクエストに適さない
ことが示された場合、LUは自身のセッション・コントロ
ール・ブロック中のLRIビットをチェックして、該セッ
ションが制限付資源セッションとして識別されているか
否かを判断する。該セッションが制限付資源セッション
でないならば、非活動化プロセスのコントロールは、こ
こで説明しているプロセスとは全く別次元のプロセス
で、コントロール・ポイントへ渡される。オペレーショ
ン70によって、セッションが制限付資源セッションだと
表示されたならば、処理を実行中であるノードに関して
該セッションが“競合勝者（Contention-winner）”で
あるか否かをさらにテストされ、このオペレーション72
によって行われる判断は２次LUがセッションを非活動化
するのを防止するのに必要である。

オペレーション66、68、70、72が（会話が終了するとき
は大抵１回以上）実行される間、オペレーション64にて
始動されたタイマは動き続ける。タイムアウトとなる時
間が経過すると、オペレーション76にて、いつでも２つ
のLU間で最小限の数のセッションがアクティブでなけれ
ばならないのか否かのチェックが行われる。ノード対ノ
ードのトラフィックが多量になると予期されるとき、ま
たはノード対ノードのトラフィックにおいて高度のリラ
イアビリティが維持されねばならないとき、いつでも最
小限の数のセッションはアクティブでなければならない
という条件の下に、多量かつ並行なセッションをセット
・アップすることができる。判断76の結果、最小限の数
のセッションが維持されるべきことが示された場合に
は、現在セッションを非活動化することによって維持さ
れるべきセッションの最小限度の数を下回ってしまう、
つまり違反してしまうか否かについても、さらにチェッ
クが行われる。もし現在セッションの非活動化がアクテ
ィブなセッションの数を減らすことによって下限を下回
るならば、該プロセスは現在プロセスを非活動化するこ
ともなく終了する。しかしながら、チェック76の結果、
維持されるべきセッションの数に最小限度がないことが
示される場合、または、チェック78の結果、そのような
最小限度があったとしても現在セッションの非活動化は
かかる限度に違反するものではないことが示される場合
には、ローカルつまり１次のLUはUNBINDプロセスを開始
する。（オペレーション80）。UNBIND処理の結果、セッ
ションは非活動化する。

以上の説明を繰り返すと、BIND処理によって、セッショ
ン内の活動中のリンクの何れかが制限付資源リンクであ
るや否やが確認される。制限付資源リンクであるリンク
があるならば、セッション全体が制限付資源セッション
として表示される。セッションがコントロール・ポイン
トのアクションを待つことなしに、当該セッションを非
活動化するステップを採ることができる。１次LUがセッ
ションを非活動化できるようになった結果、使用されて
いないセッションをサポートする制限付資源リンクがア
クティブであり続ける時間が減少する。この結果、記述
のように、ネットワーク・オペレーションのコストが減
少するとともに、制限付資源リンクの最大限のアベイラ
ビリティが保証される。

F.効果 本発明によれば、制限付資源リンクが使用されないセッ
ションに不必要に割り当てられ続けることを避けること
ができる。

【図面の簡単な説明】

第１図は、データ通信ネットワークの概略を示すブロッ
ク図である。 第２図は、本発明の実施時にネットワーク内で発せられ
るコマンドまたはリクエストの説明図である。 第３図は、BINDリクエストの処理ステップのフローチャ
ートである。 第４図は、第３図に示した処理の際に各ノードで実施さ
れるステップのフローチャートである。 第５図は、セッションがユーザ間のカンバゼーションを
サポートするのにもはや必要とされないときに実行され
るステップのフローチャートである。

フロントページの続き (72)発明者 マーシヤ・エレン・フエリイ アメリカ合衆国ノース・カロライナ州ラレ イ、フライアース・ウオーク・プレス6110 番地 (72)発明者 ジヨン・エングン・フエトヴエト アメリカ合衆国ノース・カロライナ州ラレ イ、ウエーバー・ドライブ4206番地 (72)発明者 ジエームズ・ペイトン・グレイ アメリカ合衆国ノース・カロライナ州チヤ ペル・ヒル、エモリイ・ドライブ904番地 (72)発明者 ズボミイール・オーダニク アメリカ合衆国ノース・カロライナ州ラレ イ、ダンヒル・テラス10740番地 (56)参考文献 特開 昭61−245655（ＪＰ，Ａ) 特開 昭61−286950（ＪＰ，Ａ)

Claims (1)

【特許請求の範囲】
1. 【請求項１】ユーザとネットワークの間にインターフェ
   ースとしてロジカル・ユニットが存在しており、ネット
   ワーク内のノードとリンクを適宜つないでロジカル・ユ
   ニット同士の間にセッションを確立した状態でユーザ同
   士がデータを通信するネットワークの制御方法であっ
   て、 活動中の各セッションについて、該セッションが制限付
   資源リンクを１つ以上含む第１のタイプであるか、それ
   とも制限付資源リンクを全く含まない第２のタイプであ
   るかを識別し、 現在活動中のセッションについて、該セッションがユー
   ザの間のデータ通信にとってもはや必要とされないもの
   かどうかを判断し、 セッションがユーザ間のデータ通信にとってもはや必要
   とされず、かつ該セッションが第１のタイプであるなら
   ば、ロジカル・ユニットをしてネットワーク・コントロ
   ール・オペレータからのリクエストを待つことなしに該
   セッションを終了せしめる ことを特徴とする方法。