JP3413696B2

JP3413696B2 - フロー制御方式及びそのハブ

Info

Publication number: JP3413696B2
Application number: JP29984795A
Authority: JP
Inventors: 郁男田岡; 直秀関谷; 武志木村; 英樹井上; 博史永野; 孝司西村
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 1995-11-17
Filing date: 1995-11-17
Publication date: 2003-06-03
Anticipated expiration: 2015-11-17
Also published as: JPH09149065A

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はフロー制御方式及び
そのハブに関し、更に詳しくはバックボーンのスイッチ
ングハブとイーサネット対応の端末機器を収容するフロ
ントエンドのハブ（マルチポートリピータ又はスイッチ
ングハブ）とが階層構造で接続するネットワークのフロ
ー制御方式及びそのハブに関する。

【０００２】Ｂ−ＩＳＤＮ時代のＬＡＮ製品としてＡＴ
Ｍハブと共に注目されているものにスイッチングハブが
ある。スイッチングハブを使用すれば、既存のイーサネ
ット対応機器（端末，サーバ等）に別段の変更を加える
ことなく、通信帯域の有効利用が図れる。

【０００３】

【従来の技術】図１２は従来技術を説明する図である。
図１２（Ａ）はイーサネットＬＡＮの一部を示してお
り、図においてＡ〜Ｄはイーサネット対応の通信端末、
Ｈ１は端末Ａ〜Ｄを収容するフロントエンドのマルチポ
ートリピータ（通常のハブ）である。

【０００４】マルチポートリピータＨ１は、各ポートが
１本の通信線（同軸ケーブル等）を共有するもので、あ
るポートから受け取ったパケットは他の全ポートに送り
出される。例えばバックボーン（支線ＬＡＮを束ねる基
幹部）からの端末Ａ宛のパケットは、全端末Ａ〜Ｄに送
り出され、端末Ａは自己宛のパケットを受け取り、端末
Ｂ〜Ｄは自己宛でないパケットを破棄する。

【０００５】この種のＬＡＮは帯域共有型のＬＡＮと呼
ばれ、ある端末が通信をしていると、他の端末は通信を
できないので、伝送路帯域を有効に利用できない。そこ
で、従来は図１２（Ｂ）に示す如く、フロントエンドの
ハブＨ１をスイッチングハブＳＨ１で置き換えることが
行われた。スイッチングハブＳＨ１は、パケットをその
宛先アドレスに従って必要なポートにのみ送出するもの
で、例えばバックボーンからの端末Ａ宛のパケットは端
末Ａにのみ送り出され、この場合の端末Ｂは同時に端末
Ｄと通信できる。

【０００６】この種のＬＡＮは帯域専有型のＬＡＮと呼
ばれ、フロントエンドにスイッチングハブＳＨ１を使用
することで、各端末Ａ〜Ｄは伝送路帯域をより有効に利
用できる。更に、スイッチングハブはイーサネットにお
けるパケット送受信用のＭＡＣアドレスと端末の該当ポ
ート番号とを対応させるアドレステーブルを備えてお
り、各パケットは自動的かつ適正にルーティングされる
ので、既存のイーサネット対応機器のハード／ソフトウ
ェアを変更することなく、現有設備をそのまま収容でき
る利点がある。

【０００７】またスイッチングハブは複雑な通信プロト
コルを必要としないので、例えばパケットの宛先アドレ
スまでを読み込んだ時点で直ちに出力ポートを決定する
ような機能をハードウェアスイッチ（ＡＳＩＣ等）で構
成できる。このため、スイッチングハブには交換能力５
Ｇｂｐｓで１００Ｍｂｐｓのイーサネットを収容するよ
うな、ＡＴＭスイッチに匹敵する能力を持つものもあ
る。

【０００８】そこで、従来は図１２（Ｃ）に示す如く、
スイッチングハブＳＨ１をバックボーンのハブに使用す
ることが考えられた。ここで、Ａ〜Ｈはイーサネット対
応の通信端末、Ｈ１〜Ｈ３はフロントエンドのマルチポ
ートリピータ、ＳＨ４はフロントエンドのスイッチング
ハブである。しかし、現状のスイッチングハブは適当な
フロー制御を備えていないため、これを端末からのトラ
ヒックが集中するバックボーンで使用すると、直ぐにバ
ッファオーバフローを起こしてしまい、通信が停止する
問題が指摘されている。

【０００９】このため、何らかのフロー制御を実装する
ことが考えられるが、この種のスイッチングハブに唯一
実装可能なフロー制御としては、コリジョン信号による
バックプレッシャ方式がある。バックプレッシャ方式
は、ＩＥＥＥ８０２．３準拠の端末機器が標準に備える
衝突検出機能を拡大解釈して利用するもので、スイッチ
ングハブがバッファオーバフローを起こしそうになった
ポートに対してコリジョン信号を送出すると、コリジョ
ンドメイン（コリジョン信号が届く範囲）内の端末はコ
リジョン信号との衝突を検出してパケット送出を一時的
に停止するものである。

【００１０】

【発明が解決しようとする課題】しかし、このバックプ
レッシャ方式はフロントエンドのスイッチングハブＳＨ
４では有効に働くが、バックボーンのスイッチングハブ
ＳＨ１では有効に働かない。図１２（Ｃ）に基づきその
理由を具体的に説明する。

【００１１】今、スイッチングハブＳＨ１が端末Ｂから
端末Ｃ宛のパケットを転送しているとすると、該ＳＨ１
は複数ポートの入力パケットを同時に同一ポートには出
力できないので、端末Ｅから端末Ｃ又はＤ宛のパケット
を転送できない。その結果、端末ＥのパケットはハブＨ
３を収容する入力ポートのバッファに溜まる。この場合
に、もし端末ＢからＣ宛のパケット転送が長引くと、や
がてＳＨ１の入力バッファはオーバフローし、溢れたパ
ケットは破棄されてしまう。

【００１２】このため、スイッチングハブＳＨ１は、入
力バッファが溢れそうになると、当該ポートにコリジョ
ン信号を送出する。この場合に、マルチポートリピータ
Ｈ３の場合は、コリジョン信号はコリジョンドメイン
（この例ではハブＨ３）内でブロードキャストされ、全
収容端末Ｅ〜Ｇに送出される。その結果、端末Ｅはパケ
ットの送出を停止し、これによりＳＨ１はバッファオー
バフローを回避できる。

【００１３】しかし、コリジョンドメイン内の端末Ｆ及
びＧはスイッチングハブＳＨ１を介さない端末Ｆ−Ｇ間
の通信でさえも行えなくなる問題がある。この現象はバ
ックプレッシャシンドロームと呼ばれる。ところで、こ
のバックプレッシャシンドロームはフロントエンドのハ
ブＨ３をスイッチングハブＳＨ３に置き換えても同様に
生じる。

【００１４】即ち、この場合のＳＨ１からのコリジョン
信号はＳＨ３のみに送出される（即ち、ＳＨ３のみがコ
リジョンドメインとなる）が、コリジョンドメインにあ
るＳＨ３はＳＨ１にパケットを送れないので、もしこの
状態で端末Ｆが端末Ｈ宛のパケットを送出すると、該パ
ケットはＳＨ３の入力ポートに溜まる。そして、この状
態が長引くと、やがてＳＨ３は端末Ｆにコリジョン信号
を送出し、端末Ｆは通信できなくなる。同様に、端末Ｇ
も通信できなくなる。

【００１５】なお、上記バックプレッシャ方式に代え、
ＡＴＭハブが採用する動的帯域割り振り（ＡＢＲ：Avai
lable Bit Rate）の様な上位レイヤで実現するフロー制
御をスイッチングハブに実装することも考えられる。し
かし、その為には既存のイーサネット対応機器のハード
／ソフトウェアを変更する必要があり、現有機器をその
まま収容できると言うスイッチングハブの優位性が損な
われてしまう。

【００１６】本発明は上記の問題点を解決するもので、
その目的とする所は、通信を制限したい機器にのみコリ
ジョン信号を送出できるフロー制御方式及びそのハブを
提供することにある。

【００１７】

【課題を解決するための手段】上記の課題は例えば図１
の構成により解決される。即ち、本発明の（１）のフロ
ー制御方式は、バックボーンのスイッチングハブとイー
サネット対応の端末機器を収容するフロントエンドのハ
ブ（マルチポートリピータ又はスイッチングハブ）とが
階層構造で接続するネットワークのフロー制御方式にお
いて、バックボーンのスイッチングハブＳＨ１は自己の
入力ポートがオーバフローする前に該入力ポートにパケ
ットを送出している端末宛のオーバフロー通知用パケッ
トを生成して当該ポートに送出し、これを受けたフロン
トエンドのハブＨ２はオーバフロー通知用パケットの宛
先端末を直接収容するポートにコリジョン信号を送出す
るものである。

【００１８】動作の一例を具体的に説明する。今、バッ
クボーンのスイッチングハブＳＨ１が端末ＲからＭ宛の
パケットを転送しているとすると、該ＳＨ１は複数ポー
トの入力パケットを同時に同一ポートには出力できない
ので、端末ＡからＭ宛のパケットを転送できない。その
結果、端末ＡのパケットはハブＨ１を収容するポートＰ
１の入力バッファに溜まる。

【００１９】この状態で、もし端末ＲからのＭ宛のパケ
ット転送が長引くと、やがてＳＨ１におけるポートＰ１
の入力バッファはオーバフローし、溢れたパケットは破
棄されてしまう。そこで、スイッチングハブＳＨ１は、
ポートＰ１の入力バッファが溢れそうになると、該ポー
トＰ１にパケットを送出している端末Ａを検出して該端
末Ａ宛のオーバフロー通知用パケットを生成し、ポート
Ｐ１に送出する。

【００２０】このオーバフロー通知用パケットは、途中
のハブＨ１，Ｈ２でブロードキャストされるが、端末Ｂ
〜Ｌは自己宛でないオーバフロー通知用パケットを最終
的に破棄する。端末Ａは自己宛のオーバフロー通知用パ
ケットを無視可能である。フロントエンドのハブＨ２に
おいて、端末Ａを直接収容するポートＰ１は端末Ａ宛の
オーバフロー通知用パケットを検出したことによりポー
トＰ１にコリジョン信号を送出する。一方、端末Ａを直
接収容しないポートＰ２，Ｐ３は端末Ａ宛のオーバフロ
ー通知用パケットを検出してもポートＰ２，Ｐ３にコリ
ジョン信号を送出しない。

【００２１】その結果、端末Ａのみがパケットの送出を
停止し、これによりスイッチングハブＳＨ１はバッファ
オーバフローを回避できる。他の端末Ｂ，Ｃはコリジョ
ンドメインには無いので、端末Ｂ−Ｃ間で通信できる。
またハブＨ１，Ｈ２もコリジョンドメインには無いの
で、この場合の端末Ｂ／ＣはハブＨ１，Ｈ２を介して端
末Ｄ〜Ｈ又は端末Ｉ〜Ｌと通信できる。

【００２２】なお、ハブＨ１，Ｈ２に代えて、同等の機
能を備えるスイッチングハブを用いても良い。この場合
の端末Ａ宛のオーバフロー通知用パケットはハブＨ２の
ポートＰ１にのみルーティングされるだけで、他は上記
と同じ結果となる。本発明（１）によれば、バックボー
ンのスイッチングハブＳＨ１はバッファオーバフローの
原因となる端末宛にオーバフロー通知用パケットを送出
するので、フロントエンドまでのパスをコリジョン信号
で塞いでしまうことは無い。

【００２３】また、最終的にオーバフロー通知用パケッ
トを受けたフロントエンドのハブＨ２は、オーバフロー
通知用パケットの宛先端末を直接収容するポートにのみ
コリジョン信号を送出するので、他のポートの端末は通
信を行える。かくして、本発明（１）によれば、通信を
制限したい機器にのみコリジョン信号を送出でき、回線
の有効利用が図れる。

【００２４】また、本発明（２）のスイッチングハブ
は、バックボーンのスイッチングハブとイーサネット対
応の端末機器を収容するフロントエンドのハブ（マルチ
ポートリピータ又はスイッチングハブ）とが階層構造で
接続するネットワークのスイッチングハブにおいて、入
力ポートのバッファ使用率が所定の閾値を越えたことに
より、当該入力バッファに蓄積された最新パケットの送
信元アドレスを読み出すと共に、得られた送信元アドレ
スを宛先アドレスとする所定のオーバフロー通知用パケ
ットを生成して当該ポートに送出するフロー制御部を備
える。

【００２５】このようなスイッチングハブは、多段構成
のバックボーンの中枢にも、またバックボーンの中継段
にも使用でき、もって既存のイーサネット対応機器に変
更を加えること無く、ネットワークの帯域専有化、高速
スイッチ化を容易に実現できる。好ましくは、本発明
（３）においては、オーバフロー通知用パケットは、そ
の送信元アドレスとして所要ネットワーク（例えばＬＡ
Ｎ）についての予め規定したユニークな番号を含む。

【００２６】従って、フロントエンドのハブＨ２や端末
Ａ等はオーバフロー通知用パケットを容易に識別でき
る。また、本発明（４）のハブは、バックボーンのスイ
ッチングハブとイーサネット対応の端末機器を収容する
フロントエンドのハブ（マルチポートリピータ又はスイ
ッチングハブ）とが階層構造で接続するネットワークの
ハブにおいて、ポートを通過するパケットのヘッダ情報
を検出するヘッダ情報検出部と、ヘッダ情報検出部が出
力ポートを通過する所定のオーバフロー通知用パケット
を検出したことにより、該パケットの宛先端末を直接収
容するポートに対してコリジョン信号を送出するバック
プレッシャ制御部とを備える。

【００２７】このようなハブ（マルチポートリピータ又
はスイッチングハブ）をフロントエンドに用いれば、本
発明（２）のスイッチングハブと協動することで、既存
のイーサネット対応機器をそのまま収容できると共に、
回線利用の大幅な改善が得られる。好ましくは、本発明
（５）においては、ハブは、ポート別に収容端末のアド
レス情報及び該収容が直接か間接かを示す情報を保持す
る収容端末テーブルを備え、バックプレッシャ制御部
は、ポート対応の収容端末テーブルに基づき当該宛先端
末の収容が直接か間接かを判別する。

【００２８】図１の例では、中継段のハブＨ１は端末Ａ
を直接収容していないのでコリジョン信号を発生しな
い。フロントエンドのハブＨ２は端末Ａを直接収容して
いるのでコリジョン信号を発生する。このような制御は
ポート対応の収容端末テーブルを参照することで、当該
宛先端末の収容が直接か間接かの判断に基づき容易に行
える。

【００２９】また好ましくは、本発明（６）において
は、ハブは、ヘッダ情報検出部が入力ポートを通過する
通信パケットについて新たな送信元アドレスの情報を検
出したことにより、収容端末テーブルの内容を更新する
テーブル管理部を備える。従って、各ハブＨ１，Ｈ２等
は収容端末の管理を自律的に行え、プラグ・アンド・プ
レイのネットワークを構成できる。

【００３０】また好ましくは、本発明（７）において
は、ハブは、所定のノード通知用パケットを保持し、こ
れをポートに定期的に送出するノード通知用パケット送
出部を備える。ところで、プラグ・アンド・プレイのネ
ットワークを構成する場合は、ハブＨ１は中継段（バッ
クボーン側）に有り、かつハブＨ２はフロントエンドに
有ることを夫々自律的に管理したい。本発明（７）によ
れば、ハブは、所定のノード通知用パケットをポートに
定期的に送出するノード通知用パケット送出部を備える
ので、自律的管理が可能となる。

【００３１】図１において、ハブＨ２のポートＰ０から
出力されたノード通知用パケットはハブＨ１のポートＰ
１で認識され、これによりハブＨ１のポートＰ１は自己
がバックボーン側に有ると判断する。ハブＨ１のポート
Ｐ２，Ｐ３についても同様である。ところで、ハブＨ
１，Ｈ２の各ポートＰ０〜Ｐ３が夫々共通の構成を有し
ていると仮定すると、逆に、ハブＨ１のポートＰ１から
出力されたノード通知用パケットはハブＨ２のポートＰ
０で認識され、これによりハブＨ２のポートＰ０は自己
がバックボーン側に有ると判断する場合も考えられる。

【００３２】しかし、この場合のハブＨ２のポートＰ０
は実際に端末を収容していないので、コリジョン信号を
生成することは無い。従って、ハブＨ２のポートＰ０の
みがバックボーン側に有ると判断しても、システムの運
用上問題は生じない。一方、端末Ａ〜Ｃがオーバフロー
通知用パケットを出すことは無いので、ハブＨ２のポー
トＰ１〜Ｐ３はバックボーン側に有ると判断することは
無い。即ち、夫々はフロントエンド側にあると判断す
る。

【００３３】以上からして、各ハブ（スイッチングハブ
を含む）の各ポートＰ０〜Ｐ３は夫々バックボーンに有
るか又はフロントエンドにあるかの自律的管理を行える
ようになる。なお、マニュアル設定等により、バックボ
ーン側に接続するポート（この例ではポートＰ０）のみ
からノード通知用パケットを送出するようにしても良
い。

【００３４】また好ましくは、本発明（８）において
は、ノード通知用パケットは、その宛先アドレス及び送
信元アドレスとして所要ネットワークについての予め規
定したユニークな番号を含む。宛先アドレスをユニーク
な番号とすれば、例えばハブＨ１がスイッチングハブの
場合は、該パケットは入力ポートＰ１より他にスイッチ
転送されない。また送信元アドレスをユニークな番号と
することでノード通知用パケットであることを容易に認
識できる。

【００３５】また好ましくは、本発明（９）において
は、ハブは、ヘッダ情報検出部が入力ポートを通過する
所定のノード通知用パケットを検出したことにより、下
位ノード検出の旨の情報を保持する保持部を備える。従
って、保持部が下位ノード検出の旨の情報を保持してい
る間は、当該ポートはバックボーン側にあるとして機能
できる。

【００３６】また好ましくは、本発明（１０）において
は、ノード通知用パケットは当該入力ポートで破棄され
る。従って、ハブＨ１がマルチポートリピータの場合で
も、入力ポートＰ１のノード通知用パケットは他にブロ
ードキャストされない。また好ましくは、本発明（１
１）においては、保持部の下位ノード検出の旨の情報
は、ヘッダ情報検出部が所定時間の間入力ポートを通過
するノード通知用パケットを検出しないことによりリセ
ットされる。

【００３７】従って、例えばハブＨ１のポートＰ２に端
末Ｄを直接接続すると、ポートＰ２は自動的にフロント
エンドの側に有ると判断する。また好ましくは、本発明
（１２）においては、バックプレッシャ制御に係る機能
は保持部が下位ノード検出の旨の情報を保持しているこ
とにより消勢される。ところで、上記バックプレッシャ
制御に係る一連の機能は、これをハードウエアで実現す
れば各ポートにおける処理負担（処理遅延）とはならな
いが、もしファームウエアで実現すると、シーケンシャ
ルな処理となり、処理遅延の原因となり得る。

【００３８】一方、保持部が下位ノード検出の旨の情報
を保持している場合は、当該ポートはバックボーン側に
ありバックプレッシャ制御に係る一連の機能は必要が無
い。そこで、バックプレッシャ制御に係る機能は保持部
が下位ノード検出の旨の情報を保持していることにより
消勢される。また好ましくは、本発明（１３）において
は、ハブは、ヘッダ情報検出部が入力ポートを通過する
所定のノード通知用パケットを検出したことにより、下
位ノード検出の旨の情報を保持する保持部を備え、テー
ブル管理部は保持部が下位ノード検出の旨の情報を保持
していることにより収容端末テーブルの収容情報を間接
にして更新する。

【００３９】従って、ハブＨ１，Ｈ２は夫々の収容モー
ドで端末を適正に管理できる。

【００４０】

【発明の実施の形態】以下、添付図面に従って本発明に
好適なる実施の形態を詳細に説明する。なお、全図を通
して同一符号は同一又は相当部分を示すものとする。図
２〜図５は実施の形態によるフロー制御方式の構成を示
す図（１）〜（４）である。

【００４１】図２はローカルエリアネットワーク（ＬＡ
Ｎ）の一部を示しており、図においてＡ〜Ｃはイーサネ
ット対応の通信機器（端末，サーバ等）、Ｈ２は端末Ａ
〜Ｃを収容するフロントエンドのハブ（マルチポートリ
ピータ）、Ｈ１はハブＨ２等を収容するバックボーン
（中継段）のハブ（マルチポートリピータ）、ＳＨ１は
ハブＨ１等を収容するバックボーン（中枢部）のスイッ
チングハブである。

【００４２】なお、図示しないが、通信機器Ｄ〜Ｈ，Ｉ
〜Ｌ，Ｍ〜Ｑ，Ｒ〜Ｖについても端末Ａ〜Ｃに対するの
と同様の階層構造でＬＡＮに収容されている。また、本
実施の形態ではハブＨ１，Ｈ２をマルチポートリピータ
として説明するが、各ポートに共通なバスの部分をスイ
ッチ部で置き換えるだけで、ハブＨ１，Ｈ２はスイッチ
ングハブとなる。

【００４３】図２において、スイッチングハブＳＨ１で
は、ポートＰ３配下の端末ＲからポートＰ２配下の端末
Ｍ宛に大量のパケットデータが流れている。この状態
で、端末Ａが端末Ｍ宛にパケットを送出したと仮定す
る。係る通信状況の下で、各ハブの動作を以下に詳細に
説明する。図３は図２のスイッチングハブＳＨ１の詳細
構成を示しており、図においてＳＷはパケットを交換す
るスイッチ部、Ｐ０〜Ｐ３はポート、ＩＢＦは入力バッ
ファ、ＵＲＤは入力バッファの使用率を監視するバッフ
ァ監視部、ＦＬＣは入力バッファの使用率に応じてオー
バフロー通知用パケットを生成し、送信するフロー制御
部である。また、アドレステーブルはＭＡＣアドレスと
ポート番号とを対応付けるテーブルで、スイッチ部ＳＷ
が参照する。

【００４４】上記により、スイッチングハブＳＨ１のポ
ートＰ１には端末Ａからの端末Ｍ宛のパケットが入力す
る。ポートＰ１は該パケットをスイッチ部ＳＷに送り出
そうとするが、スイッチ部ＳＷは、アドレステーブルよ
り宛先端末ＭがポートＰ２配下にあることを確認すると
共に、現在はポートＰ３からのパケットをポートＰ２配
下の端末にスイッチング中であることにより、ポートＰ
１からのパケット入力を拒否する。その結果、端末Ａか
らの端末Ｍ宛のパケットはポートＰ１の入力バッファＩ
ＢＦに溜められる。

【００４５】この状況が長引くと、やがてポートＰ１の
入力バッファＩＢＦからはパケットが溢れ出してしま
う。そこで、ポートＰ１のバッファ監視部ＵＲＤは入力
バッファＩＢＦの使用状態を常時監視しており、入力バ
ッファＩＢＦが溢れそうになると、フロー制御部ＦＬＣ
を付勢する。その詳細を以下に説明する。図６は実施の
形態によるオーバフロー通知用パケット送信処理のフロ
ーチャートである。

【００４６】ステップＳ１ではバッファ監視部ＵＲＤは
入力バッファＩＢＦの使用率をチェックする。ステップ
Ｓ２では使用率＞α（所定値）か否かを判別し、使用率
＞αでない場合はステップＳ１に戻る。また、使用率＞
αの場合はステップＳ３に進み、入力バッファＩＢＦに
最後に入力したパケットの送信元アドレス（この例では
ＭＡＣ＝Ａ）を抽出すると共に、フロー制御部ＦＬＣを
付勢する。

【００４７】ステップＳ４ではフロー制御部ＦＬＣは端
末Ａ宛のオーバフロー通知用パケットを生成し、これを
ポートＰ１に送信する。ステップＳ５では、バッファ監
視部ＵＲＤは所定のｘ秒の経過を待つと共に、該ｘ秒を
経過すると、ステップＳ６で入力バッファＩＢＦの使用
率≦β（但し、β＜α）か否かを判別する。使用率≦β
の場合は入力バッファＩＢＦ内のパケットが十分に減少
したのでステップＳ１に戻る。また使用率≦βでない場
合はステップＳ４に戻り、再度フロー制御部ＦＬＣを付
勢する。

【００４８】なお、新たに端末Ｂが端末Ｑ宛のパケット
を送出することも考えられるので、上記ステップＳ６の
判別で使用率≦βでない場合は、ステップＳ３に戻る様
にしても良い。この場合のバッファ監視部ＵＲＤは入力
バッファＩＢＦに最後に入力したパケットの送信元アド
レス（この例ではＭＡＣ＝Ｂ）を抽出すると共に、フロ
ー制御部ＦＬＣを再度付勢する。ステップＳ４ではフロ
ー制御部ＦＬＣは端末Ｂ宛のオーバフロー通知用パケッ
トを生成し、これをポートＰ１に送信する。

【００４９】図１０は実施の形態によるオーバフロー通
知用パケットのＭＡＣフレームフォーマットを示す図で
ある。このフォーマットはイーサネットにおけるオリジ
ナルのＤＩＸ仕様と、後にこれを標準化したＩＥＥＥ８
０２．３仕様とに準拠している。「宛先アドレス」に
は、本来は通信パケットの宛先アドレスが入るが、オー
バフロー通知用パケットではオーバフロー通知先の端末
アドレス（例えばＡ）を入れる。

【００５０】「送信元アドレス」には、本来は通信パケ
ットを送出した端末アドレスが入るが、オーバフロー通
知用パケットではオーバフロー通知用パケットであるこ
とを示す所要ネットワーク（この例ではＬＡＮ）におい
てユニークな番号（例えばＸ）を入れる。更に、「送信
元アドレス」中の「Ｉ／Ｇ」ビットは、個別（０）／グ
ループ（１）を表しており、オーバフロー通知用パケッ
トではグループ（１）とする。また「Ｕ／Ｌ」ビット
は、ユニバーサル（０）／ローカル（１）を表してお
り、オーバフロー通知用パケット（即ち、ＬＡＮ）では
ローカル（１）とする。

【００５１】「タイプ」は、本来はユーザデータの上位
プロトコルの種類を示すが、オーバフロー通知用パケッ
トではオーバフロー通知用パケットであることを示すユ
ニークな番号を入れる。「ＬＬＣヘッダ」は、本来は宛
先端末の上位レイヤとリンクをとる論理リンク制御のた
めに使用するが、オーバフロー通知用パケットは端末の
上位レイヤに渡す必要は無いので、端末の上位レイヤに
とって無意味なビット列となし、論理リンク制御で破棄
される様にする。

【００５２】図５はフロントエンドにおけるハブＨ２の
詳細構成を示しており、例えばバックボーン（中継段）
のハブＨ１が無いと仮定すると、スイッチングハブＳＨ
１からのオーバフロー通知用パケットはフロントエンド
のハブＨ２に入力する。図において、ＢＵＳは各ポート
が共用するバス、Ｐ０〜Ｐ３はポート、ＳＦＲはポート
を通過するパケットヘッダ部の信号を参照するためのシ
フトレジスタ、ＨＤＤはポートを通過するパケットヘッ
ダ部の各種情報を検出するヘッダ情報検出部、ＢＰＣは
コリジョン信号を出力するバックプレッシャ制御部、Ｔ
ＡＢはポート別の収容端末に係る情報を保持する収容端
末テーブル、ＴＢＣは収容端末に係る情報の登録／削除
を行うテーブル管理部、ＦＬＧは下位ノード検出の旨の
情報を保持する保持部、ＮＰＳはノード通知用パケット
を送出するノード通知用パケット送出部である。各収容
端末テーブルＴＡＢの一例の記憶態様を図の右側に示
す。

【００５３】上記により、ハブＨ２のポートＰ０に入力
した端末Ａ宛のオーバフロー通知用パケットは、バスＢ
ＵＳを介してハブＨ２の全ポートＰ１〜Ｐ１３に分配さ
れる。各ポートＰ１〜Ｐ１３のヘッダ情報検出部ＨＤＤ
は通過パケットのアドレス情報を検出して必要なバック
プレッシャ制御部ＢＰＣの付勢を行う。図７は実施の形
態によるコリジョン信号送出処理のフローチャートであ
る。

【００５４】ステップＳ１１では、ヘッダ情報検出部Ｈ
ＤＤは出力ポートに向かうパケットの送信元アドレスを
チェックする。ステップＳ１２では「送信元アドレス」
＝「Ｘ」か否かを判別し、「送信元アドレス」＝「Ｘ」
でない場合は、例えば通常の通信用パケットであるの
で、そのまま処理を抜ける。また「送信元アドレス」＝
「Ｘ」の場合は、オーバフロー通知用パケットであるの
で、ステップＳ１３に進み、更に該パケットの「宛先ア
ドレス」をチェックする。ステップＳ１４では、宛先ア
ドレスにより自己の収容端末テーブルを参照し、該宛先
アドレスの端末が自ポートの収容端末か否かを判別す
る。

【００５５】収容端末でない場合は処理を抜ける。ま
た、収容端末の場合はステップＳ１５で更に該収容端末
が直接収容「０」か、又は中間に他のハブが介在する間
接収容「１」か否かを判別する。間接収容「１」の場合
は、この段ではコリジョン信号ＣＳを送出しないので、
そのまま処理を抜ける。また直接収容「０」の場合はス
テップＳ１６でバックプレッシャ制御部ＢＰＣを付勢す
る。これによりバックプレッシャ制御部ＢＰＣはコリジ
ョン信号ＣＳを生成し、接続端末に送出する。

【００５６】図５について上記の処理結果を言うと、ハ
ブＨ２のポートＰ１は、収容端末＝「Ａ」、かつ直接収
容「０」により、コリジョン信号ＣＳを端末Ａに送出す
る。ポートＰ２は、収容端末＝「Ｂ」によりコリジョン
信号ＣＳを送出しない。ポートＰ３も収容端末＝「Ｃ」
によりコリジョン信号ＣＳを送出しない。従って、端末
Ａのみがコリジョン信号ＣＳの衝突を検出し、パケット
の送信を停止する。

【００５７】図４はバックボーン（中継段）におけるハ
ブＨ１の構成を示しており、細部の構成は図５のハブＨ
２と同一である。ハブＨ１が有る場合はＳＨ１からのオ
ーバフロー通知用パケットはまずハブＨ１に入力する。
ハブＨ１のオーバフロー通知用パケット処理は図５で述
べたものと同一で良い。但し、収容端末テーブルＴＡＢ
の記憶内容が異なるので以下の結果となる。

【００５８】ハブＨ１において、ポートＰ１は収容端末
に「Ａ」を含むが、該端末Ａは間接収容「１」であるの
で、コリジョン信号ＣＳは送出されない。オーバフロー
通知用パケットはポートＰ１を通過する。またポートＰ
２は収容端末に「Ａ」を含まないので、コリジョン信号
ＣＳは送出されない。オーバフロー通知用パケットはポ
ートＰ２を通過する。またポートＰ３は、同じく収容端
末に「Ａ」を含まないので、コリジョン信号ＣＳは送出
されない。オーバフロー通知用パケットはポートＰ３を
通過する。

【００５９】従って、中間にハブＨ１が存在しても、オ
ーバフロー通知用パケットはハブＨ１通過し、フロント
エンドのハブＨ２に至る。ところで、一般に中継段のハ
ブＨ１は、フロントエンドのハブＨ２に比べて１ポート
当たりの論理的な収容端末数が多くなるので、収容端末
テーブルＴＡＢの検索をファームウエアで行う場合は、
検索に時間を要し、能率的でない。そこで、このような
ハブＨ１をバックボーン側に設置した場合は、上記バッ
クプレッシャ制御に係る部分の機能を消勢（バイパス）
する。こうすれば、ハブＨ１の処理遅延は生じない。

【００６０】ところで、上記各収容端末テーブルＴＡＢ
の正確な運用は、ネットワークの変更時（ハブの設置
時、端末の増設／削除／移設時等）にネットワークの管
理者が各ポートの収容端末テーブルＴＡＢを更新するこ
とにより、実現可能である。しかし、この種のＬＡＮで
は、ハブやスイッチングハブを既存のネットワークに設
置する際に、ケーブルを接続するだけで、端末登録等の
処理が自動的に行われ、即座に運用（プラグ・アンド・
プレイ）できることが好ましい。そこで、各ポートにお
ける収容端末テーブルＴＡＢの生成・管理を、各ハブに
て自律的に行なう。

【００６１】なお、このために、ノード通知用パケット
送出部ＮＰＳはネットワークに設置後、定期的にノード
通知用パケットを送出する。図８は実施の形態による端
末登録処理のフローチャートである。ステップＳ２１で
はヘッダ情報検出部ＨＤＤは流入パケットの送信元アド
レスをチェックし、ステップＳ２２では該パケットがノ
ード通知用パケットか否かを判別する。アドレスの抽出
は最初に送出されたパケットから行なう。ノード通知用
パケットの場合はステップＳ２７で保持部ＦＬＧに下位
ノード検出の旨の情報「１」を保持し、処理を抜ける。

【００６２】なお、図示しないが、保持部ＦＬＧの内容
は、所定時間を経過しても次のノード通知用パケットが
検出されない場合は、リセットされる。また、上記ステ
ップＳ２２の判別でノード通知用パケットで無い場合
は、この例では通常の通信パケットである。ステップＳ
２３では収容端末テーブルＴＡＢを参照し、既登録アド
レスと一致するか否かを判別する。

【００６３】例えば、Ｈ２−Ｐ１の収容端末テーブルＴ
ＡＢに端末Ａが既に登録されており、該端末Ａがパケッ
トを送出した場合は、既登録アドレスＡと一致する。こ
の場合はそのまま処理を抜ける。しかし、例えばハブＨ
２のポートＰ１に新たに端末ａを追加した場合は、既登
録アドレスＡと一致しない。この場合は、ステップＳ２
４で下位ノード検出の旨の情報ＦＬＧ＝１か否かをチェ
ックし、ＦＬＧ＝０（直接）の場合は、ステップＳ２５
でＨ１−Ｐ１の収容端末テーブルＴＡＢに端末ａのアド
レス「ａ」及び直接収容「０」の情報を追加する。

【００６４】上記の処理は、中継段のハブＨ１でも同様
である。例えばハブＨ２のポートＰ０から新たに接続さ
れた端末ａからのパケットを受信した場合は、ステップ
Ｓ２３の判別で既登録アドレスＡと一致しない。但し、
この場合はステップＳ２４の判別でＦＬＧ＝１（間接）
であることにより、ステップＳ２６でＨ１−Ｐ１の収容
端末テーブルＴＡＢに端末ａのアドレス「ａ」及び間接
収容「１」の情報を追加する。

【００６５】なお、このような収容端末テーブルＴＡＢ
の記憶容量は有限であり、定期的に１テーブルの全内容
がリセットされ、又は新たな端末の登録があった時に最
も古い端末の登録が削除される。実際上、スイッチング
ハブＳＨ１にオーバフローを起こすようなアクティブな
端末は直ちにハブＨ１，Ｈ２の収容端末テーブルＴＡＢ
に再登録されるので、フロー制御、バックプレッシャ制
御に関しては何らの支障も生じない。

【００６６】図１１は実施の形態によるノード通知用パ
ケットのＭＡＣフレームフォーマットを示す図である。
このフォーマットはイーサネットにおけるオリジナルの
ＤＩＸ仕様と、後にこれを標準化したＩＥＥＥ８０２．
３仕様とに準拠している。「宛先アドレス」にはノード
通知用パケットであることを示すユニークな番号を入れ
る。更に「Ｉ／Ｇ」ビットはグループ（１）とし、「Ｕ
／Ｌ」ビットはローカル（１）とする。

【００６７】「送信元アドレス」にはノード通知用パケ
ットであることを示すユニークな番号を入れる。更に
「Ｉ／Ｇ」ビットはグループ（１）とし、「Ｕ／Ｌ」ビ
ットはローカル（１）とする。「タイプ」にはオーバフ
ロー通知用パケットであることを示すユニークな番号を
入れる。

【００６８】「ＬＬＣヘッダ」は、端末の上位レイヤに
とって無意味なビット列となし、論理リンク制御で破棄
される様にする。図９は実施の形態によるポートのハー
ドウエア構成を示す図で、図においてＳＦＲはシフトレ
ジスタ、ＤＥＣはデコーダ、ＦＦはフリップフロップ、
ＴＭはタイマ、ＣＳＧはコリジョン信号生成部、ＣＭＰ
はコンパレータ、ＲＥＧはレジスタ、ＳＱＣはシーケン
シャル制御部、ＯはＯＲゲート回路、ＮはＮＯＲゲート
回路、ＡはＡＮＤゲート回路である。

【００６９】デーコーダ１は流出パケットの「送信元ア
ドレス」＝「オーバフロー通知用パケット」を検出した
ことによりオーバフロー通知用パケット検出信号ＯＦＰ
＝１を出力する。一方、この場合のデコーダ２は過去の
流入パケットの「送信元アドレス＝ノード通知用パケッ
ト」を検出していないことにより、下位ノード検出の旨
の信号ＢＢを保持するフリップフロップＦＦはリセット
されている。従って、フォールス端子の出力信号ＢＢ／
＝１である。

【００７０】一方、コンパレータ５〜６はオーバフロー
通知用パケットの宛先アドレスと、レジスタ９〜１０の
収容端末登録アドレスＡ〜ａとを夫々比較しており、何
れかで一致が得られると、その＝端子に信号「１」を出
力する。これにより、ＯＲゲート回路Ｏが満足され、か
つＡＮＤゲート回路Ａも満足される。その結果、コリジ
ョン信号生成部ＣＳＧが付勢され、出力ポートにコリジ
ョン信号ＣＳを出力する。

【００７１】タイマ４はコリジョン信号生成部ＣＳＧが
付勢されて後の所定時間を計数し、タイムアウトＴＯす
るとコリジョン信号ＣＳの出力を停止させる。なお、フ
リップフロップＦＦが下位ノード検出の旨の信号ＢＢを
保持している場合（ハブがバックボーン側にある場合）
は、信号ＢＢ／＝０であり、コリジョン信号ＣＳは出力
されない。

【００７２】この場合に、タイマ３はノード通知用パケ
ットの検出の度にリスタートされるので、当該ポートに
端末が直接接続されるまではフリップフロップＦＦはリ
セットされない。一方、コンパレータ７〜８は流入パケ
ットの送信元アドレスと、レジスタ９〜１０の収容端末
登録アドレスＡ〜ａとを夫々比較しており、何れも一致
が得られないと、シーケンシャル制御部ＳＱＣを付勢す
る。

【００７３】シーケンシャル制御部ＳＱＣは、付勢され
た場合は、その時の流入パケットの送信元アドレスをレ
ジスタ９〜１０の何れか一つにシーケンシャルモードで
セットする。従って、新たな端末アドレスが登録される
場合に、最も古い登録の端末アドレスが抹消される。こ
のように、ポートをハードウェアで構成すれば、本発明
に係る各種機能は瞬時に行われ、遅延を生じない。

【００７４】なお、上記実施の形態では本発明に係る各
種機能を各ポートに分散配置したが、これはハードウエ
ア化、高速処理に好適である。但し、本発明に係る各種
機能をスイッチングハブ又はハブの共通の制御部にまと
めて設けても良い。また、上記実施の形態では本発明に
係る各種機能のフル実装の例を示したが、本発明の機能
は使用目的に応じた最小限の組合せにより実現されても
良い。

【００７５】また、上記バックボーンのスイッチングハ
ブＳＨ１にハブＨ１，Ｈ２の機能を追加しても良い。こ
うすれば、ネットワーク全体を共通のスイッチングハブ
ＳＨ１で構築又は置換できる。また、上記本発明に好適
なる実施の形態を述べたが、本発明思想を逸脱しない範
囲内で、構成、制御、及びこれらの組合せの様々な変更
が行えることは言うまでも無い。

【００７６】

【発明の効果】以上述べた如く本発明によれば、既存の
イーサネットに接続された端末を変更することなくＩＥ
ＥＥ８０３．２上での端末のフロー制御が可能となる。
また、スイッチングハブをＬＡＮの基幹部分に使用する
ことができ、その能力を有効に利用することが可能にな
る。

【図面の簡単な説明】

【図１】図１は本発明の原理を説明する図である。

【図２】図２は実施の形態によるフロー制御方式の構成
を示す図（１）である。

【図３】図３は実施の形態によるフロー制御方式の構成
を示す図（２）である。

【図４】図４は実施の形態によるフロー制御方式の構成
を示す図（３）である。

【図５】図５は実施の形態によるフロー制御方式の構成
を示す図（４）である。

【図６】図６は実施の形態によるオーバフロー通知用パ
ケット送信処理のフローチャートである。

【図７】図７は実施の形態によるコリジョン信号送出処
理のフローチャートである。

【図８】図８は実施の形態による端末登録処理のフロー
チャートである。

【図９】図９は実施の形態によるポートのハードウエア
構成を示す図である。

【図１０】図１０は実施の形態によるオーバフロー通知
用パケットのＭＡＣフレームフォーマットを示す図であ
る。

【図１１】図１１は実施の形態によるノード通知用パケ
ットのＭＡＣフレームフォーマットを示す図である。

【図１２】図１２は従来技術を説明する図である。

【符号の説明】

Ａ〜Ｖ通信機器ＳＨ１スイッチングハブＨ１，Ｈ２ハブＢＵＳバスＰ０〜Ｐ３ポートＩＢＦ入力バッファＵＲＤバッファ監視部ＦＬＣフロー制御部ＳＦＲシフトレジスタＨＤＤヘッダ情報検出部ＢＰＣバックプレッシャ制御部ＴＡＢ収容端末テーブルＴＢＣテーブル管理部ＦＬＧ保持部ＮＰＳノード通知用パケット送出部

───────────────────────────────────────────────────── フロントページの続き (72)発明者木村武志神奈川県川崎市高津区坂戸３丁目２番１号富士通ネットワークエンジニアリング株式会社内 (72)発明者井上英樹神奈川県川崎市高津区坂戸３丁目２番１号富士通ネットワークエンジニアリング株式会社内 (72)発明者永野博史神奈川県川崎市高津区坂戸３丁目２番１号富士通ネットワークエンジニアリング株式会社内 (72)発明者西村孝司神奈川県川崎市高津区坂戸３丁目２番１号富士通ネットワークエンジニアリング株式会社内 (56)参考文献特開平６−311161（ＪＰ，Ａ) 特開平６−216925（ＪＰ，Ａ) 特開平８−265356（ＪＰ，Ａ) 特開平９−116569（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁷，ＤＢ名) H04L 12/44

Claims

(57)【特許請求の範囲】

【請求項１】バックボーンのスイッチングハブとイー
サネット対応の端末機器を収容するフロントエンドのハ
ブ（マルチポートリピータ又はスイッチングハブ）とが
階層構造で接続するネットワークのフロー制御方式にお
いて、バックボーンのスイッチングハブは自己の入力ポートが
オーバフローする前に該入力ポートにパケットを送出し
ている端末宛のオーバフロー通知用パケットを生成して
当該ポートに送出し、これを受けたフロントエンドのハ
ブはオーバフロー通知用パケットの宛先端末を直接収容
するポートにコリジョン信号を送出することを特徴とす
るフロー制御方式。
【請求項２】バックボーンのスイッチングハブとイー
サネット対応の端末機器を収容するフロントエンドのハ
ブ（マルチポートリピータ又はスイッチングハブ）とが
階層構造で接続するネットワークのスイッチングハブに
おいて、入力ポートのバッファ使用率が所定の閾値を越えたこと
により、当該入力バッファに蓄積された最新パケットの
送信元アドレスを読み出すと共に、得られた送信元アド
レスを宛先アドレスとする所定のオーバフロー通知用パ
ケットを生成して当該ポートに送出するフロー制御部を
備えることを特徴とするスイッチングハブ。
【請求項３】オーバフロー通知用パケットは、その送
信元アドレスとして所要ネットワークについての予め規
定したユニークな番号を含むことを特徴とする請求項２
のスイッチングハブ。
【請求項４】バックボーンのスイッチングハブとイー
サネット対応の端末機器を収容するフロントエンドのハ
ブ（マルチポートリピータ又はスイッチングハブ）とが
階層構造で接続するネットワークのハブにおいて、ポートを通過するパケットのヘッダ情報を検出するヘッ
ダ情報検出部と、ヘッダ情報検出部が出力ポートを通過する所定のオーバ
フロー通知用パケットを検出したことにより、該パケッ
トの宛先端末を直接収容するポートに対してコリジョン
信号を送出するバックプレッシャ制御部とを備えること
を特徴とするハブ。
【請求項５】ポート別に収容端末のアドレス情報及び
該収容が直接か間接かを示す情報を保持する収容端末テ
ーブルを備え、バックプレッシャ制御部は、ポート対応の収容端末テー
ブルに基づき当該宛先端末の収容が直接か間接かを判別
することを特徴とする請求項４のハブ。
【請求項６】ヘッダ情報検出部が入力ポートを通過す
る通信パケットについて新たな送信元アドレスの情報を
検出したことにより、収容端末テーブルの内容を更新す
るテーブル管理部を備えることを特徴とする請求項５の
ハブ。
【請求項７】所定のノード通知用パケットを保持し、
これをポートに定期的に送出するノード通知用パケット
送出部を備えることを特徴とする請求項４のハブ。
【請求項８】ノード通知用パケットは、その宛先アド
レス及び送信元アドレスとして所要ネットワークについ
ての予め規定したユニークな番号を含むことを特徴とす
る請求項７のハブ。
【請求項９】ヘッダ情報検出部が入力ポートを通過す
る所定のノード通知用パケットを検出したことにより、
下位ノード検出の旨の情報を保持する保持部を備えるこ
とを特徴とする請求項４のハブ。
【請求項１０】ノード通知用パケットは当該入力ポー
トで破棄されることことを特徴とする請求項９のハブ。
【請求項１１】保持部の下位ノード検出の旨の情報
は、ヘッダ情報検出部が所定時間の間入力ポートを通過
するノード通知用パケットを検出しないことによりリセ
ットされることを特徴とする請求項９のハブ。
【請求項１２】バックプレッシャ制御に係る機能は保
持部が下位ノード検出の旨の情報を保持していることに
より消勢されることを請求項９のハブ。
【請求項１３】ヘッダ情報検出部が入力ポートを通過
する所定のノード通知用パケットを検出したことによ
り、下位ノード検出の旨の情報を保持する保持部を備
え、テーブル管理部は保持部が下位ノード検出の旨の情報を
保持していることにより収容端末テーブルの収容情報を
間接にして更新することを特徴とする請求項６のハブ。