JPH0697983A - ネットワークシステム - Google Patents

Abstract

(57)【要約】 【目的】本発明は、ネットワークシステムにおいてデー
タリンク層でのバッファのフレームあふれが生じないよ
うにフロー制御を行うことを特徴とする。 【構成】本発明のネットワークシステムのノードでは、
物理層インターフェース２３ｆで受信されたフレームは
受信バッファ２３ｄに記憶される。バッファ使用量監視
回路２３ｈは受信バッファ２３ｄ内のフレームの数をフ
レーム受信毎にチェックし、チェックしたフレーム数が
予め設定されたフレーム数よりも多い場合、バッファフ
ル信号を生成する。このバッファフル信号を受信する
と、プロトコルコントローラ２３ｂは送信中止フレーム
を送信バッファ２３ｄにセットし、物理層インターフェ
ース２３ｆに送信を指示する。また、受信バッファ２３
ｅのフレーム数が所定フレーム数以下になった場合、バ
ッファエンプティ信号が生成され、このバッファエンプ
ティ信号に従って送信開始フレームが送信される。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、複数のノードおよび各
ノードを相互接続する伝送路を有し、各ノード間におい
てフレームの送受信が行われるネットワークシステムに
関する。

【０００２】

【従来の技術】フレーム交換型のネットワーク、特に、
ローカルエリアネットワーク（ＬＡＮ）の分野では、フ
レームを受信する場合に受信バッファでフレームあふれ
が発生しないように、送信端末と受信端末との間で制御
を行うフロー制御が必要となる。受信端末において受信
処理能力以上のフレーム数を受信した場合、受信処理可
能フレーム数を越える分のフレーム数に対応するフレー
ムは廃棄され、受信端末から送信端末に対してフレーム
の再送要求が行われている。従来、このようなフロー制
御は、ＯＳＩ（open system interconnection ）参照モ
デルのトランスポート層に相当する部分で行われてい
た。このトランスポート層においては、通信の論理的な
チャネル毎にバッファが管理され、各バッファにおいて
フレームあふれが生じないようにフロー制御が行われて
いた。

【０００３】

【発明が解決しようとする課題】しかし、トランスポー
ト層における論理チャネル毎のフロー制御では、チャネ
ルの識別ができないデータリンク層でのバッファのフレ
ームあふれを防ぐことができないという問題があった。

【０００４】本発明は上記事情に鑑みなされたものであ
り、データリンク層においてバッファのフレームあふれ
が生じないようにフロー制御を行うことができるネット
ワークシステムを提供することを目的とする。

【０００５】

【課題を解決するための手段】本発明のネットワークシ
ステムでは、フレームの送受信を行う複数のノードと、
各ノードを相互接続する伝送路を有するネットワークシ
ステムにおいて、各ノードが、他ノードに対してフレー
ムの送受信を行う送受信手段と、送受信手段で受信した
フレームを記憶する記憶手段と、記憶手段に記憶されて
いるフレームの数をチェックするチェック手段と、記憶
手段に記憶されているフレームの数に応じて、他ノード
に対するフレーム送信の中止を要求する送信中止フレー
ムを生成する生成手段とを有し、生成された送信中止フ
レームは送受信手段によって他ノードに送信され、送信
中止フレームを受信した他ノードでは、送信中止フレー
ムを送信したノードに対するフレームの送信を中止する
ことを特徴とする。

【０００６】

【作用】以上のような構成により、データリンク層にお
けるバッファのフレームあふれが生じないようにフロー
制御が行われるので、トランスポート層における無駄な
フレームの再送が少なくなる。従って、フレームの転送
時間が短くなる。また、再送されるフレームが少なくな
るので、ネットワークの容量を効率良く使用することが
できる。

【０００７】

【実施例】本発明の実施例を説明する前に、従来のネッ
トワークシステムのノードについて図８を参照して説明
する。図８において、従来のノードは、ＣＰＵ（centra
lprocessing unit ）１０、メモリ１１、制御バス１
２、ネットワークインターフェース１３、および伝送路
１４によって構成される。

【０００８】ネットワークインターフェース１３は、バ
スインターフェース１３ａ、プロトコルコントローラ１
３ｂ、メモリ１３ｃ、送信バッファ１３ｄ、受信バッフ
ァ１３ｅ、物理層インターフェース１３ｆ、および内部
バス１３ｇによって構成される。内部バス１３ｇは、バ
スインターフェース１３ａ、プロトコルコントローラ１
３ｂ、メモリ１３ｃ、送信バッファ１３ｄ、受信バッフ
ァ１３ｅ、および物理層インターフェース１３ｆを相互
接続するために用いられる。

【０００９】物理層インターフェース１３ｆは、伝送路
１４上の電気信号を判定することにより、他ノードから
自ノード宛に送信されたフレームを受信する。受信バッ
ファ１３ｅは、物理層インターフェース１３ｆで受信し
たフレームを記憶する。

【００１０】プロトコルコントローラ１３ｂは、受信バ
ッファ１３ｅに記憶されているフレームを読出し、読出
したフレームに対してプロトコル処理を行い、ＣＰＵ１
０にその処理結果を示す結果データを転送する。

【００１１】また、プロトコルコントローラ１３ｂは、
ＣＰＵ１０から出力されるフレーム送信要求に応じて、
メモリ１１に記憶されている送信情報を制御バス１２、
バスインターフェース１３ａ、および内部バス１３ｇを
介して送信バッファ１３ｄに転送し、この送信情報にプ
ロトコル情報を付加し、物理層インターフェース１３ｆ
にフレーム送信を指示する。これによって、プロトコル
情報が付加された送信情報が送信フレームとして物理層
インターフェース１３ｆから伝送路１４に出力される。
次に、本発明の実施例について説明する。

【００１２】図１は、本発明の実施例であるネットワー
クシステムのノードの構成を示すブロック図である。図
１に示すように、本ノードは、ＣＰＵ２０、メモリ２
１、制御バス２２、ネットワークインターフェース２
３、および伝送路２４によって構成される。

【００１３】ネットワークインターフェース２３は、バ
スインターフェース２３ａ、プロトコルコントローラ２
３ｂ、メモリ２３ｃ、送信バッファ２３ｄ、受信バッフ
ァ２３ｅ、物理層インターフェース２３ｆ、内部バス２
３ｇ、およびバッファ使用量監視回路２３ｈによって構
成されている。すなわち、本実施例では、図８に示す従
来のネットワークシステムのノードと比較して、バッフ
ァ使用量監視回路２３ｈが新たに設けられている。な
お、内部バス２３ｇは、バスインターフェース２３ａ、
プロトコルコントローラ２３ｂ、メモリ２３ｃ、送信バ
ッファ２３ｄ、受信バッファ２３ｅ、物理層インターフ
ェース２３ｆ、およびバッファ使用量監視回路２３ｈを
相互接続するために用いられる。物理層インターフェー
ス２３ｆは、伝送路２４上の電気信号を判定することに
より、他ノードから自ノード宛に送信されたフレームを
受信する。

【００１４】図２は、物理層インターフェース２３ｆで
受信されたフレーム（受信フレーム）の構成を示す図で
ある。図２に示すように、受信フレームには、ヘッダ
（Ｈ）３０、宛先アドレス（ＤＡ）３１、発信元アドレ
ス（ＳＡ）３２、情報（ＩＮＦＯ）３３、およびエラー
検出符号（ＦＣＳ）３４が含まれる。

【００１５】受信フレーム内の宛先アドレス３１が自ノ
ードアドレスである場合、すなわち、受信フレームが自
ノード宛に送信されたフレームである場合、この受信フ
レームは物理層インターフェース２３ｆによって受信バ
ッファ２３ｅのフレームが記憶されていない空きエリア
に記憶される。

【００１６】一方、受信フレーム内の宛先アドレス３１
が自ノードアドレス以外のアドレスである場合、すなわ
ち、自ノード宛に送信されたフレームでない場合、受信
フレームは物理層インターフェース２３ｆによって廃棄
される。

【００１７】なお、受信バッファ２３ｅは、図３に示す
ように、識別エリア４０とデータエリア４１によって論
理的に構成されている。識別エリア４０とデータエリア
４１は、それぞれ複数のエリアを有している。

【００１８】物理層インターフェース２３ｆは、自ノー
ド宛のフレームを受信した場合、受信バッファ２３ｅの
データエリア４１の所定エリアに受信フレームを記憶さ
せ、識別エリア４０の対応するエリアに“１”を書込
む。また、物理層インターフェース２３ｆは、フレーム
が受信バッファ２３ｅのデータエリア４１から読出され
た場合、識別エリア４０の対応するエリアに“０”を書
込む。

【００１９】バッファ使用量監視回路２３ｈは、識別エ
リア４０の各エリアに書込まれている“１”の数をフレ
ーム受信毎にカウントする。このカウント値によって受
信バッファ２３ｅのフレーム記憶状況を把握することが
できる。

【００２０】ここで、プロトコルコントローラ２３ｂに
おけるフレーム送信処理について図４を参照して説明す
る。なお、図４は、図１に示す本発明の実施例であるノ
ードのプロトコルコントローラ２３ｂにおけるフレーム
送信処理を示すフローチャートである。

【００２１】図４において、ステップＡ１では、ＣＰＵ
２０からフレーム送信要求があったかどうかが判断され
る。ステップＡ１においてＣＰＵ２０からフレーム送信
要求があった場合、ステップＡ２では、他ノードからの
送信中止フレームを物理層インターフェース２３ｆが受
信したかどうかが判断される。

【００２２】図５は、他ノードからのフレームの送信中
止を要求するための送信中止フレームの構成を示すブロ
ック図である。図５に示すように、この送信中止フレー
ムには、ヘッダ（Ｈ）４０、宛先アドレス（ＤＡ）４
１、発信元アドレス（ＳＡ）４２、“送信中止”情報４
３、およびエラー検出符号（ＦＣＳ）４４が含まれる。
なお、宛先アドレス４１には同報アドレスがセットさ
れ、発信元アドレス４２にはこの送信中止フレームを送
信するノードの自ノードアドレスがセットされることに
なる。

【００２３】ステップＡ２において、他ノードからの送
信中止フレームを受信した場合、ステップＡ３では、他
ノードからの送信開始フレームを物理層インターフェー
ス２３ｆが受信したかどうかが判断される。

【００２４】すなわち、他ノードに対するフレームの送
信中において、他ノードから送信中止フレームを受信し
た場合、他ノードに対するフレームの送信が中止され
る。その後、他ノードから送信開始フレームを受信した
場合、他ノードに対してフレームの送信が再開されるこ
とになる。従って、送信開始フレームが受信されるま
で、他ノードに対するフレームの送信は中止される。

【００２５】なお、送信開始フレームの構成は、図５に
示す送信中止フレームとほぼ同様であり、送信開始フレ
ームでは、“送信中止”情報４３の代わりに、“送信開
始”情報が含まれる。

【００２６】ステップＡ３において、他ノードからの送
信開始フレームを受信した場合、送信バッファ２３ｄ内
のフレームが送信される（ステップＡ４）。すなわち、
メモリ２１に記憶されている送信情報は、制御バス２
２、バスインターフェース２３ａ、および内部バス２３
ｇを介して送信バッファ２３ｄに転送され、この送信情
報にプロトコル情報が付加される。また、物理層インタ
ーフェース２３ｆにフレーム送信が指示される。これに
よって、プロトコル情報が付加された送信情報が送信フ
レームとして物理層インターフェース２３ｆから伝送路
２４に出力されることになる。

【００２７】なお、ＣＰＵ２０は、複数のノードに対す
るフレーム送信要求をプロトコルコントローラ２３ｂに
行う場合がある。この場合、上記のようなフレーム送信
処理がそれぞれのフレーム送信要求に対して順次行われ
ることになる。

【００２８】図６は、例えば、３つのノード（宛先Ａ、
Ｂ、Ｃ）に対するフレーム送信要求がＣＰＵ２０から与
えられた場合におけるプロトコルコントローラ２３ｂの
フレーム送信処理の手順を説明するための図である。

【００２９】図６において、時間Ｔ1 は、宛先Ａ、Ｂ、
Ｃに対するフレーム送信要求をＣＰＵ２０から受信した
時を示している。従って、プロトコルコントローラ２３
ｂでは、第１に、宛先Ａに対するフレーム送信が開始さ
れる。

【００３０】時間Ｔ2 は、宛先Ａに対するフレーム送信
中において宛先Ａから送信中止フレームを受信し、宛先
Ｂに対するフレーム送信を開始する時を示している。従
って、受信した送信中止フレームに応じて宛先Ａに対す
るフレーム送信は一時中止される。

【００３１】時間Ｔ3 は、宛先Ａから送信開始フレーム
を受信し、宛先Ａに対するフレーム送信を再開する時を
示している。従って、受信した送信開始フレームに応じ
て宛先Ａに対するフレーム送信が再開され、宛先Ｂに対
するフレーム送信が一時中止される。

【００３２】時間Ｔ4 は、宛先Ａに対するフレーム送信
を終了し、宛先Ｂに対する送信を再開する時を示してい
る。時間Ｔ5 は、宛先Ｂに対するフレーム送信を終了
し、宛先Ｃに対するフレーム送信を開始する時を示して
いる。時間Ｔ6 は、宛先Ｃに対するフレーム送信を終了
する時を示している。

【００３３】以上のように、宛先Ａから順にフレーム送
信処理が行われる。なお、宛先Ａに対するフレーム送信
中に送信中止フレームを受信した場合には、フレーム送
信処理が宛先Ａに対する処理から宛先Ｂに対する処理に
移行する。その後、送信開始フレームを受信した場合に
は、フレーム送信処理が宛先Ｂに対する処理から宛先Ａ
に対する処理に戻ることになる。このような動作によっ
て、宛先Ａから宛先Ｃに対してフレーム送信処理が行わ
れる。

【００３４】前述したようなデータフレームのフレーム
送信処理の他に制御フレーム（送信中止フレーム、送信
開始フレーム）を送信する処理がさらに行われる。制御
フレームを送信するかどうかは１つのデータフレームを
送信する度に判断され、必要ならばデータフレームより
も優先して制御フレームが送信されることになる。

【００３５】次に、プロトコルコントローラ２３ｂにお
けるフレーム受信処理について図７を参照して説明す
る。なお、図７は、図１に示す本発明の実施例であるノ
ードのプロトコルコントローラ２３ｂにおけるフレーム
受信処理を示すフローチャートである。

【００３６】プロトコルコントローラ２３ｂでは、その
処理能力を示す処理可能フレーム数と比較して受信フレ
ーム数が多くなると、受信バッファ２３ｅに記憶される
フレーム数が多くなる。受信バッファ２３ｅに記憶され
るフレームの数が予め設定されたフレーム数以上になっ
た場合、バッファ使用量監視回路２３ｈは、“バッファ
フル”信号を生成し、この“バッファフル”信号をプロ
トコルコントローラ２３ｂに出力する。

【００３７】従って、ステップＢ１では、この“バッフ
ァフル”信号を受信したかどうかが判定される。ステッ
プＢ１において、“バッファフル”信号が受信されてい
ない場合、受信バッファ２３ｅにはフレームを記憶する
エリアがまだ十分あると判断され、物理層インターフェ
ース２３ｆにおいて次に受信したフレームが受信バッフ
ァ２３ｅに記憶される（ステップＢ２）。

【００３８】一方、ステップＢ１において、“バッファ
フル”信号が受信された場合、送信中止フレームが送信
バッファ２３ｄにセットされ、物理層インターフェース
２３ｆに対してフレーム送信が指示される。これによっ
て、送信バッファ２３ｄにセットされている送信中止フ
レームは物理層インターフェース２３ｆから伝送路２４
に同報送信される（ステップＢ３）。

【００３９】他ノードがこの送信中止フレームを受信し
た場合、受信した送信中止フレームに含まれる発信元ア
ドレスで示されるノードに対しては、他ノードからのフ
レーム送信が中止される。なお、このフレーム送信の中
止は次のようにして行うことができる。

【００４０】すなわち、他ノードにおけるプロトコルコ
ントローラにおいて受信フレームが送信中止フレームで
あると判断された場合、受信フレームに含まれる発信元
アドレスをフレーム送信中止ノードアドレスとしてイン
ターフェース内のメモリに記憶する。ここで、ＣＰＵか
らプロトコルコントローラに対して送信要求があった場
合、ＣＰＵから出力された宛先アドレスをメモリに記憶
されているフレーム送信中止ノードアドレスと比較し、
宛先アドレスと一致するフレーム送信中止ノードアドレ
スがメモリに記憶されていれば、フレーム送信を中止す
る。

【００４１】なお、送信中止フレームを送信したノード
では、他のノードからのフレームが受信されないので、
受信バッファ２３ｅに記憶されているフレームは、プロ
トコルコントローラ２３ｂによって順次プロトコル処理
される。

【００４２】受信バッファ２３ｅに記憶可能なフレーム
の数が予め設定されたフレーム数以下になった場合、バ
ッファ使用量監視回路２３ｈは、“バッファエンプテ
ィ”信号を生成し、この“バッファエンプティ”信号を
プロトコルコントローラ２３ｂに出力する。

【００４３】従って、ステップＢ４では、この“バッフ
ァエンプティ”信号を受信したかどうかが判定される。
ステップＢ４において、“バッファエンプティ”信号が
受信されていない場合、受信バッファ２３ｅにはフレー
ムを記憶するエリアが十分確保されていないと判断され
る。従って、受信バッファ２３ｅに記憶されているフレ
ームが読出され、読出されたフレームに対してプロトコ
ル処理が行われる（ステップＢ５）。プロトコル処理の
結果を示す結果データはＣＰＵ２０に転送される。

【００４４】一方、ステップＢ４において、“バッファ
エンプティ”信号が受信された場合、送信開始フレーム
が送信バッファ２３ｄにセットされ、物理層インターフ
ェース２３ｆにフレーム送信が指示される。これによっ
て、送信開始フレームは物理層インターフェース２３ｆ
から伝送路２４に同報送信される。

【００４５】他ノードがこの送信開始フレームを受信し
た場合、受信した送信開始フレームの中から発信元アド
レスが読出され、読出された発信元フレームと一致する
フレーム送信中止ノードアドレスがメモリから削除され
る。以上のようにして、受信バッファ２３ｅにおけるフ
レームあふれを防ぐことができる。

【００４６】なお、本実施例では、各ノードの受信バッ
ファのフレームあふれを防ぐために、送信中止フレー
ム、送信開始フレームが用いられている。しかし、各ノ
ードにタイマを設けることにより、受信バッファのフレ
ームあふれの制御を行うことが可能である。

【００４７】すなわち、所定ノードが送信中止フレーム
を受信した場合、そのノード内に設けられているタイマ
をスタートさせ、タイマのタイマ値が予め設定されたタ
イマ値に達するまでフレーム送信を中止する。これによ
って、ノードの受信バッファにおけるフレームあふれを
防ぐことができる。従って、この場合、前述した実施例
と比較して、送信開始フレームを所定ノードに送信する
必要がなくなる。また、送信開始フレームが全ノードに
届かず、いつまでもフレーム送信できなくなるという事
態を防ぐことができる。

【００４８】さらに、送信中止フレームを用いてフレー
ム送信を中止する場合、制御情報のようにデータ量が少
ない情報はフレーム送信し、画像情報のようにデータ量
が多い情報はバッファあふれが生じるのでフレーム送信
しないという判断をプロトコルコントローラで行うこと
により、制御情報だけは常にフレーム送信することが可
能となる。以上、本発明の実施例について説明したが、
本発明は上記実施例に限定されることなく本発明の要旨
の範囲内において種々の変形実施が可能である。

【００４９】

【発明の効果】以上のように、データリンク層における
バッファのフレームあふれが生じないようにフロー制御
が行われるので、トランスポート層における無駄なフレ
ームの再送が少なくなる。従って、フレームの転送時間
が短くなる。また、再送されるフレームが少なくなるの
で、ネットワークの容量を効率良く使用できる。

【図面の簡単な説明】

【図１】本発明の実施例であるネットワークシステムに
おけるノードの構成を示すブロック図。

【図２】受信フレームの構成を示す図。

【図３】図１に示すノードにおける受信バッファの論理
的な構成を示す図。

【図４】図１に示すノードにおけるプロトコルコントロ
ーラのフレーム送信処理を示すフローチャート。

【図５】送信中止フレームの構成を示す図。

【図６】３つのノードに対する送信要求がＣＰＵからあ
った場合におけるプロトコルコントローラのフレーム送
信処理の手順を説明するための図。

【図７】図１に示すノードにおけるプロトコルコントロ
ーラのフレーム受信処理を示すフローチャート。

【図８】従来のネットワークシステムにおけるノードの
構成を示すブロック図。

【符号の説明】

２０…ＣＰＵ、２１…メモリ、２２…制御バス、２３…
ネットワークインターフェース、２３ａ…バスインター
フェース、２３ｂ…プロトコルコントローラ、２３ｃ…
メモリ、２３ｄ…送信バッファ、２３ｅ…受信バッフ
ァ、２３ｆ…物理層インターフェース、２３ｇ…内部バ
ス、２３ｈ…バッファ使用量監視回路、２４…伝送路。

Claims (4)

【特許請求の範囲】
1. 【請求項１】 フレームの送受信を行う複数のノード
   と、各ノードを相互接続する伝送路を有するネットワー
   クシステムにおいて、各ノードは、 他ノードに対してフレームの送受信を行う送受信手段
   と、 送受信手段で受信したフレームを記憶する記憶手段と、 記憶手段に記憶されているフレームの数をチェックする
   チェック手段と、 記憶手段に記憶されているフレームの数に応じて、他ノ
   ードに対するフレーム送信の中止を要求する送信中止フ
   レームを生成する生成手段とを有し、 生成された送信中止フレームは送受信手段によって他ノ
   ードに送信され、送信中止フレームを受信した他ノード
   では、送信中止フレームを送信したノードに対するフレ
   ームの送信を中止することを特徴とするネットワークシ
   ステム。
2. 【請求項２】 他ノードから送信中止フレームを送信し
   たノードに対するフレーム送信は、予め決められた期間
   だけ中止されることを特徴とする請求項１記載のネット
   ワークシステム。
3. 【請求項３】 前記生成手段は、さらに、記憶手段に記
   憶されているフレームの数に応じて他ノードに対するフ
   レーム送信の再開を要求する送信開始フレームを生成
   し、他ノードから送信中止フレームを送信したノードに
   対するフレーム送信は、送信中止フレームを送信したノ
   ードから送信開始フレームを受信するまで中止されるこ
   とを特徴とする請求項１記載のネットワークシステム。
4. 【請求項４】 他ノードは、送信中止フレームを送信し
   たノードに対して所定量以上のフレームのみの送信を中
   止することを特徴とする請求項１記載のネットワークシ
   ステム。