JP2002199001A - サービス提供装置の動作方法 - Google Patents

サービス提供装置の動作方法

Info

Publication number
JP2002199001A
JP2002199001A JP2001323958A JP2001323958A JP2002199001A JP 2002199001 A JP2002199001 A JP 2002199001A JP 2001323958 A JP2001323958 A JP 2001323958A JP 2001323958 A JP2001323958 A JP 2001323958A JP 2002199001 A JP2002199001 A JP 2002199001A
Authority
JP
Japan
Prior art keywords
server
terminal
nis
management server
connection
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.)
Granted
Application number
JP2001323958A
Other languages
English (en)
Other versions
JP3577025B2 (ja
Inventor
Yoshiyuki Tsuda
悦幸 津田
Hiroshi Ezaki
浩 江崎
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 JP2001323958A priority Critical patent/JP3577025B2/ja
Publication of JP2002199001A publication Critical patent/JP2002199001A/ja
Application granted granted Critical
Publication of JP3577025B2 publication Critical patent/JP3577025B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

(57)【要約】 【課題】 マスターモードで動作するサービス提供装置
が動作停止しても、ネットワーク全体の機能停止を回避
できる動作方法を提供すること。 【解決手段】 マスターモードのサービス提供装置が正
常に動作しなくなった場合、スレーブモードの装置は、
シングルモードへと状態遷移し、該装置に割り当てられ
た部分システムに対し、該シングルモードの装置が、サ
ービスを提供する。従来のモードが固定されていたマス
ター／スレーブ・システムと異なり、マスターモードの
装置が正常に動作しなくなった場合、該システムに対し
て、サービスの提供が停止してしまうといった不具合を
回避することができる。

Description

【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、非同期伝送モード
にて情報の交換を行うＡＴＭ交換システムに係わり、特
に、ＡＴＭ交換システムにおいて、従来のコンピュータ
間のデータ通信と、ＡＴＭ端末間のデータ通信を、効果
的に行うようにした、ＡＴＭ交換システムのシステム構
成方法に関する。
【０００２】
【従来の技術】ＡＴＭ交換システムでは、有意情報のみ
セルと呼ばれる５３バイト固定長のパケットに載せてデ
ータ通信を行うので、単位時間当たり有意情報量が大き
く変動するマルチメディア環境下でも、複数ユーザによ
る交換資源の共有化が可能となる。この複数ユーザによ
る交換資源の共有化によるコストダウンの可能性のた
め、ＡＴＭ交換技術は、Ｂ−ＩＳＤＮを実現する唯一の
解として、現在、研究・開発が活発に行われている。
【０００３】従来のＡＴＭ交換システムは、電話網のシ
ステム構成方法を基に構成されているので、後述するよ
うに電話等のデータ通信には適しているが、従来から行
われているコンピュータ間のデータ通信に対しては必ず
しも適していない。
【０００４】以下、（１）従来のＡＴＭ交換システムで
のデータ通信方法、とともに（２）イーサネット（登録
商標）ＬＡＮ（Ｅｔｈｅｒｎｅｔ（登録商標）−ＬＡ
Ｎ）におけるコンピュータ間のデータ通信、に関して、
図を参照しながら具体的に説明する。
【０００５】１）従来のＡＴＭ交換システムでのデータ
通信方法について 図５６（ａ）に従来のＡＴＭ交換システムの一例を、図
５６（ｂ）〜（ｄ）にＡＴＭ交換システムで用いられる
セル・フォーマットを示す。（ｂ）は（ａ）のＡＴＭ交
換機８０２に入力されるセルのフォーマットであり、
（ｃ）はＡＴＭ交換機８０２内におけるセルのフォーマ
ットであり、（ｄ）はＡＴＭ交換機８０２から出力され
るセルのフォーマットである。
【０００６】図５６（ａ）に示すような従来のＡＴＭ交
換システムでは、ＡＴＭ交換機８０２に入力されたセル
のヘッダに含まれるＶＰＩ（Virtual Path Identifier
）およびＶＣＩ（Virtual Channel Identifier）と呼
ばれる領域が参照され、ＡＴＭ交換機８０２内にあるル
ーティングタグ・テーブル（図示せず）に予め設定され
たルーティング情報を基にルーティングされるので、デ
ータ送信端末８０３のセル転送に先だって、前記ルーテ
ィング情報が設定されていなければならない。また、前
記したように、従来のＡＴＭ交換システムは複数ユーザ
による交換資源の共有化によってコストダウンを図ろう
としているが、網がユーザに対し新たにデータ通信サー
ビスを提供する場合、前記データ通信を網が受け入れて
も、交換資源を共有している他のユーザのデータ通信の
ＱＯＳ（Quality Of Service）を網が保証しなければな
らない。従って、従来のＡＴＭ交換システムでは、デー
タ転送に先だって、データ送信端末８０３からデータ受
信端末８０４までのルーティングタグ・テーブルの設定
と、前記データ転送サービスに必要なセル廃棄率の保証
あるいは最大セル転送遅延といったＱＯＳと、平均／ピ
ーク使用帯域（単位時間当たりのデータ転送量）といっ
たトラヒックパラメータの使用とを、ＡＴＭ交換システ
ム内に存在する呼設定手段８２４に対し呼設定要求とし
て行う。網は、データ送信端末８０３から出された前記
呼設定要求を受け入れられる場合、前記ルーティングタ
グ・テーブル等の設定を行うとともに、前記データ送信
端末８０３が送信するセルに書き込むＶＰＩ／ＶＣＩ等
を前記データ送信端末８０４に通知する。
【０００７】データ送信端末８０３は、呼設定が終了し
てからセル転送を開始する。すなわち、データ送信端末
８０３は、まず、網から送られたＶＰＩ／ＶＣＩ等を基
にヘッダと呼ばれる５バイトデータを作成し、送信する
データのうち有意情報のみ定義されたプロトコルに従っ
て、４８バイトの情報フィールドに入るよう分割／コー
ディングを行う。最後に、作成したヘッダと情報フィー
ルドを結合してセルを作成し、前記セルをデータ送信端
末８０３からＡＴＭ交換機８０２に送信する。
【０００８】ＡＴＭ交換機８０２に有効セルが入力され
た場合、該入力セルのＶＰＩ／ＶＣＩが参照され、呼設
定時に設定されたルーティング情報を基に、該ＡＴＭ交
換機８０２の所望の出力から出力されるようにスイッチ
ングが行われる。
【０００９】具体的には、まず、ＡＴＭ交換機８０２に
入力されたセルは前処理部８２１に入力され、該前処理
部８２１では、入力セルのＶＰＩ／ＶＣＩをキーとして
ルーティングタグ・テーブルを検索し、呼設定時に前記
ＶＰＩ／ＶＣＩに対して設定されたルーティングタグを
検索する。次に、該前処理部８２１は、前記検索したル
ーティングタグを入力セルに付加し、前記ルーティング
タグを付加したセルをスイッチ８２２へ転送する。スイ
ッチは、入力セルのうち、前処理部８２１で付加された
ルーティングタグを参照し、前記ルーティングタグに従
ってスイッチングを行い、所望の出力から後処理部８２
３へ該入力セルを転送する。前記スイッチ８２２におい
て、入力セルのＶＰＩ／ＶＣＩを参照する代わりにルー
ティングタグを参照する理由は、ＶＰＩ／ＶＣＩ領域の
大きさ（ｂｉｔ数）は大きく、ＶＰＩ／ＶＣＩ領域全体
をデコードするのは効率が悪いので、前記領域をデコー
ドする代わりにスイッチ規模に合った大きさのルーティ
ングタグを前処理部８２１で付加し、スイッチ８２２で
は前記ルーティングタグをデコードすることによって効
率化を図るためである。最後に、後処理部８２３は、ス
イッチ８２２から転送された入力セルのうち、前処理部
８２１で付加したルーティングタグを削除し、ＡＴＭ交
換機８０２の所望の出力からセルを出力する。
【００１０】また、前記したように、ＶＰＩ／ＶＣＩは
ＡＴＭ交換機８０２の前処理部８２１のルーティングタ
グ・テーブルのエントリとして使用されるので、データ
送信端末から送信されたセルが複数のＡＴＭ交換機を経
由してデータ受信端末に転送される場合、経由するＡＴ
Ｍ交換機のルーティングタグ・テーブルの都合に従っ
て、前記ＶＰＩ／ＶＣＩをセル転送路の途中のＡＴＭ交
換機で書き換えなければならない場合がある。従って、
この場合に対応するために、ＡＴＭ交換機８０２に入力
されたセルのＶＰＩ／ＶＣＩをキーとして、ＡＴＭ交換
機８０２の出力側のＶＰＩ／ＶＣＩを検索し、入力セル
のＶＰＩ／ＶＣＩを該検索したＶＰＩ／ＶＣＩで置き換
えるＶＰＩ／ＶＣＩ変換機能が、ＡＴＭ交換機８０２の
前処理部８２１または後処理部８２３に実装されている
場合がある。
【００１１】データ送信端末から送信されたセルは、複
数のＡＴＭ交換機を経て所望のデータ受信端末に転送さ
れる。データ受信端末は、受信したセルから、定義され
たプロトコルに従ってデータ送信端末が送信したデータ
を再生する。
【００１２】また、データ送信端末は、呼設定時、網に
申告したトラヒック・パラメータを守ってデータ転送を
行うのであるが、網に接続されたすべてのデータ送信端
末が常に前記トラヒック・パラメータを守るとは限らな
いので、網は、データ送信端末が前記トラヒック・パラ
メータを守ってデータ転送を行っているかどうかチェッ
クしなければならない。なぜなら、網に接続されたデー
タ送信端末の中に、前記トラヒック・パラメータを守ら
ない違法なデータ送信端末、パラメータの設定を間違え
たため前記トラヒック・パラメータを守ることのできな
いデータ送信端末、または障害が発生したため前記トラ
ヒック・パラメータを守らないデータ送信端末等が存在
した場合、前記データ送信端末の送信するセルによっ
て、網が、交換資源を共有している他のデータ転送のＱ
ＯＳを保証できない場合が起こり得るからである。
【００１３】前記目的を達成するために、網は、まず呼
設定時に、データ送信端末８０３が申告したトラヒック
・パラメータを前記データ送信端末８０３が守っている
かどうかチェックし、前記データ送信端末８０３が送信
するセルが前記トラヒック・パラメータを違反した場
合、前記セルを廃棄するか、または前記セルに対して目
印を付けるタギング（tagging ）を行う。次に、該タギ
ングしたセルを網が受け入れることによって、他のデー
タ転送のＱＯＳを保証できない場合、該タギングしたセ
ルを廃棄することによって、他のデータ転送のＱＯＳを
網が保証することができる。具体的には、図５６（ａ）
に示すＡＴＭ交換機８０２内の前処理部８２１のポリシ
ング部（ＰＬ）８４１において、呼設定時に、データ送
信端末８０３が申告したトラヒック・パラメータを、該
データ送信端末８０３が違反していないかどうかチェッ
クし、前記データ送信端末８０３から送信されたセルが
前記トラヒック・パラメータを違反していた場合、前記
セルを廃棄、または前記セルのＣＬＰ（Cell Loss Prio
rity）ビットをセットすることによってタギングを行
う。ＡＴＭ交換機８０２が、該タギングしたセルを受け
入れることによって、他のデータ転送のＱＯＳを保証で
きない場合、該タギングしたセルを廃棄する。
【００１４】一方、データ送信端末８０３は、送信する
セルが、呼設定時、網に申告したトラヒック・パラメー
タを違反しないように、データ送信端末８０３内のシェ
イピング部（ＳＨ）８３１において、送信するセル流を
整形して、セルを送信する。
【００１５】次に、ＡＴＭ交換システムにおける端末の
立ち上げ手順（特に、メタシグナリング手順）は以下の
ようになる。すなわち、ＡＴＭ交換システムに接続され
た端末８０３は、起動(boot)時、メタシグナリング・セ
ルと呼ばれるＶＰＩ／ＶＣＩに特定値を持ったセルを、
網の管理機能を提供する網管理手段（図示せず）に向け
て送信する。網管理手段は、メタシグナリング・セルを
受信した場合、前記メタシグナリング・セルが転送され
てきたセル転送路に接続された端末８０３が起動したこ
とを認識し、前記端末８０３に対してシグナリング・チ
ャネルの帯域の割り当てや、前記端末８０３からＡＴＭ
交換システム内の呼設定手段８２４までのルーティング
・テーブルの設定等を行う。網管理手段は、前記設定が
終了した後、前記端末８０３の使用するシグナリング・
セルのＶＰＩ／ＶＣＩ等を前記端末に通知する。前記シ
グナリング・セルは、端末８０３が網に対して呼設定要
求を行う場合に使用される。
【００１６】次に、従来のＡＴＭ交換システムにおける
コピーコネクションのサポート方法について具体的に説
明する。
【００１７】コピーコネクションには、サブネット内の
すべての端末にデータを転送するブロードキャスト・コ
ネクションと、指定された複数の端末にデータを転送す
るマルチキャスト・コネクションの２種類のコピーコネ
クションがある。以下、まず、ＡＴＭ交換システムにお
ける前記２種類のコピーコネクションの必要性について
説明する。
【００１８】ＴＣＰ／ＩＰ等、従来方法によるコンピュ
ータ間通信には、後述するようにサブネット内の端末(H
ost)に対し、データグラムをブロードキャストする場合
があるので、従来のＡＴＭ交換システムで従来方法によ
るコンピュータ間通信を行う場合、何らかの方法によっ
てユーザに対しブロードキャスト・サービスを提供しな
ければならない。また、ネットワークを用いてテレビ会
議等を行う場合、同じ画像を複数の端末に転送しなけれ
ばならないが、ネットワークが何らかの方法でマルチキ
ャスト・サービスをユーザに提供することができるな
ら、ユーザはネットワークに画像を１回送信すれば、ネ
ットワークが複数の端末に同じ画像を送信してくれるの
で、ユーザは効率的なデータ転送をすることができる。
【００１９】以下、従来のＡＴＭ交換システムにおいて
コピーコネクションを実現する方法について、図５７を
参照しながら具体的に説明する。
【００２０】図５７（ａ）は、コピースイッチによるコ
ピーコネクションの実現方法である。ＡＴＭ交換機のセ
ルスイッチとして、コピースイッチ８４４を用いた場
合、コピーコネクションに属しないセルおよびコピーコ
ネクションに属するセルの両方のを、１つのセルスイッ
チで扱うことができる。まず、コピーコネクションに属
しないセルが、前記コピースイッチ８４４に入力された
場合、該入力セルは通常セル用バッファ８４６に入力さ
れ、一般のＡＴＭセルスイッチと同じようにスイッチン
グが行われる。一方、コピーコネクションに属するセル
が入力された場合、該入力セルはコピーセル用バッファ
８４８に入力され、該入力セルの属するコネクションに
指定された出力ポート８５０1 ，８５０2 ，８５０3 に
指定された回数コピーされることによって、ユーザに対
しコピーコネクションを提供することができる。
【００２１】しかし、このようにコピーコネクションの
実現方法としてコピースイッチを用いた場合、コピース
イッチの出力ポートは、コピーコネクションに属するセ
ルとコピーコネクションに属しないセルのうち、いずれ
か一方のセルを選択して出力しなければならないので、
コピースイッチの出力ポートの出力アルゴリズムは複雑
になってしまうという問題点があった。また、コピース
イッチをＬＳＩ化する場合、コピースイッチに入るコピ
ーセル用バッファの大きさには制限があるが、前記した
ようにコピーセル用バッファ８４８に入力されたセル
は、指定された回数コピーされるまではバッファから出
力されないので、コピーセル用バッファ８４８はコピー
コネクションに属するセルでオーバーフローしやすく、
コピーコネクションに属するセルは廃棄されやすいとい
う問題点があった。
【００２２】図５７（ｂ）は、コピー機能を提供するコ
ピー手段を適用したコピーコネクションの実現方法であ
る。コピーコネクションの実現方法としてコピー手段８
５４による方法を用いた場合、コピーコネクションに属
するセルがＡＴＭ交換機に入力された場合、まず、前記
セルはセルスイッチ８５２によってコピー手段８５４に
転送されるようにスイッチングされる。コピー手段８５
４は、前記コピーコネクションに属するセルが入力され
た場合、前記セルをバッファ８５６に格納し、前記セル
の属するコネクションに対し指定された出力ポート８５
８1 ，８５８2，８５８3 に、指定された回数だけ前記
セルをコピーして出力することによって、ユーザに対し
コピーコネクションを提供することができる。一方、コ
ピーコネクションに属しないセルがＡＴＭ交換機に入力
された場合、前記セルは、セルスイッチ８５２の所望の
出力ポート８５８1 ，８５８2 ，８５８3 から出力され
るようにスイッチングが行われる。
【００２３】コピーコネクションの実現方法としてコピ
ー手段が用いられた場合、セルスイッチ内で入力セルの
コピーを行う必要はないので、コピースイッチを用いた
場合に比べセルスイッチの構造は簡単になるという利点
がある。また、コピーセル用バッファをセルスイッチ内
に持つ必要はなく、コピー手段内に持てばよいので、コ
ピースイッチの場合に比べてより多くのコピーセル用バ
ッファを持つことができ、コピーコネクションに属する
セルがより廃棄されにくいという利点がある。
【００２４】しかし、コピー機能を提供するコピー手段
に実装されるコピーセル用バッファの大きさは有限であ
るので、前記コピーコネクションに属するセルはコピー
コネクションに属していないセルに比べて廃棄されやす
いという問題点があった。コピーコネクションに属する
セルがコピー手段に入力された場合、コピー手段内で所
定の回数コピーされ出力されるが、コピー手段の出力が
１つしかない場合、コピーされたセルは同時には１つし
か出力できないので、前記コピー手段による方法を用い
た場合、コピーコネクションに属するセルに対してサー
ビスをするのに時間がかかってしまうという問題点があ
る。この問題点はコピー手段の出力を１つ以上にするこ
となどによって解決することができるものの、前記コピ
ー手段の出力を１つ以上とした場合には、セルスイッチ
のコピー手段以外からの入力の数が少なくなるので、入
出力数の大きいセルスイッチを構成したいときなどは新
たな問題となる。
【００２５】図５７（ｃ）は、コピーサーバ８６２によ
るコピーコネクションの実現方法である。コピーコネク
ションの実現方法として、コピーサーバー８６２による
方法が採用された場合、ＡＴＭ交換システムに接続して
いる１つの端末(Host)をコピーコネクションに対しサー
ビスを行うコピーサーバーとし、ＡＴＭ交換機８６０
は、コピーコネクションに属するセルを前記コピーサー
バー８６２に転送し、コピーサーバー８６２が該転送さ
れたセルを、該コネクションに対し指定された宛先に、
指定された回数コピーし、該コピーしたセルを再びＡＴ
Ｍ交換機８６０へ転送することによって、ユーザに対し
コピーコネクションを提供することができる。
【００２６】コピーコネクションの実現方法として、コ
ピーサーバーによる方法を用いた場合、ＡＴＭ交換機内
にコピー機能（コピースイッチ、コピー手段等）を持つ
必要がないので、コピー機能を持たないＡＴＭ交換機
で、ユーザに対しコピーコネクションを提供できるとい
う利点がある。また、図５７（ａ）のようなＡＴＭ交換
機内にコピーセル用バッファを持つコピースイッチ／コ
ピー手段に比べて、コピーサーバーの場合、コピーセル
用バッファをより大きくできるので、コピーコネクショ
ンに属するセルがより廃棄されにくいという利点があ
る。
【００２７】しかし、コピーコネクションの実現方法と
して、コピーサーバーによる方法が用いられた場合、コ
ピーサーバー８６２によってコピーされたセルは、同時
には１つのセルしかＡＴＭ交換機８６０へ転送できない
ため、コピーコネクションのサービスに時間がかかって
しまうという問題点があった。また、一般に、コピーサ
ーバーによってコピーコネクションをサポートする場
合、コピーサーバーに転送されたコピーコネクションに
属するセルは、コピーサーバーのＯＳを通してソフトウ
ェアで処理されるため、該入力セルに対し処理を行うの
に時間がかかってしまうという問題点があった。
【００２８】次に、従来のＡＴＭ交換システムにおける
コネクションレス・サービスのサポート方法について具
体的に説明する。
【００２９】従来のＡＴＭ交換システムは、電話網の構
成方法を基にシステム設計が行われているので、ＡＴＭ
交換システムにおけるデータ通信は、基本的には、電話
網の場合と同じようなコネクション型の（コネクション
・オリエンテッドな）データ通信である。すなわち、デ
ータ通信を行う必要の生じたデータ送信端末は、データ
転送に先だって、まず、網に対し呼設定要求を行い、前
記呼設定を受け入れられてから、該データ送信端末は網
が設定したコネクションを用いてデータ転送を行うとい
う方法を採用している。一方、従来から行われているコ
ンピュータ間通信の多くは、後述するようにコネクショ
ンレス型のデータ通信である。従って、従来のＡＴＭ交
換システムで、従来の方法によるコンピュータ間通信を
行う場合、何らかの方法でコネクションレス型のデータ
通信をサポートしなければならない。以下、図５８を参
照しながら、従来のＡＴＭ交換システムでコネクション
レス型のデータ通信をサポートする方法について説明す
る。
【００３０】従来のＡＴＭ交換システムでは、コネクシ
ョンレス型のデータ通信は、ＣＬＳＦ(Connection-Less
Service Function)処理によってユーザに対し提供され
る。具体的には、従来のＡＴＭ交換システムにおいて、
コネクションレス・サービスをユーザに提供する場合、
部分ネット（サブネット）内に１つ以上のＣＬＳＦ処理
手段を設け、前記ＣＬＳＦ処理手段とコネクションレス
型データ通信を行うサブネット内のすべての端末(Host)
との間に、前記データ通信用のコネクションを予め設定
しておく。また、前記ＣＬＳＦ処理手段と少なくとも前
記サブネットの上位サブネット内のＣＬＳＦ処理手段と
の間に、コネクションレス型のデータ通信用のコネクシ
ョンを予め設定しておく。前記２種類のコネクション
（ＣＬＳＦ処理手段と端末間のコネクション／ＣＬＳＦ
処理手段間のコネクション）を用いることによって、従
来のＡＴＭ交換システムにおいてコネクションレス型の
データ通信サービスが実行される。
【００３１】以下、図５８を用いて、従来のＡＴＭ交換
システムにおける、ＣＬＳＦ処理手段を用いたコネクシ
ョンレス型のデータ通信について具体的に説明する。
【００３２】図５８において、端末(Host)８７４から同
じサブネット内に存在する端末(Host)８７６へ、コネク
ションレス型のデータ通信を行う場合、ＣＬＳＦ処理手
段８７０とサブネット内の端末(Host)８７４，８７６と
の間に予め設定されたコネクションレス型データ通信用
のコネクションを用いて、データ通信を行う。すなわ
ち、端末(Host)８７４は、前記設定されたコネクション
レス・サービス用のコネクションを用いて、データをセ
ルスイッチ８６４に接続したＣＬＳＦ処理手段８７０に
転送し、ＣＬＳＦ処理手段８７０が、前記コネクション
レス・サービス用のコネクションを用いて前記データを
端末(Host)８７６へ転送することによって、前記データ
通信が実行される（経路１参照）。
【００３３】また、図５８において、端末(Host)８７４
から上位サブネット内に存在する端末(Host)８７８へ、
コネクションレス・サービスを用いてデータ通信を行う
場合、前記予め設定されたＣＬＳＦ処理手段８７０とサ
ブネット内の端末(Host)８７４との間のコネクション
と、ＣＬＳＦ処理手段８７０，８７２間に設定されたコ
ネクションと、ＣＬＳＦ処理手段８７２とサブネット内
の端末(Host)８７８との間のコネクションを用いて、デ
ータ通信を行う。すなわち、端末(Host)８７４は、ま
ず、前記予め設定されたコネクションレス・サービス用
のコネクションを用いて、データを、セルスイッチ８６
４に接続したＣＬＳＦ処理手段８７０に転送し、次に、
ＣＬＳＦ処理手段８７０が、前記データを、前記予め設
定されたコネクションレス・サービス用のコネクション
を用いて、セルスイッチ８６８に接続しているＣＬＳＦ
処理手段８７２に転送し、最後に、ＣＬＳＦ処理手段８
７２は、前記データを、前記予め設定されたコネクショ
ンレス・サービス用のコネクションを用いて、端末(Hos
t)８７８へ転送することによって、前記データ通信が実
行される（経路２参照）。
【００３４】同様に、図５８において、端末(Host)８７
４からさらに上位のサブネットにデータを転送する場合
も、前記予め設定されたＣＬＳＦ処理手段８７０とサブ
ネット内の端末(Host)８７４との間のコネクションと、
ＣＬＳＦ処理手段８７０，８７２間に設定されたコネク
ションを用いて、データ通信を行うことができる（経路
３参照）。
【００３５】ここで、コネクションレス・サービスを、
従来のＡＴＭ交換システムにおいて、前記ＣＬＳＦでユ
ーザに提供する場合、少なくとも以下の２つの問題点が
存在する。
【００３６】１つ目の問題点は、ＣＬＳＦ処理手段内の
バッファ量に関する問題点である。ファイル転送等のコ
ンピュータ間通信を、前記ＣＬＳＦ処理手段を用いて実
行する場合、前記ＣＬＳＦ処理手段には多量のデータバ
ッファが必要である。特に、複数のＣＬＳＦ処理手段を
経由してデータ通信を行う場合で、途中のＣＬＳＦ処理
手段間で誤り検出を行い再送制御を行う場合、ＣＬＳＦ
処理手段には多量のデータバッファが必要である。一
方、ファイル転送以外のレイテンシに対する要求の厳し
いコンピュータ間通信をＣＬＳＦ処理手段で行う場合、
該ＣＬＳＦ処理手段における遅延を小さくするためＣＬ
ＳＦ処理手段は、ＡＴＭ交換機内に実装されるが、ＡＴ
Ｍ交換機内にＣＬＳＦ処理手段を実装する場合、データ
バッファの大きさを大きくできないといった問題点があ
った。
【００３７】２つ目の問題点は、複数のＣＬＳＦ処理手
段を経由すること等によるレイテンシに関する問題点で
ある。前記したように、ファイル転送以外のコンピュー
タ間通信には、レイテンシに対して要求の厳しいコンピ
ュータ間通信も存在するが、すべてのコンピュータ間通
信をＣＬＳＦ処理手段を用いて行おうとした場合、前記
レイテンシに関して要求の厳しいコンピュータ間通信に
対し問題が生ずる。これは、ＣＬＳＦ処理手段を経由す
ることによって、遅延が生じるためである。また、ＣＬ
ＳＦ処理手段は、サブネット内の多くの端末(Host)によ
って共有しているが、複数の端末(Host)が同時にＣＬＳ
Ｆ処理手段を使用し始めた場合、アクセスの競合による
輻輳によって、ＣＬＳＦ処理手段を経由するのに大きな
時間がかかる場合があるといった問題点があった。
【００３８】２）イーサネットＬＡＮ（Ethernet-LAN）
におけるコンピュータ間のデータ通信について 次に、従来のイーサネットＬＡＮにおけるコンピュータ
間のデータ通信について説明する。
【００３９】図５９は、複数の端末(Host)８８０（８８
０1 ，８８０2 ，８８０3 ）が１つのバス(Ethernet)８
８２を共有し、各端末(Host)８８０1 ，８８０2 ，８８
０3が前記バス型のイーサネットを用いてコンピュータ
間通信を行う場合のハードウェア構成を示したものであ
る。以下、図５９を参照しながら、ＴＣＰ／ＩＰ（Tran
smission Control Protocol/Internet Protocol)を用い
たＬＡＮ内のコンピュータ間通信について、具体的に説
明する。
【００４０】バス型のイーサネットで、端末(Host)８８
０1 ，８８０2 ，８８０3 がデータ通信を行う必要が生
じた時は、まず、共有バス８８２上の信号を観察し、他
の端末が使用しているかどうかを調べる。他の端末が共
有８８２バスを使用していない場合、データ送信端末
（例えば８８０2 ）は、宛先のデータ受信端末（例えば
８８０3 ）の４８ビットのＭＡＣアドレスを書き込んだ
フレームをフレーム生成手段８８８にて生成し、共有バ
ス８８２上に送信する。この方法では、偶然、２つ以上
の端末が同時にフレームを共有バス８８２に送信し始め
る場合が存在し、この場合、共有バス８８２上で信号が
競合し不具合が発生する。この不具合に対しては、フレ
ームを送信した端末が共有バス８８２上の信号を観察
し、信号の衝突を検出した場合、直ちにフレームの送信
を停止し、一定時間後に送信を再開するといった方法等
を用いて、複数端末によるフレーム送信開始の競合は回
避することができる。
【００４１】端末インタフェース８８４の受信部は、共
有バス上に出力されるフレームを常時観察し、自分宛の
フレームが共有バス上に送信された場合、前記フレーム
を取り込むことによって、データ送信端末から送られた
情報をデータ受信端末が受信することができる。具体的
には、端末インタフェース８８４内のＭＡＣフィルタ８
８６は、製造時に個々の端末インタフェースに割り振ら
れたＭＡＣアドレスと、ブロードキャスト・アドレスを
認識し、前記ＭＡＣアドレスまたはブロードキャスト・
アドレスが宛先に書き込まれたフレームが共有バス８８
２に出力された場合、前記フレームをＭＡＣフィルタ８
８６が取り込み、該取り込んだフレームを端末インタフ
ェース８８４が端末８８０へ送ることによって、データ
送信端末が送信したフレームを、データ受信端末が受信
することができる。
【００４２】次に、ＩＰ(Internet Protocol) を用い
た、データ送信端末からデータ受信端末へのデータグラ
ム転送法について、図６０を参照しながら具体的に説明
する。
【００４３】前記した従来のイーサネットのＭＡＣアド
レスによるフレームの転送方法は、データ送信端末とデ
ータ受信端末が同一のイーサネット上にある場合に、有
効なデータ転送方法である。すなわち、従来のイーサネ
ットでは、データ送信端末は、送信フレームの宛先アド
レス・フィールドに、宛先のデータ受信端末のＭＡＣア
ドレスを書き込んでフレームを送信し、データ受信端末
はイーサネット上に出力されるフレームの宛先アドレス
を観察し、前記フレームの宛先アドレスがブロードキャ
スト・アドレスの場合、またはデータ受信端末のＭＡＣ
アドレスに等しい場合、前記フレームをデータ受信端末
が取り込むことによって、データ送信端末からデータ受
信端末へのデータ転送が実行される。従って、宛先のデ
ータ受信端末がデータ送信端末と同じイーサネット上に
ない場合、データ送信端末から送信されたフレームは、
前記イーサネット上のどのデータ受信端末によっても受
信されず、前記データ送信端末から前記データ受信端末
へのデータ転送を実行することはできない。従って、同
一のイーサネット上にないデータ受信端末へデータを転
送するには、何らかの方法を用いて、データ転送を行わ
なければならない。以下、そのような場合におけるＩＰ
によるデータ転送方法について説明する。
【００４４】インターネット上の端末(Host)には、一意
に識別できるような３２ビットのＩＰ（Internet Proto
col ）アドレスが割り当てられていて、インターネット
では、前記ＩＰアドレスを用いて、データ送信端末から
データ受信端末へのデータ転送が行われる。また、異な
るイーサネットは、ＩＰルーターによって相互接続さ
れ、前記ＩＰルーターによって、送信フレーム中の宛先
ＩＰアドレスを基に送信フレーム中の宛先ＭＡＣアドレ
スが変換される。
【００４５】具体的には、図６０において、一方のイー
サネットE0上の端末８９０から他方のイーサネットE1上
の端末８９４へデータを転送する場合、まず、イーサネ
ットE0上の端末８９０からＩＰルーター８９６へ、デー
タグラムの宛先アドレスがＣipで、フレームの宛先アド
レスがＲmac となるようなフレームを送信する。ＩＰル
ーター８９６のイーサネットE0に対するインターフェー
ス部は、前記フレームの宛先アドレスがＲmac であるの
で、前記フレームを受信することができる。ＩＰルータ
ー８９６は、前記フレームを受信し、前記フレームのデ
ータグラムの宛先に書かれているアドレス（Ｃip) を基
にＩＰルーター８９６内のテーブルを参照し、イーサネ
ットE1上の端末８９４のＭＡＣアドレス（Ｃmac)を検索
する。次に、ＩＰルーター８９６は、前記フレームの宛
先ＭＡＣアドレスを前記検索したＭＡＣアドレス（Ｃma
c)に置き換えて、該フレームをイーサネットE1上に送信
する。最後に、前記イーサネットE1に送信されたフレー
ムは、前記フレームの宛先アドレスがＣmac であるの
で、イーサネットE1上の端末８９４によって取り込まれ
る。以上説明した手順によって、データ送信端末から送
信されたフレームは、ＩＰルーターを経由して、データ
受信端末へ転送される。
【００４６】以上説明したＩＰによるデータ転送方法
は、データ送信端末とデータ受信端末が同一イーサネッ
ト上にない場合に有効な転送方法であり、データ送信端
末とデータ受信端末が同一イーサネット上にある場合
は、前記ＩＰによるデータ転送方法を用いる必要はない
が、データ送信端末とデータ受信端末が同じイーサネッ
トにある場合とない場合を区別して、送信データを送信
フレームにマッピングするのは面倒なので、前記したデ
ータ送信端末とデータ受信端末が同一イーサネット上に
ある場合も、ＩＰによるデータ転送方法が用いられる。
すなわち、データ送信端末とデータ受信端末が同一イー
サネット上にある場合も、送信データを，宛先ＩＰアド
レスを書き込んだデータグラムに入るように分割し、前
記データグラムを、宛先ＭＡＣアドレスが書き込まれた
フレームに挿入することによって、送信データから送信
フレームへのマッピングが行われている。
【００４７】以下、データ送信端末が、宛先のＩＰアド
レスから、宛先のデータ受信端末のＭＡＣアドレスまた
はＩＰルーターのＭＡＣアドレスを獲得するＡＲＰ( Ad
dress Resolusion Protocol) と呼ばれる方法について
図６１を参照しながら説明する。
【００４８】前記したように、データ送信端末が同一の
イーサネット上のデータ受信端末へデータ転送を行う場
合、宛先のデータ受信端末のＭＡＣアドレスが必要であ
る。また、データ送信端末が同一のイーサネット上にな
いデータ受信端末へデータ転送を行う場合、前記データ
送信端末と同一のイーサネット上にある前記データ転送
に関係するＩＰルーターのＭＡＣアドレスが必要であ
る。データ転送に先だって、前記データ受信端末のＭＡ
Ｃアドレスまたは前記ＩＰルーターのＭＡＣアドレス
は、ＡＲＰと呼ばれる方法によって獲得することができ
る。
【００４９】具体的には、データ送信端末８９８は、ま
ず、データ転送に先だって、獲得したいＭＡＣアドレス
に対応するＩＰアドレスを書き込んだ、ＡＲＰ要求メッ
セージと呼ばれる定められたフォーマットのデータグラ
ムを、サブネットワーク内の端末(Host)にブロードキャ
ストする。次に、前記ＡＲＰ要求メッセージを受信し
た、サブネットワーク内の端末(Host)のうち、前記ＡＲ
Ｐ要求メッセージに対し答えることのできる端末(Host)
８９０は、前記ＡＲＰ要求メッセージ中に書き込まれた
ＩＰアドレスに対応するＭＡＣアドレスを書き込んだ、
ＡＲＰ応答メッセージと呼ばれる定められたフォーマッ
トのデータグラムを、前記データ送信端末に送信するこ
とによって、前記データ送信端末８９８は宛先のＭＡＣ
アドレスを獲得することができる。ただし、データ受信
端末がデータ送信端末と同一のサブネットワーク上にあ
る場合はデータ受信端末であるが、同一サブネットワー
ク上にない場合は対応するＩＰルーターが返答する。
【００５０】一般に、サブネットワーク内の端末(Host)
に対しブロードキャストされたフレームは、サブネット
ワーク内のすべての端末(Host)によって受信される。前
記フレームを受信した端末インタフェースは、受信フレ
ームのうち、フレーム・データ領域に格納されているデ
ータグラムを端末(Host)へ転送する。前記データグラム
を受信した端末(Host)は、ＴＣＰ／ＩＰ処理ルーチンを
起動し、前記データグラムに対し処理を行う。従って、
ブロードキャストされたＡＲＰ要求メッセージに対し、
前記ＡＲＰ要求メッセージに対し応答することのできる
端末(Host)では、前記データグラムによってＡＲＰ応答
メッセージを作成し、前記ＡＲＰ応答メッセージを返送
するプロセスが起動されるが、前記ＡＲＰ要求メッセー
ジに対し応答することのできない端末(Host)では、引き
続いてプロセスは起動されずに、前記ＡＲＰ要求メッセ
ージに対する処理は終了してしまう。従って、前記ＡＲ
Ｐ要求メッセージに対し応答することのできない端末(H
ost)にとっては、前記ＡＲＰ要求メッセージを受信する
ことによって、処理中のプロセスを中断して、前記ＡＲ
Ｐ要求メッセージに対し不必要な処理を行わなければな
らないといった問題点があった。
【００５１】前記問題点に対しては、以前送信したＡＲ
Ｐ要求メッセージに対する応答を基に、ＩＰアドレスと
ＭＡＣアドレスの対応表（ＡＲＰテーブルと呼ぶ）を作
成し、ＡＲＰを行わなければならなくなったデータ送信
端末は、まず、ＡＲＰテーブルを参照し、前記テーブル
でＭＡＣアドレスが検索できた場合、ＡＲＰ要求メッセ
ージをブロードキャストしないことによって、ブロード
キャストする回数を減らすことができる。
【００５２】次に、ネットワーク情報を集中管理するの
に有用なネットワーク・インフォメーション・サービス
（Network Information Service ；以下、ＮＩＳと略記
する）について説明する。
【００５３】ネットワークに接続された端末(Host)は、
ホストネーム、ホストＩＰアドレス、ユーザネーム、ユ
ーザ・パスワードといったネットワーク情報を必要とす
る。例えば、前記したデータ送信端末からデータ受信端
末へのデータ転送において、ユーザは、データ受信端末
のＩＰアドレスの代わりにデータ受信端末のホストネー
ムを用いて、前記データ受信端末を指定し、データ転送
を行う場合の方が多い。上記の場合、データ受信端末の
ホストネームをＩＰアドレスに変換する変換テーブル
（hosts ファイル) が必要であり、前記データ送信端末
はデータ転送に先だって、ユーザから指定されたデータ
受信端末のホストネームを、前記変換テーブル（hosts
ファイル) を用いてＩＰアドレスに変換し、該ＩＰアド
レスを用いてデータ転送を開始する。従って、ユーザが
データ受信端末のホストネームを用いてデータ転送を行
うためには、データ送信端末にホストネームからＩＰア
ドレスに変換するのに用いる変換テーブル（hosts ファ
イル) が必要である。
【００５４】ネットワークに接続された端末(Host)の数
が少ない場合は、前記端末(Host)のネットワーク情報が
書き込まれたファイル（例えば、hosts ファイル）を直
接編集することによって、前記ネットワーク情報を管理
してもそれほど面倒ではないが、ネットワークに接続さ
れた端末(Host ) の数が増加するに従って、前記ネット
ワークに接続された端末(Host)の前記ネットワーク情報
が書き込められたファイルを直接編集して、前記ネット
ワーク情報を管理することはたいへん面倒となる。なぜ
なら、前記ネットワーク情報が変更される度に、前記ネ
ットワークに接続された端末(Host)の数だけ前記ネット
ワーク情報が書き込まれたファイルを編集し直さなけれ
ばならないからである。従って、ネットワークに接続さ
れたすべての端末(Host)が必要とするようなネットワー
ク情報は、個々の端末(Host)の対応するファイルを直接
編集することによって、前記ネットワーク情報を管理す
る方法よりシステム管理者が１つのファイルを編集して
集中管理し、前記１つのファイルがネットワークに接続
された端末(Host)に分配される方法の方が優れている。
ＮＩＳは、前記したような集中管理方法を、サブネット
ワークのユーザに提供する。
【００５５】以下、図６２を参照しながら、従来のＮＩ
Ｓの構成について具体的に説明する。サブネットワーク
に属する端末(Host)のうち、同一のネットワーク情報を
共有する端末（８９２，８９４，８９８，９０４）の集
合をＮＩＳドメインと定義する。このＮＩＳドメインに
属する端末（８９２，８９４，８９８，９０４）には、
ネットワーク情報（以下、ＮＩＳ情報と呼ぶ）を管理
し、ユーザからのＮＩＳ情報の問い合わせに答えるＮＩ
Ｓサーバー（８９３，９００，９０６）、およびＮＩＳ
情報をサーバーに問い合わせるＮＩＳクライアント（８
９６，９０２，９０８）が存在する。また、ＮＩＳドメ
インに属する端末(Host)が持つネットワーク情報のう
ち、端末固有のネットワーク情報が格納されたファイル
をＮＩＳファイルと定義し、ＮＩＳドメインに属する端
末間で共有するネットワーク情報が格納されたファイル
をＮＩＳマップと定義する。ＮＩＳドメインに属する端
末(Host)が、ＮＩＳファイルとＮＩＳマップを利用する
方法としては、ＮＩＳファイルにＮＩＳマップが追加さ
れる方法と、ＮＩＳファイルがＮＩＳマップに置き換え
られる方法と、ＮＩＳマップが使用されずＮＩＳファイ
ルのみ使用される方法等がある。
【００５６】上記のように、ＮＩＳでは、ネットワーク
に接続された端末間で共有されるネットワーク情報は、
システム管理者が管理するファイルで集中管理される
が、前記集中管理されるファイルは、ネットワークに接
続されたすべての端末(Host)に分配され、前記分配され
たネットワーク情報が、ネットワークに接続した端末(H
ost)によって利用される。具体的には、ＮＩＳサーバー
には、ＮＩＳドメインに唯一存在するＮＩＳマスタサー
バー（８９３）と、ＮＩＳスレーブサーバー（９００，
９０６）の２種類のサーバーが存在し、ネットワークの
システム管理者がＮＩＳマスタサーバー８９３のＮＩＳ
マップを編集管理し、ＮＩＳマスタサーバー８９３が、
ＮＩＳマップが変更された場合に前記変更されたＮＩＳ
マップをＮＩＳドメインに属するＮＩＳスレーブサーバ
ー９００，９０６に分配することによって、サブネット
ワークに属する端末のネットワーク情報は集中管理され
る。
【００５７】また、ネットワークに接続した端末(Host)
には、十分なディスク容量を持った端末(Host)（例え
ば、図６２の８９８あるいは９０４）と、ユーザファイ
ルを格納するのには不十分であるが、システムファイル
は格納することができるディスク容量を持ったデータレ
ス・クライアント（例えば図６２の８９４あるいは８９
８）と、ディスクを持たないディスクレス・クライアン
ト（例えば図６２の８９４）とが存在する。一般的に
は、端末(Host)またはデータレス・クライアントにおい
ては、ＮＩＳサーバー・プロセスとＮＩＳクライアント
・プロセスが起動され、ディスクレス・クライアントま
たはデータレス・クライアントにおいては、ＮＩＳクラ
イアント・プロセスのみ起動されている。端末(Host)の
ユーザ・プロセスが、ネットワーク情報が必要になった
場合、前記ユーザ・プロセスが、端末(Host)において起
動しているＮＩＳクライアント・プロセスに対し、ネッ
トワーク情報の要求を行う。前記ネットワーク情報の要
求を受けたＮＩＳクライアント・プロセスは、前記ネッ
トワーク情報の要求を、ネットワーク上のＮＩＳサーバ
ー・プロセスが起動している端末(Host)へリレーイング
する。ＮＩＳサーバー・プロセスは、前記ネットワーク
情報の要求に対する応答を、前記ＮＩＳクライアント・
プロセスを経由することによって、前記ユーザ・プロセ
スに転送する。なお、図６３および図６４に、従来のネ
ットワーク情報のアクセス・アルゴリズムを図示する。
なお、図６３および図６４に示すフローチャートは、図
中のＬ２５で連結されているものである。
【００５８】ＮＩＳクライアントは、ネットワーク上に
存在するＮＩＳサーバーにネットワーク情報の要求を出
す場合、該ＮＩＳクライアントが帰属(bind)しているＮ
ＩＳサーバーにのみ、前記要求を送信する。以下、ＮＩ
ＳクライアントのＮＩＳサーバーへの帰属(bind)アルゴ
リズムについて、具体的に説明する。
【００５９】ＮＩＳクライアントは、起動時、ＮＩＳサ
ーバーに帰属(bind)するため、ypbind要求メッセージを
網にブロードキャストし、該ypbind要求メッセージに対
し、該ＮＩＳクライアントに一番早くypbind応答メッセ
ージを送信したＮＩＳサーバーに、該ＮＩＳクライアン
トは帰属(bind)するという方法が採用されている。ま
た、ＮＩＳクライアントのＮＩＳサーバーへの参照要求
に対し、ＮＩＳサーバーの応答がタイムオーバーした場
合、ＮＩＳクライアントは、ＮＩＳサーバーへの帰属(b
ind)をやり直すが、前記帰属(bind)のやり直しの際に
も、ネットワークのブロードキャスト機能が用いられて
いる。すなわち、前記ＮＩＳクライアントは、ypbind要
求メッセージを網にブロードキャストし、前記ypbind要
求メッセージに対し、前記ＮＩＳクライアントに一番早
くypbind応答メッセージを送信したＮＩＳサーバーに、
前記ＮＩＳクライアントは帰属(bind)し直す、という方
法が採用されている。なお、図６５に、従来のＮＩＳク
ライアントのＮＩＳサーバーへの帰属(bind)アルゴリズ
ムを示す。
【００６０】しかし、端末の起動時、端末(Host)のＣＰ
Ｕは起動処理に忙しく、前記端末にＮＩＳサーバーが存
在する場合でも、前記ＮＩＳサーバーが前記クライアン
トの前記ブロードキャストに応じることができないの
で、一般的に、ＮＩＳクライアントは、該ＮＩＳクライ
アントが起動している端末(Host)以外の端末のＮＩＳサ
ーバーに帰属することになる。従って、同一端末(Host)
に、ＮＩＳサーバーとＮＩＳクライアントが起動されて
いる場合でも、該ＮＩＳクライアントは、ネットワーク
を経由して他の端末で起動しているＮＩＳサーバーにネ
ットワーク情報を要求することとなり、効率が悪いとい
った問題点があった。
【００６１】次に、図６６を参照しながら、ディスクレ
ス・クライアントの起動手順(boot-strap)について、具
体的に説明する。ディスクレス・クライアントのブート
ストラップには、以下で説明する、ＢＯＯＴＰ（BOOTst
rap Protocol) と、bootparamRPCによる方法の２通りの
方法が知られている。
【００６２】ＢＯＯＴＰは、多くのパーソナル・コンピ
ュータで採用されているブートストラップである。ディ
スクレス・ワークステーションは、自分の端末のＭＡＣ
アドレスしか、ネットワーク情報として持っていないの
で、自分端末のＩＰアドレス、ルートファイルシステム
のある端末の名前、システムファイルのある端末の名
前、スワップ領域のある端末の名前等の、ブート時に必
要な情報を、ネットワークを経由して手に入れなければ
ならない。図６６（ａ）に示すように、ＢＯＯＴＰで
は、まず、ディスクレス・クライアント９１０は、ネッ
トワークに接続している端末にＢＯＯＴＰ要求メッセー
ジをブロードキャストし、ネットワークに接続している
端末(Host)のうち、ブートサーバー９１２が、前記ＢＯ
ＯＴＰ要求メッセージに対し必要な情報を埋め込んだＢ
ＯＯＴＰ応答メッセージを前記ディスクレス・クライア
ント９１０に送ることによって、前記ディスクレス・ク
ライアント９１０はブート時に必要な情報を得ることが
できる。ディスクレス・クライアント９１０は、前記Ｂ
ＯＯＴＰ応答メッセージを受信するまでは、自分のＩＰ
アドレスがわからないので、ブートサーバー９１２は、
前記ＢＯＯＴＰ応答メッセージを、宛先ＭＡＣアドレス
を書き込んだブロードキャストによって、前記ディスク
レス・クライアント９１０に転送する。
【００６３】一方、図６６（ｂ）に示すように、bootpa
ramRPCによるブートストラップでは、まず、ディスクレ
ス・クライアント９１４が、ブート時に、ＲＡＲＰ（Re
verse Address Resolution Protocol)要求メッセージを
ネットワーク上にブロードキャストし、前記ＲＡＲＰ要
求メッセージに対して、ネットワークに接続された端末
のうち前記ディスクレス・クライアントをブートするの
に最も適当なブートサーバー（図６６では９１５）が、
最初に応答を返すことによって、前記ディスクレス・ク
ライアント９１４は、ブートするのに必要な情報を得る
ことができる。また、前記ブートサーバー９１５以外の
ネットワークに接続されたブートサーバー（図６６では
９１６）が、前記ＲＡＲＰ要求メッセージに対して遅れ
て応答を返すことによって、前記ブートサーバー９１５
が他の処理の実行に忙しい場合でも、前記ディスクレス
・クライアント９１４がブートすることができる。
【００６４】ここまで述べたように、従来のＡＴＭ交換
システムは、電話網の交換機の構成を基に、システム設
計が行われているので、ＡＴＭ交換システムにおけるデ
ータ通信は、基本的には、電話網の場合と同じようなコ
ネクション型のデータ通信である。すなわち、データ通
信を行う必要の生じたデータ送信端末は、データ転送に
先だって、まず、網に対し呼設定要求を行い、網が、前
記呼設定要求を受け入れられる場合、前記呼設定要求に
対し、該当するコネクションを設定する。データ送信端
末は、前記呼設定が終了してから、網が設定したコネク
ションを用いてデータ転送を開始する、という方法を採
用している。
【００６５】一方、前記したように、従来から行われて
いるコンピュータ間通信の多くは、コネクションレス型
のデータ通信であった。すなわち、データ送信端末は、
網に対し呼設定要求等を行わずに、データ通信を行う必
要の生じた時点で、宛先を書き込んだパケットの送信を
行う。前記パケットは、網の都合によって宛先のデータ
受信端末まで到着しない場合が存在するが、データ送信
端末は、定義されたプロトコルまたは上位ソフトウェア
によって、送信パケットが宛先のデータ受信端末まで届
いたかどうか判定し、前記パケットが宛先のデータ受信
端末まで届かなかった場合、前記パケットの再送等の方
法によってデータ転送を行っている。
【００６６】前述した通り、ＡＴＭ交換技術は、B-ISDN
を実現する唯一の解として、現在、活発に研究・開発が
行われているが、従来構成のＡＴＭ交換システムにおい
て、コンピュータ間のデータ通信の実現方法に関して、
以下に示す２通りのアプローチがある。第１のアプロー
チの方法は、コネクション型データ通信を基に設計され
た従来のＡＴＭ交換システムにおいて、コンピュータ間
のデータ通信を、コネクション型データ通信で実現しよ
うという方法である。第２のアプローチの方法は、コネ
クション型データ通信を基に設計された従来のＡＴＭ交
換システムにおいて、コンピュータ間のデータ通信を、
従来のコンピュータ間のデータ通信と同じようにコネク
ションレス型データ通信で実現しようという方法であ
る。
【００６７】第１のアプローチの方法には、前述した通
り、以下のような問題点がある。まず、１つ目の問題点
は、コンピュータ間のデータ通信をコネクション型のデ
ータ通信で実行した場合、呼設定に要する時間のための
データ転送効率の低下である。２つ目の問題点は、ＣＬ
ＳＦ処理でコンピュータ間のデータ通信を行った場合、
ＣＬＳＦ処理にコンピュータ間のデータ通信の集中によ
るコンピュータ間のデータ通信のエンド・エンド間での
遅延の増大と、コンピュータ間のデータ通信用のセルの
廃棄の増大である。また、従来のコンピュータ間のデー
タ通信は、コネクションレス型のデータ通信として発展
し、現在、コネクションレス型のデータ通信方法として
の資産が相当多く存在するが、第１のアプローチの方法
を採用した場合、前記従来のコネクションレス型のデー
タ通信における過去の資産をどう引き継いでいくかに問
題点が存在する。
【００６８】一方、第２のアプローチを採用した場合、
前記したコンピュータ間のデータ通信におけるコネクシ
ョンレス型データ通信の過去の資産をそのまま引き継ぐ
ことができるので、ＡＴＭ交換システムにおいて、従来
方法によるコンピュータ間のデータ通信が行えるという
大きな利点がある。しかし、コネクション型データ通信
を基に設計された従来のＡＴＭ交換システムにおいて、
コンピュータ間のデータ通信に対し、コネクションレス
型のデータ通信を基に設計された従来のコンピュータ間
のデータ通信方法をそのまま適用することはできず、従
来のコンピュータ間のデータ通信方法を、従来のＡＴＭ
交換システムに合うように改造しなければならない。ま
たは、逆に、従来のＡＴＭ交換システムを、従来のコン
ピュータ間のデータ通信方法に合うように改造しなけれ
ばならない。
【００６９】以下、従来のＡＴＭ交換システムで、従来
方法によるコンピュータ間通信を行う場合の問題点につ
いて、具体的に説明する。
【００７０】第１の問題点は、呼設定が終了するまで、
データ転送が開始できないことによるデータ転送の効率
の低下である。従来のＡＴＭ交換システムで、コンピュ
ータ間のデータ通信を行う場合、データ転送に先だって
呼設定が行われなければならず、データ転送に比べて呼
設定に時間が要する場合、データ転送の効率が低下して
しまうという問題点があった。
【００７１】この問題点自体は、平成５年３月の信学会
ＩＮ研究会で発表された「ＡＴＭ−ＬＡＮにおけるデー
タ転送実現法（江崎、津田、夏堀）」で示されたよう
な、ネットワークに接続された端末(Host)間に予めコネ
クションを設定しておいて、データ通信を行う必要の生
じた端末(Host)は、前記コネクションを用いてデータ転
送を行うという方法を採用することで解決される。すな
わち、サブネットワーク内、サブネットワーク外のコン
ピュータ間のデータ通信を行う端末(Host)間に、ＱＯＳ
の保証を必要としないコネクションを予め設定してお
き、前記端末が前記データ通信を行う必要が生じた時
に、前記コネクションを用いることによって、呼設定を
行わずにデータ通信を行うことができる。この方法によ
れば、データ通信に際し、呼設定を行い、呼設定の終了
までデータ転送を待つ必要がないので、レイテンシに対
して要求の厳しいコンピュータ間のデータ通信も、効率
よく実行することができる。しかし、この方法において
は、セルに書かれたＶＰＩによって、前記予め設定され
たＱＯＳの保証を必要としないコネクションが識別され
る（ＶＰルーティング) ため、データ送信端末は、前記
コネクションを用いてデータ転送を行う場合、前記コネ
クションに対応するＶＰＩを、何らかの手段を用いて獲
得しなければならない。上記方法においては、前記デー
タ送信端末が、ＡＲＰ要求セルをサブネットワークにブ
ロードキャストし、相手端末あるいはＡＲＰサーバー
が、ＡＲＰ応答セルを前記端末に送り返すことによっ
て、前記コネクションに対応するＶＰＩを前記端末が獲
得する。それゆえ、上記方法には、ＡＲＰ要求セルをサ
ブネットワークにブロードキャストする際に、網のブロ
ードキャスト機能を使用する問題点と、スター型のネッ
トワークの場合、宛先の端末にブロードキャストしてデ
ータを送信できるからといって、シングルキャストし
て、該宛先の端末にデータが届くかどうか保証ができな
いといった問題点と、未知ＶＰＩに対して、ＡＲＰ応答
セルを端末が受信するまでデータ転送を開始することが
できないといった問題点があった。
【００７２】第２の問題点は、従来のコンピュータ間の
データ通信方法は、ネットワークにブロードキャスト機
能があることを前提として、データ通信方法が構築され
ていることである。
【００７３】第２の問題点に対しては、従来のＡＴＭ交
換システムにおいて、何らかの方法によって、網にブロ
ードキャスト機能を持つことによって、コンピュータ間
のデータ通信を従来の方法で行うという対処方法が考え
られる。例えば、前述したように、コピースイッチ、コ
ピー機能を提供するコピー手段、またはコピーサーバー
を実装することによって、網にブロードキャスト機能を
持つことができる。しかし、これらの対処方法ではそれ
ぞれ新たな問題点を生ずる。以下、各々の機能を網に実
装した場合の問題点について、具体的に説明する。
【００７４】まず、セルスイッチの代わりに、コピース
イッチを採用することによって、該コピースイッチで、
ブロードキャスト機能を実行するという方法を採用した
場合、すでに説明した通り、以下のような問題点があっ
た。すなわち、コピースイッチの出力ポートは、コピー
コネクションに属するセルと、コピーコネクションに属
しないセルのうち、いずれかを選択して出力しなければ
ならず、前記出力ポートのアルゴリズムが複雑になって
しまい、コピースイッチは、その分、セルスイッチより
高価になってしまうという問題点があった。また、コピ
ースイッチをＬＳＩ化する場合、ＬＳＩに入るコピーセ
ル用バッファの大きさには制限があるので、コピーセル
用バッファの大きさを十分大きくすることはできず、コ
ピーコネクションに属するセルは、オーバーフローしや
すく、廃棄されやすいといった問題点があった。また、
前記セルが廃棄された場合、クライアントは、前記セル
のタイムオーバー後、再びブロードキャスト・セルを再
送するので、クライアントにとっては、タイムオーバー
するまで待つことによる遅延の増大という問題点を引き
起こし、網にとっては、ブロードキャスト・セルの再送
によって、ブロードキャスト・セルの増大といった問題
点があった。
【００７５】また、セルスイッチにコピー手段を付加
し、該コピー手段でブロードキャスト機能を実行する方
法を採用した場合、前述した通り以下のような問題点が
あった。すなわち、コピー手段の場合、コピースイッチ
の場合に比べて、より大きなコピーセル用バッファを実
装することができるが、コピー手段に実装することので
きるコピーセル用バッファの大きさは有限であるので、
コピーコネクションに属するセルは廃棄されやすいとい
った問題点があった。また、コピー手段の出力が１つし
かない場合、同時には、１つのセルしかコピーし出力す
ることができないので、コピーコネクションに属するセ
ルの、エンド・エンド間のブロードキャスト・サービス
に時間がかかってしまう、といった問題点があった。さ
らに、スイッチ規模が大きい場合や、他のＡＴＭ交換機
にコピー機能がない時に、他の交換機に対してもコピー
機能を提供しなければならず、コピーセル用バッファに
入力されたセルに対し、コピーし出力しなければならな
い回数が増大してしまうといった問題点があった。従っ
て、この場合、エンド・エンド間のブロードキャスト・
サービスの遅延の増大と、バッファにセルが滞留する時
間の増大による、コピーコネクションに属するセルの廃
棄の増大と、そして、前記セル廃棄の問題点に対して、
コピーセル用バッファを大きくしなければならないとい
った問題点があった。
【００７６】一方、ＡＴＭ交換システムに属する端末(H
ost)の１つをコピーサーバーとし、前記コピーサーバー
によって、網のブロードキャスト・サービスを行う方法
を採用した場合、コピーセル用バッファに対する問題点
は事実上解消するが、前述した通り、以下のような問題
点は解決することができない。すなわち、コピーサーバ
ーの場合、出力が１つしかないので、同時には１つのセ
ルしかコピーし出力することができず、エンド・エンド
間のブロードキャスト・サービスに時間がかかってしま
うといった問題点があった。また、通常のコピーサーバ
ーの実装では、コピーサーバーは、ＯＳ上の１つのソフ
トウェア・プロセスとして実装されるので、コピーサー
バーにおいて１つのセルをコピーし出力するのに時間が
かかってしまうといった問題点があった。
【００７７】以上説明してきた問題点は、従来のＡＴＭ
交換システムにおける、コピー機能の実装形態上の問題
点であったが、実装形態以外にも、コピーアルゴリズム
にも、以下のような問題点が存在する。
【００７８】図６７（ａ）は、単純なブロードキャスト
・アルゴリズムを採用した場合の、交換機に入力された
ブロードキャスト・コネクションに属するセルの流れを
示したものである。単純なブロードキャスト・アルゴリ
ズムを採用した場合、交換機に入力されたブロードキャ
スト・コネクションに属するセルは、図示したように、
セルスイッチ９１８に接続したすべての後処理部９１９
1 ，９１９2 ，９１９ 3 ，９１９4 へ出力されるよう
に、セルスイッチ９１８内でコピーされる。従って、前
記したアルゴリズムを採用した場合、ブロードキャスト
・コネクションに属するセルが入力されたポートと同じ
ポートに存在する後処理部９１９1 にも、該コピー・セ
ルが転送されるという問題点があった。従って、前記し
たアルゴリズムを採用した場合、図６７（ｂ）におい
て、交換機９２０から交換機９２１に、ブロードキャス
ト・コネクションに属するセルが入力された場合、交換
機９２１内で前記セルに対してコピーが行われた結果、
交換機９２０にも、再びコピーセルが転送されてしまう
といった問題点があった。
【００７９】この問題点は、前記単純なブロードキャス
ト・アルゴリズムに、ブロードキャスト・コネクション
に属するセルが入力された前処理部と同じポートに存在
する後処理部には転送しないアルゴリズムを付加するこ
とによって、解決することができる。しかし、該アルゴ
リズムを採用することで、セルスイッチは、前処理部ご
とに、前記前処理部に対応するブロードキャスト・アル
ゴリズム（ブロードキャスト・コネクションに属するセ
ルが入力された前処理部と同じポートに存在する後処理
部には、前記セルをコピーしたセルを転送しないという
アルゴリズム）を持たなければならず、１つのブロード
キャスト・アルゴリズムで、簡単にブロードキャスト・
サービスを提供することができないといった問題点があ
る。
【００８０】また、ＡＴＭ交換システムの交換機間の接
続にループが存在する場合、ループの影響を考慮しな
い、ブロードキャスト・アルゴリズムを採用した場合、
前記ループによって、ブロードキャスト・ストームが発
生してしまうといった問題点がある。すなわち、図６７
（ｃ）において、交換機９２５に、ブロードキャスト・
コネクションに属するセルが入力された場合、交換機９
２５のブロードキャスト・アルゴリズムによって、コピ
ーセルが交換機９２６に転送され、交換機９２６のブロ
ードキャスト・アルゴリズムによって、コピーセルが交
換機９２７に転送される。交換機９２７に転送されたコ
ピーセルが、交換機９２７のブロードキャスト・アルゴ
リズムによって、交換機９２６に転送された結果、再
び、交換機９２５のブロードキャスト・アルゴリズムに
よって、コピーセルが交換機９２６に転送されてしまう
という、ブロードキャスト・ストームの発生といった問
題点があった。また、前記ネットワーク内の経路にルー
プが存在する場合を考慮した、ブロードキャスト・アル
ゴリズムは複雑であり、簡単なアルゴリズムで、ブロー
ドキャスト・コネクションを提供することができない、
といった問題点があった。
【００８１】さらに、何らかの方法によって、網にブロ
ードキャスト機能を持つことによって、コンピュータ間
のデータ通信を、従来の方法で行う場合、以下のような
問題点も存在する。
【００８２】前記したように、従来のコンピュータ間の
データ通信方法において、網のブロードキャスト機能を
使用するのは、クライアントが、サーバーに対して要求
を出す場合のみであった。すなわち、ＡＲＰにおいて
は、MAC アドレスを獲得したいクライアントが、MAC ア
ドレスを獲得するために、網のブロードキャスト機能を
使用し、ＮＩＳにおいては、ＮＩＳサーバーのIPアドレ
スを知らないＮＩＳクライアントが、ＮＩＳサーバーの
IPアドレスを獲得するために、網のブロードキャスト機
能を使用する。また、ディスクレス・クライアントは、
ブートサーバーのIPアドレス等を獲得するために、網の
ブロードキャスト機能を使用していた。従って、従来の
コンピュータ間のデータ通信方法においては、サーバー
のアドレス等がわからない場合にのみ、クライアント
は、網のブロードキャスト機能を用いて、サーバーとデ
ータ通信が行われる。従って、ブロードキャストされた
データは、前記データをブロードキャストしたクライア
ントのサーバーにおいてのみ有効であり、前記サーバー
以外の端末(Host)においては、前記データは意味をなさ
ないので、前記サーバー以外の端末(Host)が、前記ブロ
ードキャストされたデータを受信した場合、前記データ
は参照されずに廃棄されるといった問題点も存在する。
【００８３】一方、すでに説明したように、端末のネッ
トワーク・インターフェースは、端末のMAC アドレスと
ブロードキャスト・アドレスのみ認識し、受信パケット
のうち、前記アドレスが宛先に書かれたパケットのみ、
前記インターフェース内に取り込む。前記インターフェ
ース内に取り込まれたパケットのうち、定義されたプロ
トコルに従って、受信パケットの情報フィールドのみ、
データ受信バッファから、端末の記憶メモリに転送さ
れ、端末のＯＳ上のプロトコル処理プロセスによって処
理されている。また、受信データの中には、端末での処
理のレイテンシに対して要求の厳しい場合（ＡＲＰ、Ｎ
ＩＳ等) が存在するので、処理中のプロセスの実行を中
断して、受信データに対して処理を行う場合も存在す
る。
【００８４】従って、前記サーバー以外の端末(Host)
が、前記ブロードキャストされたデータを受信した場
合、実行中のプロセスを中断して、前記データに対して
処理を行うが、前記端末にとっては、前記データは意味
をなさないため、前記データに対して何も処理が行われ
ずに処理が終了してしまう。その結果として、前記サー
バー以外の端末(Host)にとって、前記ブロードキャスト
されたデータを受信することによって、実行中のプロセ
スの中断により処理効率が低下するといった問題点があ
った。
【００８５】
【発明が解決しようとする課題】以上述べてきた従来の
ＡＴＭ交換システムにおいて、特に解決が望まれている
問題点としては、以下のことが考えられる。
【００８６】ネットワークの管理を行う複数のサービス
提供装置のうち、１つをマスターモードで動作させ、他
をスレーブモードで動作させ、それらサービス提供装置
の協調動作でネットワーク全体の管理をするネットワー
ク・システムにおいて、従来は、マスターモードのサー
ビス提供装置が動作停止すると、協調動作ができなくな
るため、ネットワーク全体が機能停止してしまうという
問題点があった。
【００８７】本発明は、上記課題を解決するためになさ
れたものであり、マスターモードで動作するサービス提
供装置が動作停止しても、ネットワーク全体の機能停止
を回避できるサービス提供装置の動作方法を提供するこ
とを目的とする。
【００８８】
【課題を解決するための手段】また、本発明は、複数の
端末を含むサブシステムを複数相互に接続して構成し、
各サブシステム内にはその内に含まれる端末を管理する
サービス提供装置をそれぞれ備えたネットワークにおけ
るサービス提供装置の動作方法であって、前記サービス
提供装置のうちの１つをマスターモードのサービス提供
装置とし、当該マスターモードのサービス提供装置がマ
スターとしての動作を正常に行っている間は、他のサー
ビス提供装置がスレーブモードの動作を行うことによっ
て、全サービス提供装置が協調してサブシステム間にま
たがる前記管理を行い、前記マスターモードのサービス
提供装置がマスターモードとしての動作を正常に行わな
くなった場合には、各サービス提供装置はシングルモー
ドにモード遷移して、自己の属するサブシステム内で閉
じた前記管理を行うことを特徴とする。
【００８９】本発明によると、１つのシステムが複数の
サービス提供装置（例えば、ＮＩＳサーバーやＤＮＳサ
ーバーなど）によって、協調的に管理される分散環境化
において、新たに、前記サービス提供装置が起動した場
合で、起動手順に起動後の状態としてマスターモードと
書かれていた場合、前記サービス提供装置は、起動後、
マスターモードへ状態遷移し、必要に応じて、スレーブ
モードのサービス提供装置へ指示を行って、システム全
体の管理を行うことができる。
【００９０】また、起動手順に、起動後の状態としてス
レーブモードと書かれていた場合、前記サービス提供装
置は、起動後、該サービス提供装置の帰属先のマスター
モードのサービス提供装置が正常に動作していることを
確認した後、スレーブモードへと状態遷移することがで
き、マスターモードのサービス提供装置の指示に従っ
て、該サービス提供装置に割り当てられた部分システム
の管理を行うことができる。
【００９１】該サービス提供装置の帰属先のマスターモ
ードのサービス提供装置が正常に動作していることを確
認できなかった場合、以後、定期的に、帰属先のマスタ
ーモードのサービス提供装置が正常に動作し始めたかど
うか検査を行い、前記マスターモードのサービス提供装
置が正常に動作し始めるまで、該サービス提供装置はシ
ングルモードとして動作し、該サービス提供装置に割り
当てられた部分システムの管理を行うことができる。該
シングルモードとして動作中のサービス提供装置が、帰
属先のマスターモードのサービス提供装置が正常に動作
し始めたことを確認できた場合、該サービス提供装置
は、シングルモードとして動作中にどういう管理処理を
行ったかを、マスターモードのサービス提供装置に通知
し、スレーブモードへと状態遷移することができる。
【００９２】また、スレーブモードで動作中のサービス
提供装置は、定期的に、マスターモードのサービス提供
装置が正常に動作しているか検査を行い、正常動作を確
認できた場合は、スレーブモードで動作し続けるが、正
常動作を確認できなかった場合、シングルモードへと状
態遷移し、該サービス提供装置に割り当てられた部分シ
ステムに対し、部分システムの管理を行うことができ
る。以後、定期的に、帰属先のマスターモードのサービ
ス提供装置が正常に動作し始めたかどうか検査を行い、
帰属先のマスターモードのサービス提供装置が正常に動
作し始めたことを確認できた場合、該サービス提供装置
は、シングルモードとして動作中にどういう管理処理を
行ったかを、マスターモードのサービス提供装置に通知
し、スレーブモードへと状態遷移することができる。
【００９３】該シングルモードとして動作中のサービス
提供装置が、帰属先のマスターモードのサービス提供装
置が正常に動作し始めたことを確認できた場合、該サー
ビス提供装置は、シングルモードで動作中にどういう管
理処理を行ったかを、マスターモードのサービス提供装
置に通知し、スレーブモードへと状態遷移することがで
きる。
【００９４】これによって、従来のモードが固定されて
いたマスター／スレーブ・システムと異なり、マスター
モードのサービス提供装置が正常に動作しなくなった場
合、該システムに対して、サービスの提供が停止してし
まうといった不具合を回避することができる。また、本
発明によれば、比較的簡単な方法によって、障害の発生
したマスターモードのサービス提供装置を復帰させ、す
みやかに前記協調的管理を復旧させることができる。
【００９５】
【発明の実施の形態】以下、図面を参照しながら発明の
実施の形態を説明する。なお、説明の便宜上、次の４項
目に分けて説明する。 （１）本発明に係るネットワーク・システムの構成 （２）本発明に係るＶＰＩ／ＶＣＩ割り当てアルゴリズ
ム （３）サブネット内に複数のノードが存在する場合につ
いて （４）サブネット間のデータ通信について １．本発明に係るネットワーク・システムの構成 図１は、本発明の一実施例に係るネットワーク・システ
ムの構成を示したものである。ＡＴＭを用いたローカル
・エリア・ネットワーク（ＬＡＮ）を、本発明に係るネ
ットワーク・サーバーで構成する場合、基本的に、以下
の４つのネットワーク・サーバーで構成することができ
る。 （ａ）ノード設定サーバー(node setup server) （ｂ）ノード管理サーバー(node managing server) （ｃ）各種ネームサーバー(name server) （ｄ）呼設定サーバー(call setup server) 以下、図１について概略を説明した後、下記した場合に
ついて、前記４つのネットワーク・サーバーの動作を具
体的に説明する。 （1-1 ）ＬＡＮのブートについて（シングル・ノードの
場合) （1-2 ）端末のブートについて （1-3 ）ディスクレス・クライアントのブートについて （1-4 ）ＡＲＰ、ＮＩＳについて （1-5 ）呼設定について （1-6 ）予め設定されたコネクションを用いたデータ通
信について （1-7 ）保守・管理について まず、図１について、概略的な説明をする。なお、図１
において実際は、ＡＴＭ交換機２はネットワークサーバ
ー１と端末３との間に設けられるが、説明の便宜上、図
１のように示してある。
【００９６】ノード設定サーバー（node setup server)
４は、クライアント（すなわちノード管理サーバー５）
からの要求を受け付け、ルーティングタグ・テーブル等
のハードウェア２４に対し、直接、書き込んだり／読み
出したりすることによって、ハードウェアの設定等を実
行する。また、クライアント（ノード管理サーバー５）
からの要求によって、ＯＡＭ情報が書き込まれたレジス
タからの読み出し等を行う。
【００９７】ノード管理サーバー（node managing serv
er) ５は、主として、ノード（すなわちＡＴＭ交換機
２）の管理を実行する。すなわち、ＡＴＭ交換機２の入
出力線の先に端末が接続されているか否かを監視し、入
出力線の先に端末が接続された場合、コンフィグュエー
ション・ファイル（以下、configファイルと記す）５５
に書き込まれている情報に従って、ＡＴＭ交換機２内の
ルーティングタグ・テーブル等のハードウェア設定を実
行する。また、ノード管理サーバー５は、クライアント
（呼設定サーバー７）からの、コネクションの設定要求
を受け付け、対応するノード設定サーバー４に対して、
ハードウェア等の設定要求を送信する。また、ノード管
理サーバー５は、ＡＴＭ交換機２内のルーティングタグ
・テーブルといったハードウェアの保守・管理を実行す
るとともに、対象とするノード（ＡＴＭ交換機2)を経由
するコネクションに対して、ＯＡＭセルの送受信といっ
た、ＯＡＭ機能を実行したりする。
【００９８】各種ネームサーバー(name server) ６０１
は、宛先端末名（例えば、ホストネーム、ＩＰアドレ
ス、電話番号等) をキーとして、宛先アドレス（例え
ば、ＶＰＩ／ＶＣＩ）の検索といった、クライアント
（例えば、ＮＩＳクライアント６１) からの要求を受け
付け、前記ネームサーバーが管理するテーブルを検索
し、検索した結果得られた情報を、クライアントに送信
する。本発明を、ＮＩＳを用いない、宛先またはコネク
ションの管理方法に適用することも可能であるが、以
下、本発明の一実施例を具体的に説明するために、ＮＩ
Ｓを用いた、宛先またはコネクションの管理方法につい
て説明する。
【００９９】呼設定サーバー(call setup server) ７
は、クライアント（すなわち端末３）からの呼設定要求
を受け付け、対応するノード管理サーバー５に対し、コ
ネクションの設定を要求する。また、サブネットワーク
外の端末への呼設定要求を、該呼設定サーバー７が受け
付けた場合、サブネットワーク内のコネクションの設定
を、該サブネットワーク内のノード管理サーバー５に要
求するとともに、サブネットワーク外の対応するノード
管理サーバーに対し、呼設定要求のリレーイングを行
う。
【０１００】図１に図示したように、端末３とネットワ
ーク・サーバーとの間には、ブート・チャネル１１、メ
タシグナリング・チャネル１０、インフォメーション・
チャネル１２、シグナリング・チャネル１３の４種類の
チャネルが設定されていて、本発明においては、端末
は、前記４種類のチャネルを用いて、ネットワーク・サ
ーバーとデータ通信を行うことを想定している。
【０１０１】前記４種類のチャネルのうち、ブート・チ
ャネル１１とメタシグナリング・チャネル１０は、ネッ
トワーク（ＡＴＭ交換システム) の立ち上げ時に、ＡＴ
Ｍ交換機２のすべての入出力線に対して、前記入出力線
の先に接続されるであろう端末と対応するノード管理サ
ーバーとの間に設定されるものとする。ネットワーク
（ＡＴＭ交換システム) の立ち上げ終了後、ＡＴＭ交換
機２の入出力線の先に接続された端末が起動した場合、
該端末は、必要に応じてブート・チャネル１１またはメ
タシグナリング・チャネル１０を用いて、対応するノー
ド管理サーバーに前記端末の起動に必要な情報を要求
し、該端末は、前記チャネルを用いて前記情報を手に入
れることを想定している。本発明の一実施例において
は、具体的に説明するために、ブート・チャネル１１と
メタシグナリング・チャネル１０は２つの異なるチャネ
ルとして記述しているが、前記２つのチャネルが同一の
一つのチャネルとして、ネットワーク・サーバーを構成
することも可能である。
【０１０２】また、前記４種類のチャネルのうち、イン
フォメーション・チャネル１２とシグナリング・チャネ
ル１３は、端末３の起動時等に必要に応じて、前記端末
３と対応するネットワーク・サーバーとの間に設定され
るものとする。前記端末３が、コンピュータ等の端末の
場合で、ネーム・サーバー６０１とデータ通信を行う必
要のある端末であるとき、前記端末３の起動時等に、前
記端末３と対応するネーム・サーバーとの間にインフォ
メーション・チャネル１２が設定され、前記端末３は、
前記チャネルを用いて前記ネーム・サーバーとデータ通
信を行う、ということを想定している。また、前記端末
３が、ＡＴＭ端末等の場合で、新たに呼設定を行う必要
のある端末であるとき、前記端末の起動時等に、前記端
末と対応する呼設定サーバー７との間にシグナリング・
チャネル１３が設定され、前記端末３は、前記チャネル
を用いて前記呼設定サーバー７とデータ通信を行うこと
を想定している。
【０１０３】１−１．ＬＡＮのブートについて（シング
ル・ノードの場合) 次に、図２を参照しながら、１つのノード（ＡＴＭ交換
機）によって、ＬＡＮ(Local Area Network)が構成され
る場合のＬＡＮのブート方法について、具体的に説明す
る。なお複数のノード（ＡＴＭ交換機) によって、ＬＡ
Ｎが構成される場合については、(4) 節で後述する。
【０１０４】本発明の一実施例においては、４つのネッ
トワーク・サーバーでＬＡＮを構築することを目指して
いる。４つのネットワーク・サーバーの起動順序として
は、いろいろな順序が存在するが、本発明の一実施例に
おいては、まず、ノード管理サーバー５が起動し、次
に、ノード設定サーバー４が起動し、最後に、ネーム・
サーバーと呼設定サーバーが起動する起動順序を例にと
って、以下、ＬＡＮのブート手順を具体的に説明する。
【０１０５】まず、図２において、ノード管理サーバー
５内のＡＴＭブートプロセス５２が起動することによっ
て、ノード管理サーバー５は起動される。次に、前記Ａ
ＴＭブートプロセス５２は、ノード設定サーバー４を起
動するとともに、ノード管理サーバー５に付属するＨＤ
(HardDisc)中の管理ファイル５６の初期化を実行する。
ノード設定サーバー４は、起動処理中に、前記ノード設
定サーバー４に付属するＨＤが存在する場合、ＨＤ中の
バックアップ・ファイル（以下、backupファイルと記
す）４２の初期化と、ＡＴＭ交換機２内に存在するルー
ティングタグ・テーブル等のハードウェア・テーブル等
の初期化を実行する。
【０１０６】次に、前記ＡＴＭブートプロセス５２は、
ノード管理サーバー５内に、端末ブートプロセス５３を
起動するとともに、ノード設定サーバー４に、ＡＴＭ交
換機２のすべての入出力線に対し、前記入出力線の先に
接続されるであろう端末と、前記ノード管理サーバー５
内の端末ブートプロセス５３との間にブートチャネル１
１の設定を、前記ノード設定サーバー４に要求する。同
様に、前記ＡＴＭブートプロセス５２は、ノード管理サ
ーバー５内に、端末メタシグナリング・プロセス５４を
起動するとともに、ＡＴＭ交換機２のすべての入出力線
に対し、前記入出力線の先に接続されるであろう端末
と、前記ノード管理サーバー５内の端末メタシグナリン
グ・プロセス５４との間にメタシグナリング・チャネル
１０の設定を、前記ノード設定サーバー４に要求する。
【０１０７】本発明に係るＡＴＭ交換システムにおいて
は、端末が、ブートチャネル１１またはメタシグナリン
グ・チャネル１０等を用いて、ノード管理サーバー５等
に要求を送信する場合、端末ごとに固有のチャネル番号
を使用するのではなく、同一のチャネル番号（例えば、
ｗｅｌｌ−ｋｎｏｗｎチャネル番号）を使用しても良
い。例えば、メタシグナリング・チャネル１０を使用す
る場合は、ＶＰＩ／ＶＣＩ＝１を用い、ブート・チャネ
ル１１を使用する場合は、ＶＰＩ／ＶＣＩ＝ａｌｌ
１、あるいはＶＰＩ／ＶＣＩ＝（特定の値）を用いても
良い。同一のチャネル番号を使用する場合、ＡＴＭ交換
機の入出力線の先に接続された端末からＡＴＭ交換器に
該セルが入力されたとき、どの端末から送信されたセル
かを識別できるようにするために、該ＡＴＭ交換機内で
該セルのＶＰＩ／ＶＣＩ値を書き替えるように、ノード
管理サーバ５がノード設定サーバ４に対しＡＴＭ交換機
内のルーティングタグ・テーブル等の設定を行えば、ノ
ード管理サーバ５は、端末から該セルを受信した場合、
受信したセルのＶＰＩ／ＶＣＩ値等を調べることによっ
て、どの端末あるいはＡＴＭ交換機のどの入力線の先に
接続された端末から、該セルが送信されてきたかを識別
できる。
【０１０８】端末３がコンピュータ等の端末(Host)の場
合で、前記端末の起動の際、ホストネーム、ホストＩＰ
アドレス、ルートファイルシステムが存在する端末名と
いった、ネットワーク情報を必要とする場合が存在す
る。本発明の一実施例においては、前記したようなコン
ピュータ等の端末が対象とするＡＴＭ交換機２に接続さ
れ起動する場合、以下に示す手順で、前記コンピュータ
等の端末が起動に必要なネットワーク情報を手に入れる
ことを想定している。すなわち、まず、前記コンピュー
タ等の端末３が、前記ブートチャネル１１を用いて、ノ
ード管理サーバー５内に存在する端末ブートプロセス５
３に、ブート用セル（例えば、ＢＯＯＴＰセル) を送信
し、前記端末３の起動に必要なブートイメージの転送を
要求する。端末ブートプロセス５３は、ブート用セルを
受信した場合、configファイル５５を参照し、前記ブー
ト用セルを送信した端末３に対応するブートイメージ
を、前記ブートチャネル１１を用いて前記端末３に転送
することによって、前記コンピュータ等の端末３は、起
動に必要なネットワーク情報を手に入れることができ
る。
【０１０９】ＡＴＭ端末等の端末３が、ＡＴＭ交換機２
に接続され起動する場合、前記端末３から、メタシグナ
リング・セルがメタシグナリング・チャネル１０に送信
され、シグナリング・チャネルの設定と、シグナリング
・セルに用いるためのＶＰＩ／ＶＣＩ値等の情報の転送
とを要求する。本発明の一実施例においては、前記ＡＴ
Ｍ端末等の端末３が対象とするＡＴＭ交換機２に接続さ
れ起動する場合、以下に示す手順で、前記端末３が起動
に必要なシグナリング・チャネルの設定等を要求するこ
とを想定している。すなわち、まず、前記端末３が、前
記メタシグナリング・チャネル１０を用いて、ノード管
理サーバー５内に存在する端末メタシグナリング・プロ
セス５４にメタシグナリング・セルを送信し、前記端末
３の起動に必要なシグナリング・チャネルの設定を要求
する。端末メタシグナリング・プロセス５４は、該メタ
シグナリング・セルを受信した場合、configファイル５
５を参照し、前記メタシグナリング・セルを送信した端
末３に対応するシグナリング・チャネルの設定等を行
い、前記端末３が、前記シグナリング・チャネルを使用
するためのＶＰＩ／ＶＣＩ値等の情報を、前記メタシグ
ナリング・チャネル１０を用いて、前記端末３に転送す
ることによって、前記端末３は、起動に必要な情報を手
に入れることができる。
【０１１０】前記した端末の起動手順において、端末３
の起動に際し、ブートチャネル１１を用いて、ノード管
理サーバー５内に存在する端末ブートプロセスから５
３、ブート・イメージを手に入れて、メタシグナリング
・チャネル１０を用いて、ノード管理サーバー５内に存
在する端末メタシグナリング・プロセス５４に対し、シ
グナリング・チャネルの設定要求と、前記シグナリング
・チャネルを使用するためのＶＰＩ／ＶＣＩ値等の情報
の転送を要求してもよい。
【０１１１】また、前記した端末の起動手順において、
コンピュータ等の端末３に対し、前記端末３の起動に必
要な情報の要求と転送にブートチャネル１１を用い、Ａ
ＴＭ端末等の端末３に対し、前記端末３の起動に必要な
シグナリング・チャネルの設定と前記シグナリング・チ
ャネル等の使用情報等の転送にメタシグナリング・チャ
ネル１０を用いているが、どちらか一方のチャネル（例
えば、メタシグナリング・チャネル１０) を用いて、両
方の用途に用いてもよい。本発明の一実施例において
は、コンピュータ等の端末の起動とＡＴＭ端末等の起動
とを明確に記述するために、２つのチャネル（ブートチ
ャネル１１とメタシグナリング・チャネル１０) を用い
た。
【０１１２】また、図２には図示していないが、ノード
管理サーバー５とノード設定サーバー４が起動した後、
ネームサーバー（例えば、ＮＩＳサーバー）と呼設定サ
ーバーが起動される。同一端末(Host)３上に、４つのサ
ーバー（ノード管理サーバー５、ノード設定サーバー
４、ネームサーバー、呼設定サーバー) を起動する場
合、例えば、ノード管理サーバー５内のconfigファイル
５５に、ネームサーバーと呼設定サーバーの起動手順を
書き込んでおき、ノード管理サーバー５内のＡＴＭブー
トプロセスが前記configファイル５５を読み出して前記
ネームサーバーと呼設定サーバーを起動することによっ
て、前記４つのサーバーを起動することができる。ま
た、前記４つのサーバーが同一の端末上に存在する場
合、サーバー間のデータ通信はプロセス間通信等を用い
て行うことができる。
【０１１３】次に、４つのサーバー（ノード設定サーバ
ー、ノード管理サーバー、ネームサーバー、呼設定サー
バー) が同一の端末上に存在しない場合のネットワーク
・サーバーの起動方法、およびサーバー間のデータ通信
方法について、図３を参照しながら説明する。
【０１１４】前記４つのサーバーが同一の端末上に存在
しない場合、前記４つのサーバー間のデータ通信は、Ａ
ＴＭ等のデータ通信手段を用いて行わなければならな
い。まず、ノード設定サーバー４とノード管理サーバー
５との間のデータ通信路設定用の設定用チャネルとし、
同様に、ノード管理サーバー５とネームサーバー（例え
ば、ＮＩＳサーバー６）との間のデータ通信路をＮＩＳ
用チャネル（１７）と、ノード管理サーバー５と呼設定
サーバー７との間のデータ通信路を呼設定用チャネル
（１８）とそれぞれ定義して、前記４つのサーバーの起
動方法および前記チャネルの設定方法について具体的に
説明する。
【０１１５】まず、ノード設定サーバー４とノード管理
サーバー５が同一の端末上に存在しない場合の前記２つ
のサーバーの起動方法と、前記２つサーバー間のデータ
通信路である設定用チャネルの設定方法について説明す
る。ノード設定サーバー４とノード管理サーバー５が同
一の端末上に存在する場合は、例えば、ノード管理サー
バー５の起動手順において、ノード設定サーバー４を起
動することができた。しかし、前記２つのサーバーが同
一の端末上に存在しない場合は、前記した方法を採用す
ることはできず、前記２つのサーバーは、例えば、個々
の端末の起動手順において起動しなければならない。従
って、ノード管理サーバー５は、前記２つのサーバーの
起動後、設定用チャネルを用いて、ノード設定サーバー
４に、ＡＴＭ交換機２内のルーティングタグ・テーブル
等の初期化と、ＡＴＭ交換機２のすべての入出力線の先
に接続されるであろう端末とノード管理サーバー５内の
端末ブートプロセス５３との間のブート・チャネル１１
と、前記端末３とノード管理サーバー５内の端末メタシ
グナリング・プロセス５４との間のメタシグナリング・
チャネル１０等の設定を要求することになる。また、前
記設定用チャネルは、以下に示すような３通りの方法で
設定することができる。すなわち、１つ目の方法は、ノ
ード設定サーバー４の起動時に、ＡＴＭ交換機２のすべ
ての入出力線の先に接続されるであろう端末３と、ノー
ド設定サーバー４内の設定プロセス４１との間に、ＶＰ
Ｉ／ＶＣＩ値に特別な値を持つ設定用チャネルを設定す
る方法である。２つ目の方法は、ノード設定サーバー４
の起動時に、ＡＴＭ交換機２の特定の入出力線の先に接
続されるであろう端末と、ノード設定サーバー４内の設
定プロセス４１との間に、ＶＰＩ／ＶＣＩ値に特別な値
を持つ設定用チャネルを設定する方法である。３つ目の
方法は、ノード設定サーバー４の起動後、前記ノード設
定サーバー４に対してコマンド投入等の方法を用いて、
ＡＴＭ交換機２の特定の入出力線の先に接続される端末
３上のノード管理サーバー５と、前記ノード設定サーバ
ー４内の設定プロセス４１との間に、ＶＰＩ／ＶＣＩ値
に特定値を持つ設定用チャネルを設定する方法である。
【０１１６】次に、ネームサーバー（例えば、ＮＩＳサ
ーバー６）の起動と、ＮＩＳサーバー６とノード管理サ
ーバー５との間のデータ通信路であるＮＩＳ用チャネル
１７の設定方法について説明する。前記したように、ノ
ード設定サーバー４とノード管理サーバー５の起動時
に、ＡＴＭ交換機２のすべての入出力線の先に接続され
るであろう端末と、ノード管理サーバー５内の端末ブー
トプロセス５３との間にブート・チャネル１１が、ま
た、前記すべての入出力線の先に接続されるであろう端
末と、ノード管理サーバー５内の端末メタシグナリング
・プロセス５４との間にメタシグナリング・チャネル１
０が設定される。従って、前記ＡＴＭ交換機２の入出力
線の先に接続される端末は、前記ブート・チャネル１１
またはメタシグナリング・チャネル１０を用いて、ノー
ド管理サーバー５に、該端末の起動を通知することがで
きる。同様に、前記端末上に起動されるＮＩＳサーバー
６は、前記ブート・チャネル１１またはメタシグナリン
グ・チャネル１０を用いて、ノード管理サーバー５に、
該ＮＩＳサーバー６の起動を通知することができ、該Ｎ
ＩＳサーバー６の起動通知を受信したノード管理サーバ
ー５は、前記ＮＩＳサーバー６とノード管理サーバー５
との間に、ＮＩＳ用チャネル１７の設定を行う。前記Ｎ
ＩＳ用チャネル１７を用いて、ノード管理サーバー５内
のＮＩＳマスター・プロセス６００と、ＮＩＳサーバー
内のＮＩＳスレーブ・プロセス６０１は、サーバー間の
通信(yppush 、ypxfr 等) と、後述するＮＩＳマップの
ダウンロード等を実行することができる。
【０１１７】最後に、呼設定サーバー７の起動と、呼設
定サーバー７とノード管理サーバー５との間のデータ通
信路である呼設定用チャネル（１８）の設定方法につい
て、説明する。前記したネームサーバーの起動方法とＮ
ＩＳ用チャネル（１７）の設定方法と同様に、呼設定サ
ーバー７が起動される端末は、前記ブート・チャネル１
１またはメタシグナリング・チャネル１０を用いて、ノ
ード管理サーバー５に、該端末の起動を通知することが
できる。同様に、前記端末上に起動される呼設定サーバ
ー７は、前記ブート・チャネル１１またはメタシグナリ
ング・チャネル１０を用いて、ノード管理サーバー５に
該呼設定サーバー７の起動を通知することができ、該呼
設定サーバー７の起動通知を受信したノード管理サーバ
ー５は、前記呼設定サーバー７とノード管理サーバー５
との間に呼設定用チャネル１８の設定を行う。前記呼設
定用チャネル１８を用いて、ノード管理サーバー５内の
管理プロセス５１および呼設定サーバー７内の呼設定プ
ロセスは、サーバー間のデータ通信を実行することがで
きる。
【０１１８】１−２．端末のブートについて いわゆる端末には、ディスクを持った端末(Host)と、比
較的小規模のディスクを持ったデータレス・クライアン
トと、ディスクを持たないディスクレス・クライアント
が存在する。本節では、前記ディスクを持った端末(Hos
t)、およびＯＳ等の実行可能ファイルをディスク中に記
憶しているデータレス・クライアントの起動方法につい
て、具体的に説明する。以下、本節では、前記ディスク
を持った端末端末(Host)とデータレス・クライアントと
を、特に断らない場合、単に端末と呼ぶこととする。な
お、上記ディスクレス・クライアントの起動方法につい
ては、次節の(1-3) で具体的に説明する。
【０１１９】以下、図１、図２、および図３を参照しな
がら、本発明の一実施例における端末の起動手順につい
て、具体的に説明する。
【０１２０】まず、本発明においては、（1-1 節で説明
したように）ノード設定サーバー４とノード管理サーバ
ー５の起動時に、ＡＴＭ交換機２のすべての入出力線の
先に接続されるであろう端末と、ノード管理サーバー５
内の端末ブートプロセス５３との間にブート・チャネル
１１が、また、前記すべての入出力線の先に接続される
であろう端末と、ノード管理サーバー５内の端末メタシ
グナリング・プロセス５４との間にメタシグナリング・
チャネル１０が設定される。前記ノード設定サーバー４
とノード管理サーバー５の起動後、前記ＡＴＭ交換機２
の入出力線の先に接続された端末が起動する場合、前記
端末は、前記ブート・チャネル１０またはメタシグナリ
ング・チャネル１１を用いて、該端末の起動をノード管
理サーバー５に通知することができる。
【０１２１】対象とするＡＴＭ交換機２の入出力線の先
に接続される端末が、コンピュータ等の端末の場合、該
端末の起動をノード管理サーバー５に通知するためと、
該端末の起動に必要なネットワーク情報（例えば、ホス
トネームといった情報) 等を、前記ノード管理サーバー
５から得るために、該端末は、前記ブート・チャネル１
１を用いて、前記ノード管理サーバー５とデータ通信を
実行する。すなわち、端末は、起動時、前記端末の起動
を通知するために、ブート用セル（例えば、BOOTP セ
ル、RARPセル等) をブートチャネル１１を用いてノード
管理サーバー５に送信し、前記ノード管理サーバー５
は、前記ブート用セルを受信することによって、前記端
末の起動を認識することができる。また、前記端末は、
必要に応じて前記端末の起動に必要な情報の要求を前記
ブート用セルに書き込んでおき、前記ブート用セルをブ
ートチャネル１１を用いてノード管理サーバー５に送信
し、前記ノード管理サーバー５は、前記ブート用セルを
受信し、前記ブート用セルに書かれた要求に従って、前
記端末３の起動に必要な情報を前記ブート・チャネル１
１を用いて前記端末に送信することによって、前記端末
３は起動に必要な情報を得ることができる。
【０１２２】また、前記端末３は、起動時または起動
後、必要に応じて、前記端末３上に起動するＮＩＳクラ
イアント・プロセス６１と、ＮＩＳサーバーとの間のデ
ータ通信路であるインフォメーション・チャネル１２の
設定要求を、前記ブート・チャネル１１を用いて、ノー
ド管理サーバー５に送信することとする。すなわち、コ
ンピュータ等の端末の場合で、該端末上に、ＮＩＳクラ
イアント・プロセス６１が起動され、前記ＮＩＳクライ
アント・プロセス６１が、該端末以外の端末に起動して
いるＮＩＳサーバーに帰属(bind)する場合、前記ＮＩＳ
クライアント６１は、サブネット内に存在するＮＩＳサ
ーバーを何らかの方法で検索し、前記検索したＮＩＳサ
ーバーとの間にポイント・ツー・ポイントのデータ通信
路を構築する必要がある。本発明においては、前記した
場合、前記端末の起動時または起動後、まず、前記ＮＩ
Ｓクライアント・プロセス６１が、ブート・チャネル１
１を用いて、ノード管理サーバー５に、サブネット内の
ＮＩＳサーバーの検索要求と、前記検索したＮＩＳサー
バーと前記端末３との間のデータ通信路であるインフォ
メーション・チャネル１２の設定要求とを送信する。ノ
ード管理サーバー５は、前記ＮＩＳサーバーの検索要求
と、前記ＮＩＳサーバーとの間のデータ通信路の設定要
求を受信した場合、前記ノード管理サーバー５が、サブ
ネット内の端末の構成についての管理情報である管理フ
ァイル５６を参照し、ＮＩＳサーバー・プロセスが起動
している、比較的負荷の小さい適切な端末を検索する。
次に、前記ノード管理サーバー５は、前記検索したＮＩ
Ｓサーバー・プロセスが起動している端末と、前記端末
３との間のデータ通信路であるインフォメーション・チ
ャネル１２を設定し、前記端末３が前記インフォメーシ
ョン・チャネル１２を使用するためのＶＰＩ／ＶＣＩ値
等の情報を、前記ノード管理サーバー５は、前記端末３
に対し、前記ブート・チャネル１１を用いて送信する。
以上説明したような手順を採用することによって、前記
端末３上のＮＩＳクライアント６１は、前記インフォメ
ーション・チャネル１２を用いることによって、帰属(b
ind)先のＮＩＳサーバーに対して、必要なネットワーク
情報の検索要求を送信したり、前記ＮＩＳサーバーか
ら、必要なネットワーク情報を受信したりすることがで
きる。
【０１２３】また、ＮＩＳクライアント６１は、帰属(b
ind)先のＮＩＳサーバーに対しネットワーク情報の送信
を要求し、前記ＮＩＳサーバーから前記要求したネット
ワーク情報が送信されてくるのを待つが、前記ＮＩＳサ
ーバーから前記ネットワーク情報の受信に時間がかかる
場合、前記ＮＩＳクライアント６１は、帰属(bind)先の
ＮＩＳサーバーの変更をノード管理サーバー５に要求す
る。すなわち、ＮＩＳクライアント６１は、前記インフ
ォメーション・チャネル１２を用いて、帰属(bind)先の
ＮＩＳサーバーに対し必要とするネットワーク情報の送
信を要求する。前記ＮＩＳクライアント６１は、前記Ｎ
ＩＳサーバーから、前記インフォメーション・チャネル
１２を経由して、要求したネットワーク情報の受信を待
つが、前記ネットワーク情報の受信がタイムアウトした
場合、前記ＮＩＳクライアント６１は、前記ブート・チ
ャネル１１を用いて、ノード管理サーバー５に、帰属(b
ind)先のＮＩＳサーバーの変更を要求する。帰属(bind)
先のＮＩＳサーバーの変更要求を受信したノード管理サ
ーバー５は、サブネット内の端末の構成についての管理
情報である管理ファイル５６を参照し、ＮＩＳサーバー
・プロセスが起動している比較的負荷の小さい適切な端
末を検索する。次に、前記ノード管理サーバー５は、前
記検索したＮＩＳサーバー・プロセスが起動している端
末と、前記端末３との間にインフォメーション・チャネ
ルを再設定し、前記端末３が前記インフォメーション・
チャネルを使用するためのＶＰＩ／ＶＣＩ値等の情報
を、ブート・チャネル１１を用いて前記端末に送信する
ことによって、ＮＩＳクライアント６１は帰属(bind)先
のＮＩＳサーバーを変更することができる。
【０１２４】また、対象とするＡＴＭ交換機２の入出力
線の先に接続される端末が、ＡＴＭ等の端末の場合、該
端末３の起動をノード管理サーバー５に通知するため
と、該端末が呼設定を行うのに必要なシグナリング・チ
ャネル１３の設定と、前記シグナリング・チャネル１３
を使用するのに必要なＶＰＩ／ＶＣＩ値等の情報を、前
記ノード管理サーバー５から得るために、該端末３は、
前記メタシグナリング・チャネル１０を用いて前記ノー
ド管理サーバー５とデータ通信を行う。すなわち、端末
３は、起動時、前記端末３の起動を通知するために、メ
タシグナリング・セルを、メタシグナリング・チャネル
１０を用いてノード管理サーバー５に送信し、前記ノー
ド管理サーバー５は、前記メタシグナリング・セルを受
信することによって、前記端末３の起動を認識すること
ができる。また、前記ノード管理サーバー５は、前記メ
タシグナリング・セルを受信した場合、前記端末３に対
して、前記端末３と呼設定サーバー７との間のシグナリ
ング・チャネル１３を設定するとともに、前記端末３
が、前記シグナリング・チャネル１３を使用するのに必
要なＶＰＩ／ＶＣＩ値等の情報を、前記メタシグナリン
グ・チャネル１０を用いて前記端末３に送信することに
よって、前記端末３は、呼設定を行うのに必要な、シグ
ナリング・チャネル１３を使用するためのＶＰＩ／ＶＣ
Ｉ値等の情報を得ることができる。
【０１２５】以上説明したように、本発明においては、
コンピュータ等の端末の場合、端末の起動の通知と、端
末の起動に必要な情報の送信を、ブート・チャネル１１
を用いて実行し、ＡＴＭ端末等の場合、前記端末が呼設
定を行うのに必要なシグナリング・チャネル１３の設定
と、前記端末が、前記シグナリング・チャネル１３を使
用するために必要なＶＰＩ／ＶＣＩ値等の情報の送信
を、メタシグナリング・チャネル１０を用いて実行する
こととしている。コンピュータ等のＡＴＭ端末の場合、
前記したブート・チャネル１１とメタシグナリング・チ
ャネル１０の２つのチャネルを用いて、前記端末の起動
処理を実行してもよい。すなわち、コンピュータ等のＡ
ＴＭ端末の場合、ノード管理サーバー５に対し、端末の
起動通知と、端末の起動に必要な情報の受信を、ブート
・チャネル１１を用いて行い、シグナリング・チャネル
１３の設定要求と、端末が前記シグナリング・チャネル
１３を使用するためのＶＰＩ／ＶＣＩ値等の情報の受信
を、メタシグナリング・チャネル１０を用いて行っても
よい。
【０１２６】次に、ノード管理サーバー５が、ブート・
チャネル１１を経由して、端末３から転送されたブート
用セル（BOOTP セル、RARPセル等) を受信した場合、あ
るいはメタシグナリング・チャネル１０を経由して、端
末３から転送されたメタシグナリング・セルを受信した
場合のノード管理サーバー５の動作について、具体的に
説明する。
【０１２７】ノード管理サーバー５が、メタシグナリン
グ・セル（またはブート用セル）を受信した場合、前記
ノード管理サーバー５は、まず、configファイル５５を
参照し、configファイル５５に書かれた内容に従って、
端末の立ち上げシーケンスを実行する。configファイル
５５のうち、メタシグナリング・セル（またはブート用
セル）が転送されてきた交換機の入力ポート、またはメ
タシグナリング・セル（またはブート用セル）に記述さ
れたキーワードに従って、必要な部分が選択され、前記
選択した情報に従って、端末３の立ち上げシーケンスが
実行される。電話等の端末や、コンピュータ等の端末
で、新たにコネクションを設定する必要のある端末の場
合、前記configファイル５５には、端末３から呼設定サ
ーバー７までのシグナリング・チャネル１３等の設定手
順が記述されている。また、コンピュータ等の端末の場
合、前記configファイル５５には必要に応じて、端末か
らＮＩＳサーバー６までの、または、ブロードキャスト
・チャネル等の設定手順が記述されていてもよい。ま
た、サブネットワーク内に、複数の呼設定サーバーが存
在する場合、ノード管理サーバー５は、管理ファイル５
６を参照し、比較的負荷の小さい呼設定サーバーに、前
記端末３の呼設定処理をするように、前記端末３と前記
呼設定サーバーとの間に、シグナリング・チャネル１３
を設定してもよい。
【０１２８】次に、前記ノード管理サーバー５は、conf
igファイル５５に書かれた内容に従ってＡＴＭ交換シス
テム内のコネクションを設定する。具体的には、config
ファイル５５に書かれている内容に従って、ＡＴＭ交換
システム内にコネクションを設定するために、ノード管
理サーバー５は、対応するノード設定サーバー４に対
し、ハードウェアの設定を要求する。前記ノード管理サ
ーバー５と前記ノード設定サーバー４が同一の端末上に
起動されている場合は、前記ノード管理サーバー５から
前記ノード設定サーバー４への設定要求は、プロセス間
通信によって転送される。一方、前記ノード管理サーバ
ー５と前記ノード設定サーバー４が、同一の端末上に起
動されていない場合は、前記ノード管理サーバー５から
前記ノード設定サーバー４への設定要求は、図３で示し
たような設定用チャネルを用いて転送される。
【０１２９】ノード設定サーバー４は、前記設定要求を
受信した場合、ルーティングタグ・テーブル２４等のハ
ードウェアを直接書き込むことによって、前記コネクシ
ョン設定要求に対して、スイッチ等のルーティング・テ
ーブルを設定する。また、前記ノード設定サーバー４
は、ルーティングタグ・テーブル２４等のハードウェア
情報を、backupファイル４２にバックアップしていても
よい。前記ノード設定サーバー４が、backupファイル４
２を作成する場合、前記ノード設定サーバー４は、ハー
ドウェアに正常に書き込みが終了した場合、前記backup
ファイル４２の更新を行う。前記backupファイル４２
は、ＡＴＭ交換システムに、電源の瞬断等の事故が発生
し、ハードウェア・テーブル等の内容が破壊された場合
に、ノード設定サーバー４がハードウェア・テーブル等
の内容を、効果的に復旧する場合に用いられる。また、
ノード設定サーバー４は、受信した設定要求を、backup
ファイル４２にロギングしてもよい。ＡＴＭ交換システ
ムに不具合が発生した場合、前記ロギング・ファイルを
参照することによって、効果的にその不具合を取り除く
ことができる。
【０１３０】ノード設定サーバー４が、受信した設定要
求に対し、正常に設定が終了した場合、ノード管理サー
バー５は、該ノード管理サーバー５が管理する管理ファ
イル５６を更新する。次に、ノード管理サーバー５は、
前記管理ファイル５６の内容を基にサブネットワークに
対するＮＩＳマップを再構成する。本発明においては、
ノード管理サーバー５は、サブネットワークに対するＮ
ＩＳマスター・サーバー６００としても機能することを
想定しているが、前記構成を想定した場合、ノード管理
サーバー５が、該サーバーが管理するＮＩＳマップ（Ｎ
ＩＳマスター・マップ）を再構成した場合、該ノード管
理サーバー５が前記ＮＩＳマップをＮＩＳスレーブ・サ
ーバー６０１にダウン・ロードする。すなわち、前記ノ
ード管理サーバー５は、ＮＩＳスレーブ・サーバー６０
１に対し、ＮＩＳマスター・マップの更新を通知する
（yppushユーティリティによって実行される）。ＮＩＳ
マスター・マップの更新の通知を受けたＮＩＳスレーブ
・サーバー６０１は、ＮＩＳマスター・サーバー６００
（ノード管理サーバー５）に対し、ＮＩＳマップの転送
を要求する（ypxfr ユーティリティによって実行され
る) 。ＮＩＳマップの転送を受信したＮＩＳスレーブ・
サーバー６０１は、該ＮＩＳスレーブ・サーバー６０１
が管理するＮＩＳマップを更新する。
【０１３１】ここで、前記ＮＩＳマスター・サーバー６
００（ノード管理サーバー５）の、ＮＩＳスレーブ・サ
ーバー６０１へのＮＩＳマップの転送においては、端末
３が起動する度に、または呼設定サーバーがコネクショ
ンを設定する度に、ＮＩＳマップを転送する方法を採用
した場合、ＮＩＳマップが頻繁に転送される可能性があ
る。これに対しては、ＮＩＳマップが更新される度に、
ＮＩＳマップをＮＩＳマスター・サーバー６００からＮ
ＩＳスレーブ・サーバー６０１へ転送するのではなく
て、定期的にまたは更新量がスレショルドを越えた場合
に転送するといった方法を用いることによって、上記動
作を改善し、性能を向上させることができる。
【０１３２】最後に、ノード管理サーバー５は、前記端
末３に対し設定完了を通知する。すなわち、ノード管理
サーバー５は、メタシグナリング・セルを送信した端末
に対しては、シグナリング・チャネル１３の設定完了
と、シグナリング・セルのＶＰＩ／ＶＣＩ値等を通知
し、ブート用セルを送信した端末に対しては、ブート・
イメージ等を通知する。
【０１３３】ここで、前記したノード管理サーバー５
の、端末の起動手順において、該ノード管理サーバー５
は、端末からの要求に従ってconfigファイル５５を参照
し、ノード設定サーバー４に対し設定要求を送信すると
していた。前記方法を採用した場合、端末が起動要求を
送信する度に、ノード管理サーバー５は設定要求をノー
ド設定サーバー４に送信するが、前記端末が前記起動要
求のタイムオーバー等の原因によって起動要求を再送し
た場合、該ノード管理サーバー５は、ノード設定サーバ
ー４に対して設定要求を再送してしまう可能性がある。
この点は、以下の手順を採用することにより改善され
る。すなわち、ノード管理サーバー５が、端末から起動
要求を受信した場合、configファイル５５と管理ファイ
ル５６を参照し、前記起動要求に対し設定するコネクシ
ョンがすでに前記管理ファイル５６に登録されていた場
合、ノード設定サーバー４に対しては設定要求を出さず
に、端末に対して設定完了通知を出すようにすれば良
い。
【０１３４】また、管理ファイル５６に登録されている
情報と実際にハードウェアに設定されている設定データ
とが異なる場合、前記改善方法を採用したとき端末から
のコネクション設定要求が無視される可能性がある。こ
の点は、管理ファイル５６に登録されているコネクショ
ンに対し、１回目の設定要求に対しては、前記した通り
何のアクションも起こさないが、２回目以降の設定要求
に対してアクションを起こすことによって改善される。
【０１３５】同様に、ノード設定サーバー４は、ノード
管理サーバー５から、ハードウェア・テーブルの設定要
求を受信した場合、backupファイル４２を参照し、前記
ハードウェアの設定がすでに実行されている場合、前記
設定要求に対しては、ハードウェアの設定を行わずに、
ノード管理サーバー５に対して設定完了を通知すること
によって、性能が改善される。さらに、ノード設定サー
バー４は、backupファイル４２にすでに実行されたアク
ションに対して、１回目のアクション要求に対してはア
クションを起こさず、２回目以降のアクション要求に対
してアクションを起こすことによって、backupファイル
４２と実際のハードウェアの不一致による不具合を改善
することができる。
【０１３６】また、本発明の一実施例においては、後述
するように、頻繁にデータ通信が行われそうな端末間に
予めコネクションを設定しておき、前記端末間のデータ
通信を行う場合、前記予め設定されたコネクションを用
いることによって、呼設定を行わずにデータ転送を開始
することのできる効果的なデータ通信方法を想定してい
る。前記した予め設定されたコネクションを、いつ、ど
のように設定するかについて、以下に示すような、３通
りの方法が存在する。
【０１３７】１つ目の方法は、前記コネクションを、ハ
ードウェアで予め作り込んでおくという方法である。す
なわち、ＡＴＭ交換機２内の前処理部のルーティングタ
グ・テーブルを、ＲＯＭ等の不揮発メモリで作成し、Ａ
ＴＭ交換機２を製造する際、所望のデータを前記ＲＯＭ
に書き込んでおくことによって、前記コネクションの設
定を行おうとする方法である。ただし、他の２方法に比
較して、この方法を採用した場合、製造後、ＲＯＭを書
き換えることはできないので、ルーティング・タグ・テ
ーブルを変更することはできない。
【０１３８】２つ目の方法は、前記コネクションを、ネ
ットワークの立ち上げ時に設定する方法である。すなわ
ち、本発明の一実施例においては、ＡＴＭネットワーク
は、前記した４つのサーバーで管理することを想定して
いるが、前記したconfigファイル５５に、予め前記コネ
クションの設定を記述しておくことによって、ＡＴＭネ
ットワークの立ち上げ時、ノード管理サーバー５が、前
記configファイル５５に書かれた内容に従ってコネクシ
ョンを設定することによって、前記コネクションの設定
を行おうとする方法である。ただし、他の２方法に比較
して、この方法を採用した場合、前記ノード管理サーバ
ー５が、前記configファイル５５に書かれたすべてのコ
ネクションを設定し終わるまで、ＡＴＭネットワークの
立ち上げが終了しないので、ネットワークの立ち上げに
時間がかかる。
【０１３９】３つ目の方法は、前記コネクションを、端
末の立ち上げ時に設定する方法である。すなわち、ネッ
トワークの起動後（ノード管理サーバー５の起動後) 、
ネットワークに接続される端末の起動を、ノード管理サ
ーバー５が認識した場合、前記端末に対して、該ノード
管理サーバー５が、configファイル５５に記述された内
容に従って、コネクションの設定を行おうという方法で
ある。上記２つ目の方法は、ネットワークの立ち上げ時
にノード管理サーバー５がconfigファイル５５を参照し
てコネクションを設定しようという方法であったが、こ
の３つ目の方法では、ネットワークの立ち上げの時点で
はなく、ネットワークに接続される端末の起動をノード
管理サーバー５が認識した時点で、前記端末に対してco
nfigファイル５５を参照してコネクションを設定しよう
という方法である。具体的には、(1-1) 節で説明したよ
うに、ネットワークの立ち上げ時に、ノード管理サーバ
ー５は、対象とするＡＴＭ交換機２のすべての入出力線
に対し、前記入出力線の先に接続されるであろう端末
と、ノード管理サーバー５との間に、ブート・チャネル
１１とメタシグナリング・チャネル１０とを設定する。
ＡＴＭ交換機２の入出力線の先に接続された端末は、起
動時に、前記ブート・チャネル１１またはメタシグナリ
ング・チャネル１０を用いて、ノード管理サーバー５
に、ブート用セル（またはメタシグナリング・セル) を
送信する。ノード管理サーバー５は、ブート用セル（ま
たは、メタシグナリング・セル) を受信した場合、前記
ノード管理サーバー５は、該端末の起動を認識し、conf
igファイル５５に書かれた内容に従って、該端末に対し
て予め設定するコネクション等の設定を実行する。ただ
し、他の２方法に比較して、この方法を採用した場合、
端末の立ち上げに時間がかかる。
【０１４０】前記した３つの方法には、それぞれ長所・
短所が存在するので、状況に応じて３つの方法のうちか
ら長所を生かすように１つの方法を選択することが効果
的である。
【０１４１】１−３．ディスクレス・クライアントのブ
ートについて 一般に、ディスクレス・クライアントは、起動時、ルー
ト・ファイルシステム(/) 、作業領域（スワップエリ
ア：/tmp) 、ＯＳ等の実行可能ファイル(/usr)、端末名
（ホスト名) 等の情報を持っていないので、起動時、デ
ィスクレス・クライアントは、前記した情報を獲得しな
ければならない。従来のディスクレス・クライアント
は、前記情報を獲得するために、起動時、ブート用パケ
ット（RARPパケットまたはBOOTP パケット) をサブネッ
トワーク内にブロードキャストし、サブネットワーク内
に存在するブートサーバーが前記パケットに応答するこ
とによって、前記ディスクレス・クライアントは前記情
報を獲得することができる。
【０１４２】本発明においては、(1-1) 節で説明したよ
うに、ＡＴＭ交換機２（ネットワーク) の立ち上げ時
に、ノード管理サーバー５が、ＡＴＭ交換機２のすべて
の入出力線に対し、前記入出力線の先に接続されるであ
ろう端末とノード管理サーバー５との間に、ブート・チ
ャネル１１を設定しておく。ＡＴＭ交換機２（ネットワ
ーク) の起動後、前記ＡＴＭ交換機２の入出力線の先に
接続されたディスクレス・クライアントが起動する場
合、前記ディスクレス・クライアントは、ブート・チャ
ネル１１を用いて、ブート用セル（RARPセルまたはBOOT
P セル) をノード管理サーバー５に送信する。ノード管
理サーバー５は、ブート・チャネル１１を経由して転送
されたブート用セルを受信した場合、configファイル５
５を参照し、前記configファイル５５のブート用セルを
送信したディスクレス・クライアントに対応する記述に
従って、前記ディスクレス・クライアントを起動するの
に必要なブートイメージ（ルート・ファイルシステム、
スワップエリア、実行可能ファイル、ホスト名等) を、
前記ディスクレス・クライアントに、前記ブート・チャ
ネル１１を用いて送信する。前記ノード管理サーバー５
の、configファイル５５を参照する手順において、本発
明の一実施例においては、ブート用セルがＡＴＭ交換機
２に入力された入力チャネル番号をキーとして、config
ファイル５５を参照し、configファイル５５に書かれた
ブートイメージを、ノード管理サーバー５が前記ブート
用セルを送信したディスクレス・クライアントに転送す
ることを想定している。
【０１４３】ディスクレス・クライアントを、提案する
ＡＴＭ交換機に接続する場合について、以下、具体的に
説明する。
【０１４４】まず、従来のディスクレス・クライアント
は、起動時、ブート用パケット（ARP パケットまたはBO
OTP パケット) をサブネットワーク内の端末にブロード
キャストし、サブネットワーク内に存在するブートサー
バー等が前記パケットに対し応答することによって、前
記ディスクレス・クライアントはブートイメージを得る
ことを想定している。従来のネットワークにおいては、
サブネットワーク内に存在する端末に対して予めブロー
ドキャスト・チャネルが設定されていて、前記ディスク
レス・クライアントは、前記ブロードキャスト・チャネ
ルを使用することによって、サブネットワーク内に存在
するブート・サーバーにブート用セルを転送することが
できた。
【０１４５】本発明の一実施例においては、ディスクレ
ス・クライアントが、ブート用セルを送信するために使
用するチャネル（すなわちブート・チャネル１１) を予
め設定しておき、特定のＶＰＩ／ＶＣＩ値（例えば、VP
I=all 1 、または、VPI/VCI=all 1) を、予め割り当て
ておく。また、前記チャネルは、ＡＴＭ交換機２（ネッ
トワーク) の立ち上げ時に、ＡＴＭ交換機２のすべての
入出力線の先に接続されるであろう端末とノード管理サ
ーバー５との間に、ノード管理サーバー５によって設定
されるものとする。従来のネットワークにおいては、デ
ィスクレス・クライアントの起動時に使用されるブート
時に使用されるチャネルとして、サブネットワーク内に
存在するすべての端末へのブロードキャスト・チャネル
が用いられていたが、本発明においては、ブロードキャ
スト・チャネルを使用するのではなく、端末からサブネ
ットワーク内に存在するノード管理サーバー５までのユ
ニキャスト・チャネル（シングルキャスト・チャネル)
であるブート・チャネルを用いることを想定している。
【０１４６】１−５．ＡＲＰ、ＮＩＳについて 以下、本発明に係るＡＴＭ交換システムにおける、ＡＲ
Ｐ(Address Resolution Protocol) について説明する。
【０１４７】本発明のＡＴＭ交換システムにおいては、
頻繁にデータ通信が行われそうな端末間に予めコネクシ
ョンを設定しておき、前記端末間のデータ通信を行う場
合、前記予め設定されたコネクションを用いることによ
って、呼設定を行わずにデータ転送を開始することので
きる効果的なデータ通信方法を想定している。また、本
発明においては、前記データ通信を行う際、宛先のデー
タ受信端末の端末名等をキーとして、前記予め設定され
たコネクションのコネクション識別子(VPI/VCI等) を検
索し、前記検索して得られたコネクション識別子を用い
て、前記コネクションを使用することを想定している。
ここに、以下の説明で、ＡＲＰとは、宛先のデータ受信
端末の端末名等から、既に設定されたコネクションのう
ち該当するコネクションのコネクション識別子(VPI/VCI
等) を獲得する方法のことを言うものとする。
【０１４８】従来のコンピュータ間のデータ通信方法(T
CP/IP)におけるＡＲＰとは、宛先のデータ受信端末のＩ
Ｐアドレス（端末名に対応する）からＭＡＣアドレス
（コネクション識別子に対応する) を獲得する方法であ
った。また、従来のコンピュータ間のデータ通信方法に
おいては、サブネットワークに属する各々のデータ送信
端末は、同一の宛先にデータ通信を行う場合、同一のＭ
ＡＣアドレス（コネクション識別子に対応）を用いてデ
ータ転送を行うことができた。
【０１４９】ここで、前述した従来のコンピュータ間の
データ通信方法を、そのまま従来のＡＴＭ交換システム
に適用した場合の問題点について説明する。
【０１５０】前述したように、従来のコンピュータ間の
データ通信で行われた方法を、従来のＡＴＭ交換システ
ムにそのまま適用しようとすると、サブネットワークに
属するすべての端末間にメッシュ状にコネクションを設
定し、前記各々のデータ送信端末が同一の宛先にデータ
転送を行う場合、同一のコネクション識別子（ＶＰＩ／
ＶＣＩ）を用いてデータ転送ができるように、コネクシ
ョンの設定を行わなければならない。しかし、前記サブ
ネットワークに属する端末間にメッシュ状に張られたコ
ネクションは、常時、すべてのコネクションが使用され
るわけではないので、前記方法を採用した場合、ＶＰＩ
／ＶＣＩテーブル（宛先の端末名から、コネクション識
別子を検索する時に使用するテーブル) の大きさが、不
必要に大きくなってしまうといった問題点があった。ま
た、ネットワーク・サイドにとっても、端末が、呼設定
を行わずにデータ転送を行うことを保証するためには、
前記予め設定されたコネクションが正常かどうか、常
時、チェックを行わなければならず、前記コネクション
の数が不必要に多い場合、ネットワーク・サイドが効率
よく前記コネクションをチェックすることができないと
いった問題点があった。
【０１５１】本発明の一実施例は、前記問題点を改善す
るために、サブネットワーク内のすべての端末間にメッ
シュ状にコネクションを設定するのではなく、頻繁にデ
ータ通信が行われそうな端末間にのみコネクションを設
定することによって、予め設定しなければならないコネ
クションの数を削減するようにしたものである。また、
本発明の一実施例においては、前記予め設定を行うコネ
クションのうち、サブネットワークに属するすべての端
末に共通するコネクションと端末に固有なコネクション
とに分類し、前記サブネットワークに属するすべての端
末に共通するコネクションについて、コネクション識別
子（ＶＰＩ／ＶＣＩ）を端末間で共通にすることによっ
て、サブネットワーク内に存在するＶＰＩ／ＶＣＩテー
ブルの管理を効率よく行うようにしたものである。
【０１５２】また、予めコネクションを設定することに
よって、呼設定を行わずにデータ転送を開始する方法を
採用しても、端末が前記コネクションを使用する場合
に、前記コネクションを使用するためのＶＰＩ／ＶＣＩ
値等を、他の端末に問い合わせなければならない方法を
採用した場合、他の端末に問い合わせるのに時間がかか
るので、予めコネクションを設定することによる利点が
小さくなるといった問題点があった。
【０１５３】本発明の一実施例は、端末が、予め設定さ
れたコネクションを使用するためのＶＰＩ／ＶＣＩ値等
を記憶することのできる場合、端末側で前記ＶＰＩ／Ｖ
ＣＩ値等を記憶し、端末がデータ通信を行う場合、前記
端末側で記憶されているＶＰＩ／ＶＣＩ値等を用いるこ
とによって、効率よくデータ転送を開始するようにした
ものである。
【０１５４】以下、本発明の一実施例においては、ＶＰ
Ｉ／ＶＣＩテーブルを効率よく管理等を行うために、Ｎ
ＩＳ（Network Information System）を用いて管理する
方法について説明する。本発明を、ＮＩＳを用いずに実
現することも可能であるが、以下、本発明の一実施例を
具体的に説明するためにＮＩＳの使用を想定する。以
下、ＶＰＩ／ＶＣＩテーブルをＮＩＳを用いて管理する
方法と、本発明におけるＮＩＳの実現方法について、具
体的に説明する。
【０１５５】図４は、本発明の一実施例における、ＶＰ
Ｉ／ＶＣＩテーブルの構成を示したものである。本発明
においては、端末がＶＰＩ／ＶＣＩテーブルを持つこと
によって、データ通信を行う必要の生じた端末は、宛先
のデータ受信端末の端末名等をキーとして、前記ＶＰＩ
／ＶＣＩテーブルを検索することによって、効率よくＶ
ＰＩ／ＶＣＩを獲得する方法を想定している。具体的に
は、データ送信端末は、宛先のデータ受信端末までのコ
ネクションが設定されたデータ転送路に対して、宛先の
端末(Host)名等と前記コネクションを使用するためのＶ
ＰＩ／ＶＣＩ値等とを一組としたＶＰＩ／ＶＣＩテーブ
ルを管理し、データ転送を行う必要の生じたデータ送信
端末は、宛先の端末名をキーとして前記ＶＰＩ／ＶＣＩ
テーブルを検索することによって、宛先のデータ受信端
末までセルを転送するためのコネクションを使用するの
に必要なＶＰＩ／ＶＣＩ値等を獲得する（ハッシュ関数
を用いて検索しても良い）。
【０１５６】また、本発明の一実施例において、ＶＰＩ
／ＶＣＩテーブルは、図４に示すように、サブネットワ
ークに属する端末に共通なＶＰＩ／ＶＣＩテーブルであ
るＮＩＳマップ６２と、端末に固有なＶＰＩ／ＶＣＩテ
ーブルであるＮＩＳファイル６３の２種類のＶＰＩ／Ｖ
ＣＩテーブルから構成されているとする。ここで、通
常、ＮＩＳにおいては、ＮＩＳファイルという用語は存
在せず、ローカル・ファイルと呼ばれているが、本発明
の一実施例においては、ローカル・ファイルという代わ
りにＮＩＳファイルと呼ぶこととする。また、本発明の
ＡＴＭ交換システムにおいては、サブネットワークに属
しているすべての端末と、予め指定されたサーバー等の
機能を持つ複数の端末との間のコネクションは設定され
ているものとし、サブネットワークに属する任意の端末
が前記コネクションを使用する場合、宛先の端末名に対
して同一のＶＰＩ／ＶＣＩ値等が割り当てられているも
のとする。前記したサブネットワークに属するすべての
端末に対して、共通の宛先とＶＰＩ／ＶＣＩ値等はＮＩ
Ｓマップ６２に登録されているものとする。また、個々
の端末に固有に設定されたコネクションに対しては、宛
先の端末名と、前記コネクションを使用するためのＶＰ
Ｉ／ＶＣＩ値等は、ＮＩＳファイル６３に登録されてい
るものとする。
【０１５７】本発明の一実施例においては、ＶＰＩ／Ｖ
ＣＩテーブルの管理に、まず、ＮＩＳファイル６３を参
照し、次に、ＮＩＳマップ６２を参照することによっ
て、宛先の端末名から前記端末にセルを送信するために
必要なＶＰＩ／ＶＣＩ値等を検索することを想定してい
る。ただし、本発明においては、まず初めに、ＮＩＳマ
ップ６２を参照し、次に、ＮＩＳファイル６３を参照し
ても構わない。
【０１５８】図５は、前記したサブネットワークに共通
なコネクションと、個々の端末に固有なコネクションの
関係を示した本発明の具体例である。
【０１５９】コンピュータ・ネットワークに属する端末
には、一般に、サーバーとクライアントの２種類の端末
が存在する。一般的に、クライアントからサーバー、サ
ーバーからクライアント、およびサーバーからサーバー
へのデータ転送は行われるが、クライアントからクライ
アントへのデータ転送はあまり行われないといった特徴
が存在する。従って、本発明において、サブネットワー
クに属する端末に対して、端末の起動時（またはネット
ワークの起動時) 等に対応する、サーバーとサーバー
間、あるいはサーバーとクライアント間のコネクション
を予め設定することによって、前記端末が、予めコネク
ションが設定された端末に対して実際にデータ通信を行
う際に、呼設定を行わずにデータ通信を開始することが
できる。本発明の一実施例においては、ノード管理サー
バー５が、以下に示すような手順を実行することによっ
て、前記した予め設定するコネクションを、効率よく設
定することができる。すなわち、ノード管理サーバー５
が、ブート用セル(RARP セルまたはBOOTP セル) 、また
はメタシグナリング・セルを受信した場合、前記セルが
転送されてきたブート・チャネル１１またはメタシグナ
リング・チャネル１０の先に接続された端末が起動され
たと認識する。次に、前記ノード管理サーバー５は、co
nfigファイル５５を参照し、前記端末に対してconfigフ
ァイル５５中に記述されたサーバー等の間のコネクショ
ンを設定することによって、前記予め設定するコネクシ
ョンを効率よく設定することができる。
【０１６０】また、予めコネクションを設定する際に、
宛先がサーバーとなるコネクションを設定する場合、サ
ブネットワークに属するすべての端末に対して、同一の
宛先に対して同一のＶＰＩ／ＶＣＩ値等となるようにコ
ネクションの設定を行うこととする。前記したようなＶ
ＰＩ／ＶＣＩ値の設定を行うことで、サブネットワーク
に属するすべての端末において、同一の情報が書かれた
ＮＩＳマップ62を使用することができるので、サブネッ
トワークにおけるＮＩＳマップ６２の管理を効率よく行
うことができる。
【０１６１】図５において、宛先がサーバーの場合のＶ
ＰＩ／ＶＣＩテーブルは、ＮＩＳマップ６２で管理する
ことができるが、宛先がクライアントの場合のＶＰＩ／
ＶＣＩテーブルは、ＮＩＳマップ６２で管理することは
できず、前記テーブルはＮＩＳファイル６３で管理する
ことになる。従って、クライアントからサーバーへのコ
ネクションは、ＮＩＳマップ６２で管理されることにな
るが、前記コネクションに対する逆向きのコネクション
（サーバーからクライアントへのコネクション) は、Ｎ
ＩＳファイル６３で管理されることになる。従って、本
発明の一実施例においては、ＮＩＳファイル６３には、
前記したサーバーからクライアントへの予め設定するコ
ネクション、および呼設定要求の結果、端末固有に設定
されるコネクションの２通りのコネクションが登録され
ることになる。
【０１６２】なお、クライアントからクライアントへデ
ータ転送を行う場合は、該当する端末が網に対して呼設
定要求を行うことによって、網が前記コネクションを設
定し、前記コネクションに対するＶＰＩ／ＶＣＩ値等を
ＮＩＳファイル６３に登録することによって、前記コネ
クションに対して本発明におけるＶＰＩ／ＶＣＩテーブ
ル管理方法で対応することができる。
【０１６３】図６は、本発明の一実施例におけるサブネ
ットワーク内の、ＮＩＳマップの配送方法を示した模式
図である。
【０１６４】一般的に、コンピュータ・ネットワークに
おいては、ハードディスクを持ったホスト３１と、小規
模のハードディスクを持ったデータレス・クライアント
３２と、ディスクを持たないディスクレス・クライアン
ト３３の３種類の端末が存在する。現在のＮＩＳの実装
方法においては、ユーザのＮＩＳの使用効率を高めるた
めに、なるべくＮＩＳスレーブ・マップはユーザ側のハ
ードディスク上に、ＮＩＳスレーブサーバー・プロセス
は、ユーザ端末上に起動しようとしている。従って、図
６に示すように、前記ホスト３１においては、ＮＩＳス
レーブ・マップ６２１が構築され、ＮＩＳスレーブサー
バー・プロセス６０１とＮＩＳクライアント・プロセス
６１が起動されているものとする。また、前記データレ
ス・クライアント３２においては、実装されているハー
ドディスクの規模に応じて、ＮＩＳスレーブ・マップ６
２１、ＮＩＳスレーブサーバー・プロセス６０１、およ
びＮＩＳクライアント・プロセス６１で構成されている
場合と、ＮＩＳクライアント・プロセス６１のみで構成
されている場合の、２通りの場合が存在するものとす
る。同様に、前記ディスクレス・クライアント３３の場
合、端末上に、ＮＩＳクライアント・プロセス６１のみ
起動されているものとする。
【０１６５】本発明の一実施例においては、前記したよ
うに、ノード管理サーバー５内に、ＮＩＳマスター・サ
ーバー６００が存在し、該ＮＩＳマスター・サーバー６
００が管理するＮＩＳマスター・マップ６２０を、サブ
ネットワーク内に存在するすべてのＮＩＳスレーブ・サ
ーバー６０１に分配することによって、サブネットワー
ク内に存在するすべてのＮＩＳマップの管理（同期) を
行うものとする。すなわち、ノード管理サーバー５内に
存在するＮＩＳマスター・サーバー６００は、該ＮＩＳ
マスター・サーバー６００が管理するＮＩＳマスター・
マップ６２０が更新された場合、前記更新されたマップ
のコピーを、サブネットワーク内に存在するすべてのＮ
ＩＳスレーブ・サーバー６０１に配送し、前記ＮＩＳス
レーブ・サーバー６０１が、該配送されたＮＩＳマスタ
ー・マップ６２０のコピーを基に、ＮＩＳスレーブ・マ
ップ６２１を構築することによって、サブネットワーク
内に存在するＮＩＳマップの管理を行うことができる。
具体的には、ＮＩＳマスター・マップ６２０が更新され
た場合、まず、ノード管理サーバー５内に存在するＮＩ
Ｓマスター・サーバー６００は、サブネットワーク内に
存在するすべてのＮＩＳスレーブ・サーバー６０１に対
して、ＮＩＳマスター・マップが更新されたことを通知
する(yppush)。ＮＩＳスレーブ・サーバー６０１は、前
記ＮＩＳマスター・マップ６２０の更新通知を受信した
場合、ＮＩＳマスター・サーバー６００に対して、ＮＩ
Ｓマスター・マップ６２０の転送を要求し、該転送され
たＮＩＳマスター・マップ６２０を基に、前記ＮＩＳス
レーブ・サーバー６０１は、ＮＩＳスレーブ・マップ６
２１を再構築する(ypxfr) 。
【０１６６】ここで、前記したサブネットワーク内のＮ
ＩＳマップの更新方法によると、ＮＩＳマスター・マッ
プ６２０が更新された場合、ＮＩＳマスター・サーバー
６００から、サブネットワーク内のＮＩＳスレーブ・サ
ーバー６０１に、ＮＩＳマスター・マップ６２０の更新
通知が送られるが、ＮＩＳスレーブ・サーバー６０１が
他の処理の実行等で、前記更新通知を受信できなかった
場合、該ＮＩＳスレーブ・サーバー６０１の管理するＮ
ＩＳスレーブ・マップ６２１が更新されない可能性があ
る。この点は、ＮＩＳスレーブ・サーバー６０１が、Ｎ
ＩＳマスター・サーバー６００に対して、定期的に、Ｎ
ＩＳマスター・マップ６２０の転送を要求し、該転送さ
れたＮＩＳマスター・マップ６２０を基にＮＩＳマップ
を再構築すること等によって改善することができる。ま
た、ＮＩＳスレーブ・サーバー６０１は、ＮＩＳマスタ
ー・サーバー６００に対して、ＮＩＳマスター・マップ
６２０の更新時刻の通知を要求し、該ＮＩＳスレーブ・
マップ６２１の更新時刻と比較することによって、ＮＩ
Ｓマスター・マップ６２０の更新を知ることができ、前
記更新情報に基づいてＮＩＳマップの再構築シーケンス
を実行することができる。
【０１６７】また、従来のＮＩＳには、以下に示すよう
な問題点があった。すなわち、従来のＮＩＳにおいて
は、ＮＩＳクライアント６１の、ＮＩＳサーバー（ＮＩ
Ｓマスター・サーバー６００／ＮＩＳスレーブ・サーバ
ー６０１）への１回目の帰属(bind)は、ＮＩＳクライア
ント・プロセス６１の起動時に行われるため、同一端末
上に、ＮＩＳサーバー・プロセスとＮＩＳクライアント
・プロセス６１が起動される場合でも、前記ＮＩＳクラ
イアント・プロセス６１は、同一の端末上のＮＩＳサー
バー・プロセスには帰属(bind)せず、ネットワークを経
由して他の端末上のＮＩＳサーバー・プロセスに帰属し
てしまうといった問題点があった。すなわち、従来のＮ
ＩＳクライアント６１のＮＩＳサーバーへの帰属(bind)
は、前記要求(ypbind)をサブネットワークにブロードキ
ャストし、前記要求に対し、一番早く応答を返したＮＩ
Ｓサーバーに、該要求を送信したＮＩＳクライアント６
１は帰属される。従って、ＮＩＳクライアント６１のＮ
ＩＳサーバーへの１回目の帰属(bind)は端末の起動(boo
t)期間中に行われ、前記起動(boot)期間中はＣＰＵは起
動処理に忙しく、ＮＩＳクライアント６１の送出する前
記要求(ypbind)に同一端末上のＮＩＳサーバーが直ちに
応答できず、他の端末上のＮＩＳサーバーの方が早く応
答し、前記ＮＩＳサーバーに帰属してしまうといった問
題点があった。前記問題点のため、ＮＩＳクライアント
６１は、ＮＩＳ情報にアクセスする場合、同一端末上に
ＮＩＳサーバーが起動されている場合でも、ネットワー
クを経由して他の端末上のＮＩＳサーバーにアクセスす
るため、ＮＩＳ情報にアクセスするのに時間がかかって
しまうといった問題点と、ネットワークに負荷をかけて
しまうといった問題点があった。
【０１６８】以下、従来のＮＩＳにおいて、ユーザープ
ロセスがネットワーク情報をアクセスする手順について
説明した後、本発明の一実施例における、上記問題点の
解決方法について、図６および図７を参照しながら説明
する。
【０１６９】従来のＮＩＳにおいては、ユーザープロセ
スが、ネットワーク情報をアクセスする場合、まず、前
記ユーザープロセスが、対応するライブラリ・コールの
呼び出しを行う。該呼び出しを受けたライブラリ・コー
ルは、まず、ＮＩＳファイル（ローカル・ファイル) を
参照し、検索したい情報が見つかるまで、前記ファイル
を参照する。検索したい情報が、前記ＮＩＳファイル６
３に見つからなかった場合、前記ライブラリ・コール
は、検索したい情報の検索をＮＩＳクライアント61に要
求し、該検索要求を受信したＮＩＳクライアント６１
は、該ＮＩＳクライアント６１が帰属(bind)しているＮ
ＩＳサーバーに、前記検索要求をリレーイングする。前
記検索要求を受信したＮＩＳサーバーは、該ＮＩＳサー
バーが管理しているＮＩＳマップを検索し、検索情報を
ＮＩＳクライアント６１を経由して、該検索要求を出力
したライブラリ・コールに返送する。該ＮＩＳサーバー
が前記ＮＩＳマップを検索した結果、検索情報が見つか
らなかった場合、オペレーティング・システムによって
は、検索要求をＤＮＳ(Domain Name Server)にリレーイ
ングするものも存在する。
【０１７０】本発明の一実施例においては、以上説明し
た従来のＮＩＳを、以下に示す２つの方法に変更するこ
とによって、前記問題点を解決している。
【０１７１】１つ目の方法は、ＮＩＳクライアント６１
の検索要求を送信する手順を変更することによって、前
記問題点を解決する方法である。この方法によるアルゴ
リズムを、図８および図９に示す。なお、図８および図
９に示すフローチャートは、図中のＬ１およびＬ２にお
いて連結されているものである。この点に関しては、後
述する説明で参照する、複数の図面に分けて示された他
のフローチャートについても、同様である。
【０１７２】まず、ＮＩＳクライアントでは、ライブラ
リ・コールによるネットワーク情報の検索が行われ（ス
テップ１）、ＮＩＳファイル（ローカル・ファイル) を
参照し（ステップ２）、検索したい情報が見つかった場
合、検索を終了する（ステップ３〜５）。
【０１７３】一方、検索したい情報が見つからなかった
場合、前記ライブラリ・コールは、ＮＩＳクライアント
に情報の検索を要求する（ステップ３）。この検索要求
を受信したＮＩＳクライアントと同一の端末(Host)に、
ＮＩＳサーバーが起動している場合（ＮＩＳサーバーが
起動しているかどうかは、ＯＳのプロセス管理表を検索
すれば知ることができる) 、前記ＮＩＳクライアント
が、前記同一の端末上に起動しているＮＩＳサーバー
に、前記検索要求をリレーイングする（ステップ７，
８）。そして、ＮＩＳマップの検索結果を知らせ（ステ
ップ９，１２，１４，１５あるいはステップ９，１２，
１６，１７，１８）、あるいはさらにＤＮＳに情報の検
索を要求し（ステップ１９）、その検索結果を知らせる
（ステップ２０，２１あるいはステップ２０，２２，２
３）。
【０１７４】前記ＮＩＳクライアントと同一の端末(Hos
t)にＮＩＳサーバーが起動していなかった場合は、前記
ＮＩＳクライアント６１は、該ＮＩＳクライアント６１
が帰属(bind)しているＮＩＳサーバーに、前記検索要求
のリレーイングが行われ（ステップ７，１０）、以下、
情報検索の後に、上記と同様の処理、すなわち検索結果
の通知、場合によってはＤＮＳへの情報検索要求および
その検索結果の通知が実行される（ステップ１３〜２
３）。
【０１７５】２つ目の方法は、ＮＩＳクライアントのＮ
ＩＳサーバーへの帰属(bind)方法を変更することによっ
て、前記問題点を解決する方法である。なお、図１０
に、この方法によるアルゴリズムを示す。
【０１７６】ここに、従来のＮＩＳにおいては、ＮＩＳ
クライアントのＮＩＳサーバーへの帰属方法(ypbind)
は、ＮＩＳクライアントが前記帰属要求をブロードキャ
ストした後、一番早く前記ＮＩＳクライアントに応答を
返したＮＩＳサーバーに、前記ＮＩＳクライアントが帰
属するという方法であった。前記ＮＩＳクライアント
の、ＮＩＳサーバーへの帰属方法を採用した場合、端末
の起動(boot)後、１回目のＮＩＳクライアントのＮＩＳ
サーバーへの帰属は端末の起動手順実行中に行われるた
め、前記端末のＣＰＵは、前記端末の起動手順の実行に
忙しく、前記１回目のＮＩＳクライアントの帰属要求(y
pbind)にすばやく応答できないといったことが原因で、
前記問題点が発生していた。
【０１７７】本発明の一実施例においては、ＮＩＳクラ
イアントがＮＩＳサーバーへ帰属を行う場合、まず、Ｎ
ＩＳクライアントと同一の端末にＮＩＳサーバーが起動
している場合（ステップ３１）、前記ＮＩＳサーバーに
前記ＮＩＳクライアントが帰属するとし（ステップ３
２）、ＮＩＳクライアントと同一の端末にＮＩＳサーバ
ーが起動していない場合に、前記ＮＩＳクライアント
が、ネットワーク上の他の端末に対し、前記帰属要求(y
pbind)をブロードキャストするとする（ステップ３
７）。
【０１７８】上記した本発明によるＮＩＳクライアント
のＮＩＳサーバーへの帰属方法を採用した場合で、ＮＩ
Ｓクライアントと同一の端末上にＮＩＳサーバーが起動
している場合、端末の起動後に行われる１回目のＮＩＳ
クライアントのＮＩＳサーバーの際、ＮＩＳクライアン
トは、同一の端末上に起動しているＮＩＳサーバーに帰
属されるため、前記した問題点を解決することができ
る。
【０１７９】なお、本発明においては、ノード管理サー
バーが、ＮＩＳクライアントの要求に応じて、前記ＮＩ
Ｓクライアントの帰属(bind)するＮＩＳサーバーを決定
することによって、ＮＩＳクライアントが網のブロード
キャスト機能を使わずに、自分の帰属するＮＩＳサーバ
ーを決定する方法を想定している。
【０１８０】具体的には、ＮＩＳクライアントは、該Ｎ
ＩＳクライアントが起動(boot)した時点では、該ＮＩＳ
クライアントが帰属(bind)するＮＩＳサーバーはまだ決
定されていないので、前記ＮＩＳクライアントは、帰属
先のＮＩＳサーバーを決定しなければならない。また、
ＮＩＳクライアントは、ＮＩＳサーバーからの応答が返
ってこない場合や、ＮＩＳサーバーからの応答がおそく
なった等の場合、帰属先のＮＩＳサーバーを変更するこ
とによって、ＮＩＳサーバーからの応答性能を改善しな
ければならない。
【０１８１】本発明の一実施例においては、ＮＩＳクラ
イアントは、帰属先のＮＩＳサーバーを決定または変更
する必要の生じた場合、まず、前記ＮＩＳクライアント
が、ノード管理サーバーに対してブート・チャネルを使
用して前記要求を送信する。前記要求を受信したノード
管理サーバーは、該ノード管理サーバーが管理する管理
ファイルを参照し、サブネットワークに登録されたＮＩ
Ｓサーバーのうち、負荷の小さなＮＩＳサーバーを検索
し、前記要求を送信したＮＩＳクライアントの帰属する
ＮＩＳサーバーを決定する。次に、ノード管理サーバー
は、前記要求を送信したＮＩＳクライアントから、該ノ
ード管理サーバーが決定したＮＩＳサーバーまでのコネ
クション（すなわち、インフォメーション・チャネル）
を設定するとともに、前記ＮＩＳクライアントが、前記
コネクションを使用するためのＶＰＩ／ＶＣＩ値等の設
定を行う。
【０１８２】また、前記ＶＰＩ／ＶＣＩ値等の設定にお
いて、予めＮＩＳクライアントが、ＮＩＳサーバーに対
してデータ転送を行うためのＶＰＩ／ＶＣＩ値等が設定
されている場合、新たにＶＰＩ／ＶＣＩ値等を設定し直
さずに、予め設定されたＶＰＩ／ＶＣＩ値等を用いて、
前記コネクションが使用できるようにした方が効率がよ
い。すなわち、ＮＩＳクライアントからの帰属先のＮＩ
Ｓサーバーの変更要求を受信した場合、ノード管理サー
バーは、ＮＩＳクライアントから変更後のＮＩＳサーバ
ーまでのコネクションの設定を行うとともに、前記ＮＩ
Ｓクライアントが、ＮＩＳサーバーとデータ転送するた
めに使用していたＶＰＩ／ＶＣＩ値等を用いて、前記コ
ネクションを使用できるように前記コネクションの設定
を行えばよい。
【０１８３】前記した方法を採用することによって、Ｎ
ＩＳクライアントは、帰属先のＮＩＳサーバーを決定す
る場合、ノード管理サーバーに前記要求を送信すればよ
いので、従来方法の場合のような前記要求をブロードキ
ャストして帰属先のＮＩＳサーバーを決定する必要はな
いので、本発明においては、ブロードキャストを用いず
にＡＲＰ／ＮＩＳを実現することができる。
【０１８４】なお、本発明によるブロードキャストを用
いないＡＲＰ／ＮＩＳの実現方法を、従来のブロードキ
ャスト機能を持たないＡＴＭ交換システムで行う場合、
まず、端末(Host)からノード管理サーバーまでのコネク
ション（すなわち、ブート・チャネル) を設定し、前記
コネクションを使用するためのＶＰＩ／ＶＣＩ値とし
て、特定値（例えば、VPI=all 1 、または、VPI/VCI=al
l 1)を割り当てる。次に、網のブロードキャスト機能を
使用している従来の端末インターフェースに対し、ブロ
ードキャスト・チャネルとして、前記特定値を割り当て
る。前記方法を採用することによって、前記端末上に起
動しているＮＩＳクライアントは、例えば、従来のブロ
ードキャストによってＮＩＳサーバーを決定する際、網
のブロードキャスト機能を用いるために前記特定値が使
用されるので、前記ＮＩＳクライアントからのＮＩＳサ
ーバー検索要求は、ブロードキャストされずに、ノード
管理サーバーに転送されることになる。
【０１８５】以上説明した方法を採用することによっ
て、ＮＩＳクライアントは、前記ＮＩＳサーバー決定要
求を、サブネットワーク内の端末にブロードキャストせ
ずに、前記要求をノード管理サーバーに転送し、ノード
管理サーバーが、前記ＮＩＳクライアントの帰属先のＮ
ＩＳサーバーを決定することによって、ＮＩＳクライア
ントは、帰属先のＮＩＳサーバーを決定することができ
る。
【０１８６】１−５．呼設定について 端末(Host)が行うデータ通信には、前述したように、コ
ネクション型のデータ通信とコネクションレス型のデー
タ通信がある。また、コネクション型データ通信には、
予め設定されたコネクションを用いて行うコネクション
型のデータ通信と、予めコネクションが設定されていな
い宛先に対して、コネクションを設定してからデータ通
信を行うコネクション型のデータ通信が存在する。ここ
では、予めコネクションが設定されていない宛先に対し
て、コネクションを設定してからデータ通信を行うコネ
クション型のデータ通信について説明する。
【０１８７】また、本節の次の(1-6) 節では、予め設定
されたコネクションを用いて行うコネクション型のデー
タ通信と、コネクションレス型のデータ通信について説
明する。
【０１８８】以下、本発明の一実施例による呼設定手順
を用いた、予めコネクションが設定されていない宛先に
対して、コネクションを設定してからデータ通信を行う
方法について、図１１を参照しながら具体的に説明す
る。また、呼設定時の各アルゴリズムのうち、端末のデ
ータ通信のアルゴリズムを図１２，１３に、呼設定サー
バの呼設定アルゴリズムを図１４，１５に、ノード管理
サーバのコネクション設定アルゴリズムを図１６に、ノ
ード設定サーバの設定アルゴリズムを図１７に、それぞ
れ示す。
【０１８９】端末(Host)は、データ通信を行う必要が生
じた場合、まず、宛先のデータ受信端末までのデータ転
送に必要なＱＯＳを持つコネクションがすでに設定され
ているかどうか、ＮＩＳ等を用いてＶＰＩ／ＶＣＩテー
ブルを検索する。すなわち、データ通信を行う必要の生
じたユーザ・プロセスは、まず、端末固有のＶＰＩ／Ｖ
ＣＩテーブルであるＮＩＳファイル６３を参照し、次
に、サブネットワークに属する端末に共通なＶＰＩ／Ｖ
ＣＩテーブルであるＮＩＳマップ６２を参照し、宛先の
データ受信端末までのセル転送のための、ＶＰＩ／ＶＣ
Ｉ値等が、すでに設定されているかどうか、宛先のデー
タ受信端末の名前をキーとして、前記テーブルを検索す
る（図１２のステップ５２，５４）。
【０１９０】具体的には、端末上の、データ通信を行う
必要の生じたユーザ・プロセスは、対応するコネクショ
ンがすでに設定されているかどうか調べるため、対応す
るライブラリ・コールを実行する。前記ライブラリ・コ
ールは、まず、端末固有のＮＩＳファイル６３に、宛先
のデータ受信端末までの、セル転送時に用いるＶＰＩ／
ＶＣＩ値等が、すでに設定されているかどうか、参照要
求を行う（ステップ５２）。前記ＮＩＳファイル６３
に、前記ＶＰＩ／ＶＣＩ値等がすでに設定されていた場
合、前記ユーザ・プロセスは、前記ＶＰＩ／ＶＣＩ値等
を用いて、セルを作成し、作成したセルを送信すること
によって、データ転送を開始する（図１３のステップ６
３，６４）。
【０１９１】前記ＮＩＳファイル６３に、前記ＶＰＩ／
ＶＣＩ値等が設定されていなかった場合、前記ライブラ
リ・コールは、前記ＮＩＳファイル６３に対して行った
参照要求を、該端末上に起動しているＮＩＳクライアン
ト・プロセス６１にリレーイングし、前記ＮＩＳクライ
アント６１は、宛先のデータ受信端末までのセル転送時
に用いるＶＰＩ／ＶＣＩ値等について、前記ＮＩＳクラ
イアント６１が帰属(bind)しているＮＩＳサーバーに問
い合わせる（図１２のステップ５３）。
【０１９２】前記問い合わせを受信したＮＩＳサーバー
は、該ＮＩＳサーバーが管理しているＮＩＳマップ６２
を検索し、前記ユーザー・プロセスのセル転送時に用い
るＶＰＩ／ＶＣＩ値等が、すでに設定されているかどう
か検索する（ステップ５４）。前記ＶＰＩ／ＶＣＩ値等
がすでに設定されていた場合、該ＮＩＳサーバーは、前
記ＶＰＩ／ＶＣＩ値等を、ＮＩＳクライアント６１を経
由して前記問い合わせをしたユーザ・プロセスに通知す
る（ステップ５４，６２）。一方、前記ＶＰＩ／ＶＣＩ
値等が設定されていなかった場合、該ＮＩＳサーバー
は、検索の失敗を、ＮＩＳクライアント６１を経由して
前記問い合わせをしたユーザ・プロセスに通知する（図
１２のステップ５４，５５）。
【０１９３】前記ＮＩＳサーバーから、セル転送時に用
いるＶＰＩ／ＶＣＩ値等の通知を受けたユーザ・プロセ
スは、前記ＶＰＩ／ＶＣＩ値等を用いて、セルを作成
し、作成したセルを送信することによって、データ転送
を開始する（図１３のステップ６２，６４）。
【０１９４】前記ＮＩＳサーバーから、セル転送時に使
用するＶＰＩ／ＶＣＩ値等の検索の失敗通知を受信した
ユーザ・プロセス、またはＮＩＳクライアント・プロセ
ス６１は、以下に説明する呼設定手順を実行することに
よって、セル転送時に用いるＶＰＩ／ＶＣＩ値等を獲得
する。なお、ユーザ・プロセス、またはＮＩＳクライア
ント６１は、ＶＰＩ／ＶＣＩ値等の獲得要求がタイムア
ウトすることによって、以下に示す、呼設定手順を実行
してもよい。
【０１９５】具体的には、端末上のユーザ・プロセスま
たはＮＩＳクライアント・プロセス６１は、呼設定クラ
イアント・プロセスを起動し、前記起動された呼設定ク
ライアント・プロセスは、端末の起動時に設定されたシ
グナリング・チャネル１３を用いて、シグナリング・セ
ルをＡＴＭ交換システム内に存在する呼設定サーバーに
転送する（図１２のステップ５６）。
【０１９６】呼設定サーバーは、前記シグナリング・セ
ルを受信すると（図１４のステップ７０）、前記シグナ
リング・セル中に記述された、通信品質（ＱＯＳ、トラ
ヒック・パラメータ等) で、宛先のデータ受信端末まで
のコネクションの設定を、ノード管理サーバー５に要求
する（図１４のステップ７２）。
【０１９７】ノード管理サーバー５は、前記コネクショ
ン設定要求を受信すると（図１６のステップ９０）、該
ノード管理サーバー５が管理する管理ファイル５６を参
照し、前記データ送信端末が、申告したトラヒック・パ
ラメータでセルを送出した場合、網がサービスを提供し
ているコネクションのＱＯＳと、前記データ送信端末の
要求するコネクションのＱＯＳを、網が保証することが
できるかどうか判定する （図１６のステップ９１）。
前記判定等の結果、網が前記データ送信端末の要求する
コネクションを受け入れることができる場合、前記コネ
クションを設定するため、ノード管理サーバー５は、対
応するノード設定サーバー４に対し、ルーティングタグ
・テーブルといった対応するハードウェアの設定を要求
する（図１６のステップ９３）。一方、前記判定等の結
果、網が前記データ送信端末の要求するコネクションを
受け入れることができない場合、前記ノード管理サーバ
ー５は、呼設定サーバーを経由して（図１６のステップ
９２）、前記呼設定要求を受け入れない旨、前記データ
送信端末に通知する（図１４のステップ７５，７６，７
８）。
【０１９８】ノード設定サーバー４は、前記ハードウェ
ア設定要求を受信すると（図１７のステップ１１０）、
ルーティングタグ・テーブルといった、対応するハード
ウェアに対し、指定されたデータを書き込むとともに
（図１７のステップ１１１）、ノード設定サーバー４が
管理するbackupファイル４２がある場合、前記backupフ
ァイル４２に設定内容の書き込みを実行する（図１７の
ステップ１１３〜１１６）。前記ノード設定サーバー４
は、前記設定が終了した場合、前記設定要求を出したノ
ード管理サーバー５に対して、前記設定の終了を通知す
る（図１７のステップ１１２）。
【０１９９】ノード管理サーバー５は、前記設定終了の
通知を受信すると（図１６のステップ９６）、該ノード
管理サーバー５の管理する管理ファイル５６の更新を行
い（図１６のステップ９８）、呼設定が要求された前記
コネクションが、サブネットワークに属するすべての端
末に共通するコネクションであった場合、必要に応じ
て、前記管理ファイル５６からＮＩＳマップ６２が作成
され、該作成したＮＩＳマップ６２で、該ノード管理サ
ーバー５が管理するＮＩＳマップ６２を更新する（図１
６のステップ９９〜１００）。
【０２００】ここに、本発明の一実施例においては、ノ
ード管理サーバー５は、ＮＩＳマスター・サーバー６０
０としても機能していると想定しているので、前記ＮＩ
Ｓマップ６２が更新された場合、前記マップを管理して
いるノード管理サーバー５は、対応するＮＩＳスレーブ
・サーバー６０１に対し、該当するＮＩＳマップ６２の
更新を要求する（図１６のステップ１０１）。最後に、
ノード管理サーバー５は、以上説明したような設定が終
了した場合、設定の終了と前記コネクションの設定とを
要求したデータ送信端末がセル転送時に使用するＶＰＩ
／ＶＣＩ値等を、前記呼設定サーバーを経由して、前記
データ送信端末へ通知する（図１６のステップ９７と図
１４のステップ７７）。
【０２０１】データ送信端末は、前記設定終了とＶＰＩ
／ＶＣＩ値等の通知とを受けると（図１２のステップ５
９）、前記ＶＰＩ／ＶＣＩ値等を基にセルを作成し、該
作成したセルを、呼設定時に、網に申告したトラヒック
・パラメータを違反しないように送信することによっ
て、データ転送を開始する（図１２のステップ６０，６
４）。なお、前記データ送信端末は、宛先のデータ受信
端末に対するコネクションのうち、該端末に固有なＶＰ
Ｉ／ＶＣＩ値等を記憶しているＮＩＳファイル６３に、
前記網から通知されたＶＰＩ／ＶＣＩ値等を追加しても
よい。
【０２０２】前記した呼設定手順は、データ送信端末と
データ受信端末が、同一のサブネットワークに存在する
場合であったが、以下、データ送信端末とデータ受信端
末が、同一のサブネットワークに存在しない場合につい
て、前記した呼設定手順との差分について、具体的に説
明する。
【０２０３】呼設定サーバーが受信した呼設定要求のう
ち、該呼設定で要求されるコネクションのエンド・ポイ
ントであるデータ受信端末が、前記呼設定サーバーが対
象とするサブネットワークにない場合（図１４のステッ
プ７１）、前記呼設定サーバーは、対象とするサブネッ
トワーク内の呼設定と、対象とするサブネットワーク外
の呼設定の両方について対応しなければならない。呼設
定サーバーが対応しなければならない前記呼設定のう
ち、該呼設定サーバーが対象とするサブネットワーク内
の呼設定（データ送信端末からＩＷＵまでの呼設定) に
ついては、前記したデータ送信端末とデータ受信端末が
同一のサブネットワーク内にある場合と同様である（図
１５のステップ７９）。
【０２０４】一方、該呼設定サーバーが対象とするサブ
ネットワーク外の呼設定については、該呼設定サーバー
が受信した呼設定要求を、対応するサブネットワーク外
の呼設定サーバーにリレーイングすることによって実行
される（図１５のステップ８０）。すなわち、前記呼設
定要求を受信した呼設定サーバーは、該受信したデータ
送信端末からデータ受信端末までの呼設定要求を、サブ
ネットワーク内の対応するＩＷＵからデータ受信端末ま
での呼設定要求に変更し、前記変更した呼設定要求を、
前記呼設定サーバー７は、対応するサブネットワーク外
の呼設定サーバーに、対応するシグナリング・チャネル
１３を用いて転送する。前記サブネットワーク内の呼設
定サーバー７は、該サブネットワーク内のノード管理サ
ーバー５からコネクションの設定通知および前記コネク
ションを用いるためのＶＰＩ／ＶＣＩ値等を受信すると
ともに（図１５のステップ８３）、該サブネットワーク
外の対応する呼設定サーバーからコネクションの設定通
知を受信した場合（図１５のステップ８４）、前記サブ
ネットワーク内の呼設定サーバーは、該呼設定要求を送
信したデータ送信端末に対し、呼設定の終了と、前記コ
ネクションを用いるためのＶＰＩ／ＶＣＩ値等とを通知
する（図１４のステップ７７）。
【０２０５】前記した手順において、変更された呼設定
要求を受信したサブネットワーク外の呼設定サーバーの
行う手順については、サブネットワーク内の呼設定サー
バー７の行う手順と同様である。すなわち、該呼設定要
求を受信したサブネットワーク外の呼設定サーバーは、
該呼設定要求を、担当するサブネットワーク内の呼設定
と、担当するサブネットワーク外の呼設定要求に分割
し、担当するサブネットワーク内の呼設定に対しては、
コネクションの設定を、対応するノード管理サーバー５
に要求する。また、担当するサブネットワーク外の呼設
定要求に対しては、呼設定要求を、前記したように変更
した後、対応する呼設定サーバーに対し、シグナリング
・チャネルを用いて転送する。
【０２０６】前記したノード管理サーバー５の呼設定手
順においては、該ノード管理サーバー５は、呼設定サー
バー７からの要求に従って、ノード設定サーバー４に対
しハードウェアの設定要求を送信するとしていた。ノー
ド管理サーバー５が、要求を受け付けた旨を、呼設定サ
ーバーからの要求を受け付けるとすぐに呼設定サーバー
へ返答せずに、処理が終了してから呼設定サーバーへ返
答する場合、以下のようなことが生じる可能性がある。
すなわち、前記方法を採用した場合、呼設定サーバーが
呼設定要求を送信する度に、ノード管理サーバー５は、
ハードウェアの設定要求をノード設定サーバー４に送信
するが、前記呼設定サーバー７が、前記呼設定要求のタ
イムオーバー等の原因によって呼設定要求を再送した場
合、該ノード管理サーバー５は、ノード設定サーバー４
に対してハードウェアの設定要求を再送する可能性があ
る。この点は、以下の手順を採用することにより回避で
きる。すなわち、ノード管理サーバー５が、呼設定サー
バー７から呼設定要求を受信した場合、管理ファイル５
６を参照し、前記呼設定要求に対し設定するコネクショ
ンが、すでに前記管理ファイル５６に登録されていた場
合、ノード設定サーバー４に対しては設定要求を出さず
に、端末に対して設定完了通知を出すことによって、上
記可能性は回避できる。
【０２０７】しかし、この場合でも、管理ファイル５６
に登録されている情報と、実際にハードウェアに設定さ
れている設定データとが異なるときは、端末からのコネ
クション設定要求が無視される可能性がある。この点に
関しては、管理ファイル５６に登録されているコネクシ
ョンに対し、１回目の設定要求に対しては前記した通り
何のアクションも起こさないが、２回目以降の設定要求
に対して何らかのアクション（例えば、実際に設定を行
う、または、エラーを返す等) を起こすことによって改
善される。
【０２０８】同様に、ノード設定サーバー４は、ノード
管理サーバー５から、ハードウェア・テーブルの設定要
求を受信した場合、backupファイル４２が存在する場
合、前記backupファイル４２を参照し、前記ハードウェ
アの設定がすでに実行されている場合、前記設定要求に
対してはハードウェアの設定を行わずに、ノード管理サ
ーバー５に対して設定完了を通知することによって、性
能が改善される。さらに、コネクション設定サーバー
は、backupファイル４２にすでに実行されたアクション
に対して、１回目のアクション要求に対してはアクショ
ンを起こさず、２回目以降のアクション要求に対して何
らかのアクション（例えば、実際に設定を行う、また
は、エラーを返す等) を起こすことによって、backupフ
ァイル４２と実際のハードウェアの不一致による不具合
を改善することができる。
【０２０９】１−６．予め設定されたコネクションを用
いたデータ通信について ここでは、前記したように、予め設定されたコネクショ
ンを用いて行うコネクション型のデータ通信と、コネク
ションレス型のデータ通信について、図１１、図１２、
および１３を参照しながら、具体的に説明する。
【０２１０】本発明の一実施例においては、前記したよ
うに、端末(Host)上の、データ通信を行う必要の生じた
ユーザ・プロセスは、まず、端末固有のＶＰＩ／ＶＣＩ
テーブルであるＮＩＳファイル６３を参照し、次に、サ
ブネットワークに属する端末に共通なＶＰＩ／ＶＣＩテ
ーブルであるＮＩＳマップ６２を参照し、宛先のデータ
受信端末までのセル転送に必要なＱＯＳを満たすコネク
ションが、すでに設定されているかどうか、宛先のデー
タ受信端末の名前をキーとして、前記テーブルを検索す
る。前記ＮＩＳファイル６３またはＮＩＳマップ６２を
参照した結果、宛先のデータ受信端末までのコネクショ
ンがすでに設定されていた場合、前記すでに設定されて
いるコネクションを用いてデータ転送を開始する。すな
わち、前記ユーザ・プロセスは、前記２つのテーブルを
検索した結果、得られたVPI またはＶＰＩ／ＶＣＩ値等
を使用して、送信データから、定義されたプロトコルに
従ってユーザセルを作成し、該作成したセルを、前記テ
ーブル検索時に用いたトラヒック・パラメータを違反し
ないように送信することによって、データ転送を開始す
る。
【０２１１】以上説明した、予め設定されたコネクショ
ンを用いてデータ通信を行う場合には、以下に説明する
ような、ＰＶＣ(Permanent Virtual Connection)を用い
てデータ通信を行う場合と、呼接続が終了していないコ
ネクションを用いて、コネクション型のデータ通信を再
開する場合と、コネクションレス型のデータ通信を行う
場合の、３通りの場合が存在する。以下、前記３とおり
の場合について、具体的に説明する。
【０２１２】ＰＶＣを用いたデータ通信は、よくデータ
通信が行われる端末間に、予めコネクションを設定して
おくことによって、実際にデータ通信を行う必要の生じ
た時に、呼設定を行わずに、データ転送を開始すること
のできる効率的なデータ通信方法をユーザに提供する方
法である。前記ＰＶＣを用いたデータ通信方法を、本発
明のＡＴＭ交換システムで行うためのは、前記よくデー
タ通信が行われるデータ送信端末とデータ受信端末間
に、予め、前記データ通信に必要なＱＯＳと、トラヒッ
ク・パラメータを持つコネクションを設定しておき、前
記コネクションのためのＶＰＩ／ＶＣＩ値等を、ＮＩＳ
ファイル６３（またはＮＩＳマップ６２）に登録してお
く。
【０２１３】本発明によるＡＴＭ交換システムにおいて
は、前記したデータ送信端末が、データ通信を行う必要
が生じた場合、宛先のデータ受信端末までのコネクショ
ンが、すでに設定されているかどうか調べるために、宛
先のデータ受信端末の名前と、データ通信に必要なＱＯ
Ｓを、キーとして、ＮＩＳファイル６３（またはＮＩＳ
マップ６２) が検索される。前記ＮＩＳファイル６３
（またはＮＩＳマップ６２) には、ＰＶＣを用いたデー
タ通信のためのＶＰＩ／ＶＣＩ値等が予め設定されてい
るので、前記検索の結果、前記コネクションに対するＶ
ＰＩ／ＶＣＩ値等が検索される。前記データ送信端末
は、前記検索されたＶＰＩ／ＶＣＩ値等を用いて、送信
するセルを作成し、前記ＮＩＳファイル６３（またはＮ
ＩＳマップ６２) 検索時に得られたトラヒック・パラメ
ータに違反しないように、該作成したセルを送信するこ
とによって、呼設定を行わずにデータ転送を開始するこ
とができる。
【０２１４】当初予定していたデータ通信は終了した
が、コネクションの接続を終了していないコネクション
を用いて、コネクション型のデータ通信を再開する場合
には、以下に示す２通りのものが存在する。すなわち、
１つ目の場合は、ユーザ側の立場から、データ転送が終
了したコネクションに対して、コネクションの接続を解
除しないことによって、同一の宛先に呼設定を行わず
に、効率的にデータ通信を行う目的のためのものであ
る。２つ目の場合は、網側の立場から、データ通信が行
われたデータ送信端末とデータ受信端末の間には、近い
将来に再びデータ通信が行われる可能性が高く、前記コ
ネクションに対して、可能な限りコネクションの接続を
保持することによって、前記コネクションに対して網が
再び呼設定要求の処理を実行する手間を省略するための
ものである。
【０２１５】１つ目の場合の、ユーザの立場によるコネ
クションの切断の保留は、ユーザからのコネクションの
切断要求によって、コネクションの接続を解除すること
によって実現できる。すなわち、網は、ユーザからのコ
ネクションの切断要求を受信するまでは、一度呼設定さ
れたコネクションを解除しないことによって、ユーザ
は、前記コネクションを用いて、同一の宛先に対して、
呼設定を行わずに効率的にデータ通信を行うことができ
る。
【０２１６】この方法をユーザに提供した場合、ユーザ
は効率的にデータ通信を行えるという利点がある。一
方、ユーザがコネクションの切断要求を行わない場合、
新たにコネクションを設定できない可能性がある。この
点への対処方としては、コネクションの設定継続時間に
対し課金をすることによって、ユーザのコネクションの
切断要求を促す方法が考えられる。本発明の一実施例に
おいては、前記したユーザの立場によるコネクションの
切断の保留は、ＰＶＣによる方法によってユーザにサー
ビスを提供することを想定する。
【０２１７】２つ目の場合の網の立場によるコネクショ
ン切断の保留は、ユーザのデータ通信が終了した場合で
も、一定期間、前記データ通信に用いられたコネクショ
ンの接続を終了しないことによって、前記一定期間内に
再び同一のデータ通信が行われる場合、再び網が呼設定
処理を行わずに、ユーザに対し、サービスを提供できる
といった方法である。前記方法は、コネクションの切断
を、ライフタイムと呼ばれる一定期間行わずに、前記ラ
イフタイムの期間内に同一のデータ通信が行われる場
合、呼設定を行わずにデータ通信を行うことによって実
現することができる。前記方法を採用した場合、データ
通信が終了しても、前記ライフタイムの期間内はコネク
ションが切断されないので、前記ライフタイムの期間内
に、同一のデータ通信が行われる場合は、ユーザは呼設
定要求を行わずにデータ通信を行うことによって、網
は、呼設定要求に対する処理を行う手間が軽減されると
いった利点がある。
【０２１８】一方、１つ目の場合に対して、コネクショ
ンの継続時間に対して課金する方法を採用した場合、ユ
ーザは、コネクションの継続時間に対する課金を少なく
するため、コネクションの継続時間、すなわちライフタ
イムに対する時間設定を小さくしようとする。そのした
結果として、同一の宛先に対してデータ通信が行われる
場合でも、前記ライフタイムの期間内に、前記データ通
信が行われる可能性が低下し、前記同一の宛先に対する
データ通信が行われる際にも、ユーザが、呼設定を行わ
なければならない場合が多くなることも考えられる。こ
の点は、ユーザの送信する呼設定要求に対して課金する
ことによって、ユーザの、ライフタイムに対する時間設
定を長く設定するように誘導することによって、改善す
ることができる。なぜなら、ユーザは、呼設定要求回数
に対する課金およびライフタイムに対する課金の課金金
額の合計が最小となるように、ライフタイムに対する時
間設定を変えるため、網が呼設定要求回数に対する課金
を高くした場合、ユーザは、ライフタイムに対する時間
設定を長くすることによって、同一の宛先に対してデー
タ通信を行う場合、呼設定要求を出さずにデータ通信を
行おうとするためである。
【０２１９】一方、企業内ネットワークの場合は、デー
タ通信に対して課金が行われないので、前記課金を行う
ことによって、ユーザのライフタイムに対する時間設定
を、網側の意図によって誘導することはできない。従っ
て、前記した企業内ネットワークの場合は、網にとって
都合のよいライフタイムに対する時間設定を、ユーザが
使用するように推奨することが望ましい。
【０２２０】以下、本発明の一実施例においては、コネ
クションに対して、ライフタイムを設定する方法を想定
して説明する。なお、前記したＰＶＣに対しては、無限
大のライフタイムを設定することによって対応すること
ができる。
【０２２１】以下、コネクションレス型データ通信を、
予め設定されたコネクションを用いて行う場合につい
て、具体的に説明する。
【０２２２】ここに、従来のＡＴＭ交換システムにおい
ては、コネクションレス型のデータ通信は、ＣＬＳＦ処
理手段によって実行される。すなわち、データ送信端末
が、コネクションレス型のデータ通信を行う場合、情報
セルをＣＬＳＦ処理手段に送信することによって、前記
データ通信を実行することができる。一方、従来のコン
ピュータ間のデータ通信は、コネクションレス型のデー
タ通信方法を用いて行われていたので、従来構成のＡＴ
Ｍ交換システムにおいて、従来方法によってコンピュー
タ間のデータ通信を実行した場合、コンピュータ間のデ
ータ通信は、ＣＬＳＦ処理手段に集中してしまう、とい
った問題点があった。
【０２２３】前記問題点については、コンピュータ間の
データ通信を行う端末間に、予めＱＯＳの保証を必要と
しないコネクションを設定しておき、端末が、前記デー
タ通信を行う必要が生じた場合、前記コネクションを用
いてデータ通信を行うことによって、ＣＬＳＦ処理手段
を経由せずにデータ通信が行えるので、前記問題点は軽
減される。具体的には、ネットワークの立ち上げ時、ま
たは、端末の立ち上げ時、または、端末の要求に従っ
て、コンピュータ間のデータ通信を行う端末間に、予め
ＱＯＳの保証を必要としないコンピュータ間のデータ通
信用のコネクションを設定しておく。端末(Host)が、従
来方法によって、コンピュータ間のデータ通信を行う場
合、端末上のソフトウェア、またはＴＣＰ等のプロトコ
ル・ソフトウェアによって、廃棄されたパケットに対し
て再送制御等が行われるので、前記データ通信を行うた
めのコネクションに対してはセル廃棄があってもよい。
また、コンピュータ間等のデータ通信の多くの場合は、
ファイル転送等のデータ転送の遅延が許されるデータ転
送である。従って、前記コンピュータ間のデータ通信
は、ＱＯＳ（セル廃棄率、セル転送遅延等) の保証を必
要としないライフタイムが無限大のコネクションで提供
することができる。前記コネクションに対するＶＰＩ／
ＶＣＩ値等は、予めＮＩＳマップ６２またはＮＩＳファ
イル６３に登録しておき、前記端末が、前記宛先に対す
るデータ通信を行う必要が生じた場合、前記ＮＩＳファ
イル６３またはＮＩＳマップ６２を検索することによっ
て、前記コネクションに対するＶＰＩ／ＶＣＩ値等を獲
得し、前記ＶＰＩ／ＶＣＩ値等を用いて、送信セルを作
成し、前記セルを送信することによってデータ転送を開
始する。
【０２２４】１−７．保守・管理について 本発明の一実施例においては、ＡＴＭ交換システムの保
守・管理の大部分は、ノード管理サーバー５が行うこと
を想定している。以下、図１を参照しながら、本発明の
一実施例におけるノード管理サーバー５によるＡＴＭ交
換システムの保守・管理方法について具体的に説明す
る。本発明の一実施例で想定しているＡＴＭ交換システ
ムの保守・管理には、以下の項目が存在する。 （１）コネクションの接続確認 （２）端末または各種サーバーの生存確認 （３）ハードウェア・テーブル等の正当性確認およびソ
フトウェア・テーブル等の正当性確認 （４）ハードウェア・テーブルとソフトウェア・テーブ
ル間の整合性確認 （５）複数ソフトウェア・テーブル間の整合性確認 （６）統計情報の収集および統計情報に基づくコネクシ
ョン制御 以下、前記した各項目について、具体的に説明する。
【０２２５】１−７−１．コネクションの接続確認 従来のＡＴＭ交換システムでは、コネクションの接続確
認は、物理リンクのエンド・エンド間の物理レイヤでの
接続確認と、ＡＴＭコネクションのエンド・エンド間の
ＡＴＭレイヤでの接続確認の２レベルの接続確認を想定
している。
【０２２６】本発明の一実施例においては、前記物理レ
イヤでの接続確認は、ハードウェアに組み込まれた論理
回路（セル同期回路、フレーム同期回路等) によって行
われるものとし、前記論理回路によって行われた物理レ
イヤでの接続確認情報は、ハードウェア上のレジスタま
たはＲＡＭ等に、必要に応じて書き込まれるとする。ま
た、本発明の一実施例においては、ノード管理サーバー
５は、前記接続確認情報等を、以下に示す３つの方法に
よって獲得することを想定している。すなわち、１つ目
の方法は、ノード管理サーバー５が、ノード設定サーバ
ー４を経由して、ハードウェア上の前記接続確認情報等
を読み取る方法であり、最も一般的な方法と考えられ
る。２つ目の方法は、ノード設定サーバー４が、ハード
ウェア上の前記接続確認情報等を、周期的にポーリング
する方法である。前記ノード設定サーバー４がポーリン
グした結果得られた接続確認情報等に異常が検出された
場合、ノード設定サーバー４が、割込みでノード管理サ
ーバー５に通知するか、それとも前記接続確認情報等を
ノード設定サーバー４が管理するbackupファイル４２に
書き込んでおき、ノード管理サーバー５がノード設定サ
ーバー４を経由して、前記backupファイル４２に書き込
まれた情報をアクセスすることによって、ノード管理サ
ーバー５が前記情報にアクセスすることができる。前記
した２つ目の方法は、ハードウェアとソフトウェアにと
って、最も負荷の小さい方法と考えられる。３つ目の方
法は、物理レイヤで得られた接続確認情報等に異常が検
出された場合、前記異常を検出したハードウェア上のロ
ジックが、割込みで前記異常をノード設定サーバー４に
通知し、ノード設定サーバー４は、前記異常情報をノー
ド管理サーバー５にリレーイングすることによって、ノ
ード管理サーバー５は、異常情報にアクセスするという
方法である。前記した３つ目の方法は、ノード管理サー
バー５が、異常情報を最も早くアクセスできる方法と考
えられる。
【０２２７】また、前記ＡＴＭレイヤでの接続確認は、
ＡＴＭコネクションのエンド・エンド間に、接続確認用
のＯＡＭセルを転送することによって、前記ＡＴＭレイ
ヤでの接続確認を実行することができる。具体的には、
ノード管理サーバー５は、管理ファイル５６に登録され
たコネクションのうち、接続確認を行う必要のあるコネ
クションに対して、コネクションの一方のエンド・ポイ
ントをノード管理サーバー５とし、コネクションのもう
一方のエンド・ポイントでループバックされる（また
は、応答を返す）ような設定を施した接続確認用のＯＡ
Ｍセルを送信する。前記接続確認用のＯＡＭセルが、前
記コネクションのエンド・ポイントでループバックさ
れ、前記ＯＡＭセルを、前記ノード管理サーバー５が、
再び受信することによって、前記接続確認を実行するこ
とができる。
【０２２８】また、前記ノード管理サーバー５は、必要
に応じて、前記ＯＡＭセルを送信してから、再び前記Ｏ
ＡＭセルを受信するまでの時間を測定することによっ
て、前記ＯＡＭセルを送信したコネクションの、セルの
混み具合（輻輳状態) を知ることができる。
【０２２９】以上説明した、物理レイヤとＡＴＭレイヤ
の接続確認等の情報は、必要に応じて管理ファイル５６
に書き込まれ、管理ファイル５６をアクセスすることに
よって、ＡＴＭ交換システム内のすべての接続確認情報
にアクセスできるような手段を、網はシステム管理者に
対し提供してもよい。
【０２３０】１−７−２．端末または各種サーバーの生
存確認 以下、端末または各種サーバーの生存確認方法について
説明する。なお、生存とは、端末や各種サーバーなどの
個々の装置が正常に動作していることを言うものとす
る。
【０２３１】本発明の一実施例においては、端末（また
は各種サーバー）の生存確認は、以下に示すような、３
レベルの確認方法によって行うことを想定する。すなわ
ち、所定のチャネル、例えばブートチャネルやメタシグ
ナリングチャネルを使って、第１レベルの生存確認とし
て、ノード管理サーバー５から端末（または、各種サー
バー) までのコネクションの接続確認とし、第２レベル
の生存確認として、ノード管理サーバー５から端末（ま
たは、各種サーバー) 上のプロトコル・ソフトウェアま
でのコネクションの接続確認とし、第３レベルの生存確
認として、ノード管理サーバー５から端末（または、各
種サーバー) 上のソフトウェアまでのコネクションの接
続確認とする。
【０２３２】第１レベルの生存確認は、前記したＡＴＭ
レイヤでのコネクションの接続確認方法と同様の方法で
実現することができる。すなわち、ノード管理サーバー
５から端末（または、各種サーバー) で、ループバック
されるような設定を施した接続確認用のＯＡＭセルを送
信し、前記ＯＡＭセルを前記ノード管理サーバー５が再
び受信することによって、第１レベルの生存確認を実現
することができる。
【０２３３】第２レベルの生存確認は、従来から行われ
ているＴＣＰ／ＩＰにおけるＩＣＭＰ（Internetwork C
ontrol Message Protocol ）のエコー（echo）要求パケ
ットの送受信と同じような方法によって実現することが
できる。すなわち、端末（または、各種サーバー) 上に
実装されるプロトコル・ソフトウェアの中に、特定のフ
ォーマットを持つセルを受信した場合、受信セルの宛先
と送り元をひっくり返したセルを送信するルーチンを設
け、前記ルーチンを用いて送り元から送信されたセルを
送り元に返送することによって、端末（または、各種サ
ーバー) 上のプロトコル・ソフトウェアの生存確認を行
うことができる。前記第２レベルの生存確認を用いるこ
とによって、ホスト・インターフェースのハードウェア
とソフトウェアとの間のインターフェースが、正常に機
能していることを確認することもできる。
【０２３４】第３レベルの生存確認は、前記した第２レ
ベルの生存確認と同じ方法を用いて実行することができ
る。すなわち、端末（または、各種サーバー) 上に実装
されるアプリケーション・ソフトウェアの中に、特定の
フォーマットを持つセルを受信した場合、受信セルの宛
先と送り元をひっくり返したセルを送信するルーチンを
設け、前記ルーチンを用いて送り元から送信されたセル
を送り元に返送することによって、端末（または、各種
サーバー) 上のアプリケーション・ソフトウェアの生存
確認を行うことができる。
【０２３５】１−７−３．ハードウェア・テーブル等の
正当性確認およびソフトウェア・テーブル等の正当性確
認 本発明の一実施例においては、ソフトウェア・テーブル
( もしくは、ハードウェア・テーブル) として、backup
ファイル４２、configファイル５５、管理ファイル５
６、ＮＩＳマップ６２、ＮＩＳファイル６３の５つのフ
ァイルを想定している。前記ソフトウェア・テーブルと
ハードウェア・テーブルの正当性は、パリティ・チェッ
ク等の方法によって確認することができる。すなわち、
テーブルにデータを書き込む場合、データとともにパリ
ティ・データもテーブルに書き込んでおき、テーブルか
らデータを読み出す場合、前記パリティ・データを基に
パリティ・チェックを行うことによって、テーブルの正
当性を確認することができる。
【０２３６】１−７−４．ハードウェア・テーブルとソ
フトウェア・テーブル間の整合性確認 本発明の一実施例においては、ハードウェア・テーブル
と、ノード管理サーバー５が管理するbackupファイル４
２（ソフトウェア・テーブル) との間に、整合性が取れ
ていることを想定している。すなわち、本発明において
は、ハードウェアの検出情報（例えば、エラー情報)
を、ノード管理サーバー５がアクセスする方法として、
ノード設定サーバー４が、ハードウェア・テーブルをポ
ーリングして、backupファイル４２に書き込んだ情報
を、ノード管理サーバー５が、ノード設定サーバー４を
経由して読み取ることによって、効果的にアクセスする
方法を想定していた。また、本発明においては、交換機
に電源断等の障害が発生し、ハードウェア・テーブルの
内容が破壊された場合、ノード設定サーバー４が、back
upファイル４２に書かれた情報を基に、ハードウェア・
テーブル等を復元することを想定していた。従って、本
発明においては、ハードウェア・テーブルとソフトウェ
ア・テーブルとの間に、整合が取れていることが必要で
ある。
【０２３７】本発明の一実施例においては、ノード設定
サーバー４が、定期的に、ハードウェア・テーブルと、
backupファイル４２（ソフトウェア・テーブル) を読み
出して、読み出したデータを比較することによって、前
記整合性の確認を行うものとする。
【０２３８】１−７−５．複数ソフトウェア・テーブル
間の整合性確認 本発明の一実施例においては、管理ファイル５６とback
upファイル４２、管理ファイル５６とノード管理サーバ
ー５が管理するＮＩＳマップ６２( 以下、ＮＩＳマスタ
ー・マップ６２０と呼ぶ) 、ＮＩＳマスター・マップ６
２０とＮＩＳスレーブ・サーバー６０１が管理するＮＩ
Ｓマップ６２( 以下、ＮＩＳスレーブ・マップ６２1 と
呼ぶ) といったファイル間に整合性が取れていることを
想定している。以下、前記３組のファイル間の整合性に
ついて、順に説明する。
【０２３９】まず、管理ファイル５６とbackupファイル
４２との間のファイル間の整合性について説明する。本
発明の一実施例においては、管理ファイル５６に登録さ
れた情報に基づいて、ノード管理サーバー５が、ＡＴＭ
交換システム内に設定されたコネクション等の管理を行
うことを想定している。それゆえ、管理ファイル５６と
backupファイル４２との間に整合が取れていない場合、
例えば、管理ファイル５６に登録されているコネクショ
ンのうち、ハードウェアの設定が行われていないコネク
ションが存在する場合、ユーザが、管理ファイル５６に
登録されたコネクションを用いてデータ通信を行おうと
しても、前記コネクションに対してハードウェア設定は
行われていないので、前記データ通信を行えない可能性
がある。また、backupファイル４２に登録されているコ
ネクションのうち、管理ファイル５６に登録されていな
いコネクションが存在する場合、ノード管理サーバー５
が知り得ないコネクションが存在することとなり、セキ
ュリティ上で考慮すべき点が生ずる可能性がある。従っ
て、何らかの方法を用いて、管理ファイル５６の内容と
backupファイル４２の内容との間に整合性を取れば良い
わけである。本発明の一実施例においては、定期的に、
管理ファイル５６の情報を基に、ハードウェアの設定情
報を作成し、前記作成したハードウェアの設定情報と、
backupファイル４２の内容を比較することによって、前
記管理ファイル５６とbackupファイル４２の内容の整合
性を取ることを想定している。
【０２４０】次に、管理ファイル５６とＮＩＳマスター
・マップ６２０との間の、ファイル間の整合性について
説明する。
【０２４１】まず、本発明の一実施例においては、ユー
ザは、ＮＩＳを用いて、データ通信を行うためのＶＰＩ
／ＶＣＩ値等を獲得することを想定しているので、ＮＩ
Ｓマスター・マップ６２０に登録されているコネクショ
ンのうち、管理ファイル５６に登録されていないコネク
ションが存在した場合で、前記コネクションを使って、
ユーザがデータ通信を行おうとしても、前記データ通信
を実行できない可能性がある。また、逆に、管理ファイ
ル５６に登録されているコネクションのうち、ＮＩＳマ
スター・マップ６２０に登録されていないコネクション
が存在した場合、ユーザがＮＩＳを使用しても、前記コ
ネクションを使用するためのＶＰＩ／ＶＣＩ値等を獲得
しえないため、ユーザは、前記コネクションを使用する
ことができない。従って、そのような場合、何らかの方
法を用いて、管理ファイル５６とＮＩＳマスター・マッ
プ６２０の内容との間に、整合性を取らば良い。本発明
の一実施例においては、定期的に、管理ファイル５６の
情報を基に、ＮＩＳマスター・マップ６２０を作成し、
前記作成したＮＩＳマスター・マップ６２０の内容と、
既存のＮＩＳマスター・マップ６２０の内容を比較する
ことによって、前記管理ファイル５６とＮＩＳマスター
・マップ６２０の内容の整合性を取ることを想定してい
る。
【０２４２】最後に、ＮＩＳマスター・マップ６２０と
ＮＩＳスレーブ・マップ６２1 との間の、ファイル間の
整合性について説明する。本発明の一実施例において
は、ユーザは、ＮＩＳを用いて、データ通信を行うため
のＶＰＩ／ＶＣＩ値等を獲得することを想定しているの
で、すべてのＮＩＳマップ６２間の整合性が取られてい
なければならない。従って、何らかの方法を用いて、管
理ファイル５６とＮＩＳマスター・マップ６２０の内容
との間に、整合を取らなければならない。本発明の一実
施例においては、定期的に、管理ファイル５６の情報を
基に、ＮＩＳマスター・マップ６２０を作成し、前記作
成したＮＩＳマスター・マップ６２０の内容と、既存の
ＮＩＳマスター・マップ６２０の内容を比較することに
よって、前記管理ファイル５６とＮＩＳマスター・マッ
プ６２０の内容との間に、整合性を取ることを想定して
いる。
【０２４３】１−７−６．統計情報の収集および統計情
報に基づくコネクション制御 本発明の一実施例においては、ノード管理サーバー５
が、ＡＴＭ交換システム内に設定されたコネクション等
に関する情報を収集し、前記情報に基づいて、ＡＴＭ交
換システム内に設定されたコネクション等の管理を行う
ことを想定している。また、ノード管理サーバー５が収
集した統計情報等は、一端、管理ファイル５６に書き込
まれ、前記管理ファイル５６に書き込まれた統計情報等
を用いて、ノード管理サーバー５は、ＡＴＭ交換システ
ム内のコネクション等の制御を行うことを想定してい
る。
【０２４４】まず、本発明の一実施例においては、前記
したように、ハードウェア上のロジックに組み込まれた
回路によって、収集されたＡＴＭ交換システム内に設定
されたコネクションに関する統計情報は、一端、ノード
設定サーバー４によって読み取られ、前記ノード設定サ
ーバー４が管理するbackupファイル４２内に書き込まれ
る。従って、ノード管理サーバー５は、ノード設定サー
バー４を通して、backupファイル４２をアクセスするこ
とによって、前記ノード設定サーバー４が収集したハー
ドウェアの統計情報をアクセスすることができる。ノー
ド管理サーバー５がアクセスしたハードウェアの統計情
報は、ノード管理サーバー５が管理する管理ファイル５
６に収集される。
【０２４５】ノード管理サーバー５は、前記したハード
ウェアの統計情報以外に、ノード管理サーバー５が送信
するＯＡＭセル等によって得られた、統計情報に関して
も収集を行う。すなわち、本発明の一実施例において
は、上記(1-7-1) コネクションの接続確認、および上記
(1-7-2) 端末または各種サーバーの生存確認の項で前記
したように、ノード管理サーバー５は、接続確認用のＯ
ＡＭセル等を送信し、前記ＯＡＭセル等がターゲット・
ポイントでループバックされ、前記ＯＡＭセル等を、再
び前記ノード管理サーバー５が受信することによって、
コネクションの接続確認・端末（または、各種サーバ
ー) の生存確認を行うことを想定している。また、ノー
ド管理サーバー５は、前記ＯＡＭセル等を送信してか
ら、前記ＯＡＭセル等を再び受信するまでの時間を測定
し、前記測定した時間を基に、対象とするコネクション
の輻輳状態、あるいは端末（または、各種サーバー) の
負荷状態に関する統計情報を収集することができる。前
記収集した統計情報は、ノード管理サーバー５によっ
て、前記サーバーが管理する管理ファイル５６に収集さ
れる。
【０２４６】次に、ノード管理サーバー５は、前記管理
ファイル５６に収集された統計情報を基に、ＡＴＭ交換
システム内に設定されたコネクションの制御等を行う。
すなわち、障害等の原因により、ハードウェア・テーブ
ル等の設定が破壊され、コネクションが切断された場
合、管理ファイル５６に収集された統計情報によって前
記不具合を検出し、ノード管理サーバー５が、前記統計
情報を基にハードウェア・テーブル等の設定を修復する
ことによって、前記不具合を解消することができる。ハ
ードウェア・テーブル等の設定を修復するだけでは、前
記不具合を解消することができない場合で、ルーティン
グを変更することによってコネクションのエンド・エン
ド間のデータ通信が実行できる場合、ノード管理サーバ
ー５が、ハードウェア・テーブル等の設定を変更し、前
記コネクションに対するルーティングを変更することに
よって、前記不具合を解消することができる。
【０２４７】また、各種サーバーの負荷状態に関する統
計情報を用いることによって、ノード管理サーバー５
は、負荷の大きいサーバーに対して、前記サーバーのク
ライアントの一部を、負荷の小さいサーバーのクライア
ントに移すことによって、前記サーバーの負荷を軽減す
ることができる。一方、ユーザに対しては、ユーザ側の
プロセスであるクライアント・プロセスが帰属(bind)し
ているサーバーの負荷が大きい場合、前記クライアント
がサーバーに対し要求を送信し、前記サーバーが前記ク
ライアントに対するサービスを行うまでの応答時間が長
くなる可能性がある。本発明の一実施例においては、ノ
ード管理サーバー５が、前記した方法によって、各種サ
ーバーの負荷状態を観測し、負荷の大きなサーバーのク
ライアントの一部を負荷の小さなサーバーに移すことに
よって、サーバーの負荷を軽減し、結果として、サーバ
ーのクライアントに対する応答時間を短縮することがで
きる。
【０２４８】前記した方法は、網がアクションを起こす
ことによって、端末へのサービス応答を改善する方法で
あったが、端末がアクションを起こすことによっても、
前記端末へのサービス応答を改善することができる。以
下、端末がアクションを起こすことによって、端末への
サービス応答を改善する方法について説明する。
【０２４９】端末上のクライアントは、サーバーの応答
が遅くなった場合、まず、前記クライアントが、ノード
管理サーバー５に対し、前記クライアントの帰属(bind)
するサーバーの変更を要求する。ノード管理サーバー５
は、前記要求を受信した場合、管理ファイル５６を参照
し、前記クライアントの帰属(bind)するサーバーを、負
荷の小さなサーバーに変更することによって対応する。
具体的には、ノード管理サーバー５は、対応するハード
ウェア・テーブル等の設定を変更することによって、前
記端末上のクライアントのサーバーに対して送信する要
求が、前記変更後のサーバーにルーティングされるよう
にする。前記方法を採用することによって、端末上のク
ライアントは、サーバーが変更された場合でも、ＶＰＩ
／ＶＣＩ値等を変更せずに、変更後のサーバーに対し要
求を送信することができる。
【０２５０】２．本発明に係るＶＰＩ／ＶＣＩ割り当て
アルゴリズム 以下、ＶＰＩ／ＶＣＩ値の割り当てアルゴリズムについ
て、図面を参照しながら、具体的に説明する。
【０２５１】２−１．ＶＰＩ／ＶＣＩ割り当てアルゴリ
ズムの必要性と従来方法について まず、ＶＰＩ／ＶＣＩ割り当てアルゴリズムの必要性に
ついて簡単に説明する。ＡＴＭにおけるデータ通信の場
合、データ転送路上に多重化された複数のコネクション
は、ＶＰＩまたはＶＰＩ＋ＶＣＩで、個々のコネクショ
ンが識別される。従って、ＡＴＭにおけるデータ通信の
場合、データ転送路上で個々のコネクションが識別でき
るように、ＶＰＩまたはＶＰＩ＋ＶＣＩを、個々のコネ
クションに割り当てなければならない。ここに、以下、
ＶＰＩまたはＶＰＩ＋ＶＣＩを、対応するコネクション
に割り当てることを、単に、ＶＰＩ／ＶＣＩの割り当て
と呼こととする。
【０２５２】ＡＴＭにおけるデータ通信の場合、一般的
には、ＶＰＩ／ＶＣＩの割り当ては、以下に示すよう
に、呼設定時に網によって行われる。すなわち、データ
送信端末は、データ通信開始時に、網に対して、データ
送信端末からデータ受信端末までのコネクションの設定
（呼設定) を要求する。従来技術の節でも説明したよう
に、網は、呼設定要求を受信した場合、データ送信端末
が申告したトラヒック・パラメータを基に、データ送信
端末からデータ受信端末までの、該データ送信端末が要
求したＱＯＳを満たすコネクションが設定できるかどう
か判定する。該コネクションが設定できる場合、網は、
該コネクションを設定するとともに、該データ送信端末
が該コネクションを使用するためのＶＰＩ／ＶＣＩ値
を、該コネクションが多重化されるデータ転送路上の他
のコネクションのＶＰＩ／ＶＣＩ値に重ならないよう
に、該コネクションに割り当てを行う。最後に、網は、
前記呼設定要求を送信したデータ送信端末に呼設定の終
了を伝えるとともに、該コネクションに割り当てたＶＰ
Ｉ／ＶＣＩ値等の通知を行う。
【０２５３】本発明の一実施例においては、ＶＰＩ／Ｖ
ＣＩの割り当ては、前記した呼設定時以外にも、以下に
示す２つの場合にも網によって行われる。すなわち、本
発明の一実施例においては、網の立ち上げ時に、網によ
って、メタシグナリング・コネクション以外にも、予め
記述された設定ファイル（configファイル５５）の内容
に従って、予め指定されたコネクションが設定される
が、前記コネクションの設定時にも、必要に応じてＶＰ
Ｉ／ＶＣＩの割り当てが行われる。同様に、本発明の一
実施例においては、端末の立ち上げ時に、網によって、
シグナリング・コネクション以外にも、予め記述された
設定ファイル（configファイル５５）の内容に従って、
予め指定されたコネクションが設定されるが、前記コネ
クションの設定時にも、必要に応じてＶＰＩ／ＶＣＩの
割り当てが行われる。
【０２５４】ここで、従来のＡＴＭにおいては、ＶＰＩ
／ＶＣＩの割り当ては、網が呼設定要求を受信した際
に、網が、データ送信端末からデータ受信端末までコネ
クションを設定し、該設定したコネクションにＶＰＩ／
ＶＣＩ値を対応させる場合に、ＶＰＩ／ＶＣＩ割り当て
アルゴリズムが実行される。
【０２５５】ＩＴＵ−ＴＳ（旧ＣＣＩＴＴ）によるＡＴ
Ｍの標準化において、前記設定したコネクションに、Ｖ
ＰＩ／ＶＣＩ値を対応する方法として、コネクションを
設定する度に、ＶＰＩ／ＶＣＩ値の番号の若い方から順
にＶＰＩ／ＶＣＩ値を割り当てていくという方法が標準
化の方法として勧告されている。従って、前記標準化さ
れた方法に従った場合、コネクションを設定するごと
に、ＶＰＩ／ＶＣＩ値の小さい方から順に、割り当てら
れるＶＰＩ／ＶＣＩ値の最大の数までＶＰＩ／ＶＣＩ値
を割り当てていく。割り当てられるＶＰＩ／ＶＣＩ値の
最大の数までＶＰＩ／ＶＣＩ値を割り当ててしまった場
合で、次にＶＰＩ／ＶＣＩ値を割り当てる場合は、最初
に戻って、ＶＰＩ／ＶＣＩ値の小さい方から順に、使い
終わったＶＰＩ／ＶＣＩ値がないかどうか検索し、使い
終わったＶＰＩ／ＶＣＩ値がみつかった場合、該検索し
たＶＰＩ／ＶＣＩ値を小さい方から順に、コネクション
に割り当てていくことになる。
【０２５６】前記ＶＰＩ／ＶＣＩ値の割り当て手順にお
いて、ある時点で、あるＶＰＩ／ＶＣＩ値（ｎとする)
まで割り当てた場合で、前記ＶＰＩ／ＶＣＩ値の割り当
て終了後、ｎよりも小さいＶＰＩ／ＶＣＩ値（ｍとす
る) が割り当てられたコネクションの使用が終了した場
合、次の時点で、設定したコネクションにＶＰＩ／ＶＣ
Ｉ値を割り当てる方法として、ｍを割り当てる方法と、
ｎ＋１を割り当てる方法の２通りの方法が考えられる。
【０２５７】しかし、ｍを割り当てる方法には、次のよ
うな短所がある。すなわち、一般に、データ通信には、
データ通信し終わった端末に対し、再びデータ通信を行
う確率が高いという特徴が存在するので、前記した例に
おいて、ある時点で、データ通信が終了したｍというＶ
ＰＩ／ＶＣＩ値を持つコネクションは、近い将来、再び
設定要求される確率が高いということになる。それゆ
え、このｍを割り当てる方法を採用した場合、次の時点
で設定されたコネクションに対し、ｍというＶＰＩ／Ｖ
ＣＩ値が割り当てられるので、次の時点で、他のデータ
送信端末とデータ受信端末との間のコネクションが設定
された場合、該コネクションにｍというＶＰＩ／ＶＣＩ
値が割り当てられてしまい、同一のデータ送信端末とデ
ータ受信端末との間のコネクションが再び設定される場
合でも、該コネクションにｍという同一のＶＰＩ／ＶＣ
Ｉ値が割り当てられない場合があることになる。従っ
て、前記した場合、同一のデータ送信端末とデータ受信
端末との間のコネクションが、再び設定される場合で
も、ＶＰＩ／ＶＣＩ割り当てアルゴリズムを再実行しな
ければならず、効率が悪い。
【０２５８】一方、ＶＰＩ／ＶＣＩ値としてｎ＋１を割
り当てる方法を採用した場合、ｍというＶＰＩ／ＶＣＩ
値を持つコネクションが解放されても、次の時点で設定
されるコネクションには、ｎ＋１というＶＰＩ／ＶＣＩ
値が割り当てられるので、ｍというＶＰＩ／ＶＣＩ値が
割り当てられていたコネクションに対し、近い将来、再
び呼設定要求を網が受信した場合でも、ｍというＶＰＩ
／ＶＣＩ値を割り当てることができる。
【０２５９】以下、本発明の一実施例においては、ＶＰ
Ｉ／ＶＣＩ値の割り当て方法として、このｎ＋１を割り
当てる方法を採用したものについて、図面を参照しなが
ら具体的に説明する。
【０２６０】図１８（ａ）は、本発明の一実施例におけ
るＶＰＩ／ＶＣＩの割り当て方法を行う場合の、ハード
構成の一例を図示したものであり、図１８（ｂ）は、図
１８（ａ）における管理プロセス５１のＶＰＩ／ＶＣＩ
値割当機能に関する要部構成を示したものである。（本
発明の一実施例においては、ＶＰＩ／ＶＣＩ割り当て処
理をノード管理サーバー５で行うとしているが、呼設定
サーバー７で行っても良い。）本発明の一実施例におい
ては、呼設定サーバー７とノード管理サーバー５との間
は呼設定用チャネル１８で接続されており、ノード管理
サーバー５は、呼設定用チャネル１８を通して、呼設定
サーバー７からコネクション設定要求を受信するものと
する。ノード管理サーバー５上の管理プロセス５１内に
設けられた受信部５１１がコネクション設定要求を受信
した場合、同ＶＰＩ／ＶＣＩ割当処理部５１２は、必要
に応じて管理ファイル５６を参照し、設定を要求された
コネクションに対し、ＶＰＩ／ＶＣＩ値を割り当て、こ
の割り当て結果を同送信部５１３によって呼設定サーバ
ー７に送るものとする。また、該管理ファイル５６は複
数のファイルから構成されるが、ＶＰＩ／ＶＣＩ値を割
り当てるために用いるファイルとして、割り当てること
のできるＶＰＩ／ＶＣＩ値等をリストしたファイルをVP
I/VCI-リスト・ファイル（以下、VPI/VCI-listファイル
と記す）５６１とし、現時点から過去にさかのぼって、
一番最後に割り当てられたＶＰＩ／ＶＣＩ値等を一時的
に記憶するためのファイルをVPI/VCI-ポインタ・ファイ
ル（以下、VPI/VCI-pointer ファイルと記す）５６２と
する。従って、ノード管理サーバー５上の管理プロセス
５１は、コネクション設定要求を受信した場合、まず、
VPI/VCI-pointer ファイル５６２を参照し、一番最近に
割り当てたＶＰＩ／ＶＣＩ値（または、VPI/VCI-listフ
ァイル５６１に記述されたＶＰＩ／ＶＣＩリストの番
号) を入手する。次に、該管理プロセス５１は、VPI/VC
I-listファイル５６１を参照し、該一番最近に割り当て
たＶＰＩ／ＶＣＩ値等を基準として、ファイルの後方へ
（ファイルの最後まで検索し終わった場合は、ファイル
の先頭に戻って、該ＶＰＩ／ＶＣＩ値等のリストまで)
、順々にＶＰＩ／ＶＣＩ値等のリストを検索し、割り
当てることのできるＶＰＩ／ＶＣＩ値等を検索する。
【０２６１】本発明の一実施例においては、VPI/VCI-li
stファイル５６１中の、最後に設定されたＶＰＩ／ＶＣ
Ｉ値のリストを示すポインタとして、VPI/VCI-pointer
ファイル５６２の使用を仮定しているが、必ずしもファ
イルを使用する必要はなく、リストを示すことのできる
ポインタであればよい。
【０２６２】また、前記説明において、割り当てること
のできるＶＰＩ／ＶＣＩ値とは、ＡＴＭ交換機の立ち上
げ後、まだ一度もコネクションに割り当てられていない
ＶＰＩ／ＶＣＩ値、またはコネクションの接続が終了
し、該コネクションに割り当てられていたＶＰＩ／ＶＣ
Ｉ値が、他のコネクションに割り当てることができるよ
うになったＶＰＩ／ＶＣＩ値のことを意味するとする。
新たにコネクションが設定され、該コネクションにＶＰ
Ｉ／ＶＣＩ値を割り当てる必要が生じた場合、網は、管
理しているＶＰＩ／ＶＣＩ値のうち、現在、他のコネク
ションに割り当てられているＶＰＩ／ＶＣＩ値と、どの
コネクションにも割り当てられていないＶＰＩ／ＶＣＩ
値とを区別し、現在、どのコネクションにも割り当てら
れていないＶＰＩ／ＶＣＩ値の中から、適当なＶＰＩ／
ＶＣＩ値を選択して、該選択したＶＰＩ／ＶＣＩ値を、
該コネクションに割り当てなければならない。網が、現
在、設定しているコネクションに割り当てているＶＰＩ
／ＶＣＩ値と、どのコネクションにも割り当てていない
ＶＰＩ／ＶＣＩ値を区別する方法として、以下に示す２
通りの方法が存在する。
【０２６３】１つ目の方法は、前記ＶＰＩ／ＶＣＩ値の
リスト中に、有効ビットというビットを設け、ノード管
理サーバー５が、該有効ビットを制御することによっ
て、該ＶＰＩ／ＶＣＩ値が割り当てられているか否かを
区別する方法である。すなわち、ノード管理サーバー５
が、設定するコネクションにＶＰＩ／ＶＣＩ値を割り当
てた時点で、VPI/VCI-listファイル５６１の対応するＶ
ＰＩ／ＶＣＩ値リストの有効ビットをセットし、該コネ
クションの接続が終了した時点で、ノード管理サーバー
５は、該VPI/VCI-listファイル５６１の対応するＶＰＩ
／ＶＣＩ値リストの有効ビットをリセットすることによ
って、該ＶＰＩ／ＶＣＩ値が、コネクションに割り当て
られているか否かを識別する方法である。ノード管理サ
ーバー５は、設定するコネクションに新たにＶＰＩ／Ｖ
ＣＩ値を割り当てる必要が生じた場合、該ノード管理サ
ーバー５は、VPI/VCI-listファイル５６１を参照し、有
効ビットがセットされていないＶＰＩ／ＶＣＩ値リスト
を検索し、検索したＶＰＩ／ＶＣＩ値のうち適当なＶＰ
Ｉ／ＶＣＩ値を選択し、該新たに設定するコネクション
に割り当てを実行する。ただし、この方法によると、ノ
ード管理サーバー５は、コネクションの接続が終了した
時点で、該コネクションに割り当てられたＶＰＩ／ＶＣ
Ｉ値の解放を行わなければならず、何らかの原因でコネ
クションの接続が終了していたのに、該コネクションに
割り当てられたＶＰＩ／ＶＣＩ値の解放を行わなかった
場合、該ＶＰＩ／ＶＣＩ値は、以後使用することができ
なくなる可能性がある。
【０２６４】一方、２つ目の方法は、前記ＶＰＩ／ＶＣ
Ｉ値のリスト中にライフタイムというフィールドを設
け、ノード管理サーバー５は、該ライフタイムに記述さ
れた生存時間を基に、対応するＶＰＩ／ＶＣＩ値が、コ
ネクションに割り当てられているか否かを判定する方法
である。この方法では、上記のような可能性は生じな
い。なぜなら、ＶＰＩ／ＶＣＩ値のコネクションへの割
り当て期間はライフタイムによって管理されるため、何
らかの原因でコネクションの接続が終了しているのに、
該コネクションに割り当てられたＶＰＩ／ＶＣＩ値の解
放が永遠に行われないといったことがないからである。
ただし、この方法は、コネクションの設定時に、該コネ
クションが使用される期間を予測して、該使用期間をラ
イフタイムに設定するのであるが、ユーザが、前記ライ
フタイムに設定された期間を越えて、継続して前記コネ
クションを使用したくなった場合でも、該ライフタイム
に設定された期間を越えて、該コネクションに割り当て
られたＶＰＩ／ＶＣＩ値を使用できない可能性がある。
しかし、このことは、ユーザが、ライフタイムに設定さ
れた期間を越えて、コネクションを使用したい場合、ノ
ード管理サーバー５が、VPI/VCI-listファイル５６１の
対応するＶＰＩ／ＶＣＩ値リストのライフタイムを、書
き換えることによって、回避することができる。また、
２つ目の方法に対し、該ＶＰＩ／ＶＣＩ値リストのライ
フタイムに設定された期間が終了する前に、該ＶＰＩ／
ＶＣＩ値に対応するコネクションの接続が終了した場
合、ノード管理サーバー５は、前記ＶＰＩ／ＶＣＩ値リ
ストのライフタイムに設定されている期間を書き換える
ことによって、該ＶＰＩ／ＶＣＩ値のコネクションへの
割り当て期間を、強制的に終了させることができる。
【０２６５】以下、本発明の一実施例においては、２つ
目の方法、すなわち、ＶＰＩ／ＶＣＩ値リストに設けら
れたライフタイムによって、該ＶＰＩ／ＶＣＩ値が、コ
ネクションに割り当てられているか否かを、ノード管理
サーバー５が識別する方法について、具体的に説明す
る。
【０２６６】前記ライフタイムによって、対応するＶＰ
Ｉ／ＶＣＩ値が使用されているか否かを識別する方法に
は、ライフタイムとして、割り当ての継続時間を用いる
方法と、割り当ての終了時刻を用いる方法の２通りの方
法が存在し、以下、前記２通りの方法について、簡単に
説明する。
【０２６７】１番目の方法は、ライフタイムとして、該
ＶＰＩ／ＶＣＩ値のコネクションへの割り当ての継続時
間を用いる方法である。例えば、継続時間の単位とし
て、秒を採用した場合、コネクションの設定時に、ノー
ド管理サーバー５は、VPI/VCI-listファイル５６１中の
対応するＶＰＩ／ＶＣＩ値リスト中のライフタイムに、
指定された継続時間（例えば、６０秒間) を設定する。
VPI/VCI-listファイル５６１中の、ライフタイムの項目
に、“０”以外の数字が設定されている場合、該ライフ
タイムに設定されている数値が“０”になるまで、１秒
毎に、デクリメントされる。ノード管理サーバー５は、
新たにＶＰＩ／ＶＣＩ値をコネクションに割り当てる必
要が生じた場合、VPI/VCI-listファイル５６１を参照し
て、ＶＰＩ／ＶＣＩ値リストのライフタイムが“０”の
ＶＰＩ／ＶＣＩ値を検索することによって、ある特定の
時点で、コネクションに割り当てられていないＶＰＩ／
ＶＣＩ値を検索することができる。
【０２６８】２番目の方法は、ライフタイムとして、該
ＶＰＩ／ＶＣＩ値のコネクションへの割り当ての終了時
刻（あるいは、開始時刻および終了時刻、または開始時
刻）を用いる方法である。例えば、現時刻が１９９３年
６月２日１７時３０分００秒として、あるＶＰＩ／ＶＣ
Ｉ値をコネクションに１分間割り当てたい場合、VPI/VC
I-listファイル５６１の対応するＶＰＩ／ＶＣＩ値リス
トのライフタイムに、１９９３年６月２日１７時３１分
００秒を設定すればよい。ライフタイムの設定方法とし
て、ある時刻（例えば、１９９０年１月１日００時００
分００秒) を基準として、前記ある時刻からの経過時間
を、現在の時刻として、ライフタイムの終了時刻を設定
してもよい。ノード管理サーバー５は、新たにＶＰＩ／
ＶＣＩ値をコネクションに割り当てる必要が生じた場
合、図１８（ａ）で示される時計とVPI/VCI-listファイ
ル５６１を参照して、ＶＰＩ／ＶＣＩ値リストのライフ
タイムによって示される時刻が、時計によって示される
現時刻より前のＶＰＩ／ＶＣＩ値を検索することによっ
て、現時点で、コネクションに割り当てられていないＶ
ＰＩ／ＶＣＩ値を、検索することができる。また、ＰＶ
Ｃ（permanent virtual connection）の場合のような、
固定的にコネクションを設定する場合に対しては、該コ
ネクションに割り当てるＶＰＩ／ＶＣＩ値リストのライ
フタイムに、ライフタイムとして設定できる最大値を、
該ライフタイムに設定することで、該ＶＰＩ／ＶＣＩ値
を、他のコネクションに割り当てられないようにするこ
とができる。
【０２６９】以下、本発明の一実施例においては、ライ
フタイムとして、前記２番目の方法の、ＶＰＩ／ＶＣＩ
値のコネクションへの割り当ての終了時刻を用いる方法
を採用するとして、２つのＶＰＩ／ＶＣＩ割り当て方法
について、具体的に説明する。
【０２７０】２−２．ＶＰＩ／ＶＣＩ割り当てアルゴリ
ズムについて( 方法Ａ) 以下、本発明の一実施例におけるＶＰＩ／ＶＣＩ割り当
て方法について、呼設定時を例として、具体的に説明す
る。なお、網の立ち上げ時と端末の起動時のＶＰＩ／Ｖ
ＣＩ割り当ても、呼設定時のＶＰＩ／ＶＣＩの割り当て
方法と同様である。
【０２７１】図１９は、方法Ａにおける、VPI/VCI-list
ファイル５６１とVPI/VCI-pointerファイル５６２の構
成を示した構成例であり、図２０および図２１は、方法
ＡにおけるＶＰＩ／ＶＣＩ割り当てアルゴリズムの一例
を示したものである。図１９において、VPI/VCI-listフ
ァイル５６１とは、少なくとも番号(No)、ＶＰＩ／ＶＣ
Ｉ値（ＶＰＩ／ＶＣＩ) 、およびライフタイム（LIFE）
からなる複数のユーザーリスト（user-list ）から構成
され、VPI/VCI-pointer ファイル５６２とは、少なくと
も前記VPI/VCI-listファイル５６１中の特定のユーザー
リストの番号(No)を示すユーザーポインタ(user-pointe
r)から構成されるものとする。ここに、VPI/VCI-listフ
ァイル５６１、VPI/VCI-pointer ファイル５６２とし
て、番号(No)を用いずに、VPI/VCI-pointer ファイル５
６２として、VPI/VCI-listファイル５６１の先頭からの
オフセットを用いることで、方法Ａの、ＶＰＩ／ＶＣＩ
割り当てアルゴリズムを実行することができるが、本発
明の一実施例においては、記述をわかりやすくするた
め、前記したVPI/VCI-listファイル５６１、VPI/VCI-po
inter ファイル５６２の構成を用いた。また、本発明の
一実施例においては、VPI/VCI-pointer ファイル５６２
として、現時点から過去にさかのぼって、一番最近に設
定されたＶＰＩ／ＶＣＩ値のポインタを含むとしている
が、該一番最近に設定されたＶＰＩ／ＶＣＩ値のポイン
タの代わりに、該ＶＰＩ／ＶＣＩ値の次のＶＰＩ／ＶＣ
Ｉ値のポインタを含むとしてもよい。
【０２７２】方法Ａにおいて、ノード管理サーバー５
が、呼設定サーバー７からコネクション設定要求を受信
した場合（図２０のステップ１２０）、該ノード管理サ
ーバー５は、該コネクションが以前に設定されたことが
あるかどうか、VPI/VCI-listファイル５６１を参照する
（ステップ１２１）。該コネクションが以前に設定され
たことがある場合、ノード管理サーバー５は、該以前設
定されたコネクションに対し割り当てたＶＰＩ／ＶＣＩ
値が、現時点で、他のコネクションに割り当てられてい
ないかどうか、VPI/VCI-listファイル５６１を参照する
（ステップ１２２）。該ＶＰＩ／ＶＣＩ値が、現時点
で、他のコネクションに割り当てられていない場合、ノ
ード管理サーバー５は、該ＶＰＩ／ＶＣＩ値を用いて、
ユーザーが申告したトラヒック・パラメータで、ユーザ
が要求したＱＯＳを満たすコネクションが設定できるか
どうか、コネクション設定処理を実行する（ステップ１
２３）。
【０２７３】一方、該コネクションが以前に設定された
ことがない場合、または該ＶＰＩ／ＶＣＩ値が、現時点
で、他のコネクションに割り当てられている場合、以下
に示すＶＰＩ／ＶＣＩ割り当て処理を開始する（ステッ
プ１２４）。まず、ノード管理サーバー５は、VPI/VCI-
pointer ファイル５６２を参照し、現時点から過去にさ
かのぼって、一番最近に設定されたＶＰＩ／ＶＣＩ値へ
のポインタ（番号（Ｎｏ））を獲得する。この獲得した
番号を、［ＰｏｉｎｔＮｏ］とする（ステップ１２
６）。次に、ノード管理サーバー５は、獲得した番号
［ＰｏｉｎｔＮｏ］を基に、VPI/VCI-listファイル５６
１を参照し、コネクションに割り当てることのできるＶ
ＰＩ／ＶＣＩ値を検索する（ステップ１３３）。すなわ
ち、ノード管理サーバー５は、VPI/VCI-listファイル５
６１に記述されたユーザーリストのうち、［Ｐｏｉｎｔ
Ｎｏ］で示される番号の次の番号のユーザーリストか
ら、順々に、ユーザーリストを参照し、ユーザーリスト
のライフタイムに書かれた割り当て終了時刻と、ノード
管理サーバー５が参照した時計の現時刻とを比較し、前
記現時刻より前記終了時刻の方が前のユーザリストを検
索する。
【０２７４】参照したユーザーリストのライフタイムの
終了時刻が、現時刻よりも前の場合、ノード管理サーバ
ー５は、参照したユーザーリストに書かれたＶＰＩ／Ｖ
ＣＩ値を用いて、ユーザーが申告したトラヒック・パラ
メータで、ユーザが要求したＱＯＳを満たすコネクショ
ンが設定できるかどうか、コネクション設定処理を実行
する（図２１のステップ１３４）。また、次回、ＶＰＩ
／ＶＣＩ割り当て処理を行うために、VPI/VCI-pointer
ファイル５６２を更新する（ステップ１３５）。
【０２７５】また、参照したユーザーリストのライフタ
イムの終了時刻が、現時刻よりも前でない場合、ノード
管理サーバー５は、次のユーザーリストを参照する（ス
テップ１２７，１２８，１３０，１３３）。現時点で参
照したユーザーリストが、VPI/VCI-listファイル５６１
の最後のユーザーリストの場合、ノード管理サーバー５
は、VPI/VCI-listファイル５６１の最初のユーザーリス
トを参照する（ステップ１２７，１２８，１２９，１３
０，１３３）。また、ノード管理サーバー５が、VPI/VC
I-listファイル５６１に含まれたユーザーリストを、一
通り参照した結果、割り当てるＶＰＩ／ＶＣＩ値が検索
できなかった場合（ステップ１３０，１３１）、ノード
管理サーバー５は、呼設定サーバー７にコネクションが
設定できない等の通知を行う（ステップ１３２）。
【０２７６】２−３．ＶＰＩ／ＶＣＩ割り当てアルゴリ
ズムについて（方法Ｂ） 以下、本発明の一実施例におけるＶＰＩ／ＶＣＩ割り当
て方法として、ＶＰＩ／ＶＣＩ値リストの管理方法とし
て、リンクド・リストを用いた方法について、具体的に
説明する。なお、ＶＰＩ／ＶＣＩ割り当て方法のうち、
方法Ａと同様の部分については、説明を省略する。
【０２７７】図２２は、方法ＢにおけるVPI/VCI-listフ
ァイル５６１の構成例であり、図２３は、VPI/VCI-poin
ter ファイル５６２の構成例であり、また、図２４，２
５は、方法ＢにおけるＶＰＩ／ＶＣＩ割り当てアルゴリ
ズムの一例を示したものである。図２２において、VPI/
VCI-listファイル５６１とは、少なくとも番号（Ｎ
ｏ）、次の番号（Ｎｅｘｔ）、ＶＰＩ／ＶＣＩ値（ＶＰ
Ｉ／ＶＣＩ) 、およびライフタイム（LIFE）からなる複
数のユーザーリスト（user-list ）から構成されたユー
ザー毎に存在するユーザー・リンクドリスト（user-lin
ked-list）と、現時点でコネクションに割り当てられて
いないＶＰＩ／ＶＣＩ値のリストであるフリーリスト
（free-list ）から構成されたフリー・リンクドリスト
（free-linked-list）とを有しているものとする。ま
た、図２３において、VPI/VCI-pointer ファイル５６２
とは、ユーザー毎に存在し、少なくとも前記VPI/VCI-li
stファイル５６１中の最後に割り当てられたユーザーリ
ストの番号（Ｎｏ）を示すユーザーポインタ（user-poi
nter）と、フリーリストの先頭を示すフリーポインタ
（free-pointer）とから構成されるものとする。なお、
本発明の一実施例においては、VPI/VCI-pointer ファイ
ル５６２として、現時点から過去にさかのぼって、一番
最近に設定されたＶＰＩ／ＶＣＩ値の番号（Ｎｏ）を含
むとしているが、該一番最近に設定されたＶＰＩ／ＶＣ
Ｉ値の番号（Ｎｏ）の代わりに、該ＶＰＩ／ＶＣＩ値の
次のＶＰＩ／ＶＣＩ値の番号（Ｎｏ）を含むとしてもよ
い。
【０２７８】以下、方法Ｂにおける、ＶＰＩ／ＶＣＩ割
り当てアルゴリズムについて、方法Ａと異なる部分につ
いてのみ、図２４，２５を参照しながら、具体的に説明
する。
【０２７９】呼設定サーバー７から設定を要求されたコ
ネクションが、以前に設定したことがない場合（図２４
のステップ１１３１）、または以前に設定したコネクシ
ョンに使用したＶＰＩ／ＶＣＩ値が、現時点で他のコネ
クションに割り当てられている場合（ステップ１１３
２）、ノード管理サーバー５は、以下に示すＶＰＩ／Ｖ
ＣＩ割り当て処理を開始する。
【０２８０】まず、ノード管理サーバー５は、VPI/VCI-
pointer ファイル５６２を参照し、フリー・リンクドリ
ストに含まれるフリーリストの個数を参照し、フリーリ
ストの個数が“０”かどうか調べる（ステップ１１３
５）。フリー・リンクドリストに含まれるフリーリスト
の個数が、“０”個でない場合、フリー・リンクドリス
トの先頭のフリーリストに書かれているＶＰＩ／ＶＣＩ
値を、該設定要求されたコネクションに割り当てを行う
（ステップ１１３８）。具体的には、VPI/VCI-pointer
ファイル５６２のフリーポインタに書かれたＶＰＩ／Ｖ
ＣＩ値を、該設定要求されたコネクションに割り当てる
として、ユーザーが申告するトラヒック・パラメータ
で、ユーザが要求するＱＯＳを満たすコネクションが設
定できるかどうか、コネクション設定処理を実行する。
【０２８１】また、次回、ＶＰＩ／ＶＣＩ割り当て処理
を行うために、VPI/VCI-listファイル５６１と、VPI/VC
I-pointer ファイル５６２の更新を行う（ステップ１１
４０，１４１）。すなわち、まず、VPI/VCI-listファイ
ル５６１中に存在するユーザー・リンクドリストの更新
を行うため、ユーザー・リンクドリストの最後に、該選
択したフリーリストを加える。具体的には、ユーザー・
ポインタで示されるＶＰＩ／ＶＣＩリストの［Ｎｅｘ
ｔ］値を、該選択したフリーポインタで示されるＶＰＩ
／ＶＣＩリストの［Ｎｅｘｔ］にコピーし、該選択した
フリーポインタで示されるＶＰＩ／ＶＣＩリストの［Ｎ
ｏ］値を、ユーザーポインタで示されるＶＰＩ／ＶＣＩ
リストの［Ｎｅｘｔ］にコピーする。次に、VPI/VCI-po
inter ファイル５６２中に存在するユーザーポインタの
更新を行うため、フリーポインタを該ユーザーポインタ
にコピーする。具体的には、フリーポインタに書かれて
いる［Ｎｏ］値を、ユーザーポインタの［Ｎｏ］にコピ
ーし、ユーザーポインタに書かれている［ｔｏｔａｌ］
値に１を加える。
【０２８２】最後に、VPI/VCI-pointer ファイル５６２
中に存在するフリー・ポインタの更新を行うため、フリ
ー・リンクドリストの先頭から２番目のフリーリストの
内容を、フリーポインタにコピーする（ステップ１１４
２）。具体的には、フリーポインタの [No] で示され
る、ＶＰＩ／ＶＣＩリストを参照し、次に、該ＶＰＩ／
ＶＣＩリストに書かれている［Ｎｅｘｔ］番目のＶＰＩ
／ＶＣＩリストを参照する。該ＶＰＩ／ＶＣＩリストに
書かれている［Ｎｏ］値と［ＶＰＩ／ＶＣＩ］値を、フ
リーポインタの［Ｎｏ］と［ＶＰＩ／ＶＣＩ］にコピー
する。
【０２８３】一方、フリー・リンクドリストに含まれる
フリーリストの個数が、“０”個の場合、該設定要求さ
れたコネクションに、割り当てるＶＰＩ／ＶＣＩ値が検
索できなかったので、ノード管理サーバー５は、呼設定
サーバー７にコネクションが設定できない等の通知を行
う（図２４のステップ１１３６，１１３７）。
【０２８４】方法ＢによるＶＰＩ／ＶＣＩ割り当て方法
を採用した場合、ノード管理サーバー５は、何らかの方
法を用いて、他のコネクションに割り当てることのでき
るＶＰＩ／ＶＣＩ値を獲得しなければならない。以下、
前記他のコネクションに割り当てることのできるＶＰＩ
／ＶＣＩリスト（フリーリスト) を獲得する方法につい
て、図２６を参照しながら、具体的に説明する。
【０２８５】ノード管理サーバー５は、定期的に、VPI/
VCI-listファイル５６１を参照し、ユーザー・リンクド
リストをたどって、該ユーザー・リンクドリストに含ま
れるＶＰＩ／ＶＣＩリスト（ユーザーリスト) を参照す
る（図２６のステップ１５４）。該参照したＶＰＩ／Ｖ
ＣＩリスト（ユーザーリスト) のライフタイムを参照
し、定められた時間が経過したＶＰＩ／ＶＣＩリスト
（ユーザーリスト) を検索することによって、他のコネ
クションに割り当てることのできるＶＰＩ／ＶＣＩリス
ト（フリーリスト) を獲得することができる。前記した
方法等によって、他のコネクションに割り当てることの
できるＶＰＩ／ＶＣＩリストを獲得した場合（ステップ
１５５）、ノード管理サーバー５は、該獲得したＶＰＩ
／ＶＣＩリスト （ユーザーリスト) を、フリーリスト
に加えるため、VPI/VCI-listファイル５６１とVPI/VCI-
pointer ファイル５６２の変更を行う（ステップ１５
６）。
【０２８６】３．サブネット内に複数のノードが存在す
る場合について 前述した（１) 節（本発明に係るネットワーク・システ
ムの構成）の説明においては、サブネット( サブネット
ワーク) が、１つの（スイッチ) ノードから構成される
場合について、本発明のネットワーク・システムについ
て説明した。
【０２８７】ここでは、サブネット内に複数の（スイッ
チ) ノードが存在する場合における、本発明のネットワ
ーク・システムのうち、特に、サブネットが１つのノー
ドから構成される場合からの変更部分について、具体的
に説明する。また、上記（１) 節では、本発明のネット
ワーク・サーバーのうち、呼設定サーバーとネームサー
バーは、サブネット内にそれぞれ１つずつ存在するとい
うモデルで説明した。ここでは、前記呼設定サーバーと
ネームサーバーが、サブネット内にそれぞれ複数存在す
る場合、およびそれらが存在しない場合、すなわちサブ
ネット内に４種類のサーバーのうちノード管理サーバー
とノード設定サーバーしか存在しない場合について、具
体的に説明する。なお、本発明のネットワーク・サーバ
ーのうち、サブネット間のデータ通信に適用したものつ
いては、次の（４) 節で説明する。
【０２８８】以下、サブネット内に、ノードが複数存在
する場合における、本発明のネットワーク・サーバーに
ついて、以下の項目について具体的に説明する。 （3-1 ）サブネット内に複数のノード管理サーバーが存
在する場合について （3-2 ）サブネット内に複数のＮＩＳサーバーが存在す
る場合について （3-3 ）サブネット内に複数の呼設定サーバーが存在す
る場合について ３−１．サブネット内に複数のノード管理サーバーが存
在する場合について 先の（１) 節においては、サブネット内に存在する唯一
のノード管理サーバーによって、サブネットに属する端
末等の管理等を行うというモデルで、本発明のネットワ
ーク・サーバーについて説明した。また、上記（１) 節
においては、１つの（スイッチ) ノードに対して、１組
のノード管理サーバーとノード設定サーバーを対応させ
るというモデルを用いて、本発明で提案するネットワー
ク・サーバーについて説明した。一方、サブネット内に
複数の（スイッチ) ノードが存在する場合、前記したモ
デルを採用すると、１つのノードに対して１つのノード
管理サーバーが必要であるので、前記した場合、サブネ
ット内に複数のノード管理サーバーが存在することとな
る。従って、上記（１) 節で説明した本発明のノード管
理サーバーを、サブネット内に複数のノード管理サーバ
ーが存在する場合にも適用するため、以下に述べる変更
を加えるものとする。
【０２８９】本発明のネットワーク・サーバーにおいて
は、サブネットが複数のノードから構成される場合に適
用するため、ノード管理サーバーの動作モードとして、
少なくとも、マスターモード（masterMode）とスレーブ
モード（slaveMode ）の２種類の動作モードを想定す
る。従って、本発明のネットワーク・サーバーにおいて
は、サブネット内に、唯一存在するマスターモードのノ
ード管理サーバーが、サブネットに属する端末等のすべ
てのネットワーク資源を管理し、その他のノード管理サ
ーバーは、スレーブモードとして動作するものとし、前
記マスターモードのノード管理サーバーの命令に従って
動作するものとする。
【０２９０】また、ノード管理サーバーの動作モードと
して、マスターモードとスレーブモードの２種類の動作
モードしか存在しない場合、以下に示すようなことが生
じる可能性がある。一つは、ネットワークの立ち上げ時
のような場合、サブネット内にスレーブモードのノード
管理サーバーが複数存在していても、マスターモードの
ノード管理サーバーが立ち上がるまで、サブネットに属
する端末に対してサービスすることはできない可能性が
あることである。他の一つは、ネットワークの通常運用
中に、マスターモードのノード管理サーバーがダウンし
た場合、サブネット内にスレーブモードのノード管理サ
ーバーが複数存在していても、前記マスターモードのノ
ード管理サーバーが、行っていたネットワーク・サービ
スが停止してしまう可能性があることである。本発明の
ノード管理サーバーにおいては、ノード管理サーバーの
動作モードとして、マスターモードとスレーブモードの
他に、シングルモード(singleMode)を設けることによっ
て、上記二つの可能性を回避するものである。すなわ
ち、ネットワークの立ち上げ時、各々の（スイッチ)ノ
ードに対し１つずつ存在するノード管理サーバーは、サ
ブネット内に唯一存在するマスターモードのノード管理
サーバーの起動を認識するまで、シングルモードのノー
ド管理サーバーとして動作することによって、該ノード
管理サーバーが対応するノードに接続している端末に対
して、該ノード管理サーバーがネットワークのサービス
を提供することとする。また、ネットワークの通常運用
時に、マスターモードのノード管理サーバーのダウンを
検出したスレーブモードのノード管理サーバーは、シン
グルモードのノード管理サーバーへ状態遷移することに
よって、該ノード管理サーバーが対応するノードに接続
している端末に対して、該ノード管理サーバーが、ネッ
トワークのサービスを提供することとする。
【０２９１】以下、図２７を参照しながら、本発明にお
けるノード管理サーバーの３つの動作モードについて、
具体的に説明する。
【０２９２】本発明においては、サブネットに属する各
々の（スイッチ) ノードに対して、それぞれ１組のノー
ド設定サーバーとノード管理サーバーを対応させている
が、ノード管理サーバーの動作モードとして、サブネッ
トが１つのノードから構成されているとして動作するシ
ングルモードと、サブネットが複数のノードから構成さ
れているとして動作するマルチ・モードとを想定する。
サブネットが複数のノードから構成されている場合、マ
ルチ・モードは、さらに、サブネット内に唯一存在する
マスターモードのノード管理サーバーと、その他のスレ
ーブモードのノード管理サーバーの２種類のノード管理
サーバーに分類することとする。
【０２９３】シングルモード(singleMode)のノード管理
サーバー５０１は、サブネットが、該ノード管理サーバ
ーが対応する（スイッチ) ノードだけで構成されるとし
て、該ノードに接続している端末に対し、ネットワーク
・サービスを提供する。すなわち、該ノード管理サーバ
ーは、該ノードに接続している端末に対し、上記（１)
節で説明した該ノードに接続する端末間の呼設定サービ
スと、該ノード管理サーバーが管理する管理ファイルを
用いたネーム・サービス等を提供する。
【０２９４】マスターモード(masterMode)５０３のノー
ド管理サーバーは、サブネット内に唯一存在し、サブネ
ットに属する端末に対して、上記（１）節で説明した該
サブネットに属する端末間の呼設定サービスと、該ノー
ド管理サーバーが管理する管理ファイルを用いたネーム
・サービス等に加えて、サブネット外の端末との間の呼
設定サービス等を提供する。また、マスターモードのノ
ード管理サーバー５０３は、該マスターモードのノード
管理サーバー５０３がダウンした場合、スレーブモード
のノード管理サーバー５０２が、スムーズにシングルモ
ードに移行できるように、該マスターモードのノード管
理サーバー５０３が管理する管理情報を、スレーブモー
ドのノード管理サーバー５０２に対し、定期的に転送し
てもよい。
【０２９５】スレーブモード(slaveMode) ５０２のノー
ド管理サーバーは、マスターモードのノード管理サーバ
ー５０３に対して、定期的に、生存確認用のセルを送信
し、該マスターモードのノード管理サーバー５０３が、
該生存確認用のセルに対して応答を返すこと等によっ
て、マスターモードのノード管理サーバー５０３の生存
確認を実行する。該スレーブモードのノード管理サーバ
ー５０２は、前記応答セルを受信できなかった等の場
合、マスターモードのノード管理サーバー５０３がダウ
ンしたと認識し、シングルモードへ動作モードを遷移す
る。該スレーブモードのノード管理サーバー５０２は、
スムーズに、シングルモードへ状態遷移できるように、
マスターモードのノード管理サーバー５０３の生存時、
該マスターモードのノード管理サーバー５０３から転送
される管理情報を基に、シングルモード動作時に必要な
ファイルを作成してもよい。なお、（スイッチ) ノード
に対し割当てられたノード管理サーバーが、スレーブモ
ードで動作している場合、該ノードに接続している端末
の、ネットワーク・サービスの要求は、該スレーブモー
ドのノード管理サーバー５０２をバイパスして、マスタ
ーモードのノード管理サーバー５０３に送信され、同様
に、マスターモードのノード管理サーバー５０３の応答
は、該スレーブモードのノード管理サーバー５０２をバ
イパスして、要求を送信した端末に返される。マスター
モードのノード管理サーバー５０３は、また、スレーブ
モードのノード管理サーバー５０２を介して、ノード設
定サーバーに、ルーティングタグ等のハードウェアの設
定を要求してもよいし、該スレーブモードのノード管理
サーバー５０２を介せずに、直接、ノード設定サーバー
に要求してもよい。
【０２９６】以下、本発明におけるノード管理サーバー
の３つの動作モード間の状態遷移について、具体的に説
明する。また、図２８および図２９に、本発明における
ノード管理サーバーの３つの動作モード間の状態遷移ア
ルゴリズムの一部を示す。
【０２９７】本発明におけるノード管理サーバーは、起
動後（リセット後) 、動作モードがシングルモードに状
態遷移するとする（図２８のステップ１６１）。
【０２９８】リセット後、シングルモードで動作中のノ
ード管理サーバーは、該ノード管理サーバーが管理する
ＡＴＭ交換機のすべての入出力線に対して、該入出力線
の先に接続されるであろう端末と、該シングルモードの
ノード管理サーバー５０１との間に、ブート・チャネル
１１とメタシグナリング・チャネル１０の設定を実行す
る（図２８のステップ１６２）。該設定の終了後、該シ
ングルモードのノード管理サーバー５０１は、configフ
ァイル５５を参照する（ステップ１６３）。
【０２９９】該configファイル５５に、“master”と記
述されていた場合、該configファイル５５を参照したシ
ングルモードのノード管理サーバー５０１は、速やか
に、マスターモード５０３へと状態遷移するとする（ス
テップ１６４）。
【０３００】また、configファイル５５に“slave ”と
記述されていた場合、該configファイル５５を参照した
シングルモードのノード管理サーバー５０１は、該シン
グルモードのノード管理サーバー５０１が管理するＡＴ
Ｍ交換機のすべての入出力線に対して、後述する構成認
識アルゴリズムを実行し（図２９のステップ１６５〜１
６８）、マスター・モ−ドのノード管理サーバー５０３
から応答を受信した場合（ステップ１６８）、後述する
タイミングで、スレーブモードのノード管理サーバー５
０２に状態遷移するとする（ステップ１７５）。
【０３０１】すなわち、マスターモードのノード管理サ
ーバー５０３から応答を受信したシングルモードのノー
ド管理サーバー５０１は、まず、シングルモードで動作
中に得られた、該ノード管理サーバーが管理するＡＴＭ
交換機に接続する端末等の管理情報等を、該マスターモ
ードのノード管理サーバー５０３に転送する（ステップ
１６９）。次に、該シングルモードのノード管理サーバ
ー５０１は、該ノード管理サーバーが管理するＡＴＭ交
換機に接続する端末に対して、シングルモードで動作中
に設定した、該端末と該シングルモードのノード管理サ
ーバー５０１との間の、ブート・チャネル１１とメタシ
グナリング・チャネル１０の設定を、該端末とマスター
モードのノード管理サーバー５０３との間のチャネルと
なるように、該ブート・チャネル１１とメタシグナリン
グ・チャネル１０の設定を変更する（ステップ１７０〜
１７４）。最後に、該シングルモードのノード管理サー
バー５０１は、該シングルモードのノード管理サーバー
５０１とマスターモードのノード管理サーバー５０３と
の間に、管理用チャネル１６の設定を行うとともに（図
示せず）、動作モードをスレーブモードに状態遷移する
とする（ステップ１７５）。
【０３０２】ここに、図３０に、シングルモードのノー
ド管理サーバー５０１の動作モードが、スレーブモード
５０２に状態遷移する場合の、ブート・チャネル１１と
メタシグナリング・チャネル１０の設定変更と、管理用
チャネル１６の設定を示した模式図を示す。
【０３０３】マスターモードのノード管理サーバー５０
３から応答を受信しなかった場合、ある一定の期間後、
後述する構成認識アルゴリズムを再度実行するとし、以
後、マスターモードのノード管理サーバー５０３から応
答を受信するまで、周期的に、後述する構成認識アルゴ
リズムを繰り返すとし、その間、該ノード管理サーバー
は、シングルモード５０１で動作するとする。
【０３０４】また、スレーブモードのノード管理サーバ
ー５０２は、定期的に、マスターモードのノード管理サ
ーバー５０３に対して、生存確認用のセルを送信し、該
マスターモードのノード管理サーバー５０３が、該生存
確認用のセルに対し、応答を返すこと等によって、マス
ターモードのノード管理サーバー５０３の生存確認を実
行するとする。該スレーブモードのノード管理サーバー
５０２は、前記応答セルを受信できなかった等の場合、
マスターモードのノード管理サーバー５０３がダウンし
たと認識し、該スレーブモードのノード管理サーバー５
０２は、シングルモードへと動作モードを遷移させると
する。シングルモードに状態遷移したノード管理サーバ
ー５０１は、周期的に、前記したマスターモードのノー
ド管理サーバー５０３の生存確認方法、または後述する
構成認識アルゴリズム等を繰り返し実行し、マスターモ
ードのノード管理サーバー５０３の生存が確認された場
合、再び、スレーブモードへと状態遷移するとする。
【０３０５】また、スレーブモードのノード管理サーバ
ー５０２に対して、“master命令“を実行した場合、該
スレーブモードのノード管理サーバー５０２は、マスタ
ーモードへと状態遷移するとする。同様に、マスターモ
ードのノード管理サーバー５０３に対して、“slave 命
令“を実行した場合、該マスターモードのノード管理サ
ーバー５０３は、スレーブモードへと状態遷移するとす
る。
【０３０６】以下、図３０、および図３１〜３４を参照
しながら、本発明におけるスレーブモード等のノード管
理サーバーの構成認識アルゴリズムについて、具体的に
説明する。
【０３０７】図３１の方法Ａの構成認識アルゴリズム
は、ブート用セルを用いた構成認識アルゴリズムであ
る。
【０３０８】方法Ａによる構成認識を行うノード管理サ
ーバーは、対象とする入出力線のブート・チャネル１１
に、特定フォーマットを持つブート用セルを送信し（図
３１のステップ１８１）、該ブート用セルに対し、ノー
ド管理サーバーから特定フォーマットを持つ応答セルを
受信した場合（ステップ１８３）、該対象とする入出力
線の先にノード管理サーバーの存在を認識する（ステッ
プ１８６）、という方法である。また、該特定フォーマ
ットを持つ応答セルに、“singleMode”と書かれていた
場合、該応答セルを受信したノード管理サーバーは、該
対象とする入出力線の先にシングルモードのノード管理
サーバー５０１の存在を認識し、“masterMode“と書か
れていた場合、該対象とする入出力線の先にマスターモ
ードのノード管理サーバー５０３の存在を認識してもよ
い。また、対象とする入出力線のブート・チャネル１１
に、特定フォーマットを持つブート用セルを送信した
（ステップ１８１）後、特定フォーマットを持つ応答セ
ルを受信しなかった場合（ステップ１８２）、該構成認
識を行うノード管理サーバーは、該対象とする入出力線
の先にはノード管理サーバーは存在しないと認識する
（ステップ１８５）。
【０３０９】次に、図３２に示す前記特定フォーマット
を持つブート用セルを受信したノード管理サーバーのア
ルゴリズムについて説明する。本発明においては、図３
０に示すように、ブート・チャネル１１は、端末とシン
グルモードのノード管理サーバー５０１との間、または
端末とマスターモードのノード管理サーバー５０３との
間に設定されていて、端末とスレーブモードのノード管
理サーバー５０２との間には設定されていない。従っ
て、前記特定フォーマットを持つブート用セルを受信し
たシングルモードのノード管理サーバー５０１、または
マスターモードのノード管理サーバー５０３は、動作モ
ードに従って、以下の処理を実行するとする。すなわ
ち、動作モードがマスターモードの場合、該マスターモ
ードのノード管理サーバー５０３が管理するconfigファ
イル５５を参照し、該ブート用セルに対し、マスターモ
ードと書き込んだ特定フォーマットの応答セルを作成し
（図３２のステップ１９２）、該応答セルを、該ブート
用セルが転送されてきた入出力線のブート・チャネル１
１に転送する（ステップ１９３）。一方、動作モードが
シングルモードの場合、必要に応じて該ブート用セルに
対し、“singleMode”と書き込んだ特定フォーマットの
応答セルを作成し（ステップ１９４）、作成した応答セ
ルを、該ブート用セルが転送されてきた入出力線のブー
ト・チャネル１１に転送する（ステップ１９５）。
【０３１０】次に、図３３の方法Ｂの構成認識アルゴリ
ズムは、メタシグナリング・セルを用いた構成認識アル
ゴリズムである。すなわち、メタシグナリング・セルを
受信したノード管理サーバーは、該メタシグナリング・
セルが転送されてきた入出力線に対して、シグナリング
・チャネル１３を設定するとともに、該入出力線の先の
ユーザが、該シグナリング・チャネル１３を使用するた
めのＶＰＩ／ＶＣＩ値等を通知するため、応答セルを作
成し、該作成した応答セルを、該メタシグナリング・セ
ルが転送されてきた入出力線のメタシグナリング・チャ
ネル１０に転送する（図３４のステップ２１１〜２１
３）。該方法Ｂによる構成認識アルゴリズムは、ノード
管理サーバーが、前記応答セルを受信することによって
（図３３のステップ２０４）、対象とする入出力線の先
にノード管理サーバーの存在を認識する（ステップ２０
５）、方法である。なお、図３４に、メタシグナリング
・セルを受信したノード管理サーバーのアルゴリズムに
ついて示す。
【０３１１】３−２．サブネット内に複数のＮＩＳサー
バーが存在する場合について 本実施例は、ノード管理サーバー内にＮＩＳマスター・
サーバーが存在し、サブネット内に複数のＮＩＳスレー
ブ・サーバーが存在するモデルでモデル化したものであ
る。先の（１) 節では、サブネットが前記モデルの場合
について説明した。本節では、まず、ノード管理サーバ
ーは起動しているが、サブネット内にＮＩＳスレーブ・
サーバーが起動していない場合について説明し、次に、
サブネット内が前記した場合、またはサブネット内に複
数のＮＩＳスレーブ・サーバーが存在する場合におけ
る、ＮＩＳスレーブ・サーバーの起動手順について説明
する。
【０３１２】図３５は、対象とするサブネットにおい
て、ノード管理サーバーは起動しているが、ＮＩＳスレ
ーブ・サーバー６０１は起動していない場合の、本発明
における、ネットワーク・サーバーと端末との間のチャ
ネル構成を示した模式図である。サブネット内に、ＮＩ
Ｓスレーブ・サーバー６０１が起動していない場合、端
末３とノード管理サーバーとの間に、インフォメーショ
ン・チャネル１２が設定されるとする。端末上の、ＮＩ
Ｓクライアント・プロセスは、サブネット内のＮＩＳ情
報にアクセスする必要が生じた場合、前記インフォメー
ション・チャネル１２を用いて、ノード管理サーバー内
に存在するＮＩＳマスター・プロセス６００に、ＮＩＳ
情報への要求を送信するものとする。ノード管理サーバ
ー内のＮＩＳマスター・サーバー６００は、インフォメ
ーション・チャネル１２を経由して、ＮＩＳ情報への要
求を受信した場合、要求されたＮＩＳ情報を検索し、検
索したＮＩＳ情報を、該インフォメーション・チャネル
１２を経由して、前記要求を送信した端末上のＮＩＳク
ライアント・プロセスに、送信するものとする。
【０３１３】サブネット内に、ＮＩＳスレーブ・サーバ
ー６０１が存在しない場合、サブネット内に多数存在す
る端末上のＮＩＳクライアント・プロセスのＮＩＳ情報
の要求は、すべて、ノード管理サーバー５内に存在する
ＮＩＳマスター・プロセス６００に転送されることにな
るので、該ノード管理サーバー５の負荷は大きい状態に
ある。
【０３１４】図３６は、対象とするサブネット内におい
て、ノード管理サーバーは起動しているがＮＩＳスレー
ブ・サーバー６０１は起動していない状態から、ＮＩＳ
スレーブ・サーバー６０１が起動した場合の、端末とノ
ード管理サーバー５とＮＩＳスレーブ・サーバー６０１
間のチャネルの設定変更の様子を示した模式図である。
また、図３７および図３８は、前記した場合のノード管
理サーバーのＮＩＳ(スレーブ) サーバー起動時のアル
ゴリズムである。以下、図３６、図３７および図３８を
参照しながら、前記した場合について具体的に説明す
る。
【０３１５】ＮＩＳ( スレーブ) サーバー６０１は、起
動時に、ブート・チャネル１１を用いて、特定フォーマ
ットを持ったブート用セルを、ノード管理サーバー５に
転送する（図３７のステップ２２１）。
【０３１６】ノード管理サーバー５は、前記ブート用セ
ルを受信すると（ステップ２２３）、前記ブート用セル
を基に、configファイル５５を参照し（ステップ２２
４）、ＮＩＳ( スレーブ) サーバー６０１が起動したこ
とを認識する。前記ＮＩＳ( スレーブ) サーバー６０１
の起動を認識したノード管理サーバー５は、該ノード管
理サーバー５と該ＮＩＳ( スレーブ) サーバー６０１と
の間のＮＩＳ用チャネル１７の設定を対応するノード設
定サーバー４に要求するとともに（ステップ２２６）、
以下に示す処理を実行する。
【０３１７】すなわち、ノード管理サーバー５は、管理
ファイル５６を参照し、ノード管理サーバー５と端末３
との間、またはＮＩＳスレーブ・サーバー６０１と端末
３との間に設定されているすべてのインフォメーション
・チャネル１２に対し、負荷が重いかどうか検査する
（図３８のステップ２３１）。検査したインフォメーシ
ョン・チャネル１２のうち、負荷が重いと判定したイン
フォメーション・チャネル１２に対しては、接続先のノ
ード管理サーバー５、またはＮＩＳスレーブ・サーバー
６０１を変更することによって（ステップ２３２〜２３
８）、ＮＩＳサーバーの負荷分散を行うこととする。
【０３１８】対象とするサブネットにおいて、ノード管
理サーバ５ーは起動しているが、ＮＩＳスレーブ・サー
バー６０１は起動していない状態から、図３６に示すよ
うにＮＩＳスレーブ・サーバー６０１が起動した場合、
端末３とノード管理サーバー５との間に設定されている
すべてのインフォメーション・チャネル１２を、端末３
と該ＮＩＳスレーブ・サーバー６０１との間のインフォ
メーション・チャネル１２となるように設定を変更すれ
ば、ノード管理サーバー５の負荷を軽減することができ
る。
【０３１９】また、ノード管理サーバー５は、定期的
に、管理ファイル５６を参照し、設定されているすべて
のインフォメーション・チャネル１２を検査し、負荷の
重い(応答の遅い) インフォメーション・チャネル１２
があるかどうか検査し、該当するインフォメーション・
チャネル１２が存在した場合、接続先のＮＩＳサーバー
の変更（インフォメーション・チャネル１２の設定変
更) 等によって、ＮＩＳサーバーの負荷を分散すること
ができる。
【０３２０】該ノード管理サーバー５のインフォメーシ
ョン・チャネル１２の設定変更において、該インフォメ
ーション・チャネル１２を使用している端末に対して、
該端末が、前記インフォメーション・チャネル１２を使
用するためのＶＰＩ／ＶＣＩ値等を変更しなくてすむよ
うに、該インフォメーション・チャネル１２の設定変更
を行うことが望ましい。あるいは、ＶＰＩ／ＶＣＩ値等
を変更しなければならない場合、必要に応じて、ＶＰＩ
／ＶＣＩ値等の割り当て処理を実行し、実行した結果得
られたＶＰＩ／ＶＣＩ値等を用いて、前記インフォメー
ション・チャネル１２の設定変更を行い、設定変更の終
了後、該インフォメーション・チャネル１２を使用する
端末に対し、該インフォメーション・チャネル１２を使
用するためのＶＰＩ／ＶＣＩ値等を通知してもよい。
【０３２１】次に、図３９および図４０は、本発明にお
ける端末上のＮＩＳクライアント６１のＮＩＳサーバー
（６００／６０１）への帰属(bind)時の、ノード管理サ
ーバー等のアルゴリズムを示したものである。
【０３２２】図３９および図４０によれば、端末の起動
後、端末３上のＮＩＳクライアント６１がはじめてＮＩ
Ｓサーバーに帰属(bind)する場合（図３９のステップ２
５０）、該端末３と帰属先のＮＩＳサーバーとの間のイ
ンフォメーション・チャネル１２の設定をノード管理サ
ーバー５に要求するために、ブート・チャネル１１を用
いて、特定のフォーマットを持ったブート用セルをノー
ド管理サーバー５に送信する（ステップ２５２）。ま
た、端末３上のＮＩＳクライアント６１は、設定された
インフォメーション・チャネル１２を用いて、ＮＩＳサ
ーバーに、ＮＩＳ情報の要求を行うが、ＮＩＳ情報の要
求に対して、ＮＩＳサーバーの負荷が重く、応答が返っ
てこなかった場合、すなわち応答がタイムアウトした場
合（ステップ２５１）、端末３上のＮＩＳクライアント
６１は、帰属先のＮＩＳサーバーを負荷のより小さなＮ
ＩＳサーバーへ変更を要求するために、ブート・チャネ
ル１１を用いて、特定のフォーマットを持ったブート用
セルをノード管理サーバー５に送信する（ステップ２５
２）。
【０３２３】該特定のフォーマットを持ったブート用セ
ルを受信したノード管理サーバー５は、管理ファイル５
６等を参照し、負荷のより小さなＮＩＳサーバーを検索
し（図４０のステップ２６４）、該ブート用セルを送信
した端末と、該検索したＮＩＳサーバーとの間の、イン
フォメーション・チャネル１２の設定、またはインフォ
メーション・チャネル１２の設定変更を行うこととする
（ステップ２６３）。前記インフォメーション・チャネ
ル１２の設定、またはインフォメーション・チャネル１
２の設定変更において、ＶＰＩ／ＶＣＩ値等の割り当て
処理を実行しなければならない場合、必要に応じてＶＰ
Ｉ／ＶＣＩ値等の割り当て処理を実行することとする。
【０３２４】ノード管理サーバー５は、前記インフォメ
ーション・チャネル１２等の設定変更が終了した場合、
管理ファイル５６を変更するとともに（ステップ２７
３）、端末上のＮＩＳクライアント６１が、前記インフ
ォメーション・チャネル１２を使用するためのＶＰＩ／
ＶＣＩ値等の情報を該端末３に通知するために、ノード
管理サーバー５は、ブート・チャネル１１を用いて前記
情報を該端末３に転送する（ステップ２７４）。
【０３２５】３−３．サブネット内に複数の呼設定サー
バーが存在する場合について 前述した(3-2) 節とほぼ同様であるが、本発明において
は、サブネット内に複数の呼設定サーバーが存在すると
いうモデルでモデル化し、先の（１) 節では、サブネッ
トが前記モデルで構成される場合について説明した。こ
こでは、まず、ノード管理サーバーは起動しているが、
サブネット内の呼設定サーバーが起動していない場合に
ついて説明し、次に、サブネット内が前記した場合、ま
たはサブネット内に複数の呼設定サーバーが存在する場
合における呼設定サーバーの起動手順について説明す
る。
【０３２６】図３５は、また、対象とするサブネットに
おいて、ノード管理サーバー５は起動しているが、呼設
定サーバー７は起動していない場合の、本発明における
ネットワーク・サーバーと端末との間のチャネル構成を
示した模式図である。
【０３２７】サブネット内に、呼設定サーバーが起動し
ていない場合に、端末３からメタシグナリング・セルが
ノード管理サーバー５に送信されたとき、該端末３とノ
ード管理サーバー５との間にシグナリング・チャネル１
３が設定されるとする。端末３上の呼設定プロセスは、
サブネット内の他の端末に対しコネクション型のデータ
通信を行う必要の生じた場合、前記シグナリング・チャ
ネル１３を用いて、ノード管理サーバー５内に存在する
管理プロセス５１に呼設定要求を送信するものとする。
ノード管理サーバー５内の管理プロセス５１は、シグナ
リング・チャネル１３を経由して、呼設定要求を受信し
た場合、要求されたコネクションを設定するとともに、
該端末３が設定したコネクションを使用するためのＶＰ
Ｉ／ＶＣＩ値等の情報を、該シグナリング・チャネル１
３を経由して、前記要求を送信した端末３に送信するも
のとする。
【０３２８】サブネット内に、呼設定サーバーが存在し
ない場合、サブネット内に多数存在する端末の呼設定要
求は、すべてノード管理サーバー５内に存在する管理プ
ロセス５１に転送され、該管理プロセス５１が処理しな
ければならないので、該ノード管理サーバーの負荷は大
きい状態にある。
【０３２９】図３６は、また、対象とするサブネット内
において、ノード管理サーバー５は起動しているが呼設
定サーバー７は起動していない状態から、呼設定サーバ
ー７が起動した場合の、端末３とノード管理サーバー５
と呼設定サーバー７間のチャネルの設定変更の様子を示
した模式図である。また、図４１および４２は、前記し
た場合のノード管理サーバー５の呼設定サーバー７起動
時のアルゴリズムである。
【０３３０】以下、図３６、図４１および４２を参照し
ながら、前記した場合について、具体的に説明する。
【０３３１】呼設定サーバー７は、起動時に、ブート・
チャネル１１を用いて、特定フォーマットを持ったブー
ト用セルをノード管理サーバー５に転送する（図４１の
ステップ２９１）。
【０３３２】前記ブート用セルを受信したノード管理サ
ーバー５は、前記ブート用セルを基に、configファイル
５５を参照し（ステップ３０１）、呼設定サーバー７が
起動したことを認識する。前記呼設定サーバー７の起動
を認識したノード管理サーバー５は、該ノード管理サー
バー５と該呼設定サーバー７との間の、呼設定用チャネ
ル１８の設定と、負荷のより小さなＮＩＳ（スレーブ/
マスター) サーバーと該呼設定サーバー７との間の、イ
ンフォメーション・チャネル１２の設定を、対応するノ
ード設定サーバー４に要求する（ステップ３０３）。具
体的には、以下に示す処理を実行する。
【０３３３】ノード管理サーバー５は、管理ファイル５
６を参照し（図４２のステップ３０７）、ノード管理サ
ーバー５と端末３との間、またはすでに起動している呼
設定サーバー７と端末３との間に設定されているすべて
のシグナリング・チャネル１３に対し、負荷が重いかど
うか検査する。検査したシグナリング・チャネル１３の
うち、負荷が重いと判定したシグナリング・チャネル１
３に対しては、接続先のノード管理サーバー５または呼
設定サーバー７を変更することによって（ステップ３０
８）、呼設定サーバー７の負荷分散を行うこととする。
【０３３４】対象とするサブネットにおいて、ノード管
理サーバー５は起動しているが呼設定サーバーは起動し
ていない状態から、図３６に示すように呼設定サーバー
７が起動した場合、端末３とノード管理サーバー５との
間に設定されているすべてのシグナリング・チャネル１
３を、端末と該呼設定サーバー７との間のシグナリング
・チャネル１３となるように設定を変更すれば、ノード
管理サーバーの負荷を軽減することができる。
【０３３５】また、ノード管理サーバー５は、定期的
に、管理ファイル５６を参照し（ステップ３０７）、設
定されているすべてのシグナリング・チャネル１３を検
査し、負荷の重い（応答の遅い) シグナリング・チャネ
ル１３があるかどうか検査し、該当するシグナリング・
チャネル１３が存在した場合、接続先の呼設定サーバー
７の変更（シグナリング・チャネル１３の設定変更) 等
によって、呼設定サーバー７の負荷を分散することがで
きる。
【０３３６】該ノード管理サーバー５のシグナリング・
チャネル１３の設定変更において、該シグナリング・チ
ャネル１３を使用している端末３に対して、該端末３
が、前記シグナリング・チャネル１３を使用するための
ＶＰＩ／ＶＣＩ値等を変更しなくてすむように、該シグ
ナリング・チャネル１３の設定変更を行うことが望まし
い。なお、ＶＰＩ／ＶＣＩ値等を変更しなければならな
い場合、必要に応じてＶＰＩ／ＶＣＩ値等の割り当て処
理を実行し、実行した結果得られたＶＰＩ／ＶＣＩ値等
を用いて、前記シグナリング・チャネル１３の設定変更
を行い、設定変更の終了後、該シグナリング・チャネル
１３を使用する端末に対し、該シグナリング・チャネル
１３を使用するための、ＶＰＩ／ＶＣＩ値等を通知して
もよい。
【０３３７】また、一般的に、呼設定要求を受信した呼
設定サーバーは、まず、ネットワーク情報を入手するた
め、サブネット内のＮＩＳサーバーにアクセスし、次
に、得られたネットワーク情報を基に、対応するコネク
ションの設定をサブネット内のノード管理サーバーに要
求するという２段階の処理を、本発明において想定して
いる。図３６は、また、対象とするサブネットにおい
て、ノード管理サーバー５と呼設定サーバー７とＮＩＳ
スレーブ・サーバー６０１が起動している場合、呼設定
サーバー７が、前記した第１段階の処理を実行する方法
として、該呼設定サーバー７とＮＩＳスレーブ・サーバ
ー６０１との間に設定されているインフォメーション・
チャネル１２を用いる方法について図示している。図３
６以外の方法としては、呼設定サーバー７とノード管理
サーバー５内の管理プロセス５１との間に設定されてい
る呼設定用チャネル１８と、該管理プロセス５１とＮＩ
Ｓマスター・プロセス６００との間のプロセス間通信と
を用いる方法が考えられる。すなわち、呼設定サーバー
７が、前記した第１段階の処理を実行するため、該呼設
定サーバー７とノード管理サーバー５内の管理プロセス
５１との間に設定されている呼設定用チャネル１８を用
いて、ＮＩＳ情報の要求を該管理プロセス５１に送信
し、該ＮＩＳ情報の要求を受信した該管理プロセス５１
は、プロセス間通信を用いて、該ＮＩＳ情報の要求をＮ
ＩＳマスター・サーバー６００に送信する。ＮＩＳマス
ター・サーバー６００から、プロセス間通信によって、
該ＮＩＳ情報の要求に対する応答を受信した管理プロセ
ス５１は、該管理プロセス５１と呼設定サーバー７との
間に設定されている呼設定用チャネル１８を用いて、該
ＮＩＳ情報の応答を呼設定サーバー７に送信するといっ
た方法も存在する。
【０３３８】また、図３６では、対象とするサブネット
において、ノード管理サーバー５と呼設定サーバー７し
か起動していない場合、前記した呼設定サーバー７の第
１段階の処理を実行する方法として、呼設定サーバー７
とノード管理サーバー５内の管理プロセス５１との間に
設定されている呼設定用チャネル１８と、該管理プロセ
ス５１とＮＩＳマスター・プロセス６００との間のプロ
セス間通信とを用いる方法を図示している。図３６以外
の方法としては、呼設定サーバー７とノード管理サーバ
ー５内のＮＩＳマスター・サーバー６００との間に、イ
ンフォメーション・チャネル１２を設定する方法も考え
ることができる。すなわち、呼設定サーバー７が、前記
した第１段階の処理を実行するため、該呼設定サーバー
７とノード管理サーバー５内のＮＩＳマスター・サーバ
ー６００との間に設定されているインフォメーション・
チャネル１２を用いて、ＮＩＳ情報の要求を該ＮＩＳマ
スター・サーバー６００に送信し、該ＮＩＳマスター・
サーバー６００が、該インフォメーション・チャネル１
２を用いて、該ＮＩＳ情報の要求に対する応答を該呼設
定サーバー７に送信するといった方法である。
【０３３９】次に、図４３および図４４は、本発明にお
ける端末３と呼設定サーバー７との間のシグナリング・
チャネル１３の設定あるいは設定されたシグナリング・
チャネル１３の変更時の、ノード管理サーバー等のアル
ゴリズムを示したものである。
【０３４０】図４３および図４４によれば、端末の起動
後、端末３上の呼設定プロセスが、該端末３と呼設定サ
ーバー７との間のシグナリング・チャネル１３の設定を
ノード管理サーバー５に要求するために、メタシグナリ
ング・チャネル１０を用いて、メタシグナリング・セル
をノード管理サーバー５に送信する（図４３のステップ
３３０）。また、端末上の呼設定プロセスは、設定され
たシグナリング・チャネル１３を用いて、呼設定サーバ
ーに呼設定要求を送信するが、該呼設定要求に対して呼
設定サーバーの負荷が重く、応答が返ってこなかった場
合、すなわち応答がタイムアウトした場合（ステップ３
３１）、端末上の呼設定プロセスは、接続先の呼設定サ
ーバー７を負荷のより小さな呼設定サーバー７へ変更を
要求するために、メタシグナリング・チャネル１０を用
いて、メタシグナリング・セルをノード管理サーバー５
に送信しても良い（ステップ３３２）。
【０３４１】該メタシグナリング・セルを受信したノー
ド管理サーバー５は、管理ファイル５６等を参照し（図
４４のステップ３４４）、負荷のより小さな呼設定サー
バー７を検索し、該メタシグナリング・セルを送信した
端末３と、該検索した呼設定サーバー７との間のシグナ
リング・チャネル１３の設定、またはシグナリング・チ
ャネル１３の設定変更を行うこととする（ステップ３４
９）。前記シグナリング・チャネル１３の設定、または
シグナリング・チャネル１３の設定変更において、ＶＰ
Ｉ／ＶＣＩ値等の割り当て処理を実行しなければならな
い場合、必要に応じてＶＰＩ／ＶＣＩ値等の割り当て処
理を実行することとする（ステップ３４７）。
【０３４２】ノード管理サーバー５は、前記シグナリン
グ・チャネル１３等の設定変更が終了した場合、管理フ
ァイル５６を変更するとともに（ステップ３５３）、該
端末３が、前記シグナリング・チャネル１３を使用する
ための、ＶＰＩ／ＶＣＩ値等の情報を、該端末に通知す
るために、ノード管理サーバーは、メタシグナリング・
チャネル１０を用いて、前記情報を該端末に転送するこ
ととする（ステップ３５４）。
【０３４３】４．サブネット間のデータ通信について 本節では、本発明におけるサブネット間のデータ転送方
法について、以下に示す項目に従って、順に説明を行
う。 （4-1 ）サブネット間にまたがるネットワーク情報の管
理方法について （4-2 ）サブネット間にまたがるコネクションの設定方
法について （4-3 ）サブネット間にまたがるコネクションレス型デ
ータ転送方法について 以下、上記した項目に含まれないサブネット間にまたが
る事項、例えばネットワーク起動時のノード管理サーバ
ーのサブネットとサブネットの境界を認識する方法につ
いて、本発明の一実施例を、図３０、および図３１〜３
４を参照しながら、具体的に説明する。
【０３４４】図３０、および図３１〜３４は、同一サブ
ネットに属するノード管理サーバーが、起動時にすでに
起動しているサブネットのノード管理サーバーに帰属す
る方法について説明したものであった。前記した場合、
新たに起動したノード管理サーバーは、まず、シングル
モード５０１に状態遷移し、該ノード管理サーバーの管
理対象の（スイッチ) ノードに接続する端末に対し、ノ
ード管理サーバーとしてのサービスを提供しつつ、該ノ
ード管理サーバーが帰属するサブネットのマスターモー
ドのノード管理サーバー５０３に、該ノード管理サーバ
ーの起動の通知を試みるという方法であった。前記した
ように、本発明の一実施例においては、マスターモード
のノード管理サーバー５０３に、ノード管理サーバーの
起動を通知する方法として、２つの手段と、２つの方法
について説明した。すなわち、マスターモードのノード
管理サーバー５０３に、ノード管理サーバーの起動を通
知する手段として、該ノード管理サーバーが、起動時
に、管理対象のＡＴＭ交換機（スイッチノード) に対
し、該ＡＴＭ交換機のすべての入出力線の先に接続され
るであろう端末と、該ノード管理サーバーとの間に設定
するブート・チャネル１１とメタシグナリング・チャネ
ル１０のうち、ブート・チャネル１１を手段として用い
る方法と、メタシグナリング・チャネル１０を手段とし
て用いる方法について説明した。
【０３４５】また、ノード管理サーバーの起動をマスタ
ーモードのノード管理サーバー５０３に通知した後、該
ノード管理サーバーが、シングルモードからスレーブモ
ードへ状態遷移する方法として、シングルモードのノー
ド管理サーバー５０１が自発的にスレーブモードへ状態
遷移する方法と、マスターモードのノード管理サーバー
５０３が、シングルモードのノード管理サーバー５０１
に、スレーブモードへの状態遷移命令を送る方法の２と
おりの方法が存在する。
【０３４６】ここで、図３０（ａ）において、マスター
モードのノード管理サーバー５０３と、シングルモード
のノード管理サーバー５０１の属するサブネットが異な
る場合について、以下、具体的に説明する。
【０３４７】図３０（ａ）において、シングルモードの
ノード管理サーバー５０１は、該ノード管理サーバーの
起動をマスターモードのノード管理サーバー５０３に通
知するために、該ノード管理サーバーとＡＴＭ交換機の
入出力線の先に設定されているブート・チャネル１１を
用いて、ブート用セルを送信する。該ブート用セルを受
信したマスターモードのノード管理サーバー５０３は、
configファイル５５を参照し、該ブート用セルを送信し
た端末（シングルモードのノード管理サーバー５０１）
に、該端末が起動するのに必要なブート・イメージを送
信する。該ブート・イメージを受信したシングルモード
のノード管理サーバー５０１は、該ブート・イメージに
書かれたサブネットの名前と、該シングルモードのノー
ド管理サーバー５０１のconfigファイル５５に書かれて
いるサブネットの名前とを比較し、両者が異なっている
場合、該シングルモードのノード管理サーバー５０１
は、該入出力線によって、他のサブネットに接続してい
ることを認識することができる。また、他のサブネット
に接続していることを認識した該シングルモードのノー
ド管理サーバー５０１は、該入出力線のブート・チャネ
ル１１を用いて、該ブート・イメージを送信したマスタ
ーモードのノード管理サーバー５０３に、他のサブネッ
トに接続していることを通知してもよい。
【０３４８】また、シングルモードのノード管理サーバ
ー５０１は、該ノード管理サーバーの起動をマスターモ
ードのノード管理サーバー５０３に通知するために、ブ
ート用セルを送信する際に、該シングルモードのノード
管理サーバー５０１が属するサブネットの名前を、該ブ
ート用セルに書き込んで送信してもよい。前記した場
合、該ブート用セルを受信したマスターモードのノード
管理サーバー５０３は、受信したブート用セルに書かれ
ているサブネットの名前と、該マスターモードのノード
管理サーバー５０３のconfigファイル５５に書かれてい
る名前とを比較し、両者が異なっている場合、該マスタ
ーモードのノード管理サーバー５０３は、該入出力線
で、異なるサブネットが接続されていることを認識する
ことができる。該異なるサブネットが接続されているこ
とを認識したマスターモードのノード管理サーバー５０
３は、異なるサブネットに接続されていることを、該入
出力線のブート・チャネル１１を用いて、該ブート用セ
ルを送信したシングルモードのノード管理サーバー５０
１に通知してもよい。
【０３４９】また、マスターモードのノード管理サーバ
ー５０３のconfigファイル５５にサブネットとサブネッ
トの境界の入出力線の名前（例えば、ＶＰＩ／ＶＣＩ値
等)を書き込んでおくことによっても、マスターモード
のノード管理サーバー５０３が、サブネットとサブネッ
トの境界を認識することができる。本発明の一実施例に
おいては、ブート用セルを受信したマスターモードのノ
ード管理サーバー５０３が、該ブート用セルの転送され
てきた入出力線を識別できるように、ＡＴＭ交換機にお
いて、該ブート用セルのＶＰＩ／ＶＣＩ値の変換を行う
ことも想定している。従って、マスターモードのノード
管理サーバー５０３は、受信したブート用セルのＶＰＩ
／ＶＣＩ値を基に、configファイル５５に書かれている
サブネットとサブネットの境界のＶＰＩ／ＶＣＩ値と比
較することによって、該ブート用セルを送信したシング
ルモードのノード管理サーバー５０１が、サブネット中
のノード管理サーバーであるか、サブネット外のノード
管理サーバーであるかを識別することができる。
【０３５０】また、マスターモードのノード管理サーバ
ー５０３は、サブネット外のシングルモードのノード管
理サーバー５０１に対し、該サブネット外のシングルモ
ードのノード管理サーバー５０１から送信されるブート
用セルには応答せず、メタシグナリング・セルには応答
することによって、該サブネット外のシングルモードの
ノード管理サーバー５０１に対し、該入出力線が、サブ
ネットとサブネットの境界になっていることを通知する
ことができる。すなわち、マスターモードのノード管理
サーバー５０３は、該ノード管理サーバーのconfigファ
イル５５に記載されたノード管理サーバー以外のノード
管理サーバーから、ある入出力線を経由して、ブート用
セルとメタシグナリング・セルを受信した場合、該ブー
ト用セルに対しては何らアクションを行わず、該メタシ
グナリング・セルに対しては、該入出力線に対しシグナ
リング・チャネル１３を設定し、該シングルモードのノ
ード管理サーバー５０１に、該シグナリング・チャネル
１３の設定完了通知を送信する。シングルモードのノー
ド管理サーバー５０１は、ある入出力線を経由して、シ
グナリング・チャネル１３等の設定完了通知は送られて
きたが、ブート・イメージは送られてこなかった場合、
“該入出力線の先に、マスターモードのノード管理サー
バー５０３は存在するが、該シングルモードのノード管
理サーバー５０１をブートするのに適切な情報（ブート
・イメージ) を持ったマスターモードのノード管理サー
バー５０３ではなかった“と認識することができる。つ
まり、該シングルモードのノード管理サーバー５０１
は、該入出力線を経由して到達することのできるマスタ
ーモードのノード管理サーバー５０３は、該シングルモ
ードのノード管理サーバー５０１が属するサブネットの
マスターモードのノード管理サーバー５０３とは異なる
他のサブネットのマスターモードのノード管理サーバー
５０３と認識し、該入出力線が、サブネットとサブネッ
トの境界であると認識することができる。
【０３５１】以上は、マスターモード、スレーブモー
ド、およびシングルモードという、３状態を遷移するモ
デルを、ノード管理サーバーに適用したものであった。
以下、この状態遷移モデルを、ＮＩＳサーバーやＤＮＳ
サーバーといった一般のサーバーの状態遷移モデルに適
用した場合について説明する。
【０３５２】すなわち、システム全体が、複数のサーバ
ーによって協調管理されるシステムにおいて、システム
全体を複数の部分システムに分割し、各部分システムに
は、少なくとも１つのサーバーが割り当てられているも
のとする。各サーバーの動作モードとして、以下に説明
するマスターモード、スレーブモード、およびシングル
モードの３種類の動作モードが存在することとする。
【０３５３】シングルモードで動作中のサーバーは、該
サーバーに割り当てられた部分システム内の管理だけ行
う。
【０３５４】スレーブモードで動作中のサーバーの行う
管理には、以下に示す２通りの場合が存在する。
【０３５５】まず、１つの場合は、スレーブモードで動
作中のサーバーは、マスターモードで動作中のサーバー
の指示のみに従い、主体的に管理を行わないという場合
である。
【０３５６】他の場合は、スレーブモードで動作中のサ
ーバーは、該サーバーに割り当てられた部分システム内
の管理に対しては、主体的に行い、行った管理処理を必
要に応じてマスターモードで動作中のサーバーに通知す
る。一方、該サーバーに割り当てられた部分システム外
にまたがる管理に対しては、該スレーブモードで動作中
のサーバーは、対応するマスターモードで動作中のサー
バーに伺いを立て、該マスターモードで動作中のサーバ
ーの指示に従うといった方法である。
【０３５７】マスターモードで動作中のサーバーは、該
サーバーに部分システムが割り当てられている場合は、
該部分システムの管理を行うとともに、スレーブモード
で動作中のサーバーから要求された部分システム間にま
たがる管理を行い、関係する部分システムに割り当てら
れたスレーブモードで動作中のサーバーに、指示を送信
する。
【０３５８】以下、上記サーバーの状態遷移方法につい
て説明する。
【０３５９】サーバーは、起動後、まず、シングルモー
ドに状態遷移する。起動手順に、該サーバーの起動後の
動作モードがマスターモードと記述されていた場合は、
該サーバーは、起動後、マスターモードへと状態遷移す
る。
【０３６０】起動手順に、該サーバーの起動後の動作モ
ードがスレーブモードと記述されていた場合は、該サー
バーは、起動後、該サーバーが帰属するマスターモード
のサーバーが、正常に動作しているか動作確認を行い、
正常に動作していることが確認された場合は、スレーブ
モードへと状態遷移する。該サーバーが帰属するマスタ
ーモードのサーバーの正常動作が確認されなかった場
合、以後、定期的に、該マスターモードのサーバーの正
常動作が確認されるまで、シングルモードで動作する。
該サーバーは、シングルモードで動作している間は、割
り当てられた部分システムの管理のみを行い、該サーバ
ーが帰属するマスターモードのサーバーの正常動作を確
認した時点で、該サーバーがシングルモードで動作中に
行った管理処理を、マスターモードのサーバーに通知
し、スレーブモードへと状態遷移する。
【０３６１】スレーブモードで動作中のサーバーは、定
期的に、該サーバーが帰属するマスターモードのサーバ
ーの動作確認を行い、該マスターモードのサーバーの正
常動作が確認された場合は、スレーブモードで動作しつ
づける。該マスターモードのサーバーの正常動作が確認
されなかった場合、該スレーブモードで動作していたサ
ーバーは、シングルモードへと状態遷移する。該サーバ
ーは、シングルモードで動作している間は、割り当てら
れた部分システムの管理のみを行い、該サーバーが帰属
するマスターモードのサーバーの正常動作を確認した時
点で、該サーバーがシングルモードで動作中に行った管
理処理を、マスターモードのサーバーに通知し、スレー
ブモードへと状態遷移する。
【０３６２】４−１．サブネット間にまたがるネットワ
ーク情報の管理方法について 以下、図４５および図４６、ならびに図４７および図４
８を参照しながら、本発明におけるノード管理サーバー
のサブネット間にまたがるネットワーク情報の管理方法
について、具体的に説明する。図４５〜４８では、サブ
ネット間にまたがるネットワーク情報として、ノード管
理サーバーが管理する管理ファイル５６を例にとって説
明しているが、本発明を、例えばＮＩＳサーバーが管理
するＮＩＳ情報にも適用することも可能である。
【０３６３】サブネット間にまたがるネットワーク情報
の管理方法として、大きく分類して、対象とするサブネ
ットが該サブネットに属するネットワーク構成要素の情
報のみ管理する方法と、該サブネットが該サブネットに
属さないネットワーク構成要素の情報も管理する方法の
２通りの方法が存在する。特に、サブネット間の関係
が、ある１つのルート・ノード（ルート・サブネット)
を起点としたツリー構造の場合、該ツリー構造に属する
１つのサブネットが、該サブネットをルートとした部分
ツリー構造に属するすべてのサブネットのネットワーク
構成要素を管理する方法が一般的である。本発明の一実
施例においては、あるサブネットが、該サブネットをル
ートとした部分ツリー構造に属するすべてのサブネット
のネットワーク情報を管理する方法として、図４５に示
す直接アクセス方法と、図４６に示す間接アクセス方法
の２通りの方法を考慮する。
【０３６４】直接アクセス方法とは、図４５において、
あるサブネットに属するノード管理サーバーの管理ファ
イル５６には、該サブネットよりも下位のサブネットに
属するノード管理サーバーの管理ファイル５６の情報も
含まれるものとし、該サブネットの管理ファイル５６に
アクセスすれば、該サブネットよりも下位のサブネット
の管理ファイル５６の情報にもアクセスできるといった
方法である。
【０３６５】一方、間接アクセス方法とは、図４６にお
いて、あるサブネットに属するノード管理サーバーの管
理ファイル５６には、該サブネットよりも下位のサブネ
ットに属するノード管理サーバーの管理ファイル５６の
情報の代わりに、該管理ファイル５６へのポインタが含
まれるものとする。間接アクセス方法の場合、該サブネ
ットの管理ファイル５６にアクセスした場合、該管理フ
ァイル５６に含まれるポインタで示される、サブネット
の管理ファイル５６にもアクセス要求が転送され、該ア
クセス要求が転送されたサブネットの管理ファイル５６
に、対象とするネットワーク情報が存在した場合、その
ネットワーク情報が、あたかも元のサブネットの管理フ
ァイル５６にあったかのようにアクセスすることができ
るといった方法である。
【０３６６】本発明の一実施例においては、サブネット
間の構成は、あるサブネットをルート・ノードとしたツ
リー構造と、該ツリー構造内のあるノード（サブネッ
ト) と、該ノードをルートとした部分木には含まれない
ノードとをショート・カットして接続した構造とから構
成されることとする。なお、以下の説明において、サブ
ネット間の関係がツリー構造の場合、あるサブネットに
対し、該サブネットの１つ上位のサブネットをペアレン
ト・サブネット（以下、parentサブネットと記述する）
と呼ぶこととし、該サブネットの１つ下位のサブネット
をチャイルド・サブネット（以下、child サブネットと
記述する）と呼ぶこととする。また、あるサブネットと
ショート・カットして接続した同位のサブネットを、フ
レンド・サブネット（以下、friendサブネットと記述す
る）と呼ぶこととする。
【０３６７】また、本発明の一実施例においては、ネッ
トワーク情報の検索方向として、対象とするサブネット
の管理ファイル５６に、検索するネットワーク情報が見
つからなかった場合、該サブネットの１つ上位のサブネ
ット(parent サブネット) のノード管理サーバーと、該
サブネットと同位のサブネット(friend サブネット)の
ノード管理サーバーの２方向に検索の依頼を送信するも
のとする。該検索依頼を受信したparentサブネットのノ
ード管理サーバー５０４は、該ノード管理サーバーが管
理する管理ファイル５６を参照し、該検索したいネット
ワーク情報がなければ、該検索依頼を、さらに、該pare
ntサブネットの１つ上位のサブネットと、該parentサブ
ネットと同位のサブネットへリレーイングすることとす
る。また、該検索依頼を受信したfriendサブネットのノ
ード管理サーバー５０６は、該ノード管理サーバーが管
理する管理ファイル５６を参照し、該検索したいネット
ワーク情報が、該サブネット、または該サブネットをル
ートとする部分木に属するサブネットのノード管理サー
バーの管理ファイル５６に存在するかどうか、検索を実
行する。friendサブネットのノード管理サーバー５０６
は、管理ファイル５６を検索した結果、該検索依頼を受
けたネットワーク情報が見つからなかった場合、該検索
依頼を、他のサブネットへはリレーイングを行わないも
のとする。
【０３６８】図４７および図４８は、本発明の一実施例
における、直接アクセス方法と間接アクセス方法が混在
した場合の、ネットワーク情報アクセス時のノード管理
サーバーのアルゴリズムを図示したものである。図にお
いて、対象とするノード管理サーバーは、該ノード管理
サーバーが属するサブネット内のクライアントと、chil
d サブネットまたはfriendサブネットのノード管理サー
バー（５０５／５０６）から、ネットワーク情報の検索
要求を受信した場合（図４７のステップ３７０，図４８
のステップ３９０）、まず、該対象とするノード管理サ
ーバー自身の管理ファイル５６を検索するものとする
（図４８のステップ３９２）。次に、該ノード管理サー
バーは、ポインタで指されているノード管理サーバー
へ、ネットワーク情報の検索要求を依頼するものとする
（ステップ３９４）。
【０３６９】以上説明した検索の結果、検索したいネッ
トワーク情報が見つからなかった場合のうち、サブネッ
ト内のクライアントまたはchild サブネットから検索要
求を受信した場合、該ノード管理サーバーは、parentサ
ブネットのノード管理サーバー５０４へ、より上位のサ
ブネットが管理している管理ファイル５６でのネットワ
ーク情報の検索要求を送信するとともに、friendサブネ
ットのノード管理サーバー５０６へ、該サブネットが管
理している管理ファイル５６でのネットワーク情報の検
索要求を送信する（ステップ３９６）。
【０３７０】以上説明した検索の結果、検索したいネッ
トワーク情報が見つかった場合、該対象とするノード管
理サーバーは、該ネットワーク情報の検索を要求した該
サブネット内のクライアント、child サブネット、また
はfriendサブネットのノード管理サーバー（５０５／５
０６）に対し、検索要求を受けたネットワーク情報を送
信することとする。また、検索したいネットワーク情報
が見つからなかった場合、該ノード管理サーバーは、該
ネットワーク情報の検索を要求した該サブネット内のク
ライアント、child サブネット、またはfriendサブネッ
トのノード管理サーバー（５０５／５０６）に対し、検
索できなかったことを意味する検索ＮＧ通知を送信する
か、または何等アクションを起こさないことによって、
検索できなかったことを、通知することもできる。
【０３７１】４−２．サブネット間にまたがるコネクシ
ョンの設定方法について 以下、本発明の一実施例におけるサブネット間にまたが
るコネクションの設定方法について、図面を参照しなが
ら具体的に説明する。
【０３７２】まず、本発明の一実施例においては、呼設
定サーバー７が、端末から送信された呼設定要求（シグ
ナリング・セル) を受信した場合、以下に示す(a) →
(b) →(c) の手順で、該呼設定要求で要求された、宛先
の端末３との間のコネクションを設定するものとし、以
下、(a),(b),(c) の各々の項目について、具体的に説明
する。 a)宛先の端末が所属するサブネットの特定 b)該サブネットまでのルーティングの決定 c)ハードウェアの設定要求の送信 まず、呼設定サーバー７が、呼設定要求（シグナリング
・セル) を受信した場合、宛先の端末の所属するサブネ
ットを特定するために、該呼設定サーバー７が所属する
サブネットのノード管理サーバー５またはＮＩＳ（スレ
ーブ) サーバー（６００／６０１）に、該宛先の端末が
該サブネットに所属しているかどうか、ネットワーク情
報の検索を要求する。宛先の端末が該サブネットに所属
していなかった場合（該サブネットにおけるネットワー
ク情報の検索に失敗した場合) 、対象とするサブネット
のparentサブネットまたはfriendサブネットに、該宛先
の端末が所属しているかどうか調べるため、ネットワー
ク情報の検索を要求する。該parentサブネットまたは該
friendサブネットにおいて、ネットワーク情報の検索を
実行した結果、検索したい情報が見つからなかった場
合、該parentサブネットを基準として、該parentサブネ
ットのparentサブネットまたは該parentサブネットのfr
iendサブネットに対して、宛先の端末が前記サブネット
に所属しているかどうか調べるため、該ネットワーク情
報の検索を要求する。以下、該ネットワーク情報が検索
できるまで、順次、基準とするサブネットをツリー構造
の上位に移動させていって、該ネットワーク情報の検索
を実行するものとする。
【０３７３】宛先の端末の所属するサブネットが特定で
きた場合、呼設定サーバー７は、次に、該サブネットま
でのルーティングを決定するものとする。前記したよう
に、本発明の一実施例においては、サブネット間の構成
は、あるサブネットをルート・ノードとしたツリー構
造、該ツリー構造に属するノード（サブネット) 、およ
び該ノード（サブネット) をルートとした部分木には含
まれないノード（サブネット) をショート・カットして
接続した構造から構成されるとしている。従って、本発
明の一実施例において、サブネット間にまたがるコネク
ションを設定する場合、前記したサブネット間の構成を
用いて、効率よくコネクションを設定することとする。
すなわち、サブネット間にまたがるコネクションを設定
する場合、できるかぎり、サブネットとサブネット間を
ショート・カットしたコネクションを用いることによっ
て、端末間に設定されるコネクションの中に含まれる(
スイッチ) ノードの個数を少なくし、該コネクションの
エンド・エンド間の遅延を小さくすることを目標とす
る。なお、該ルーティングの決定において、呼設定サー
バー７は、ユーザから申告された平均／ピーク使用帯域
といったトラヒック・パラメータを基に、ユーザが要求
するセル廃棄率／セル転送遅延といったＱＯＳを満たす
コネクションが設定できるかどうか、ノード管理サーバ
ー５に問い合わせ、該要求品質を満たすようなルーティ
ングを決定するものとする。
【０３７４】最後に、該決定されたルーティングに従っ
て、該呼設定サーバー７は、該コネクションの設定を対
応するノード管理サーバー５に要求することとする。該
ノード管理サーバー５が対応するコネクションを正常に
設定できた場合、該呼設定サーバー７は、呼設定要求を
送信した端末に、該コネクションを使用するためのＶＰ
Ｉ／ＶＣＩ値等の情報を通知する。
【０３７５】図４９、図５０、および図５１は、サブネ
ット間にまたがるコネクションを設定するための、各々
のサーバーと端末との間の、チャネル構成方法を示した
ものである。以下、図４９〜５１で図示した３つの構成
方法について、具体的に説明する。
【０３７６】図４９は、サブネット間の情報の通信を、
サブネット間のノード管理サーバー５の間に設定された
管理用チャネル１６を用いて行おうというものである。
図４９の場合、端末から送信されたシグナリング・セル
を受信した呼設定サーバー７は、対応するコネクション
の設定を、該呼設定サーバー７の属するサブネットのノ
ード管理サーバー５に依頼し、以後、該ノード管理サー
バー５が、前記した手順で該コネクションの設定を行う
という方法である。なお、図４９は、ノード管理サーバ
ー５と呼設定サーバー７が、同一の端末上に存在しない
場合について図示したが、ノード管理サーバー５と呼設
定サーバー７が同一の端末上に存在する場合は、２つの
サーバー間のデータ通信は、呼設定用チャネル１８の代
わりに、プロセス間のデータ通信を使用してもよい。
【０３７７】図５０は、サブネット間の情報の通信を、
サブネット間の呼設定サーバー７の間に設定されている
シグナリング・チャネル１３を用いて行おうというもの
である。本発明の一実施例においては、前記したよう
に、ノード管理サーバー５の構成認識方法として、該ノ
ード管理サーバー５が管理するＡＴＭ交換機のすべての
入出力線に対し、ブート用セルとメタシグナリング・セ
ルを送信する方法について説明した。図５０の呼設定サ
ーバー７間のシグナリング・チャネル１３は、該ノード
管理サーバー５が、ある入出力線に対して構成認識を行
うため送信したメタシグナリング・セルに対し、シグナ
リング・チャネル１３が設定された場合、該ノード管理
サーバー５は、該入出力線を介して他のサブネットに接
続していると認識するとともに、該設定されたシグナリ
ング・チャネル１３を、サブネット内の呼設定サーバー
７に接続されるようにしたものである。なお、図４９と
同様であるが、図５０は、ノード管理サーバー５と呼設
定サーバー７が、同一の端末上に存在しない場合につい
て図示しているが、ノード管理サーバー５と呼設定サー
バー７が、同一の端末上に存在する場合は、２つのサー
バー間のデータ通信は、呼設定用チャネル18の代わり
に、プロセス間のデータ通信を使用してもよい。
【０３７８】図５１は、サブネット間の情報通信の方法
は、図４９，５０とほぼ同様であるが、宛先の端末の所
属するサブネットを検索するために、ネットワーク情報
にアクセスする点が、図４９，５０とは異なる。すなわ
ち、図５０の場合、宛先の端末の所属するサブネットを
検索するために、呼設定サーバー７は、ネットワーク情
報の検索をノード管理サーバー５に依頼する。該ネット
ワーク情報の検索要求を受信したノード管理サーバー５
は、該ノード管理サーバー５が管理する管理ファイル５
６、またはＮＩＳマスター・ファイル６２０等を検索す
るこにより、該要求されたネットワーク情報の検索を実
行する。一方、図５１の場合、宛先の端末の所属するサ
ブネットを検索するために、呼設定サーバー７は、ネッ
トワーク情報の検索をＮＩＳ（スレーブ) サーバー６０
１に依頼する点が、図４９，５０による方法と異なる。
なお、図４９，５０と同様であるが、図５１は、ノード
管理サーバー５と呼設定サーバー７とＮＩＳ（スレー
ブ) サーバー（６００／６０１）が、同一の端末上に存
在しない場合について図示しているが、該３つのサーバ
ーが、同一の端末上に存在する場合は、該３つのサーバ
ー間のデータ通信は、対応するチャネルを使用する代わ
りに、プロセス間のデータ通信を使用してもよい。
【０３７９】以下、図５２および図５３を参照しなが
ら、図５１の場合の呼設定サーバー７のサブネット間に
またがるコネクションを設定する方法について、具体的
に説明する。
【０３８０】対象とする呼設定サーバー７が、端末３ま
たは他のサブネットの呼設定サーバー７からシグナリン
グ・セルを受信した場合（図５２のステップ４２０）、
該呼設定サーバー７は、まず、該シグナリング・セルで
要求されているコネクションの宛先が、該呼設定サーバ
ー７と同じサブネットに存在するかどうか、該サブネッ
トが管理しているネットワーク情報の検索を行う（ステ
ップ４２１）。具体的には、該呼設定サーバー７は、イ
ンフォメーション・チャネル１２を用いて、ＮＩＳ（ス
レーブ／マスター) サーバーに、該宛先の端末が該サブ
ネット内に存在しているかどうか検索するため該端末の
ネットワーク情報の検索を依頼する。該端末のネットワ
ーク情報の検索を依頼されたＮＩＳサーバーは、該ＮＩ
Ｓサーバーが管理するＮＩＳファイル等を参照し（ステ
ップ４４１）、該宛先の端末等の情報が存在するかどう
か検索し、該ネットワーク情報が検索できた場合、検索
したネットワーク情報を、該検索要求を送信した呼設定
サーバー７に送信する（ステップ４４２）。一方、該ネ
ットワーク情報が検索できなかった場合、検索できなか
った旨を、該呼設定サーバー７に通知する（検索ＮＧセ
ルを送信する) 。
【０３８１】呼設定サーバー７が、ＮＩＳサーバーから
検索ＮＧセルを受信した場合、該宛先の端末が、該呼設
定サーバー７と同一のサブネット内に存在しなかったと
認識するとともに（ステップ４２５）、該呼設定サーバ
ー７は、該呼設定サーバー７が所属するサブネットの１
つ上位のサブネット(parent サブネット) または同位の
サブネット(friend サブネット) の呼設定サーバー７
へ、該宛先の端末と、対象とする呼設定サーバー７が所
属するサブネットまでのコネクションの設定を要求する
（ステップ４２６）。具体的には、対象とする呼設定サ
ーバー７が、端末またはchild サブネットからシグナリ
ング・セルを受信した場合、受信したシグナリング・セ
ルで要求しているコネクションの設定区間を、宛先の端
末と、該呼設定サーバー７が所属するサブネットと該１
つ上位のサブネット（parentサブネット) の境界点（Ｉ
ＷＵｐとする；ＩＷＵ:InterWorking Unit) との間に変
更し、該変更したシグナリング・セルを、該呼設定サー
バー７が所属するサブネットのすべてのparentサブネッ
トの呼設定サーバー７に送信する。同様に、該対象とす
る呼設定サーバー７が、端末または他のサブネット（ch
ild サブネットとfriendサブネット) からシグナリング
・セルを受信した場合、受信したシグナリング・セルで
要求しているコネクションの設定区間を、宛先の端末
と、該呼設定サーバー７が所属するサブネットと該frie
ndサブネットの境界点（ＩＷＵｆとする)との間に変更
し、該変更したシグナリング・セルを、該呼設定サーバ
ー７が所属するサブネットのすべてのfriendサブネット
の呼設定サーバー７に送信する。
【０３８２】該変更されたシグナリング・セルを受信し
た、parentサブネットの呼設定サーバー７は、該対象と
する呼設定サーバー７と同様な処理を実行する。すなわ
ち、宛先の端末が所属するサブネットに出会うまで、受
信したシグナリング・セルを変更しつつ、該変更したシ
グナリング・セルを、上位方向（parent方向) と同位方
向（friend方向) のサブネットの呼設定サーバー７にリ
レーイングする。該宛先の端末の所属するサブネットを
発見した場合、該宛先の端末とＩＷＵｐとの間のコネク
ションを設定するとともに、該コネクションを使用する
ためのＶＰＩ／ＶＣＩ値等を書き込んだ応答セルを、該
parentサブネットの呼設定サーバー７は、対象とするサ
ブネットの呼設定サーバー７へ送信する。一方、該宛先
の所属するサブネットが発見できなかった場合、該pare
ntサブネットの呼設定サーバー７は、対象とするサブネ
ットの呼設定サーバー７へ、コネクションが設定できな
かった旨を書き込んだ応答セルを送信する。
【０３８３】該変更されたシグナリング・セルを受信し
たfriendサブネットの呼設定サーバー７は、該対象とす
る呼設定サーバー７と同様な処理を実行する。すなわ
ち、宛先の端末が所属するサブネットに出会うまで、受
信したシグナリング・セルを変更しつつ、該変更したシ
グナリング・セルを、同位方向（friend方向) の、サブ
ネットの呼設定サーバー７にリレーイングする。該宛先
の端末の所属するサブネットを発見した場合、該宛先の
端末とＩＷＵｆとの間のコネクションを設定するととも
に、該コネクションを使用するためのＶＰＩ／ＶＣＩ値
等を書き込んだ応答セルを、該 friend サブネットの呼
設定サーバー７は、対象とするサブネットの呼設定サー
バー７へ送信する。一方、該宛先の所属するサブネット
が発見できなかった場合、該parentサブネットの呼設定
サーバー７は、対象とするサブネットの呼設定サーバー
７へ、コネクションが設定できなかった旨を書き込んだ
応答セルを送信する。
【０３８４】対象とする呼設定サーバー７が、ＮＩＳサ
ーバーからネットワーク情報の検索成功の通知を受けた
場合、parentサブネットの呼設定サーバー７からコネク
ションの設定通知を受けた場合、またはfriendサブネッ
トの呼設定サーバー７からコネクションの設定通知を受
けた場合、該呼設定サーバー７は、対応するコネクショ
ンの設定処理を実行する。具体的には、該呼設定サーバ
ー７が、ＮＩＳサーバーからネットワーク情報の検索成
功の通知を受けた場合、該呼設定サーバー７は、宛先の
端末と、呼設定要求を送信した端末または他のサブネッ
トとの境界点までのコネクションの設定要求を、サブネ
ット内のノード管理サーバーに送信する（図５３のステ
ップ４３１）。また、該呼設定サーバー７が、parentサ
ブネットの呼設定サーバー７からコネクションの設定通
知を受けた場合、該呼設定サーバー７は、ＩＷＵｐと、
呼設定要求を送信した端末または他のサブネットとの境
界点までのコネクションの設定要求を、サブネット内の
ノード管理サーバーに送信する。また、該呼設定サーバ
ー7 が、friendサブネットの呼設定サーバー7 からコネ
クションの設定通知を受けた場合、該呼設定サーバー7
は、ＩＷＵｆと、呼設定要求を送信した端末または他の
サブネットとの境界点までのコネクションの設定要求
を、サブネット内のノード管理サーバーに送信する（図
５３のステップ４３１）。
【０３８５】コネクションの設定要求を受信したノード
管理サーバー５は、申告されたトラヒック・パラメータ
で、要求されたＱＯＳを満たすコネクションが設定でき
るかどうか、管理ファイル５６等を参照することによっ
て判断する。あるいは、呼設定サーバー７が判断しても
良い。該要求を満たすコネクションが設定できる場合、
必要に応じてＶＰＩ／ＶＣＩ値等の割り当て処理を実行
し、ノード設定サーバー４に、ハードウェアの設定要求
を送信することによって、コネクションの設定を実行す
るとともに、該コネクションを使用するためのＶＰＩ／
ＶＣＩ値等の情報を書き込んだ応答セルを作成し、該コ
ネクションの設定要求を送信した呼設定サーバー７に、
該応答セルを送信する。一方、該要求を満たすコネクシ
ョンが設定できない場合、該ノード管理サーバーは、コ
ネクションの設定ができない旨書き込んだ、応答セルを
作成し、該コネクションの設定要求を送信した呼設定サ
ーバー７に、該応答セルを送信する。
【０３８６】該コネクションを使用するためのＶＰＩ／
ＶＣＩ値等の情報を書き込んだ応答セルを該呼設定サー
バー７が受信した場合、該呼設定サーバー７は、該コネ
クションの設定を要求した端末または他のサブネットの
呼設定サーバー７に、コネクションの設定の完了と、該
コネクションを使用するためのＶＰＩ／ＶＣＩ値等の情
報を書き込んだ設定ＯＫセルを送信する。一方、該呼設
定サーバー７が送信したシグナリング・セルに対し、す
べてのparent/friend サブネットの呼設定サーバー７か
ら要求するコネクションが設定できなかったと通知され
た場合、またはノード管理サーバーから要求したコネク
ションが設定できなかったと通知された場合、該呼設定
サーバー７は、該コネクションの設定を要求した端末ま
たは他のサブネットの呼設定サーバー７に、コネクショ
ンが設定できなかったことを意味する設定ＮＧセルを送
信する。
【０３８７】４−３．サブネット間にまたがるコネクシ
ョンレス型データ転送方法について 本発明の一実施例においては、以下に示す３つの方法に
よって、呼設定を行う手間が省けるという利点があるコ
ネクションレス型のデータ転送方法を実現するものであ
る。 （ａ）指定された端末間に、予め設定されたＱＯＳ（セ
ル転送遅延、セル廃棄) を保証しないコネクションを用
いる方法 （ｂ）ＣＬＳＦ(Connection-Less Service Function)処
理を用いたデータ転送方法 （ｃ）呼設定サーバーがＱＯＳの保証を必要としないコ
ネクションを設定することによる、コネクションレス型
のデータ転送のエミュレーション すなわち、本発明の一実施例においては、宛先の端末ま
で予めコネクションが設定されている場合は、上記(a)
の方法を用いてコネクションレス型のデータ転送を行う
こととし、予めコネクションが設定されていない場合
は、上記(b) の方法を用いてコネクションレス型のデー
タ転送を行うこととする。また、上記(a)の方法と上記
(b) の方法を用いてはデータ転送を行えない端末間の場
合、上記(c) の方法を用いてコネクションレス型のデー
タ転送を行うこともできる。上記(c) の方法を用いてコ
ネクションレス型のデータ転送を行う場合、呼設定サー
バー７が、宛先の端末までＱＯＳの保証を必要としない
コネクションを設定するまでは、端末が送信したセル
は、宛先の端末まで到達せず、途中で廃棄されることと
なる。
【０３８８】以下、本発明の一実施例における、ＣＬＳ
Ｆ処理を用いたコネクションレス型のデータ転送方法に
ついて、図５４、図５５を参照しながら、具体的に説明
する。
【０３８９】図５４は、本発明の一実施例におけるＣＬ
ＳＦ処理を用いたコネクションレス型のデータ転送を行
う場合の、端末３とＣＬＳＦ処理手段８とＮＩＳ（スレ
ーブ) サーバー６０１との間のチャネル構成を示したも
のである。本発明の一実施例において、簡単のために、
ＣＬＳＦ処理８を用いたコネクションレス型のデータ転
送を行う場合、サブネット間の構成は、１つのサブネッ
トをルート・ノードとしたツリー構造から構成されると
考えることとする。ここに、ツリー構造以外の他のネッ
トワーク構造の場合でも、本発明を適用することができ
るが、ここでは簡単のために、ツリー構造を考えること
とする。また、該ツリー構造において、該ツリー構造中
のあるノード（サブネット) は、ただ１つの上位のノー
ド（サブネット) に接続することとし、また、該ツリー
構造中のあるノード（サブネット) は、同位のノード
（サブネット) には接続しないと考えることとする。こ
こで、実際のサブネット間の構成では、ツリー構造中の
あるノード（サブネット) は、２つ以上の上位のノード
（サブネット) または同位のノード( サブネット) と接
続しているかもしれないが、コネクションレス型のデー
タ転送を行う場合は、上記したようなサブネット間の構
成モデルで考えるものとする。
【０３９０】本発明においては、該サブネット間のツリ
ー構造を用いて、サブネット間にまたがるコネクション
レス型のデータ転送を、効率よく行うものとする。
【０３９１】また、本発明の一実施例において、ＣＬＳ
Ｆ処理を用いたコネクションレス型のデータ転送を行う
場合、サブネット内に少なくとも１つのＣＬＳＦ処理手
段８が必要であり、予め、該サブネット内の端末のう
ち、コネクションレス型のデータ転送を行うすべての端
末３と該ＣＬＳＦ処理手段８との間に、ＱＯＳの保証を
必要としないＣＬ用チャネル１５を設定しておく必要が
ある。また、同一サブネット内のＣＬＳＦ処理手段８と
ＮＩＳ（スレーブ) サーバー６０１との間には、インフ
ォメーション・チャネル１２が設定されているものとす
る。また、対象とするサブネット内のＣＬＳＦ処理手段
８と、１つ上位のサブネット（parentサブネット) 内の
ＣＬＳＦ処理手段８との間に、ＣＬＳＦ間チャネル１９
が設定されているものとする。なお、図５４は、ＣＬＳ
Ｆ処理手段８とＮＩＳサーバー６０１が、同一のネット
ワーク構成要素（端末) 上に存在しない場合について図
示したものであるが、ＣＬＳＦ処理手段８とＮＩＳサー
バー６０１が、同一のネットワーク構成要素（端末) 上
に存在する場合は、２つのサーバー間のデータ通信は、
インフォメーション・チャネル１２を使用する代わり
に、プロセス間のデータ通信等を使用してもよい。
【０３９２】さらに、本発明の一実施例においては、対
象とするサブネット内の、ＣＬＳＦ処理手段８が起動し
た時点で、該ＣＬＳＦ処理手段８と、parentサブネット
内のＣＬＳＦ処理手段８との間のＣＬＳＦ間チャネル１
９と、該ＣＬＳＦ処理手段８と該サブネット内のＮＩＳ
（スレーブ) サーバー６０１との間のインフォメーショ
ン・チャネル１２が、設定されるものとする。また、対
象とするサブネット内の端末３が起動した時点で、該端
末３と該サブネット内のＣＬＳＦ処理手段８との間のＣ
Ｌ用チャネル１５が設定されるものとする。
【０３９３】図５５は、本発明の一実施例におけるＣＬ
ＳＦ処理手段８のコネクションレス型のデータ転送のア
ルゴリズムを示したものである。以下、図５５を参照し
ながら、具体的に説明する。
【０３９４】本発明の一実施例において、ＣＬＳＦ処理
手段８がユーザセルを受信した場合、まず、ＣＬＳＦ処
理手段８内のＶＰＩ／ＶＣＩキャッシュを参照し（ステ
ップ４８０）、該ユーザセルの宛先の端末名が存在する
かどうか、検索を実行する。ここに、ＶＰＩ／ＶＣＩキ
ャッシュとは、本発明の一実施例においては、以前使用
したＶＰＩ／ＶＣＩ値を記憶するための一時キャッシュ
とする。該ＶＰＩ／ＶＣＩキャッシュを参照した結果、
該ユーザセルの宛先の端末名が検索できた場合、検索し
た結果得られたＶＰＩ／ＶＣＩ値を基に、ユーザセルの
ヘッダ変換（ＶＰＩ／ＶＣＩ値の書き換え) を行い、該
ＣＬＳＦ処理手段８は、該ヘッダ変換を行ったユーザセ
ルを送信する。ＣＬＳＦ処理手段８は、ヘッダ変換を行
ったユーザセルを送信することによって、該ユーザセル
の宛先が該サブネット内にある場合、対応するＣＬ用チ
ャネル１５を用いて、該ユーザセルを宛先の端末３まで
転送することができる（ステップ４８６，４８７）。ま
た、該ユーザセルの宛先が該サブネット内にない場合、
ＣＬＳＦ間チャネル１９を用いて、該ユーザセルを、１
つ上位のサブネット（parentサブネット) のＣＬＳＦ処
理手段８まで転送することができる（ステップ４８８，
４８９）。
【０３９５】一方、ＶＰＩ／ＶＣＩキャッシュを参照し
た結果、該ユーザセルの宛先の端末名が検索できなかっ
た場合、該ＣＬＳＦ処理手段８は、インフォメーション
・チャネル１２を用いて、該ユーザセルの宛先の端末の
ネットワーク情報の検索を、ＮＩＳ（スレーブ) サーバ
ー６０１に要求する（ステップ４８１）。該ユーザセル
の宛先の端末のネットワーク情報の検索要求を受信した
ＮＩＳ（スレーブ) サーバー６０１は、該ＮＩＳサーバ
ーが管理するＮＩＳファイル等を参照し（ステップ５０
１）、該端末のネットワーク情報が存在するかどうか、
検索を行う。宛先の端末が該サブネット内に存在する場
合、該端末のネットワーク情報は、該ＮＩＳファイル等
を参照することによって検索することができるので、こ
の場合、該ＮＩＳサーバー６０１は、ＮＩＳファイル等
を検索することによって得られた宛先の端末３へＣＬ用
チャネル１５を用いてコネクションレス型のデータ転送
を行うためのＶＰＩ／ＶＣＩ値等を、該ＣＬＳＦ処理手
段８に送信する（ステップ５０５）。一方、宛先の端末
が、該サブネット内に存在しない場合、該端末のネット
ワーク情報は、該ＮＩＳファイル等を参照することによ
っては、検索することができないので、前記した場合、
該ＮＩＳサーバー６０１は、検索の失敗を書き込んだ検
索ＮＧセルを作成し、該ＣＬＳＦ処理手段８に送信す
る。
【０３９６】該ＣＬＳＦ処理部８は、該ＮＩＳサーバー
６０１から宛先の端末へＣＬ用チャネル１５を用いてコ
ネクションレス型のデータ通信を行うためのＶＰＩ／Ｖ
ＣＩ値等の情報を送信された場合、該ＣＬＳＦ処理部８
は、該ＶＰＩ／ＶＣＩを基に、ユーザセルのヘッダ変換
（ＶＰＩ／ＶＣＩ値の書き換え) を行い、該ＣＬＳＦ処
理部８は、該ヘッダ変換を行ったユーザセルを送信する
（ステップ４８７）。また、該ＣＬＳＦ処理部８が、該
ＮＩＳサーバーから検索ＮＧセルを受信した場合、該Ｃ
ＬＳＦ処理部８は、受信したユーザセルを、ＣＬＳＦ間
チャネル２０を用いて、該サブネットの１つ上位のサブ
ネット（parentサブネット) に転送する（ステップ４８
９）。最後に、該ＣＬＳＦ処理部８は、ＮＩＳサーバー
から送信されたネットワーク情報を、ＶＰＩ／ＶＣＩキ
ャッシュに書き込むことによって（ステップ４９０）、
以降の宛先の端末名からＶＰＩ／ＶＣＩ値への変換を、
効率よく行えるようになる。
【０３９７】
【発明の効果】また、本発明によれば、１つのシステム
が複数のサービス提供装置によって、協調的に管理され
る分散環境下において、マスターモードのサービス提供
装置に障害が発生するなどによって、マスターモードの
サービス提供装置がマスターモードとして正常に動作し
なくなった場合、スレーブモードのサービス提供装置
は、シングルモードへと状態遷移し、該サービス提供装
置に割り当てられた部分システムに対し、該シングルモ
ードのサービス提供装置が、サービスを提供することが
できるようにした。
【０３９８】これによって、従来のモードが固定されて
いたマスター／スレーブ・システムと異なり、マスター
モードのサービス提供装置が正常に動作しなくなった場
合、該システムに対して、サービスの提供が停止してし
まうといった不具合を回避することができる。また、本
発明によれば、比較的簡単な方法によって、障害の発生
したマスターモードのサービス提供装置を復帰させ、す
みやかに前記協調的管理を復旧させることができる。
【図面の簡単な説明】
【図１】本発明の一実施例に係るネットワーク・システ
ムの要部概略構成を示す図
【図２】本発明の一実施例に係るノード管理サーバーに
よるシングル・モードの場合のブートについて説明する
ための図
【図３】ネットワーク・サーバーが同一の端末上にない
場合の当該ネットワーク・サーバーのブートについて説
明するための図
【図４】本発明の一実施例に係るＡＴＭ交換システムに
おけるＶＰＩ／ＶＣＩテーブルを示す図
【図５】端末立ち上げ時のＶＰＩ／ＶＣＩテーブルにつ
いて説明するための図
【図６】本発明の一実施例に係るＡＴＭ交換システムに
おけるＮＩＳマップの分配について説明するための図
【図７】本発明の一実施例に係るＡＴＭ交換システムに
おけるＮＩＳのアクセス方法について説明するための図
【図８】本発明の一実施例に係るネットワーク情報のア
クセス方法を示すフローチャート
【図９】図８のフローチャートの続きの部分を示すフロ
ーチャート
【図１０】本発明の一実施例に係るＮＩＳクライアント
のＮＩＳサーバーへのbind方法を示すフローチャート
【図１１】本発明の一実施例に係るＡＴＭ交換システム
におけるデータ転送方法について説明するための図
【図１２】本発明の一実施例に係るＡＴＭ交換システム
におけるデータ転送アルゴリズムの一例を示すフローチ
ャート
【図１３】図１２のフローチャートの続きの部分を示す
フローチャート
【図１４】本発明の一実施例に係るＡＴＭ交換システム
におけるデータ転送アルゴリズムの他の例を示すフロー
チャート
【図１５】図１４のフローチャートの続きの部分を示す
フローチャート
【図１６】本発明の一実施例に係るＡＴＭ交換システム
におけるデータ転送アルゴリズムのさらに他の例を示す
フローチャート
【図１７】図１６のフローチャートの続きの部分を示す
フローチャート
【図１８】本発明におけるＶＰＩ／ＶＣＩ割り当て時の
ハードウェア構成を示す図
【図１９】本発明の一実施例に係るＶＰＩ／ＶＣＩ−ｌ
ｉｓｔファイルおよびＶＰＩ／ＶＣＩ−ｐｏｉｎｔｅｒ
ファイルの構成の一例を示す図
【図２０】本発明の一実施例に係るＶＰＩ／ＶＣＩ割り
当て方法の一例を示すフローチャート
【図２１】図２０のフローチャートの続きの部分を示す
フローチャート
【図２２】本発明の一実施例に係るＶＰＩ／ＶＣＩ−ｌ
ｉｓｔファイルの構成の他の例を示す図
【図２３】本発明の一実施例に係るＶＰＩ／ＶＣＩ−ｐ
ｏｉｎｔｅｒファイルの構成の他の例を示す図
【図２４】本発明の一実施例に係るＶＰＩ／ＶＣＩ割り
当て方法の他の例を示すフローチャート
【図２５】図２４のフローチャートの続きの部分を示す
フローチャート
【図２６】他のコネクションに割り当てることのできる
ＶＰＩ／ＶＣＩ値を獲得する方法を示すフローチャート
【図２７】本発明の一実施例に係るノード管理サーバー
の状態遷移について説明するための図
【図２８】本発明の一実施例に係るノード管理サーバー
の状態遷移アルゴリスズの一部を示すフローチャート
【図２９】図２８のフローチャートの続きの部分を示す
フローチャート
【図３０】本発明の一実施例に係るノード管理サーバー
の状態遷移を示した模式図
【図３１】本発明の一実施例に係るノード管理サーバー
の構成認識アルゴリズムの一例を示すフローチャート
【図３２】特定フォーマットを持つブート用セルを受信
したノード管理サーバーのアルゴリズムを示すフローチ
ャート
【図３３】本発明の一実施例に係るノード管理サーバー
の構成認識アルゴリズムの他の例を示すフローチャート
【図３４】メタシグナリング・セルを受信したノード管
理サーバーのアルゴリズムを示すフローチャート
【図３５】本発明の一実施例に係る呼設定サーバー／ネ
ームサーバーが起動していない場合のシステム構成を示
す図
【図３６】本発明の一実施例に係る呼設定サーバーとネ
ームサーバーの起動について説明するための図
【図３７】本発明の一実施例に係るノード管理サーバー
のＮＩＳサーバー起動時のアルゴリズムを示すフローチ
ャート
【図３８】図３７のフローチャートの続きの部分を示す
フローチャート
【図３９】本発明の一実施例に係る端末上のＮＩＳクラ
イアントのＮＩＳサーバー帰属アルゴリズムを示すフロ
ーチャート
【図４０】図３９のフローチャートの続きの部分を示す
フローチャート
【図４１】本発明の一実施例に係るノード管理サーバー
の呼設定サーバー起動時のアルゴリズムを示すフローチ
ャート
【図４２】図４１のフローチャートの続きの部分を示す
フローチャート
【図４３】本発明の一実施例に係る端末上の呼設定プロ
セスの呼設定サーバーへの接続アルゴリズムを示すフロ
ーチャート
【図４４】図４３のフローチャートの続きの部分を示す
フローチャート
【図４５】本発明の一実施例に係るサブネット間にまた
がるネットワーク情報の直接アクセス方法について説明
するための図
【図４６】本発明の一実施例に係るサブネット間にまた
がるネットワーク情報の間接アクセス方法について説明
するための図
【図４７】本発明の一実施例に係るネットワーク情報ア
クセス時のノード管理サーバーのアルゴリズムを示すフ
ローチャート
【図４８】図４７のフローチャートの続きの部分を示す
フローチャート
【図４９】本発明の一実施例に係るサブネット間にまた
がる呼設定を行うためのチャネル構成の一例を説明する
ための図
【図５０】本発明の一実施例に係るサブネット間にまた
がる呼設定を行うためのチャネル構成の他の例を説明す
るための図
【図５１】本発明の一実施例に係るサブネット間にまた
がる呼設定を行うためのチャネル構成のさらに他の例を
示す図
【図５２】本発明の一実施例に係るサブネット間を考慮
した呼設定サーバーのアルゴリズムを示すフローチャー
ト
【図５３】図５２のフローチャートの続きの部分を示す
フローチャート
【図５４】本発明の一実施例に係るサブネット間にまた
がるコネクションレス型のデータ転送について説明する
ための図
【図５５】本発明の一実施例に係るＣＬＳＦ処理手段の
データ転送アルゴリズムを示すフローチャート
【図５６】従来のＡＴＭ交換システムの一例を示す図
【図５７】従来のＡＴＭ交換システムにおけるコピーコ
ネクションの実現方法について説明するための図
【図５８】従来のＡＴＭ交換システムにおけるＣＬＳＦ
処理手段によるコネクションレス・サービスの実現方法
について説明するための図
【図５９】従来のコンピュータ間通信の一例を示す図
【図６０】従来のＩＰによるデータグラムの転送につい
て説明するための図
【図６１】従来のＡＲＰについて説明するための図
【図６２】従来のＮＩＳについて説明するための図
【図６３】従来のネットワーク情報へのアクセス手順を
示すフローチャート
【図６４】図６３のフローチャートの続きの部分を示す
フローチャート
【図６５】従来のＮＩＳクライアントのＮＩＳサーバー
へのｂｉｎｄ手順を示すフローチャート
【図６６】従来のディスクレス・クライアントのブート
ストラップについて説明するための図
【図６７】従来のブロードキャスト・アルゴリズムにつ
いて説明するための図
【符号の説明】
１０…メタシグナリング・チャネル １１…ブート・チャネル １２…インフォメーション・チャネル １３…シグナリング・チャネル １４…ユーザ・チャネル １５…ＣＬ用チャネル １６…管理用チャネル １７…ＮＩＳ用チャネル １８…呼設定用チャネル １９…ＣＬＳＦ間チャネル ２…ＡＴＭ交換機 ２１…前処理部 ２２…共有メモリ型スイッチ ２３…後処理部 ２４…ルーティングタグ・テーブル等のハードウェア・
テーブル ３…端末（Ｈｏｓｔ） ３１…ホスト ３２…データレス・クライアント ３３…ディスクレス・クライアント ３４…端末ブート・プロセス ４…ノード設定サーバー ４１…設定プロセス ４２…ｂａｃｋｕｐファイル ５…ノード管理サーバー ５０１…ノード管理サーバー（シングルモード） ５０２…ノード管理サーバー（スレーブモード） ５０３…ノード管理サーバー（マスターモード） ５０４…ノード管理サーバー（ｐａｒｅｎｔ） ５０５…ノード管理サーバー（ｃｈｉｌｄ） ５０６…ノード管理サーバー（ｆｒｉｅｎｄ） ５１…管理プロセス ５２…ＡＴＭブート・プロセス ５３…端末ブート・プロセス ５４…端末メタシグナリング・プロセス ５５…ｃｏｎｆｉｇファイル ５６…管理ファイル ５１１…受信部 ５１２…ＶＰＩ／ＶＣＩ割当処理部 ５１３…送信部 ５６１…ＶＰＩ／ＶＣＩ−ｌｉｓｔファイル ５６２…ＶＰＩ／ＶＣＩ−ｐｏｉｎｔｅｒファイル ６…ＮＩＳサーバー ６００…ＮＩＳマスタ・サーバー（プロセス） ６０１…ＮＩＳスレーブ・サーバー（プロセス） ６１…ＮＩＳクライアント ６２…ＮＩＳマップ ６２０…ＮＩＳマスター・マップ ６２１…ＮＩＳスレーブ・マップ ６３…ＮＩＳファイル ７…呼設定サーバー（プロセス）

Claims (5)

    【特許請求の範囲】
  1. 【請求項１】複数の端末を含むサブシステムを複数相互
    に接続して構成し、各サブシステム内にはその内に含ま
    れる端末を管理するサービス提供装置をそれぞれ備えた
    ネットワークにおけるサービス提供装置の動作方法であ
    って、 前記サービス提供装置のうちの１つをマスターモードの
    サービス提供装置とし、当該マスターモードのサービス
    提供装置がマスターとしての動作を正常に行っている間
    は、他のサービス提供装置がスレーブモードの動作を行
    うことによって、全サービス提供装置が協調してサブシ
    ステム間にまたがる前記管理を行い、 前記マスターモードのサービス提供装置がマスターモー
    ドとしての動作を正常に行わなくなった場合には、各サ
    ービス提供装置はシングルモードにモード遷移して、自
    己の属するサブシステム内で閉じた前記管理を行うこと
    を特徴とするサービス提供装置の動作方法。
  2. 【請求項２】前記サービス提供装置は、シングルモード
    としての動作中に、定期的に、前記マスターモードのサ
    ービス提供装置が正常に動作し始めたかどうかを検査
    し、前記マスターモードのサービス提供装置が正常に動
    作し始めたことを確認したときには、シングルモードと
    しての動作中に行った管理処理について前記マスターモ
    ードのサービス提供装置に通知し、スレーブモードへモ
    ード遷移することを特徴とする請求項１に記載のサービ
    ス提供装置の動作方法。
  3. 【請求項３】前記マスターモードのサービス提供装置
    は、新たに起動した場合、マスターモードへモード遷移
    し、前記スレーブモードのサービス提供装置へ指示を行
    って、システム全体の管理を行うことを特徴とする請求
    項１に記載のサービス提供装置の動作方法。
  4. 【請求項４】前記スレーブモードのサービス提供装置
    は、新たに起動した場合、前記マスターモードのサービ
    ス提供装置が正常に動作していることを確認したなら
    ば、スレーブモードで動作を開始し、確認できなかった
    ならば、シングルモードで動作を開始することを特徴と
    する請求項１に記載のサービス提供装置の動作方法。
  5. 【請求項５】前記サービス提供装置は、ＮＩＳサーバー
    またはＤＮＳサーバーであることを特徴とする請求項１
    に記載のサービス提供装置の動作方法。
JP2001323958A 2001-10-22 2001-10-22 サービス提供装置の動作方法 Expired - Fee Related JP3577025B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2001323958A JP3577025B2 (ja) 2001-10-22 2001-10-22 サービス提供装置の動作方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2001323958A JP3577025B2 (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
JP2002199001A true JP2002199001A (ja) 2002-07-12
JP3577025B2 JP3577025B2 (ja) 2004-10-13

Family

ID=19140769

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2001323958A Expired - Fee Related JP3577025B2 (ja) 2001-10-22 2001-10-22 サービス提供装置の動作方法

Country Status (1)

Country Link
JP (1) JP3577025B2 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007173990A (ja) * 2005-12-19 2007-07-05 Fujitsu Ltd 情報処理装置、通信負荷分散方法及び通信負荷分散プログラム
JP2009141551A (ja) * 2007-12-05 2009-06-25 Nippon Telegr & Teleph Corp <Ntt> 経路計算装置におけるセッション管理方法およびその経路計算装置
JP2010519819A (ja) * 2007-02-15 2010-06-03 タイコ エレクトロニクス サブシー コミュニケーションズ エルエルシー 分散型ネットワーク管理システムおよび方法
US7937748B2 (en) 2005-04-27 2011-05-03 Kabushiki Kaisha Toshiba Communication apparatus and communication method and computer readable medium

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7937748B2 (en) 2005-04-27 2011-05-03 Kabushiki Kaisha Toshiba Communication apparatus and communication method and computer readable medium
JP2007173990A (ja) * 2005-12-19 2007-07-05 Fujitsu Ltd 情報処理装置、通信負荷分散方法及び通信負荷分散プログラム
JP4645435B2 (ja) * 2005-12-19 2011-03-09 富士通株式会社 情報処理装置、通信負荷分散方法及び通信負荷分散プログラム
JP2010519819A (ja) * 2007-02-15 2010-06-03 タイコ エレクトロニクス サブシー コミュニケーションズ エルエルシー 分散型ネットワーク管理システムおよび方法
JP2009141551A (ja) * 2007-12-05 2009-06-25 Nippon Telegr & Teleph Corp <Ntt> 経路計算装置におけるセッション管理方法およびその経路計算装置
JP4615005B2 (ja) * 2007-12-05 2011-01-19 日本電信電話株式会社 経路計算装置におけるセッション管理方法およびその経路計算装置

Also Published As

Publication number Publication date
JP3577025B2 (ja) 2004-10-13

Similar Documents

Publication Publication Date Title
US6553014B1 (en) ATM communication system, process migration method in the ATM communication system, and handover processing method
US6598080B1 (en) Network interconnection apparatus network node apparatus and packet transfer method for high speed large capacity inter-network communication
JP4938687B2 (ja) ネットワークシステムおよび中継装置
US5600644A (en) Method and apparatus for interconnecting LANs
US6999998B2 (en) Shared memory coupling of network infrastructure devices
JP2791236B2 (ja) プロトコル並列処理装置
AU681062B2 (en) Network having secure fast packet switching and guaranteed quality of service
JP3131137B2 (ja) バーチャルネットワークシステム
JP2002516042A (ja) 伝送ネットワークにおいてパケットの経路指定とスイッチングとの間をダイナミックにシフトする改良された方法及び装置
JPH08111693A (ja) データ転送方法
JP2004048661A (ja) ネットワークのパス構成のための方法および装置
JP3561107B2 (ja) ネットワーク接続装置
CN108200199B (zh) IPV4 over IPV6隧道场景中的负载均衡系统及方法
Chiueh Supporting real-time traffic on Ethernet
JP3577025B2 (ja) サービス提供装置の動作方法
JPH10308758A (ja) 通信装置
JP3256610B2 (ja) 端末起動方法
EP1041794A2 (en) Network-device control apparatus and communication system
JP3583747B2 (ja) ネットワーク管理方法
JP2001036581A (ja) 通信帯域設定システムと方法
Cisco Bridging and IBM Networking Overview
Cisco Bridging and IBM Networking Overview
Cisco Bridging and IBM Networking Overview
JPH06311185A (ja) Ａｔｍ通信システム
EP4170972A1 (en) Message forwarding method, device and system

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: 20040706

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20040708

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

Free format text: PAYMENT UNTIL: 20080716

Year of fee payment: 4

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

Free format text: PAYMENT UNTIL: 20090716

Year of fee payment: 5

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

Free format text: PAYMENT UNTIL: 20090716

Year of fee payment: 5

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

Free format text: PAYMENT UNTIL: 20100716

Year of fee payment: 6

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

Free format text: PAYMENT UNTIL: 20110716

Year of fee payment: 7

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

Free format text: PAYMENT UNTIL: 20120716

Year of fee payment: 8

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

Free format text: PAYMENT UNTIL: 20130716

Year of fee payment: 9

LAPS Cancellation because of no payment of annual fees