JP3583747B2 - ネットワーク管理方法 - Google Patents

ネットワーク管理方法 Download PDF

Info

Publication number
JP3583747B2
JP3583747B2 JP2001323957A JP2001323957A JP3583747B2 JP 3583747 B2 JP3583747 B2 JP 3583747B2 JP 2001323957 A JP2001323957 A JP 2001323957A JP 2001323957 A JP2001323957 A JP 2001323957A JP 3583747 B2 JP3583747 B2 JP 3583747B2
Authority
JP
Japan
Prior art keywords
terminal
server
nis
connection
management server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2001323957A
Other languages
English (en)
Other versions
JP2002185455A (ja
Inventor
悦幸 津田
浩 江崎
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Priority to JP2001323957A priority Critical patent/JP3583747B2/ja
Publication of JP2002185455A publication Critical patent/JP2002185455A/ja
Application granted granted Critical
Publication of JP3583747B2 publication Critical patent/JP3583747B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

Description

【０００１】
【発明の属する技術分野】
本発明は、ネットワークシステムにおいて、コネクションを設定するために必要な情報や端末の生存などを管理するためのネットワーク管理方法に関する。
【０００２】
【従来の技術】
ＡＴＭ交換システムでは、有意情報のみセルと呼ばれる５３バイト固定長のパケットに載せてデータ通信を行うので、単位時間当たり有意情報量が大きく変動するマルチメディア環境下でも、複数ユーザによる交換資源の共有化が可能となる。この複数ユーザによる交換資源の共有化によるコストダウンの可能性のため、ＡＴＭ交換技術は、Ｂ−ＩＳＤＮを実現する唯一の解として、現在、研究・開発が活発に行われている。
【０００３】
従来のＡＴＭ交換システムは、電話網のシステム構成方法を基に構成されているので、後述するように電話等のデータ通信には適しているが、従来から行われているコンピュータ間のデータ通信に対しては必ずしも適していない。
【０００４】
以下、（１）従来のＡＴＭ交換システムでのデータ通信方法、とともに（２）イーサネットＬＡＮ（Ｅｔｈｅｒｎｅｔ−ＬＡＮ）におけるコンピュータ間のデータ通信、に関して、図を参照しながら具体的に説明する。
【０００５】
１）従来のＡＴＭ交換システムでのデータ通信方法について
図５６（ａ）に従来のＡＴＭ交換システムの一例を、図５６（ｂ）〜（ｄ）にＡＴＭ交換システムで用いられるセル・フォーマットを示す。（ｂ）は（ａ）のＡＴＭ交換機８０２に入力されるセルのフォーマットであり、（ｃ）はＡＴＭ交換機８０２内におけるセルのフォーマットであり、（ｄ）はＡＴＭ交換機８０２から出力されるセルのフォーマットである。
【０００６】
図５６（ａ）に示すような従来のＡＴＭ交換システムでは、ＡＴＭ交換機８０２に入力されたセルのヘッダに含まれるＶＰＩ（Ｖｉｒｔｕａｌ Ｐａｔｈ Ｉｄｅｎｔｉｆｉｅｒ ）およびＶＣＩ（Ｖｉｒｔｕａｌ Ｃｈａｎｎｅｌ Ｉｄｅｎｔｉｆｉｅｒ）と呼ばれる領域が参照され、ＡＴＭ交換機８０２内にあるルーティングタグ・テーブル（図示せず）に予め設定されたルーティング情報を基にルーティングされるので、データ送信端末８０３のセル転送に先だって、前記ルーティング情報が設定されていなければならない。また、前記したように、従来のＡＴＭ交換システムは複数ユーザによる交換資源の共有化によってコストダウンを図ろうとしているが、網がユーザに対し新たにデータ通信サービスを提供する場合、前記データ通信を網が受け入れても、交換資源を共有している他のユーザのデータ通信のＱＯＳ（Ｑｕａｌｉｔｙ Ｏｆ Ｓｅｒｖｉｃｅ）を網が保証しなければならない。従って、従来のＡＴＭ交換システムでは、データ転送に先だって、データ送信端末８０３からデータ受信端末８０４までのルーティングタグ・テーブルの設定と、前記データ転送サービスに必要なセル廃棄率の保証あるいは最大セル転送遅延といったＱＯＳと、平均／ピーク使用帯域（単位時間当たりのデータ転送量）といったトラヒックパラメータの使用とを、ＡＴＭ交換システム内に存在する呼設定手段８２４に対し呼設定要求として行う。網は、データ送信端末８０３から出された前記呼設定要求を受け入れられる場合、前記ルーティングタグ・テーブル等の設定を行うとともに、前記データ送信端末８０３が送信するセルに書き込むＶＰＩ／ＶＣＩ等を前記データ送信端末８０４に通知する。
【０００７】
データ送信端末８０３は、呼設定が終了してからセル転送を開始する。すなわち、データ送信端末８０３は、まず、網から送られたＶＰＩ／ＶＣＩ等を基にヘッダと呼ばれる５バイトデータを作成し、送信するデータのうち有意情報のみ定義されたプロトコルに従って、４８バイトの情報フィールドに入るよう分割／コーディングを行う。最後に、作成したヘッダと情報フィールドを結合してセルを作成し、前記セルをデータ送信端末８０３からＡＴＭ交換機８０２に送信する。
【０００８】
ＡＴＭ交換機８０２に有効セルが入力された場合、該入力セルのＶＰＩ／ＶＣＩが参照され、呼設定時に設定されたルーティング情報を基に、該ＡＴＭ交換機８０２の所望の出力から出力されるようにスイッチングが行われる。
【０００９】
具体的には、まず、ＡＴＭ交換機８０２に入力されたセルは前処理部８２１に入力され、該前処理部８２１では、入力セルのＶＰＩ／ＶＣＩをキーとしてルーティングタグ・テーブルを検索し、呼設定時に前記ＶＰＩ／ＶＣＩに対して設定されたルーティングタグを検索する。次に、該前処理部８２１は、前記検索したルーティングタグを入力セルに付加し、前記ルーティングタグを付加したセルをスイッチ８２２へ転送する。スイッチは、入力セルのうち、前処理部８２１で付加されたルーティングタグを参照し、前記ルーティングタグに従ってスイッチングを行い、所望の出力から後処理部８２３へ該入力セルを転送する。前記スイッチ８２２において、入力セルのＶＰＩ／ＶＣＩを参照する代わりにルーティングタグを参照する理由は、ＶＰＩ／ＶＣＩ領域の大きさ（ｂｉｔ数）は大きく、ＶＰＩ／ＶＣＩ領域全体をデコードするのは効率が悪いので、前記領域をデコードする代わりにスイッチ規模に合った大きさのルーティングタグを前処理部８２１で付加し、スイッチ８２２では前記ルーティングタグをデコードすることによって効率化を図るためである。最後に、後処理部８２３は、スイッチ８２２から転送された入力セルのうち、前処理部８２１で付加したルーティングタグを削除し、ＡＴＭ交換機８０２の所望の出力からセルを出力する。
【００１０】
また、前記したように、ＶＰＩ／ＶＣＩはＡＴＭ交換機８０２の前処理部８２１のルーティングタグ・テーブルのエントリとして使用されるので、データ送信端末から送信されたセルが複数のＡＴＭ交換機を経由してデータ受信端末に転送される場合、経由するＡＴＭ交換機のルーティングタグ・テーブルの都合に従って、前記ＶＰＩ／ＶＣＩをセル転送路の途中のＡＴＭ交換機で書き換えなければならない場合がある。従って、この場合に対応するために、ＡＴＭ交換機８０２に入力されたセルのＶＰＩ／ＶＣＩをキーとして、ＡＴＭ交換機８０２の出力側のＶＰＩ／ＶＣＩを検索し、入力セルのＶＰＩ／ＶＣＩを該検索したＶＰＩ／ＶＣＩで置き換えるＶＰＩ／ＶＣＩ変換機能が、ＡＴＭ交換機８０２の前処理部８２１または後処理部８２３に実装されている場合がある。
【００１１】
データ送信端末から送信されたセルは、複数のＡＴＭ交換機を経て所望のデータ受信端末に転送される。データ受信端末は、受信したセルから、定義されたプロトコルに従ってデータ送信端末が送信したデータを再生する。
【００１２】
また、データ送信端末は、呼設定時、網に申告したトラヒック・パラメータを守ってデータ転送を行うのであるが、網に接続されたすべてのデータ送信端末が常に前記トラヒック・パラメータを守るとは限らないので、網は、データ送信端末が前記トラヒック・パラメータを守ってデータ転送を行っているかどうかチェックしなければならない。なぜなら、網に接続されたデータ送信端末の中に、前記トラヒック・パラメータを守らない違法なデータ送信端末、パラメータの設定を間違えたため前記トラヒック・パラメータを守ることのできないデータ送信端末、または障害が発生したため前記トラヒック・パラメータを守らないデータ送信端末等が存在した場合、前記データ送信端末の送信するセルによって、網が、交換資源を共有している他のデータ転送のＱＯＳを保証できない場合が起こり得るからである。
【００１３】
前記目的を達成するために、網は、まず呼設定時に、データ送信端末８０３が申告したトラヒック・パラメータを前記データ送信端末８０３が守っているかどうかチェックし、前記データ送信端末８０３が送信するセルが前記トラヒック・パラメータを違反した場合、前記セルを廃棄するか、または前記セルに対して目印を付けるタギング（ｔａｇｇｉｎｇ ）を行う。次に、該タギングしたセルを網が受け入れることによって、他のデータ転送のＱＯＳを保証できない場合、該タギングしたセルを廃棄することによって、他のデータ転送のＱＯＳを網が保証することができる。具体的には、図５６（ａ）に示すＡＴＭ交換機８０２内の前処理部８２１のポリシング部（ＰＬ）８４１において、呼設定時に、データ送信端末８０３が申告したトラヒック・パラメータを、該データ送信端末８０３が違反していないかどうかチェックし、前記データ送信端末８０３から送信されたセルが前記トラヒック・パラメータを違反していた場合、前記セルを廃棄、または前記セルのＣＬＰ（Ｃｅｌｌ Ｌｏｓｓ Ｐｒｉｏｒｉｔｙ）ビットをセットすることによってタギングを行う。ＡＴＭ交換機８０２が、該タギングしたセルを受け入れることによって、他のデータ転送のＱＯＳを保証できない場合、該タギングしたセルを廃棄する。
【００１４】
一方、データ送信端末８０３は、送信するセルが、呼設定時、網に申告したトラヒック・パラメータを違反しないように、データ送信端末８０３内のシェイピング部（ＳＨ）８３１において、送信するセル流を整形して、セルを送信する。
【００１５】
次に、ＡＴＭ交換システムにおける端末の立ち上げ手順（特に、メタシグナリング手順）は以下のようになる。すなわち、ＡＴＭ交換システムに接続された端末８０３は、起動（ｂｏｏｔ）時、メタシグナリング・セルと呼ばれるＶＰＩ／ＶＣＩに特定値を持ったセルを、網の管理機能を提供する網管理手段（図示せず）に向けて送信する。網管理手段は、メタシグナリング・セルを受信した場合、前記メタシグナリング・セルが転送されてきたセル転送路に接続された端末８０３が起動したことを認識し、前記端末８０３に対してシグナリング・チャネルの帯域の割り当てや、前記端末８０３からＡＴＭ交換システム内の呼設定手段８２４までのルーティング・テーブルの設定等を行う。網管理手段は、前記設定が終了した後、前記端末８０３の使用するシグナリング・セルのＶＰＩ／ＶＣＩ等を前記端末に通知する。前記シグナリング・セルは、端末８０３が網に対して呼設定要求を行う場合に使用される。
【００１６】
次に、従来のＡＴＭ交換システムにおけるコピーコネクションのサポート方法について具体的に説明する。
【００１７】
コピーコネクションには、サブネット内のすべての端末にデータを転送するブロードキャスト・コネクションと、指定された複数の端末にデータを転送するマルチキャスト・コネクションの２種類のコピーコネクションがある。以下、まず、ＡＴＭ交換システムにおける前記２種類のコピーコネクションの必要性について説明する。
【００１８】
ＴＣＰ／ＩＰ等、従来方法によるコンピュータ間通信には、後述するようにサブネット内の端末（Ｈｏｓｔ）に対し、データグラムをブロードキャストする場合があるので、従来のＡＴＭ交換システムで従来方法によるコンピュータ間通信を行う場合、何らかの方法によってユーザに対しブロードキャスト・サービスを提供しなければならない。また、ネットワークを用いてテレビ会議等を行う場合、同じ画像を複数の端末に転送しなければならないが、ネットワークが何らかの方法でマルチキャスト・サービスをユーザに提供することができるなら、ユーザはネットワークに画像を１回送信すれば、ネットワークが複数の端末に同じ画像を送信してくれるので、ユーザは効率的なデータ転送をすることができる。
【００１９】
以下、従来のＡＴＭ交換システムにおいてコピーコネクションを実現する方法について、図５７を参照しながら具体的に説明する。
【００２０】
図５７（ａ）は、コピースイッチによるコピーコネクションの実現方法である。ＡＴＭ交換機のセルスイッチとして、コピースイッチ８４４を用いた場合、コピーコネクションに属しないセルおよびコピーコネクションに属するセルの両方のを、１つのセルスイッチで扱うことができる。まず、コピーコネクションに属しないセルが、前記コピースイッチ８４４に入力された場合、該入力セルは通常セル用バッファ８４６に入力され、一般のＡＴＭセルスイッチと同じようにスイッチングが行われる。一方、コピーコネクションに属するセルが入力された場合、該入力セルはコピーセル用バッファ８４８に入力され、該入力セルの属するコネクションに指定された出力ポート８５０１ ，８５０２ ，８５０３ に指定された回数コピーされることによって、ユーザに対しコピーコネクションを提供することができる。
【００２１】
しかし、このようにコピーコネクションの実現方法としてコピースイッチを用いた場合、コピースイッチの出力ポートは、コピーコネクションに属するセルとコピーコネクションに属しないセルのうち、いずれか一方のセルを選択して出力しなければならないので、コピースイッチの出力ポートの出力アルゴリズムは複雑になってしまうという問題点があった。また、コピースイッチをＬＳＩ化する場合、コピースイッチに入るコピーセル用バッファの大きさには制限があるが、前記したようにコピーセル用バッファ８４８に入力されたセルは、指定された回数コピーされるまではバッファから出力されないので、コピーセル用バッファ８４８はコピーコネクションに属するセルでオーバーフローしやすく、コピーコネクションに属するセルは廃棄されやすいという問題点があった。
【００２２】
図５７（ｂ）は、コピー機能を提供するコピー手段を適用したコピーコネクションの実現方法である。コピーコネクションの実現方法としてコピー手段８５４による方法を用いた場合、コピーコネクションに属するセルがＡＴＭ交換機に入力された場合、まず、前記セルはセルスイッチ８５２によってコピー手段８５４に転送されるようにスイッチングされる。コピー手段８５４は、前記コピーコネクションに属するセルが入力された場合、前記セルをバッファ８５６に格納し、前記セルの属するコネクションに対し指定された出力ポート８５８１ ，８５８２ ，８５８３ に、指定された回数だけ前記セルをコピーして出力することによって、ユーザに対しコピーコネクションを提供することができる。一方、コピーコネクションに属しないセルがＡＴＭ交換機に入力された場合、前記セルは、セルスイッチ８５２の所望の出力ポート８５８１ ，８５８２ ，８５８３ から出力されるようにスイッチングが行われる。
【００２３】
コピーコネクションの実現方法としてコピー手段が用いられた場合、セルスイッチ内で入力セルのコピーを行う必要はないので、コピースイッチを用いた場合に比べセルスイッチの構造は簡単になるという利点がある。また、コピーセル用バッファをセルスイッチ内に持つ必要はなく、コピー手段内に持てばよいので、コピースイッチの場合に比べてより多くのコピーセル用バッファを持つことができ、コピーコネクションに属するセルがより廃棄されにくいという利点がある。
【００２４】
しかし、コピー機能を提供するコピー手段に実装されるコピーセル用バッファの大きさは有限であるので、前記コピーコネクションに属するセルはコピーコネクションに属していないセルに比べて廃棄されやすいという問題点があった。コピーコネクションに属するセルがコピー手段に入力された場合、コピー手段内で所定の回数コピーされ出力されるが、コピー手段の出力が１つしかない場合、コピーされたセルは同時には１つしか出力できないので、前記コピー手段による方法を用いた場合、コピーコネクションに属するセルに対してサービスをするのに時間がかかってしまうという問題点がある。この問題点はコピー手段の出力を１つ以上にすることなどによって解決することができるものの、前記コピー手段の出力を１つ以上とした場合には、セルスイッチのコピー手段以外からの入力の数が少なくなるので、入出力数の大きいセルスイッチを構成したいときなどは新たな問題となる。
【００２５】
図５７（ｃ）は、コピーサーバ８６２によるコピーコネクションの実現方法である。コピーコネクションの実現方法として、コピーサーバー８６２による方法が採用された場合、ＡＴＭ交換システムに接続している１つの端末（Ｈｏｓｔ）をコピーコネクションに対しサービスを行うコピーサーバーとし、ＡＴＭ交換機８６０は、コピーコネクションに属するセルを前記コピーサーバー８６２に転送し、コピーサーバー８６２が該転送されたセルを、該コネクションに対し指定された宛先に、指定された回数コピーし、該コピーしたセルを再びＡＴＭ交換機８６０へ転送することによって、ユーザに対しコピーコネクションを提供することができる。
【００２６】
コピーコネクションの実現方法として、コピーサーバーによる方法を用いた場合、ＡＴＭ交換機内にコピー機能（コピースイッチ、コピー手段等）を持つ必要がないので、コピー機能を持たないＡＴＭ交換機で、ユーザに対しコピーコネクションを提供できるという利点がある。また、図５７（ａ）のようなＡＴＭ交換機内にコピーセル用バッファを持つコピースイッチ／コピー手段に比べて、コピーサーバーの場合、コピーセル用バッファをより大きくできるので、コピーコネクションに属するセルがより廃棄されにくいという利点がある。
【００２７】
しかし、コピーコネクションの実現方法として、コピーサーバーによる方法が用いられた場合、コピーサーバー８６２によってコピーされたセルは、同時には１つのセルしかＡＴＭ交換機８６０へ転送できないため、コピーコネクションのサービスに時間がかかってしまうという問題点があった。また、一般に、コピーサーバーによってコピーコネクションをサポートする場合、コピーサーバーに転送されたコピーコネクションに属するセルは、コピーサーバーのＯＳを通してソフトウェアで処理されるため、該入力セルに対し処理を行うのに時間がかかってしまうという問題点があった。
【００２８】
次に、従来のＡＴＭ交換システムにおけるコネクションレス・サービスのサポート方法について具体的に説明する。
【００２９】
従来のＡＴＭ交換システムは、電話網の構成方法を基にシステム設計が行われているので、ＡＴＭ交換システムにおけるデータ通信は、基本的には、電話網の場合と同じようなコネクション型の（コネクション・オリエンテッドな）データ通信である。すなわち、データ通信を行う必要の生じたデータ送信端末は、データ転送に先だって、まず、網に対し呼設定要求を行い、前記呼設定を受け入れられてから、該データ送信端末は網が設定したコネクションを用いてデータ転送を行うという方法を採用している。一方、従来から行われているコンピュータ間通信の多くは、後述するようにコネクションレス型のデータ通信である。従って、従来のＡＴＭ交換システムで、従来の方法によるコンピュータ間通信を行う場合、何らかの方法でコネクションレス型のデータ通信をサポートしなければならない。以下、図５８を参照しながら、従来のＡＴＭ交換システムでコネクションレス型のデータ通信をサポートする方法について説明する。
【００３０】
従来のＡＴＭ交換システムでは、コネクションレス型のデータ通信は、ＣＬＳＦ（Ｃｏｎｎｅｃｔｉｏｎ−Ｌｅｓｓ Ｓｅｒｖｉｃｅ Ｆｕｎｃｔｉｏｎ）処理によってユーザに対し提供される。具体的には、従来のＡＴＭ交換システムにおいて、コネクションレス・サービスをユーザに提供する場合、部分ネット（サブネット）内に１つ以上のＣＬＳＦ処理手段を設け、前記ＣＬＳＦ処理手段とコネクションレス型データ通信を行うサブネット内のすべての端末（Ｈｏｓｔ）との間に、前記データ通信用のコネクションを予め設定しておく。また、前記ＣＬＳＦ処理手段と少なくとも前記サブネットの上位サブネット内のＣＬＳＦ処理手段との間に、コネクションレス型のデータ通信用のコネクションを予め設定しておく。前記２種類のコネクション（ＣＬＳＦ処理手段と端末間のコネクション／ＣＬＳＦ処理手段間のコネクション）を用いることによって、従来のＡＴＭ交換システムにおいてコネクションレス型のデータ通信サービスが実行される。
【００３１】
以下、図５８を用いて、従来のＡＴＭ交換システムにおける、ＣＬＳＦ処理手段を用いたコネクションレス型のデータ通信について具体的に説明する。
【００３２】
図５８において、端末（Ｈｏｓｔ）８７４から同じサブネット内に存在する端末（Ｈｏｓｔ）８７６へ、コネクションレス型のデータ通信を行う場合、ＣＬＳＦ処理手段８７０とサブネット内の端末（Ｈｏｓｔ）８７４，８７６との間に予め設定されたコネクションレス型データ通信用のコネクションを用いて、データ通信を行う。すなわち、端末（Ｈｏｓｔ）８７４は、前記設定されたコネクションレス・サービス用のコネクションを用いて、データをセルスイッチ８６４に接続したＣＬＳＦ処理手段８７０に転送し、ＣＬＳＦ処理手段８７０が、前記コネクションレス・サービス用のコネクションを用いて前記データを端末（Ｈｏｓｔ）８７６へ転送することによって、前記データ通信が実行される（経路１参照）。
【００３３】
また、図５８において、端末（Ｈｏｓｔ）８７４から上位サブネット内に存在する端末（Ｈｏｓｔ）８７８へ、コネクションレス・サービスを用いてデータ通信を行う場合、前記予め設定されたＣＬＳＦ処理手段８７０とサブネット内の端末（Ｈｏｓｔ）８７４との間のコネクションと、ＣＬＳＦ処理手段８７０，８７２間に設定されたコネクションと、ＣＬＳＦ処理手段８７２とサブネット内の端末（Ｈｏｓｔ）８７８との間のコネクションを用いて、データ通信を行う。すなわち、端末（Ｈｏｓｔ）８７４は、まず、前記予め設定されたコネクションレス・サービス用のコネクションを用いて、データを、セルスイッチ８６４に接続したＣＬＳＦ処理手段８７０に転送し、次に、ＣＬＳＦ処理手段８７０が、前記データを、前記予め設定されたコネクションレス・サービス用のコネクションを用いて、セルスイッチ８６８に接続しているＣＬＳＦ処理手段８７２に転送し、最後に、ＣＬＳＦ処理手段８７２は、前記データを、前記予め設定されたコネクションレス・サービス用のコネクションを用いて、端末（Ｈｏｓｔ）８７８へ転送することによって、前記データ通信が実行される（経路２参照）。
【００３４】
同様に、図５８において、端末（Ｈｏｓｔ）８７４からさらに上位のサブネットにデータを転送する場合も、前記予め設定されたＣＬＳＦ処理手段８７０とサブネット内の端末（Ｈｏｓｔ）８７４との間のコネクションと、ＣＬＳＦ処理手段８７０，８７２間に設定されたコネクションを用いて、データ通信を行うことができる（経路３参照）。
【００３５】
ここで、コネクションレス・サービスを、従来のＡＴＭ交換システムにおいて、前記ＣＬＳＦでユーザに提供する場合、少なくとも以下の２つの問題点が存在する。
【００３６】
１つ目の問題点は、ＣＬＳＦ処理手段内のバッファ量に関する問題点である。ファイル転送等のコンピュータ間通信を、前記ＣＬＳＦ処理手段を用いて実行する場合、前記ＣＬＳＦ処理手段には多量のデータバッファが必要である。特に、複数のＣＬＳＦ処理手段を経由してデータ通信を行う場合で、途中のＣＬＳＦ処理手段間で誤り検出を行い再送制御を行う場合、ＣＬＳＦ処理手段には多量のデータバッファが必要である。一方、ファイル転送以外のレイテンシに対する要求の厳しいコンピュータ間通信をＣＬＳＦ処理手段で行う場合、該ＣＬＳＦ処理手段における遅延を小さくするためＣＬＳＦ処理手段は、ＡＴＭ交換機内に実装されるが、ＡＴＭ交換機内にＣＬＳＦ処理手段を実装する場合、データバッファの大きさを大きくできないといった問題点があった。
【００３７】
２つ目の問題点は、複数のＣＬＳＦ処理手段を経由すること等によるレイテンシに関する問題点である。前記したように、ファイル転送以外のコンピュータ間通信には、レイテンシに対して要求の厳しいコンピュータ間通信も存在するが、すべてのコンピュータ間通信をＣＬＳＦ処理手段を用いて行おうとした場合、前記レイテンシに関して要求の厳しいコンピュータ間通信に対し問題が生ずる。これは、ＣＬＳＦ処理手段を経由することによって、遅延が生じるためである。また、ＣＬＳＦ処理手段は、サブネット内の多くの端末（Ｈｏｓｔ）によって共有しているが、複数の端末（Ｈｏｓｔ）が同時にＣＬＳＦ処理手段を使用し始めた場合、アクセスの競合による輻輳によって、ＣＬＳＦ処理手段を経由するのに大きな時間がかかる場合があるといった問題点があった。
【００３８】
２）イーサネットＬＡＮ（Ｅｔｈｅｒｎｅｔ−ＬＡＮ）におけるコンピュータ間のデータ通信について
次に、従来のイーサネットＬＡＮにおけるコンピュータ間のデータ通信について説明する。
【００３９】
図５９は、複数の端末（Ｈｏｓｔ）８８０（８８０１ ，８８０２ ，８８０３ ）が１つのバス（Ｅｔｈｅｒｎｅｔ）８８２を共有し、各端末（Ｈｏｓｔ）８８０１ ，８８０２ ，８８０３ が前記バス型のイーサネットを用いてコンピュータ間通信を行う場合のハードウェア構成を示したものである。以下、図５９を参照しながら、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を用いたＬＡＮ内のコンピュータ間通信について、具体的に説明する。
【００４０】
バス型のイーサネットで、端末（Ｈｏｓｔ）８８０１ ，８８０２ ，８８０３ がデータ通信を行う必要が生じた時は、まず、共有バス８８２上の信号を観察し、他の端末が使用しているかどうかを調べる。他の端末が共有８８２バスを使用していない場合、データ送信端末（例えば８８０２ ）は、宛先のデータ受信端末（例えば８８０３ ）の４８ビットのＭＡＣアドレスを書き込んだフレームをフレーム生成手段８８８にて生成し、共有バス８８２上に送信する。この方法では、偶然、２つ以上の端末が同時にフレームを共有バス８８２に送信し始める場合が存在し、この場合、共有バス８８２上で信号が競合し不具合が発生する。この不具合に対しては、フレームを送信した端末が共有バス８８２上の信号を観察し、信号の衝突を検出した場合、直ちにフレームの送信を停止し、一定時間後に送信を再開するといった方法等を用いて、複数端末によるフレーム送信開始の競合は回避することができる。
【００４１】
端末インタフェース８８４の受信部は、共有バス上に出力されるフレームを常時観察し、自分宛のフレームが共有バス上に送信された場合、前記フレームを取り込むことによって、データ送信端末から送られた情報をデータ受信端末が受信することができる。具体的には、端末インタフェース８８４内のＭＡＣフィルタ８８６は、製造時に個々の端末インタフェースに割り振られたＭＡＣアドレスと、ブロードキャスト・アドレスを認識し、前記ＭＡＣアドレスまたはブロードキャスト・アドレスが宛先に書き込まれたフレームが共有バス８８２に出力された場合、前記フレームをＭＡＣフィルタ８８６が取り込み、該取り込んだフレームを端末インタフェース８８４が端末８８０へ送ることによって、データ送信端末が送信したフレームを、データ受信端末が受信することができる。
【００４２】
次に、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ） を用いた、データ送信端末からデータ受信端末へのデータグラム転送法について、図６０を参照しながら具体的に説明する。
【００４３】
前記した従来のイーサネットのＭＡＣアドレスによるフレームの転送方法は、データ送信端末とデータ受信端末が同一のイーサネット上にある場合に、有効なデータ転送方法である。すなわち、従来のイーサネットでは、データ送信端末は、送信フレームの宛先アドレス・フィールドに、宛先のデータ受信端末のＭＡＣアドレスを書き込んでフレームを送信し、データ受信端末はイーサネット上に出力されるフレームの宛先アドレスを観察し、前記フレームの宛先アドレスがブロードキャスト・アドレスの場合、またはデータ受信端末のＭＡＣアドレスに等しい場合、前記フレームをデータ受信端末が取り込むことによって、データ送信端末からデータ受信端末へのデータ転送が実行される。従って、宛先のデータ受信端末がデータ送信端末と同じイーサネット上にない場合、データ送信端末から送信されたフレームは、前記イーサネット上のどのデータ受信端末によっても受信されず、前記データ送信端末から前記データ受信端末へのデータ転送を実行することはできない。従って、同一のイーサネット上にないデータ受信端末へデータを転送するには、何らかの方法を用いて、データ転送を行わなければならない。以下、そのような場合におけるＩＰによるデータ転送方法について説明する。
【００４４】
インターネット上の端末（Ｈｏｓｔ）には、一意に識別できるような３２ビットのＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ）アドレスが割り当てられていて、インターネットでは、前記ＩＰアドレスを用いて、データ送信端末からデータ受信端末へのデータ転送が行われる。また、異なるイーサネットは、ＩＰルーターによって相互接続され、前記ＩＰルーターによって、送信フレーム中の宛先ＩＰアドレスを基に送信フレーム中の宛先ＭＡＣアドレスが変換される。
【００４５】
具体的には、図６０において、一方のイーサネットＥ０上の端末８９０から他方のイーサネットＥ１上の端末８９４へデータを転送する場合、まず、イーサネットＥ０上の端末８９０からＩＰルーター８９６へ、データグラムの宛先アドレスがＣｉｐで、フレームの宛先アドレスがＲｍａｃ となるようなフレームを送信する。ＩＰルーター８９６のイーサネットＥ０に対するインターフェース部は、前記フレームの宛先アドレスがＲｍａｃ であるので、前記フレームを受信することができる。ＩＰルーター８９６は、前記フレームを受信し、前記フレームのデータグラムの宛先に書かれているアドレス（Ｃｉｐ） を基にＩＰルーター８９６内のテーブルを参照し、イーサネットＥ１上の端末８９４のＭＡＣアドレス（Ｃｍａｃ）を検索する。次に、ＩＰルーター８９６は、前記フレームの宛先ＭＡＣアドレスを前記検索したＭＡＣアドレス（Ｃｍａｃ）に置き換えて、該フレームをイーサネットＥ１上に送信する。最後に、前記イーサネットＥ１に送信されたフレームは、前記フレームの宛先アドレスがＣｍａｃ であるので、イーサネットＥ１上の端末８９４によって取り込まれる。以上説明した手順によって、データ送信端末から送信されたフレームは、ＩＰルーターを経由して、データ受信端末へ転送される。
【００４６】
以上説明したＩＰによるデータ転送方法は、データ送信端末とデータ受信端末が同一イーサネット上にない場合に有効な転送方法であり、データ送信端末とデータ受信端末が同一イーサネット上にある場合は、前記ＩＰによるデータ転送方法を用いる必要はないが、データ送信端末とデータ受信端末が同じイーサネットにある場合とない場合を区別して、送信データを送信フレームにマッピングするのは面倒なので、前記したデータ送信端末とデータ受信端末が同一イーサネット上にある場合も、ＩＰによるデータ転送方法が用いられる。すなわち、データ送信端末とデータ受信端末が同一イーサネット上にある場合も、送信データを，宛先ＩＰアドレスを書き込んだデータグラムに入るように分割し、前記データグラムを、宛先ＭＡＣアドレスが書き込まれたフレームに挿入することによって、送信データから送信フレームへのマッピングが行われている。
【００４７】
以下、データ送信端末が、宛先のＩＰアドレスから、宛先のデータ受信端末のＭＡＣアドレスまたはＩＰルーターのＭＡＣアドレスを獲得するＡＲＰ（ Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｓｉｏｎ Ｐｒｏｔｏｃｏｌ） と呼ばれる方法について図６１を参照しながら説明する。
【００４８】
前記したように、データ送信端末が同一のイーサネット上のデータ受信端末へデータ転送を行う場合、宛先のデータ受信端末のＭＡＣアドレスが必要である。また、データ送信端末が同一のイーサネット上にないデータ受信端末へデータ転送を行う場合、前記データ送信端末と同一のイーサネット上にある前記データ転送に関係するＩＰルーターのＭＡＣアドレスが必要である。データ転送に先だって、前記データ受信端末のＭＡＣアドレスまたは前記ＩＰルーターのＭＡＣアドレスは、ＡＲＰと呼ばれる方法によって獲得することができる。
【００４９】
具体的には、データ送信端末８９８は、まず、データ転送に先だって、獲得したいＭＡＣアドレスに対応するＩＰアドレスを書き込んだ、ＡＲＰ要求メッセージと呼ばれる定められたフォーマットのデータグラムを、サブネットワーク内の端末（Ｈｏｓｔ）にブロードキャストする。次に、前記ＡＲＰ要求メッセージを受信した、サブネットワーク内の端末（Ｈｏｓｔ）のうち、前記ＡＲＰ要求メッセージに対し答えることのできる端末（Ｈｏｓｔ）８９０は、前記ＡＲＰ要求メッセージ中に書き込まれたＩＰアドレスに対応するＭＡＣアドレスを書き込んだ、ＡＲＰ応答メッセージと呼ばれる定められたフォーマットのデータグラムを、前記データ送信端末に送信することによって、前記データ送信端末８９８は宛先のＭＡＣアドレスを獲得することができる。ただし、データ受信端末がデータ送信端末と同一のサブネットワーク上にある場合はデータ受信端末であるが、同一サブネットワーク上にない場合は対応するＩＰルーターが返答する。
【００５０】
一般に、サブネットワーク内の端末（Ｈｏｓｔ）に対しブロードキャストされたフレームは、サブネットワーク内のすべての端末（Ｈｏｓｔ）によって受信される。前記フレームを受信した端末インタフェースは、受信フレームのうち、フレーム・データ領域に格納されているデータグラムを端末（Ｈｏｓｔ）へ転送する。前記データグラムを受信した端末（Ｈｏｓｔ）は、ＴＣＰ／ＩＰ処理ルーチンを起動し、前記データグラムに対し処理を行う。従って、ブロードキャストされたＡＲＰ要求メッセージに対し、前記ＡＲＰ要求メッセージに対し応答することのできる端末（Ｈｏｓｔ）では、前記データグラムによってＡＲＰ応答メッセージを作成し、前記ＡＲＰ応答メッセージを返送するプロセスが起動されるが、前記ＡＲＰ要求メッセージに対し応答することのできない端末（Ｈｏｓｔ）では、引き続いてプロセスは起動されずに、前記ＡＲＰ要求メッセージに対する処理は終了してしまう。従って、前記ＡＲＰ要求メッセージに対し応答することのできない端末（Ｈｏｓｔ）にとっては、前記ＡＲＰ要求メッセージを受信することによって、処理中のプロセスを中断して、前記ＡＲＰ要求メッセージに対し不必要な処理を行わなければならないといった問題点があった。
【００５１】
前記問題点に対しては、以前送信したＡＲＰ要求メッセージに対する応答を基に、ＩＰアドレスとＭＡＣアドレスの対応表（ＡＲＰテーブルと呼ぶ）を作成し、ＡＲＰを行わなければならなくなったデータ送信端末は、まず、ＡＲＰテーブルを参照し、前記テーブルでＭＡＣアドレスが検索できた場合、ＡＲＰ要求メッセージをブロードキャストしないことによって、ブロードキャストする回数を減らすことができる。
【００５２】
次に、ネットワーク情報を集中管理するのに有用なネットワーク・インフォメーション・サービス（Ｎｅｔｗｏｒｋ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｉｃｅ ；以下、ＮＩＳと略記する）について説明する。
【００５３】
ネットワークに接続された端末（Ｈｏｓｔ）は、ホストネーム、ホストＩＰアドレス、ユーザネーム、ユーザ・パスワードといったネットワーク情報を必要とする。例えば、前記したデータ送信端末からデータ受信端末へのデータ転送において、ユーザは、データ受信端末のＩＰアドレスの代わりにデータ受信端末のホストネームを用いて、前記データ受信端末を指定し、データ転送を行う場合の方が多い。上記の場合、データ受信端末のホストネームをＩＰアドレスに変換する変換テーブル（ｈｏｓｔｓ ファイル） が必要であり、前記データ送信端末はデータ転送に先だって、ユーザから指定されたデータ受信端末のホストネームを、前記変換テーブル（ｈｏｓｔｓ ファイル） を用いてＩＰアドレスに変換し、該ＩＰアドレスを用いてデータ転送を開始する。従って、ユーザがデータ受信端末のホストネームを用いてデータ転送を行うためには、データ送信端末にホストネームからＩＰアドレスに変換するのに用いる変換テーブル（ｈｏｓｔｓ ファイル） が必要である。
【００５４】
ネットワークに接続された端末（Ｈｏｓｔ）の数が少ない場合は、前記端末（Ｈｏｓｔ）のネットワーク情報が書き込まれたファイル（例えば、ｈｏｓｔｓ ファイル）を直接編集することによって、前記ネットワーク情報を管理してもそれほど面倒ではないが、ネットワークに接続された端末（Ｈｏｓｔ ） の数が増加するに従って、前記ネットワークに接続された端末（Ｈｏｓｔ）の前記ネットワーク情報が書き込められたファイルを直接編集して、前記ネットワーク情報を管理することはたいへん面倒となる。なぜなら、前記ネットワーク情報が変更される度に、前記ネットワークに接続された端末（Ｈｏｓｔ）の数だけ前記ネットワーク情報が書き込まれたファイルを編集し直さなければならないからである。従って、ネットワークに接続されたすべての端末（Ｈｏｓｔ）が必要とするようなネットワーク情報は、個々の端末（Ｈｏｓｔ）の対応するファイルを直接編集することによって、前記ネットワーク情報を管理する方法よりシステム管理者が１つのファイルを編集して集中管理し、前記１つのファイルがネットワークに接続された端末（Ｈｏｓｔ）に分配される方法の方が優れている。ＮＩＳは、前記したような集中管理方法を、サブネットワークのユーザに提供する。
【００５５】
以下、図６２を参照しながら、従来のＮＩＳの構成について具体的に説明する。サブネットワークに属する端末（Ｈｏｓｔ）のうち、同一のネットワーク情報を共有する端末（８９２，８９４，８９８，９０４）の集合をＮＩＳドメインと定義する。このＮＩＳドメインに属する端末（８９２，８９４，８９８，９０４）には、ネットワーク情報（以下、ＮＩＳ情報と呼ぶ）を管理し、ユーザからのＮＩＳ情報の問い合わせに答えるＮＩＳサーバー（８９３，９００，９０６）、およびＮＩＳ情報をサーバーに問い合わせるＮＩＳクライアント（８９６，９０２，９０８）が存在する。また、ＮＩＳドメインに属する端末（Ｈｏｓｔ）が持つネットワーク情報のうち、端末固有のネットワーク情報が格納されたファイルをＮＩＳファイルと定義し、ＮＩＳドメインに属する端末間で共有するネットワーク情報が格納されたファイルをＮＩＳマップと定義する。ＮＩＳドメインに属する端末（Ｈｏｓｔ）が、ＮＩＳファイルとＮＩＳマップを利用する方法としては、ＮＩＳファイルにＮＩＳマップが追加される方法と、ＮＩＳファイルがＮＩＳマップに置き換えられる方法と、ＮＩＳマップが使用されずＮＩＳファイルのみ使用される方法等がある。
【００５６】
上記のように、ＮＩＳでは、ネットワークに接続された端末間で共有されるネットワーク情報は、システム管理者が管理するファイルで集中管理されるが、前記集中管理されるファイルは、ネットワークに接続されたすべての端末（Ｈｏｓｔ）に分配され、前記分配されたネットワーク情報が、ネットワークに接続した端末（Ｈｏｓｔ）によって利用される。具体的には、ＮＩＳサーバーには、ＮＩＳドメインに唯一存在するＮＩＳマスタサーバー（８９３）と、ＮＩＳスレーブサーバー（９００，９０６）の２種類のサーバーが存在し、ネットワークのシステム管理者がＮＩＳマスタサーバー８９３のＮＩＳマップを編集管理し、ＮＩＳマスタサーバー８９３が、ＮＩＳマップが変更された場合に前記変更されたＮＩＳマップをＮＩＳドメインに属するＮＩＳスレーブサーバー９００，９０６に分配することによって、サブネットワークに属する端末のネットワーク情報は集中管理される。
【００５７】
また、ネットワークに接続した端末（Ｈｏｓｔ）には、十分なディスク容量を持った端末（Ｈｏｓｔ）（例えば、図６２の８９８あるいは９０４）と、ユーザファイルを格納するのには不十分であるが、システムファイルは格納することができるディスク容量を持ったデータレス・クライアント（例えば図６２の８９４あるいは８９８）と、ディスクを持たないディスクレス・クライアント（例えば図６２の８９４）とが存在する。一般的には、端末（Ｈｏｓｔ）またはデータレス・クライアントにおいては、ＮＩＳサーバー・プロセスとＮＩＳクライアント・プロセスが起動され、ディスクレス・クライアントまたはデータレス・クライアントにおいては、ＮＩＳクライアント・プロセスのみ起動されている。端末（Ｈｏｓｔ）のユーザ・プロセスが、ネットワーク情報が必要になった場合、前記ユーザ・プロセスが、端末（Ｈｏｓｔ）において起動しているＮＩＳクライアント・プロセスに対し、ネットワーク情報の要求を行う。前記ネットワーク情報の要求を受けたＮＩＳクライアント・プロセスは、前記ネットワーク情報の要求を、ネットワーク上のＮＩＳサーバー・プロセスが起動している端末（Ｈｏｓｔ）へリレーイングする。ＮＩＳサーバー・プロセスは、前記ネットワーク情報の要求に対する応答を、前記ＮＩＳクライアント・プロセスを経由することによって、前記ユーザ・プロセスに転送する。なお、図６３および図６４に、従来のネットワーク情報のアクセス・アルゴリズムを図示する。なお、図６３および図６４に示すフローチャートは、図中のＬ２５で連結されているものである。
【００５８】
ＮＩＳクライアントは、ネットワーク上に存在するＮＩＳサーバーにネットワーク情報の要求を出す場合、該ＮＩＳクライアントが帰属（ｂｉｎｄ）しているＮＩＳサーバーにのみ、前記要求を送信する。以下、ＮＩＳクライアントのＮＩＳサーバーへの帰属（ｂｉｎｄ）アルゴリズムについて、具体的に説明する。
【００５９】
ＮＩＳクライアントは、起動時、ＮＩＳサーバーに帰属（ｂｉｎｄ）するため、ｙｐｂｉｎｄ要求メッセージを網にブロードキャストし、該ｙｐｂｉｎｄ要求メッセージに対し、該ＮＩＳクライアントに一番早くｙｐｂｉｎｄ応答メッセージを送信したＮＩＳサーバーに、該ＮＩＳクライアントは帰属（ｂｉｎｄ）するという方法が採用されている。また、ＮＩＳクライアントのＮＩＳサーバーへの参照要求に対し、ＮＩＳサーバーの応答がタイムオーバーした場合、ＮＩＳクライアントは、ＮＩＳサーバーへの帰属（ｂｉｎｄ）をやり直すが、前記帰属（ｂｉｎｄ）のやり直しの際にも、ネットワークのブロードキャスト機能が用いられている。すなわち、前記ＮＩＳクライアントは、ｙｐｂｉｎｄ要求メッセージを網にブロードキャストし、前記ｙｐｂｉｎｄ要求メッセージに対し、前記ＮＩＳクライアントに一番早くｙｐｂｉｎｄ応答メッセージを送信したＮＩＳサーバーに、前記ＮＩＳクライアントは帰属（ｂｉｎｄ）し直す、という方法が採用されている。なお、図６５に、従来のＮＩＳクライアントのＮＩＳサーバーへの帰属（ｂｉｎｄ）アルゴリズムを示す。
【００６０】
しかし、端末の起動時、端末（Ｈｏｓｔ）のＣＰＵは起動処理に忙しく、前記端末にＮＩＳサーバーが存在する場合でも、前記ＮＩＳサーバーが前記クライアントの前記ブロードキャストに応じることができないので、一般的に、ＮＩＳクライアントは、該ＮＩＳクライアントが起動している端末（Ｈｏｓｔ）以外の端末のＮＩＳサーバーに帰属することになる。従って、同一端末（Ｈｏｓｔ）に、ＮＩＳサーバーとＮＩＳクライアントが起動されている場合でも、該ＮＩＳクライアントは、ネットワークを経由して他の端末で起動しているＮＩＳサーバーにネットワーク情報を要求することとなり、効率が悪いといった問題点があった。
【００６１】
次に、図６６を参照しながら、ディスクレス・クライアントの起動手順（ｂｏｏｔ−ｓｔｒａｐ）について、具体的に説明する。ディスクレス・クライアントのブートストラップには、以下で説明する、ＢＯＯＴＰ（ＢＯＯＴｓｔｒａｐ Ｐｒｏｔｏｃｏｌ） と、ｂｏｏｔｐａｒａｍＲＰＣによる方法の２通りの方法が知られている。
【００６２】
ＢＯＯＴＰは、多くのパーソナル・コンピュータで採用されているブートストラップである。ディスクレス・ワークステーションは、自分の端末のＭＡＣアドレスしか、ネットワーク情報として持っていないので、自分端末のＩＰアドレス、ルートファイルシステムのある端末の名前、システムファイルのある端末の名前、スワップ領域のある端末の名前等の、ブート時に必要な情報を、ネットワークを経由して手に入れなければならない。図６６（ａ）に示すように、ＢＯＯＴＰでは、まず、ディスクレス・クライアント９１０は、ネットワークに接続している端末にＢＯＯＴＰ要求メッセージをブロードキャストし、ネットワークに接続している端末（Ｈｏｓｔ）のうち、ブートサーバー９１２が、前記ＢＯＯＴＰ要求メッセージに対し必要な情報を埋め込んだＢＯＯＴＰ応答メッセージを前記ディスクレス・クライアント９１０に送ることによって、前記ディスクレス・クライアント９１０はブート時に必要な情報を得ることができる。ディスクレス・クライアント９１０は、前記ＢＯＯＴＰ応答メッセージを受信するまでは、自分のＩＰアドレスがわからないので、ブートサーバー９１２は、前記ＢＯＯＴＰ応答メッセージを、宛先ＭＡＣアドレスを書き込んだブロードキャストによって、前記ディスクレス・クライアント９１０に転送する。
【００６３】
一方、図６６（ｂ）に示すように、ｂｏｏｔｐａｒａｍＲＰＣによるブートストラップでは、まず、ディスクレス・クライアント９１４が、ブート時に、ＲＡＲＰ（Ｒｅｖｅｒｓｅ Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）要求メッセージをネットワーク上にブロードキャストし、前記ＲＡＲＰ要求メッセージに対して、ネットワークに接続された端末のうち前記ディスクレス・クライアントをブートするのに最も適当なブートサーバー（図６６では９１５）が、最初に応答を返すことによって、前記ディスクレス・クライアント９１４は、ブートするのに必要な情報を得ることができる。また、前記ブートサーバー９１５以外のネットワークに接続されたブートサーバー（図６６では９１６）が、前記ＲＡＲＰ要求メッセージに対して遅れて応答を返すことによって、前記ブートサーバー９１５が他の処理の実行に忙しい場合でも、前記ディスクレス・クライアント９１４がブートすることができる。
【００６４】
ここまで述べたように、従来のＡＴＭ交換システムは、電話網の交換機の構成を基に、システム設計が行われているので、ＡＴＭ交換システムにおけるデータ通信は、基本的には、電話網の場合と同じようなコネクション型のデータ通信である。すなわち、データ通信を行う必要の生じたデータ送信端末は、データ転送に先だって、まず、網に対し呼設定要求を行い、網が、前記呼設定要求を受け入れられる場合、前記呼設定要求に対し、該当するコネクションを設定する。データ送信端末は、前記呼設定が終了してから、網が設定したコネクションを用いてデータ転送を開始する、という方法を採用している。
【００６５】
一方、前記したように、従来から行われているコンピュータ間通信の多くは、コネクションレス型のデータ通信であった。すなわち、データ送信端末は、網に対し呼設定要求等を行わずに、データ通信を行う必要の生じた時点で、宛先を書き込んだパケットの送信を行う。前記パケットは、網の都合によって宛先のデータ受信端末まで到着しない場合が存在するが、データ送信端末は、定義されたプロトコルまたは上位ソフトウェアによって、送信パケットが宛先のデータ受信端末まで届いたかどうか判定し、前記パケットが宛先のデータ受信端末まで届かなかった場合、前記パケットの再送等の方法によってデータ転送を行っている。
【００６６】
前述した通り、ＡＴＭ交換技術は、Ｂ−ＩＳＤＮを実現する唯一の解として、現在、活発に研究・開発が行われているが、従来構成のＡＴＭ交換システムにおいて、コンピュータ間のデータ通信の実現方法に関して、以下に示す２通りのアプローチがある。第１のアプローチの方法は、コネクション型データ通信を基に設計された従来のＡＴＭ交換システムにおいて、コンピュータ間のデータ通信を、コネクション型データ通信で実現しようという方法である。第２のアプローチの方法は、コネクション型データ通信を基に設計された従来のＡＴＭ交換システムにおいて、コンピュータ間のデータ通信を、従来のコンピュータ間のデータ通信と同じようにコネクションレス型データ通信で実現しようという方法である。
【００６７】
第１のアプローチの方法には、前述した通り、以下のような問題点がある。まず、１つ目の問題点は、コンピュータ間のデータ通信をコネクション型のデータ通信で実行した場合、呼設定に要する時間のためのデータ転送効率の低下である。２つ目の問題点は、ＣＬＳＦ処理でコンピュータ間のデータ通信を行った場合、ＣＬＳＦ処理にコンピュータ間のデータ通信の集中によるコンピュータ間のデータ通信のエンド・エンド間での遅延の増大と、コンピュータ間のデータ通信用のセルの廃棄の増大である。また、従来のコンピュータ間のデータ通信は、コネクションレス型のデータ通信として発展し、現在、コネクションレス型のデータ通信方法としての資産が相当多く存在するが、第１のアプローチの方法を採用した場合、前記従来のコネクションレス型のデータ通信における過去の資産をどう引き継いでいくかに問題点が存在する。
【００６８】
一方、第２のアプローチを採用した場合、前記したコンピュータ間のデータ通信におけるコネクションレス型データ通信の過去の資産をそのまま引き継ぐことができるので、ＡＴＭ交換システムにおいて、従来方法によるコンピュータ間のデータ通信が行えるという大きな利点がある。しかし、コネクション型データ通信を基に設計された従来のＡＴＭ交換システムにおいて、コンピュータ間のデータ通信に対し、コネクションレス型のデータ通信を基に設計された従来のコンピュータ間のデータ通信方法をそのまま適用することはできず、従来のコンピュータ間のデータ通信方法を、従来のＡＴＭ交換システムに合うように改造しなければならない。または、逆に、従来のＡＴＭ交換システムを、従来のコンピュータ間のデータ通信方法に合うように改造しなければならない。
【００６９】
以下、従来のＡＴＭ交換システムで、従来方法によるコンピュータ間通信を行う場合の問題点について、具体的に説明する。
【００７０】
第１の問題点は、呼設定が終了するまで、データ転送が開始できないことによるデータ転送の効率の低下である。従来のＡＴＭ交換システムで、コンピュータ間のデータ通信を行う場合、データ転送に先だって呼設定が行われなければならず、データ転送に比べて呼設定に時間が要する場合、データ転送の効率が低下してしまうという問題点があった。
【００７１】
この問題点自体は、平成５年３月の信学会ＩＮ研究会で発表された「ＡＴＭ−ＬＡＮにおけるデータ転送実現法（江崎、津田、夏堀）」で示されたような、ネットワークに接続された端末（Ｈｏｓｔ）間に予めコネクションを設定しておいて、データ通信を行う必要の生じた端末（Ｈｏｓｔ）は、前記コネクションを用いてデータ転送を行うという方法を採用することで解決される。すなわち、サブネットワーク内、サブネットワーク外のコンピュータ間のデータ通信を行う端末（Ｈｏｓｔ）間に、ＱＯＳの保証を必要としないコネクションを予め設定しておき、前記端末が前記データ通信を行う必要が生じた時に、前記コネクションを用いることによって、呼設定を行わずにデータ通信を行うことができる。この方法によれば、データ通信に際し、呼設定を行い、呼設定の終了までデータ転送を待つ必要がないので、レイテンシに対して要求の厳しいコンピュータ間のデータ通信も、効率よく実行することができる。しかし、この方法においては、セルに書かれたＶＰＩによって、前記予め設定されたＱＯＳの保証を必要としないコネクションが識別される（ＶＰルーティング） ため、データ送信端末は、前記コネクションを用いてデータ転送を行う場合、前記コネクションに対応するＶＰＩを、何らかの手段を用いて獲得しなければならない。上記方法においては、前記データ送信端末が、ＡＲＰ要求セルをサブネットワークにブロードキャストし、相手端末あるいはＡＲＰサーバーが、ＡＲＰ応答セルを前記端末に送り返すことによって、前記コネクションに対応するＶＰＩを前記端末が獲得する。それゆえ、上記方法には、ＡＲＰ要求セルをサブネットワークにブロードキャストする際に、網のブロードキャスト機能を使用する問題点と、スター型のネットワークの場合、宛先の端末にブロードキャストしてデータを送信できるからといって、シングルキャストして、該宛先の端末にデータが届くかどうか保証ができないといった問題点と、未知ＶＰＩに対して、ＡＲＰ応答セルを端末が受信するまでデータ転送を開始することができないといった問題点があった。
【００７２】
第２の問題点は、従来のコンピュータ間のデータ通信方法は、ネットワークにブロードキャスト機能があることを前提として、データ通信方法が構築されていることである。
【００７３】
第２の問題点に対しては、従来のＡＴＭ交換システムにおいて、何らかの方法によって、網にブロードキャスト機能を持つことによって、コンピュータ間のデータ通信を従来の方法で行うという対処方法が考えられる。例えば、前述したように、コピースイッチ、コピー機能を提供するコピー手段、またはコピーサーバーを実装することによって、網にブロードキャスト機能を持つことができる。しかし、これらの対処方法ではそれぞれ新たな問題点を生ずる。以下、各々の機能を網に実装した場合の問題点について、具体的に説明する。
【００７４】
まず、セルスイッチの代わりに、コピースイッチを採用することによって、該コピースイッチで、ブロードキャスト機能を実行するという方法を採用した場合、すでに説明した通り、以下のような問題点があった。すなわち、コピースイッチの出力ポートは、コピーコネクションに属するセルと、コピーコネクションに属しないセルのうち、いずれかを選択して出力しなければならず、前記出力ポートのアルゴリズムが複雑になってしまい、コピースイッチは、その分、セルスイッチより高価になってしまうという問題点があった。また、コピースイッチをＬＳＩ化する場合、ＬＳＩに入るコピーセル用バッファの大きさには制限があるので、コピーセル用バッファの大きさを十分大きくすることはできず、コピーコネクションに属するセルは、オーバーフローしやすく、廃棄されやすいといった問題点があった。また、前記セルが廃棄された場合、クライアントは、前記セルのタイムオーバー後、再びブロードキャスト・セルを再送するので、クライアントにとっては、タイムオーバーするまで待つことによる遅延の増大という問題点を引き起こし、網にとっては、ブロードキャスト・セルの再送によって、ブロードキャスト・セルの増大といった問題点があった。
【００７５】
また、セルスイッチにコピー手段を付加し、該コピー手段でブロードキャスト機能を実行する方法を採用した場合、前述した通り以下のような問題点があった。すなわち、コピー手段の場合、コピースイッチの場合に比べて、より大きなコピーセル用バッファを実装することができるが、コピー手段に実装することのできるコピーセル用バッファの大きさは有限であるので、コピーコネクションに属するセルは廃棄されやすいといった問題点があった。また、コピー手段の出力が１つしかない場合、同時には、１つのセルしかコピーし出力することができないので、コピーコネクションに属するセルの、エンド・エンド間のブロードキャスト・サービスに時間がかかってしまう、といった問題点があった。さらに、スイッチ規模が大きい場合や、他のＡＴＭ交換機にコピー機能がない時に、他の交換機に対してもコピー機能を提供しなければならず、コピーセル用バッファに入力されたセルに対し、コピーし出力しなければならない回数が増大してしまうといった問題点があった。従って、この場合、エンド・エンド間のブロードキャスト・サービスの遅延の増大と、バッファにセルが滞留する時間の増大による、コピーコネクションに属するセルの廃棄の増大と、そして、前記セル廃棄の問題点に対して、コピーセル用バッファを大きくしなければならないといった問題点があった。
【００７６】
一方、ＡＴＭ交換システムに属する端末（Ｈｏｓｔ）の１つをコピーサーバーとし、前記コピーサーバーによって、網のブロードキャスト・サービスを行う方法を採用した場合、コピーセル用バッファに対する問題点は事実上解消するが、前述した通り、以下のような問題点は解決することができない。すなわち、コピーサーバーの場合、出力が１つしかないので、同時には１つのセルしかコピーし出力することができず、エンド・エンド間のブロードキャスト・サービスに時間がかかってしまうといった問題点があった。また、通常のコピーサーバーの実装では、コピーサーバーは、ＯＳ上の１つのソフトウェア・プロセスとして実装されるので、コピーサーバーにおいて１つのセルをコピーし出力するのに時間がかかってしまうといった問題点があった。
【００７７】
以上説明してきた問題点は、従来のＡＴＭ交換システムにおける、コピー機能の実装形態上の問題点であったが、実装形態以外にも、コピーアルゴリズムにも、以下のような問題点が存在する。
【００７８】
図６７（ａ）は、単純なブロードキャスト・アルゴリズムを採用した場合の、交換機に入力されたブロードキャスト・コネクションに属するセルの流れを示したものである。単純なブロードキャスト・アルゴリズムを採用した場合、交換機に入力されたブロードキャスト・コネクションに属するセルは、図示したように、セルスイッチ９１８に接続したすべての後処理部９１９１ ，９１９２ ，９１９３ ，９１９４ へ出力されるように、セルスイッチ９１８内でコピーされる。従って、前記したアルゴリズムを採用した場合、ブロードキャスト・コネクションに属するセルが入力されたポートと同じポートに存在する後処理部９１９１ にも、該コピー・セルが転送されるという問題点があった。従って、前記したアルゴリズムを採用した場合、図６７（ｂ）において、交換機９２０から交換機９２１に、ブロードキャスト・コネクションに属するセルが入力された場合、交換機９２１内で前記セルに対してコピーが行われた結果、交換機９２０にも、再びコピーセルが転送されてしまうといった問題点があった。
【００７９】
この問題点は、前記単純なブロードキャスト・アルゴリズムに、ブロードキャスト・コネクションに属するセルが入力された前処理部と同じポートに存在する後処理部には転送しないアルゴリズムを付加することによって、解決することができる。しかし、該アルゴリズムを採用することで、セルスイッチは、前処理部ごとに、前記前処理部に対応するブロードキャスト・アルゴリズム（ブロードキャスト・コネクションに属するセルが入力された前処理部と同じポートに存在する後処理部には、前記セルをコピーしたセルを転送しないというアルゴリズム）を持たなければならず、１つのブロードキャスト・アルゴリズムで、簡単にブロードキャスト・サービスを提供することができないといった問題点がある。
【００８０】
また、ＡＴＭ交換システムの交換機間の接続にループが存在する場合、ループの影響を考慮しない、ブロードキャスト・アルゴリズムを採用した場合、前記ループによって、ブロードキャスト・ストームが発生してしまうといった問題点がある。すなわち、図６７（ｃ）において、交換機９２５に、ブロードキャスト・コネクションに属するセルが入力された場合、交換機９２５のブロードキャスト・アルゴリズムによって、コピーセルが交換機９２６に転送され、交換機９２６のブロードキャスト・アルゴリズムによって、コピーセルが交換機９２７に転送される。交換機９２７に転送されたコピーセルが、交換機９２７のブロードキャスト・アルゴリズムによって、交換機９２６に転送された結果、再び、交換機９２５のブロードキャスト・アルゴリズムによって、コピーセルが交換機９２６に転送されてしまうという、ブロードキャスト・ストームの発生といった問題点があった。また、前記ネットワーク内の経路にループが存在する場合を考慮した、ブロードキャスト・アルゴリズムは複雑であり、簡単なアルゴリズムで、ブロードキャスト・コネクションを提供することができない、といった問題点があった。
【００８１】
さらに、何らかの方法によって、網にブロードキャスト機能を持つことによって、コンピュータ間のデータ通信を、従来の方法で行う場合、以下のような問題点も存在する。
【００８２】
前記したように、従来のコンピュータ間のデータ通信方法において、網のブロードキャスト機能を使用するのは、クライアントが、サーバーに対して要求を出す場合のみであった。すなわち、ＡＲＰにおいては、ＭＡＣ アドレスを獲得したいクライアントが、ＭＡＣ アドレスを獲得するために、網のブロードキャスト機能を使用し、ＮＩＳにおいては、ＮＩＳサーバーのＩＰアドレスを知らないＮＩＳクライアントが、ＮＩＳサーバーのＩＰアドレスを獲得するために、網のブロードキャスト機能を使用する。また、ディスクレス・クライアントは、ブートサーバーのＩＰアドレス等を獲得するために、網のブロードキャスト機能を使用していた。従って、従来のコンピュータ間のデータ通信方法においては、サーバーのアドレス等がわからない場合にのみ、クライアントは、網のブロードキャスト機能を用いて、サーバーとデータ通信が行われる。従って、ブロードキャストされたデータは、前記データをブロードキャストしたクライアントのサーバーにおいてのみ有効であり、前記サーバー以外の端末（Ｈｏｓｔ）においては、前記データは意味をなさないので、前記サーバー以外の端末（Ｈｏｓｔ）が、前記ブロードキャストされたデータを受信した場合、前記データは参照されずに廃棄されるといった問題点も存在する。
【００８３】
一方、すでに説明したように、端末のネットワーク・インターフェースは、端末のＭＡＣ アドレスとブロードキャスト・アドレスのみ認識し、受信パケットのうち、前記アドレスが宛先に書かれたパケットのみ、前記インターフェース内に取り込む。前記インターフェース内に取り込まれたパケットのうち、定義されたプロトコルに従って、受信パケットの情報フィールドのみ、データ受信バッファから、端末の記憶メモリに転送され、端末のＯＳ上のプロトコル処理プロセスによって処理されている。また、受信データの中には、端末での処理のレイテンシに対して要求の厳しい場合（ＡＲＰ、ＮＩＳ等） が存在するので、処理中のプロセスの実行を中断して、受信データに対して処理を行う場合も存在する。
【００８４】
従って、前記サーバー以外の端末（Ｈｏｓｔ）が、前記ブロードキャストされたデータを受信した場合、実行中のプロセスを中断して、前記データに対して処理を行うが、前記端末にとっては、前記データは意味をなさないため、前記データに対して何も処理が行われずに処理が終了してしまう。その結果として、前記サーバー以外の端末（Ｈｏｓｔ）にとって、前記ブロードキャストされたデータを受信することによって、実行中のプロセスの中断により処理効率が低下するといった問題点があった。
【００８５】
【発明が解決しようとする課題】
従来のＡＴＭでは、ネットワークの情報、例えば他の端末のアドレスと名前の組等は、端末が個別に有していたため、重複したものをそれぞれ持っているという無駄があった。
本発明は、上記課題を解決するためになされたものであり、ネットワークの情報を端末が個別に有することなく、必要なときに獲得できるネットワーク管理方法を提供することを目的とする。
従来のＡＴＭでは、更に、端末が正常に動作しているかどうか（すなわち、生存しているかどうか）の確認を行っていなかったため、正常に動作していない端末との間に呼設定をする場合が生じるという不具合があった。
本発明は、更に、各端末が正常に動作しているかどうかを統括的かつ効率的に確認できるネットワーク管理方法を提供することを目的とする。
【００９３】
【課題を解決するための手段】
本発明は、１つまたは複数の交換機、複数の端末、ならびに前記交換機および前記端末を含むネットワーク構成要素に関する情報を記憶しているネットワーク情報検索装置を備えてなるネットワークにおけるネットワーク管理方法であって、予め前記交換機に対し、各端末と前記ネットワーク情報検索装置との間にそれぞれ所定のユニキャスト・チャネルを設定しておくステップと、前記端末が、前記所定のユニキャスト・チャネルを用いて、他の端末へのコネクションを設定するために必要な情報を前記ネットワーク情報検索装置から獲得するステップとを有してなることを特徴とする。
【００９４】
本発明によれば、コンピュータ等の端末は、該ネットワーク・システムに属するネットワーク構成要素のネットワーク情報（例えば、端末名、アドレス、宛先の端末にデータを送信するためのＶＰＩ／ＶＣＩ値等） が必要な場合、予め設定された特定のチャネル（例えば、ブート・チャネルあるいはインフォメーション・チャネル）を使用して、ネットワーク情報検索装置に、該ネットワーク情報の転送を要求する。
【００９５】
該ネットワーク情報の転送要求を受信したネットワーク情報検索装置は、該ネットワーク情報検索装置が管理するファイル（ＮＩＳファイル等）を検索し、該要求されたネットワーク情報を、前記チャネルを使用して、該要求を送信した端末に転送することによって、該端末は、該ネットワーク情報検索装置が管理するネットワーク情報にアクセスすることができる。
【００９６】
また、本発明よれば、ネットワーク情報検索装置への帰属（ｂｉｎｄ）または帰属先のネットワーク情報検索装置の変更を要求する際に、ｙｐｂｉｎｄパケットをブロードキャストすることによって該要求をネットワーク情報検索装置に送信する従来のコンピュータ等の端末を、以下の方法でサポートすることができる。すなわち、ブロードキャストとして送信されたｙｐｂｉｎｄパケットを、上り方向の前記チャネルを用いることによって、ネットワーク情報検索装置への帰属または帰属先のネットワーク情報検索装置の変更要求を、関連するネットワーク管理装置に送信することができる。また、ネットワーク管理装置は、下り方向のチャネルを使用することによって、設定後または変更後の帰属先のネットワーク情報検索装置に、データを送信するために使用するチャネル（例えば、インフォメーション・チャネル）のＶＰＩ／ＶＣＩ値を、該要求を送信した端末に送信することができる。
【００９７】
また、本発明によると、コンピュータ等の端末が、例えばコネクションレス型のデータ通信を行う等のために、宛先の端末名に対するＶＰＩ／ＶＣＩ値等のネットワーク情報を獲得する必要が生じた場合、該端末とネットワーク情報検索装置との間に設定されている前記チャネル（例えば、ブート・チャネルあるいはインフォメーション・チャネル）を用いて、前記情報の検索を前記ネットワーク情報検索装置に要求する。
【００９８】
ネットワーク情報検索装置は、該検索要求を受信した場合、該ネットワーク情報検索装置が管理するファイル（ＮＩＳファイル）等を参照し、該宛先の端末名に対するＶＰＩ／ＶＣＩ値等のネットワーク情報の検索を実行し、該検索した情報を、前記チャネルを用いて、該検索要求を送信した端末に送信する。
【００９９】
このようにして、該検索要求を送信した端末は、該チャネルを経由して、該ネットワーク情報検索装置から転送された、前記情報を用いて、該宛先の端末に対し、所望のデータ通信、例えばコネクションレス型のデータ通信を行うことができるようにしている。
【０１００】
したがって、本発明によれば、ネットワーク構成要素に関する情報を効率的に保持、管理できるとともに、予め前記チャネルを設定しているので、情報を獲得するのに要する時間を短縮できるという利点がある。
【０１０１】
また、本発明は、請求項１に係る発明において、予め前記交換機に対し、各端末と前記ネットワークに含まれる管理装置との間にそれぞれ所定のユニキャスト・チャネルを設定しておくステップと、前記管理装置が、前記所定のユニキャスト・チャネルをそれぞれ用いて各端末に対し適当なタイミングで生存を確認するための信号を送信するステップと、前記管理装置が、各端末に対してそれぞれ送信された前記信号に対する返答の有無により各端末が生存しているか否かを判断するステップとを更に有してなることを特徴とする。
【０１０２】
本発明によると、前記管理装置は、予め各端末との間にそれぞれ設定されている前記チャネルを用いて、各端末に対し適当なタイミングで各端末の生存を確認するための信号を送信する。
【０１０３】
生存確認の対象となった端末が正常に動作している場合は、前記信号は例えばループバックされて、前記管理装置に再び受信されるので、前記管理装置はこの端末が正常に動作していることを確認できる。
【０１０４】
一方、前記信号に対する応答信号を、前記管理装置が受信しなかった場合は、前記管理装置はこの端末は正常に動作していないと確認する。
【０１０５】
これによって、管理装置は、各端末が生存を確認、把握することができるようになり、正常動作していない端末との間に呼を設定してしまうような不都合を排除することが可能となる。
【０１１２】
【発明の実施の形態】
以下、図面を参照しながら発明の実施の形態を説明する。なお、説明の便宜上、次の４項目に分けて説明する。
（１）本発明に係るネットワーク・システムの構成
（２）本発明に係るＶＰＩ／ＶＣＩ割り当てアルゴリズム
（３）サブネット内に複数のノードが存在する場合について
（４）サブネット間のデータ通信について
１．本発明に係るネットワーク・システムの構成
図１は、本発明の一実施例に係るネットワーク・システムの構成を示したものである。ＡＴＭを用いたローカル・エリア・ネットワーク（ＬＡＮ）を、本発明に係るネットワーク・サーバーで構成する場合、基本的に、以下の４つのネットワーク・サーバーで構成することができる。
（ａ）ノード設定サーバー（ｎｏｄｅ ｓｅｔｕｐ ｓｅｒｖｅｒ）
（ｂ）ノード管理サーバー（ｎｏｄｅ ｍａｎａｇｉｎｇ ｓｅｒｖｅｒ）
（ｃ）各種ネームサーバー（ｎａｍｅ ｓｅｒｖｅｒ）
（ｄ）呼設定サーバー（ｃａｌｌ ｓｅｔｕｐ ｓｅｒｖｅｒ）
以下、図１について概略を説明した後、下記した場合について、前記４つのネットワーク・サーバーの動作を具体的に説明する。
（１−１ ）ＬＡＮのブートについて（シングル・ノードの場合）
（１−２ ）端末のブートについて
（１−３ ）ディスクレス・クライアントのブートについて
（１−４ ）ＡＲＰ、ＮＩＳについて
（１−５ ）呼設定について
（１−６ ）予め設定されたコネクションを用いたデータ通信について
（１−７ ）保守・管理について
まず、図１について、概略的な説明をする。なお、図１において実際は、ＡＴＭ交換機２はネットワークサーバー１と端末３との間に設けられるが、説明の便宜上、図１のように示してある。
【０１１３】
ノード設定サーバー（ｎｏｄｅ ｓｅｔｕｐ ｓｅｒｖｅｒ）４は、クライアント（すなわちノード管理サーバー５）からの要求を受け付け、ルーティングタグ・テーブル等のハードウェア２４に対し、直接、書き込んだり／読み出したりすることによって、ハードウェアの設定等を実行する。また、クライアント（ノード管理サーバー５）からの要求によって、ＯＡＭ情報が書き込まれたレジスタからの読み出し等を行う。
【０１１４】
ノード管理サーバー（ｎｏｄｅ ｍａｎａｇｉｎｇ ｓｅｒｖｅｒ） ５は、主として、ノード（すなわちＡＴＭ交換機２）の管理を実行する。すなわち、ＡＴＭ交換機２の入出力線の先に端末が接続されているか否かを監視し、入出力線の先に端末が接続された場合、コンフィグュエーション・ファイル（以下、ｃｏｎｆｉｇファイルと記す）５５に書き込まれている情報に従って、ＡＴＭ交換機２内のルーティングタグ・テーブル等のハードウェア設定を実行する。また、ノード管理サーバー５は、クライアント（呼設定サーバー７）からの、コネクションの設定要求を受け付け、対応するノード設定サーバー４に対して、ハードウェア等の設定要求を送信する。また、ノード管理サーバー５は、ＡＴＭ交換機２内のルーティングタグ・テーブルといったハードウェアの保守・管理を実行するとともに、対象とするノード（ＡＴＭ交換機２）を経由するコネクションに対して、ＯＡＭセルの送受信といった、ＯＡＭ機能を実行したりする。
【０１１５】
各種ネームサーバー（ｎａｍｅ ｓｅｒｖｅｒ） ６０１は、宛先端末名（例えば、ホストネーム、ＩＰアドレス、電話番号等） をキーとして、宛先アドレス（例えば、ＶＰＩ／ＶＣＩ）の検索といった、クライアント（例えば、ＮＩＳクライアント６１） からの要求を受け付け、前記ネームサーバーが管理するテーブルを検索し、検索した結果得られた情報を、クライアントに送信する。本発明を、ＮＩＳを用いない、宛先またはコネクションの管理方法に適用することも可能であるが、以下、本発明の一実施例を具体的に説明するために、ＮＩＳを用いた、宛先またはコネクションの管理方法について説明する。
【０１１６】
呼設定サーバー（ｃａｌｌ ｓｅｔｕｐ ｓｅｒｖｅｒ） ７は、クライアント（すなわち端末３）からの呼設定要求を受け付け、対応するノード管理サーバー５に対し、コネクションの設定を要求する。また、サブネットワーク外の端末への呼設定要求を、該呼設定サーバー７が受け付けた場合、サブネットワーク内のコネクションの設定を、該サブネットワーク内のノード管理サーバー５に要求するとともに、サブネットワーク外の対応するノード管理サーバーに対し、呼設定要求のリレーイングを行う。
【０１１７】
図１に図示したように、端末３とネットワーク・サーバーとの間には、ブート・チャネル１１、メタシグナリング・チャネル１０、インフォメーション・チャネル１２、シグナリング・チャネル１３の４種類のチャネルが設定されていて、本発明においては、端末は、前記４種類のチャネルを用いて、ネットワーク・サーバーとデータ通信を行うことを想定している。
【０１１８】
前記４種類のチャネルのうち、ブート・チャネル１１とメタシグナリング・チャネル１０は、ネットワーク（ＡＴＭ交換システム） の立ち上げ時に、ＡＴＭ交換機２のすべての入出力線に対して、前記入出力線の先に接続されるであろう端末と対応するノード管理サーバーとの間に設定されるものとする。ネットワーク（ＡＴＭ交換システム） の立ち上げ終了後、ＡＴＭ交換機２の入出力線の先に接続された端末が起動した場合、該端末は、必要に応じてブート・チャネル１１またはメタシグナリング・チャネル１０を用いて、対応するノード管理サーバーに前記端末の起動に必要な情報を要求し、該端末は、前記チャネルを用いて前記情報を手に入れることを想定している。本発明の一実施例においては、具体的に説明するために、ブート・チャネル１１とメタシグナリング・チャネル１０は２つの異なるチャネルとして記述しているが、前記２つのチャネルが同一の一つのチャネルとして、ネットワーク・サーバーを構成することも可能である。
【０１１９】
また、前記４種類のチャネルのうち、インフォメーション・チャネル１２とシグナリング・チャネル１３は、端末３の起動時等に必要に応じて、前記端末３と対応するネットワーク・サーバーとの間に設定されるものとする。前記端末３が、コンピュータ等の端末の場合で、ネーム・サーバー６０１とデータ通信を行う必要のある端末であるとき、前記端末３の起動時等に、前記端末３と対応するネーム・サーバーとの間にインフォメーション・チャネル１２が設定され、前記端末３は、前記チャネルを用いて前記ネーム・サーバーとデータ通信を行う、ということを想定している。また、前記端末３が、ＡＴＭ端末等の場合で、新たに呼設定を行う必要のある端末であるとき、前記端末の起動時等に、前記端末と対応する呼設定サーバー７との間にシグナリング・チャネル１３が設定され、前記端末３は、前記チャネルを用いて前記呼設定サーバー７とデータ通信を行うことを想定している。
【０１２０】
１−１．ＬＡＮのブートについて（シングル・ノードの場合）
次に、図２を参照しながら、１つのノード（ＡＴＭ交換機）によって、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）が構成される場合のＬＡＮのブート方法について、具体的に説明する。なお複数のノード（ＡＴＭ交換機） によって、ＬＡＮが構成される場合については、（４） 節で後述する。
【０１２１】
本発明の一実施例においては、４つのネットワーク・サーバーでＬＡＮを構築することを目指している。４つのネットワーク・サーバーの起動順序としては、いろいろな順序が存在するが、本発明の一実施例においては、まず、ノード管理サーバー５が起動し、次に、ノード設定サーバー４が起動し、最後に、ネーム・サーバーと呼設定サーバーが起動する起動順序を例にとって、以下、ＬＡＮのブート手順を具体的に説明する。
【０１２２】
まず、図２において、ノード管理サーバー５内のＡＴＭブートプロセス５２が起動することによって、ノード管理サーバー５は起動される。次に、前記ＡＴＭブートプロセス５２は、ノード設定サーバー４を起動するとともに、ノード管理サーバー５に付属するＨＤ（ＨａｒｄＤｉｓｃ）中の管理ファイル５６の初期化を実行する。ノード設定サーバー４は、起動処理中に、前記ノード設定サーバー４に付属するＨＤが存在する場合、ＨＤ中のバックアップ・ファイル（以下、ｂａｃｋｕｐファイルと記す）４２の初期化と、ＡＴＭ交換機２内に存在するルーティングタグ・テーブル等のハードウェア・テーブル等の初期化を実行する。
【０１２３】
次に、前記ＡＴＭブートプロセス５２は、ノード管理サーバー５内に、端末ブートプロセス５３を起動するとともに、ノード設定サーバー４に、ＡＴＭ交換機２のすべての入出力線に対し、前記入出力線の先に接続されるであろう端末と、前記ノード管理サーバー５内の端末ブートプロセス５３との間にブートチャネル１１の設定を、前記ノード設定サーバー４に要求する。同様に、前記ＡＴＭブートプロセス５２は、ノード管理サーバー５内に、端末メタシグナリング・プロセス５４を起動するとともに、ＡＴＭ交換機２のすべての入出力線に対し、前記入出力線の先に接続されるであろう端末と、前記ノード管理サーバー５内の端末メタシグナリング・プロセス５４との間にメタシグナリング・チャネル１０の設定を、前記ノード設定サーバー４に要求する。
【０１２４】
本発明に係るＡＴＭ交換システムにおいては、端末が、ブートチャネル１１またはメタシグナリング・チャネル１０等を用いて、ノード管理サーバー５等に要求を送信する場合、端末ごとに固有のチャネル番号を使用するのではなく、同一のチャネル番号（例えば、ｗｅｌｌ−ｋｎｏｗｎチャネル番号）を使用しても良い。例えば、メタシグナリング・チャネル１０を使用する場合は、ＶＰＩ／ＶＣＩ＝１を用い、ブート・チャネル１１を使用する場合は、ＶＰＩ／ＶＣＩ＝ａｌｌ １、あるいはＶＰＩ／ＶＣＩ＝（特定の値）を用いても良い。同一のチャネル番号を使用する場合、ＡＴＭ交換機の入出力線の先に接続された端末からＡＴＭ交換器に該セルが入力されたとき、どの端末から送信されたセルかを識別できるようにするために、該ＡＴＭ交換機内で該セルのＶＰＩ／ＶＣＩ値を書き替えるように、ノード管理サーバ５がノード設定サーバ４に対しＡＴＭ交換機内のルーティングタグ・テーブル等の設定を行えば、ノード管理サーバ５は、端末から該セルを受信した場合、受信したセルのＶＰＩ／ＶＣＩ値等を調べることによって、どの端末あるいはＡＴＭ交換機のどの入力線の先に接続された端末から、該セルが送信されてきたかを識別できる。
【０１２５】
端末３がコンピュータ等の端末（Ｈｏｓｔ）の場合で、前記端末の起動の際、ホストネーム、ホストＩＰアドレス、ルートファイルシステムが存在する端末名といった、ネットワーク情報を必要とする場合が存在する。本発明の一実施例においては、前記したようなコンピュータ等の端末が対象とするＡＴＭ交換機２に接続され起動する場合、以下に示す手順で、前記コンピュータ等の端末が起動に必要なネットワーク情報を手に入れることを想定している。すなわち、まず、前記コンピュータ等の端末３が、前記ブートチャネル１１を用いて、ノード管理サーバー５内に存在する端末ブートプロセス５３に、ブート用セル（例えば、ＢＯＯＴＰセル） を送信し、前記端末３の起動に必要なブートイメージの転送を要求する。端末ブートプロセス５３は、ブート用セルを受信した場合、ｃｏｎｆｉｇファイル５５を参照し、前記ブート用セルを送信した端末３に対応するブートイメージを、前記ブートチャネル１１を用いて前記端末３に転送することによって、前記コンピュータ等の端末３は、起動に必要なネットワーク情報を手に入れることができる。
【０１２６】
ＡＴＭ端末等の端末３が、ＡＴＭ交換機２に接続され起動する場合、前記端末３から、メタシグナリング・セルがメタシグナリング・チャネル１０に送信され、シグナリング・チャネルの設定と、シグナリング・セルに用いるためのＶＰＩ／ＶＣＩ値等の情報の転送とを要求する。本発明の一実施例においては、前記ＡＴＭ端末等の端末３が対象とするＡＴＭ交換機２に接続され起動する場合、以下に示す手順で、前記端末３が起動に必要なシグナリング・チャネルの設定等を要求することを想定している。すなわち、まず、前記端末３が、前記メタシグナリング・チャネル１０を用いて、ノード管理サーバー５内に存在する端末メタシグナリング・プロセス５４にメタシグナリング・セルを送信し、前記端末３の起動に必要なシグナリング・チャネルの設定を要求する。端末メタシグナリング・プロセス５４は、該メタシグナリング・セルを受信した場合、ｃｏｎｆｉｇファイル５５を参照し、前記メタシグナリング・セルを送信した端末３に対応するシグナリング・チャネルの設定等を行い、前記端末３が、前記シグナリング・チャネルを使用するためのＶＰＩ／ＶＣＩ値等の情報を、前記メタシグナリング・チャネル１０を用いて、前記端末３に転送することによって、前記端末３は、起動に必要な情報を手に入れることができる。
【０１２７】
前記した端末の起動手順において、端末３の起動に際し、ブートチャネル１１を用いて、ノード管理サーバー５内に存在する端末ブートプロセスから５３、ブート・イメージを手に入れて、メタシグナリング・チャネル１０を用いて、ノード管理サーバー５内に存在する端末メタシグナリング・プロセス５４に対し、シグナリング・チャネルの設定要求と、前記シグナリング・チャネルを使用するためのＶＰＩ／ＶＣＩ値等の情報の転送を要求してもよい。
【０１２８】
また、前記した端末の起動手順において、コンピュータ等の端末３に対し、前記端末３の起動に必要な情報の要求と転送にブートチャネル１１を用い、ＡＴＭ端末等の端末３に対し、前記端末３の起動に必要なシグナリング・チャネルの設定と前記シグナリング・チャネル等の使用情報等の転送にメタシグナリング・チャネル１０を用いているが、どちらか一方のチャネル（例えば、メタシグナリング・チャネル１０） を用いて、両方の用途に用いてもよい。本発明の一実施例においては、コンピュータ等の端末の起動とＡＴＭ端末等の起動とを明確に記述するために、２つのチャネル（ブートチャネル１１とメタシグナリング・チャネル１０） を用いた。
【０１２９】
また、図２には図示していないが、ノード管理サーバー５とノード設定サーバー４が起動した後、ネームサーバー（例えば、ＮＩＳサーバー）と呼設定サーバーが起動される。同一端末（Ｈｏｓｔ）３上に、４つのサーバー（ノード管理サーバー５、ノード設定サーバー４、ネームサーバー、呼設定サーバー） を起動する場合、例えば、ノード管理サーバー５内のｃｏｎｆｉｇファイル５５に、ネームサーバーと呼設定サーバーの起動手順を書き込んでおき、ノード管理サーバー５内のＡＴＭブートプロセスが前記ｃｏｎｆｉｇファイル５５を読み出して前記ネームサーバーと呼設定サーバーを起動することによって、前記４つのサーバーを起動することができる。また、前記４つのサーバーが同一の端末上に存在する場合、サーバー間のデータ通信はプロセス間通信等を用いて行うことができる。
【０１３０】
次に、４つのサーバー（ノード設定サーバー、ノード管理サーバー、ネームサーバー、呼設定サーバー） が同一の端末上に存在しない場合のネットワーク・サーバーの起動方法、およびサーバー間のデータ通信方法について、図３を参照しながら説明する。
【０１３１】
前記４つのサーバーが同一の端末上に存在しない場合、前記４つのサーバー間のデータ通信は、ＡＴＭ等のデータ通信手段を用いて行わなければならない。まず、ノード設定サーバー４とノード管理サーバー５との間のデータ通信路設定用の設定用チャネルとし、同様に、ノード管理サーバー５とネームサーバー（例えば、ＮＩＳサーバー６）との間のデータ通信路をＮＩＳ用チャネル（１７）と、ノード管理サーバー５と呼設定サーバー７との間のデータ通信路を呼設定用チャネル（１８）とそれぞれ定義して、前記４つのサーバーの起動方法および前記チャネルの設定方法について具体的に説明する。
【０１３２】
まず、ノード設定サーバー４とノード管理サーバー５が同一の端末上に存在しない場合の前記２つのサーバーの起動方法と、前記２つサーバー間のデータ通信路である設定用チャネルの設定方法について説明する。ノード設定サーバー４とノード管理サーバー５が同一の端末上に存在する場合は、例えば、ノード管理サーバー５の起動手順において、ノード設定サーバー４を起動することができた。しかし、前記２つのサーバーが同一の端末上に存在しない場合は、前記した方法を採用することはできず、前記２つのサーバーは、例えば、個々の端末の起動手順において起動しなければならない。従って、ノード管理サーバー５は、前記２つのサーバーの起動後、設定用チャネルを用いて、ノード設定サーバー４に、ＡＴＭ交換機２内のルーティングタグ・テーブル等の初期化と、ＡＴＭ交換機２のすべての入出力線の先に接続されるであろう端末とノード管理サーバー５内の端末ブートプロセス５３との間のブート・チャネル１１と、前記端末３とノード管理サーバー５内の端末メタシグナリング・プロセス５４との間のメタシグナリング・チャネル１０等の設定を要求することになる。また、前記設定用チャネルは、以下に示すような３通りの方法で設定することができる。すなわち、１つ目の方法は、ノード設定サーバー４の起動時に、ＡＴＭ交換機２のすべての入出力線の先に接続されるであろう端末３と、ノード設定サーバー４内の設定プロセス４１との間に、ＶＰＩ／ＶＣＩ値に特別な値を持つ設定用チャネルを設定する方法である。２つ目の方法は、ノード設定サーバー４の起動時に、ＡＴＭ交換機２の特定の入出力線の先に接続されるであろう端末と、ノード設定サーバー４内の設定プロセス４１との間に、ＶＰＩ／ＶＣＩ値に特別な値を持つ設定用チャネルを設定する方法である。３つ目の方法は、ノード設定サーバー４の起動後、前記ノード設定サーバー４に対してコマンド投入等の方法を用いて、ＡＴＭ交換機２の特定の入出力線の先に接続される端末３上のノード管理サーバー５と、前記ノード設定サーバー４内の設定プロセス４１との間に、ＶＰＩ／ＶＣＩ値に特定値を持つ設定用チャネルを設定する方法である。
【０１３３】
次に、ネームサーバー（例えば、ＮＩＳサーバー６）の起動と、ＮＩＳサーバー６とノード管理サーバー５との間のデータ通信路であるＮＩＳ用チャネル１７の設定方法について説明する。前記したように、ノード設定サーバー４とノード管理サーバー５の起動時に、ＡＴＭ交換機２のすべての入出力線の先に接続されるであろう端末と、ノード管理サーバー５内の端末ブートプロセス５３との間にブート・チャネル１１が、また、前記すべての入出力線の先に接続されるであろう端末と、ノード管理サーバー５内の端末メタシグナリング・プロセス５４との間にメタシグナリング・チャネル１０が設定される。従って、前記ＡＴＭ交換機２の入出力線の先に接続される端末は、前記ブート・チャネル１１またはメタシグナリング・チャネル１０を用いて、ノード管理サーバー５に、該端末の起動を通知することができる。同様に、前記端末上に起動されるＮＩＳサーバー６は、前記ブート・チャネル１１またはメタシグナリング・チャネル１０を用いて、ノード管理サーバー５に、該ＮＩＳサーバー６の起動を通知することができ、該ＮＩＳサーバー６の起動通知を受信したノード管理サーバー５は、前記ＮＩＳサーバー６とノード管理サーバー５との間に、ＮＩＳ用チャネル１７の設定を行う。前記ＮＩＳ用チャネル１７を用いて、ノード管理サーバー５内のＮＩＳマスター・プロセス６００と、ＮＩＳサーバー内のＮＩＳスレーブ・プロセス６０１は、サーバー間の通信（ｙｐｐｕｓｈ 、ｙｐｘｆｒ 等） と、後述するＮＩＳマップのダウンロード等を実行することができる。
【０１３４】
最後に、呼設定サーバー７の起動と、呼設定サーバー７とノード管理サーバー５との間のデータ通信路である呼設定用チャネル（１８）の設定方法について、説明する。前記したネームサーバーの起動方法とＮＩＳ用チャネル（１７）の設定方法と同様に、呼設定サーバー７が起動される端末は、前記ブート・チャネル１１またはメタシグナリング・チャネル１０を用いて、ノード管理サーバー５に、該端末の起動を通知することができる。同様に、前記端末上に起動される呼設定サーバー７は、前記ブート・チャネル１１またはメタシグナリング・チャネル１０を用いて、ノード管理サーバー５に該呼設定サーバー７の起動を通知することができ、該呼設定サーバー７の起動通知を受信したノード管理サーバー５は、前記呼設定サーバー７とノード管理サーバー５との間に呼設定用チャネル１８の設定を行う。前記呼設定用チャネル１８を用いて、ノード管理サーバー５内の管理プロセス５１および呼設定サーバー７内の呼設定プロセスは、サーバー間のデータ通信を実行することができる。
【０１３５】
１−２．端末のブートについて
いわゆる端末には、ディスクを持った端末（Ｈｏｓｔ）と、比較的小規模のディスクを持ったデータレス・クライアントと、ディスクを持たないディスクレス・クライアントが存在する。本節では、前記ディスクを持った端末（Ｈｏｓｔ）、およびＯＳ等の実行可能ファイルをディスク中に記憶しているデータレス・クライアントの起動方法について、具体的に説明する。以下、本節では、前記ディスクを持った端末端末（Ｈｏｓｔ）とデータレス・クライアントとを、特に断らない場合、単に端末と呼ぶこととする。なお、上記ディスクレス・クライアントの起動方法については、次節の（１−３） で具体的に説明する。
【０１３６】
以下、図１、図２、および図３を参照しながら、本発明の一実施例における端末の起動手順について、具体的に説明する。
【０１３７】
まず、本発明においては、（１−１ 節で説明したように）ノード設定サーバー４とノード管理サーバー５の起動時に、ＡＴＭ交換機２のすべての入出力線の先に接続されるであろう端末と、ノード管理サーバー５内の端末ブートプロセス５３との間にブート・チャネル１１が、また、前記すべての入出力線の先に接続されるであろう端末と、ノード管理サーバー５内の端末メタシグナリング・プロセス５４との間にメタシグナリング・チャネル１０が設定される。前記ノード設定サーバー４とノード管理サーバー５の起動後、前記ＡＴＭ交換機２の入出力線の先に接続された端末が起動する場合、前記端末は、前記ブート・チャネル１０またはメタシグナリング・チャネル１１を用いて、該端末の起動をノード管理サーバー５に通知することができる。
【０１３８】
対象とするＡＴＭ交換機２の入出力線の先に接続される端末が、コンピュータ等の端末の場合、該端末の起動をノード管理サーバー５に通知するためと、該端末の起動に必要なネットワーク情報（例えば、ホストネームといった情報） 等を、前記ノード管理サーバー５から得るために、該端末は、前記ブート・チャネル１１を用いて、前記ノード管理サーバー５とデータ通信を実行する。すなわち、端末は、起動時、前記端末の起動を通知するために、ブート用セル（例えば、ＢＯＯＴＰ セル、ＲＡＲＰセル等） をブートチャネル１１を用いてノード管理サーバー５に送信し、前記ノード管理サーバー５は、前記ブート用セルを受信することによって、前記端末の起動を認識することができる。また、前記端末は、必要に応じて前記端末の起動に必要な情報の要求を前記ブート用セルに書き込んでおき、前記ブート用セルをブートチャネル１１を用いてノード管理サーバー５に送信し、前記ノード管理サーバー５は、前記ブート用セルを受信し、前記ブート用セルに書かれた要求に従って、前記端末３の起動に必要な情報を前記ブート・チャネル１１を用いて前記端末に送信することによって、前記端末３は起動に必要な情報を得ることができる。
【０１３９】
また、前記端末３は、起動時または起動後、必要に応じて、前記端末３上に起動するＮＩＳクライアント・プロセス６１と、ＮＩＳサーバーとの間のデータ通信路であるインフォメーション・チャネル１２の設定要求を、前記ブート・チャネル１１を用いて、ノード管理サーバー５に送信することとする。すなわち、コンピュータ等の端末の場合で、該端末上に、ＮＩＳクライアント・プロセス６１が起動され、前記ＮＩＳクライアント・プロセス６１が、該端末以外の端末に起動しているＮＩＳサーバーに帰属（ｂｉｎｄ）する場合、前記ＮＩＳクライアント６１は、サブネット内に存在するＮＩＳサーバーを何らかの方法で検索し、前記検索したＮＩＳサーバーとの間にポイント・ツー・ポイントのデータ通信路を構築する必要がある。本発明においては、前記した場合、前記端末の起動時または起動後、まず、前記ＮＩＳクライアント・プロセス６１が、ブート・チャネル１１を用いて、ノード管理サーバー５に、サブネット内のＮＩＳサーバーの検索要求と、前記検索したＮＩＳサーバーと前記端末３との間のデータ通信路であるインフォメーション・チャネル１２の設定要求とを送信する。ノード管理サーバー５は、前記ＮＩＳサーバーの検索要求と、前記ＮＩＳサーバーとの間のデータ通信路の設定要求を受信した場合、前記ノード管理サーバー５が、サブネット内の端末の構成についての管理情報である管理ファイル５６を参照し、ＮＩＳサーバー・プロセスが起動している、比較的負荷の小さい適切な端末を検索する。次に、前記ノード管理サーバー５は、前記検索したＮＩＳサーバー・プロセスが起動している端末と、前記端末３との間のデータ通信路であるインフォメーション・チャネル１２を設定し、前記端末３が前記インフォメーション・チャネル１２を使用するためのＶＰＩ／ＶＣＩ値等の情報を、前記ノード管理サーバー５は、前記端末３に対し、前記ブート・チャネル１１を用いて送信する。以上説明したような手順を採用することによって、前記端末３上のＮＩＳクライアント６１は、前記インフォメーション・チャネル１２を用いることによって、帰属（ｂｉｎｄ）先のＮＩＳサーバーに対して、必要なネットワーク情報の検索要求を送信したり、前記ＮＩＳサーバーから、必要なネットワーク情報を受信したりすることができる。
【０１４０】
また、ＮＩＳクライアント６１は、帰属（ｂｉｎｄ）先のＮＩＳサーバーに対しネットワーク情報の送信を要求し、前記ＮＩＳサーバーから前記要求したネットワーク情報が送信されてくるのを待つが、前記ＮＩＳサーバーから前記ネットワーク情報の受信に時間がかかる場合、前記ＮＩＳクライアント６１は、帰属（ｂｉｎｄ）先のＮＩＳサーバーの変更をノード管理サーバー５に要求する。すなわち、ＮＩＳクライアント６１は、前記インフォメーション・チャネル１２を用いて、帰属（ｂｉｎｄ）先のＮＩＳサーバーに対し必要とするネットワーク情報の送信を要求する。前記ＮＩＳクライアント６１は、前記ＮＩＳサーバーから、前記インフォメーション・チャネル１２を経由して、要求したネットワーク情報の受信を待つが、前記ネットワーク情報の受信がタイムアウトした場合、前記ＮＩＳクライアント６１は、前記ブート・チャネル１１を用いて、ノード管理サーバー５に、帰属（ｂｉｎｄ）先のＮＩＳサーバーの変更を要求する。帰属（ｂｉｎｄ）先のＮＩＳサーバーの変更要求を受信したノード管理サーバー５は、サブネット内の端末の構成についての管理情報である管理ファイル５６を参照し、ＮＩＳサーバー・プロセスが起動している比較的負荷の小さい適切な端末を検索する。次に、前記ノード管理サーバー５は、前記検索したＮＩＳサーバー・プロセスが起動している端末と、前記端末３との間にインフォメーション・チャネルを再設定し、前記端末３が前記インフォメーション・チャネルを使用するためのＶＰＩ／ＶＣＩ値等の情報を、ブート・チャネル１１を用いて前記端末に送信することによって、ＮＩＳクライアント６１は帰属（ｂｉｎｄ）先のＮＩＳサーバーを変更することができる。
【０１４１】
また、対象とするＡＴＭ交換機２の入出力線の先に接続される端末が、ＡＴＭ等の端末の場合、該端末３の起動をノード管理サーバー５に通知するためと、該端末が呼設定を行うのに必要なシグナリング・チャネル１３の設定と、前記シグナリング・チャネル１３を使用するのに必要なＶＰＩ／ＶＣＩ値等の情報を、前記ノード管理サーバー５から得るために、該端末３は、前記メタシグナリング・チャネル１０を用いて前記ノード管理サーバー５とデータ通信を行う。すなわち、端末３は、起動時、前記端末３の起動を通知するために、メタシグナリング・セルを、メタシグナリング・チャネル１０を用いてノード管理サーバー５に送信し、前記ノード管理サーバー５は、前記メタシグナリング・セルを受信することによって、前記端末３の起動を認識することができる。また、前記ノード管理サーバー５は、前記メタシグナリング・セルを受信した場合、前記端末３に対して、前記端末３と呼設定サーバー７との間のシグナリング・チャネル１３を設定するとともに、前記端末３が、前記シグナリング・チャネル１３を使用するのに必要なＶＰＩ／ＶＣＩ値等の情報を、前記メタシグナリング・チャネル１０を用いて前記端末３に送信することによって、前記端末３は、呼設定を行うのに必要な、シグナリング・チャネル１３を使用するためのＶＰＩ／ＶＣＩ値等の情報を得ることができる。
【０１４２】
以上説明したように、本発明においては、コンピュータ等の端末の場合、端末の起動の通知と、端末の起動に必要な情報の送信を、ブート・チャネル１１を用いて実行し、ＡＴＭ端末等の場合、前記端末が呼設定を行うのに必要なシグナリング・チャネル１３の設定と、前記端末が、前記シグナリング・チャネル１３を使用するために必要なＶＰＩ／ＶＣＩ値等の情報の送信を、メタシグナリング・チャネル１０を用いて実行することとしている。コンピュータ等のＡＴＭ端末の場合、前記したブート・チャネル１１とメタシグナリング・チャネル１０の２つのチャネルを用いて、前記端末の起動処理を実行してもよい。すなわち、コンピュータ等のＡＴＭ端末の場合、ノード管理サーバー５に対し、端末の起動通知と、端末の起動に必要な情報の受信を、ブート・チャネル１１を用いて行い、シグナリング・チャネル１３の設定要求と、端末が前記シグナリング・チャネル１３を使用するためのＶＰＩ／ＶＣＩ値等の情報の受信を、メタシグナリング・チャネル１０を用いて行ってもよい。
【０１４３】
次に、ノード管理サーバー５が、ブート・チャネル１１を経由して、端末３から転送されたブート用セル（ＢＯＯＴＰ セル、ＲＡＲＰセル等） を受信した場合、あるいはメタシグナリング・チャネル１０を経由して、端末３から転送されたメタシグナリング・セルを受信した場合のノード管理サーバー５の動作について、具体的に説明する。
【０１４４】
ノード管理サーバー５が、メタシグナリング・セル（またはブート用セル）を受信した場合、前記ノード管理サーバー５は、まず、ｃｏｎｆｉｇファイル５５を参照し、ｃｏｎｆｉｇファイル５５に書かれた内容に従って、端末の立ち上げシーケンスを実行する。ｃｏｎｆｉｇファイル５５のうち、メタシグナリング・セル（またはブート用セル）が転送されてきた交換機の入力ポート、またはメタシグナリング・セル（またはブート用セル）に記述されたキーワードに従って、必要な部分が選択され、前記選択した情報に従って、端末３の立ち上げシーケンスが実行される。電話等の端末や、コンピュータ等の端末で、新たにコネクションを設定する必要のある端末の場合、前記ｃｏｎｆｉｇファイル５５には、端末３から呼設定サーバー７までのシグナリング・チャネル１３等の設定手順が記述されている。また、コンピュータ等の端末の場合、前記ｃｏｎｆｉｇファイル５５には必要に応じて、端末からＮＩＳサーバー６までの、または、ブロードキャスト・チャネル等の設定手順が記述されていてもよい。また、サブネットワーク内に、複数の呼設定サーバーが存在する場合、ノード管理サーバー５は、管理ファイル５６を参照し、比較的負荷の小さい呼設定サーバーに、前記端末３の呼設定処理をするように、前記端末３と前記呼設定サーバーとの間に、シグナリング・チャネル１３を設定してもよい。
【０１４５】
次に、前記ノード管理サーバー５は、ｃｏｎｆｉｇファイル５５に書かれた内容に従ってＡＴＭ交換システム内のコネクションを設定する。具体的には、ｃｏｎｆｉｇファイル５５に書かれている内容に従って、ＡＴＭ交換システム内にコネクションを設定するために、ノード管理サーバー５は、対応するノード設定サーバー４に対し、ハードウェアの設定を要求する。前記ノード管理サーバー５と前記ノード設定サーバー４が同一の端末上に起動されている場合は、前記ノード管理サーバー５から前記ノード設定サーバー４への設定要求は、プロセス間通信によって転送される。一方、前記ノード管理サーバー５と前記ノード設定サーバー４が、同一の端末上に起動されていない場合は、前記ノード管理サーバー５から前記ノード設定サーバー４への設定要求は、図３で示したような設定用チャネルを用いて転送される。
【０１４６】
ノード設定サーバー４は、前記設定要求を受信した場合、ルーティングタグ・テーブル２４等のハードウェアを直接書き込むことによって、前記コネクション設定要求に対して、スイッチ等のルーティング・テーブルを設定する。また、前記ノード設定サーバー４は、ルーティングタグ・テーブル２４等のハードウェア情報を、ｂａｃｋｕｐファイル４２にバックアップしていてもよい。前記ノード設定サーバー４が、ｂａｃｋｕｐファイル４２を作成する場合、前記ノード設定サーバー４は、ハードウェアに正常に書き込みが終了した場合、前記ｂａｃｋｕｐファイル４２の更新を行う。前記ｂａｃｋｕｐファイル４２は、ＡＴＭ交換システムに、電源の瞬断等の事故が発生し、ハードウェア・テーブル等の内容が破壊された場合に、ノード設定サーバー４がハードウェア・テーブル等の内容を、効果的に復旧する場合に用いられる。また、ノード設定サーバー４は、受信した設定要求を、ｂａｃｋｕｐファイル４２にロギングしてもよい。ＡＴＭ交換システムに不具合が発生した場合、前記ロギング・ファイルを参照することによって、効果的にその不具合を取り除くことができる。
【０１４７】
ノード設定サーバー４が、受信した設定要求に対し、正常に設定が終了した場合、ノード管理サーバー５は、該ノード管理サーバー５が管理する管理ファイル５６を更新する。次に、ノード管理サーバー５は、前記管理ファイル５６の内容を基にサブネットワークに対するＮＩＳマップを再構成する。本発明においては、ノード管理サーバー５は、サブネットワークに対するＮＩＳマスター・サーバー６００としても機能することを想定しているが、前記構成を想定した場合、ノード管理サーバー５が、該サーバーが管理するＮＩＳマップ（ＮＩＳマスター・マップ）を再構成した場合、該ノード管理サーバー５が前記ＮＩＳマップをＮＩＳスレーブ・サーバー６０１にダウン・ロードする。すなわち、前記ノード管理サーバー５は、ＮＩＳスレーブ・サーバー６０１に対し、ＮＩＳマスター・マップの更新を通知する（ｙｐｐｕｓｈユーティリティによって実行される）。ＮＩＳマスター・マップの更新の通知を受けたＮＩＳスレーブ・サーバー６０１は、ＮＩＳマスター・サーバー６００（ノード管理サーバー５）に対し、ＮＩＳマップの転送を要求する（ｙｐｘｆｒ ユーティリティによって実行される） 。ＮＩＳマップの転送を受信したＮＩＳスレーブ・サーバー６０１は、該ＮＩＳスレーブ・サーバー６０１が管理するＮＩＳマップを更新する。
【０１４８】
ここで、前記ＮＩＳマスター・サーバー６００（ノード管理サーバー５）の、ＮＩＳスレーブ・サーバー６０１へのＮＩＳマップの転送においては、端末３が起動する度に、または呼設定サーバーがコネクションを設定する度に、ＮＩＳマップを転送する方法を採用した場合、ＮＩＳマップが頻繁に転送される可能性がある。これに対しては、ＮＩＳマップが更新される度に、ＮＩＳマップをＮＩＳマスター・サーバー６００からＮＩＳスレーブ・サーバー６０１へ転送するのではなくて、定期的にまたは更新量がスレショルドを越えた場合に転送するといった方法を用いることによって、上記動作を改善し、性能を向上させることができる。
【０１４９】
最後に、ノード管理サーバー５は、前記端末３に対し設定完了を通知する。すなわち、ノード管理サーバー５は、メタシグナリング・セルを送信した端末に対しては、シグナリング・チャネル１３の設定完了と、シグナリング・セルのＶＰＩ／ＶＣＩ値等を通知し、ブート用セルを送信した端末に対しては、ブート・イメージ等を通知する。
【０１５０】
ここで、前記したノード管理サーバー５の、端末の起動手順において、該ノード管理サーバー５は、端末からの要求に従ってｃｏｎｆｉｇファイル５５を参照し、ノード設定サーバー４に対し設定要求を送信するとしていた。前記方法を採用した場合、端末が起動要求を送信する度に、ノード管理サーバー５は設定要求をノード設定サーバー４に送信するが、前記端末が前記起動要求のタイムオーバー等の原因によって起動要求を再送した場合、該ノード管理サーバー５は、ノード設定サーバー４に対して設定要求を再送してしまう可能性がある。この点は、以下の手順を採用することにより改善される。すなわち、ノード管理サーバー５が、端末から起動要求を受信した場合、ｃｏｎｆｉｇファイル５５と管理ファイル５６を参照し、前記起動要求に対し設定するコネクションがすでに前記管理ファイル５６に登録されていた場合、ノード設定サーバー４に対しては設定要求を出さずに、端末に対して設定完了通知を出すようにすれば良い。
【０１５１】
また、管理ファイル５６に登録されている情報と実際にハードウェアに設定されている設定データとが異なる場合、前記改善方法を採用したとき端末からのコネクション設定要求が無視される可能性がある。この点は、管理ファイル５６に登録されているコネクションに対し、１回目の設定要求に対しては、前記した通り何のアクションも起こさないが、２回目以降の設定要求に対してアクションを起こすことによって改善される。
【０１５２】
同様に、ノード設定サーバー４は、ノード管理サーバー５から、ハードウェア・テーブルの設定要求を受信した場合、ｂａｃｋｕｐファイル４２を参照し、前記ハードウェアの設定がすでに実行されている場合、前記設定要求に対しては、ハードウェアの設定を行わずに、ノード管理サーバー５に対して設定完了を通知することによって、性能が改善される。さらに、ノード設定サーバー４は、ｂａｃｋｕｐファイル４２にすでに実行されたアクションに対して、１回目のアクション要求に対してはアクションを起こさず、２回目以降のアクション要求に対してアクションを起こすことによって、ｂａｃｋｕｐファイル４２と実際のハードウェアの不一致による不具合を改善することができる。
【０１５３】
また、本発明の一実施例においては、後述するように、頻繁にデータ通信が行われそうな端末間に予めコネクションを設定しておき、前記端末間のデータ通信を行う場合、前記予め設定されたコネクションを用いることによって、呼設定を行わずにデータ転送を開始することのできる効果的なデータ通信方法を想定している。前記した予め設定されたコネクションを、いつ、どのように設定するかについて、以下に示すような、３通りの方法が存在する。
【０１５４】
１つ目の方法は、前記コネクションを、ハードウェアで予め作り込んでおくという方法である。すなわち、ＡＴＭ交換機２内の前処理部のルーティングタグ・テーブルを、ＲＯＭ等の不揮発メモリで作成し、ＡＴＭ交換機２を製造する際、所望のデータを前記ＲＯＭに書き込んでおくことによって、前記コネクションの設定を行おうとする方法である。ただし、他の２方法に比較して、この方法を採用した場合、製造後、ＲＯＭを書き換えることはできないので、ルーティング・タグ・テーブルを変更することはできない。
【０１５５】
２つ目の方法は、前記コネクションを、ネットワークの立ち上げ時に設定する方法である。すなわち、本発明の一実施例においては、ＡＴＭネットワークは、前記した４つのサーバーで管理することを想定しているが、前記したｃｏｎｆｉｇファイル５５に、予め前記コネクションの設定を記述しておくことによって、ＡＴＭネットワークの立ち上げ時、ノード管理サーバー５が、前記ｃｏｎｆｉｇファイル５５に書かれた内容に従ってコネクションを設定することによって、前記コネクションの設定を行おうとする方法である。ただし、他の２方法に比較して、この方法を採用した場合、前記ノード管理サーバー５が、前記ｃｏｎｆｉｇファイル５５に書かれたすべてのコネクションを設定し終わるまで、ＡＴＭネットワークの立ち上げが終了しないので、ネットワークの立ち上げに時間がかかる。
【０１５６】
３つ目の方法は、前記コネクションを、端末の立ち上げ時に設定する方法である。すなわち、ネットワークの起動後（ノード管理サーバー５の起動後） 、ネットワークに接続される端末の起動を、ノード管理サーバー５が認識した場合、前記端末に対して、該ノード管理サーバー５が、ｃｏｎｆｉｇファイル５５に記述された内容に従って、コネクションの設定を行おうという方法である。上記２つ目の方法は、ネットワークの立ち上げ時にノード管理サーバー５がｃｏｎｆｉｇファイル５５を参照してコネクションを設定しようという方法であったが、この３つ目の方法では、ネットワークの立ち上げの時点ではなく、ネットワークに接続される端末の起動をノード管理サーバー５が認識した時点で、前記端末に対してｃｏｎｆｉｇファイル５５を参照してコネクションを設定しようという方法である。具体的には、（１−１） 節で説明したように、ネットワークの立ち上げ時に、ノード管理サーバー５は、対象とするＡＴＭ交換機２のすべての入出力線に対し、前記入出力線の先に接続されるであろう端末と、ノード管理サーバー５との間に、ブート・チャネル１１とメタシグナリング・チャネル１０とを設定する。ＡＴＭ交換機２の入出力線の先に接続された端末は、起動時に、前記ブート・チャネル１１またはメタシグナリング・チャネル１０を用いて、ノード管理サーバー５に、ブート用セル（またはメタシグナリング・セル） を送信する。ノード管理サーバー５は、ブート用セル（または、メタシグナリング・セル） を受信した場合、前記ノード管理サーバー５は、該端末の起動を認識し、ｃｏｎｆｉｇファイル５５に書かれた内容に従って、該端末に対して予め設定するコネクション等の設定を実行する。ただし、他の２方法に比較して、この方法を採用した場合、端末の立ち上げに時間がかかる。
【０１５７】
前記した３つの方法には、それぞれ長所・短所が存在するので、状況に応じて３つの方法のうちから長所を生かすように１つの方法を選択することが効果的である。
【０１５８】
１−３．ディスクレス・クライアントのブートについて
一般に、ディスクレス・クライアントは、起動時、ルート・ファイルシステム（／） 、作業領域（スワップエリア：／ｔｍｐ） 、ＯＳ等の実行可能ファイル（／ｕｓｒ）、端末名（ホスト名） 等の情報を持っていないので、起動時、ディスクレス・クライアントは、前記した情報を獲得しなければならない。従来のディスクレス・クライアントは、前記情報を獲得するために、起動時、ブート用パケット（ＲＡＲＰパケットまたはＢＯＯＴＰ パケット） をサブネットワーク内にブロードキャストし、サブネットワーク内に存在するブートサーバーが前記パケットに応答することによって、前記ディスクレス・クライアントは前記情報を獲得することができる。
【０１５９】
本発明においては、（１−１） 節で説明したように、ＡＴＭ交換機２（ネットワーク） の立ち上げ時に、ノード管理サーバー５が、ＡＴＭ交換機２のすべての入出力線に対し、前記入出力線の先に接続されるであろう端末とノード管理サーバー５との間に、ブート・チャネル１１を設定しておく。ＡＴＭ交換機２（ネットワーク） の起動後、前記ＡＴＭ交換機２の入出力線の先に接続されたディスクレス・クライアントが起動する場合、前記ディスクレス・クライアントは、ブート・チャネル１１を用いて、ブート用セル（ＲＡＲＰセルまたはＢＯＯＴＰ セル） をノード管理サーバー５に送信する。ノード管理サーバー５は、ブート・チャネル１１を経由して転送されたブート用セルを受信した場合、ｃｏｎｆｉｇファイル５５を参照し、前記ｃｏｎｆｉｇファイル５５のブート用セルを送信したディスクレス・クライアントに対応する記述に従って、前記ディスクレス・クライアントを起動するのに必要なブートイメージ（ルート・ファイルシステム、スワップエリア、実行可能ファイル、ホスト名等） を、前記ディスクレス・クライアントに、前記ブート・チャネル１１を用いて送信する。前記ノード管理サーバー５の、ｃｏｎｆｉｇファイル５５を参照する手順において、本発明の一実施例においては、ブート用セルがＡＴＭ交換機２に入力された入力チャネル番号をキーとして、ｃｏｎｆｉｇファイル５５を参照し、ｃｏｎｆｉｇファイル５５に書かれたブートイメージを、ノード管理サーバー５が前記ブート用セルを送信したディスクレス・クライアントに転送することを想定している。
【０１６０】
ディスクレス・クライアントを、提案するＡＴＭ交換機に接続する場合について、以下、具体的に説明する。
【０１６１】
まず、従来のディスクレス・クライアントは、起動時、ブート用パケット（ＡＲＰ パケットまたはＢＯＯＴＰ パケット） をサブネットワーク内の端末にブロードキャストし、サブネットワーク内に存在するブートサーバー等が前記パケットに対し応答することによって、前記ディスクレス・クライアントはブートイメージを得ることを想定している。従来のネットワークにおいては、サブネットワーク内に存在する端末に対して予めブロードキャスト・チャネルが設定されていて、前記ディスクレス・クライアントは、前記ブロードキャスト・チャネルを使用することによって、サブネットワーク内に存在するブート・サーバーにブート用セルを転送することができた。
【０１６２】
本発明の一実施例においては、ディスクレス・クライアントが、ブート用セルを送信するために使用するチャネル（すなわちブート・チャネル１１） を予め設定しておき、特定のＶＰＩ／ＶＣＩ値（例えば、ＶＰＩ＝ａｌｌ １ 、または、ＶＰＩ／ＶＣＩ＝ ａｌｌ １） を、予め割り当てておく。また、前記チャネルは、ＡＴＭ交換機２（ネットワーク） の立ち上げ時に、ＡＴＭ交換機２のすべての入出力線の先に接続されるであろう端末とノード管理サーバー５との間に、ノード管理サーバー５によって設定されるものとする。従来のネットワークにおいては、ディスクレス・クライアントの起動時に使用されるブート時に使用されるチャネルとして、サブネットワーク内に存在するすべての端末へのブロードキャスト・チャネルが用いられていたが、本発明においては、ブロードキャスト・チャネルを使用するのではなく、端末からサブネットワーク内に存在するノード管理サーバー５までのユニキャスト・チャネル（シングルキャスト・チャネル） であるブート・チャネルを用いることを想定している。
【０１６３】
１−５．ＡＲＰ、ＮＩＳについて
以下、本発明に係るＡＴＭ交換システムにおける、ＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ） について説明する。
【０１６４】
本発明のＡＴＭ交換システムにおいては、頻繁にデータ通信が行われそうな端末間に予めコネクションを設定しておき、前記端末間のデータ通信を行う場合、前記予め設定されたコネクションを用いることによって、呼設定を行わずにデータ転送を開始することのできる効果的なデータ通信方法を想定している。また、本発明においては、前記データ通信を行う際、宛先のデータ受信端末の端末名等をキーとして、前記予め設定されたコネクションのコネクション識別子（ＶＰＩ／ＶＣＩ等） を検索し、前記検索して得られたコネクション識別子を用いて、前記コネクションを使用することを想定している。ここに、以下の説明で、ＡＲＰとは、宛先のデータ受信端末の端末名等から、既に設定されたコネクションのうち該当するコネクションのコネクション識別子（ＶＰＩ／ＶＣＩ等） を獲得する方法のことを言うものとする。
【０１６５】
従来のコンピュータ間のデータ通信方法（ＴＣＰ／ＩＰ）におけるＡＲＰとは、宛先のデータ受信端末のＩＰアドレス（端末名に対応する）からＭＡＣアドレス（コネクション識別子に対応する） を獲得する方法であった。また、従来のコンピュータ間のデータ通信方法においては、サブネットワークに属する各々のデータ送信端末は、同一の宛先にデータ通信を行う場合、同一のＭＡＣアドレス（コネクション識別子に対応）を用いてデータ転送を行うことができた。
【０１６６】
ここで、前述した従来のコンピュータ間のデータ通信方法を、そのまま従来のＡＴＭ交換システムに適用した場合の問題点について説明する。
【０１６７】
前述したように、従来のコンピュータ間のデータ通信で行われた方法を、従来のＡＴＭ交換システムにそのまま適用しようとすると、サブネットワークに属するすべての端末間にメッシュ状にコネクションを設定し、前記各々のデータ送信端末が同一の宛先にデータ転送を行う場合、同一のコネクション識別子（ＶＰＩ／ＶＣＩ）を用いてデータ転送ができるように、コネクションの設定を行わなければならない。しかし、前記サブネットワークに属する端末間にメッシュ状に張られたコネクションは、常時、すべてのコネクションが使用されるわけではないので、前記方法を採用した場合、ＶＰＩ／ＶＣＩテーブル（宛先の端末名から、コネクション識別子を検索する時に使用するテーブル） の大きさが、不必要に大きくなってしまうといった問題点があった。また、ネットワーク・サイドにとっても、端末が、呼設定を行わずにデータ転送を行うことを保証するためには、前記予め設定されたコネクションが正常かどうか、常時、チェックを行わなければならず、前記コネクションの数が不必要に多い場合、ネットワーク・サイドが効率よく前記コネクションをチェックすることができないといった問題点があった。
【０１６８】
本発明の一実施例は、前記問題点を改善するために、サブネットワーク内のすべての端末間にメッシュ状にコネクションを設定するのではなく、頻繁にデータ通信が行われそうな端末間にのみコネクションを設定することによって、予め設定しなければならないコネクションの数を削減するようにしたものである。また、本発明の一実施例においては、前記予め設定を行うコネクションのうち、サブネットワークに属するすべての端末に共通するコネクションと端末に固有なコネクションとに分類し、前記サブネットワークに属するすべての端末に共通するコネクションについて、コネクション識別子（ＶＰＩ／ＶＣＩ）を端末間で共通にすることによって、サブネットワーク内に存在するＶＰＩ／ＶＣＩテーブルの管理を効率よく行うようにしたものである。
【０１６９】
また、予めコネクションを設定することによって、呼設定を行わずにデータ転送を開始する方法を採用しても、端末が前記コネクションを使用する場合に、前記コネクションを使用するためのＶＰＩ／ＶＣＩ値等を、他の端末に問い合わせなければならない方法を採用した場合、他の端末に問い合わせるのに時間がかかるので、予めコネクションを設定することによる利点が小さくなるといった問題点があった。
【０１７０】
本発明の一実施例は、端末が、予め設定されたコネクションを使用するためのＶＰＩ／ＶＣＩ値等を記憶することのできる場合、端末側で前記ＶＰＩ／ＶＣＩ値等を記憶し、端末がデータ通信を行う場合、前記端末側で記憶されているＶＰＩ／ＶＣＩ値等を用いることによって、効率よくデータ転送を開始するようにしたものである。
【０１７１】
以下、本発明の一実施例においては、ＶＰＩ／ＶＣＩテーブルを効率よく管理等を行うために、ＮＩＳ（Ｎｅｔｗｏｒｋ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍ）を用いて管理する方法について説明する。本発明を、ＮＩＳを用いずに実現することも可能であるが、以下、本発明の一実施例を具体的に説明するためにＮＩＳの使用を想定する。以下、ＶＰＩ／ＶＣＩテーブルをＮＩＳを用いて管理する方法と、本発明におけるＮＩＳの実現方法について、具体的に説明する。
【０１７２】
図４は、本発明の一実施例における、ＶＰＩ／ＶＣＩテーブルの構成を示したものである。本発明においては、端末がＶＰＩ／ＶＣＩテーブルを持つことによって、データ通信を行う必要の生じた端末は、宛先のデータ受信端末の端末名等をキーとして、前記ＶＰＩ／ＶＣＩテーブルを検索することによって、効率よくＶＰＩ／ＶＣＩを獲得する方法を想定している。具体的には、データ送信端末は、宛先のデータ受信端末までのコネクションが設定されたデータ転送路に対して、宛先の端末（Ｈｏｓｔ）名等と前記コネクションを使用するためのＶＰＩ／ＶＣＩ値等とを一組としたＶＰＩ／ＶＣＩテーブルを管理し、データ転送を行う必要の生じたデータ送信端末は、宛先の端末名をキーとして前記ＶＰＩ／ＶＣＩテーブルを検索することによって、宛先のデータ受信端末までセルを転送するためのコネクションを使用するのに必要なＶＰＩ／ＶＣＩ値等を獲得する（ハッシュ関数を用いて検索しても良い）。
【０１７３】
また、本発明の一実施例において、ＶＰＩ／ＶＣＩテーブルは、図４に示すように、サブネットワークに属する端末に共通なＶＰＩ／ＶＣＩテーブルであるＮＩＳマップ６２と、端末に固有なＶＰＩ／ＶＣＩテーブルであるＮＩＳファイル６３の２種類のＶＰＩ／ＶＣＩテーブルから構成されているとする。ここで、通常、ＮＩＳにおいては、ＮＩＳファイルという用語は存在せず、ローカル・ファイルと呼ばれているが、本発明の一実施例においては、ローカル・ファイルという代わりにＮＩＳファイルと呼ぶこととする。また、本発明のＡＴＭ交換システムにおいては、サブネットワークに属しているすべての端末と、予め指定されたサーバー等の機能を持つ複数の端末との間のコネクションは設定されているものとし、サブネットワークに属する任意の端末が前記コネクションを使用する場合、宛先の端末名に対して同一のＶＰＩ／ＶＣＩ値等が割り当てられているものとする。前記したサブネットワークに属するすべての端末に対して、共通の宛先とＶＰＩ／ＶＣＩ値等はＮＩＳマップ６２に登録されているものとする。また、個々の端末に固有に設定されたコネクションに対しては、宛先の端末名と、前記コネクションを使用するためのＶＰＩ／ＶＣＩ値等は、ＮＩＳファイル６３に登録されているものとする。
【０１７４】
本発明の一実施例においては、ＶＰＩ／ＶＣＩテーブルの管理に、まず、ＮＩＳファイル６３を参照し、次に、ＮＩＳマップ６２を参照することによって、宛先の端末名から前記端末にセルを送信するために必要なＶＰＩ／ＶＣＩ値等を検索することを想定している。ただし、本発明においては、まず初めに、ＮＩＳマップ６２を参照し、次に、ＮＩＳファイル６３を参照しても構わない。
【０１７５】
図５は、前記したサブネットワークに共通なコネクションと、個々の端末に固有なコネクションの関係を示した本発明の具体例である。
【０１７６】
コンピュータ・ネットワークに属する端末には、一般に、サーバーとクライアントの２種類の端末が存在する。一般的に、クライアントからサーバー、サーバーからクライアント、およびサーバーからサーバーへのデータ転送は行われるが、クライアントからクライアントへのデータ転送はあまり行われないといった特徴が存在する。従って、本発明において、サブネットワークに属する端末に対して、端末の起動時（またはネットワークの起動時） 等に対応する、サーバーとサーバー間、あるいはサーバーとクライアント間のコネクションを予め設定することによって、前記端末が、予めコネクションが設定された端末に対して実際にデータ通信を行う際に、呼設定を行わずにデータ通信を開始することができる。本発明の一実施例においては、ノード管理サーバー５が、以下に示すような手順を実行することによって、前記した予め設定するコネクションを、効率よく設定することができる。すなわち、ノード管理サーバー５が、ブート用セル（ＲＡＲＰ セルまたはＢＯＯＴＰ セル） 、またはメタシグナリング・セルを受信した場合、前記セルが転送されてきたブート・チャネル１１またはメタシグナリング・チャネル１０の先に接続された端末が起動されたと認識する。次に、前記ノード管理サーバー５は、ｃｏｎｆｉｇファイル５５を参照し、前記端末に対してｃｏｎｆｉｇファイル５５中に記述されたサーバー等の間のコネクションを設定することによって、前記予め設定するコネクションを効率よく設定することができる。
【０１７７】
また、予めコネクションを設定する際に、宛先がサーバーとなるコネクションを設定する場合、サブネットワークに属するすべての端末に対して、同一の宛先に対して同一のＶＰＩ／ＶＣＩ値等となるようにコネクションの設定を行うこととする。前記したようなＶＰＩ／ＶＣＩ値の設定を行うことで、サブネットワークに属するすべての端末において、同一の情報が書かれたＮＩＳマップ６２を使用することができるので、サブネットワークにおけるＮＩＳマップ６２の管理を効率よく行うことができる。
【０１７８】
図５において、宛先がサーバーの場合のＶＰＩ／ＶＣＩテーブルは、ＮＩＳマップ６２で管理することができるが、宛先がクライアントの場合のＶＰＩ／ＶＣＩテーブルは、ＮＩＳマップ６２で管理することはできず、前記テーブルはＮＩＳファイル６３で管理することになる。従って、クライアントからサーバーへのコネクションは、ＮＩＳマップ６２で管理されることになるが、前記コネクションに対する逆向きのコネクション（サーバーからクライアントへのコネクション） は、ＮＩＳファイル６３で管理されることになる。従って、本発明の一実施例においては、ＮＩＳファイル６３には、前記したサーバーからクライアントへの予め設定するコネクション、および呼設定要求の結果、端末固有に設定されるコネクションの２通りのコネクションが登録されることになる。
【０１７９】
なお、クライアントからクライアントへデータ転送を行う場合は、該当する端末が網に対して呼設定要求を行うことによって、網が前記コネクションを設定し、前記コネクションに対するＶＰＩ／ＶＣＩ値等をＮＩＳファイル６３に登録することによって、前記コネクションに対して本発明におけるＶＰＩ／ＶＣＩテーブル管理方法で対応することができる。
【０１８０】
図６は、本発明の一実施例におけるサブネットワーク内の、ＮＩＳマップの配送方法を示した模式図である。
【０１８１】
一般的に、コンピュータ・ネットワークにおいては、ハードディスクを持ったホスト３１と、小規模のハードディスクを持ったデータレス・クライアント３２と、ディスクを持たないディスクレス・クライアント３３の３種類の端末が存在する。現在のＮＩＳの実装方法においては、ユーザのＮＩＳの使用効率を高めるために、なるべくＮＩＳスレーブ・マップはユーザ側のハードディスク上に、ＮＩＳスレーブサーバー・プロセスは、ユーザ端末上に起動しようとしている。従って、図６に示すように、前記ホスト３１においては、ＮＩＳスレーブ・マップ６２１が構築され、ＮＩＳスレーブサーバー・プロセス６０１とＮＩＳクライアント・プロセス６１が起動されているものとする。また、前記データレス・クライアント３２においては、実装されているハードディスクの規模に応じて、ＮＩＳスレーブ・マップ６２１、ＮＩＳスレーブサーバー・プロセス６０１、およびＮＩＳクライアント・プロセス６１で構成されている場合と、ＮＩＳクライアント・プロセス６１のみで構成されている場合の、２通りの場合が存在するものとする。同様に、前記ディスクレス・クライアント３３の場合、端末上に、ＮＩＳクライアント・プロセス６１のみ起動されているものとする。
【０１８２】
本発明の一実施例においては、前記したように、ノード管理サーバー５内に、ＮＩＳマスター・サーバー６００が存在し、該ＮＩＳマスター・サーバー６００が管理するＮＩＳマスター・マップ６２０を、サブネットワーク内に存在するすべてのＮＩＳスレーブ・サーバー６０１に分配することによって、サブネットワーク内に存在するすべてのＮＩＳマップの管理（同期） を行うものとする。すなわち、ノード管理サーバー５内に存在するＮＩＳマスター・サーバー６００は、該ＮＩＳマスター・サーバー６００が管理するＮＩＳマスター・マップ６２０が更新された場合、前記更新されたマップのコピーを、サブネットワーク内に存在するすべてのＮＩＳスレーブ・サーバー６０１に配送し、前記ＮＩＳスレーブ・サーバー６０１が、該配送されたＮＩＳマスター・マップ６２０のコピーを基に、ＮＩＳスレーブ・マップ６２１を構築することによって、サブネットワーク内に存在するＮＩＳマップの管理を行うことができる。具体的には、ＮＩＳマスター・マップ６２０が更新された場合、まず、ノード管理サーバー５内に存在するＮＩＳマスター・サーバー６００は、サブネットワーク内に存在するすべてのＮＩＳスレーブ・サーバー６０１に対して、ＮＩＳマスター・マップが更新されたことを通知する（ｙｐｐｕｓｈ）。ＮＩＳスレーブ・サーバー６０１は、前記ＮＩＳマスター・マップ６２０の更新通知を受信した場合、ＮＩＳマスター・サーバー６００に対して、ＮＩＳマスター・マップ６２０の転送を要求し、該転送されたＮＩＳマスター・マップ６２０を基に、前記ＮＩＳスレーブ・サーバー６０１は、ＮＩＳスレーブ・マップ６２１を再構築する（ｙｐｘｆｒ） 。
【０１８３】
ここで、前記したサブネットワーク内のＮＩＳマップの更新方法によると、ＮＩＳマスター・マップ６２０が更新された場合、ＮＩＳマスター・サーバー６００から、サブネットワーク内のＮＩＳスレーブ・サーバー６０１に、ＮＩＳマスター・マップ６２０の更新通知が送られるが、ＮＩＳスレーブ・サーバー６０１が他の処理の実行等で、前記更新通知を受信できなかった場合、該ＮＩＳスレーブ・サーバー６０１の管理するＮＩＳスレーブ・マップ６２１が更新されない可能性がある。この点は、ＮＩＳスレーブ・サーバー６０１が、ＮＩＳマスター・サーバー６００に対して、定期的に、ＮＩＳマスター・マップ６２０の転送を要求し、該転送されたＮＩＳマスター・マップ６２０を基にＮＩＳマップを再構築すること等によって改善することができる。また、ＮＩＳスレーブ・サーバー６０１は、ＮＩＳマスター・サーバー６００に対して、ＮＩＳマスター・マップ６２０の更新時刻の通知を要求し、該ＮＩＳスレーブ・マップ６２１の更新時刻と比較することによって、ＮＩＳマスター・マップ６２０の更新を知ることができ、前記更新情報に基づいてＮＩＳマップの再構築シーケンスを実行することができる。
【０１８４】
また、従来のＮＩＳには、以下に示すような問題点があった。すなわち、従来のＮＩＳにおいては、ＮＩＳクライアント６１の、ＮＩＳサーバー（ＮＩＳマスター・サーバー６００／ＮＩＳスレーブ・サーバー６０１）への１回目の帰属（ｂｉｎｄ）は、ＮＩＳクライアント・プロセス６１の起動時に行われるため、同一端末上に、ＮＩＳサーバー・プロセスとＮＩＳクライアント・プロセス６１が起動される場合でも、前記ＮＩＳクライアント・プロセス６１は、同一の端末上のＮＩＳサーバー・プロセスには帰属（ｂｉｎｄ）せず、ネットワークを経由して他の端末上のＮＩＳサーバー・プロセスに帰属してしまうといった問題点があった。すなわち、従来のＮＩＳクライアント６１のＮＩＳサーバーへの帰属（ｂｉｎｄ）は、前記要求（ｙｐｂｉｎｄ）をサブネットワークにブロードキャストし、前記要求に対し、一番早く応答を返したＮＩＳサーバーに、該要求を送信したＮＩＳクライアント６１は帰属される。従って、ＮＩＳクライアント６１のＮＩＳサーバーへの１回目の帰属（ｂｉｎｄ）は端末の起動（ｂｏｏｔ）期間中に行われ、前記起動（ｂｏｏｔ）期間中はＣＰＵは起動処理に忙しく、ＮＩＳクライアント６１の送出する前記要求（ｙｐｂｉｎｄ）に同一端末上のＮＩＳサーバーが直ちに応答できず、他の端末上のＮＩＳサーバーの方が早く応答し、前記ＮＩＳサーバーに帰属してしまうといった問題点があった。前記問題点のため、ＮＩＳクライアント６１は、ＮＩＳ情報にアクセスする場合、同一端末上にＮＩＳサーバーが起動されている場合でも、ネットワークを経由して他の端末上のＮＩＳサーバーにアクセスするため、ＮＩＳ情報にアクセスするのに時間がかかってしまうといった問題点と、ネットワークに負荷をかけてしまうといった問題点があった。
【０１８５】
以下、従来のＮＩＳにおいて、ユーザープロセスがネットワーク情報をアクセスする手順について説明した後、本発明の一実施例における、上記問題点の解決方法について、図６および図７を参照しながら説明する。
【０１８６】
従来のＮＩＳにおいては、ユーザープロセスが、ネットワーク情報をアクセスする場合、まず、前記ユーザープロセスが、対応するライブラリ・コールの呼び出しを行う。該呼び出しを受けたライブラリ・コールは、まず、ＮＩＳファイル（ローカル・ファイル） を参照し、検索したい情報が見つかるまで、前記ファイルを参照する。検索したい情報が、前記ＮＩＳファイル６３に見つからなかった場合、前記ライブラリ・コールは、検索したい情報の検索をＮＩＳクライアント６１に要求し、該検索要求を受信したＮＩＳクライアント６１は、該ＮＩＳクライアント６１が帰属（ｂｉｎｄ）しているＮＩＳサーバーに、前記検索要求をリレーイングする。前記検索要求を受信したＮＩＳサーバーは、該ＮＩＳサーバーが管理しているＮＩＳマップを検索し、検索情報をＮＩＳクライアント６１を経由して、該検索要求を出力したライブラリ・コールに返送する。該ＮＩＳサーバーが前記ＮＩＳマップを検索した結果、検索情報が見つからなかった場合、オペレーティング・システムによっては、検索要求をＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｅｒｖｅｒ）にリレーイングするものも存在する。
【０１８７】
本発明の一実施例においては、以上説明した従来のＮＩＳを、以下に示す２つの方法に変更することによって、前記問題点を解決している。
【０１８８】
１つ目の方法は、ＮＩＳクライアント６１の検索要求を送信する手順を変更することによって、前記問題点を解決する方法である。この方法によるアルゴリズムを、図８および図９に示す。なお、図８および図９に示すフローチャートは、図中のＬ１およびＬ２において連結されているものである。この点に関しては、後述する説明で参照する、複数の図面に分けて示された他のフローチャートについても、同様である。
【０１８９】
まず、ＮＩＳクライアントでは、ライブラリ・コールによるネットワーク情報の検索が行われ（ステップ１）、ＮＩＳファイル（ローカル・ファイル） を参照し（ステップ２）、検索したい情報が見つかった場合、検索を終了する（ステップ３〜５）。
【０１９０】
一方、検索したい情報が見つからなかった場合、前記ライブラリ・コールは、ＮＩＳクライアントに情報の検索を要求する（ステップ３）。この検索要求を受信したＮＩＳクライアントと同一の端末（Ｈｏｓｔ）に、ＮＩＳサーバーが起動している場合（ＮＩＳサーバーが起動しているかどうかは、ＯＳのプロセス管理表を検索すれば知ることができる） 、前記ＮＩＳクライアントが、前記同一の端末上に起動しているＮＩＳサーバーに、前記検索要求をリレーイングする（ステップ７，８）。そして、ＮＩＳマップの検索結果を知らせ（ステップ９，１２，１４，１５あるいはステップ９，１２，１６，１７，１８）、あるいはさらにＤＮＳに情報の検索を要求し（ステップ１９）、その検索結果を知らせる（ステップ２０，２１あるいはステップ２０，２２，２３）。
【０１９１】
前記ＮＩＳクライアントと同一の端末（Ｈｏｓｔ）にＮＩＳサーバーが起動していなかった場合は、前記ＮＩＳクライアント６１は、該ＮＩＳクライアント６１が帰属（ｂｉｎｄ）しているＮＩＳサーバーに、前記検索要求のリレーイングが行われ（ステップ７，１０）、以下、情報検索の後に、上記と同様の処理、すなわち検索結果の通知、場合によってはＤＮＳへの情報検索要求およびその検索結果の通知が実行される（ステップ１３〜２３）。
【０１９２】
２つ目の方法は、ＮＩＳクライアントのＮＩＳサーバーへの帰属（ｂｉｎｄ）方法を変更することによって、前記問題点を解決する方法である。なお、図１０に、この方法によるアルゴリズムを示す。
【０１９３】
ここに、従来のＮＩＳにおいては、ＮＩＳクライアントのＮＩＳサーバーへの帰属方法（ｙｐｂｉｎｄ）は、ＮＩＳクライアントが前記帰属要求をブロードキャストした後、一番早く前記ＮＩＳクライアントに応答を返したＮＩＳサーバーに、前記ＮＩＳクライアントが帰属するという方法であった。前記ＮＩＳクライアントの、ＮＩＳサーバーへの帰属方法を採用した場合、端末の起動（ｂｏｏｔ）後、１回目のＮＩＳクライアントのＮＩＳサーバーへの帰属は端末の起動手順実行中に行われるため、前記端末のＣＰＵは、前記端末の起動手順の実行に忙しく、前記１回目のＮＩＳクライアントの帰属要求（ｙｐｂｉｎｄ）にすばやく応答できないといったことが原因で、前記問題点が発生していた。
【０１９４】
本発明の一実施例においては、ＮＩＳクライアントがＮＩＳサーバーへ帰属を行う場合、まず、ＮＩＳクライアントと同一の端末にＮＩＳサーバーが起動している場合（ステップ３１）、前記ＮＩＳサーバーに前記ＮＩＳクライアントが帰属するとし（ステップ３２）、ＮＩＳクライアントと同一の端末にＮＩＳサーバーが起動していない場合に、前記ＮＩＳクライアントが、ネットワーク上の他の端末に対し、前記帰属要求（ｙｐｂｉｎｄ）をブロードキャストするとする（ステップ３７）。
【０１９５】
上記した本発明によるＮＩＳクライアントのＮＩＳサーバーへの帰属方法を採用した場合で、ＮＩＳクライアントと同一の端末上にＮＩＳサーバーが起動している場合、端末の起動後に行われる１回目のＮＩＳクライアントのＮＩＳサーバーの際、ＮＩＳクライアントは、同一の端末上に起動しているＮＩＳサーバーに帰属されるため、前記した問題点を解決することができる。
【０１９６】
なお、本発明においては、ノード管理サーバーが、ＮＩＳクライアントの要求に応じて、前記ＮＩＳクライアントの帰属（ｂｉｎｄ）するＮＩＳサーバーを決定することによって、ＮＩＳクライアントが網のブロードキャスト機能を使わずに、自分の帰属するＮＩＳサーバーを決定する方法を想定している。
【０１９７】
具体的には、ＮＩＳクライアントは、該ＮＩＳクライアントが起動（ｂｏｏｔ）した時点では、該ＮＩＳクライアントが帰属（ｂｉｎｄ）するＮＩＳサーバーはまだ決定されていないので、前記ＮＩＳクライアントは、帰属先のＮＩＳサーバーを決定しなければならない。また、ＮＩＳクライアントは、ＮＩＳサーバーからの応答が返ってこない場合や、ＮＩＳサーバーからの応答がおそくなった等の場合、帰属先のＮＩＳサーバーを変更することによって、ＮＩＳサーバーからの応答性能を改善しなければならない。
【０１９８】
本発明の一実施例においては、ＮＩＳクライアントは、帰属先のＮＩＳサーバーを決定または変更する必要の生じた場合、まず、前記ＮＩＳクライアントが、ノード管理サーバーに対してブート・チャネルを使用して前記要求を送信する。前記要求を受信したノード管理サーバーは、該ノード管理サーバーが管理する管理ファイルを参照し、サブネットワークに登録されたＮＩＳサーバーのうち、負荷の小さなＮＩＳサーバーを検索し、前記要求を送信したＮＩＳクライアントの帰属するＮＩＳサーバーを決定する。次に、ノード管理サーバーは、前記要求を送信したＮＩＳクライアントから、該ノード管理サーバーが決定したＮＩＳサーバーまでのコネクション（すなわち、インフォメーション・チャネル）を設定するとともに、前記ＮＩＳクライアントが、前記コネクションを使用するためのＶＰＩ／ＶＣＩ値等の設定を行う。
【０１９９】
また、前記ＶＰＩ／ＶＣＩ値等の設定において、予めＮＩＳクライアントが、ＮＩＳサーバーに対してデータ転送を行うためのＶＰＩ／ＶＣＩ値等が設定されている場合、新たにＶＰＩ／ＶＣＩ値等を設定し直さずに、予め設定されたＶＰＩ／ＶＣＩ値等を用いて、前記コネクションが使用できるようにした方が効率がよい。すなわち、ＮＩＳクライアントからの帰属先のＮＩＳサーバーの変更要求を受信した場合、ノード管理サーバーは、ＮＩＳクライアントから変更後のＮＩＳサーバーまでのコネクションの設定を行うとともに、前記ＮＩＳクライアントが、ＮＩＳサーバーとデータ転送するために使用していたＶＰＩ／ＶＣＩ値等を用いて、前記コネクションを使用できるように前記コネクションの設定を行えばよい。
【０２００】
前記した方法を採用することによって、ＮＩＳクライアントは、帰属先のＮＩＳサーバーを決定する場合、ノード管理サーバーに前記要求を送信すればよいので、従来方法の場合のような前記要求をブロードキャストして帰属先のＮＩＳサーバーを決定する必要はないので、本発明においては、ブロードキャストを用いずにＡＲＰ／ＮＩＳを実現することができる。
【０２０１】
なお、本発明によるブロードキャストを用いないＡＲＰ／ＮＩＳの実現方法を、従来のブロードキャスト機能を持たないＡＴＭ交換システムで行う場合、まず、端末（Ｈｏｓｔ）からノード管理サーバーまでのコネクション（すなわち、ブート・チャネル） を設定し、前記コネクションを使用するためのＶＰＩ／ＶＣＩ値として、特定値（例えば、ＶＰＩ＝ａｌｌ １ 、または、ＶＰＩ／ＶＣＩ＝ａｌｌ １）を割り当てる。次に、網のブロードキャスト機能を使用している従来の端末インターフェースに対し、ブロードキャスト・チャネルとして、前記特定値を割り当てる。前記方法を採用することによって、前記端末上に起動しているＮＩＳクライアントは、例えば、従来のブロードキャストによってＮＩＳサーバーを決定する際、網のブロードキャスト機能を用いるために前記特定値が使用されるので、前記ＮＩＳクライアントからのＮＩＳサーバー検索要求は、ブロードキャストされずに、ノード管理サーバーに転送されることになる。
【０２０２】
以上説明した方法を採用することによって、ＮＩＳクライアントは、前記ＮＩＳサーバー決定要求を、サブネットワーク内の端末にブロードキャストせずに、前記要求をノード管理サーバーに転送し、ノード管理サーバーが、前記ＮＩＳクライアントの帰属先のＮＩＳサーバーを決定することによって、ＮＩＳクライアントは、帰属先のＮＩＳサーバーを決定することができる。
【０２０３】
１−５．呼設定について
端末（Ｈｏｓｔ）が行うデータ通信には、前述したように、コネクション型のデータ通信とコネクションレス型のデータ通信がある。また、コネクション型データ通信には、予め設定されたコネクションを用いて行うコネクション型のデータ通信と、予めコネクションが設定されていない宛先に対して、コネクションを設定してからデータ通信を行うコネクション型のデータ通信が存在する。ここでは、予めコネクションが設定されていない宛先に対して、コネクションを設定してからデータ通信を行うコネクション型のデータ通信について説明する。
【０２０４】
また、本節の次の（１−６） 節では、予め設定されたコネクションを用いて行うコネクション型のデータ通信と、コネクションレス型のデータ通信について説明する。
【０２０５】
以下、本発明の一実施例による呼設定手順を用いた、予めコネクションが設定されていない宛先に対して、コネクションを設定してからデータ通信を行う方法について、図１１を参照しながら具体的に説明する。また、呼設定時の各アルゴリズムのうち、端末のデータ通信のアルゴリズムを図１２，１３に、呼設定サーバの呼設定アルゴリズムを図１４，１５に、ノード管理サーバのコネクション設定アルゴリズムを図１６に、ノード設定サーバの設定アルゴリズムを図１７に、それぞれ示す。
【０２０６】
端末（Ｈｏｓｔ）は、データ通信を行う必要が生じた場合、まず、宛先のデータ受信端末までのデータ転送に必要なＱＯＳを持つコネクションがすでに設定されているかどうか、ＮＩＳ等を用いてＶＰＩ／ＶＣＩテーブルを検索する。すなわち、データ通信を行う必要の生じたユーザ・プロセスは、まず、端末固有のＶＰＩ／ＶＣＩテーブルであるＮＩＳファイル６３を参照し、次に、サブネットワークに属する端末に共通なＶＰＩ／ＶＣＩテーブルであるＮＩＳマップ６２を参照し、宛先のデータ受信端末までのセル転送のための、ＶＰＩ／ＶＣＩ値等が、すでに設定されているかどうか、宛先のデータ受信端末の名前をキーとして、前記テーブルを検索する（図１２のステップ５２，５４）。
【０２０７】
具体的には、端末上の、データ通信を行う必要の生じたユーザ・プロセスは、対応するコネクションがすでに設定されているかどうか調べるため、対応するライブラリ・コールを実行する。前記ライブラリ・コールは、まず、端末固有のＮＩＳファイル６３に、宛先のデータ受信端末までの、セル転送時に用いるＶＰＩ／ＶＣＩ値等が、すでに設定されているかどうか、参照要求を行う（ステップ５２）。前記ＮＩＳファイル６３に、前記ＶＰＩ／ＶＣＩ値等がすでに設定されていた場合、前記ユーザ・プロセスは、前記ＶＰＩ／ＶＣＩ値等を用いて、セルを作成し、作成したセルを送信することによって、データ転送を開始する（図１３のステップ６３，６４）。
【０２０８】
前記ＮＩＳファイル６３に、前記ＶＰＩ／ＶＣＩ値等が設定されていなかった場合、前記ライブラリ・コールは、前記ＮＩＳファイル６３に対して行った参照要求を、該端末上に起動しているＮＩＳクライアント・プロセス６１にリレーイングし、前記ＮＩＳクライアント６１は、宛先のデータ受信端末までのセル転送時に用いるＶＰＩ／ＶＣＩ値等について、前記ＮＩＳクライアント６１が帰属（ｂｉｎｄ）しているＮＩＳサーバーに問い合わせる（図１２のステップ５３）。
【０２０９】
前記問い合わせを受信したＮＩＳサーバーは、該ＮＩＳサーバーが管理しているＮＩＳマップ６２を検索し、前記ユーザー・プロセスのセル転送時に用いるＶＰＩ／ＶＣＩ値等が、すでに設定されているかどうか検索する（ステップ５４）。前記ＶＰＩ／ＶＣＩ値等がすでに設定されていた場合、該ＮＩＳサーバーは、前記ＶＰＩ／ＶＣＩ値等を、ＮＩＳクライアント６１を経由して前記問い合わせをしたユーザ・プロセスに通知する（ステップ５４，６２）。一方、前記ＶＰＩ／ＶＣＩ値等が設定されていなかった場合、該ＮＩＳサーバーは、検索の失敗を、ＮＩＳクライアント６１を経由して前記問い合わせをしたユーザ・プロセスに通知する（図１２のステップ５４，５５）。
【０２１０】
前記ＮＩＳサーバーから、セル転送時に用いるＶＰＩ／ＶＣＩ値等の通知を受けたユーザ・プロセスは、前記ＶＰＩ／ＶＣＩ値等を用いて、セルを作成し、作成したセルを送信することによって、データ転送を開始する（図１３のステップ６２，６４）。
【０２１１】
前記ＮＩＳサーバーから、セル転送時に使用するＶＰＩ／ＶＣＩ値等の検索の失敗通知を受信したユーザ・プロセス、またはＮＩＳクライアント・プロセス６１は、以下に説明する呼設定手順を実行することによって、セル転送時に用いるＶＰＩ／ＶＣＩ値等を獲得する。なお、ユーザ・プロセス、またはＮＩＳクライアント６１は、ＶＰＩ／ＶＣＩ値等の獲得要求がタイムアウトすることによって、以下に示す、呼設定手順を実行してもよい。
【０２１２】
具体的には、端末上のユーザ・プロセスまたはＮＩＳクライアント・プロセス６１は、呼設定クライアント・プロセスを起動し、前記起動された呼設定クライアント・プロセスは、端末の起動時に設定されたシグナリング・チャネル１３を用いて、シグナリング・セルをＡＴＭ交換システム内に存在する呼設定サーバーに転送する（図１２のステップ５６）。
【０２１３】
呼設定サーバーは、前記シグナリング・セルを受信すると（図１４のステップ７０）、前記シグナリング・セル中に記述された、通信品質（ＱＯＳ、トラヒック・パラメータ等） で、宛先のデータ受信端末までのコネクションの設定を、ノード管理サーバー５に要求する（図１４のステップ７２）。
【０２１４】
ノード管理サーバー５は、前記コネクション設定要求を受信すると（図１６のステップ９０）、該ノード管理サーバー５が管理する管理ファイル５６を参照し、前記データ送信端末が、申告したトラヒック・パラメータでセルを送出した場合、網がサービスを提供しているコネクションのＱＯＳと、前記データ送信端末の要求するコネクションのＱＯＳを、網が保証することができるかどうか判定する （図１６のステップ９１）。前記判定等の結果、網が前記データ送信端末の要求するコネクションを受け入れることができる場合、前記コネクションを設定するため、ノード管理サーバー５は、対応するノード設定サーバー４に対し、ルーティングタグ・テーブルといった対応するハードウェアの設定を要求する（図１６のステップ９３）。一方、前記判定等の結果、網が前記データ送信端末の要求するコネクションを受け入れることができない場合、前記ノード管理サーバー５は、呼設定サーバーを経由して（図１６のステップ９２）、前記呼設定要求を受け入れない旨、前記データ送信端末に通知する（図１４のステップ７５，７６，７８）。
【０２１５】
ノード設定サーバー４は、前記ハードウェア設定要求を受信すると（図１７のステップ１１０）、ルーティングタグ・テーブルといった、対応するハードウェアに対し、指定されたデータを書き込むとともに（図１７のステップ１１１）、ノード設定サーバー４が管理するｂａｃｋｕｐファイル４２がある場合、前記ｂａｃｋｕｐファイル４２に設定内容の書き込みを実行する（図１７のステップ１１３〜１１６）。前記ノード設定サーバー４は、前記設定が終了した場合、前記設定要求を出したノード管理サーバー５に対して、前記設定の終了を通知する（図１７のステップ１１２）。
【０２１６】
ノード管理サーバー５は、前記設定終了の通知を受信すると（図１６のステップ９６）、該ノード管理サーバー５の管理する管理ファイル５６の更新を行い （図１６のステップ９８）、呼設定が要求された前記コネクションが、サブネットワークに属するすべての端末に共通するコネクションであった場合、必要に応じて、前記管理ファイル５６からＮＩＳマップ６２が作成され、該作成したＮＩＳマップ６２で、該ノード管理サーバー５が管理するＮＩＳマップ６２を更新する（図１６のステップ９９〜１００）。
【０２１７】
ここに、本発明の一実施例においては、ノード管理サーバー５は、ＮＩＳマスター・サーバー６００としても機能していると想定しているので、前記ＮＩＳマップ６２が更新された場合、前記マップを管理しているノード管理サーバー５は、対応するＮＩＳスレーブ・サーバー６０１に対し、該当するＮＩＳマップ６２の更新を要求する（図１６のステップ１０１）。最後に、ノード管理サーバー５は、以上説明したような設定が終了した場合、設定の終了と前記コネクションの設定とを要求したデータ送信端末がセル転送時に使用するＶＰＩ／ＶＣＩ値等を、前記呼設定サーバーを経由して、前記データ送信端末へ通知する（図１６のステップ９７と図１４のステップ７７）。
【０２１８】
データ送信端末は、前記設定終了とＶＰＩ／ＶＣＩ値等の通知とを受けると （図１２のステップ５９）、前記ＶＰＩ／ＶＣＩ値等を基にセルを作成し、該作成したセルを、呼設定時に、網に申告したトラヒック・パラメータを違反しないように送信することによって、データ転送を開始する（図１２のステップ６０，６４）。なお、前記データ送信端末は、宛先のデータ受信端末に対するコネクションのうち、該端末に固有なＶＰＩ／ＶＣＩ値等を記憶しているＮＩＳファイル６３に、前記網から通知されたＶＰＩ／ＶＣＩ値等を追加してもよい。
【０２１９】
前記した呼設定手順は、データ送信端末とデータ受信端末が、同一のサブネットワークに存在する場合であったが、以下、データ送信端末とデータ受信端末が、同一のサブネットワークに存在しない場合について、前記した呼設定手順との差分について、具体的に説明する。
【０２２０】
呼設定サーバーが受信した呼設定要求のうち、該呼設定で要求されるコネクションのエンド・ポイントであるデータ受信端末が、前記呼設定サーバーが対象とするサブネットワークにない場合（図１４のステップ７１）、前記呼設定サーバーは、対象とするサブネットワーク内の呼設定と、対象とするサブネットワーク外の呼設定の両方について対応しなければならない。呼設定サーバーが対応しなければならない前記呼設定のうち、該呼設定サーバーが対象とするサブネットワーク内の呼設定（データ送信端末からＩＷＵまでの呼設定） については、前記したデータ送信端末とデータ受信端末が同一のサブネットワーク内にある場合と同様である（図１５のステップ７９）。
【０２２１】
一方、該呼設定サーバーが対象とするサブネットワーク外の呼設定については、該呼設定サーバーが受信した呼設定要求を、対応するサブネットワーク外の呼設定サーバーにリレーイングすることによって実行される（図１５のステップ８０）。すなわち、前記呼設定要求を受信した呼設定サーバーは、該受信したデータ送信端末からデータ受信端末までの呼設定要求を、サブネットワーク内の対応するＩＷＵからデータ受信端末までの呼設定要求に変更し、前記変更した呼設定要求を、前記呼設定サーバー７は、対応するサブネットワーク外の呼設定サーバーに、対応するシグナリング・チャネル１３を用いて転送する。前記サブネットワーク内の呼設定サーバー７は、該サブネットワーク内のノード管理サーバー５からコネクションの設定通知および前記コネクションを用いるためのＶＰＩ／ＶＣＩ値等を受信するとともに（図１５のステップ８３）、該サブネットワーク外の対応する呼設定サーバーからコネクションの設定通知を受信した場合（図１５のステップ８４）、前記サブネットワーク内の呼設定サーバーは、該呼設定要求を送信したデータ送信端末に対し、呼設定の終了と、前記コネクションを用いるためのＶＰＩ／ＶＣＩ値等とを通知する（図１４のステップ７７）。
【０２２２】
前記した手順において、変更された呼設定要求を受信したサブネットワーク外の呼設定サーバーの行う手順については、サブネットワーク内の呼設定サーバー７の行う手順と同様である。すなわち、該呼設定要求を受信したサブネットワーク外の呼設定サーバーは、該呼設定要求を、担当するサブネットワーク内の呼設定と、担当するサブネットワーク外の呼設定要求に分割し、担当するサブネットワーク内の呼設定に対しては、コネクションの設定を、対応するノード管理サーバー５に要求する。また、担当するサブネットワーク外の呼設定要求に対しては、呼設定要求を、前記したように変更した後、対応する呼設定サーバーに対し、シグナリング・チャネルを用いて転送する。
【０２２３】
前記したノード管理サーバー５の呼設定手順においては、該ノード管理サーバー５は、呼設定サーバー７からの要求に従って、ノード設定サーバー４に対しハードウェアの設定要求を送信するとしていた。ノード管理サーバー５が、要求を受け付けた旨を、呼設定サーバーからの要求を受け付けるとすぐに呼設定サーバーへ返答せずに、処理が終了してから呼設定サーバーへ返答する場合、以下のようなことが生じる可能性がある。すなわち、前記方法を採用した場合、呼設定サーバーが呼設定要求を送信する度に、ノード管理サーバー５は、ハードウェアの設定要求をノード設定サーバー４に送信するが、前記呼設定サーバー７が、前記呼設定要求のタイムオーバー等の原因によって呼設定要求を再送した場合、該ノード管理サーバー５は、ノード設定サーバー４に対してハードウェアの設定要求を再送する可能性がある。この点は、以下の手順を採用することにより回避できる。すなわち、ノード管理サーバー５が、呼設定サーバー７から呼設定要求を受信した場合、管理ファイル５６を参照し、前記呼設定要求に対し設定するコネクションが、すでに前記管理ファイル５６に登録されていた場合、ノード設定サーバー４に対しては設定要求を出さずに、端末に対して設定完了通知を出すことによって、上記可能性は回避できる。
【０２２４】
しかし、この場合でも、管理ファイル５６に登録されている情報と、実際にハードウェアに設定されている設定データとが異なるときは、端末からのコネクション設定要求が無視される可能性がある。この点に関しては、管理ファイル５６に登録されているコネクションに対し、１回目の設定要求に対しては前記した通り何のアクションも起こさないが、２回目以降の設定要求に対して何らかのアクション（例えば、実際に設定を行う、または、エラーを返す等） を起こすことによって改善される。
【０２２５】
同様に、ノード設定サーバー４は、ノード管理サーバー５から、ハードウェア・テーブルの設定要求を受信した場合、ｂａｃｋｕｐファイル４２が存在する場合、前記ｂａｃｋｕｐファイル４２を参照し、前記ハードウェアの設定がすでに実行されている場合、前記設定要求に対してはハードウェアの設定を行わずに、ノード管理サーバー５に対して設定完了を通知することによって、性能が改善される。さらに、コネクション設定サーバーは、ｂａｃｋｕｐファイル４２にすでに実行されたアクションに対して、１回目のアクション要求に対してはアクションを起こさず、２回目以降のアクション要求に対して何らかのアクション（例えば、実際に設定を行う、または、エラーを返す等） を起こすことによって、ｂａｃｋｕｐファイル４２と実際のハードウェアの不一致による不具合を改善することができる。
【０２２６】
１−６．予め設定されたコネクションを用いたデータ通信について
ここでは、前記したように、予め設定されたコネクションを用いて行うコネクション型のデータ通信と、コネクションレス型のデータ通信について、図１１、図１２、および１３を参照しながら、具体的に説明する。
【０２２７】
本発明の一実施例においては、前記したように、端末（Ｈｏｓｔ）上の、データ通信を行う必要の生じたユーザ・プロセスは、まず、端末固有のＶＰＩ／ＶＣＩテーブルであるＮＩＳファイル６３を参照し、次に、サブネットワークに属する端末に共通なＶＰＩ／ＶＣＩテーブルであるＮＩＳマップ６２を参照し、宛先のデータ受信端末までのセル転送に必要なＱＯＳを満たすコネクションが、すでに設定されているかどうか、宛先のデータ受信端末の名前をキーとして、前記テーブルを検索する。前記ＮＩＳファイル６３またはＮＩＳマップ６２を参照した結果、宛先のデータ受信端末までのコネクションがすでに設定されていた場合、前記すでに設定されているコネクションを用いてデータ転送を開始する。すなわち、前記ユーザ・プロセスは、前記２つのテーブルを検索した結果、得られたＶＰＩ またはＶＰＩ／ＶＣＩ値等を使用して、送信データから、定義されたプロトコルに従ってユーザセルを作成し、該作成したセルを、前記テーブル検索時に用いたトラヒック・パラメータを違反しないように送信することによって、データ転送を開始する。
【０２２８】
以上説明した、予め設定されたコネクションを用いてデータ通信を行う場合には、以下に説明するような、ＰＶＣ（Ｐｅｒｍａｎｅｎｔ Ｖｉｒｔｕａｌ Ｃｏｎｎｅｃｔｉｏｎ）を用いてデータ通信を行う場合と、呼接続が終了していないコネクションを用いて、コネクション型のデータ通信を再開する場合と、コネクションレス型のデータ通信を行う場合の、３通りの場合が存在する。以下、前記３とおりの場合について、具体的に説明する。
【０２２９】
ＰＶＣを用いたデータ通信は、よくデータ通信が行われる端末間に、予めコネクションを設定しておくことによって、実際にデータ通信を行う必要の生じた時に、呼設定を行わずに、データ転送を開始することのできる効率的なデータ通信方法をユーザに提供する方法である。前記ＰＶＣを用いたデータ通信方法を、本発明のＡＴＭ交換システムで行うためのは、前記よくデータ通信が行われるデータ送信端末とデータ受信端末間に、予め、前記データ通信に必要なＱＯＳと、トラヒック・パラメータを持つコネクションを設定しておき、前記コネクションのためのＶＰＩ／ＶＣＩ値等を、ＮＩＳファイル６３（またはＮＩＳマップ６２）に登録しておく。
【０２３０】
本発明によるＡＴＭ交換システムにおいては、前記したデータ送信端末が、データ通信を行う必要が生じた場合、宛先のデータ受信端末までのコネクションが、すでに設定されているかどうか調べるために、宛先のデータ受信端末の名前と、データ通信に必要なＱＯＳを、キーとして、ＮＩＳファイル６３（またはＮＩＳマップ６２） が検索される。前記ＮＩＳファイル６３（またはＮＩＳマップ６２） には、ＰＶＣを用いたデータ通信のためのＶＰＩ／ＶＣＩ値等が予め設定されているので、前記検索の結果、前記コネクションに対するＶＰＩ／ＶＣＩ値等が検索される。前記データ送信端末は、前記検索されたＶＰＩ／ＶＣＩ値等を用いて、送信するセルを作成し、前記ＮＩＳファイル６３（またはＮＩＳマップ６２） 検索時に得られたトラヒック・パラメータに違反しないように、該作成したセルを送信することによって、呼設定を行わずにデータ転送を開始することができる。
【０２３１】
当初予定していたデータ通信は終了したが、コネクションの接続を終了していないコネクションを用いて、コネクション型のデータ通信を再開する場合には、以下に示す２通りのものが存在する。すなわち、１つ目の場合は、ユーザ側の立場から、データ転送が終了したコネクションに対して、コネクションの接続を解除しないことによって、同一の宛先に呼設定を行わずに、効率的にデータ通信を行う目的のためのものである。２つ目の場合は、網側の立場から、データ通信が行われたデータ送信端末とデータ受信端末の間には、近い将来に再びデータ通信が行われる可能性が高く、前記コネクションに対して、可能な限りコネクションの接続を保持することによって、前記コネクションに対して網が再び呼設定要求の処理を実行する手間を省略するためのものである。
【０２３２】
１つ目の場合の、ユーザの立場によるコネクションの切断の保留は、ユーザからのコネクションの切断要求によって、コネクションの接続を解除することによって実現できる。すなわち、網は、ユーザからのコネクションの切断要求を受信するまでは、一度呼設定されたコネクションを解除しないことによって、ユーザは、前記コネクションを用いて、同一の宛先に対して、呼設定を行わずに効率的にデータ通信を行うことができる。
【０２３３】
この方法をユーザに提供した場合、ユーザは効率的にデータ通信を行えるという利点がある。一方、ユーザがコネクションの切断要求を行わない場合、新たにコネクションを設定できない可能性がある。この点への対処方としては、コネクションの設定継続時間に対し課金をすることによって、ユーザのコネクションの切断要求を促す方法が考えられる。本発明の一実施例においては、前記したユーザの立場によるコネクションの切断の保留は、ＰＶＣによる方法によってユーザにサービスを提供することを想定する。
【０２３４】
２つ目の場合の網の立場によるコネクション切断の保留は、ユーザのデータ通信が終了した場合でも、一定期間、前記データ通信に用いられたコネクションの接続を終了しないことによって、前記一定期間内に再び同一のデータ通信が行われる場合、再び網が呼設定処理を行わずに、ユーザに対し、サービスを提供できるといった方法である。前記方法は、コネクションの切断を、ライフタイムと呼ばれる一定期間行わずに、前記ライフタイムの期間内に同一のデータ通信が行われる場合、呼設定を行わずにデータ通信を行うことによって実現することができる。前記方法を採用した場合、データ通信が終了しても、前記ライフタイムの期間内はコネクションが切断されないので、前記ライフタイムの期間内に、同一のデータ通信が行われる場合は、ユーザは呼設定要求を行わずにデータ通信を行うことによって、網は、呼設定要求に対する処理を行う手間が軽減されるといった利点がある。
【０２３５】
一方、１つ目の場合に対して、コネクションの継続時間に対して課金する方法を採用した場合、ユーザは、コネクションの継続時間に対する課金を少なくするため、コネクションの継続時間、すなわちライフタイムに対する時間設定を小さくしようとする。そのした結果として、同一の宛先に対してデータ通信が行われる場合でも、前記ライフタイムの期間内に、前記データ通信が行われる可能性が低下し、前記同一の宛先に対するデータ通信が行われる際にも、ユーザが、呼設定を行わなければならない場合が多くなることも考えられる。この点は、ユーザの送信する呼設定要求に対して課金することによって、ユーザの、ライフタイムに対する時間設定を長く設定するように誘導することによって、改善することができる。なぜなら、ユーザは、呼設定要求回数に対する課金およびライフタイムに対する課金の課金金額の合計が最小となるように、ライフタイムに対する時間設定を変えるため、網が呼設定要求回数に対する課金を高くした場合、ユーザは、ライフタイムに対する時間設定を長くすることによって、同一の宛先に対してデータ通信を行う場合、呼設定要求を出さずにデータ通信を行おうとするためである。
【０２３６】
一方、企業内ネットワークの場合は、データ通信に対して課金が行われないので、前記課金を行うことによって、ユーザのライフタイムに対する時間設定を、網側の意図によって誘導することはできない。従って、前記した企業内ネットワークの場合は、網にとって都合のよいライフタイムに対する時間設定を、ユーザが使用するように推奨することが望ましい。
【０２３７】
以下、本発明の一実施例においては、コネクションに対して、ライフタイムを設定する方法を想定して説明する。なお、前記したＰＶＣに対しては、無限大のライフタイムを設定することによって対応することができる。
【０２３８】
以下、コネクションレス型データ通信を、予め設定されたコネクションを用いて行う場合について、具体的に説明する。
【０２３９】
ここに、従来のＡＴＭ交換システムにおいては、コネクションレス型のデータ通信は、ＣＬＳＦ処理手段によって実行される。すなわち、データ送信端末が、コネクションレス型のデータ通信を行う場合、情報セルをＣＬＳＦ処理手段に送信することによって、前記データ通信を実行することができる。一方、従来のコンピュータ間のデータ通信は、コネクションレス型のデータ通信方法を用いて行われていたので、従来構成のＡＴＭ交換システムにおいて、従来方法によってコンピュータ間のデータ通信を実行した場合、コンピュータ間のデータ通信は、ＣＬＳＦ処理手段に集中してしまう、といった問題点があった。
【０２４０】
前記問題点については、コンピュータ間のデータ通信を行う端末間に、予めＱＯＳの保証を必要としないコネクションを設定しておき、端末が、前記データ通信を行う必要が生じた場合、前記コネクションを用いてデータ通信を行うことによって、ＣＬＳＦ処理手段を経由せずにデータ通信が行えるので、前記問題点は軽減される。具体的には、ネットワークの立ち上げ時、または、端末の立ち上げ時、または、端末の要求に従って、コンピュータ間のデータ通信を行う端末間に、予めＱＯＳの保証を必要としないコンピュータ間のデータ通信用のコネクションを設定しておく。端末（Ｈｏｓｔ）が、従来方法によって、コンピュータ間のデータ通信を行う場合、端末上のソフトウェア、またはＴＣＰ等のプロトコル・ソフトウェアによって、廃棄されたパケットに対して再送制御等が行われるので、前記データ通信を行うためのコネクションに対してはセル廃棄があってもよい。また、コンピュータ間等のデータ通信の多くの場合は、ファイル転送等のデータ転送の遅延が許されるデータ転送である。従って、前記コンピュータ間のデータ通信は、ＱＯＳ（セル廃棄率、セル転送遅延等） の保証を必要としないライフタイムが無限大のコネクションで提供することができる。前記コネクションに対するＶＰＩ／ＶＣＩ値等は、予めＮＩＳマップ６２またはＮＩＳファイル６３に登録しておき、前記端末が、前記宛先に対するデータ通信を行う必要が生じた場合、前記ＮＩＳファイル６３またはＮＩＳマップ６２を検索することによって、前記コネクションに対するＶＰＩ／ＶＣＩ値等を獲得し、前記ＶＰＩ／ＶＣＩ値等を用いて、送信セルを作成し、前記セルを送信することによってデータ転送を開始する。
【０２４１】
１−７．保守・管理について
本発明の一実施例においては、ＡＴＭ交換システムの保守・管理の大部分は、ノード管理サーバー５が行うことを想定している。以下、図１を参照しながら、本発明の一実施例におけるノード管理サーバー５によるＡＴＭ交換システムの保守・管理方法について具体的に説明する。
本発明の一実施例で想定しているＡＴＭ交換システムの保守・管理には、以下の項目が存在する。
（１）コネクションの接続確認
（２）端末または各種サーバーの生存確認
（３）ハードウェア・テーブル等の正当性確認およびソフトウェア・テーブル等の正当性確認
（４）ハードウェア・テーブルとソフトウェア・テーブル間の整合性確認
（５）複数ソフトウェア・テーブル間の整合性確認
（６）統計情報の収集および統計情報に基づくコネクション制御
以下、前記した各項目について、具体的に説明する。
【０２４２】
１−７−１．コネクションの接続確認
従来のＡＴＭ交換システムでは、コネクションの接続確認は、物理リンクのエンド・エンド間の物理レイヤでの接続確認と、ＡＴＭコネクションのエンド・エンド間のＡＴＭレイヤでの接続確認の２レベルの接続確認を想定している。
【０２４３】
本発明の一実施例においては、前記物理レイヤでの接続確認は、ハードウェアに組み込まれた論理回路（セル同期回路、フレーム同期回路等） によって行われるものとし、前記論理回路によって行われた物理レイヤでの接続確認情報は、ハードウェア上のレジスタまたはＲＡＭ等に、必要に応じて書き込まれるとする。また、本発明の一実施例においては、ノード管理サーバー５は、前記接続確認情報等を、以下に示す３つの方法によって獲得することを想定している。すなわち、１つ目の方法は、ノード管理サーバー５が、ノード設定サーバー４を経由して、ハードウェア上の前記接続確認情報等を読み取る方法であり、最も一般的な方法と考えられる。２つ目の方法は、ノード設定サーバー４が、ハードウェア上の前記接続確認情報等を、周期的にポーリングする方法である。前記ノード設定サーバー４がポーリングした結果得られた接続確認情報等に異常が検出された場合、ノード設定サーバー４が、割込みでノード管理サーバー５に通知するか、それとも前記接続確認情報等をノード設定サーバー４が管理するｂａｃｋｕｐファイル４２に書き込んでおき、ノード管理サーバー５がノード設定サーバー４を経由して、前記ｂａｃｋｕｐファイル４２に書き込まれた情報をアクセスすることによって、ノード管理サーバー５が前記情報にアクセスすることができる。前記した２つ目の方法は、ハードウェアとソフトウェアにとって、最も負荷の小さい方法と考えられる。３つ目の方法は、物理レイヤで得られた接続確認情報等に異常が検出された場合、前記異常を検出したハードウェア上のロジックが、割込みで前記異常をノード設定サーバー４に通知し、ノード設定サーバー４は、前記異常情報をノード管理サーバー５にリレーイングすることによって、ノード管理サーバー５は、異常情報にアクセスするという方法である。前記した３つ目の方法は、ノード管理サーバー５が、異常情報を最も早くアクセスできる方法と考えられる。
【０２４４】
また、前記ＡＴＭレイヤでの接続確認は、ＡＴＭコネクションのエンド・エンド間に、接続確認用のＯＡＭセルを転送することによって、前記ＡＴＭレイヤでの接続確認を実行することができる。具体的には、ノード管理サーバー５は、管理ファイル５６に登録されたコネクションのうち、接続確認を行う必要のあるコネクションに対して、コネクションの一方のエンド・ポイントをノード管理サーバー５とし、コネクションのもう一方のエンド・ポイントでループバックされる（または、応答を返す）ような設定を施した接続確認用のＯＡＭセルを送信する。前記接続確認用のＯＡＭセルが、前記コネクションのエンド・ポイントでループバックされ、前記ＯＡＭセルを、前記ノード管理サーバー５が、再び受信することによって、前記接続確認を実行することができる。
【０２４５】
また、前記ノード管理サーバー５は、必要に応じて、前記ＯＡＭセルを送信してから、再び前記ＯＡＭセルを受信するまでの時間を測定することによって、前記ＯＡＭセルを送信したコネクションの、セルの混み具合（輻輳状態） を知ることができる。
【０２４６】
以上説明した、物理レイヤとＡＴＭレイヤの接続確認等の情報は、必要に応じて管理ファイル５６に書き込まれ、管理ファイル５６をアクセスすることによって、ＡＴＭ交換システム内のすべての接続確認情報にアクセスできるような手段を、網はシステム管理者に対し提供してもよい。
【０２４７】
１−７−２．端末または各種サーバーの生存確認
以下、端末または各種サーバーの生存確認方法について説明する。なお、生存とは、端末や各種サーバーなどの個々の装置が正常に動作していることを言うものとする。
【０２４８】
本発明の一実施例においては、端末（または各種サーバー）の生存確認は、以下に示すような、３レベルの確認方法によって行うことを想定する。すなわち、所定のチャネル、例えばブートチャネルやメタシグナリングチャネルを使って、第１レベルの生存確認として、ノード管理サーバー５から端末（または、各種サーバー） までのコネクションの接続確認とし、第２レベルの生存確認として、ノード管理サーバー５から端末（または、各種サーバー） 上のプロトコル・ソフトウェアまでのコネクションの接続確認とし、第３レベルの生存確認として、ノード管理サーバー５から端末（または、各種サーバー） 上のソフトウェアまでのコネクションの接続確認とする。
【０２４９】
第１レベルの生存確認は、前記したＡＴＭレイヤでのコネクションの接続確認方法と同様の方法で実現することができる。すなわち、ノード管理サーバー５から端末（または、各種サーバー） で、ループバックされるような設定を施した接続確認用のＯＡＭセルを送信し、前記ＯＡＭセルを前記ノード管理サーバー５が再び受信することによって、第１レベルの生存確認を実現することができる。
【０２５０】
第２レベルの生存確認は、従来から行われているＴＣＰ／ＩＰにおけるＩＣＭＰ（Ｉｎｔｅｒｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ ）のエコー（ｅｃｈｏ）要求パケットの送受信と同じような方法によって実現することができる。すなわち、端末（または、各種サーバー） 上に実装されるプロトコル・ソフトウェアの中に、特定のフォーマットを持つセルを受信した場合、受信セルの宛先と送り元をひっくり返したセルを送信するルーチンを設け、前記ルーチンを用いて送り元から送信されたセルを送り元に返送することによって、端末（または、各種サーバー） 上のプロトコル・ソフトウェアの生存確認を行うことができる。前記第２レベルの生存確認を用いることによって、ホスト・インターフェースのハードウェアとソフトウェアとの間のインターフェースが、正常に機能していることを確認することもできる。
【０２５１】
第３レベルの生存確認は、前記した第２レベルの生存確認と同じ方法を用いて実行することができる。すなわち、端末（または、各種サーバー） 上に実装されるアプリケーション・ソフトウェアの中に、特定のフォーマットを持つセルを受信した場合、受信セルの宛先と送り元をひっくり返したセルを送信するルーチンを設け、前記ルーチンを用いて送り元から送信されたセルを送り元に返送することによって、端末（または、各種サーバー） 上のアプリケーション・ソフトウェアの生存確認を行うことができる。
【０２５２】
１−７−３．ハードウェア・テーブル等の正当性確認およびソフトウェア・テーブル等の正当性確認
本発明の一実施例においては、ソフトウェア・テーブル（ もしくは、ハードウェア・テーブル） として、ｂａｃｋｕｐファイル４２、ｃｏｎｆｉｇファイル５５、管理ファイル５６、ＮＩＳマップ６２、ＮＩＳファイル６３の５つのファイルを想定している。前記ソフトウェア・テーブルとハードウェア・テーブルの正当性は、パリティ・チェック等の方法によって確認することができる。すなわち、テーブルにデータを書き込む場合、データとともにパリティ・データもテーブルに書き込んでおき、テーブルからデータを読み出す場合、前記パリティ・データを基にパリティ・チェックを行うことによって、テーブルの正当性を確認することができる。
【０２５３】
１−７−４．ハードウェア・テーブルとソフトウェア・テーブル間の整合性確認
本発明の一実施例においては、ハードウェア・テーブルと、ノード管理サーバー５が管理するｂａｃｋｕｐファイル４２（ソフトウェア・テーブル） との間に、整合性が取れていることを想定している。すなわち、本発明においては、ハードウェアの検出情報（例えば、エラー情報） を、ノード管理サーバー５がアクセスする方法として、ノード設定サーバー４が、ハードウェア・テーブルをポーリングして、ｂａｃｋｕｐファイル４２に書き込んだ情報を、ノード管理サーバー５が、ノード設定サーバー４を経由して読み取ることによって、効果的にアクセスする方法を想定していた。また、本発明においては、交換機に電源断等の障害が発生し、ハードウェア・テーブルの内容が破壊された場合、ノード設定サーバー４が、ｂａｃｋｕｐファイル４２に書かれた情報を基に、ハードウェア・テーブル等を復元することを想定していた。従って、本発明においては、ハードウェア・テーブルとソフトウェア・テーブルとの間に、整合が取れていることが必要である。
【０２５４】
本発明の一実施例においては、ノード設定サーバー４が、定期的に、ハードウェア・テーブルと、ｂａｃｋｕｐファイル４２（ソフトウェア・テーブル） を読み出して、読み出したデータを比較することによって、前記整合性の確認を行うものとする。
【０２５５】
１−７−５．複数ソフトウェア・テーブル間の整合性確認
本発明の一実施例においては、管理ファイル５６とｂａｃｋｕｐファイル４２、管理ファイル５６とノード管理サーバー５が管理するＮＩＳマップ６２（ 以下、ＮＩＳマスター・マップ６２０と呼ぶ） 、ＮＩＳマスター・マップ６２０とＮＩＳスレーブ・サーバー６０１が管理するＮＩＳマップ６２（ 以下、ＮＩＳスレーブ・マップ６２１ と呼ぶ） といったファイル間に整合性が取れていることを想定している。以下、前記３組のファイル間の整合性について、順に説明する。
【０２５６】
まず、管理ファイル５６とｂａｃｋｕｐファイル４２との間のファイル間の整合性について説明する。本発明の一実施例においては、管理ファイル５６に登録された情報に基づいて、ノード管理サーバー５が、ＡＴＭ交換システム内に設定されたコネクション等の管理を行うことを想定している。それゆえ、管理ファイル５６とｂａｃｋｕｐファイル４２との間に整合が取れていない場合、例えば、管理ファイル５６に登録されているコネクションのうち、ハードウェアの設定が行われていないコネクションが存在する場合、ユーザが、管理ファイル５６に登録されたコネクションを用いてデータ通信を行おうとしても、前記コネクションに対してハードウェア設定は行われていないので、前記データ通信を行えない可能性がある。また、ｂａｃｋｕｐファイル４２に登録されているコネクションのうち、管理ファイル５６に登録されていないコネクションが存在する場合、ノード管理サーバー５が知り得ないコネクションが存在することとなり、セキュリティ上で考慮すべき点が生ずる可能性がある。従って、何らかの方法を用いて、管理ファイル５６の内容とｂａｃｋｕｐファイル４２の内容との間に整合性を取れば良いわけである。本発明の一実施例においては、定期的に、管理ファイル５６の情報を基に、ハードウェアの設定情報を作成し、前記作成したハードウェアの設定情報と、ｂａｃｋｕｐファイル４２の内容を比較することによって、前記管理ファイル５６とｂａｃｋｕｐファイル４２の内容の整合性を取ることを想定している。
【０２５７】
次に、管理ファイル５６とＮＩＳマスター・マップ６２０との間の、ファイル間の整合性について説明する。
【０２５８】
まず、本発明の一実施例においては、ユーザは、ＮＩＳを用いて、データ通信を行うためのＶＰＩ／ＶＣＩ値等を獲得することを想定しているので、ＮＩＳマスター・マップ６２０に登録されているコネクションのうち、管理ファイル５６に登録されていないコネクションが存在した場合で、前記コネクションを使って、ユーザがデータ通信を行おうとしても、前記データ通信を実行できない可能性がある。また、逆に、管理ファイル５６に登録されているコネクションのうち、ＮＩＳマスター・マップ６２０に登録されていないコネクションが存在した場合、ユーザがＮＩＳを使用しても、前記コネクションを使用するためのＶＰＩ／ＶＣＩ値等を獲得しえないため、ユーザは、前記コネクションを使用することができない。従って、そのような場合、何らかの方法を用いて、管理ファイル５６とＮＩＳマスター・マップ６２０の内容との間に、整合性を取らば良い。本発明の一実施例においては、定期的に、管理ファイル５６の情報を基に、ＮＩＳマスター・マップ６２０を作成し、前記作成したＮＩＳマスター・マップ６２０の内容と、既存のＮＩＳマスター・マップ６２０の内容を比較することによって、前記管理ファイル５６とＮＩＳマスター・マップ６２０の内容の整合性を取ることを想定している。
【０２５９】
最後に、ＮＩＳマスター・マップ６２０とＮＩＳスレーブ・マップ６２１ との間の、ファイル間の整合性について説明する。本発明の一実施例においては、ユーザは、ＮＩＳを用いて、データ通信を行うためのＶＰＩ／ＶＣＩ値等を獲得することを想定しているので、すべてのＮＩＳマップ６２間の整合性が取られていなければならない。従って、何らかの方法を用いて、管理ファイル５６とＮＩＳマスター・マップ６２０の内容との間に、整合を取らなければならない。本発明の一実施例においては、定期的に、管理ファイル５６の情報を基に、ＮＩＳマスター・マップ６２０を作成し、前記作成したＮＩＳマスター・マップ６２０の内容と、既存のＮＩＳマスター・マップ６２０の内容を比較することによって、前記管理ファイル５６とＮＩＳマスター・マップ６２０の内容との間に、整合性を取ることを想定している。
【０２６０】
１−７−６．統計情報の収集および統計情報に基づくコネクション制御
本発明の一実施例においては、ノード管理サーバー５が、ＡＴＭ交換システム内に設定されたコネクション等に関する情報を収集し、前記情報に基づいて、ＡＴＭ交換システム内に設定されたコネクション等の管理を行うことを想定している。また、ノード管理サーバー５が収集した統計情報等は、一端、管理ファイル５６に書き込まれ、前記管理ファイル５６に書き込まれた統計情報等を用いて、ノード管理サーバー５は、ＡＴＭ交換システム内のコネクション等の制御を行うことを想定している。
【０２６１】
まず、本発明の一実施例においては、前記したように、ハードウェア上のロジックに組み込まれた回路によって、収集されたＡＴＭ交換システム内に設定されたコネクションに関する統計情報は、一端、ノード設定サーバー４によって読み取られ、前記ノード設定サーバー４が管理するｂａｃｋｕｐファイル４２内に書き込まれる。従って、ノード管理サーバー５は、ノード設定サーバー４を通して、ｂａｃｋｕｐファイル４２をアクセスすることによって、前記ノード設定サーバー４が収集したハードウェアの統計情報をアクセスすることができる。ノード管理サーバー５がアクセスしたハードウェアの統計情報は、ノード管理サーバー５が管理する管理ファイル５６に収集される。
【０２６２】
ノード管理サーバー５は、前記したハードウェアの統計情報以外に、ノード管理サーバー５が送信するＯＡＭセル等によって得られた、統計情報に関しても収集を行う。すなわち、本発明の一実施例においては、上記（１−７−１） コネクションの接続確認、および上記（１−７−２） 端末または各種サーバーの生存確認の項で前記したように、ノード管理サーバー５は、接続確認用のＯＡＭセル等を送信し、前記ＯＡＭセル等がターゲット・ポイントでループバックされ、前記ＯＡＭセル等を、再び前記ノード管理サーバー５が受信することによって、コネクションの接続確認・端末（または、各種サーバー） の生存確認を行うことを想定している。また、ノード管理サーバー５は、前記ＯＡＭセル等を送信してから、前記ＯＡＭセル等を再び受信するまでの時間を測定し、前記測定した時間を基に、対象とするコネクションの輻輳状態、あるいは端末（または、各種サーバー） の負荷状態に関する統計情報を収集することができる。前記収集した統計情報は、ノード管理サーバー５によって、前記サーバーが管理する管理ファイル５６に収集される。
【０２６３】
次に、ノード管理サーバー５は、前記管理ファイル５６に収集された統計情報を基に、ＡＴＭ交換システム内に設定されたコネクションの制御等を行う。すなわち、障害等の原因により、ハードウェア・テーブル等の設定が破壊され、コネクションが切断された場合、管理ファイル５６に収集された統計情報によって前記不具合を検出し、ノード管理サーバー５が、前記統計情報を基にハードウェア・テーブル等の設定を修復することによって、前記不具合を解消することができる。ハードウェア・テーブル等の設定を修復するだけでは、前記不具合を解消することができない場合で、ルーティングを変更することによってコネクションのエンド・エンド間のデータ通信が実行できる場合、ノード管理サーバー５が、ハードウェア・テーブル等の設定を変更し、前記コネクションに対するルーティングを変更することによって、前記不具合を解消することができる。
【０２６４】
また、各種サーバーの負荷状態に関する統計情報を用いることによって、ノード管理サーバー５は、負荷の大きいサーバーに対して、前記サーバーのクライアントの一部を、負荷の小さいサーバーのクライアントに移すことによって、前記サーバーの負荷を軽減することができる。一方、ユーザに対しては、ユーザ側のプロセスであるクライアント・プロセスが帰属（ｂｉｎｄ）しているサーバーの負荷が大きい場合、前記クライアントがサーバーに対し要求を送信し、前記サーバーが前記クライアントに対するサービスを行うまでの応答時間が長くなる可能性がある。本発明の一実施例においては、ノード管理サーバー５が、前記した方法によって、各種サーバーの負荷状態を観測し、負荷の大きなサーバーのクライアントの一部を負荷の小さなサーバーに移すことによって、サーバーの負荷を軽減し、結果として、サーバーのクライアントに対する応答時間を短縮することができる。
【０２６５】
前記した方法は、網がアクションを起こすことによって、端末へのサービス応答を改善する方法であったが、端末がアクションを起こすことによっても、前記端末へのサービス応答を改善することができる。以下、端末がアクションを起こすことによって、端末へのサービス応答を改善する方法について説明する。
【０２６６】
端末上のクライアントは、サーバーの応答が遅くなった場合、まず、前記クライアントが、ノード管理サーバー５に対し、前記クライアントの帰属（ｂｉｎｄ）するサーバーの変更を要求する。ノード管理サーバー５は、前記要求を受信した場合、管理ファイル５６を参照し、前記クライアントの帰属（ｂｉｎｄ）するサーバーを、負荷の小さなサーバーに変更することによって対応する。具体的には、ノード管理サーバー５は、対応するハードウェア・テーブル等の設定を変更することによって、前記端末上のクライアントのサーバーに対して送信する要求が、前記変更後のサーバーにルーティングされるようにする。前記方法を採用することによって、端末上のクライアントは、サーバーが変更された場合でも、ＶＰＩ／ＶＣＩ値等を変更せずに、変更後のサーバーに対し要求を送信することができる。
【０２６７】
２．本発明に係るＶＰＩ／ＶＣＩ割り当てアルゴリズム
以下、ＶＰＩ／ＶＣＩ値の割り当てアルゴリズムについて、図面を参照しながら、具体的に説明する。
【０２６８】
２−１．ＶＰＩ／ＶＣＩ割り当てアルゴリズムの必要性と従来方法について まず、ＶＰＩ／ＶＣＩ割り当てアルゴリズムの必要性について簡単に説明する。ＡＴＭにおけるデータ通信の場合、データ転送路上に多重化された複数のコネクションは、ＶＰＩまたはＶＰＩ＋ＶＣＩで、個々のコネクションが識別される。従って、ＡＴＭにおけるデータ通信の場合、データ転送路上で個々のコネクションが識別できるように、ＶＰＩまたはＶＰＩ＋ＶＣＩを、個々のコネクションに割り当てなければならない。ここに、以下、ＶＰＩまたはＶＰＩ＋ＶＣＩを、対応するコネクションに割り当てることを、単に、ＶＰＩ／ＶＣＩの割り当てと呼こととする。
【０２６９】
ＡＴＭにおけるデータ通信の場合、一般的には、ＶＰＩ／ＶＣＩの割り当ては、以下に示すように、呼設定時に網によって行われる。すなわち、データ送信端末は、データ通信開始時に、網に対して、データ送信端末からデータ受信端末までのコネクションの設定（呼設定） を要求する。従来技術の節でも説明したように、網は、呼設定要求を受信した場合、データ送信端末が申告したトラヒック・パラメータを基に、データ送信端末からデータ受信端末までの、該データ送信端末が要求したＱＯＳを満たすコネクションが設定できるかどうか判定する。該コネクションが設定できる場合、網は、該コネクションを設定するとともに、該データ送信端末が該コネクションを使用するためのＶＰＩ／ＶＣＩ値を、該コネクションが多重化されるデータ転送路上の他のコネクションのＶＰＩ／ＶＣＩ値に重ならないように、該コネクションに割り当てを行う。最後に、網は、前記呼設定要求を送信したデータ送信端末に呼設定の終了を伝えるとともに、該コネクションに割り当てたＶＰＩ／ＶＣＩ値等の通知を行う。
【０２７０】
本発明の一実施例においては、ＶＰＩ／ＶＣＩの割り当ては、前記した呼設定時以外にも、以下に示す２つの場合にも網によって行われる。すなわち、本発明の一実施例においては、網の立ち上げ時に、網によって、メタシグナリング・コネクション以外にも、予め記述された設定ファイル（ｃｏｎｆｉｇファイル５５）の内容に従って、予め指定されたコネクションが設定されるが、前記コネクションの設定時にも、必要に応じてＶＰＩ／ＶＣＩの割り当てが行われる。同様に、本発明の一実施例においては、端末の立ち上げ時に、網によって、シグナリング・コネクション以外にも、予め記述された設定ファイル（ｃｏｎｆｉｇファイル５５）の内容に従って、予め指定されたコネクションが設定されるが、前記コネクションの設定時にも、必要に応じてＶＰＩ／ＶＣＩの割り当てが行われる。
【０２７１】
ここで、従来のＡＴＭにおいては、ＶＰＩ／ＶＣＩの割り当ては、網が呼設定要求を受信した際に、網が、データ送信端末からデータ受信端末までコネクションを設定し、該設定したコネクションにＶＰＩ／ＶＣＩ値を対応させる場合に、ＶＰＩ／ＶＣＩ割り当てアルゴリズムが実行される。
【０２７２】
ＩＴＵ−ＴＳ（旧ＣＣＩＴＴ）によるＡＴＭの標準化において、前記設定したコネクションに、ＶＰＩ／ＶＣＩ値を対応する方法として、コネクションを設定する度に、ＶＰＩ／ＶＣＩ値の番号の若い方から順にＶＰＩ／ＶＣＩ値を割り当てていくという方法が標準化の方法として勧告されている。従って、前記標準化された方法に従った場合、コネクションを設定するごとに、ＶＰＩ／ＶＣＩ値の小さい方から順に、割り当てられるＶＰＩ／ＶＣＩ値の最大の数までＶＰＩ／ＶＣＩ値を割り当てていく。割り当てられるＶＰＩ／ＶＣＩ値の最大の数までＶＰＩ／ＶＣＩ値を割り当ててしまった場合で、次にＶＰＩ／ＶＣＩ値を割り当てる場合は、最初に戻って、ＶＰＩ／ＶＣＩ値の小さい方から順に、使い終わったＶＰＩ／ＶＣＩ値がないかどうか検索し、使い終わったＶＰＩ／ＶＣＩ値がみつかった場合、該検索したＶＰＩ／ＶＣＩ値を小さい方から順に、コネクションに割り当てていくことになる。
【０２７３】
前記ＶＰＩ／ＶＣＩ値の割り当て手順において、ある時点で、あるＶＰＩ／ＶＣＩ値（ｎとする） まで割り当てた場合で、前記ＶＰＩ／ＶＣＩ値の割り当て終了後、ｎよりも小さいＶＰＩ／ＶＣＩ値（ｍとする） が割り当てられたコネクションの使用が終了した場合、次の時点で、設定したコネクションにＶＰＩ／ＶＣＩ値を割り当てる方法として、ｍを割り当てる方法と、ｎ＋１を割り当てる方法の２通りの方法が考えられる。
【０２７４】
しかし、ｍを割り当てる方法には、次のような短所がある。すなわち、一般に、データ通信には、データ通信し終わった端末に対し、再びデータ通信を行う確率が高いという特徴が存在するので、前記した例において、ある時点で、データ通信が終了したｍというＶＰＩ／ＶＣＩ値を持つコネクションは、近い将来、再び設定要求される確率が高いということになる。それゆえ、このｍを割り当てる方法を採用した場合、次の時点で設定されたコネクションに対し、ｍというＶＰＩ／ＶＣＩ値が割り当てられるので、次の時点で、他のデータ送信端末とデータ受信端末との間のコネクションが設定された場合、該コネクションにｍというＶＰＩ／ＶＣＩ値が割り当てられてしまい、同一のデータ送信端末とデータ受信端末との間のコネクションが再び設定される場合でも、該コネクションにｍという同一のＶＰＩ／ＶＣＩ値が割り当てられない場合があることになる。従って、前記した場合、同一のデータ送信端末とデータ受信端末との間のコネクションが、再び設定される場合でも、ＶＰＩ／ＶＣＩ割り当てアルゴリズムを再実行しなければならず、効率が悪い。
【０２７５】
一方、ＶＰＩ／ＶＣＩ値としてｎ＋１を割り当てる方法を採用した場合、ｍというＶＰＩ／ＶＣＩ値を持つコネクションが解放されても、次の時点で設定されるコネクションには、ｎ＋１というＶＰＩ／ＶＣＩ値が割り当てられるので、ｍというＶＰＩ／ＶＣＩ値が割り当てられていたコネクションに対し、近い将来、再び呼設定要求を網が受信した場合でも、ｍというＶＰＩ／ＶＣＩ値を割り当てることができる。
【０２７６】
以下、本発明の一実施例においては、ＶＰＩ／ＶＣＩ値の割り当て方法として、このｎ＋１を割り当てる方法を採用したものについて、図面を参照しながら具体的に説明する。
【０２７７】
図１８（ａ）は、本発明の一実施例におけるＶＰＩ／ＶＣＩの割り当て方法を行う場合の、ハード構成の一例を図示したものであり、図１８（ｂ）は、図１８（ａ）における管理プロセス５１のＶＰＩ／ＶＣＩ値割当機能に関する要部構成を示したものである。（本発明の一実施例においては、ＶＰＩ／ＶＣＩ割り当て処理をノード管理サーバー５で行うとしているが、呼設定サーバー７で行っても良い。）
本発明の一実施例においては、呼設定サーバー７とノード管理サーバー５との間は呼設定用チャネル１８で接続されており、ノード管理サーバー５は、呼設定用チャネル１８を通して、呼設定サーバー７からコネクション設定要求を受信するものとする。ノード管理サーバー５上の管理プロセス５１内に設けられた受信部５１１がコネクション設定要求を受信した場合、同ＶＰＩ／ＶＣＩ割当処理部５１２は、必要に応じて管理ファイル５６を参照し、設定を要求されたコネクションに対し、ＶＰＩ／ＶＣＩ値を割り当て、この割り当て結果を同送信部５１３によって呼設定サーバー７に送るものとする。また、該管理ファイル５６は複数のファイルから構成されるが、ＶＰＩ／ＶＣＩ値を割り当てるために用いるファイルとして、割り当てることのできるＶＰＩ／ＶＣＩ値等をリストしたファイルをＶＰＩ／ＶＣＩ−リスト・ファイル（以下、ＶＰＩ／ＶＣＩ−ｌｉｓｔファイルと記す）５６１とし、現時点から過去にさかのぼって、一番最後に割り当てられたＶＰＩ／ＶＣＩ値等を一時的に記憶するためのファイルをＶＰＩ／ＶＣＩ−ポインタ・ファイル（以下、ＶＰＩ／ＶＣＩ−ｐｏｉｎｔｅｒ ファイルと記す）５６２とする。従って、ノード管理サーバー５上の管理プロセス５１は、コネクション設定要求を受信した場合、まず、ＶＰＩ／ＶＣＩ−ｐｏｉｎｔｅｒ ファイル５６２を参照し、一番最近に割り当てたＶＰＩ／ＶＣＩ値（または、ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１に記述されたＶＰＩ／ＶＣＩリストの番号） を入手する。次に、該管理プロセス５１は、ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１を参照し、該一番最近に割り当てたＶＰＩ／ＶＣＩ値等を基準として、ファイルの後方へ（ファイルの最後まで検索し終わった場合は、ファイルの先頭に戻って、該ＶＰＩ／ＶＣＩ値等のリストまで） 、順々にＶＰＩ／ＶＣＩ値等のリストを検索し、割り当てることのできるＶＰＩ／ＶＣＩ値等を検索する。
【０２７８】
本発明の一実施例においては、ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１中の、最後に設定されたＶＰＩ／ＶＣＩ値のリストを示すポインタとして、ＶＰＩ／ＶＣＩ−ｐｏｉｎｔｅｒ ファイル５６２の使用を仮定しているが、必ずしもファイルを使用する必要はなく、リストを示すことのできるポインタであればよい。
【０２７９】
また、前記説明において、割り当てることのできるＶＰＩ／ＶＣＩ値とは、ＡＴＭ交換機の立ち上げ後、まだ一度もコネクションに割り当てられていないＶＰＩ／ＶＣＩ値、またはコネクションの接続が終了し、該コネクションに割り当てられていたＶＰＩ／ＶＣＩ値が、他のコネクションに割り当てることができるようになったＶＰＩ／ＶＣＩ値のことを意味するとする。新たにコネクションが設定され、該コネクションにＶＰＩ／ＶＣＩ値を割り当てる必要が生じた場合、網は、管理しているＶＰＩ／ＶＣＩ値のうち、現在、他のコネクションに割り当てられているＶＰＩ／ＶＣＩ値と、どのコネクションにも割り当てられていないＶＰＩ／ＶＣＩ値とを区別し、現在、どのコネクションにも割り当てられていないＶＰＩ／ＶＣＩ値の中から、適当なＶＰＩ／ＶＣＩ値を選択して、該選択したＶＰＩ／ＶＣＩ値を、該コネクションに割り当てなければならない。網が、現在、設定しているコネクションに割り当てているＶＰＩ／ＶＣＩ値と、どのコネクションにも割り当てていないＶＰＩ／ＶＣＩ値を区別する方法として、以下に示す２通りの方法が存在する。
【０２８０】
１つ目の方法は、前記ＶＰＩ／ＶＣＩ値のリスト中に、有効ビットというビットを設け、ノード管理サーバー５が、該有効ビットを制御することによって、該ＶＰＩ／ＶＣＩ値が割り当てられているか否かを区別する方法である。すなわち、ノード管理サーバー５が、設定するコネクションにＶＰＩ／ＶＣＩ値を割り当てた時点で、ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１の対応するＶＰＩ／ＶＣＩ値リストの有効ビットをセットし、該コネクションの接続が終了した時点で、ノード管理サーバー５は、該ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１の対応するＶＰＩ／ＶＣＩ値リストの有効ビットをリセットすることによって、該ＶＰＩ／ＶＣＩ値が、コネクションに割り当てられているか否かを識別する方法である。ノード管理サーバー５は、設定するコネクションに新たにＶＰＩ／ＶＣＩ値を割り当てる必要が生じた場合、該ノード管理サーバー５は、ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１を参照し、有効ビットがセットされていないＶＰＩ／ＶＣＩ値リストを検索し、検索したＶＰＩ／ＶＣＩ値のうち適当なＶＰＩ／ＶＣＩ値を選択し、該新たに設定するコネクションに割り当てを実行する。ただし、この方法によると、ノード管理サーバー５は、コネクションの接続が終了した時点で、該コネクションに割り当てられたＶＰＩ／ＶＣＩ値の解放を行わなければならず、何らかの原因でコネクションの接続が終了していたのに、該コネクションに割り当てられたＶＰＩ／ＶＣＩ値の解放を行わなかった場合、該ＶＰＩ／ＶＣＩ値は、以後使用することができなくなる可能性がある。
【０２８１】
一方、２つ目の方法は、前記ＶＰＩ／ＶＣＩ値のリスト中にライフタイムというフィールドを設け、ノード管理サーバー５は、該ライフタイムに記述された生存時間を基に、対応するＶＰＩ／ＶＣＩ値が、コネクションに割り当てられているか否かを判定する方法である。この方法では、上記のような可能性は生じない。なぜなら、ＶＰＩ／ＶＣＩ値のコネクションへの割り当て期間はライフタイムによって管理されるため、何らかの原因でコネクションの接続が終了しているのに、該コネクションに割り当てられたＶＰＩ／ＶＣＩ値の解放が永遠に行われないといったことがないからである。ただし、この方法は、コネクションの設定時に、該コネクションが使用される期間を予測して、該使用期間をライフタイムに設定するのであるが、ユーザが、前記ライフタイムに設定された期間を越えて、継続して前記コネクションを使用したくなった場合でも、該ライフタイムに設定された期間を越えて、該コネクションに割り当てられたＶＰＩ／ＶＣＩ値を使用できない可能性がある。しかし、このことは、ユーザが、ライフタイムに設定された期間を越えて、コネクションを使用したい場合、ノード管理サーバー５が、ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１の対応するＶＰＩ／ＶＣＩ値リストのライフタイムを、書き換えることによって、回避することができる。また、２つ目の方法に対し、該ＶＰＩ／ＶＣＩ値リストのライフタイムに設定された期間が終了する前に、該ＶＰＩ／ＶＣＩ値に対応するコネクションの接続が終了した場合、ノード管理サーバー５は、前記ＶＰＩ／ＶＣＩ値リストのライフタイムに設定されている期間を書き換えることによって、該ＶＰＩ／ＶＣＩ値のコネクションへの割り当て期間を、強制的に終了させることができる。
【０２８２】
以下、本発明の一実施例においては、２つ目の方法、すなわち、ＶＰＩ／ＶＣＩ値リストに設けられたライフタイムによって、該ＶＰＩ／ＶＣＩ値が、コネクションに割り当てられているか否かを、ノード管理サーバー５が識別する方法について、具体的に説明する。
【０２８３】
前記ライフタイムによって、対応するＶＰＩ／ＶＣＩ値が使用されているか否かを識別する方法には、ライフタイムとして、割り当ての継続時間を用いる方法と、割り当ての終了時刻を用いる方法の２通りの方法が存在し、以下、前記２通りの方法について、簡単に説明する。
【０２８４】
１番目の方法は、ライフタイムとして、該ＶＰＩ／ＶＣＩ値のコネクションへの割り当ての継続時間を用いる方法である。例えば、継続時間の単位として、秒を採用した場合、コネクションの設定時に、ノード管理サーバー５は、ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１中の対応するＶＰＩ／ＶＣＩ値リスト中のライフタイムに、指定された継続時間（例えば、６０秒間） を設定する。ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１中の、ライフタイムの項目に、“０”以外の数字が設定されている場合、該ライフタイムに設定されている数値が“０”になるまで、１秒毎に、デクリメントされる。ノード管理サーバー５は、新たにＶＰＩ／ＶＣＩ値をコネクションに割り当てる必要が生じた場合、ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１を参照して、ＶＰＩ／ＶＣＩ値リストのライフタイムが“０”のＶＰＩ／ＶＣＩ値を検索することによって、ある特定の時点で、コネクションに割り当てられていないＶＰＩ／ＶＣＩ値を検索することができる。
【０２８５】
２番目の方法は、ライフタイムとして、該ＶＰＩ／ＶＣＩ値のコネクションへの割り当ての終了時刻（あるいは、開始時刻および終了時刻、または開始時刻）を用いる方法である。例えば、現時刻が１９９３年６月２日１７時３０分００秒として、あるＶＰＩ／ＶＣＩ値をコネクションに１分間割り当てたい場合、ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１の対応するＶＰＩ／ＶＣＩ値リストのライフタイムに、１９９３年６月２日１７時３１分００秒を設定すればよい。ライフタイムの設定方法として、ある時刻（例えば、１９９０年１月１日００時００分００秒） を基準として、前記ある時刻からの経過時間を、現在の時刻として、ライフタイムの終了時刻を設定してもよい。ノード管理サーバー５は、新たにＶＰＩ／ＶＣＩ値をコネクションに割り当てる必要が生じた場合、図１８（ａ）で示される時計とＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１を参照して、ＶＰＩ／ＶＣＩ値リストのライフタイムによって示される時刻が、時計によって示される現時刻より前のＶＰＩ／ＶＣＩ値を検索することによって、現時点で、コネクションに割り当てられていないＶＰＩ／ＶＣＩ値を、検索することができる。また、ＰＶＣ（ｐｅｒｍａｎｅｎｔ ｖｉｒｔｕａｌ ｃｏｎｎｅｃｔｉｏｎ）の場合のような、固定的にコネクションを設定する場合に対しては、該コネクションに割り当てるＶＰＩ／ＶＣＩ値リストのライフタイムに、ライフタイムとして設定できる最大値を、該ライフタイムに設定することで、該ＶＰＩ／ＶＣＩ値を、他のコネクションに割り当てられないようにすることができる。
【０２８６】
以下、本発明の一実施例においては、ライフタイムとして、前記２番目の方法の、ＶＰＩ／ＶＣＩ値のコネクションへの割り当ての終了時刻を用いる方法を採用するとして、２つのＶＰＩ／ＶＣＩ割り当て方法について、具体的に説明する。
【０２８７】
２−２．ＶＰＩ／ＶＣＩ割り当てアルゴリズムについて（ 方法Ａ）
以下、本発明の一実施例におけるＶＰＩ／ＶＣＩ割り当て方法について、呼設定時を例として、具体的に説明する。なお、網の立ち上げ時と端末の起動時のＶＰＩ／ＶＣＩ割り当ても、呼設定時のＶＰＩ／ＶＣＩの割り当て方法と同様である。
【０２８８】
図１９は、方法Ａにおける、ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１とＶＰＩ／ＶＣＩ−ｐｏｉｎｔｅｒ ファイル５６２の構成を示した構成例であり、図２０および図２１は、方法ＡにおけるＶＰＩ／ＶＣＩ割り当てアルゴリズムの一例を示したものである。図１９において、ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１とは、少なくとも番号（Ｎｏ）、ＶＰＩ／ＶＣＩ値（ＶＰＩ／ＶＣＩ） 、およびライフタイム（ＬＩＦＥ）からなる複数のユーザーリスト（ｕｓｅｒ−ｌｉｓｔ ）から構成され、ＶＰＩ／ＶＣＩ−ｐｏｉｎｔｅｒ ファイル５６２とは、少なくとも前記ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１中の特定のユーザーリストの番号（Ｎｏ）を示すユーザーポインタ（ｕｓｅｒ−ｐｏｉｎｔｅｒ）から構成されるものとする。ここに、ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１、ＶＰＩ／ＶＣＩ−ｐｏｉｎｔｅｒ ファイル５６２として、番号（Ｎｏ）を用いずに、ＶＰＩ／ＶＣＩ−ｐｏｉｎｔｅｒ ファイル５６２として、ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１の先頭からのオフセットを用いることで、方法Ａの、ＶＰＩ／ＶＣＩ割り当てアルゴリズムを実行することができるが、本発明の一実施例においては、記述をわかりやすくするため、前記したＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１、ＶＰＩ／ＶＣＩ−ｐｏｉｎｔｅｒ ファイル５６２の構成を用いた。また、本発明の一実施例においては、ＶＰＩ／ＶＣＩ−ｐｏｉｎｔｅｒ ファイル５６２として、現時点から過去にさかのぼって、一番最近に設定されたＶＰＩ／ＶＣＩ値のポインタを含むとしているが、該一番最近に設定されたＶＰＩ／ＶＣＩ値のポインタの代わりに、該ＶＰＩ／ＶＣＩ値の次のＶＰＩ／ＶＣＩ値のポインタを含むとしてもよい。
【０２８９】
方法Ａにおいて、ノード管理サーバー５が、呼設定サーバー７からコネクション設定要求を受信した場合（図２０のステップ１２０）、該ノード管理サーバー５は、該コネクションが以前に設定されたことがあるかどうか、ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１を参照する（ステップ１２１）。該コネクションが以前に設定されたことがある場合、ノード管理サーバー５は、該以前設定されたコネクションに対し割り当てたＶＰＩ／ＶＣＩ値が、現時点で、他のコネクションに割り当てられていないかどうか、ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１を参照する（ステップ１２２）。該ＶＰＩ／ＶＣＩ値が、現時点で、他のコネクションに割り当てられていない場合、ノード管理サーバー５は、該ＶＰＩ／ＶＣＩ値を用いて、ユーザーが申告したトラヒック・パラメータで、ユーザが要求したＱＯＳを満たすコネクションが設定できるかどうか、コネクション設定処理を実行する（ステップ１２３）。
【０２９０】
一方、該コネクションが以前に設定されたことがない場合、または該ＶＰＩ／ＶＣＩ値が、現時点で、他のコネクションに割り当てられている場合、以下に示すＶＰＩ／ＶＣＩ割り当て処理を開始する（ステップ１２４）。まず、ノード管理サーバー５は、ＶＰＩ／ＶＣＩ−ｐｏｉｎｔｅｒ ファイル５６２を参照し、現時点から過去にさかのぼって、一番最近に設定されたＶＰＩ／ＶＣＩ値へのポインタ（番号（Ｎｏ））を獲得する。この獲得した番号を、［ＰｏｉｎｔＮｏ］とする（ステップ１２６）。次に、ノード管理サーバー５は、獲得した番号［ＰｏｉｎｔＮｏ］を基に、ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１を参照し、コネクションに割り当てることのできるＶＰＩ／ＶＣＩ値を検索する（ステップ１３３）。すなわち、ノード管理サーバー５は、ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１に記述されたユーザーリストのうち、［ＰｏｉｎｔＮｏ］で示される番号の次の番号のユーザーリストから、順々に、ユーザーリストを参照し、ユーザーリストのライフタイムに書かれた割り当て終了時刻と、ノード管理サーバー５が参照した時計の現時刻とを比較し、前記現時刻より前記終了時刻の方が前のユーザリストを検索する。
【０２９１】
参照したユーザーリストのライフタイムの終了時刻が、現時刻よりも前の場合、ノード管理サーバー５は、参照したユーザーリストに書かれたＶＰＩ／ＶＣＩ値を用いて、ユーザーが申告したトラヒック・パラメータで、ユーザが要求したＱＯＳを満たすコネクションが設定できるかどうか、コネクション設定処理を実行する（図２１のステップ１３４）。また、次回、ＶＰＩ／ＶＣＩ割り当て処理を行うために、ＶＰＩ／ＶＣＩ−ｐｏｉｎｔｅｒ ファイル５６２を更新する（ステップ１３５）。
【０２９２】
また、参照したユーザーリストのライフタイムの終了時刻が、現時刻よりも前でない場合、ノード管理サーバー５は、次のユーザーリストを参照する（ステップ１２７，１２８，１３０，１３３）。現時点で参照したユーザーリストが、ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１の最後のユーザーリストの場合、ノード管理サーバー５は、ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１の最初のユーザーリストを参照する（ステップ１２７，１２８，１２９，１３０，１３３）。また、ノード管理サーバー５が、ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１に含まれたユーザーリストを、一通り参照した結果、割り当てるＶＰＩ／ＶＣＩ値が検索できなかった場合（ステップ１３０，１３１）、ノード管理サーバー５は、呼設定サーバー７にコネクションが設定できない等の通知を行う（ステップ１３２）。
【０２９３】
２−３．ＶＰＩ／ＶＣＩ割り当てアルゴリズムについて（方法Ｂ）
以下、本発明の一実施例におけるＶＰＩ／ＶＣＩ割り当て方法として、ＶＰＩ／ＶＣＩ値リストの管理方法として、リンクド・リストを用いた方法について、具体的に説明する。なお、ＶＰＩ／ＶＣＩ割り当て方法のうち、方法Ａと同様の部分については、説明を省略する。
【０２９４】
図２２は、方法ＢにおけるＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１の構成例であり、図２３は、ＶＰＩ／ＶＣＩ−ｐｏｉｎｔｅｒ ファイル５６２の構成例であり、また、図２４，２５は、方法ＢにおけるＶＰＩ／ＶＣＩ割り当てアルゴリズムの一例を示したものである。図２２において、ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１とは、少なくとも番号（Ｎｏ）、次の番号（Ｎｅｘｔ）、ＶＰＩ／ＶＣＩ値（ＶＰＩ／ＶＣＩ） 、およびライフタイム（ＬＩＦＥ）からなる複数のユーザーリスト（ｕｓｅｒ−ｌｉｓｔ ）から構成されたユーザー毎に存在するユーザー・リンクドリスト（ｕｓｅｒ−ｌｉｎｋｅｄ−ｌｉｓｔ）と、現時点でコネクションに割り当てられていないＶＰＩ／ＶＣＩ値のリストであるフリーリスト（ｆｒｅｅ−ｌｉｓｔ ）から構成されたフリー・リンクドリスト（ｆｒｅｅ−ｌｉｎｋｅｄ−ｌｉｓｔ）とを有しているものとする。また、図２３において、ＶＰＩ／ＶＣＩ−ｐｏｉｎｔｅｒ ファイル５６２とは、ユーザー毎に存在し、少なくとも前記ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１中の最後に割り当てられたユーザーリストの番号（Ｎｏ）を示すユーザーポインタ（ｕｓｅｒ−ｐｏｉｎｔｅｒ）と、フリーリストの先頭を示すフリーポインタ（ｆｒｅｅ−ｐｏｉｎｔｅｒ）とから構成されるものとする。なお、本発明の一実施例においては、ＶＰＩ／ＶＣＩ−ｐｏｉｎｔｅｒ ファイル５６２として、現時点から過去にさかのぼって、一番最近に設定されたＶＰＩ／ＶＣＩ値の番号（Ｎｏ）を含むとしているが、該一番最近に設定されたＶＰＩ／ＶＣＩ値の番号（Ｎｏ）の代わりに、該ＶＰＩ／ＶＣＩ値の次のＶＰＩ／ＶＣＩ値の番号（Ｎｏ）を含むとしてもよい。
【０２９５】
以下、方法Ｂにおける、ＶＰＩ／ＶＣＩ割り当てアルゴリズムについて、方法Ａと異なる部分についてのみ、図２４，２５を参照しながら、具体的に説明する。
【０２９６】
呼設定サーバー７から設定を要求されたコネクションが、以前に設定したことがない場合（図２４のステップ１１３１）、または以前に設定したコネクションに使用したＶＰＩ／ＶＣＩ値が、現時点で他のコネクションに割り当てられている場合（ステップ１１３２）、ノード管理サーバー５は、以下に示すＶＰＩ／ＶＣＩ割り当て処理を開始する。
【０２９７】
まず、ノード管理サーバー５は、ＶＰＩ／ＶＣＩ−ｐｏｉｎｔｅｒ ファイル５６２を参照し、フリー・リンクドリストに含まれるフリーリストの個数を参照し、フリーリストの個数が“０”かどうか調べる（ステップ１１３５）。フリー・リンクドリストに含まれるフリーリストの個数が、“０”個でない場合、フリー・リンクドリストの先頭のフリーリストに書かれているＶＰＩ／ＶＣＩ値を、該設定要求されたコネクションに割り当てを行う（ステップ１１３８）。具体的には、ＶＰＩ／ＶＣＩ−ｐｏｉｎｔｅｒ ファイル５６２のフリーポインタに書かれたＶＰＩ／ＶＣＩ値を、該設定要求されたコネクションに割り当てるとして、ユーザーが申告するトラヒック・パラメータで、ユーザが要求するＱＯＳを満たすコネクションが設定できるかどうか、コネクション設定処理を実行する。
【０２９８】
また、次回、ＶＰＩ／ＶＣＩ割り当て処理を行うために、ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１と、ＶＰＩ／ＶＣＩ−ｐｏｉｎｔｅｒ ファイル５６２の更新を行う（ステップ１１４０，１４１）。すなわち、まず、ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１中に存在するユーザー・リンクドリストの更新を行うため、ユーザー・リンクドリストの最後に、該選択したフリーリストを加える。具体的には、ユーザー・ポインタで示されるＶＰＩ／ＶＣＩリストの［Ｎｅｘｔ］値を、該選択したフリーポインタで示されるＶＰＩ／ＶＣＩリストの［Ｎｅｘｔ］にコピーし、該選択したフリーポインタで示されるＶＰＩ／ＶＣＩリストの［Ｎｏ］値を、ユーザーポインタで示されるＶＰＩ／ＶＣＩリストの［Ｎｅｘｔ］にコピーする。次に、ＶＰＩ／ＶＣＩ−ｐｏｉｎｔｅｒ ファイル５６２中に存在するユーザーポインタの更新を行うため、フリーポインタを該ユーザーポインタにコピーする。具体的には、フリーポインタに書かれている［Ｎｏ］値を、ユーザーポインタの［Ｎｏ］にコピーし、ユーザーポインタに書かれている［ｔｏｔａｌ］値に１を加える。
【０２９９】
最後に、ＶＰＩ／ＶＣＩ−ｐｏｉｎｔｅｒ ファイル５６２中に存在するフリー・ポインタの更新を行うため、フリー・リンクドリストの先頭から２番目のフリーリストの内容を、フリーポインタにコピーする（ステップ１１４２）。具体的には、フリーポインタの ［Ｎｏ］ で示される、ＶＰＩ／ＶＣＩリストを参照し、次に、該ＶＰＩ／ＶＣＩリストに書かれている［Ｎｅｘｔ］番目のＶＰＩ／ＶＣＩリストを参照する。該ＶＰＩ／ＶＣＩリストに書かれている［Ｎｏ］値と［ＶＰＩ／ＶＣＩ］値を、フリーポインタの［Ｎｏ］と［ＶＰＩ／ＶＣＩ］にコピーする。
【０３００】
一方、フリー・リンクドリストに含まれるフリーリストの個数が、“０”個の場合、該設定要求されたコネクションに、割り当てるＶＰＩ／ＶＣＩ値が検索できなかったので、ノード管理サーバー５は、呼設定サーバー７にコネクションが設定できない等の通知を行う（図２４のステップ１１３６，１１３７）。
【０３０１】
方法ＢによるＶＰＩ／ＶＣＩ割り当て方法を採用した場合、ノード管理サーバー５は、何らかの方法を用いて、他のコネクションに割り当てることのできるＶＰＩ／ＶＣＩ値を獲得しなければならない。以下、前記他のコネクションに割り当てることのできるＶＰＩ／ＶＣＩリスト（フリーリスト） を獲得する方法について、図２６を参照しながら、具体的に説明する。
【０３０２】
ノード管理サーバー５は、定期的に、ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１を参照し、ユーザー・リンクドリストをたどって、該ユーザー・リンクドリストに含まれるＶＰＩ／ＶＣＩリスト（ユーザーリスト） を参照する（図２６のステップ１５４）。該参照したＶＰＩ／ＶＣＩリスト（ユーザーリスト） のライフタイムを参照し、定められた時間が経過したＶＰＩ／ＶＣＩリスト（ユーザーリスト） を検索することによって、他のコネクションに割り当てることのできるＶＰＩ／ＶＣＩリスト（フリーリスト） を獲得することができる。前記した方法等によって、他のコネクションに割り当てることのできるＶＰＩ／ＶＣＩリストを獲得した場合（ステップ１５５）、ノード管理サーバー５は、該獲得したＶＰＩ／ＶＣＩリスト （ユーザーリスト） を、フリーリストに加えるため、ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル５６１とＶＰＩ／ＶＣＩ−ｐｏｉｎｔｅｒ ファイル５６２の変更を行う（ステップ１５６）。
【０３０３】
３．サブネット内に複数のノードが存在する場合について
前述した（１） 節（本発明に係るネットワーク・システムの構成）の説明においては、サブネット（ サブネットワーク） が、１つの（スイッチ） ノードから構成される場合について、本発明のネットワーク・システムについて説明した。
【０３０４】
ここでは、サブネット内に複数の（スイッチ） ノードが存在する場合における、本発明のネットワーク・システムのうち、特に、サブネットが１つのノードから構成される場合からの変更部分について、具体的に説明する。また、上記（１） 節では、本発明のネットワーク・サーバーのうち、呼設定サーバーとネームサーバーは、サブネット内にそれぞれ１つずつ存在するというモデルで説明した。ここでは、前記呼設定サーバーとネームサーバーが、サブネット内にそれぞれ複数存在する場合、およびそれらが存在しない場合、すなわちサブネット内に４種類のサーバーのうちノード管理サーバーとノード設定サーバーしか存在しない場合について、具体的に説明する。なお、本発明のネットワーク・サーバーのうち、サブネット間のデータ通信に適用したものついては、次の（４） 節で説明する。
【０３０５】
以下、サブネット内に、ノードが複数存在する場合における、本発明のネットワーク・サーバーについて、以下の項目について具体的に説明する。
（３−１ ）サブネット内に複数のノード管理サーバーが存在する場合について
（３−２ ）サブネット内に複数のＮＩＳサーバーが存在する場合について
（３−３ ）サブネット内に複数の呼設定サーバーが存在する場合について
３−１．サブネット内に複数のノード管理サーバーが存在する場合について
先の（１） 節においては、サブネット内に存在する唯一のノード管理サーバーによって、サブネットに属する端末等の管理等を行うというモデルで、本発明のネットワーク・サーバーについて説明した。また、上記（１） 節においては、１つの（スイッチ） ノードに対して、１組のノード管理サーバーとノード設定サーバーを対応させるというモデルを用いて、本発明で提案するネットワーク・サーバーについて説明した。一方、サブネット内に複数の（スイッチ） ノードが存在する場合、前記したモデルを採用すると、１つのノードに対して１つのノード管理サーバーが必要であるので、前記した場合、サブネット内に複数のノード管理サーバーが存在することとなる。従って、上記（１） 節で説明した本発明のノード管理サーバーを、サブネット内に複数のノード管理サーバーが存在する場合にも適用するため、以下に述べる変更を加えるものとする。
【０３０６】
本発明のネットワーク・サーバーにおいては、サブネットが複数のノードから構成される場合に適用するため、ノード管理サーバーの動作モードとして、少なくとも、マスターモード（ｍａｓｔｅｒＭｏｄｅ）とスレーブモード（ｓｌａｖｅＭｏｄｅ ）の２種類の動作モードを想定する。従って、本発明のネットワーク・サーバーにおいては、サブネット内に、唯一存在するマスターモードのノード管理サーバーが、サブネットに属する端末等のすべてのネットワーク資源を管理し、その他のノード管理サーバーは、スレーブモードとして動作するものとし、前記マスターモードのノード管理サーバーの命令に従って動作するものとする。
【０３０７】
また、ノード管理サーバーの動作モードとして、マスターモードとスレーブモードの２種類の動作モードしか存在しない場合、以下に示すようなことが生じる可能性がある。一つは、ネットワークの立ち上げ時のような場合、サブネット内にスレーブモードのノード管理サーバーが複数存在していても、マスターモードのノード管理サーバーが立ち上がるまで、サブネットに属する端末に対してサービスすることはできない可能性があることである。他の一つは、ネットワークの通常運用中に、マスターモードのノード管理サーバーがダウンした場合、サブネット内にスレーブモードのノード管理サーバーが複数存在していても、前記マスターモードのノード管理サーバーが、行っていたネットワーク・サービスが停止してしまう可能性があることである。本発明のノード管理サーバーにおいては、ノード管理サーバーの動作モードとして、マスターモードとスレーブモードの他に、シングルモード（ｓｉｎｇｌｅＭｏｄｅ）を設けることによって、上記二つの可能性を回避するものである。すなわち、ネットワークの立ち上げ時、各々の（スイッチ） ノードに対し１つずつ存在するノード管理サーバーは、サブネット内に唯一存在するマスターモードのノード管理サーバーの起動を認識するまで、シングルモードのノード管理サーバーとして動作することによって、該ノード管理サーバーが対応するノードに接続している端末に対して、該ノード管理サーバーがネットワークのサービスを提供することとする。また、ネットワークの通常運用時に、マスターモードのノード管理サーバーのダウンを検出したスレーブモードのノード管理サーバーは、シングルモードのノード管理サーバーへ状態遷移することによって、該ノード管理サーバーが対応するノードに接続している端末に対して、該ノード管理サーバーが、ネットワークのサービスを提供することとする。
【０３０８】
以下、図２７を参照しながら、本発明におけるノード管理サーバーの３つの動作モードについて、具体的に説明する。
【０３０９】
本発明においては、サブネットに属する各々の（スイッチ） ノードに対して、それぞれ１組のノード設定サーバーとノード管理サーバーを対応させているが、ノード管理サーバーの動作モードとして、サブネットが１つのノードから構成されているとして動作するシングルモードと、サブネットが複数のノードから構成されているとして動作するマルチ・モードとを想定する。サブネットが複数のノードから構成されている場合、マルチ・モードは、さらに、サブネット内に唯一存在するマスターモードのノード管理サーバーと、その他のスレーブモードのノード管理サーバーの２種類のノード管理サーバーに分類することとする。
【０３１０】
シングルモード（ｓｉｎｇｌｅＭｏｄｅ）のノード管理サーバー５０１は、サブネットが、該ノード管理サーバーが対応する（スイッチ） ノードだけで構成されるとして、該ノードに接続している端末に対し、ネットワーク・サービスを提供する。すなわち、該ノード管理サーバーは、該ノードに接続している端末に対し、上記（１） 節で説明した該ノードに接続する端末間の呼設定サービスと、該ノード管理サーバーが管理する管理ファイルを用いたネーム・サービス等を提供する。
【０３１１】
マスターモード（ｍａｓｔｅｒＭｏｄｅ）５０３のノード管理サーバーは、サブネット内に唯一存在し、サブネットに属する端末に対して、上記（１）節で説明した該サブネットに属する端末間の呼設定サービスと、該ノード管理サーバーが管理する管理ファイルを用いたネーム・サービス等に加えて、サブネット外の端末との間の呼設定サービス等を提供する。また、マスターモードのノード管理サーバー５０３は、該マスターモードのノード管理サーバー５０３がダウンした場合、スレーブモードのノード管理サーバー５０２が、スムーズにシングルモードに移行できるように、該マスターモードのノード管理サーバー５０３が管理する管理情報を、スレーブモードのノード管理サーバー５０２に対し、定期的に転送してもよい。
【０３１２】
スレーブモード（ｓｌａｖｅＭｏｄｅ） ５０２のノード管理サーバーは、マスターモードのノード管理サーバー５０３に対して、定期的に、生存確認用のセルを送信し、該マスターモードのノード管理サーバー５０３が、該生存確認用のセルに対して応答を返すこと等によって、マスターモードのノード管理サーバー５０３の生存確認を実行する。該スレーブモードのノード管理サーバー５０２は、前記応答セルを受信できなかった等の場合、マスターモードのノード管理サーバー５０３がダウンしたと認識し、シングルモードへ動作モードを遷移する。該スレーブモードのノード管理サーバー５０２は、スムーズに、シングルモードへ状態遷移できるように、マスターモードのノード管理サーバー５０３の生存時、該マスターモードのノード管理サーバー５０３から転送される管理情報を基に、シングルモード動作時に必要なファイルを作成してもよい。なお、（スイッチ） ノードに対し割当てられたノード管理サーバーが、スレーブモードで動作している場合、該ノードに接続している端末の、ネットワーク・サービスの要求は、該スレーブモードのノード管理サーバー５０２をバイパスして、マスターモードのノード管理サーバー５０３に送信され、同様に、マスターモードのノード管理サーバー５０３の応答は、該スレーブモードのノード管理サーバー５０２をバイパスして、要求を送信した端末に返される。マスターモードのノード管理サーバー５０３は、また、スレーブモードのノード管理サーバー５０２を介して、ノード設定サーバーに、ルーティングタグ等のハードウェアの設定を要求してもよいし、該スレーブモードのノード管理サーバー５０２を介せずに、直接、ノード設定サーバーに要求してもよい。
【０３１３】
以下、本発明におけるノード管理サーバーの３つの動作モード間の状態遷移について、具体的に説明する。また、図２８および図２９に、本発明におけるノード管理サーバーの３つの動作モード間の状態遷移アルゴリズムの一部を示す。
【０３１４】
本発明におけるノード管理サーバーは、起動後（リセット後） 、動作モードがシングルモードに状態遷移するとする（図２８のステップ１６１）。
【０３１５】
リセット後、シングルモードで動作中のノード管理サーバーは、該ノード管理サーバーが管理するＡＴＭ交換機のすべての入出力線に対して、該入出力線の先に接続されるであろう端末と、該シングルモードのノード管理サーバー５０１との間に、ブート・チャネル１１とメタシグナリング・チャネル１０の設定を実行する（図２８のステップ１６２）。該設定の終了後、該シングルモードのノード管理サーバー５０１は、ｃｏｎｆｉｇファイル５５を参照する（ステップ１６３）。
【０３１６】
該ｃｏｎｆｉｇファイル５５に、“ｍａｓｔｅｒ”と記述されていた場合、該ｃｏｎｆｉｇファイル５５を参照したシングルモードのノード管理サーバー５０１は、速やかに、マスターモード５０３へと状態遷移するとする（ステップ１６４）。
【０３１７】
また、ｃｏｎｆｉｇファイル５５に“ｓｌａｖｅ ”と記述されていた場合、該ｃｏｎｆｉｇファイル５５を参照したシングルモードのノード管理サーバー５０１は、該シングルモードのノード管理サーバー５０１が管理するＡＴＭ交換機のすべての入出力線に対して、後述する構成認識アルゴリズムを実行し（図２９のステップ１６５〜１６８）、マスター・モ−ドのノード管理サーバー５０３から応答を受信した場合（ステップ１６８）、後述するタイミングで、スレーブモードのノード管理サーバー５０２に状態遷移するとする（ステップ１７５）。
【０３１８】
すなわち、マスターモードのノード管理サーバー５０３から応答を受信したシングルモードのノード管理サーバー５０１は、まず、シングルモードで動作中に得られた、該ノード管理サーバーが管理するＡＴＭ交換機に接続する端末等の管理情報等を、該マスターモードのノード管理サーバー５０３に転送する（ステップ１６９）。次に、該シングルモードのノード管理サーバー５０１は、該ノード管理サーバーが管理するＡＴＭ交換機に接続する端末に対して、シングルモードで動作中に設定した、該端末と該シングルモードのノード管理サーバー５０１との間の、ブート・チャネル１１とメタシグナリング・チャネル１０の設定を、該端末とマスターモードのノード管理サーバー５０３との間のチャネルとなるように、該ブート・チャネル１１とメタシグナリング・チャネル１０の設定を変更する（ステップ１７０〜１７４）。最後に、該シングルモードのノード管理サーバー５０１は、該シングルモードのノード管理サーバー５０１とマスターモードのノード管理サーバー５０３との間に、管理用チャネル１６の設定を行うとともに（図示せず）、動作モードをスレーブモードに状態遷移するとする（ステップ１７５）。
【０３１９】
ここに、図３０に、シングルモードのノード管理サーバー５０１の動作モードが、スレーブモード５０２に状態遷移する場合の、ブート・チャネル１１とメタシグナリング・チャネル１０の設定変更と、管理用チャネル１６の設定を示した模式図を示す。
【０３２０】
マスターモードのノード管理サーバー５０３から応答を受信しなかった場合、ある一定の期間後、後述する構成認識アルゴリズムを再度実行するとし、以後、マスターモードのノード管理サーバー５０３から応答を受信するまで、周期的に、後述する構成認識アルゴリズムを繰り返すとし、その間、該ノード管理サーバーは、シングルモード５０１で動作するとする。
【０３２１】
また、スレーブモードのノード管理サーバー５０２は、定期的に、マスターモードのノード管理サーバー５０３に対して、生存確認用のセルを送信し、該マスターモードのノード管理サーバー５０３が、該生存確認用のセルに対し、応答を返すこと等によって、マスターモードのノード管理サーバー５０３の生存確認を実行するとする。該スレーブモードのノード管理サーバー５０２は、前記応答セルを受信できなかった等の場合、マスターモードのノード管理サーバー５０３がダウンしたと認識し、該スレーブモードのノード管理サーバー５０２は、シングルモードへと動作モードを遷移させるとする。シングルモードに状態遷移したノード管理サーバー５０１は、周期的に、前記したマスターモードのノード管理サーバー５０３の生存確認方法、または後述する構成認識アルゴリズム等を繰り返し実行し、マスターモードのノード管理サーバー５０３の生存が確認された場合、再び、スレーブモードへと状態遷移するとする。
【０３２２】
また、スレーブモードのノード管理サーバー５０２に対して、“ｍａｓｔｅｒ命令 “を実行した場合、該スレーブモードのノード管理サーバー５０２は、マスターモードへと状態遷移するとする。同様に、マスターモードのノード管理サーバー５０３に対して、“ｓｌａｖｅ 命令“を実行した場合、該マスターモードのノード管理サーバー５０３は、スレーブモードへと状態遷移するとする。
【０３２３】
以下、図３０、および図３１〜３４を参照しながら、本発明におけるスレーブモード等のノード管理サーバーの構成認識アルゴリズムについて、具体的に説明する。
【０３２４】
図３１の方法Ａの構成認識アルゴリズムは、ブート用セルを用いた構成認識アルゴリズムである。
【０３２５】
方法Ａによる構成認識を行うノード管理サーバーは、対象とする入出力線のブート・チャネル１１に、特定フォーマットを持つブート用セルを送信し（図３１のステップ１８１）、該ブート用セルに対し、ノード管理サーバーから特定フォーマットを持つ応答セルを受信した場合（ステップ１８３）、該対象とする入出力線の先にノード管理サーバーの存在を認識する（ステップ１８６）、という方法である。また、該特定フォーマットを持つ応答セルに、“ｓｉｎｇｌｅＭｏｄｅ”と書かれていた場合、該応答セルを受信したノード管理サーバーは、該対象とする入出力線の先にシングルモードのノード管理サーバー５０１の存在を認識し、“ｍａｓｔｅｒＭｏｄｅ“と書かれていた場合、該対象とする入出力線の先にマスターモードのノード管理サーバー５０３の存在を認識してもよい。また、対象とする入出力線のブート・チャネル１１に、特定フォーマットを持つブート用セルを送信した（ステップ１８１）後、特定フォーマットを持つ応答セルを受信しなかった場合（ステップ１８２）、該構成認識を行うノード管理サーバーは、該対象とする入出力線の先にはノード管理サーバーは存在しないと認識する（ステップ１８５）。
【０３２６】
次に、図３２に示す前記特定フォーマットを持つブート用セルを受信したノード管理サーバーのアルゴリズムについて説明する。本発明においては、図３０に示すように、ブート・チャネル１１は、端末とシングルモードのノード管理サーバー５０１との間、または端末とマスターモードのノード管理サーバー５０３との間に設定されていて、端末とスレーブモードのノード管理サーバー５０２との間には設定されていない。従って、前記特定フォーマットを持つブート用セルを受信したシングルモードのノード管理サーバー５０１、またはマスターモードのノード管理サーバー５０３は、動作モードに従って、以下の処理を実行するとする。すなわち、動作モードがマスターモードの場合、該マスターモードのノード管理サーバー５０３が管理するｃｏｎｆｉｇファイル５５を参照し、該ブート用セルに対し、マスターモードと書き込んだ特定フォーマットの応答セルを作成し（図３２のステップ１９２）、該応答セルを、該ブート用セルが転送されてきた入出力線のブート・チャネル１１に転送する（ステップ１９３）。一方、動作モードがシングルモードの場合、必要に応じて該ブート用セルに対し、“ｓｉｎｇｌｅＭｏｄｅ”と書き込んだ特定フォーマットの応答セルを作成し（ステップ１９４）、作成した応答セルを、該ブート用セルが転送されてきた入出力線のブート・チャネル１１に転送する（ステップ１９５）。
【０３２７】
次に、図３３の方法Ｂの構成認識アルゴリズムは、メタシグナリング・セルを用いた構成認識アルゴリズムである。すなわち、メタシグナリング・セルを受信したノード管理サーバーは、該メタシグナリング・セルが転送されてきた入出力線に対して、シグナリング・チャネル１３を設定するとともに、該入出力線の先のユーザが、該シグナリング・チャネル１３を使用するためのＶＰＩ／ＶＣＩ値等を通知するため、応答セルを作成し、該作成した応答セルを、該メタシグナリング・セルが転送されてきた入出力線のメタシグナリング・チャネル１０に転送する（図３４のステップ２１１〜２１３）。該方法Ｂによる構成認識アルゴリズムは、ノード管理サーバーが、前記応答セルを受信することによって（図３３のステップ２０４）、対象とする入出力線の先にノード管理サーバーの存在を認識する（ステップ２０５）、方法である。なお、図３４に、メタシグナリング・セルを受信したノード管理サーバーのアルゴリズムについて示す。
【０３２８】
３−２．サブネット内に複数のＮＩＳサーバーが存在する場合について
本実施例は、ノード管理サーバー内にＮＩＳマスター・サーバーが存在し、サブネット内に複数のＮＩＳスレーブ・サーバーが存在するモデルでモデル化したものである。先の（１） 節では、サブネットが前記モデルの場合について説明した。本節では、まず、ノード管理サーバーは起動しているが、サブネット内にＮＩＳスレーブ・サーバーが起動していない場合について説明し、次に、サブネット内が前記した場合、またはサブネット内に複数のＮＩＳスレーブ・サーバーが存在する場合における、ＮＩＳスレーブ・サーバーの起動手順について説明する。
【０３２９】
図３５は、対象とするサブネットにおいて、ノード管理サーバーは起動しているが、ＮＩＳスレーブ・サーバー６０１は起動していない場合の、本発明における、ネットワーク・サーバーと端末との間のチャネル構成を示した模式図である。サブネット内に、ＮＩＳスレーブ・サーバー６０１が起動していない場合、端末３とノード管理サーバーとの間に、インフォメーション・チャネル１２が設定されるとする。端末上の、ＮＩＳクライアント・プロセスは、サブネット内のＮＩＳ情報にアクセスする必要が生じた場合、前記インフォメーション・チャネル１２を用いて、ノード管理サーバー内に存在するＮＩＳマスター・プロセス６００に、ＮＩＳ情報への要求を送信するものとする。ノード管理サーバー内のＮＩＳマスター・サーバー６００は、インフォメーション・チャネル１２を経由して、ＮＩＳ情報への要求を受信した場合、要求されたＮＩＳ情報を検索し、検索したＮＩＳ情報を、該インフォメーション・チャネル１２を経由して、前記要求を送信した端末上のＮＩＳクライアント・プロセスに、送信するものとする。
【０３３０】
サブネット内に、ＮＩＳスレーブ・サーバー６０１が存在しない場合、サブネット内に多数存在する端末上のＮＩＳクライアント・プロセスのＮＩＳ情報の要求は、すべて、ノード管理サーバー５内に存在するＮＩＳマスター・プロセス６００に転送されることになるので、該ノード管理サーバー５の負荷は大きい状態にある。
【０３３１】
図３６は、対象とするサブネット内において、ノード管理サーバーは起動しているがＮＩＳスレーブ・サーバー６０１は起動していない状態から、ＮＩＳスレーブ・サーバー６０１が起動した場合の、端末とノード管理サーバー５とＮＩＳスレーブ・サーバー６０１間のチャネルの設定変更の様子を示した模式図である。また、図３７および図３８は、前記した場合のノード管理サーバーのＮＩＳ（ スレーブ） サーバー起動時のアルゴリズムである。以下、図３６、図３７および図３８を参照しながら、前記した場合について具体的に説明する。
【０３３２】
ＮＩＳ（ スレーブ） サーバー６０１は、起動時に、ブート・チャネル１１を用いて、特定フォーマットを持ったブート用セルを、ノード管理サーバー５に転送する（図３７のステップ２２１）。
【０３３３】
ノード管理サーバー５は、前記ブート用セルを受信すると（ステップ２２３）、前記ブート用セルを基に、ｃｏｎｆｉｇファイル５５を参照し（ステップ２２４）、ＮＩＳ（ スレーブ） サーバー６０１が起動したことを認識する。前記ＮＩＳ（ スレーブ） サーバー６０１の起動を認識したノード管理サーバー５は、該ノード管理サーバー５と該ＮＩＳ（ スレーブ） サーバー６０１との間のＮＩＳ用チャネル１７の設定を対応するノード設定サーバー４に要求するとともに（ステップ２２６）、以下に示す処理を実行する。
【０３３４】
すなわち、ノード管理サーバー５は、管理ファイル５６を参照し、ノード管理サーバー５と端末３との間、またはＮＩＳスレーブ・サーバー６０１と端末３との間に設定されているすべてのインフォメーション・チャネル１２に対し、負荷が重いかどうか検査する（図３８のステップ２３１）。検査したインフォメーション・チャネル１２のうち、負荷が重いと判定したインフォメーション・チャネル１２に対しては、接続先のノード管理サーバー５、またはＮＩＳスレーブ・サーバー６０１を変更することによって（ステップ２３２〜２３８）、ＮＩＳサーバーの負荷分散を行うこととする。
【０３３５】
対象とするサブネットにおいて、ノード管理サーバ５ーは起動しているが、ＮＩＳスレーブ・サーバー６０１は起動していない状態から、図３６に示すようにＮＩＳスレーブ・サーバー６０１が起動した場合、端末３とノード管理サーバー５との間に設定されているすべてのインフォメーション・チャネル１２を、端末３と該ＮＩＳスレーブ・サーバー６０１との間のインフォメーション・チャネル１２となるように設定を変更すれば、ノード管理サーバー５の負荷を軽減することができる。
【０３３６】
また、ノード管理サーバー５は、定期的に、管理ファイル５６を参照し、設定されているすべてのインフォメーション・チャネル１２を検査し、負荷の重い（ 応答の遅い） インフォメーション・チャネル１２があるかどうか検査し、該当するインフォメーション・チャネル１２が存在した場合、接続先のＮＩＳサーバーの変更（インフォメーション・チャネル１２の設定変更） 等によって、ＮＩＳサーバーの負荷を分散することができる。
【０３３７】
該ノード管理サーバー５のインフォメーション・チャネル１２の設定変更において、該インフォメーション・チャネル１２を使用している端末に対して、該端末が、前記インフォメーション・チャネル１２を使用するためのＶＰＩ／ＶＣＩ値等を変更しなくてすむように、該インフォメーション・チャネル１２の設定変更を行うことが望ましい。あるいは、ＶＰＩ／ＶＣＩ値等を変更しなければならない場合、必要に応じて、ＶＰＩ／ＶＣＩ値等の割り当て処理を実行し、実行した結果得られたＶＰＩ／ＶＣＩ値等を用いて、前記インフォメーション・チャネル１２の設定変更を行い、設定変更の終了後、該インフォメーション・チャネル１２を使用する端末に対し、該インフォメーション・チャネル１２を使用するためのＶＰＩ／ＶＣＩ値等を通知してもよい。
【０３３８】
次に、図３９および図４０は、本発明における端末上のＮＩＳクライアント６１のＮＩＳサーバー（６００／６０１）への帰属（ｂｉｎｄ）時の、ノード管理サーバー等のアルゴリズムを示したものである。
【０３３９】
図３９および図４０によれば、端末の起動後、端末３上のＮＩＳクライアント６１がはじめてＮＩＳサーバーに帰属（ｂｉｎｄ）する場合（図３９のステップ２５０）、該端末３と帰属先のＮＩＳサーバーとの間のインフォメーション・チャネル１２の設定をノード管理サーバー５に要求するために、ブート・チャネル１１を用いて、特定のフォーマットを持ったブート用セルをノード管理サーバー５に送信する（ステップ２５２）。また、端末３上のＮＩＳクライアント６１は、設定されたインフォメーション・チャネル１２を用いて、ＮＩＳサーバーに、ＮＩＳ情報の要求を行うが、ＮＩＳ情報の要求に対して、ＮＩＳサーバーの負荷が重く、応答が返ってこなかった場合、すなわち応答がタイムアウトした場合（ステップ２５１）、端末３上のＮＩＳクライアント６１は、帰属先のＮＩＳサーバーを負荷のより小さなＮＩＳサーバーへ変更を要求するために、ブート・チャネル１１を用いて、特定のフォーマットを持ったブート用セルをノード管理サーバー５に送信する（ステップ２５２）。
【０３４０】
該特定のフォーマットを持ったブート用セルを受信したノード管理サーバー５は、管理ファイル５６等を参照し、負荷のより小さなＮＩＳサーバーを検索し （図４０のステップ２６４）、該ブート用セルを送信した端末と、該検索したＮＩＳサーバーとの間の、インフォメーション・チャネル１２の設定、またはインフォメーション・チャネル１２の設定変更を行うこととする（ステップ２６３）。前記インフォメーション・チャネル１２の設定、またはインフォメーション・チャネル１２の設定変更において、ＶＰＩ／ＶＣＩ値等の割り当て処理を実行しなければならない場合、必要に応じてＶＰＩ／ＶＣＩ値等の割り当て処理を実行することとする。
【０３４１】
ノード管理サーバー５は、前記インフォメーション・チャネル１２等の設定変更が終了した場合、管理ファイル５６を変更するとともに（ステップ２７３）、端末上のＮＩＳクライアント６１が、前記インフォメーション・チャネル１２を使用するためのＶＰＩ／ＶＣＩ値等の情報を該端末３に通知するために、ノード管理サーバー５は、ブート・チャネル１１を用いて前記情報を該端末３に転送する（ステップ２７４）。
【０３４２】
３−３．サブネット内に複数の呼設定サーバーが存在する場合について
前述した（３−２） 節とほぼ同様であるが、本発明においては、サブネット内に複数の呼設定サーバーが存在するというモデルでモデル化し、先の（１） 節では、サブネットが前記モデルで構成される場合について説明した。ここでは、まず、ノード管理サーバーは起動しているが、サブネット内の呼設定サーバーが起動していない場合について説明し、次に、サブネット内が前記した場合、またはサブネット内に複数の呼設定サーバーが存在する場合における呼設定サーバーの起動手順について説明する。
【０３４３】
図３５は、また、対象とするサブネットにおいて、ノード管理サーバー５は起動しているが、呼設定サーバー７は起動していない場合の、本発明におけるネットワーク・サーバーと端末との間のチャネル構成を示した模式図である。
【０３４４】
サブネット内に、呼設定サーバーが起動していない場合に、端末３からメタシグナリング・セルがノード管理サーバー５に送信されたとき、該端末３とノード管理サーバー５との間にシグナリング・チャネル１３が設定されるとする。端末３上の呼設定プロセスは、サブネット内の他の端末に対しコネクション型のデータ通信を行う必要の生じた場合、前記シグナリング・チャネル１３を用いて、ノード管理サーバー５内に存在する管理プロセス５１に呼設定要求を送信するものとする。ノード管理サーバー５内の管理プロセス５１は、シグナリング・チャネル１３を経由して、呼設定要求を受信した場合、要求されたコネクションを設定するとともに、該端末３が設定したコネクションを使用するためのＶＰＩ／ＶＣＩ値等の情報を、該シグナリング・チャネル１３を経由して、前記要求を送信した端末３に送信するものとする。
【０３４５】
サブネット内に、呼設定サーバーが存在しない場合、サブネット内に多数存在する端末の呼設定要求は、すべてノード管理サーバー５内に存在する管理プロセス５１に転送され、該管理プロセス５１が処理しなければならないので、該ノード管理サーバーの負荷は大きい状態にある。
【０３４６】
図３６は、また、対象とするサブネット内において、ノード管理サーバー５は起動しているが呼設定サーバー７は起動していない状態から、呼設定サーバー７が起動した場合の、端末３とノード管理サーバー５と呼設定サーバー７間のチャネルの設定変更の様子を示した模式図である。また、図４１および４２は、前記した場合のノード管理サーバー５の呼設定サーバー７起動時のアルゴリズムである。
【０３４７】
以下、図３６、図４１および４２を参照しながら、前記した場合について、具体的に説明する。
【０３４８】
呼設定サーバー７は、起動時に、ブート・チャネル１１を用いて、特定フォーマットを持ったブート用セルをノード管理サーバー５に転送する（図４１のステップ２９１）。
【０３４９】
前記ブート用セルを受信したノード管理サーバー５は、前記ブート用セルを基に、ｃｏｎｆｉｇファイル５５を参照し（ステップ３０１）、呼設定サーバー７が起動したことを認識する。前記呼設定サーバー７の起動を認識したノード管理サーバー５は、該ノード管理サーバー５と該呼設定サーバー７との間の、呼設定用チャネル１８の設定と、負荷のより小さなＮＩＳ（スレーブ／ マスター） サーバーと該呼設定サーバー７との間の、インフォメーション・チャネル１２の設定を、対応するノード設定サーバー４に要求する（ステップ３０３）。具体的には、以下に示す処理を実行する。
【０３５０】
ノード管理サーバー５は、管理ファイル５６を参照し（図４２のステップ３０７）、ノード管理サーバー５と端末３との間、またはすでに起動している呼設定サーバー７と端末３との間に設定されているすべてのシグナリング・チャネル１３に対し、負荷が重いかどうか検査する。検査したシグナリング・チャネル１３のうち、負荷が重いと判定したシグナリング・チャネル１３に対しては、接続先のノード管理サーバー５または呼設定サーバー７を変更することによって（ステップ３０８）、呼設定サーバー７の負荷分散を行うこととする。
【０３５１】
対象とするサブネットにおいて、ノード管理サーバー５は起動しているが呼設定サーバーは起動していない状態から、図３６に示すように呼設定サーバー７が起動した場合、端末３とノード管理サーバー５との間に設定されているすべてのシグナリング・チャネル１３を、端末と該呼設定サーバー７との間のシグナリング・チャネル１３となるように設定を変更すれば、ノード管理サーバーの負荷を軽減することができる。
【０３５２】
また、ノード管理サーバー５は、定期的に、管理ファイル５６を参照し（ステップ３０７）、設定されているすべてのシグナリング・チャネル１３を検査し、負荷の重い（応答の遅い） シグナリング・チャネル１３があるかどうか検査し、該当するシグナリング・チャネル１３が存在した場合、接続先の呼設定サーバー７の変更（シグナリング・チャネル１３の設定変更） 等によって、呼設定サーバー７の負荷を分散することができる。
【０３５３】
該ノード管理サーバー５のシグナリング・チャネル１３の設定変更において、該シグナリング・チャネル１３を使用している端末３に対して、該端末３が、前記シグナリング・チャネル１３を使用するためのＶＰＩ／ＶＣＩ値等を変更しなくてすむように、該シグナリング・チャネル１３の設定変更を行うことが望ましい。なお、ＶＰＩ／ＶＣＩ値等を変更しなければならない場合、必要に応じてＶＰＩ／ＶＣＩ値等の割り当て処理を実行し、実行した結果得られたＶＰＩ／ＶＣＩ値等を用いて、前記シグナリング・チャネル１３の設定変更を行い、設定変更の終了後、該シグナリング・チャネル１３を使用する端末に対し、該シグナリング・チャネル１３を使用するための、ＶＰＩ／ＶＣＩ値等を通知してもよい。
【０３５４】
また、一般的に、呼設定要求を受信した呼設定サーバーは、まず、ネットワーク情報を入手するため、サブネット内のＮＩＳサーバーにアクセスし、次に、得られたネットワーク情報を基に、対応するコネクションの設定をサブネット内のノード管理サーバーに要求するという２段階の処理を、本発明において想定している。図３６は、また、対象とするサブネットにおいて、ノード管理サーバー５と呼設定サーバー７とＮＩＳスレーブ・サーバー６０１が起動している場合、呼設定サーバー７が、前記した第１段階の処理を実行する方法として、該呼設定サーバー７とＮＩＳスレーブ・サーバー６０１との間に設定されているインフォメーション・チャネル１２を用いる方法について図示している。図３６以外の方法としては、呼設定サーバー７とノード管理サーバー５内の管理プロセス５１との間に設定されている呼設定用チャネル１８と、該管理プロセス５１とＮＩＳマスター・プロセス６００との間のプロセス間通信とを用いる方法が考えられる。すなわち、呼設定サーバー７が、前記した第１段階の処理を実行するため、該呼設定サーバー７とノード管理サーバー５内の管理プロセス５１との間に設定されている呼設定用チャネル１８を用いて、ＮＩＳ情報の要求を該管理プロセス５１に送信し、該ＮＩＳ情報の要求を受信した該管理プロセス５１は、プロセス間通信を用いて、該ＮＩＳ情報の要求をＮＩＳマスター・サーバー６００に送信する。ＮＩＳマスター・サーバー６００から、プロセス間通信によって、該ＮＩＳ情報の要求に対する応答を受信した管理プロセス５１は、該管理プロセス５１と呼設定サーバー７との間に設定されている呼設定用チャネル１８を用いて、該ＮＩＳ情報の応答を呼設定サーバー７に送信するといった方法も存在する。
【０３５５】
また、図３６では、対象とするサブネットにおいて、ノード管理サーバー５と呼設定サーバー７しか起動していない場合、前記した呼設定サーバー７の第１段階の処理を実行する方法として、呼設定サーバー７とノード管理サーバー５内の管理プロセス５１との間に設定されている呼設定用チャネル１８と、該管理プロセス５１とＮＩＳマスター・プロセス６００との間のプロセス間通信とを用いる方法を図示している。図３６以外の方法としては、呼設定サーバー７とノード管理サーバー５内のＮＩＳマスター・サーバー６００との間に、インフォメーション・チャネル１２を設定する方法も考えることができる。すなわち、呼設定サーバー７が、前記した第１段階の処理を実行するため、該呼設定サーバー７とノード管理サーバー５内のＮＩＳマスター・サーバー６００との間に設定されているインフォメーション・チャネル１２を用いて、ＮＩＳ情報の要求を該ＮＩＳマスター・サーバー６００に送信し、該ＮＩＳマスター・サーバー６００が、該インフォメーション・チャネル１２を用いて、該ＮＩＳ情報の要求に対する応答を該呼設定サーバー７に送信するといった方法である。
【０３５６】
次に、図４３および図４４は、本発明における端末３と呼設定サーバー７との間のシグナリング・チャネル１３の設定あるいは設定されたシグナリング・チャネル１３の変更時の、ノード管理サーバー等のアルゴリズムを示したものである。
【０３５７】
図４３および図４４によれば、端末の起動後、端末３上の呼設定プロセスが、該端末３と呼設定サーバー７との間のシグナリング・チャネル１３の設定をノード管理サーバー５に要求するために、メタシグナリング・チャネル１０を用いて、メタシグナリング・セルをノード管理サーバー５に送信する（図４３のステップ３３０）。また、端末上の呼設定プロセスは、設定されたシグナリング・チャネル１３を用いて、呼設定サーバーに呼設定要求を送信するが、該呼設定要求に対して呼設定サーバーの負荷が重く、応答が返ってこなかった場合、すなわち応答がタイムアウトした場合（ステップ３３１）、端末上の呼設定プロセスは、接続先の呼設定サーバー７を負荷のより小さな呼設定サーバー７へ変更を要求するために、メタシグナリング・チャネル１０を用いて、メタシグナリング・セルをノード管理サーバー５に送信しても良い（ステップ３３２）。
【０３５８】
該メタシグナリング・セルを受信したノード管理サーバー５は、管理ファイル５６等を参照し（図４４のステップ３４４）、負荷のより小さな呼設定サーバー７を検索し、該メタシグナリング・セルを送信した端末３と、該検索した呼設定サーバー７との間のシグナリング・チャネル１３の設定、またはシグナリング・チャネル１３の設定変更を行うこととする（ステップ３４９）。前記シグナリング・チャネル１３の設定、またはシグナリング・チャネル１３の設定変更において、ＶＰＩ／ＶＣＩ値等の割り当て処理を実行しなければならない場合、必要に応じてＶＰＩ／ＶＣＩ値等の割り当て処理を実行することとする（ステップ３４７）。
【０３５９】
ノード管理サーバー５は、前記シグナリング・チャネル１３等の設定変更が終了した場合、管理ファイル５６を変更するとともに（ステップ３５３）、該端末３が、前記シグナリング・チャネル１３を使用するための、ＶＰＩ／ＶＣＩ値等の情報を、該端末に通知するために、ノード管理サーバーは、メタシグナリング・チャネル１０を用いて、前記情報を該端末に転送することとする（ステップ３５４）。
【０３６０】
４．サブネット間のデータ通信について
本節では、本発明におけるサブネット間のデータ転送方法について、以下に示す項目に従って、順に説明を行う。
（４−１ ）サブネット間にまたがるネットワーク情報の管理方法について
（４−２ ）サブネット間にまたがるコネクションの設定方法について
（４−３ ）サブネット間にまたがるコネクションレス型データ転送方法について
以下、上記した項目に含まれないサブネット間にまたがる事項、例えばネットワーク起動時のノード管理サーバーのサブネットとサブネットの境界を認識する方法について、本発明の一実施例を、図３０、および図３１〜３４を参照しながら、具体的に説明する。
【０３６１】
図３０、および図３１〜３４は、同一サブネットに属するノード管理サーバーが、起動時にすでに起動しているサブネットのノード管理サーバーに帰属する方法について説明したものであった。前記した場合、新たに起動したノード管理サーバーは、まず、シングルモード５０１に状態遷移し、該ノード管理サーバーの管理対象の（スイッチ） ノードに接続する端末に対し、ノード管理サーバーとしてのサービスを提供しつつ、該ノード管理サーバーが帰属するサブネットのマスターモードのノード管理サーバー５０３に、該ノード管理サーバーの起動の通知を試みるという方法であった。前記したように、本発明の一実施例においては、マスターモードのノード管理サーバー５０３に、ノード管理サーバーの起動を通知する方法として、２つの手段と、２つの方法について説明した。すなわち、マスターモードのノード管理サーバー５０３に、ノード管理サーバーの起動を通知する手段として、該ノード管理サーバーが、起動時に、管理対象のＡＴＭ交換機（スイッチノード） に対し、該ＡＴＭ交換機のすべての入出力線の先に接続されるであろう端末と、該ノード管理サーバーとの間に設定するブート・チャネル１１とメタシグナリング・チャネル１０のうち、ブート・チャネル１１を手段として用いる方法と、メタシグナリング・チャネル１０を手段として用いる方法について説明した。
【０３６２】
また、ノード管理サーバーの起動をマスターモードのノード管理サーバー５０３に通知した後、該ノード管理サーバーが、シングルモードからスレーブモードへ状態遷移する方法として、シングルモードのノード管理サーバー５０１が自発的にスレーブモードへ状態遷移する方法と、マスターモードのノード管理サーバー５０３が、シングルモードのノード管理サーバー５０１に、スレーブモードへの状態遷移命令を送る方法の２とおりの方法が存在する。
【０３６３】
ここで、図３０（ａ）において、マスターモードのノード管理サーバー５０３と、シングルモードのノード管理サーバー５０１の属するサブネットが異なる場合について、以下、具体的に説明する。
【０３６４】
図３０（ａ）において、シングルモードのノード管理サーバー５０１は、該ノード管理サーバーの起動をマスターモードのノード管理サーバー５０３に通知するために、該ノード管理サーバーとＡＴＭ交換機の入出力線の先に設定されているブート・チャネル１１を用いて、ブート用セルを送信する。該ブート用セルを受信したマスターモードのノード管理サーバー５０３は、ｃｏｎｆｉｇファイル５５を参照し、該ブート用セルを送信した端末（シングルモードのノード管理サーバー５０１）に、該端末が起動するのに必要なブート・イメージを送信する。該ブート・イメージを受信したシングルモードのノード管理サーバー５０１は、該ブート・イメージに書かれたサブネットの名前と、該シングルモードのノード管理サーバー５０１のｃｏｎｆｉｇファイル５５に書かれているサブネットの名前とを比較し、両者が異なっている場合、該シングルモードのノード管理サーバー５０１は、該入出力線によって、他のサブネットに接続していることを認識することができる。また、他のサブネットに接続していることを認識した該シングルモードのノード管理サーバー５０１は、該入出力線のブート・チャネル１１を用いて、該ブート・イメージを送信したマスターモードのノード管理サーバー５０３に、他のサブネットに接続していることを通知してもよい。
【０３６５】
また、シングルモードのノード管理サーバー５０１は、該ノード管理サーバーの起動をマスターモードのノード管理サーバー５０３に通知するために、ブート用セルを送信する際に、該シングルモードのノード管理サーバー５０１が属するサブネットの名前を、該ブート用セルに書き込んで送信してもよい。前記した場合、該ブート用セルを受信したマスターモードのノード管理サーバー５０３は、受信したブート用セルに書かれているサブネットの名前と、該マスターモードのノード管理サーバー５０３のｃｏｎｆｉｇファイル５５に書かれている名前とを比較し、両者が異なっている場合、該マスターモードのノード管理サーバー５０３は、該入出力線で、異なるサブネットが接続されていることを認識することができる。該異なるサブネットが接続されていることを認識したマスターモードのノード管理サーバー５０３は、異なるサブネットに接続されていることを、該入出力線のブート・チャネル１１を用いて、該ブート用セルを送信したシングルモードのノード管理サーバー５０１に通知してもよい。
【０３６６】
また、マスターモードのノード管理サーバー５０３のｃｏｎｆｉｇファイル５５にサブネットとサブネットの境界の入出力線の名前（例えば、ＶＰＩ／ＶＣＩ値等） を書き込んでおくことによっても、マスターモードのノード管理サーバー５０３が、サブネットとサブネットの境界を認識することができる。本発明の一実施例においては、ブート用セルを受信したマスターモードのノード管理サーバー５０３が、該ブート用セルの転送されてきた入出力線を識別できるように、ＡＴＭ交換機において、該ブート用セルのＶＰＩ／ＶＣＩ値の変換を行うことも想定している。従って、マスターモードのノード管理サーバー５０３は、受信したブート用セルのＶＰＩ／ＶＣＩ値を基に、ｃｏｎｆｉｇファイル５５に書かれているサブネットとサブネットの境界のＶＰＩ／ＶＣＩ値と比較することによって、該ブート用セルを送信したシングルモードのノード管理サーバー５０１が、サブネット中のノード管理サーバーであるか、サブネット外のノード管理サーバーであるかを識別することができる。
【０３６７】
また、マスターモードのノード管理サーバー５０３は、サブネット外のシングルモードのノード管理サーバー５０１に対し、該サブネット外のシングルモードのノード管理サーバー５０１から送信されるブート用セルには応答せず、メタシグナリング・セルには応答することによって、該サブネット外のシングルモードのノード管理サーバー５０１に対し、該入出力線が、サブネットとサブネットの境界になっていることを通知することができる。すなわち、マスターモードのノード管理サーバー５０３は、該ノード管理サーバーのｃｏｎｆｉｇファイル５５に記載されたノード管理サーバー以外のノード管理サーバーから、ある入出力線を経由して、ブート用セルとメタシグナリング・セルを受信した場合、該ブート用セルに対しては何らアクションを行わず、該メタシグナリング・セルに対しては、該入出力線に対しシグナリング・チャネル１３を設定し、該シングルモードのノード管理サーバー５０１に、該シグナリング・チャネル１３の設定完了通知を送信する。シングルモードのノード管理サーバー５０１は、ある入出力線を経由して、シグナリング・チャネル１３等の設定完了通知は送られてきたが、ブート・イメージは送られてこなかった場合、“該入出力線の先に、マスターモードのノード管理サーバー５０３は存在するが、該シングルモードのノード管理サーバー５０１をブートするのに適切な情報（ブート・イメージ） を持ったマスターモードのノード管理サーバー５０３ではなかった“と認識することができる。つまり、該シングルモードのノード管理サーバー５０１は、該入出力線を経由して到達することのできるマスターモードのノード管理サーバー５０３は、該シングルモードのノード管理サーバー５０１が属するサブネットのマスターモードのノード管理サーバー５０３とは異なる他のサブネットのマスターモードのノード管理サーバー５０３と認識し、該入出力線が、サブネットとサブネットの境界であると認識することができる。
【０３６８】
以上は、マスターモード、スレーブモード、およびシングルモードという、３状態を遷移するモデルを、ノード管理サーバーに適用したものであった。以下、この状態遷移モデルを、ＮＩＳサーバーやＤＮＳサーバーといった一般のサーバーの状態遷移モデルに適用した場合について説明する。
【０３６９】
すなわち、システム全体が、複数のサーバーによって協調管理されるシステムにおいて、システム全体を複数の部分システムに分割し、各部分システムには、少なくとも１つのサーバーが割り当てられているものとする。各サーバーの動作モードとして、以下に説明するマスターモード、スレーブモード、およびシングルモードの３種類の動作モードが存在することとする。
【０３７０】
シングルモードで動作中のサーバーは、該サーバーに割り当てられた部分システム内の管理だけ行う。
【０３７１】
スレーブモードで動作中のサーバーの行う管理には、以下に示す２通りの場合が存在する。
【０３７２】
まず、１つの場合は、スレーブモードで動作中のサーバーは、マスターモードで動作中のサーバーの指示のみに従い、主体的に管理を行わないという場合である。
【０３７３】
他の場合は、スレーブモードで動作中のサーバーは、該サーバーに割り当てられた部分システム内の管理に対しては、主体的に行い、行った管理処理を必要に応じてマスターモードで動作中のサーバーに通知する。一方、該サーバーに割り当てられた部分システム外にまたがる管理に対しては、該スレーブモードで動作中のサーバーは、対応するマスターモードで動作中のサーバーに伺いを立て、該マスターモードで動作中のサーバーの指示に従うといった方法である。
【０３７４】
マスターモードで動作中のサーバーは、該サーバーに部分システムが割り当てられている場合は、該部分システムの管理を行うとともに、スレーブモードで動作中のサーバーから要求された部分システム間にまたがる管理を行い、関係する部分システムに割り当てられたスレーブモードで動作中のサーバーに、指示を送信する。
【０３７５】
以下、上記サーバーの状態遷移方法について説明する。
【０３７６】
サーバーは、起動後、まず、シングルモードに状態遷移する。起動手順に、該サーバーの起動後の動作モードがマスターモードと記述されていた場合は、該サーバーは、起動後、マスターモードへと状態遷移する。
【０３７７】
起動手順に、該サーバーの起動後の動作モードがスレーブモードと記述されていた場合は、該サーバーは、起動後、該サーバーが帰属するマスターモードのサーバーが、正常に動作しているか動作確認を行い、正常に動作していることが確認された場合は、スレーブモードへと状態遷移する。該サーバーが帰属するマスターモードのサーバーの正常動作が確認されなかった場合、以後、定期的に、該マスターモードのサーバーの正常動作が確認されるまで、シングルモードで動作する。該サーバーは、シングルモードで動作している間は、割り当てられた部分システムの管理のみを行い、該サーバーが帰属するマスターモードのサーバーの正常動作を確認した時点で、該サーバーがシングルモードで動作中に行った管理処理を、マスターモードのサーバーに通知し、スレーブモードへと状態遷移する。
【０３７８】
スレーブモードで動作中のサーバーは、定期的に、該サーバーが帰属するマスターモードのサーバーの動作確認を行い、該マスターモードのサーバーの正常動作が確認された場合は、スレーブモードで動作しつづける。該マスターモードのサーバーの正常動作が確認されなかった場合、該スレーブモードで動作していたサーバーは、シングルモードへと状態遷移する。該サーバーは、シングルモードで動作している間は、割り当てられた部分システムの管理のみを行い、該サーバーが帰属するマスターモードのサーバーの正常動作を確認した時点で、該サーバーがシングルモードで動作中に行った管理処理を、マスターモードのサーバーに通知し、スレーブモードへと状態遷移する。
【０３７９】
４−１．サブネット間にまたがるネットワーク情報の管理方法について
以下、図４５および図４６、ならびに図４７および図４８を参照しながら、本発明におけるノード管理サーバーのサブネット間にまたがるネットワーク情報の管理方法について、具体的に説明する。図４５〜４８では、サブネット間にまたがるネットワーク情報として、ノード管理サーバーが管理する管理ファイル５６を例にとって説明しているが、本発明を、例えばＮＩＳサーバーが管理するＮＩＳ情報にも適用することも可能である。
【０３８０】
サブネット間にまたがるネットワーク情報の管理方法として、大きく分類して、対象とするサブネットが該サブネットに属するネットワーク構成要素の情報のみ管理する方法と、該サブネットが該サブネットに属さないネットワーク構成要素の情報も管理する方法の２通りの方法が存在する。特に、サブネット間の関係が、ある１つのルート・ノード（ルート・サブネット） を起点としたツリー構造の場合、該ツリー構造に属する１つのサブネットが、該サブネットをルートとした部分ツリー構造に属するすべてのサブネットのネットワーク構成要素を管理する方法が一般的である。本発明の一実施例においては、あるサブネットが、該サブネットをルートとした部分ツリー構造に属するすべてのサブネットのネットワーク情報を管理する方法として、図４５に示す直接アクセス方法と、図４６に示す間接アクセス方法の２通りの方法を考慮する。
【０３８１】
直接アクセス方法とは、図４５において、あるサブネットに属するノード管理サーバーの管理ファイル５６には、該サブネットよりも下位のサブネットに属するノード管理サーバーの管理ファイル５６の情報も含まれるものとし、該サブネットの管理ファイル５６にアクセスすれば、該サブネットよりも下位のサブネットの管理ファイル５６の情報にもアクセスできるといった方法である。
【０３８２】
一方、間接アクセス方法とは、図４６において、あるサブネットに属するノード管理サーバーの管理ファイル５６には、該サブネットよりも下位のサブネットに属するノード管理サーバーの管理ファイル５６の情報の代わりに、該管理ファイル５６へのポインタが含まれるものとする。間接アクセス方法の場合、該サブネットの管理ファイル５６にアクセスした場合、該管理ファイル５６に含まれるポインタで示される、サブネットの管理ファイル５６にもアクセス要求が転送され、該アクセス要求が転送されたサブネットの管理ファイル５６に、対象とするネットワーク情報が存在した場合、そのネットワーク情報が、あたかも元のサブネットの管理ファイル５６にあったかのようにアクセスすることができるといった方法である。
【０３８３】
本発明の一実施例においては、サブネット間の構成は、あるサブネットをルート・ノードとしたツリー構造と、該ツリー構造内のあるノード（サブネット） と、該ノードをルートとした部分木には含まれないノードとをショート・カットして接続した構造とから構成されることとする。なお、以下の説明において、サブネット間の関係がツリー構造の場合、あるサブネットに対し、該サブネットの１つ上位のサブネットをペアレント・サブネット（以下、ｐａｒｅｎｔサブネットと記述する）と呼ぶこととし、該サブネットの１つ下位のサブネットをチャイルド・サブネット（以下、ｃｈｉｌｄ サブネットと記述する）と呼ぶこととする。また、あるサブネットとショート・カットして接続した同位のサブネットを、フレンド・サブネット（以下、ｆｒｉｅｎｄサブネットと記述する）と呼ぶこととする。
【０３８４】
また、本発明の一実施例においては、ネットワーク情報の検索方向として、対象とするサブネットの管理ファイル５６に、検索するネットワーク情報が見つからなかった場合、該サブネットの１つ上位のサブネット（ｐａｒｅｎｔ サブネット） のノード管理サーバーと、該サブネットと同位のサブネット（ｆｒｉｅｎｄ サブネット） のノード管理サーバーの２方向に検索の依頼を送信するものとする。該検索依頼を受信したｐａｒｅｎｔサブネットのノード管理サーバー５０４は、該ノード管理サーバーが管理する管理ファイル５６を参照し、該検索したいネットワーク情報がなければ、該検索依頼を、さらに、該ｐａｒｅｎｔサブネットの１つ上位のサブネットと、該ｐａｒｅｎｔサブネットと同位のサブネットへリレーイングすることとする。また、該検索依頼を受信したｆｒｉｅｎｄサブネットのノード管理サーバー５０６は、該ノード管理サーバーが管理する管理ファイル５６を参照し、該検索したいネットワーク情報が、該サブネット、または該サブネットをルートとする部分木に属するサブネットのノード管理サーバーの管理ファイル５６に存在するかどうか、検索を実行する。ｆｒｉｅｎｄサブネットのノード管理サーバー５０６は、管理ファイル５６を検索した結果、該検索依頼を受けたネットワーク情報が見つからなかった場合、該検索依頼を、他のサブネットへはリレーイングを行わないものとする。
【０３８５】
図４７および図４８は、本発明の一実施例における、直接アクセス方法と間接アクセス方法が混在した場合の、ネットワーク情報アクセス時のノード管理サーバーのアルゴリズムを図示したものである。図において、対象とするノード管理サーバーは、該ノード管理サーバーが属するサブネット内のクライアントと、ｃｈｉｌｄ サブネットまたはｆｒｉｅｎｄサブネットのノード管理サーバー（５０５／５０６）から、ネットワーク情報の検索要求を受信した場合（図４７のステップ３７０，図４８のステップ３９０）、まず、該対象とするノード管理サーバー自身の管理ファイル５６を検索するものとする（図４８のステップ３９２）。次に、該ノード管理サーバーは、ポインタで指されているノード管理サーバーへ、ネットワーク情報の検索要求を依頼するものとする（ステップ３９４）。
【０３８６】
以上説明した検索の結果、検索したいネットワーク情報が見つからなかった場合のうち、サブネット内のクライアントまたはｃｈｉｌｄ サブネットから検索要求を受信した場合、該ノード管理サーバーは、ｐａｒｅｎｔサブネットのノード管理サーバー５０４へ、より上位のサブネットが管理している管理ファイル５６でのネットワーク情報の検索要求を送信するとともに、ｆｒｉｅｎｄサブネットのノード管理サーバー５０６へ、該サブネットが管理している管理ファイル５６でのネットワーク情報の検索要求を送信する（ステップ３９６）。
【０３８７】
以上説明した検索の結果、検索したいネットワーク情報が見つかった場合、該対象とするノード管理サーバーは、該ネットワーク情報の検索を要求した該サブネット内のクライアント、ｃｈｉｌｄ サブネット、またはｆｒｉｅｎｄサブネットのノード管理サーバー（５０５／５０６）に対し、検索要求を受けたネットワーク情報を送信することとする。また、検索したいネットワーク情報が見つからなかった場合、該ノード管理サーバーは、該ネットワーク情報の検索を要求した該サブネット内のクライアント、ｃｈｉｌｄ サブネット、またはｆｒｉｅｎｄサブネットのノード管理サーバー（５０５／５０６）に対し、検索できなかったことを意味する検索ＮＧ通知を送信するか、または何等アクションを起こさないことによって、検索できなかったことを、通知することもできる。
【０３８８】
４−２．サブネット間にまたがるコネクションの設定方法について
以下、本発明の一実施例におけるサブネット間にまたがるコネクションの設定方法について、図面を参照しながら具体的に説明する。
【０３８９】
まず、本発明の一実施例においては、呼設定サーバー７が、端末から送信された呼設定要求（シグナリング・セル） を受信した場合、以下に示す（ａ） →（ｂ） →（ｃ） の手順で、該呼設定要求で要求された、宛先の端末３との間のコネクションを設定するものとし、以下、（ａ），（ｂ），（ｃ） の各々の項目について、具体的に説明する。
ａ）宛先の端末が所属するサブネットの特定
ｂ）該サブネットまでのルーティングの決定
ｃ）ハードウェアの設定要求の送信
まず、呼設定サーバー７が、呼設定要求（シグナリング・セル） を受信した場合、宛先の端末の所属するサブネットを特定するために、該呼設定サーバー７が所属するサブネットのノード管理サーバー５またはＮＩＳ（スレーブ） サーバー（６００／６０１）に、該宛先の端末が該サブネットに所属しているかどうか、ネットワーク情報の検索を要求する。宛先の端末が該サブネットに所属していなかった場合（該サブネットにおけるネットワーク情報の検索に失敗した場合） 、対象とするサブネットのｐａｒｅｎｔサブネットまたはｆｒｉｅｎｄサブネットに、該宛先の端末が所属しているかどうか調べるため、ネットワーク情報の検索を要求する。該ｐａｒｅｎｔサブネットまたは該ｆｒｉｅｎｄサブネットにおいて、ネットワーク情報の検索を実行した結果、検索したい情報が見つからなかった場合、該ｐａｒｅｎｔサブネットを基準として、該ｐａｒｅｎｔサブネットのｐａｒｅｎｔサブネットまたは該ｐａｒｅｎｔサブネットのｆｒｉｅｎｄサブネットに対して、宛先の端末が前記サブネットに所属しているかどうか調べるため、該ネットワーク情報の検索を要求する。以下、該ネットワーク情報が検索できるまで、順次、基準とするサブネットをツリー構造の上位に移動させていって、該ネットワーク情報の検索を実行するものとする。
【０３９０】
宛先の端末の所属するサブネットが特定できた場合、呼設定サーバー７は、次に、該サブネットまでのルーティングを決定するものとする。前記したように、本発明の一実施例においては、サブネット間の構成は、あるサブネットをルート・ノードとしたツリー構造、該ツリー構造に属するノード（サブネット） 、および該ノード（サブネット） をルートとした部分木には含まれないノード（サブネット） をショート・カットして接続した構造から構成されるとしている。従って、本発明の一実施例において、サブネット間にまたがるコネクションを設定する場合、前記したサブネット間の構成を用いて、効率よくコネクションを設定することとする。すなわち、サブネット間にまたがるコネクションを設定する場合、できるかぎり、サブネットとサブネット間をショート・カットしたコネクションを用いることによって、端末間に設定されるコネクションの中に含まれる（ スイッチ） ノードの個数を少なくし、該コネクションのエンド・エンド間の遅延を小さくすることを目標とする。なお、該ルーティングの決定において、呼設定サーバー７は、ユーザから申告された平均／ピーク使用帯域といったトラヒック・パラメータを基に、ユーザが要求するセル廃棄率／セル転送遅延といったＱＯＳを満たすコネクションが設定できるかどうか、ノード管理サーバー５に問い合わせ、該要求品質を満たすようなルーティングを決定するものとする。
【０３９１】
最後に、該決定されたルーティングに従って、該呼設定サーバー７は、該コネクションの設定を対応するノード管理サーバー５に要求することとする。該ノード管理サーバー５が対応するコネクションを正常に設定できた場合、該呼設定サーバー７は、呼設定要求を送信した端末に、該コネクションを使用するためのＶＰＩ／ＶＣＩ値等の情報を通知する。
【０３９２】
図４９、図５０、および図５１は、サブネット間にまたがるコネクションを設定するための、各々のサーバーと端末との間の、チャネル構成方法を示したものである。以下、図４９〜５１で図示した３つの構成方法について、具体的に説明する。
【０３９３】
図４９は、サブネット間の情報の通信を、サブネット間のノード管理サーバー５の間に設定された管理用チャネル１６を用いて行おうというものである。図４９の場合、端末から送信されたシグナリング・セルを受信した呼設定サーバー７は、対応するコネクションの設定を、該呼設定サーバー７の属するサブネットのノード管理サーバー５に依頼し、以後、該ノード管理サーバー５が、前記した手順で該コネクションの設定を行うという方法である。なお、図４９は、ノード管理サーバー５と呼設定サーバー７が、同一の端末上に存在しない場合について図示したが、ノード管理サーバー５と呼設定サーバー７が同一の端末上に存在する場合は、２つのサーバー間のデータ通信は、呼設定用チャネル１８の代わりに、プロセス間のデータ通信を使用してもよい。
【０３９４】
図５０は、サブネット間の情報の通信を、サブネット間の呼設定サーバー７の間に設定されているシグナリング・チャネル１３を用いて行おうというものである。本発明の一実施例においては、前記したように、ノード管理サーバー５の構成認識方法として、該ノード管理サーバー５が管理するＡＴＭ交換機のすべての入出力線に対し、ブート用セルとメタシグナリング・セルを送信する方法について説明した。図５０の呼設定サーバー７間のシグナリング・チャネル１３は、該ノード管理サーバー５が、ある入出力線に対して構成認識を行うため送信したメタシグナリング・セルに対し、シグナリング・チャネル１３が設定された場合、該ノード管理サーバー５は、該入出力線を介して他のサブネットに接続していると認識するとともに、該設定されたシグナリング・チャネル１３を、サブネット内の呼設定サーバー７に接続されるようにしたものである。なお、図４９と同様であるが、図５０は、ノード管理サーバー５と呼設定サーバー７が、同一の端末上に存在しない場合について図示しているが、ノード管理サーバー５と呼設定サーバー７が、同一の端末上に存在する場合は、２つのサーバー間のデータ通信は、呼設定用チャネル１８の代わりに、プロセス間のデータ通信を使用してもよい。
【０３９５】
図５１は、サブネット間の情報通信の方法は、図４９，５０とほぼ同様であるが、宛先の端末の所属するサブネットを検索するために、ネットワーク情報にアクセスする点が、図４９，５０とは異なる。すなわち、図５０の場合、宛先の端末の所属するサブネットを検索するために、呼設定サーバー７は、ネットワーク情報の検索をノード管理サーバー５に依頼する。該ネットワーク情報の検索要求を受信したノード管理サーバー５は、該ノード管理サーバー５が管理する管理ファイル５６、またはＮＩＳマスター・ファイル６２０等を検索するこにより、該要求されたネットワーク情報の検索を実行する。一方、図５１の場合、宛先の端末の所属するサブネットを検索するために、呼設定サーバー７は、ネットワーク情報の検索をＮＩＳ（スレーブ） サーバー６０１に依頼する点が、図４９，５０による方法と異なる。なお、図４９，５０と同様であるが、図５１は、ノード管理サーバー５と呼設定サーバー７とＮＩＳ（スレーブ） サーバー（６００／６０１）が、同一の端末上に存在しない場合について図示しているが、該３つのサーバーが、同一の端末上に存在する場合は、該３つのサーバー間のデータ通信は、対応するチャネルを使用する代わりに、プロセス間のデータ通信を使用してもよい。
【０３９６】
以下、図５２および図５３を参照しながら、図５１の場合の呼設定サーバー７のサブネット間にまたがるコネクションを設定する方法について、具体的に説明する。
【０３９７】
対象とする呼設定サーバー７が、端末３または他のサブネットの呼設定サーバー７からシグナリング・セルを受信した場合（図５２のステップ４２０）、該呼設定サーバー７は、まず、該シグナリング・セルで要求されているコネクションの宛先が、該呼設定サーバー７と同じサブネットに存在するかどうか、該サブネットが管理しているネットワーク情報の検索を行う（ステップ４２１）。具体的には、該呼設定サーバー７は、インフォメーション・チャネル１２を用いて、ＮＩＳ（スレーブ／マスター） サーバーに、該宛先の端末が該サブネット内に存在しているかどうか検索するため該端末のネットワーク情報の検索を依頼する。該端末のネットワーク情報の検索を依頼されたＮＩＳサーバーは、該ＮＩＳサーバーが管理するＮＩＳファイル等を参照し（ステップ４４１）、該宛先の端末等の情報が存在するかどうか検索し、該ネットワーク情報が検索できた場合、検索したネットワーク情報を、該検索要求を送信した呼設定サーバー７に送信する（ステップ４４２）。一方、該ネットワーク情報が検索できなかった場合、検索できなかった旨を、該呼設定サーバー７に通知する（検索ＮＧセルを送信する） 。
【０３９８】
呼設定サーバー７が、ＮＩＳサーバーから検索ＮＧセルを受信した場合、該宛先の端末が、該呼設定サーバー７と同一のサブネット内に存在しなかったと認識するとともに（ステップ４２５）、該呼設定サーバー７は、該呼設定サーバー７が所属するサブネットの１つ上位のサブネット（ｐａｒｅｎｔ サブネット） または同位のサブネット（ｆｒｉｅｎｄ サブネット） の呼設定サーバー７へ、該宛先の端末と、対象とする呼設定サーバー７が所属するサブネットまでのコネクションの設定を要求する（ステップ４２６）。具体的には、対象とする呼設定サーバー７が、端末またはｃｈｉｌｄ サブネットからシグナリング・セルを受信した場合、受信したシグナリング・セルで要求しているコネクションの設定区間を、宛先の端末と、該呼設定サーバー７が所属するサブネットと該１つ上位のサブネット（ｐａｒｅｎｔサブネット） の境界点（ＩＷＵｐとする；ＩＷＵ：ＩｎｔｅｒＷｏｒｋｉｎｇ Ｕｎｉｔ） との間に変更し、該変更したシグナリング・セルを、該呼設定サーバー７が所属するサブネットのすべてのｐａｒｅｎｔサブネットの呼設定サーバー７に送信する。同様に、該対象とする呼設定サーバー７が、端末または他のサブネット（ｃｈｉｌｄ サブネットとｆｒｉｅｎｄサブネット） からシグナリング・セルを受信した場合、受信したシグナリング・セルで要求しているコネクションの設定区間を、宛先の端末と、該呼設定サーバー７が所属するサブネットと該ｆｒｉｅｎｄサブネットの境界点（ＩＷＵｆとする） との間に変更し、該変更したシグナリング・セルを、該呼設定サーバー７が所属するサブネットのすべてのｆｒｉｅｎｄサブネットの呼設定サーバー７に送信する。
【０３９９】
該変更されたシグナリング・セルを受信した、ｐａｒｅｎｔサブネットの呼設定サーバー７は、該対象とする呼設定サーバー７と同様な処理を実行する。すなわち、宛先の端末が所属するサブネットに出会うまで、受信したシグナリング・セルを変更しつつ、該変更したシグナリング・セルを、上位方向（ｐａｒｅｎｔ方向） と同位方向（ｆｒｉｅｎｄ方向） のサブネットの呼設定サーバー７にリレーイングする。該宛先の端末の所属するサブネットを発見した場合、該宛先の端末とＩＷＵｐとの間のコネクションを設定するとともに、該コネクションを使用するためのＶＰＩ／ＶＣＩ値等を書き込んだ応答セルを、該ｐａｒｅｎｔサブネットの呼設定サーバー７は、対象とするサブネットの呼設定サーバー７へ送信する。一方、該宛先の所属するサブネットが発見できなかった場合、該ｐａｒｅｎｔサブネットの呼設定サーバー７は、対象とするサブネットの呼設定サーバー７へ、コネクションが設定できなかった旨を書き込んだ応答セルを送信する。
【０４００】
該変更されたシグナリング・セルを受信したｆｒｉｅｎｄサブネットの呼設定サーバー７は、該対象とする呼設定サーバー７と同様な処理を実行する。すなわち、宛先の端末が所属するサブネットに出会うまで、受信したシグナリング・セルを変更しつつ、該変更したシグナリング・セルを、同位方向（ｆｒｉｅｎｄ方向） の、サブネットの呼設定サーバー７にリレーイングする。該宛先の端末の所属するサブネットを発見した場合、該宛先の端末とＩＷＵｆとの間のコネクションを設定するとともに、該コネクションを使用するためのＶＰＩ／ＶＣＩ値等を書き込んだ応答セルを、該 ｆｒｉｅｎｄ サブネットの呼設定サーバー７は、対象とするサブネットの呼設定サーバー７へ送信する。一方、該宛先の所属するサブネットが発見できなかった場合、該ｐａｒｅｎｔサブネットの呼設定サーバー７は、対象とするサブネットの呼設定サーバー７へ、コネクションが設定できなかった旨を書き込んだ応答セルを送信する。
【０４０１】
対象とする呼設定サーバー７が、ＮＩＳサーバーからネットワーク情報の検索成功の通知を受けた場合、ｐａｒｅｎｔサブネットの呼設定サーバー７からコネクションの設定通知を受けた場合、またはｆｒｉｅｎｄサブネットの呼設定サーバー７からコネクションの設定通知を受けた場合、該呼設定サーバー７は、対応するコネクションの設定処理を実行する。具体的には、該呼設定サーバー７が、ＮＩＳサーバーからネットワーク情報の検索成功の通知を受けた場合、該呼設定サーバー７は、宛先の端末と、呼設定要求を送信した端末または他のサブネットとの境界点までのコネクションの設定要求を、サブネット内のノード管理サーバーに送信する（図５３のステップ４３１）。また、該呼設定サーバー７が、ｐａｒｅｎｔサブネットの呼設定サーバー７からコネクションの設定通知を受けた場合、該呼設定サーバー７は、ＩＷＵｐと、呼設定要求を送信した端末または他のサブネットとの境界点までのコネクションの設定要求を、サブネット内のノード管理サーバーに送信する。また、該呼設定サーバー７ が、ｆｒｉｅｎｄサブネットの呼設定サーバー７ からコネクションの設定通知を受けた場合、該呼設定サーバー７ は、ＩＷＵｆと、呼設定要求を送信した端末または他のサブネットとの境界点までのコネクションの設定要求を、サブネット内のノード管理サーバーに送信する（図５３のステップ４３１）。
【０４０２】
コネクションの設定要求を受信したノード管理サーバー５は、申告されたトラヒック・パラメータで、要求されたＱＯＳを満たすコネクションが設定できるかどうか、管理ファイル５６等を参照することによって判断する。あるいは、呼設定サーバー７が判断しても良い。該要求を満たすコネクションが設定できる場合、必要に応じてＶＰＩ／ＶＣＩ値等の割り当て処理を実行し、ノード設定サーバー４に、ハードウェアの設定要求を送信することによって、コネクションの設定を実行するとともに、該コネクションを使用するためのＶＰＩ／ＶＣＩ値等の情報を書き込んだ応答セルを作成し、該コネクションの設定要求を送信した呼設定サーバー７に、該応答セルを送信する。一方、該要求を満たすコネクションが設定できない場合、該ノード管理サーバーは、コネクションの設定ができない旨書き込んだ、応答セルを作成し、該コネクションの設定要求を送信した呼設定サーバー７に、該応答セルを送信する。
【０４０３】
該コネクションを使用するためのＶＰＩ／ＶＣＩ値等の情報を書き込んだ応答セルを該呼設定サーバー７が受信した場合、該呼設定サーバー７は、該コネクションの設定を要求した端末または他のサブネットの呼設定サーバー７に、コネクションの設定の完了と、該コネクションを使用するためのＶＰＩ／ＶＣＩ値等の情報を書き込んだ設定ＯＫセルを送信する。一方、該呼設定サーバー７が送信したシグナリング・セルに対し、すべてのｐａｒｅｎｔ／ｆｒｉｅｎｄ サブネットの呼設定サーバー７から要求するコネクションが設定できなかったと通知された場合、またはノード管理サーバーから要求したコネクションが設定できなかったと通知された場合、該呼設定サーバー７は、該コネクションの設定を要求した端末または他のサブネットの呼設定サーバー７に、コネクションが設定できなかったことを意味する設定ＮＧセルを送信する。
【０４０４】
４−３．サブネット間にまたがるコネクションレス型データ転送方法について
本発明の一実施例においては、以下に示す３つの方法によって、呼設定を行う手間が省けるという利点があるコネクションレス型のデータ転送方法を実現するものである。
（ａ）指定された端末間に、予め設定されたＱＯＳ（セル転送遅延、セル廃棄） を保証しないコネクションを用いる方法
（ｂ）ＣＬＳＦ（Ｃｏｎｎｅｃｔｉｏｎ−Ｌｅｓｓ Ｓｅｒｖｉｃｅ Ｆｕｎｃｔｉｏｎ）処理を用いたデータ転送方法
（ｃ）呼設定サーバーがＱＯＳの保証を必要としないコネクションを設定することによる、コネクションレス型のデータ転送のエミュレーション
すなわち、本発明の一実施例においては、宛先の端末まで予めコネクションが設定されている場合は、上記（ａ） の方法を用いてコネクションレス型のデータ転送を行うこととし、予めコネクションが設定されていない場合は、上記（ｂ） の方法を用いてコネクションレス型のデータ転送を行うこととする。また、上記（ａ） の方法と上記（ｂ） の方法を用いてはデータ転送を行えない端末間の場合、上記（ｃ） の方法を用いてコネクションレス型のデータ転送を行うこともできる。上記（ｃ） の方法を用いてコネクションレス型のデータ転送を行う場合、呼設定サーバー７が、宛先の端末までＱＯＳの保証を必要としないコネクションを設定するまでは、端末が送信したセルは、宛先の端末まで到達せず、途中で廃棄されることとなる。
【０４０５】
以下、本発明の一実施例における、ＣＬＳＦ処理を用いたコネクションレス型のデータ転送方法について、図５４、図５５を参照しながら、具体的に説明する。
【０４０６】
図５４は、本発明の一実施例におけるＣＬＳＦ処理を用いたコネクションレス型のデータ転送を行う場合の、端末３とＣＬＳＦ処理手段８とＮＩＳ（スレーブ） サーバー６０１との間のチャネル構成を示したものである。本発明の一実施例において、簡単のために、ＣＬＳＦ処理８を用いたコネクションレス型のデータ転送を行う場合、サブネット間の構成は、１つのサブネットをルート・ノードとしたツリー構造から構成されると考えることとする。ここに、ツリー構造以外の他のネットワーク構造の場合でも、本発明を適用することができるが、ここでは簡単のために、ツリー構造を考えることとする。また、該ツリー構造において、該ツリー構造中のあるノード（サブネット） は、ただ１つの上位のノード（サブネット） に接続することとし、また、該ツリー構造中のあるノード（サブネット） は、同位のノード（サブネット） には接続しないと考えることとする。ここで、実際のサブネット間の構成では、ツリー構造中のあるノード（サブネット） は、２つ以上の上位のノード（サブネット） または同位のノード（ サブネット） と接続しているかもしれないが、コネクションレス型のデータ転送を行う場合は、上記したようなサブネット間の構成モデルで考えるものとする。
【０４０７】
本発明においては、該サブネット間のツリー構造を用いて、サブネット間にまたがるコネクションレス型のデータ転送を、効率よく行うものとする。
【０４０８】
また、本発明の一実施例において、ＣＬＳＦ処理を用いたコネクションレス型のデータ転送を行う場合、サブネット内に少なくとも１つのＣＬＳＦ処理手段８が必要であり、予め、該サブネット内の端末のうち、コネクションレス型のデータ転送を行うすべての端末３と該ＣＬＳＦ処理手段８との間に、ＱＯＳの保証を必要としないＣＬ用チャネル１５を設定しておく必要がある。また、同一サブネット内のＣＬＳＦ処理手段８とＮＩＳ（スレーブ） サーバー６０１との間には、インフォメーション・チャネル１２が設定されているものとする。また、対象とするサブネット内のＣＬＳＦ処理手段８と、１つ上位のサブネット（ｐａｒｅｎｔサブネット） 内のＣＬＳＦ処理手段８との間に、ＣＬＳＦ間チャネル１９が設定されているものとする。なお、図５４は、ＣＬＳＦ処理手段８とＮＩＳサーバー６０１が、同一のネットワーク構成要素（端末） 上に存在しない場合について図示したものであるが、ＣＬＳＦ処理手段８とＮＩＳサーバー６０１が、同一のネットワーク構成要素（端末） 上に存在する場合は、２つのサーバー間のデータ通信は、インフォメーション・チャネル１２を使用する代わりに、プロセス間のデータ通信等を使用してもよい。
【０４０９】
さらに、本発明の一実施例においては、対象とするサブネット内の、ＣＬＳＦ処理手段８が起動した時点で、該ＣＬＳＦ処理手段８と、ｐａｒｅｎｔサブネット内のＣＬＳＦ処理手段８との間のＣＬＳＦ間チャネル１９と、該ＣＬＳＦ処理手段８と該サブネット内のＮＩＳ（スレーブ） サーバー６０１との間のインフォメーション・チャネル１２が、設定されるものとする。また、対象とするサブネット内の端末３が起動した時点で、該端末３と該サブネット内のＣＬＳＦ処理手段８との間のＣＬ用チャネル１５が設定されるものとする。
【０４１０】
図５５は、本発明の一実施例におけるＣＬＳＦ処理手段８のコネクションレス型のデータ転送のアルゴリズムを示したものである。以下、図５５を参照しながら、具体的に説明する。
【０４１１】
本発明の一実施例において、ＣＬＳＦ処理手段８がユーザセルを受信した場合、まず、ＣＬＳＦ処理手段８内のＶＰＩ／ＶＣＩキャッシュを参照し（ステップ４８０）、該ユーザセルの宛先の端末名が存在するかどうか、検索を実行する。ここに、ＶＰＩ／ＶＣＩキャッシュとは、本発明の一実施例においては、以前使用したＶＰＩ／ＶＣＩ値を記憶するための一時キャッシュとする。該ＶＰＩ／ＶＣＩキャッシュを参照した結果、該ユーザセルの宛先の端末名が検索できた場合、検索した結果得られたＶＰＩ／ＶＣＩ値を基に、ユーザセルのヘッダ変換（ＶＰＩ／ＶＣＩ値の書き換え） を行い、該ＣＬＳＦ処理手段８は、該ヘッダ変換を行ったユーザセルを送信する。ＣＬＳＦ処理手段８は、ヘッダ変換を行ったユーザセルを送信することによって、該ユーザセルの宛先が該サブネット内にある場合、対応するＣＬ用チャネル１５を用いて、該ユーザセルを宛先の端末３まで転送することができる（ステップ４８６，４８７）。また、該ユーザセルの宛先が該サブネット内にない場合、ＣＬＳＦ間チャネル１９を用いて、該ユーザセルを、１つ上位のサブネット（ｐａｒｅｎｔサブネット） のＣＬＳＦ処理手段８まで転送することができる（ステップ４８８，４８９）。
【０４１２】
一方、ＶＰＩ／ＶＣＩキャッシュを参照した結果、該ユーザセルの宛先の端末名が検索できなかった場合、該ＣＬＳＦ処理手段８は、インフォメーション・チャネル１２を用いて、該ユーザセルの宛先の端末のネットワーク情報の検索を、ＮＩＳ（スレーブ） サーバー６０１に要求する（ステップ４８１）。該ユーザセルの宛先の端末のネットワーク情報の検索要求を受信したＮＩＳ（スレーブ） サーバー６０１は、該ＮＩＳサーバーが管理するＮＩＳファイル等を参照し（ステップ５０１）、該端末のネットワーク情報が存在するかどうか、検索を行う。宛先の端末が該サブネット内に存在する場合、該端末のネットワーク情報は、該ＮＩＳファイル等を参照することによって検索することができるので、この場合、該ＮＩＳサーバー６０１は、ＮＩＳファイル等を検索することによって得られた宛先の端末３へＣＬ用チャネル１５を用いてコネクションレス型のデータ転送を行うためのＶＰＩ／ＶＣＩ値等を、該ＣＬＳＦ処理手段８に送信する（ステップ５０５）。一方、宛先の端末が、該サブネット内に存在しない場合、該端末のネットワーク情報は、該ＮＩＳファイル等を参照することによっては、検索することができないので、前記した場合、該ＮＩＳサーバー６０１は、検索の失敗を書き込んだ検索ＮＧセルを作成し、該ＣＬＳＦ処理手段８に送信する。
【０４１３】
該ＣＬＳＦ処理部８は、該ＮＩＳサーバー６０１から宛先の端末へＣＬ用チャネル１５を用いてコネクションレス型のデータ通信を行うためのＶＰＩ／ＶＣＩ値等の情報を送信された場合、該ＣＬＳＦ処理部８は、該ＶＰＩ／ＶＣＩを基に、ユーザセルのヘッダ変換（ＶＰＩ／ＶＣＩ値の書き換え） を行い、該ＣＬＳＦ処理部８は、該ヘッダ変換を行ったユーザセルを送信する（ステップ４８７）。また、該ＣＬＳＦ処理部８が、該ＮＩＳサーバーから検索ＮＧセルを受信した場合、該ＣＬＳＦ処理部８は、受信したユーザセルを、ＣＬＳＦ間チャネル２０を用いて、該サブネットの１つ上位のサブネット（ｐａｒｅｎｔサブネット） に転送する（ステップ４８９）。最後に、該ＣＬＳＦ処理部８は、ＮＩＳサーバーから送信されたネットワーク情報を、ＶＰＩ／ＶＣＩキャッシュに書き込むことによって（ステップ４９０）、以降の宛先の端末名からＶＰＩ／ＶＣＩ値への変換を、効率よく行えるようになる。
【０４１４】
【発明の効果】
本発明では、ネットワーク構成要素に関する情報をネットワーク情報検索装置に記憶させるとともに、端末と前記ネットワーク情報検索装置との間に予めチャネルを設定しておき、前記端末が、このチャネルを用いて、他の端末へのコネクションを設定するために必要な情報を前記ネットワーク情報検索装置から獲得するようにした。
【０４１５】
これによって、ネットワーク構成要素に関する情報を効率的に保持、管理できるとともに、予め前記チャネルを設定しているので、情報を獲得するのに要する時間を短縮できるという利点がある。
【０４１６】
また、本発明では、各端末と管理装置との間にそれぞれチャネルを設定しておき、前記管理装置が、これらのチャネルを用いて各端末に対し適当なタイミングで各端末の生存を確認するための信号を送信し、この信号に対する返答の有無により各端末が生存しているか否かを判断するようにした。
【０４１７】
これによって、管理装置は、各端末が生存を確認、把握することができるようになり、正常動作していない端末との間に呼を設定してしまうような不都合を排除することが可能となる。
【図面の簡単な説明】
【図１】本発明の一実施例に係るネットワーク・システムの要部概略構成を示す図
【図２】本発明の一実施例に係るノード管理サーバーによるシングル・モードの場合のブートについて説明するための図
【図３】ネットワーク・サーバーが同一の端末上にない場合の当該ネットワーク・サーバーのブートについて説明するための図
【図４】本発明の一実施例に係るＡＴＭ交換システムにおけるＶＰＩ／ＶＣＩテーブルを示す図
【図５】端末立ち上げ時のＶＰＩ／ＶＣＩテーブルについて説明するための図
【図６】本発明の一実施例に係るＡＴＭ交換システムにおけるＮＩＳマップの分配について説明するための図
【図７】本発明の一実施例に係るＡＴＭ交換システムにおけるＮＩＳのアクセス方法について説明するための図
【図８】本発明の一実施例に係るネットワーク情報のアクセス方法を示すフローチャート
【図９】図８のフローチャートの続きの部分を示すフローチャート
【図１０】本発明の一実施例に係るＮＩＳクライアントのＮＩＳサーバーへのｂｉｎｄ方法を示すフローチャート
【図１１】本発明の一実施例に係るＡＴＭ交換システムにおけるデータ転送方法について説明するための図
【図１２】本発明の一実施例に係るＡＴＭ交換システムにおけるデータ転送アルゴリズムの一例を示すフローチャート
【図１３】図１２のフローチャートの続きの部分を示すフローチャート
【図１４】本発明の一実施例に係るＡＴＭ交換システムにおけるデータ転送アルゴリズムの他の例を示すフローチャート
【図１５】図１４のフローチャートの続きの部分を示すフローチャート
【図１６】本発明の一実施例に係るＡＴＭ交換システムにおけるデータ転送アルゴリズムのさらに他の例を示すフローチャート
【図１７】図１６のフローチャートの続きの部分を示すフローチャート
【図１８】本発明におけるＶＰＩ／ＶＣＩ割り当て時のハードウェア構成を示す図
【図１９】本発明の一実施例に係るＶＰＩ／ＶＣＩ−ｌｉｓｔファイルおよびＶＰＩ／ＶＣＩ−ｐｏｉｎｔｅｒファイルの構成の一例を示す図
【図２０】本発明の一実施例に係るＶＰＩ／ＶＣＩ割り当て方法の一例を示すフローチャート
【図２１】図２０のフローチャートの続きの部分を示すフローチャート
【図２２】本発明の一実施例に係るＶＰＩ／ＶＣＩ−ｌｉｓｔファイルの構成の他の例を示す図
【図２３】本発明の一実施例に係るＶＰＩ／ＶＣＩ−ｐｏｉｎｔｅｒファイルの構成の他の例を示す図
【図２４】本発明の一実施例に係るＶＰＩ／ＶＣＩ割り当て方法の他の例を示すフローチャート
【図２５】図２４のフローチャートの続きの部分を示すフローチャート
【図２６】他のコネクションに割り当てることのできるＶＰＩ／ＶＣＩ値を獲得する方法を示すフローチャート
【図２７】本発明の一実施例に係るノード管理サーバーの状態遷移について説明するための図
【図２８】本発明の一実施例に係るノード管理サーバーの状態遷移アルゴリスズの一部を示すフローチャート
【図２９】図２８のフローチャートの続きの部分を示すフローチャート
【図３０】本発明の一実施例に係るノード管理サーバーの状態遷移を示した模式図
【図３１】本発明の一実施例に係るノード管理サーバーの構成認識アルゴリズムの一例を示すフローチャート
【図３２】特定フォーマットを持つブート用セルを受信したノード管理サーバーのアルゴリズムを示すフローチャート
【図３３】本発明の一実施例に係るノード管理サーバーの構成認識アルゴリズムの他の例を示すフローチャート
【図３４】メタシグナリング・セルを受信したノード管理サーバーのアルゴリズムを示すフローチャート
【図３５】本発明の一実施例に係る呼設定サーバー／ネームサーバーが起動していない場合のシステム構成を示す図
【図３６】本発明の一実施例に係る呼設定サーバーとネームサーバーの起動について説明するための図
【図３７】本発明の一実施例に係るノード管理サーバーのＮＩＳサーバー起動時のアルゴリズムを示すフローチャート
【図３８】図３７のフローチャートの続きの部分を示すフローチャート
【図３９】本発明の一実施例に係る端末上のＮＩＳクライアントのＮＩＳサーバー帰属アルゴリズムを示すフローチャート
【図４０】図３９のフローチャートの続きの部分を示すフローチャート
【図４１】本発明の一実施例に係るノード管理サーバーの呼設定サーバー起動時のアルゴリズムを示すフローチャート
【図４２】図４１のフローチャートの続きの部分を示すフローチャート
【図４３】本発明の一実施例に係る端末上の呼設定プロセスの呼設定サーバーへの接続アルゴリズムを示すフローチャート
【図４４】図４３のフローチャートの続きの部分を示すフローチャート
【図４５】本発明の一実施例に係るサブネット間にまたがるネットワーク情報の直接アクセス方法について説明するための図
【図４６】本発明の一実施例に係るサブネット間にまたがるネットワーク情報の間接アクセス方法について説明するための図
【図４７】本発明の一実施例に係るネットワーク情報アクセス時のノード管理サーバーのアルゴリズムを示すフローチャート
【図４８】図４７のフローチャートの続きの部分を示すフローチャート
【図４９】本発明の一実施例に係るサブネット間にまたがる呼設定を行うためのチャネル構成の一例を説明するための図
【図５０】本発明の一実施例に係るサブネット間にまたがる呼設定を行うためのチャネル構成の他の例を説明するための図
【図５１】本発明の一実施例に係るサブネット間にまたがる呼設定を行うためのチャネル構成のさらに他の例を示す図
【図５２】本発明の一実施例に係るサブネット間を考慮した呼設定サーバーのアルゴリズムを示すフローチャート
【図５３】図５２のフローチャートの続きの部分を示すフローチャート
【図５４】本発明の一実施例に係るサブネット間にまたがるコネクションレス型のデータ転送について説明するための図
【図５５】本発明の一実施例に係るＣＬＳＦ処理手段のデータ転送アルゴリズムを示すフローチャート
【図５６】従来のＡＴＭ交換システムの一例を示す図
【図５７】従来のＡＴＭ交換システムにおけるコピーコネクションの実現方法について説明するための図
【図５８】従来のＡＴＭ交換システムにおけるＣＬＳＦ処理手段によるコネクションレス・サービスの実現方法について説明するための図
【図５９】従来のコンピュータ間通信の一例を示す図
【図６０】従来のＩＰによるデータグラムの転送について説明するための図
【図６１】従来のＡＲＰについて説明するための図
【図６２】従来のＮＩＳについて説明するための図
【図６３】従来のネットワーク情報へのアクセス手順を示すフローチャート
【図６４】図６３のフローチャートの続きの部分を示すフローチャート
【図６５】従来のＮＩＳクライアントのＮＩＳサーバーへのｂｉｎｄ手順を示すフローチャート
【図６６】従来のディスクレス・クライアントのブートストラップについて説明するための図
【図６７】従来のブロードキャスト・アルゴリズムについて説明するための図
【符号の説明】
１０…メタシグナリング・チャネル
１１…ブート・チャネル
１２…インフォメーション・チャネル
１３…シグナリング・チャネル
１４…ユーザ・チャネル
１５…ＣＬ用チャネル
１６…管理用チャネル
１７…ＮＩＳ用チャネル
１８…呼設定用チャネル
１９…ＣＬＳＦ間チャネル
２…ＡＴＭ交換機
２１…前処理部
２２…共有メモリ型スイッチ
２３…後処理部
２４…ルーティングタグ・テーブル等のハードウェア・テーブル
３…端末（Ｈｏｓｔ）
３１…ホスト
３２…データレス・クライアント
３３…ディスクレス・クライアント
３４…端末ブート・プロセス
４…ノード設定サーバー
４１…設定プロセス
４２…ｂａｃｋｕｐファイル
５…ノード管理サーバー
５０１…ノード管理サーバー（シングルモード）
５０２…ノード管理サーバー（スレーブモード）
５０３…ノード管理サーバー（マスターモード）
５０４…ノード管理サーバー（ｐａｒｅｎｔ）
５０５…ノード管理サーバー（ｃｈｉｌｄ）
５０６…ノード管理サーバー（ｆｒｉｅｎｄ）
５１…管理プロセス
５２…ＡＴＭブート・プロセス
５３…端末ブート・プロセス
５４…端末メタシグナリング・プロセス
５５…ｃｏｎｆｉｇファイル
５６…管理ファイル
５１１…受信部
５１２…ＶＰＩ／ＶＣＩ割当処理部
５１３…送信部
５６１…ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル
５６２…ＶＰＩ／ＶＣＩ−ｐｏｉｎｔｅｒファイル
６…ＮＩＳサーバー
６００…ＮＩＳマスタ・サーバー（プロセス）
６０１…ＮＩＳスレーブ・サーバー（プロセス）
６１…ＮＩＳクライアント
６２…ＮＩＳマップ
６２０…ＮＩＳマスター・マップ
６２１…ＮＩＳスレーブ・マップ
６３…ＮＩＳファイル
７…呼設定サーバー（プロセス）

Claims (11)

  1. １つまたは複数の交換機、複数の端末、ならびに前記交換機および前記端末を含むネットワーク構成要素に関する情報を記憶しているネットワーク情報検索装置を備えてなるネットワークにおけるネットワーク管理方法であって、
    予め前記交換機に対し、各端末と前記ネットワーク情報検索装置との間にそれぞれ所定のユニキャスト・チャネルを設定しておくステップと、
    前記端末が、前記所定のユニキャスト・チャネルを用いて、他の端末へのコネクションを設定するために必要な情報を前記ネットワーク情報検索装置から獲得するステップとを有してなることを特徴とするネットワーク管理方法。
  2. 前記他の端末へのコネクションを設定するために必要な情報は、該他の端末の端末名、該他の端末アドレスまたは該他の端末へデータを送信するためのＶＰＩ／ＶＣＩ値であることを特徴とする請求項１に記載のネットワーク管理方法。
  3. 前記所定のチャネルは、前記ネットワークの立ち上げ時または前記端末の起動時に設定しておくことを特徴とする請求項１に記載のネットワーク管理方法。
  4. 前記所定のチャネルは、ブート・チャネルまたはインフォメーション・チャネルであることを特徴とする請求項１に記載のネットワーク管理方法。
  5. 予め前記交換機に対し、各端末と前記ネットワークに含まれる管理装置との間にそれぞれ所定のユニキャスト・チャネルを設定しておくステップと、
    前記管理装置が、前記所定のユニキャスト・チャネルをそれぞれ用いて各端末に対し適当なタイミングで生存を確認するための信号を送信するステップと、
    前記管理装置が、各端末に対してそれぞれ送信された前記信号に対する返答の有無により各端末が生存しているか否かを判断するステップとを更に有してなることを特徴とする請求項１に記載のネットワーク管理方法。
  6. 前記生存の確認では、前記管理装置から前記端末までのコネクションの接続を確認することを特徴とする請求項５に記載のネットワーク管理方法。
  7. 前記管理装置から前記端末へ該端末でループバックされるべき設定を施した接続確認用のＯＡＭセルを送信し、該端末でループバックされた該ＯＡＭセルを該管理装置が受信することによって、前記生存の確認を行うことを特徴とする請求項６に記載のネットワーク管理方法。
  8. 前記生存の確認では、前記管理装置から前記端末上のプロトコル・ソフトウェアまたはアプリケーション・ソフトウェアまでのコネクションの接続を確認することを特徴とする請求項５に記載のネットワーク管理方法。
  9. 前記端末上に実装されるプロトコル・ソフトウェアまたはアプリケーション・ソフトウェアに、特定のフォーマットを持つセルを受信した場合に、受信セルの宛先情報と送信元情報とを入れ替えたセルを送信するルーチンを設け、
    前記管理装置から前記端末へ前記特定のフォーマットを持つセルを送信し、前記ルーチンによって前記端末から返送された該セルを該管理装置が受信することによって、前記端末上のプロトコル・ソフトウェアまたはアプリケーション・ソフトウェアの生存の確認を行うことを特徴とする請求項８に記載のネットワーク管理方法。
  10. 前記所定のチャネルは、前記ネットワークの立ち上げ時に設定しておくことを特徴とする請求項５に記載のネットワーク管理方法。
  11. 前記所定のチャネルは、ブートチャネルまたはメタシグナリングチャネルであることを特徴とする請求項５に記載のネットワーク管理方法。
JP2001323957A 2001-10-22 2001-10-22 ネットワーク管理方法 Expired - Fee Related JP3583747B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2001323957A JP3583747B2 (ja) 2001-10-22 2001-10-22 ネットワーク管理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2001323957A JP3583747B2 (ja) 2001-10-22 2001-10-22 ネットワーク管理方法

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP25363993A Division JP3256610B2 (ja) 1993-09-17 1993-09-17 端末起動方法

Publications (2)

Publication Number Publication Date
JP2002185455A JP2002185455A (ja) 2002-06-28
JP3583747B2 true JP3583747B2 (ja) 2004-11-04

Family

ID=19140768

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2001323957A Expired - Fee Related JP3583747B2 (ja) 2001-10-22 2001-10-22 ネットワーク管理方法

Country Status (1)

Country Link
JP (1) JP3583747B2 (ja)

Also Published As

Publication number Publication date
JP2002185455A (ja) 2002-06-28

Similar Documents

Publication Publication Date Title
WO2021203623A1 (zh) 一种物联网资源接入系统及资源接入方法
JP4938687B2 (ja) ネットワークシステムおよび中継装置
US6134599A (en) System and method for organizing devices in a network into a tree using suitability values
JP5621778B2 (ja) コンテンツベーススイッチシステム、及びコンテンツベーススイッチ方法
US10419531B2 (en) Method for setting gateway device identity, and management gateway device
US7978631B1 (en) Method and apparatus for encoding and mapping of virtual addresses for clusters
US5600644A (en) Method and apparatus for interconnecting LANs
US6553014B1 (en) ATM communication system, process migration method in the ATM communication system, and handover processing method
US20060206611A1 (en) Method and system for managing programs with network address
US20150052252A1 (en) Method and system for optimizing a network by independently scaling control segments and data flow
JP2000261505A (ja) ネットワーク層ブリッジ
JP2002516042A (ja) 伝送ネットワークにおいてパケットの経路指定とスイッチングとの間をダイナミックにシフトする改良された方法及び装置
US9942108B2 (en) Network service aware routers, and applications thereof
Chiueh Supporting real-time traffic on Ethernet
JP3577025B2 (ja) サービス提供装置の動作方法
CN109951388B (zh) 路由不间断方法和主控板
EP1041794A2 (en) Network-device control apparatus and communication system
JP3583747B2 (ja) ネットワーク管理方法
US8964596B1 (en) Network service aware routers, and applications thereof
JP3256610B2 (ja) 端末起動方法
KR100333679B1 (ko) 멀티캐스트 통신 서비스 제공 시스템 및 멀티캐스트 서비스제어방법
Cisco 11.2(1)P Caveats/11.2(3)P Modifications
Cisco 11.2(1)P Caveats/11.2(3)P Modifications
Cisco Cisco IOS Software Release 11.2, 11.2P and 11.2BC Caveats
Cisco 11.2BC Caveats

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20040220

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20040323

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20040524

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20040727

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20040729

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20070806

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20080806

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20090806

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20090806

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100806

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100806

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110806

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110806

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120806

Year of fee payment: 8

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120806

Year of fee payment: 8

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130806

Year of fee payment: 9

LAPS Cancellation because of no payment of annual fees