JPH11252142A - データ伝送装置及び方法、並びにネットワークシステム - Google Patents

Abstract

(57)【要約】 【課題】 複数のノードで構成されるネットワークの１
つのノードのパケット入出力用のキュー（待ち行列）の
有効利用を図り、システム全体の通信効率等の性能向上
を実現する。 【解決手段】 複数のノードで構成されるネットワーク
の１つのノード１００内のキューリソース１４０は、キ
ューリソース制御部１５０からの制御信号により、リク
エスト出力用領域１４１、レスポンス出力用領域１４
２、リクエスト入力用領域１４３、レスポンス入力用領
域１４４が割当制御されるようになっている。キューリ
ソース制御部１５０は、各領域１４１〜１４４に対する
入出力パケット量等に応じて、動的に各領域１４１〜１
４４の割当を変更制御する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、データ伝送装置及
び方法、並びにネットワークシステムに関し、特に、複
数のノードで構成されるネットワークの１つのノードと
なるデータ伝送装置及び当該ノードからデータを伝送す
るためのデータ伝送方法、並びにネットワークシステム
に関する。

【０００２】

【従来の技術】複数のノードで構成されるネットワーク
環境でノード間通信を行なう際には、情報をまとめて一
定の大きさとしたパケットを通信単位として用いるパケ
ット通信が近年において多く採用されている。ここでノ
ード（node）とは、ネットワーク上での送受信ステーシ
ョン、すなわち、コンピュータ端末やそれに準ずる装
置、例えばハードディスク、監視／制御機器、プリン
タ、その他の各種端末機器等のことを言う。

【０００３】図２６は、複数のノードで構成されるネッ
トワーク環境の一例を示す図である。この図２６に示し
た例は、リングトポロジー接続によるものである。トポ
ロジーとは、一般的にはネットワーク接続での形態・形
状のことであり、各ノード間をリング(ring：輪)状につ
なげた場合を言う。

【０００４】図２６において、例えばノードＮＡとノー
ドＮＣで通信等によるパケットのやり取りがある場合、
ノードＮＡから発信されたパケットは、ノードＮＢを経
由してノードＮＣに、また、ノードＮＣから発信された
パケットは、ノードＮＤを経由してノードＮＡで受信さ
れることになる。

【０００５】各ノードには入力と出力の口（ポート）が
あり、入力ポートから入った信号、又はパケットデータ
は、ノード内で処理されてから出力ポートから出力され
たり、処理されずに出力ポートからそのまま出力された
りする。ネットワークにおけるこの形態（トポロジー）
の例としては、標準規格の“Token Ring /IEEE 802.5”
や“Fibre Channel”,“Scalable Coherent Interface
/IEEE 1596-1992” などがある。

【０００６】次に、各ノード間での通信、すなわちデー
タのやり取りが行われるときのパケットの流れ方につい
て、図２７を参照しながら説明する。

【０００７】図２７において、パケットＰＫは、ノード
１０１の入力部（入力ポート）１１１からノード１０１
に到達し、出力部（出力ポート）１１２から次のノード
へと出て行く。パケット用一時記憶領域部１０５は、入
力部１１１から入ってきたパケットを一時的に蓄積して
おき、自身のノード（自ノード）へのパケットなのか否
かを判断する部分であり、自身のノードに対するパケッ
トであれば、入力パケット用記憶領域部１０３へとパケ
ットが導かれる。自ノードに対するパケットでなけれ
ば、ネットワークを通して先のノードへと転送しなけれ
ばならないので、ＭＵＸ部１０６でマルチプレクス（セ
レクト）されて出力部１１２から出て行く。パケット用
一時記憶領域部１０５では、入力されたパケットのヘッ
ダ部の中に組み込まれているパケット発行先の識別子
（ターゲットＩＤ）をみることにより、自ノードへのパ
ケットなのか、他ノードへのパケットなのかを判断する
ことができる。

【０００８】入力パケット用記憶領域部１０３は、自ノ
ードに対するパケットを自ノードの中心的な処理部に送
り込むための一時記憶領域である。その先にはノード処
理部１０２があり、ノードを包括するネットワークと他
の処理系とをインタフェースする部分である。このノー
ド処理部１０２の機能としては、例えば、バス幅やバス
の信号レベル、バスプロトコル（規約）といったバスの
変換等が挙げられる。出力パケット用記憶領域部１０４
は、他の処理系からバス変換等が行われ、ノード処理部
１０２においてデータのパケット化が行われてから、そ
のパケットを出力の前段で一時的に蓄積するための部分
である。入力パケット用記憶領域部１０３は、自ノード
入力用の一時的な記憶領域であり、出力パケット記憶領
域１０４は、自ノード出力用の一時的な記憶領域であ
る。

【０００９】パケット用一時記憶領域部１０５、入力パ
ケット用記憶領域部１０３、出力パケット用記憶領域部
１０４の具体例としては、ＦＩＦＯ（First In First O
ut）メモリやキュー（Queue:待ち行列）などが挙げられ
る。また、パケット用一時記憶領域部１０５、入力パケ
ット用記憶領域部１０３、出力パケット用記憶領域部１
０４の大きさは、最低でも、そのネットワーク上でやり
取りされる最大パケットサイズを必要とする。

【００１０】次に、図２７で示した構成をさらに具体化
して、従来のノードにおける上記入力パケット用記憶領
域部及び出力パケット用記憶領域部となるキュー（待ち
行列）リソース（資源）の配置とその制御管理について
図２８で説明する。

【００１１】図２８において、リクエスト出力キュー１
３１及びレスポンス出力キュー１３２が上記出力パケッ
ト用記憶領域部１０４に、リクエスト入力キュー１３３
及びレスポンス入力キュー１３４が上記入力パケット用
記憶領域部１０３にそれぞれ対応する。また、上記ノー
ド処理部１０２として、リクエスタ１２１及びレスポン
ダ１２２が示され、これらのリクエスタ１２１及びレス
ポンダ１２２によって、他の処理系との間のクロック周
波数、データバス幅等の整合性がとられる。なお、上記
図２７に示したパケット用一時記憶領域部１０５は、入
力パケットのアドレスを解読（デコード）するパケット
アドレス解読（デコード）部１０５ａと、記憶部１０５
ｂとで示している。

【００１２】以下、これらのリクエスト出力キュー１３
１、レスポンス出力キュー１３２、リクエスト入力キュ
ー１３３、レスポンス入力キュー１３４の役割について
説明するが、ここで説明上の便宜のために、例えば、ノ
ードＮＡとノードＮＢの２つのノード間でデータのやり
取りを行うものとする。

【００１３】リクエスト出力キュー１３１は、ノードＮ
ＡがノードＮＢに対して、データのやり取りを行ないた
いというリクエストパケットをノードＮＡ内で生成した
ときに、その生成されたリクエストパケットが入力され
る記憶領域部である。すなわち、上記生成されたパケッ
トは、ノードＮＡ内のリクエスト出力キュー１３１を経
由、または、リクエスト出力キュー１３１に一時的に蓄
積されて、順次ノードＮＡ内のＭＵＸ部１０６に送り出
される。レスポンス出力キュー１３２は、データのやり
取りを行ないたいというリクエストパケットが送られて
きたときに、そのリクエストに対して応答（レスポン
ス）できるか否かを示したレスポンスパケットが入力さ
れる記憶領域部である。すなわち、ノードＮＡからの上
記リクエストパケットがノードＮＢに対して送られてき
たときに、そのリクエスト（データのやり取り）の対象
となるノードＮＢが、応答（レスポンス）できるか否か
を示したレスポンスパケットをノードＮＡに対して返す
際に、ノードＮＢ内でそのレスポンスパケットが生成さ
れ、レスポンス出力キュー１３２を経由、または、レス
ポンス出力キュー１３２に一時的に蓄積されてから、順
次ノードＮＢ内のＭＵＸ部１０６に送り出される。

【００１４】リクエスト入力キュー１３３は、ノードＮ
ＡがノードＮＢに対して、データのやり取りを行いたい
というリクエストパケットを発行したときに、ノードＮ
Ｂでは、その内部のパケットアドレス解読（デコード）
部１０５ａで、そのリクエストパケットがノードＮＢ
（自ノード）に対するものであることを判断したあと
で、ノードＮＢの処理の中心部に取り込む際に、そのリ
クエストパケットが経由、または、一時的に蓄積される
記憶領域部である。レスポンス入力キュー１３４は、他
のノードから自ノードに送られてきたレスポンスパケッ
トが入力される記憶領域部である。すなわち、ノードＮ
ＡがノードＮＢに対して、データのやり取りを行いたい
というリクエストパケットを発行すると、そのリクエス
トに対して応答（レスポンス）できるか否かを示したレ
スポンスパケットをノードＮＢがノードＮＡに対して発
行する。そのレスポンスパケットがノードＮＡ（自ノー
ド）に対するものであることをノードＮＡは内部のパケ
ットアドレス解読（デコード）部１０５ａで判断したあ
とで、ノードＮＡの処理の中心部に取り込む。その際に
そのレスポンスパケットが経由、または、一時的に蓄積
される記憶領域部がレスポンス入力キュー１３４であ
る。

【００１５】以上のリクエスト出力キュー１３１、レス
ポンス出力キュー１３２、リクエスト入力キュー１３
３、レスポンス入力キュー１３４の関係を、模式的に以
下の図２９に示す。ノードＮＡがノードＮＢに対してリ
クエスト（データやり取りの要求）を発行して、それに
対してノードＮＢが応答する様子を図２９の（ａ）に示
す。また、ノードＮＢがノードＮＡに対してリクエスト
（データのやり取りの要求）を発行して、それに対して
ノードＮＡが応答する様子、すなわち、リクエストとレ
スポンスの発行関係が逆の場合の様子を図２９の（ｂ）
に示す。

【００１６】すなわち、図２９の（ａ）においては、ノ
ードＮＡのリクエスト出力キュー１３１Ａを介してリク
エストパケットがノードＮＢのリクエスト入力キュー１
３３Ｂに送られ、これに対する応答であるレスポンスパ
ケットが、ノードＮＢのレスポンス出力キュー１３２Ｂ
を介してノードＮＡのレスポンス入力キュー１３４Ａに
送られている。また、図２９の（ｂ）においては、ノー
ドＮＢのリクエスト出力キュー１３１Ｂを介してリクエ
ストパケットがノードＮＡのリクエスト入力キュー１３
３Ａに送られ、これに対する応答であるレスポンスパケ
ットが、ノードＮＡのレスポンス出力キュー１３２Ａを
介してノードＮＢのレスポンス入力キュー１３４Ｂに送
られている。

【００１７】

【発明が解決しようとする課題】ところで、従来におい
ては、これら４種類のキュー（リクエスト出力キュー１
３１、レスポンス出力キュー１３２、リクエスト入力キ
ュー１３３、レスポンス入力キュー１３４）は、それぞ
れ、リクエスト出力用、レスポンス出力用、リクエスト
入力用、レスポンス入力用といった固有の用途・目的に
しか使用されていない。そのような構成では、例えば、
図２９の（ａ）のノードＮＡのようにデータの送出を行
なう頻度の高いノードにおいては、そのノード内のリク
エスト出力キュー１３１、および、レスポンス入力キュ
ー１３４は頻繁に使用される状態となるが、レスポンス
出力キュー１３２、および、リクエスト入力キュー１３
３はほとんど使用されない状態となる。また、図２９の
（ｂ）のノードＮＡのようにデータの受信を行なう頻度
の高いノードにおいては、そのノード内のリクエスト入
力キュー１３３、および、レスポンス出力キュー１３２
は頻繁に使用される状態となるが、リクエスト出力キュ
ー１３１、および、レスポンス入力キュー１３４はほと
んど使用されない状態となる。

【００１８】さらに、リクエストパケットに対してレス
ポンスパケットを必要としないデータのやり取りもある
ので、その場合に、データ送出を主に行なうノードで
は、リクエスト出力キュー１３１のみが頻繁に使用さ
れ、その他のレスポンス出力キュー１３２、リクエスト
入力キュー１３３、レスポンス入力キュー１３４はほと
んど使用されないことになり、データ受信を主に行なう
ノードでは、リクエスト入力キュー１３３のみが頻繁に
使用され、その他のリクエスト出力キュー１３１、レス
ポンス出力キュー１３２、レスポンス入力キュー１３４
はほとんど使用されないことになる。

【００１９】このような状況を考えるとネットワークシ
ステムにおいて、バランス良く通信されている場合は問
題ないが、例えば、ビデオオンデマンドをはじめとする
特にビデオ映像系のアプリケーションシステムにおいて
は、映像データを送出するノードであるコンピュータや
それに準ずる機器などの役割と、そのデータを受信する
ノードであるコンピュータやそれに準ずる機器などの役
割とが分担されることが多々ある。このような例におい
て、固定した役割を担うキュー構成では、上記キューの
リソース（資源）としてのバランスが悪いと言える。ま
た、キューは記憶ブロック（メモリ）であるので、不必
要に実装してしまうとコスト高にもつながる。しかしな
がら、頻繁に使用するキューを多めに実装し、あまり使
用しないキューを全く実装しない、または、ほとんど実
装しない、という構成を採用した場合では、そのノード
自身の役割が、データ送出専用ノード、データ受信専用
ノードなどと固定化されてしまい、変更が極めて困難で
ある。このような専用ノードの用途が変更された場合、
例えば、データ送信を主として行なう役割からデータ受
信を主として行なう役割へと変更された場合には、ノー
ド自身におけるデータ処理の性能低下、さらには、その
ノードが接続されたネットワークにおける通信効率の悪
化などの問題が生じることが明らかに予測される。

【００２０】本発明は、このような実情に鑑みてなされ
たものであり、ノード内部の処理パケットの入出力用に
使用されるキュー（待ち行列）の利用効率を高め、通信
効率を高めることができるようなデータ伝送装置及び方
法、並びにネットワークシステムの提供を目的とする。

【００２１】

【課題を解決するための手段】本発明に係るデータ伝送
装置は、上述した課題を解決するために、複数のノード
で構成されるネットワークの１つのノードとなるデータ
伝送装置において、パケットを処理するパケット処理手
段と、上記パケット処理手段における処理パケットが入
出力され複数パケットを記憶する容量を有し記憶された
ものが順次処理される記憶手段、いわゆるキュー（待ち
行列）と、上記記憶手段の入力用、出力用の割り当てを
変更制御する制御手段とを有することを特徴としてい
る。

【００２２】また、本発明に係るデータ伝送方法は、上
述した課題を解決するために、複数のノードで構成され
るネットワークのノード間でデータのパケットを伝送す
るためのデータ伝送方法において、上記ノードにおける
処理パケットの入出力状況に応じたノード情報を得るノ
ード情報取得工程と、得られたノード情報に応じて処理
パケットが入出力される記憶手段の入力用、出力用の割
り当てを制御する割当制御工程とを有することを特徴と
している。

【００２３】さらに、本発明に係るネットワークシステ
ムは、複数のノードで構成されるネットワークシステム
において、上記ノード内での処理パケットが入出力され
複数パケットを記憶する容量を有し記憶されたものが順
次処理される記憶手段と、上記記憶手段の入力用、出力
用の割り当てを変更制御する制御手段とを有することを
特徴としている。

【００２４】ノード内の処理パケットの記憶手段（キュ
ー）の入力用、出力用の割り当てを変更制御することに
よって、状況に応じて動的に割当を変更でき、記憶手段
であるキューリソースの利用効率を高め、通信効率を高
めることができる。

【００２５】

【発明の実施の形態】本発明に係るデータ伝送装置及び
方法の好ましい実施の形態について、図面を参照しなが
ら説明する。

【００２６】図１は、本発明の実施の形態となるデータ
伝送装置の概略構成を示すブロック図である。

【００２７】この図１において、データ伝送装置である
ノード１００は、通信経路を介して伝送されるパケット
ＰＫが入力される入力部（入力ポート）１１１と、通信
経路にパケットＰＫを出力する出力部（出力ポート）１
１２と、入力部１１１から入力されたパケットのアドレ
スを解読（デコード）して一時記憶するパケット用一時
記憶領域部１０５（パケットアドレス解読部１０５ａ及
び記憶部１０５ｂ）と、パケット一時記憶領域部１０５
と出力部１１２との間に挿入接続されたＭＵＸ部１０６
とを有し、さらに、入力パケットが自分のノード宛のも
のであるとき、そのパケットが入力され、またノード内
で生成されたパケットを出力する記憶領域部であるキュ
ーリソース１４０と、このキューリソース１４０との間
でパケットがやり取りされ、外部の他の処理系とのイン
ターフェース部分ともなるノード処理部１０２（リクエ
スタ１２１及びレスポンダ１２２）とを有して構成され
ている。ここで、メモリブロック等を用いた記憶領域部
であるキューリソース１４０が、従来の図２７や図２８
で示した入力パケット用記憶領域部１０３及び出力パケ
ット用記憶領域部１０４に対応するものであり、キュー
リソース制御部１５０からの制御信号により、リクエス
ト出力用領域１４１、レスポンス出力用領域１４２、リ
クエスト入力用領域１４３、レスポンス入力用領域１４
４が割当制御されるようになっている。

【００２８】このキューリソース１４０のリクエスト出
力用領域１４１、レスポンス出力用領域１４２、リクエ
スト入力用領域１４３及びレスポンス入力用領域１４４
は、上述した図２８のリクエスト出力キュー１３１、レ
スポンス出力キュー１３２、リクエスト入力キュー１３
３及びレスポンス入力キュー１３４にそれぞれ対応する
ものであり、同様な機能を有している。

【００２９】すなわち、リクエスト出力用領域１４１、
レスポンス出力用領域１４２、リクエスト入力用領域１
４３及びレスポンス入力用領域１４４の役割について、
例えば、ノードＮＡとノードＮＢの２つのノード間でデ
ータのやり取りを行うものとして説明すると、次のよう
になる。

【００３０】リクエスト出力用領域１４１は、ノードＮ
ＡがノードＮＢに対して、データのやり取りを行ないた
いというリクエストパケットをノードＮＡ内で生成した
ときに、その生成されたリクエストパケットが入力され
る記憶領域部である。すなわち、上記生成されたパケッ
トは、ノードＮＡ内のリクエスト出力用領域１４１を経
由、または、リクエスト出力用領域１４１に一時的に蓄
積されて、順次ノードＮＡ内のＭＵＸ部１０６に送り出
される。レスポンス出力用領域１４２は、データのやり
取りを行いたいというリクエストパケットが送られてき
たときに、そのリクエストに対して応答（レスポンス）
できるか否かを示したレスポンスパケットが入力される
記憶領域部である。すなわち、ノードＮＡからの上記リ
クエストパケットがノードＮＢに対して送られてきたと
きに、そのリクエスト（データのやり取り）の対象とな
るノードＮＢが、応答（レスポンス）できるか否かを示
したレスポンスパケットをノードＮＡに対して返す際
に、ノードＮＢ内でそのレスポンスパケットが生成さ
れ、レスポンス出力用領域１４２を経由、または、レス
ポンス出力用領域１４２に一時的に蓄積されてから、順
次ノードＮＢ内のＭＵＸ部１０６に送り出される。

【００３１】リクエスト入力用領域１４３は、ノードＮ
ＡがノードＮＢに対して、データのやり取りを行いたい
というリクエストパケットを発行したときに、ノードＮ
Ｂでは、その内部のパケットアドレス解読（デコード）
部１０５ａで、そのリクエストパケットがノードＮＢ
（自ノード）に対するものであることを判断したあと
で、ノードＮＢの処理の中心部に取り込む際に、そのリ
クエストパケットが経由、または、一時的に蓄積される
記憶領域部である。レスポンス入力用領域１４４は、他
のノードから自ノードに送られてきたレスポンスパケッ
トが入力される記憶領域部である。すなわち、ノードＮ
ＡがノードＮＢに対して、データのやり取りを行いたい
というリクエストパケットを発行すると、そのリクエス
トに対して応答（レスポンス）できるか否かを示したレ
スポンスパケットをノードＮＢがノードＮＡに対して発
行する。そのレスポンスパケットがノードＮＡ（自ノー
ド）に対するものであることをノードＮＡは内部のパケ
ットアドレス解読（デコード）部１０５ａで判断したあ
とで、ノードＮＡの処理の中心部に取り込む。その際に
そのレスポンスパケットが経由、または、一時的に蓄積
される記憶領域部がレスポンス入力用領域１４４であ
る。

【００３２】本発明の実施の形態においては、ノード１
００内部のパケットの入出力用に必要なキューリソース
１４０を一括管理し、キューリソース制御部１５０によ
り、その時々の状況に応じてキューリソース１４０をリ
クエストパケット出力用、レスポンスパケット出力用、
リクエストパケット入力用、レスポンスパケット入力用
の各領域１４１〜１４４のそれぞれに対して動的に割り
当てる。例えば、データ送出を行なう頻度の高いノード
では、リクエスト出力用領域１４１とレスポンス入力用
領域１４４にキューリソース１４０を多く割り当てるよ
うにし、また、レスポンスパケットを必要としないやり
取りの場合には、リクエスト出力用領域１４１にだけ多
めのキューリソース１４０を割り当て、その他のレスポ
ンス出力用領域１４２、リクエスト入力用領域１４３、
レスポンス入力用領域１４４には少なめのキューリソー
ス１４０を割り当てる。データ受信を行なう頻度の高い
ノードでは、リクエスト入力用領域１４３とレスポンス
出力用領域１４２にキューリソース１４０を多く割り当
てるようにし、また、レスポンスパケットを必要としな
いやり取りの場合には、リクエスト入力用領域１４３に
だけ多めのキューリソース１４０を割り当て、その他の
リクエスト出力用領域１４１、レスポンス出力用領域１
４２、レスポンス入力用領域１４４には少なめのキュー
リソースを割り当てる。このように、一括管理して、キ
ューリソース１４０を必要とする部分に対しては多く割
り当て、それほど必要としない部分に対しては少なく割
り当てる。このような操作をネットワークシステムにお
けるノードにおいて動的に変更して、常に通信効率の高
いネットワークシステムを実現することができる。

【００３３】以下、キューリソース１４０の割当制御の
具体例について、図面を参照しながら説明する。

【００３４】図２は、メモリであるキューリソース１４
０は、ポインタで指示される複数の記憶ブロック（以下
キューエントリという。）１４６から構成されており、
各キューエントリ（記憶ブロック）１４６は、所定の記
憶容量、すなわち、そのノードあるいはネットワークで
取り扱うことのできる最大のパケットサイズを有し、ポ
インタアドレスにより各キューエントリ１４６を区別し
て指示することができるようになっている。図２の例で
は、１６エントリ（１６ブロック）から成るキューリソ
ース１４０を示しており、ポインタアドレスは０〜１５
で、４ビットで表すことができる。

【００３５】この図２に示す実施の形態では、ポインタ
を使用することで、一括管理しているキューリソース１
４０をある程度のまとまり（キューエントリ１４６）ご
とに分割して、それらをリクエスト出力用、レスポンス
出力用、リクエスト入力用、レスポンス入力用にそれぞ
れ割り当てるている。制御部１５０は、ポインタ格納部
１５１を有し、このポインタ格納部１５１には、それぞ
れ、リクエスト出力用、レスポンス出力用、リクエスト
入力用、レスポンス入力用についての、カレントポイン
タ、割当開始ポインタ、割当終了ポインタの３種類のポ
インタを格納するための記憶部がある。割当開始ポイン
タ、割当終了ポインタには、割り当てたキューエントリ
１４６の先頭ポインタアドレスと終了ポインタアドレス
とを格納する。例えば、ポインタアドレス３から８が割
り当てられた場合には、割当開始ポインタに３が、割当
終了ポインタには８が格納される。４種類（リクエスト
出力用、レスポンス出力用、リクエスト入力用、レスポ
ンス入力用）の役割に応じて、ポインタアドレスがそれ
ぞれ設定格納される。この割当開始ポインタと割当終了
ポインタは、ある時点で設定され、その後もノードの状
況に応じて、逐次その設定が変更される。ただし、それ
らのポインタアドレスの開始から終了までが、別のポイ
ンタアドレスの開始から終了までと重なることがあって
はならない。

【００３６】カレントポインタには、ノードが実際に現
在参照しているキューエントリ１４６のアドレスポイン
タが格納される。このポインタの値は、例えば、割当開
始ポインタと同じ値からノードによってキューエントリ
１４６内のパケットデータが参照されるたびに、１ずつ
順番にインクリメント（＋１）されていき、割当終了ポ
インタと同じ値になったとき、再び、割当開始ポインタ
と同じ値になり、以降、同様の動作を繰り返す。これら
のポインタ格納用の部分はキューエントリの数に依存す
るが、この例では、キューエントリ１４６が１６個ある
ので各４ビットが必要となることから、ポインタ格納部
１５１全体では、 ４ビット×１２＝４８ビット＝６バイト の容量が必要ということになる。

【００３７】以下、図３〜図７にノードの役割例に応じ
た制御の様子を説明する。図３は、データ送受信を比較
的均等に行なっているノードにおける様子を、図４は、
データ送信を高い頻度で行なうノードで、レスポンスパ
ケットがある場合における様子を、図５は、データ受信
を高い頻度で行なうノードで、レスポンスパケットがあ
る場合における様子を、図６は、データ送信を高い頻度
で行なうノードで、レスポンスパケットが不要な場合に
おける様子を、図７は、データ受信を高い頻度で行なう
ノードで、レスポンスパケットが不要な場合における様
子をそれぞれ示している。

【００３８】図３においては、ポインタを使用したキュ
ーリソース１４０のブロック分割による割り当て方法に
よって、データの送受信を比較的均等に行なっている場
合のノード内キューリソース１４０の割り当ての様子を
示している。データの送信と受信の頻度が同じくらいな
ので、キューリソース１４０も均等に分割、制御する。
この図３の例では、リクエスト出力用、レスポンス出力
用、リクエスト入力用、レスポンス入力用の各領域１４
１，１４２，１４３，１４４にそれぞれ４エントリずつ
を割り当てている状態を表わしている。なお、図中の矢
印ＣＰは、カレントポインタの位置を示している。

【００３９】図４においては、ポインタを使用したキュ
ーリソース１４０のブロック分割による割り当て方法に
よって、データの送信を高い頻度で行なっている場合の
ノード内キューリソース１４０の割り当ての様子を示し
ている。データ送信の頻度が高いので、キューリソース
制御部１５０は、リクエスト出力用領域１４１とレスポ
ンス入力用領域１４４に多めのキューリソース１４０を
割り当てるように制御する。図４では、使用頻度の高い
リクエスト出力用領域１４１とレスポンス入力用領域１
４４に５エントリずつを、そして、使用頻度の低いリク
エスト入力用領域１４３とレスポンス出力用領域１４２
に３エントリずつをそれぞれ割り当てている状態を表わ
している。

【００４０】図５においては、ポインタを使用したキュ
ーリソース１４０のブロック分割による割り当て方法に
よって、データの受信を高い頻度で行なっている場合の
ノード内キューリソース１４０の割り当ての様子を示し
ている。データ受信の頻度が高いので、リクエスト入力
用とレスポンス出力用に多めのキューリソース１４０を
割り当て、制御する。図５では、使用頻度の高いリクエ
スト入力用領域１４３とレスポンス出力用領域１４２に
６エントリずつを、そして、使用頻度の低いリクエスト
出力用領域１４１とレスポンス入力用領域１４４に２エ
ントリずつをそれぞれ割り当てている状態を表わしてい
る。

【００４１】図６においては、ポインタを使用したキュ
ーリソース１４０のブロック分割による割り当て方法に
よって、データの送信を高い頻度で行なっている場合
で、かつ、リクエストパケットに対応するレスポンスパ
ケットが不要なやり取りを行なっている場合のノード内
キューリソース１４０の割り当ての様子を示している。
データ送信の頻度が高く、レスポンスパケットが不要な
ので、リクエスト出力用のみに多めのキューリソースを
割り当て、制御する。図６では、使用頻度の高いリクエ
スト出力用領域１４１に８エントリを、そして、使用頻
度の低いレスポンス入力用領域１４４に２エントリを、
リクエスト入力用領域１４３とレスポンス出力用領域１
４２に３エントリずつをそれぞれ割り当てている状態を
表わしている。

【００４２】図７においては、ポインタを使用したキュ
ーリソース１４０のブロック分割による割り当て方法に
よって、データの受信を高い頻度で行なっている場合
で、かつ、リクエストパケットに対応するレスポンスパ
ケットが不要なやり取りを行なっている場合のノード内
キューリソース１４０の割り当ての様子を示している。
データ受信の頻度が高く、レスポンスパケットが不要な
ので、リクエスト入力用のみに多めのキューリソースを
割り当て、制御する。図７では、使用頻度の高いリクエ
スト入力用領域１４３に７エントリを、そして、使用頻
度の低いリクエスト出力用領域１４１、レスポンス出力
用領域１４２、レスポンス入力用領域１４４にそれぞれ
３エントリずつを割り当てている状態を表わしている。

【００４３】以上の図２〜図７に示す具体例では、キュ
ーリソース１４０の各領域１４１〜１４４について、領
域毎のポインタアドレスが連続している場合を示してい
るが、領域毎のエントリが不連続であってもよい。この
ような領域を構成するエントリが不連続であるような例
について、図８〜図１３を参照しながら説明する。

【００４４】すなわち、図８はキューリソース１４０及
びキューリソース制御部１５０の構成を概略的に示して
おり、この図８の具体例では、ポインタを使用すること
で、一括管理しているキューリソース１４０の各エント
リを完全に分割して、それらをリクエスト出力用、レス
ポンス出力用、リクエスト入力用、レスポンス入力用に
それぞれ割り当てている。

【００４５】キューリソース制御部１５０内のポインタ
格納部１５２には、それぞれ、リクエスト出力用、レス
ポンス出力用、リクエスト入力用、レスポンス入力用の
ポインタ格納部があり、各入出力用に割り当てられたキ
ューエントリのポインタアドレスを格納する。ここで
は、全くの任意にキューエントリを割り当てることがで
きるようになっており、５ビットで構成される１つのポ
インタ格納部分（１５２ａ及び１５２ｂ）には、キュー
エントリのポインタアドレスが格納される。ポインタア
ドレスを格納する部分１５２ａに必要な容量は、この例
のようにキューリソース１４０が１６エントリの場合に
は４ビットであり、残りの１ビットの部分１５２ｂは、
そのポインタ格納部分に有効なポインタアドレスが格納
されているか否かを示す一種のフラグのために設けられ
ている。４種類（リクエスト出力用、レスポンス出力
用、リクエスト入力用、レスポンス入力用）の役割に応
じて、ポインタアドレスがそれぞれ設定格納されるので
あるが、この設定は、ある時点で行われ、その後もノー
ドの状況に応じて、逐次その設定が変更される。ただ
し、それらのポインタアドレスが重複して存在すること
があってはならない。

【００４６】このようなポインタ格納部１５２の容量は
キューエントリの数に依存するが、ここの例では、キュ
ーエントリが１６あるので各４ビットが必要となり、格
納されているポインタアドレスが有効か否かを示す１ビ
ットを含めると、ポインタ格納部全体では、 ５ビット×５２＝２６０ビット≒３３バイト の容量が必要ということになる。

【００４７】図８の例では、１つのポインタ格納部分
（５ビットの部分：１５２ａ及び１５２ｂ）を１つの入
出力用（リクエスト出力用、レスポンス出力用、リクエ
スト入力用、レスポンス入力用）に１３個ずつで合計５
２個設けているが、１３個としたのは、全キューリソー
スエントリの数が１６個であるのに対して、１つの入出
力用に割り当てることのできるキューリソースの最大数
を１３個とし、その他の３種類の入出力用には１個ずつ
を割り当てるという状況が可能になるように考えたから
である。もし、全キューリソースエントリ１６個に対し
て、１つの入出力用に割り当てることのできるキューリ
ソースの最大数を８個とした場合には、前述のポインタ
格納部分は、１つの入出力用には８個ずつを設けておけ
ば良いので、合計で８個×４種類＝３２個となり、した
がって、ポインタ格納部分のビット数は、 ５ビット×３２＝１６０ビット＝２０バイト となり、１つの入出力用に割り当てることのできるキュ
ーリソースの最大数を１３個から８個にすることによっ
て、ビット数の節約が可能になる。

【００４８】以下、図９〜図１３に、この具体例による
ノードの役割例に応じたキューリソース割当制御の様子
を説明する。図９では、データ送受信を比較的均等に行
なっているノードにおける様子を、図１０では、データ
送信を高い頻度で行なうノード(レスポンスパケットが
ある場合)における様子を、図１１では、データ受信を
高い頻度で行なうノード（レスポンスパケットがある場
合）における様子を、図１２では、データ送信を高い頻
度で行なうノード（レスポンスパケットが不要な場合）
における様子を、図１３では、データ受信を高い頻度で
行なうノード（レスポンスパケットが不要な場合）にお
ける様子をそれぞれ表わしている。

【００４９】先ず、図９の例においては、ポインタを使
用したキューリソース１４０の完全分割による割り当て
方法によって、データの送受信を比較的均等に行なって
いる場合のノード内キューリソース１４０の割り当ての
様子を示している。データの送信と受信の頻度が同じく
らいなので、キューリソース制御部１５０は、キューリ
ソース１４０を均等に分割、制御する。図９では、各キ
ュー割り当ては全くのバラバラであるが、合計で４エン
トリずつを割り当てている状態を表わしている。すなわ
ち、リクエスト出力用領域１４１としてポインタアドレ
スが「０」，「４」，「６」，「１４」の４エントリ
を、レスポンス出力用領域１４２としてポインタアドレ
スが「１」，「８」，「１０」，「１１」の４エントリ
を、リクエスト入力用領域１４３としてポインタアドレ
スが「２」，「９」，「１２」，「１５」の４エントリ
を、レスポンス入力用領域１４４としてポインタアドレ
スが「３」，「５」，「７」，「１３」の４エントリ
を、それぞれ割り当てている。

【００５０】図１０においては、ポインタを使用したキ
ューリソース１４０の完全分割による割り当て方法によ
って、データの送信を高い頻度で行っている場合のノー
ド内キューリソース１４０の割り当ての様子を示してい
る。データ送信の頻度が高いので、キューリソース制御
部１５０は、リクエスト出力用とレスポンス入力用に多
めのキューリソースを割り当て、制御する。図１０で
は、使用頻度の高いリクエスト出力用領域１４１とレス
ポンス入力用領域１４３にそれぞれ５エントリずつを、
そして、使用頻度の低いリクエスト入力用領域１４４と
レスポンス出力用領域１４２にそれぞれ３エントリずつ
を割り当てている状態を表わしている。

【００５１】図１１においては、ポインタを使用したキ
ューリソース１４０の完全分割による割り当て方法によ
って、データの受信を高い頻度で行っている場合のノー
ド内キューリソース１４０の割り当ての様子を示してい
る。データ受信の頻度が高いので、キューリソース制御
部１５０は、リクエスト入力用とレスポンス出力用に多
めのキューリソースを割り当て、制御する。図１１で
は、使用頻度の高いリクエスト入力用領域１４２とレス
ポンス出力用領域１４２にそれぞれ６エントリずつを、
そして、使用頻度の低いリクエスト出力用領域１４１と
レスポンス入力用領域１４４にそれぞれ２エントリずつ
を割り当てている状態を表わしている。

【００５２】図１２においては、ポインタを使用したキ
ューリソース１４０の完全分割による割り当て方法によ
って、データの送信を高い頻度で行っている場合で、か
つ、リクエストパケットに対応するレスポンスパケット
が不要なやり取りを行っている場合のノード内キューリ
ソース１４０の割り当ての様子を示している。データ送
信の頻度が高く、レスポンスパケットが不要なので、キ
ューリソース制御部１５０は、リクエスト出力用のみに
多めのキューリソースを割り当て、制御する。図１２で
は、使用頻度の高いリクエスト出力用領域１４１に１０
エントリを、そして、使用頻度の低いレスポンス出力用
領域１４２、リクエスト入力用領域１４３、レスポンス
入力用領域１４４にそれぞれ２エントリずつを割り当て
ている状態を表わしている。

【００５３】図１３においては、ポインタを使用したキ
ューリソース１４０の完全分割による割り当て方法によ
って、データの受信を高い頻度で行っている場合で、か
つ、リクエストパケットに対応するレスポンスパケット
が不要なやり取りを行っている場合のノード内キューリ
ソース１４０の割り当ての様子を示している。データ受
信の頻度が高く、レスポンスパケットが不要なので、リ
クエスト入力用のみに多めのキューリソースを割り当
て、制御する。図１３では、使用頻度の高いリクエスト
入力用領域１４３に１３エントリを、そして、使用頻度
の低いリクエスト出力用領域１４１、レスポンス出力用
領域１４２、レスポンス入力用領域１４４にそれぞれ１
エントリずつを割り当てている状態を表わしている。

【００５４】次に、上記図１、図２、図８に示したよう
なキューリソース制御部１５０の制御動作の例について
説明する。キューリソース制御部１５０は、その時々の
状況に応じてキューリソース１４０をリクエスト出力
用、レスポンス出力用、リクエスト入力用、レスポンス
入力用に動的に割当制御する。具体的には、例えば、リ
クエスト出力用パケット、レスポンス出力用パケット、
リクエスト入力用パケット、レスポンス入力用パケット
のそれぞれの量（パケット量）の情報に応じて、最もパ
ケット量が多いものに多くのキューリソースを割り当て
るように制御する。このパケット量等の制御のための情
報は、キューリソース１４０に入出力されるパケット量
を直接測定してもよいが、メモリであるキューリソース
１４０の上記各領域１４１，１４２，１４３，１４４に
対するアクセスの頻度から使用状況を判断することで得
るようにしてもよい。また、アプリケーション等により
当該ノードがどのような用途に使用されるかとか、デー
タの送信、受信のいずれが多くなるか等の情報に応じて
各領域の割当を制御するようにしてもよい。

【００５５】図１４は、キューリソースの上述したよう
なリクエスト出力用、レスポンス出力用、リクエスト入
力用、レスポンス入力用の各領域に対するメモリアクセ
スの頻度、より具体的にはメモリフル状態になったこと
の認識に応じて、各領域の割当を制御する動作の一例を
示すフローチャートである。

【００５６】すなわち、例えば図１のキューリソース制
御部１５０内において、キューリソース１４０の割り当
ての判断を行うための情報を生成し、それに基づいてキ
ューリソース１４０の割り当てを行う。キューリソース
制御部１５０では、キューリソース１４０の管理や割り
当てのためにポインタを使用しているので、これらのポ
インタ情報を利用することで、図１４に示したキューリ
ソース割り当てを行うための判断フローチャートに従っ
て、キューリソースの使用状況を認識し、どの部分のキ
ューエントリを減らして、どの部分のキューエントリを
増やすかを判断し、制御する。

【００５７】図１４は、例えば図２あるいは図８のキュ
ーリソース制御部１５０が、自身で管理しているリクエ
スト出力パケット用、レスポンス出力パケット用、リク
エスト入力パケット用、レスポンス入力パケット用の各
領域１４１〜１４４のポインタを参照し、それらの情報
をどのように判断して、キューリソース割り当てを変更
するのかを示した例である。図中において、比較の対象
となっているＭは、設定可能な値として定義している。
このＭの値を設定、格納する記憶部分が制御部内に設け
られる。この値は、固定値である場合も考えられるし、
また、プログラマブルで逐次設定変更可能である場合も
考えられる。

【００５８】図１４に示した処理手順を説明する。ま
ず、キューリソース制御部１５０は、ステップＳ１１に
おいて、自身で管理している各領域（キューブロッ
ク）、すなわちリクエスト出力用領域１４１、レスポン
ス出力用領域１４２、リクエスト入力用領域１４３、レ
スポンス入力用領域１４４のポインタとしてのリードポ
インタＲ１，Ｒ２，Ｒ３，Ｒ４、及びライトポインタＷ
１，Ｗ２，Ｗ３，Ｗ４を参照し、また、各領域の全エン
トリに有効なパケットが格納されているかどうかを示す
フルフラグＦ１，Ｆ２，Ｆ３，Ｆ４を参照する。これら
の情報は、全てキューリソース制御部１５０で把握され
ている。フルフラグＦ１，Ｆ２，Ｆ３，Ｆ４は、各領域
（キュー）がフルの状態かどうかを示すフラグでもあ
り、「１」がフル状態、「０」がフルで無い状態を示す
ものとする。

【００５９】ここで、図２、図３〜図７においては、カ
レントポインタＣＰとして説明しているが、具体的には
上記のノードがキューエントリからパケットを読み出す
エントリアドレスを示したリードポインタ（読み込みポ
インタ）Ｒとキューエントリにパケットを書き込むエン
トリアドレスを示したライトポインタ（書き込みポイン
タ）Ｗとがある。ステップＳ１２,Ｓ１７，Ｓ２１，Ｓ
２５では、参照したフルフラグＦ１，Ｆ２，Ｆ３，Ｆ４
の状態をみて、図１４の例では、値が「１」のフル状態
であるか否かを判別して、どのフラグもキューエントリ
の使用状況がフルの状態でなければ、現状の割り当てら
れているキューの使用状況が比較的バランスを保ってい
ると判断して、キューリソースの割り当てをやり直すこ
とは行わないでステップＳ１１に戻る。もし、フルの状
態の領域（キューブロック）がある場合には、リクエス
ト出力パケット用についてはステップＳ１３で、レスポ
ンス出力パケット用についてはステップＳ１８で、リク
エスト入力パケット用についてはステップＳ２２で、ま
た、レスポンス入力パケット用についてはステップＳ２
６で、それぞれの領域（キューブロック）がフル状態に
なった回数をカウントして、Ｎ１，Ｎ２，Ｎ３，Ｎ４の
値として記憶しておく。

【００６０】そして、これらの値Ｎ１，Ｎ２，Ｎ３，Ｎ
４のうちどれかが、上記設定値Ｍより大きくなったとき
（ステップＳＳ１４，Ｓ１９，Ｓ２３，Ｓ２７）、すな
わち、割り当てられた各キューエントリの使用状況がか
なりの確率で不足気味になっているという状況を示した
フル状態にＭ回以上なった場合に、現状のキューリソー
スの割り当て状況ではバランスがよくないと判断して、
その時のフル状態になる確率が極めて高かった領域（キ
ューブロック）に対して、さらに、キューリソースのエ
ントリを１つ増加（ステップＳ１５，Ｓ２０，Ｓ２４，
Ｓ２８でのインクリメント）している。

【００６１】次のステップＳ１６では、上記カウント値
Ｎ１，Ｎ２，Ｎ３，Ｎ４をリセットしている。これは、
上記エントリがインクリメントされたものについてのみ
行うようにしてもよい。次のステップＳ２９では、その
時点で、リードポインタ値Ｒ１，Ｒ２，Ｒ３，Ｒ４とラ
イトポインタ値Ｗ１，Ｗ２，Ｗ３，Ｗ４との差分Ｄ１，
Ｄ２，Ｄ３，Ｄ４を求め、ステップＳ３０でこれらの差
分Ｄ１，Ｄ２，Ｄ３，Ｄ４の中で最も小さい値Ｄmin を
求める。ステップＳ３１〜Ｓ３７では、上記最小値Ｄmi
n となるキューブロック、すなわち、現状割り当てられ
ているキューリソースをあまり使用していないと判断さ
れるキューブロックに対して、キューリソースのエント
リを１つ減らすようにする。

【００６２】図１４の例では、以上のような判断の流れ
によってキューリソースの割り当てを変更していき、そ
の結果、キューリソースの使用効率のよい、したがっ
て、通信効率の良いノードの実現が可能となり、そのよ
うなノードが接続されたネットワーク全体の通信効率が
改善される。

【００６３】図１４で示した判断の流れは、ノード内の
キューリソース制御部１５０自身が全て行ってもよい
し、あるいは、例えば、各キューブロックである各領域
１４１，１４２，１４３，１４４のフルフラグ情報を格
納する場所だけをキューリソース制御部１５０内に設け
て、ホスト（ＣＰＵ）側から、それらの値を読みとるこ
とにより、どのキューエントリを増やし、どのキューエ
ントリを減らすかをＣＰＵ（ソフトウェア）で判断して
キューリソース制御部１５０内のポインタ格納部、すな
わち、図２、図３〜図７のポインタ格納部１５１や、図
８、図９〜図１３でのポインタ格納部１５２に対して適
切な設定を行う、という手法も考えられる。すなわち、
本発明の実施の形態で示されたキューリソース制御部１
５０のハードウェアが全ての処理、すなわち、フルフラ
グ情報の提供、フルフラグ情報からの判断、キューリソ
ースの割り当て決定、キューリソースの割り当て作業等
を行う場合もあるし、キューリソース制御部１５０が、
フルフラグ情報の提供とキューリソースの割り当て作業
を行い、ソフトウェア（ＣＰＵ）が、フルフラグ情報か
らの判断とキューリソース割り当て決定を行うという分
担の手法も考えられる。その際に、少なくともキューリ
ソース制御部１５０は、各フルフラグ（リクエスト出力
パケット用、レスポンス出力パケット用、リクエスト入
力パケット用、レスポンス入力パケット用）の情報を格
納する場所（記憶領域）をその内部に設けて、外部（ホ
スト側）から参照できるようになっていることが必要で
ある。

【００６４】図１４において、キューリソース制御部１
５０の参照対象となるフルフラグの考え方について、以
下の図１５〜図１７に説明する。説明の簡略化のため
に、以下の例では、キューエントリ数を３として説明す
る。

【００６５】図１５〜図１７において、キューリソース
制御部内部で管理するポインタとして、リードポインタ
Ｒ、及びライトポインタＷがあり、その他に、各キュー
ブロック（上記各領域１４１，１４２，１４３，１４
４）のキューエントリ消費状態を示すフラグとして、フ
ル状態を示すフルフラグ（Full_Flag） 及び空（エンプ
ティ）状態を示すエンプティフラグ（Empty_Flag）があ
る。

【００６６】初期状態では、図１５の（ａ）に示すよう
に、キューエントリには全く有効なパケットが格納され
ていないので、リードポインタＲとライトポインタＷは
同じキューエントリを指し示しており、フルフラグは
０、エンプティフラグは「１」となっている。エンプテ
ィフラグが「１」であるということは、キューエントリ
がエンプティ（空）であることを示している。この状態
から、図１５の（ｂ）〜（ｅ）に示すように、キューリ
ソースに対して有効なパケットが書き込まれるたびにラ
イトポインタＷは１つずつインクリメントされる。キュ
ーエントリがエンプティ（空）でなくなるとエンプティ
フラグは１から０に変更される。図１５の（ｂ）はキュ
ーエントリに１つの有効パケットが書き込まれた状態
を、図１５の（ｃ）はパケットの書き込みが完了してラ
イトポインタＷが１だけインクリメントされた状態を、
図１５の（ｄ）はキューエントリにさらに１つの有効パ
ケットが書き込まれた状態を、図１５の（ｅ）はパケッ
トの書き込みが完了してライトポインタＷがさらに１だ
けインクリメントされた状態をそれぞれ示している。

【００６７】次に、有効なパケットがキューエントリ内
に入っている時に、それらをノードが参照して読み出す
たびに、図１６の（ｆ）〜（ｉ）に示すように、リード
ポインタは１つずつデクリメントされる。図１６の
（ｆ）はキューエントリから１つの有効パケットが読み
出された状態を、図１６の（ｇ）はパケットの読み出し
が完了してリードポインタＲが１だけデクリメントされ
た状態を、図１６の（ｈ）はキューエントリからさらに
１つの有効パケットが読み出された状態を、図１６の
（ｉ）はパケットの読み出しが完了してリードポインタ
Ｒがさらに１だけデクリメントされた状態をそれぞれ示
している。図１６の（ｉ）では、読み出しが完了した状
態でキューエントリがエンプティ（空）となるため、エ
ンプティフラグは「０」から「１」に変更される。

【００６８】リードポインタＲもライトポインタＷも一
通り進むと最終的には元の位置を指し示すことになり、
リング上に際限なくそのインクリメント、デクリメント
が繰り返される。例えば、図１６の（ｊ）に示すよう
に、ライトポインタＷが３つめのキューエントリを指示
しているときに１つの有効パケットが書き込まれると、
書き込みが完了した図１７の（ｋ）では、ライトポイン
タＷは１だけインクリメントされることにより１つめの
キューエントリを指示することになる。

【００６９】また、リードポインタＲは、ライトポイン
タＷを追い越すことはなく、ライトポインタＷも、次々
に有効なパケットがキューエントリ内に書き込まれて先
に進んで行ってもリードポインタＲを追い越すことはな
い。そして、次々に有効なパケットがキューエントリ内
に書き込まれ、全てのエントリに有効なパケットが格納
された状態になると、リードポインタＲとライトポイン
タＷは再び同じキューエントリを指し示すことになり、
さらに、フルフラグを「０」から「１」に変更する。す
なわち、エンプティフラグが０（キューエントリは空の
状態でない）で、しかも、リードポインタＲとライトポ
インタＷが同じエントリ位置を指し示したときは、フル
フラグを「１」とする。フルフラグが「１」（キューエ
ントリがフルの状態）である間は、それ以降には新たな
パケットをキューエントリ内に書き込むことはできな
い。

【００７０】例えば、図１７の（ｌ）でキューエントリ
にさらに１つの有効パケットが書き込まれ、図１７の
（ｍ）でライトポインタＷが１だけインクリメントさ
れ、図１７の（ｎ）でキューエントリにさらに１つの有
効パケットが書き込まれ、図１７の（ｏ）でライトポイ
ンタＷがさらに１だけインクリメントされて、リードポ
インタＲと同じ位置を指示するようになると、フルフラ
グが「０」から「１」に変更される。

【００７１】上述したキューリソース制御部１５０で
は、このようなフラグを装備し、管理することで、図１
４に示したようなフローにおいて、本発明におけるキュ
ーリソースの割り当てを実現することが可能となる。

【００７２】次に、上記図１、図２、図８に示すキュー
リソース１４０の各領域、すなわちリクエスト出力用領
域１４１、レスポンス出力用領域１４２、リクエスト入
力用領域１４３及びレスポンス入力用領域１４４に対し
て入出力されるそれぞれのパケット量を検出し、これら
の各パケット量（リクエスト出力用パケット量、レスポ
ンス出力用パケット量、リクエスト入力用パケット量、
レスポンス入力用パケット量）の情報に応じて、最もパ
ケット量が多いものに多くのキューリソースを割り当て
るように制御する場合の具体例について説明する。

【００７３】図１８は、上記図１の構成に、パケット量
測定部１６０を付加した例を示している。このパケット
量測定部１６０で測定されたパケット量情報がキューリ
ソース制御部１５０に送られ、キューリソース制御部１
５０では、このパケット量情報に応じて、キューリソー
ス１４０のリクエスト出力用領域１４１、レスポンス出
力用領域１４２、リクエスト入力用領域１４３及びレス
ポンス入力用領域１４４の割り当てを制御している。

【００７４】パケット量測定部１６０は、リクエスト出
力パケット測定用カウンタ１６１、レスポンス出力パケ
ット測定用カウンタ１６２、リクエスト入力パケット測
定用カウンタ１６３、レスポンス入力パケット測定用カ
ウンタ１６４を有し、リクエスト出力パケット測定用カ
ウンタ１６１及びレスポンス出力パケット測定用カウン
タ１６２、リクエスト入力パケット測定用カウンタ１６
３及びレスポンス入力パケット測定用カウンタ１６４に
はタイマ１６５からのタイマ情報がそれぞれ供給されて
いる。

【００７５】キューリソース制御部１５０は、パケット
量測定部１６０のリクエスト出力パケット測定用カウン
タ１６１、レスポンス出力パケット測定用カウンタ１６
２、リクエスト入力パケット測定用カウンタ１６３、レ
スポンス入力パケット測定用カウンタ１６４から、タイ
マ１６５によって提供される一定時間内にその経路を通
過する各パケット数の測定値を受け取る。その受け取っ
たパケット量（測定値）情報に基づいて、キューリソー
スの割当を動的に行い、経路を通過するパケット数が多
い場合には、キューリソースを多く割り当て、少ない場
合には少なく割り当てる。

【００７６】パケット量測定部１６０のリクエスト出力
パケット測定用カウンタ１６１、レスポンス出力パケッ
ト測定用カウンタ１６２、リクエスト入力パケット測定
用カウンタ１６３、レスポンス入力パケット測定用カウ
ンタ１６４における具体的な測定方法としては、経路を
流れるパケットそのものかどうかを示すフラグ（信号）
を正確に観測する方法や、パケットサイズ等の各種情報
が書き込んであるヘッダ部を観測する方法、あるいは、
近似的ではあるが、パケットの数を実際にカウントする
方法などが考えられる。さらに、これらのカウンタ１６
１〜１６４はノード１００の内部にあり、ノード１００
の実現の仕方（インプリメント）に自由度があるので、
パケットであることを判断する方法はインプリメントに
依存しても問題ない。

【００７７】図１９は、パケット量測定部１６０からリ
クエスト出力パケット量、レスポンス出力パケット量、
リクエスト入力パケット量、レスポンス入力パケット量
の情報を受け取ったキューリソース制御部１５０が、ど
のように判断して、キューリソース割り当てを変更する
のかを示した例である。図中において、比較の対象とな
っているＬ，Ｍは、設定可能な値として定義している。
これらのＬ，Ｍの値を設定、格納する記憶部分がキュー
リソース制御部１５０に設けられる。これらの値は、固
定値である場合も考えられるし、また、プログラマブル
で逐次設定変更可能である場合も考えられる。

【００７８】図１９のフローチャートの動作を以下に説
明する。まず、図１８のキューリソース制御部１５０
は、ステップＳ４１において、パケット量測定部１６０
からリクエスト出力パケット量、レスポンス出力パケッ
ト量、リクエスト入力パケット量、レスポンス入力パケ
ット量の情報を定期的に受け取り、ステップＳ４２にて
その４つの値の中の最大値Ｒmax と最小値Ｒmin をそれ
ぞれ比較して求める。次のステップＳ４３で最大値Ｒma
x と最小値Ｒmin との差分（Ｒmax−Ｒmin）を計算し、
ステップＳ４４でこの差分（Ｒmax−Ｒmin）が上記設定
値Ｌ以上か否かを判別する。差分（Ｒmax−Ｒmin）が設
定値Ｌよりも小さい場合には、現状の割り当てられてい
るキューの使用状況が比較的バランスを保っていると判
断して、キューリソースの割り当てし直すことを行わな
いでステップＳ４１に戻る。差分が設定値Ｌよりも大き
い場合には、ステップＳ４５，Ｓ５０，Ｓ５４により、
その時の最大値が、リクエスト出力パケット量、レスポ
ンス出力パケット量、リクエスト入力パケット量、レス
ポンス入力パケット量のどれであったかをチェックし
て、ステップＳ４６，Ｓ５１，Ｓ５５，Ｓ５８により、
それぞれが最大値になった回数をカウントして、Ｎ１、
Ｎ２、Ｎ３、Ｎ４の値として記憶しておく。

【００７９】そして、ステップＳ４７，Ｓ５２，Ｓ５
６，Ｓ５９において、これらの値Ｎ１、Ｎ２、Ｎ３、Ｎ
４のうちどれかが設定値Ｍよりも大きくなったとき、す
なわち、各パケット量の最大値Ｒmax と最小値Ｒmin の
差分が一定値Ｌ以上にＭ回以上になった場合に、現状の
キューリソースの割り当て状況ではバランスが良くない
と判断して、その時の最大値Ｒmax であったキュー担当
ブロック（上記各領域１４１，１４２，１４３，１４
４）に対して、さらにキューリソースのエントリを１つ
増加（ステップＳ４８，Ｓ５３，Ｓ５７，Ｓ６０で該当
するエントリをインクリメント）する。次のステップＳ
４９では、上記カウント値Ｎ１，Ｎ２，Ｎ３，Ｎ４をリ
セットしている。これは、上記エントリがインクリメン
トされたものについてのみ行うようにしてもよい。ステ
ップＳ６１〜Ｓ６７では、上記最小値Ｒmin となるキュ
ーブロック、すなわち、現状割り当てられているキュー
リソースをあまり使用していないと判断されるキューブ
ロックに対して、キューリソースのエントリを１つ減ら
すようにする。

【００８０】図１９の例では、以上のような判断の流れ
によって、キューリソースの割り当てを変更していき、
その結果、キューリソースの使用効率の良い、したがっ
て、通信効率の良いノードの実現が可能となり、そのよ
うなソードが接続されたネットワーク全体の通信行率が
改善される。

【００８１】図１９で示した判断の流れは、ノード内の
制御部自身が全て行ってもよいし、あるいは、例えば、
各パケット量（リクエスト出力パケット量、レスポンス
出力パケット量、リクエスト入力パケット量、レスポン
ス入力パケット量）の情報を格納する場所だけをキュー
リソース制御部１５０内に設けて、ホスト（ＣＰＵ）側
から、それらの値を読みとることにより、どのキューを
増やし、どのキューを減らすかをＣＰＵ（ソフトウェ
ア）で判断してキューリソース制御部内のポインタ格納
部、すなわち図２のポインタ格納部１５１や図８のポイ
ンタ格納部１５２や、または、後述する複数エントリの
接続状態を切り換える方式における図２０のセレクタ制
御部１５５に対して、適切な設定を行うという手法も考
えられる。すなわち、本発明の実施の形態で示されたキ
ューリソース制御部１５０がハードウェア的に全ての処
理であるパケット量情報の提供、パケット量情報からの
判断、キューリソ−スの割り当て決定、キューリソース
の割り当て作業等を行う場合もあるし、キューリソース
制御部１５０が、パケット量情報の提供とキューリソー
スの割り当て作業を行い、ソフトウェア（ＣＰＵ）が、
パケット量情報からの判断とキューリソース割り当て決
定を行うという分担の手法も考えられる。その際に、少
なくともキューリソース制御部１５０は、各パケット量
（リクエスト出力パケット量、レスポンス出力パケット
量、リクエスト入力パケット量、レスポンス入力パケッ
ト量）の情報を格納する場所（記憶領域）をその内部に
設けて、外部（ホスト側）から参照できるようになって
いなければならない。

【００８２】次に、図２０には、さらに別の具体例を示
している。この図２０に示す例では、セレクタ、あるい
は、スイッチマトリクスにより、キューリソース１４０
として一括管理されたエントリＱ₁₁〜Ｑ₄₄を組み替える
ことで、リクエスト出力用、レスポンス出力用、リクエ
スト入力用、レスポンス入力用にそれぞれキューリソー
ス１４０を割り当てている。

【００８３】この図２０の例において、キューリソース
１４０の割り当ては、最大で１０エントリ、最低でも２
エントリとなる。図２０の例では、リクエスト出力用、
レスポンス出力用、リクエスト入力用、レスポンス入力
用に平均して４エントリずつ割り当てて配置した状態か
ら、データ送信の頻度が高い場合にはリクエスト出力用
とレスポンス入力用、または、リクエスト出力用のみに
対してキューリソースを多めに割り当てられるように、
データ受信の頻度が高い場合にはリクエスト入力用とレ
スポンス出力用、または、リクエスト入力用のみに対し
てキューリソースを多めに割り当てられるように、セレ
クタＳＥＬ、もしくは、スイッチマトリクス部分を配置
する。それらのセレクタ、もしくは、スイッチマトリク
スを、セレクタ制御部１５５から制御して、ノードの役
割に応じたキューリソース１４０の各エントリＱ₁₁〜Ｑ
₄₄の組み替えを行うことで、効率の良いノード間通信が
可能となり、したがって、ネットワーク全体の通信効率
も改善される。

【００８４】図２１〜図２５に、この図２０の構成例に
よるノードの役割の具体例に応じた制御の様子を説明す
る。図２１では、データ送受信を比較的均等に行なって
いるノードにおける様子を、図２２では、データ送信を
高い頻度で行なうノード（レスポンスパケットがある場
合）における様子を、図２３では、データ受信を高い頻
度で行なうノード（レスポンスパケットがある場合）に
おける様子を、図２４では、データ送信を高い頻度で行
なうノード（レスポンスパケットが不要な場合）におけ
る様子を、図２５では、データ受信を高い頻度で行なう
ノード（レスポンスパケットが不要な場合）における様
子をそれぞれ表わしている。

【００８５】図２１には、セレクタＳＥＬの切換制御に
よるキューリソース１４０の各エントリＱ₁₁〜Ｑ₄₄の組
み替えによって、データの送受信を比較的均等に行なっ
ている場合のノード内キューリソース１４０の割り当て
の様子を示している。データの送信と受信の頻度が同じ
くらいなので、キューリソースも均等になるように組み
替える。図２１では、太線で示された矢印が選択制御さ
れて組み替えられたパス（経路）であり、それぞれ４エ
ントリずつを割り当てている状態を表わしている。すな
わち、リクエスト出力用にエントリＱ₁₁〜Ｑ₁₄が、レス
ポンス出力用にエントリＱ₂₁〜Ｑ₂₄が、リクエスト入力
用にエントリＱ₃₁〜Ｑ₃₄が、またレスポンス入力用にエ
ントリＱ₄₁〜Ｑ₄₄がそれぞれ割り当てられるように制御
される。

【００８６】図２２には、セレクタ制御によるキューリ
ソースの組み替え方法によって、データの送信を高い頻
度で行なっている場合のノード内キューリソース１４０
の割り当ての様子を示している。データ送信の頻度が高
いので、リクエスト出力用とレスポンス入力用に多めの
キューリソースを割り当てるように組み替え、制御す
る。図２２では、太線で示された矢印が選択制御されて
組み替えられたパス（経路）であり、使用頻度の高いリ
クエスト出力用とレスポンス入力用に６エントリずつ
を、そして、使用頻度の低いリクエスト入力用とレスポ
ンス出力用に２エントリずつを割り当てている状態を表
わしている。

【００８７】図２３には、セレクタ制御によるキューリ
ソースの組み替え方法によって、データの受信を高い頻
度で行なっている場合のノード内キューリソース１４０
の割り当ての様子を示している。データ受信の頻度が高
いので、リクエスト入力用とレスポンス出力用に多めの
キューリソースを割り当てるように組み替え、制御す
る。図２３では、太線で示された矢印が選択制御されて
組み替えられたパス（経路）であり、使用頻度の高いリ
クエスト入力用とレスポンス出力用に６エントリずつ
を、そして、使用頻度の低いリクエスト出力用とレスポ
ンス入力用に２エントリずつを割り当てている状態を表
わしている。

【００８８】図２４には、セレクタ制御によるキューリ
ソースの組み替え方法によって、データの送信を高い頻
度で行なっている場合で、かつ、リクエストパケットに
対応するレスポンスパケットが不要なやり取りを行なっ
ている場合のノード内キューリソース１４０の割り当て
の様子を示している。データ送信の頻度が高く、レスポ
ンスパケットが不要なので、リクエスト出力用のみに多
めのキューリソースを割り当てるように組み替え、制御
する。図２４では、太線で示された矢印が選択制御され
て組み替えられたパス（経路）であり、使用頻度の高い
リクエスト出力用に１０エントリを、そして、使用頻度
の低いレスポンス出力用、リクエスト入力用、レスポン
ス入力用に２エントリずつを割り当てている状態を表わ
している。

【００８９】図２５には、セレクタ制御によるキューリ
ソースの組み替え方法によって、データの受信を高い頻
度で行なっている場合で、かつ、リクエストパケットに
対応するレスポンスパケットが不要なやり取りを行なっ
ている場合のノード内キューリソース１４０の割り当て
の様子を示している。データ受信の頻度が高く、レスポ
ンスパケットが不要なので、リクエスト入力用のみに多
めのキューリソースを割り当てるように組み替え、制御
する。図２５では、太線で示された矢印が選択制御され
て組み替えられたパス（経路）であり、使用頻度の高い
リクエスト入力用に１０エントリを、そして、使用頻度
の低いリクエスト出力用、レスポンス出力用、レスポン
ス入力用に２エントリずつを割り当てている状態を表わ
している。

【００９０】以上説明したような本発明の実施の形態に
よれば、キューが記憶ブロック（メモリ）であることか
ら、そのキューリソースを効率良く使用することによっ
て、必要最小限のキューサイズで足りることになり、ノ
ード内部をＩＣ（集積回路）化したときには、そのダイ
サイズを小さくすることができる。したがって、ＩＣの
小型化、省コスト、省スペースなどの利点が期待でき
る。また、従来と同じ容量のキューを実装した場合で
も、ノード間の通信効率、さらには、ネットワーク全体
の通信効率において、従来よりも改善される。

【００９１】

【発明の効果】以上の説明から明らかなように、本発明
によれば、複数のノードで構成されるネットワークの１
つのノードにおいて、パケット処理手段における処理パ
ケットが入出力され複数パケットを記憶する容量を有し
記憶されたものが順次処理される記憶手段、いわゆるキ
ュー（待ち行列）の入力用、出力用の割り当てを動的に
変更制御することにより、状況に応じて動的に上記記憶
手段であるキューリソースの割当を変更でき、キューリ
ソースの利用効率を高め、通信効率を高めることができ
る。

【００９２】すなわち、例えば、データ送出を行なう頻
度の高いノードでは、リクエストパケット出力用とレス
ポンスパケット入力用にキューリソースを多く割り当
て、データ受信を行なう頻度の高いノードでは、リクエ
ストパケット入力用とレスポンスパケット出力用にキュ
ーリソースを多く割り当てる。このように、一括管理し
て、キューリソースを必要とする部分に対しては多く割
り当て、それほど必要としない部分に対しては少なく割
り当て、キューリソースを効率良く使用することによっ
て、必要最小限のキューサイズで足りることになり、ノ
ード内部をＩＣ（集積回路）化したときには、そのダイ
サイズを小さくすることができる。したがって、ＩＣの
小型化、省コスト、省スペースなどの利点が期待でき
る。また、従来と同じ容量のキューを実装した場合で
も、ノード間の通信効率、さらには、ネットワーク全体
の通信効率において、従来よりも改善される。

【図面の簡単な説明】

【図１】本発明に係る実施の形態となるデータ伝送装置
の概略構成を示すブロック図である。

【図２】複数エントリから成るキューリソースをポイン
タを用いて割当制御を行うための構成の一例を示す図で
ある。

【図３】データの送受信が均等な場合の図２のキューリ
ソースの割当の様子の具体例を示す図である。

【図４】データの送信の頻度が高い場合の図２のキュー
リソースの割当の様子の具体例を示す図である。

【図５】データの受信の頻度が高い場合の図２のキュー
リソースの割当の様子の具体例を示す図である。

【図６】データの送信の頻度が高く、レスポンスパケッ
トが無い場合の図２のキューリソースの割当の様子の具
体例を示す図である。

【図７】データの受信の頻度が高く、レスポンスパケッ
トが無い場合の図２のキューリソースの割当の様子の具
体例を示す図である。

【図８】複数エントリから成るキューリソースをポイン
タを用いて割当制御を行うための構成の他の例を示す図
である。

【図９】データの送受信が均等な場合の図８のキューリ
ソースの割当の様子の具体例を示す図である。

【図１０】データの送信の頻度が高い場合の図８のキュ
ーリソースの割当の様子の具体例を示す図である。

【図１１】データの受信の頻度が高い場合の図８のキュ
ーリソースの割当の様子の具体例を示す図である。

【図１２】データの送信の頻度が高く、レスポンスパケ
ットが無い場合の図８のキューリソースの割当の様子の
具体例を示す図である。

【図１３】データの受信の頻度が高く、レスポンスパケ
ットが無い場合の図８のキューリソースの割当の様子の
具体例を示す図である。

【図１４】キューリソースの各領域の使用状況に応じて
キューリソース割当を行うための動作を説明するための
フローチャートである。

【図１５】キューリソースの各領域のライトポインタ及
びリードポインタの移動及びフラグの変化を説明するた
めの図である。

【図１６】キューリソースの各領域のライトポインタ及
びリードポインタの移動及びフラグの変化を説明するた
めの図１５に続く図である。

【図１７】キューリソースの各領域のライトポインタ及
びリードポインタの移動及びフラグの変化を説明するた
めの図１６に続く図である。

【図１８】本発明の他の実施の形態として、ノード内の
処理パケットの入出力量を測定してキューリソース割当
を行うデータ伝送装置の概略構成を示すブロック図であ
る。

【図１９】ノード内の処理パケットの入出力状況に応じ
てキューリソース割当を行うための動作を説明するため
のフローチャートである。

【図２０】セレクタ制御によるキューリソースの割当制
御を行うための構成の一例を示す図である。

【図２１】データの送受信が均等な場合の図２０のキュ
ーリソースの割当の様子の具体例を示す図である。

【図２２】データの送信の頻度が高い場合の図２０のキ
ューリソースの割当の様子の具体例を示す図である。

【図２３】データの受信の頻度が高い場合の図２０のキ
ューリソースの割当の様子の具体例を示す図である。

【図２４】データの送信の頻度が高く、レスポンスパケ
ットが無い場合の図２０のキューリソースの割当の様子
の具体例を示す図である。

【図２５】データの受信の頻度が高く、レスポンスパケ
ットが無い場合の図２０のキューリソースの割当の様子
の具体例を示す図である。

【図２６】複数のノードで構成されるネットワーク環境
の一例を示す図である。

【図２７】各ノード間で通信が行われるときのパケット
の流れ方を説明するための図である。

【図２８】ノード内部の入出力パケット用記憶領域部を
具体化した概略構成の例を示す図である。

【図２９】入力／出力キューと、リクエスト／レスポン
スパケットの関係を説明するための図である。

【符号の説明】

１００ ノード、 １０２ ノード処理部、 １０３
入力パケット用記憶領域部、 １０４ 出力パケット用
記憶領域部、 １０５ パケット用一時記憶領域部、
１０６ ＭＵＸ部、 １１１ 入力部、 １１２ 出力
部、 １４０キューリソース、 １４１ リクエスト出
力用領域、 １４２ レスポンス出力用領域、 １４３
リクエスト入力用領域、 １４４ レスポンス入力用
領域、１５０ キューリソース制御部、 １５１，１５
２ ポインタ格納部

───────────────────────────────────────────────────── フロントページの続き (72)発明者 遠藤 政士 東京都品川区北品川６丁目７番35号 ソニ ー株式会社内 (72)発明者 林 伸二 東京都品川区北品川６丁目７番35号 ソニ ー株式会社内

Claims (11)

【特許請求の範囲】
1. 【請求項１】 複数のノードで構成されるネットワーク
   の１つのノードとなるデータ伝送装置において、 パケットを処理するパケット処理手段と、 上記パケット処理手段における処理パケットが入出力さ
   れ複数パケットを記憶する容量を有し記憶されたものが
   順次処理される記憶手段と、 上記記憶手段の入力用、出力用の割り当てを変更制御す
   る制御手段とを有することを特徴とするデータ伝送装
   置。
2. 【請求項２】 上記制御手段は、上記記憶手段を、リク
   エストパケット出力用領域と、レスポンスパケット出力
   用領域と、リクエストパケット入力用領域と、レスポン
   スパケット入力用領域とにそれぞれ割当制御することを
   特徴とする請求項１記載のデータ伝送装置。
3. 【請求項３】 上記記憶手段に対して入出力される入力
   データ量及び出力データ量を測定するデータ量測定手段
   をさらに有し、 上記制御手段は、このデータ量測定手段からの測定デー
   タ量に応じて上記記憶手段の割当を制御することを特徴
   とする請求項１記載のデータ伝送装置。
4. 【請求項４】 上記記憶手段は、パケット記憶単位とな
   るエントリを複数有し、 上記制御手段は、上記記憶手段の各エントリを指示する
   ポインタ格納するポインタ格納部を有し、このポインタ
   格納部のポインタを用いて、上記記憶手段をリクエスト
   パケット出力用領域と、レスポンスパケット出力用領域
   と、リクエストパケット入力用領域と、レスポンスパケ
   ット入力用領域とにそれぞれ割当制御することを特徴と
   する請求項１記載のデータ伝送装置。
5. 【請求項５】 上記記憶手段は、パケット記憶単位とな
   る複数のエントリと、これらのエントリの接続状態を切
   り換えるセレクタとを有し、 上記制御手段は、上記記憶手段の上記セレクタを切換制
   御することで各エントリの接続状態を切り換えて、上記
   記憶手段をリクエストパケット出力用領域と、レスポン
   スパケット出力用領域と、リクエストパケット入力用領
   域と、レスポンスパケット入力用領域とにそれぞれ割当
   制御することを特徴とする請求項１記載のデータ伝送装
   置。
6. 【請求項６】 上記ネットワークは、複数のノードをリ
   ング状に接続してなるリングネットワークであることを
   特徴とする請求項１記載のデータ伝送装置。
7. 【請求項７】 複数のノードで構成されるネットワーク
   のノード間でデータのパケットを伝送するためのデータ
   伝送方法において、 上記ノードにおける処理パケットの入出力状況に応じた
   ノード情報を得るノード情報取得工程と、 得られたノード情報に応じて処理パケットが入出力され
   る記憶手段の入力用、出力用の割り当てを制御する割当
   制御工程とを有することを特徴とするデータ伝送方法。
8. 【請求項８】 上記割当制御工程では、上記記憶手段
   を、リクエストパケット出力用領域と、レスポンスパケ
   ット出力用領域と、リクエストパケット入力用領域と、
   レスポンスパケット入力用領域とにそれぞれ割当制御す
   ることを特徴とする請求項７記載のデータ伝送方法。
9. 【請求項９】 上記ノード情報取得工程では、上記記憶
   手段に対して入出力される入力データ量及び出力データ
   量を測定し、 上記割当制御工程では、この入力データ量及び出力デー
   タ量に応じて上記記憶手段の割当を制御することを特徴
   とする請求項７記載のデータ伝送方法。
10. 【請求項１０】 上記ネットワークは、複数のノードを
    リング状に接続してなるリングネットワークであること
    を特徴とする請求項７記載のデータ伝送方法。
11. 【請求項１１】 複数のノードで構成されるネットワー
    クシステムにおいて、 上記ノード内での処理パケットが入出力され複数パケッ
    トを記憶する容量を有し記憶されたものが順次処理され
    る記憶手段と、 上記記憶手段の入力用、出力用の割り当てを変更制御す
    る制御手段とを有することを特徴とするネットワークシ
    ステム。