(57)【要約】      （修正有）【課題】スタック型スィッチング・システムを制御する装置および方法に関する。【解決手段】スタック型スィッチング・システムは、ネットワーク・バックプレーンを介して相互に接続された複数のスィッチを有する。上記スタック型システムにおける各スィッチの内の１個のスィッチはマスタ・ユニットとして指定される一方、残りの各スィッチはスレーブ・ユニットとして指定される。上記複数のスィッチの間でマスタ機能を割当てる２つのトポロジ設計態様を開示する。第１のトポロジ設計態様は固定トポロジと称され、第２のトポロジ設計態様は動的トポロジと称される。これらの２つのトポロジ設計態様は両者ともに、最高の優先順位インデックスを有するスィッチに対してマスタ制御を割当てる。【選択図】図１
2007124673.tif 000002
【特許請求の範囲】
【請求項１】
優先順位インデックスを一組のスイッチの各スイッチに割り当てることであって、各スイッチはマスタスイッチとして動作するように構成され、
前記一組のスイッチをネットワーク・バックプレーンに接続すること、
前記一組のスイッチの優先順位インデックス値を比較した後、その優先順位インデックス値に基づいてマスタスイッチを割り当てることであって、残りのスイッチはスレーブスイッチとして動作すること、
マスタスイッチとして動作するように構成された一組のスイッチに含まれないスイッチをネットワーク・バックプレーンに接続すること、
優先順位インデックスを接続されたスイッチに割り当てること、
第１のマスタスイッチの優先順位インデックス値が接続されたスイッチの優先順位インデックス値よりも小さいときに、第１のマスタスイッチをスレーブとして再割り当てすること、
第１のマスタスイッチの優先順位インデックス値が接続されたスイッチの優先順位インデックス値よりも小さいときに、接続されたスイッチを第２のマスタスイッチとして割り当てること、
スイッチの接続、スイッチの再割り当て、そしてスイッチの割り当ては、一組のスイッチをリブートすることなくおよび一組のスイッチをリブートする時に、自動的に実行されること、
を特徴とするスイッチスタックを動作させる方法。
【請求項２】
さらに、前記マスタスイッチから前記スレーブスイッチへファームウェアをダウンロードすることを含む請求項１記載の方法。
【請求項３】
さらに、トポロジ・テーブルを前記スレーブスイッチにダウンロードすることを含む請求項１記載の方法。
【請求項４】
さらに、機器構成データを前記マスタスイッチ内で規定することを含む請求項１記載の方法。
【請求項５】
さらに、前記機器構成データを前記スレーブスイッチにダウンロードすることを含む請求項４記載の方法。
【請求項６】
割り当ては、スタックスイッチのトポロジ変更の後に実行される請求項１記載の方法。
【請求項７】
マスタスイッチは第１のマスタスイッチであり、方法はさらに、第１のマスタスイッチに与えられた電力が除去され、そして一組のスイッチからのスイッチの優先順位インデックス値が、第１のマスタスイッチを除く一組のスイッチからの残りのスイッチの優先順位インデックス値よりも小さくないときに、前記一組のスイッチからのスイッチを第２のマスタスイッチとして割り当てる、請求項１記載の方法。
【請求項８】
マスタスイッチとして動作するように構成され、優先順位値と関連する第１のスイッチと、
マスタスイッチとして動作するように構成され、優先順位値と関連し、前記第１のスイッチと結合された第２のスイッチと、
第１のスイッチの優先順位値が第２のスイッチの優先順位値よりも大きいときに、第１のスイッチはマスタスイッチとして指定され、そして第２のスイッチはスレーブスイッチとして指定されるように構成され、
第１のスイッチ及び第２のスイッチと結合され、マスタスイッチとして動作するように構成され、優先順位値と関連する第３のスイッチであって、第１のスイッチの優先順位値が第２のスイッチの優先順位値よりも大きいときに、第３のスイッチはマスタスイッチとして指定され、そして第２のスイッチはスレーブスイッチとして再指定されるように構成され、
少なくとも第１のスイッチ、第２のスイッチそして第３のスイッチの１つが、そのスイッチをリブートすることなくおよびそのスイッチをリブートする時に、マスタスイッチ及びスレーブスイッチの１つからのその指定を残りの指定に変更するように自動的に構成されることを特徴とする装置。
【請求項９】
さらに、ネットワーク・バックプレーンと、ネットワーク・バックプレーンに結合された第１のスイッチ及び第２のスイッチから成ることを特徴とする請求項８に記載の装置。
【請求項１０】
第１のスイッチは第２のスイッチと関連する優先順位値を受信するように構成され、第２のスイッチは第１のスイッチと関連する優先順位値を受信するように構成されることを特徴とする、請求項８記載の装置。
【発明の詳細な説明】
【背景技術】
【０００１】
発明の背景
本発明は、個々の入力および宛先リソース間でデータのスィッチング(switching)を行うためのコンピュータ・ネットワーク・アーキテクチャに関する。より詳細には本発明は、単一のスタック型スィッチング・システム(stacked switching system)として一体的に接続された複数のスィッチを制御する装置および方法を開示する。
【０００２】
例えばコンピュータ端末などの複数の入力／宛先リソース間でデータを相互接続してスィッチングを行う従来のスィッチング・システム(switching system)は、急速に発展する技術分野となっている。しかし、入力／宛先リソースの個数が増加するにつれ、単一スィッチによりサポートされるポートの個数では、最新式システムのネットワーク・トラフィックの要件をもはや処理し切れない。これに加え、最新式の仮想ローカル・エリア・ネットワーク(VLAN)環境の急増の故に、非常に多数のユーザおよび／またはワークグループを処理し得る経済的で高性能なスィッチング・システムに対する要望が増している。
【０００３】
イーサネット（登録商標）・スィッチは当初、Kalpana（登録商標）がオリジナルのイーサネット（登録商標）・スィッチを発売した1991年に出現した。尚、イーサネット（登録商標）の観点からスィッチとは、長年に亙り存在して来たまさにマルチポート・ブリッジ(multiport bridge)である。技術的には、ブリッジング(bridging)はOSIレイヤ2の機能であり、今日における一般的なイーサネット（登録商標）規格、トークンリング、FDDIなどの３種の異なるネットワーク規格の全てがブリッジされ得る。これまでのブリッジから今日のスィッチを区別するものは、これらの最新式マルチポート・ブリッジの特徴および用法である。
【０００４】
数年前は、２つの異なるローカル・エリア・ネットワーク(“LAN”)を相互に接続すべく、２ポート・イーサネット（登録商標）・ブリッジが使用されていた。而してコンピュータメーカは、本質的には相互に接続された多数の２ポート・ブリッジであるインテリジェント・マルチポート・ブリッジの構築を開始した。今日においては、これらのマルチポート・ブリッジが強化されてスィッチ(switch)と称されている。これらのスィッチは今や、既存のネットワーク内で使用され、大規模なLANを多数の小規模LANへと分離もしくはセグメント化している。
【０００５】
一方、リピータ(repeater)は、受信したイーサネット（登録商標）・フレームの良否に関わらず該イーサネット（登録商標）・フレームを無差別に再生して順方向送信(forward)するネットワーク・デバイスである。リピータはネットワークの受動的もしくは共有的な構成要素として知られている、と言うのも、リピータは到来フレームに対して論理的に作用しないからである。リピータは単に到来信号を再生し、ネットワークの範囲を拡大するものである。この様にしてリピータは衝突もしくはエラーなどのネットワーク事象に対して不可視であり、斯かる事象も一緒に伝搬してしまう。故にリピータは、ネットワークの衝突領域(collision domain)を拡大し得る。換言すると、リピータは既存のネットワークを延長するにすぎない。
【０００６】
これと全く異なり、ブリッジは異なるイーサネット（登録商標）LANを接続する。より詳細には、ブリッジは到来フレームを再送信する前に基本的なフレーム・フィルタリング機能を実施する。また、リピータは全てのフレームを順方向送信するが、ブリッジは必要なフレームのみを順方向送信する。もしフレームが順方向送信される必要がなければ、ブリッジはそのフレームを除外(filter out)する。
【０００７】
たとえばブリッジは、トラフィックを選別することにより、ひとつのイーサネット（登録商標）LANから別のイーサネット（登録商標）LANへの不要なネットワーク・トラフィックを排除すべく使用され得る。ブリッジはまた速度整合も行う：通常の10Mbpsイーサネット（登録商標）は100Mbps高速イーサネット（登録商標）に対してブリッジによってのみ接続され得る。
【０００８】
詳細には全てのイーサネット（登録商標）・フレームは、宛先アドレスおよびソース・アドレスとして定義された２個のフィールドを有している。これらの２個のフィールドはブリッジに対し、そのフレームが何処で発信され且つ最終的には何処に宛てられるかを知らせる。ブリッジは到来イーサネット（登録商標）・フレームを検査し、そのフレームのヘッダ内で定義された宛先アドレスを分析する。この情報から上記ブリッジは、自身の内部メモリを過去の各フレームに対してチェックし、且つ、そのフレームを別のポートに順方向送信するかそのフレームを除外するかを、すなわち、何も行わないかそのフレームを廃棄するかを決定し得る。この様にしてブリッジは、各ネットワーク・セグメント間におけるネットワーク・トラフィックを遮断し得る。一定の場合にブリッジはエラーもチェックし、損傷したもしくは不完全なフレームの順方向送信を行わないこともできる。
【０００９】
ブリッジは、良好な郵便メール配達システム(postal mail delivery system)の様に作動する。すなわちブリッジは、該ブリッジが奉仕する区域における全ての者の位置を正確に認識する。ブリッジは該ブリッジが奉仕する区域内で所期の受取人に対してのみメールを配達し、すなわち、全てのエンベロープ(envelope)の住所を検査してそのエンベロープをその特定アドレスに配達するのである。もしエンベロープもしくはフレームが損傷されもしくはエラーを含むなら、ブリッジ・メール・システムはそのメールを所期の受取人に対して配達も順方向送信もしない。更に、もしエンベロープまたはフレームが別のブリッジにより奉仕される区域に属するアドレスを表すなら、そのエンベロープもしくはフレームはその別のブリッジへと中継される。
【００１０】
リピータは、非常に多様に作動する。リピータ・メール・システムは、メール配信に対して強制的(brute-force)手法を用いる。すなわちリピータは受信した全てのメールのコピーを作成し、該コピーを、対象者と対象者の区域の全員とに対して配信する。その区域では全員が、対象者自身のメールだけでなく他の全員のメールのコピーも獲得してしまう。
【００１１】
スタック可能リピータ(stackable repeater)は、拡張選択肢を備えたリピータと見做され得る。スタック可能リピータは、各々が所定数のポートを備えた数個の独立したユニットから成る。各ユニットはそれ自身の権利においてスタンドアロンリピータとして作用すると共に、厳密に当該ユニット自身の如き付加的ユニットを付加するための外部接続も有している。各スタック可能リピータは共有媒体用のデバイスであることから、一連のハブ(hub)に対する実効帯域幅は、夫々のハブにおいて何個のポートが在るかに関わらず常に同一である。付加されるポートの個数が多いほど、任意の所定ポートが利用可能な平均帯域幅は少ない。
【００１２】
スタック可能リピータのアップグレード性とポート当たりの低廉コストにより、スタック可能リピータはハブ市場全体において最も急速に成長している部分である。スタック可能リピータによれば、LAN管理者はスタック全体を管理すべく単一の管理ユニットを購入することで、管理コストを多数のポートに割当て得る。スタック可能リピータはまた、関連するネットワーク距離の制限の故に、イーサネット（登録商標）上において多数のノードを接続する上でも極めて有用である。
【００１３】
スタック可能リピータは、高速のスタッキング・バス(stacking bus)により相互にリンクされ乍らも依然として同一の衝突領域を共有するという複数のスタンドアロンリピータと類似している。これによればスタック可能リピータは、本質的に１個の大型のリピータの様にしてネットワークの残部を検査する。尚、スタック可能リピータは現在では10Base-Tおよび新たな10/100バージョンにおいて非常に普及している。
【００１４】
スタック可能リピータは普及しつつある、と言うのも、スタック可能リピータはポート当たりのコストを低くし乍ら複数の接続を提供すると共に、管理可能であってアップグレードも容易であり、且つ、大規模LANの典型的な階層ネットワーク構造に良好に適合するからである。
【００１５】
ネットワーク・トラフィックの要求が高まるにつれ、スィッチに接続される更に多数のポートに適合するために新たなスィッチ設計態様が必要となる。スタック型スィッチング・システムを形成すべく複数のスィッチを組合せる試みは行われて来た。しかし、スタック型管理機能(stacked management function)の取り扱いは極めて複雑であることから、複数のスィッチを組合せて単一のスタック型スィッチング・システムとすることは極めて困難であった。現在においては幾つかのスタック可能スィッチが市場で入手可能であるが、これらのスタック可能スィッチの殆どは、スタック型システムにおける種々のスィッチを連携調整すべく、専用のシステム管理ユニットを必要とする。幾つかの従来の設計態様においてこの専用システム管理ユニットは、スタック型管理ソフトウェア／ファームウェアを備えた別体のハードウェア構成要素である。このシステム管理ユニットを上記スタック型スィッチング・システムにおけるスィッチ・ユニット(switch unit)の各々に接続することにより、上記システム管理ユニットは上記スタック型システムのマスタ制御器(master control)として作用する。しかし、斯かる別体のシステム管理ユニットは上記スタック型スィッチング・システムのコストおよび物理的寸法を大幅に増大する。この故に、新たなスタック型スィッチング・システムを形成する上では本発明において開示された如く複数のスィッチを相互に組合せる新規な方法が望まれるのである。
【発明の開示】
【発明が解決しようとする課題】
【００１６】
発明の要約
故に本発明の目的は、複数のスィッチング・ユニット(switching unit)を接続する方法を提供するにある。
本発明の他の目的は、複数のスィッチング・ユニットを組合せて単一のスタック型スィッチング・システムを形成するに在る。
本発明の別の目的は、スタック型スィッチング・システムとして接続された各スィッチに対して融通性のある制御法を提供するに在る。
本発明の更なる目的は、スタック型スィッチング・システムを制御するための多数の設計トポロジ(design topology)を提供するに在る。
【課題を解決するための手段】
【００１７】
本発明は、スタック型スィッチング・システムを制御する装置および方法を開示する。本発明に係るスタック型スィッチング・システムは、ネットワーク・バックプレーンを介して相互に接続された複数のスィッチを備える。上記スタック型システムにおける各スィッチの内の１個のスィッチはマスタ・ユニットとして指定される一方、残りの各スィッチはスレーブ・ユニットとして指定される。本発明は、上記複数のスィッチの間でマスタ機能を割当てる２つのトポロジ設計態様を開示する。第1のトポロジ設計態様は固定トポロジと称され、第2のトポロジ設計態様は動的トポロジと称される。これらの２つのトポロジ設計態様は両者ともに、最高の優先順位インデックスを有するスィッチに対してマスタ制御を割当てる。このマスタ制御の割当ては、上記システムに対するスィッチング・ユニットの除去もしくは付加などのトポロジ変更が行われる毎に実施される。上記固定トポロジ設計態様に関し、マスタ制御割当ては上記システムをリブートした後にのみ実施され得る。一方、上記動的トポロジ設計態様に関し、マスタ制御割当ては“処理継続中に”実施され得るが、このことは、上記マスタ制御割当てが上記システムのリブートを必要とせずに実施され得ることを意味する。
【００１８】
本発明の種々の見地の更なる目的、特徴および利点は、添付図面を参照して行われる好適実施例の以下の説明から明らかとなろう。
【発明を実施するための最良の形態】
【００１９】
図面の詳細な説明
本発明に依れば、スタック型スィッチング・アーキテクチャが記述される。複数のスィッチ・ユニットが、単一のマスタ・ユニットと複数のスレーブ・ユニットとを含むスタック型スィッチング・システムとして接続される。好適実施例において、上記スィッチ・ユニットの各々は設計態様が同様であり且つ各スタック用リンク(stacking link)を介して相互に接続される。本発明は更にスィッチ・ユニットを接続する上で２通りの設計方法を開示する：固定トポロジおよび動的トポロジである。
【００２０】
上記固定トポロジにおいては、システムがブートアップされた後に、各スィッチ・ユニットのひとつがマスタ・ユニットとして指定される。上記マスタ・ユニットに対しては、接続された全てのスィッチ・ユニットの中で最高の優先順位インデックス(priority index)が割当てられる。システム・ブートアップの間において、上記ユニットの各々は比較のために自身の優先順位インデックスを他のユニットに送信する。他の全てのユニットの各優先順位インデックスを受信すると上記ユニットの各々は、該ユニット自身が最高の優先順位インデックスを有するか否かを決定する。最高の優先順位インデックスを有するユニットが上記システムのマスタ・ユニットになるが、残る全てのユニットはスレーブ・ユニットとなる。上記マスタ・ユニットの特定の役割は、以下の各段落において詳述される。更に上記固定トポロジにおいて、一切のトポロジ変更は、システム全体および／または接続された各ユニットのリブート(reboot)を必要とする。上記システムをリブートすることにより、新たなマスタ・ユニットが選定される。この新たなマスタ・ユニットは次に、スタック型システムの特性を決定するとともに、スタッキングおよびスパンニング・ツリー・プロトコル(stacking and spanning tree protocol)に対するトポロジ・テーブルを生成する。
【００２１】
本発明に係る上記動的トポロジ設計態様において上記スタック型スィッチング・システムは、システムのリブートを必要とせずにトポロジの変更に対して順応し得る。特に、現在マスタ・ユニットおよびスレーブ・ユニットの各々はマスタ／スレーブ関係の再割当に対して自身をリブートする必要はない。たとえば、現在マスタ・ユニットよりも高い優先順位を有する新たなユニットが上記システムに付加されたとき、上記システムは該システムをリブートする必要なしで、新たに付加された上記ユニットを新マスタ・ユニットに再割当てする。現在のマスタ・ユニットは上記システムをリブートすることなく、上記新マスタ・ユニットに対してマスタ制御を“譲る”だけである。
【００２２】
この特徴はシステム・トポロジを“処理継続中に(on-the-fly)”変更し得ることから、上記動的トポロジ・システムによればシステムのリブートによる不利益を受けずにシステム設計態様の相当の融通性が提供される。
【００２３】
好適実施例において上記スタック型スィッチング・システムは、複数のスィッチング・ユニットを備えたマスタ／スレーブ式スィッチング・システムである。上記各スィッチング・ユニットのひとつはマスタ・ユニットとして指定されると共に残りは各々スレーブ・ユニットとして指定される。上記マスタ・ユニットは全てのユニットの中で、スタック型管理機能を実施する役割を果たす。これに加えて上記マスタ・ユニットは、一切のSNMPコマンドに応答すると共にSNMPエージェントなどを介してSNMPマネージャに対し各対応値を戻すなどの様に、SNMPマネージャと通信する役割を果たす。上記マスタ・ユニットは更に、全てのユニットの中で制御用トポロジ(controlling topology)を生成、維持および更新する。
【００２４】
概略的に上記マスタ・ユニットは次の機能を行う：(1)上記スタック型スィッチング・システムを管理し；(2)SNMP要求を処理し；且つ、(3)上記システムのトポロジ配向を維持すること。
【００２５】
上記固定トポロジにおいてマスタ・ユニットは先ず、上記システムに対してスレーブ・ユニットが取付けられているか否かを検出する。もし少なくとも一個のスレーブ・ユニットが上記スタック型システムに取付けられていれば、上記マスタ・ユニットは上記スタック型システムに対するトポロジ・テーブルを生成すると共に、システムにおける全てのユニットに対するトポロジ表示(topology discovery)を更新する。これに加えて上記マスタ・ユニットは、該マスタ・ユニットおよび各スレーブ・ユニットの両者を含め、上記システムにおける全てのユニットにおける各ポート制御器を初期化する。更に上記マスタ・ユニットは、該マスタ・ユニットと各スレーブ・ユニットとの間の各スタック用リンクをサポートすべく、静的順方向送信テーブル(static forwarding table)を設定する。
【００２６】
上記スタック型スィッチング・システムにおけるいずれかのユニットに対し上記マスタ・ユニットとは異なるバージョンのファームウェアが装填された場合、上記システムにおける各ユニットが同一バージョンで動作するのを確実にすべく、上記マスタ・ユニットは自身のファームウェアを各スレーブ・ユニットに対してダウンロードする。好適実施例において上記ファームウェアは種々のプログラミング・コード群を備えるが、これらのプログラミング・コードは、上記スタック機能を制御し、他のスタック・ユニット(たとえばマスタ・ユニットおよび他の各スレーブ・ユニット)とインタフェースし、且つ、各ユニットにおける個々のポートを制御して種々のリソースと通信したりするものである。上記ファームウェアの構造の一例は、本明細書の図５に示される。
【００２７】
本発明に係る上記動的トポロジ設計態様において、上記マスタ・ユニットは上記固定トポロジにおいて上述された全ての役割も果たさねばならない。しかし、この設計態様は動的トポロジ設計態様であることから、現在のマスタ・ユニットから次のマスタ・ユニットへのマスタ機能の切換えは、上記システムをリブートする必要なしで“処理継続中に”実施される。上記システムのトポロジを動的に変更することで、ユニットの付加および／または除去により引き起こされるシステムの不稼働期間は排除される。
【００２８】
上記固定トポロジ設計態様において、上記システムにおける種々のユニット間のトポロジは、システム全体がシャットダウンもしくはリブートされなければ変更され得ない。換言すると、マスタ・ユニットよりも高い優先順位インデックスを有する新たなユニットが上記システム内に導入されたとき：(1)現在のマスタ・ユニットが全てのスレーブに対する該マスタ・ユニットの制御を放棄し得ると共に；(2)新マスタ・ユニットが上記システムの制御を引き継いで新たなホスト・ユニットとなり得る；如く上記システムはリブートされる必要がある。
【００２９】
本発明の上記固定トポロジは簡単なファームウェア制御のみを必要とすることから更に簡素なシステムを提供することを銘記されたい。但し上記固定トポロジ設計態様の不都合は、上記システムにおいてトポロジ変更(すなわちユニットの除去もしくは付加)があったときに上記システムのリブートが必要なことである。
【００３０】
図１は、本発明に係るスタック型スィッチング・システム100の一実施例を示している。図示される如く、上記好適なシステムは１個のマスタ・ユニット110および１個のスレーブ・ユニット120を備える。この特定設計態様においてスレーブ・ユニット120は３本のスタック用リンク130a、130b、130cを介して現在のマスタ・ユニット110に接続される。これらの３本のスタック用リンク130a、130b、130cの各々は、マスタ・ユニット110およびスレーブ・ユニット120の夫々のスタック用ポートに接続される。図示例において、ユニット１ 110は全てのマスタ機能を行うべき現在マスタ・ユニットであり、ユニット２ 120は基本的に受動ユニットであるスレーブ・ユニットである。上述の如く、マスタ・ユニット110およびスレーブ・ユニット120は、これらの２個のユニット110、120間の通信の為に３本のスタック用リンク130a、130b、130cにより接続される。これらの３本のスタック用リンク130a、130b、130cは、上記スタック型スィッチング・システムの通信バックプレーンとして作用する。尚、種々のユニット間のスタック用リンクの本数は、これらの２個のユニット間の通信容量に依存することを銘記されたい。上記本数は、設計態様および実際の要件に依存して変更され得る。好適実施例においては、ユーザとの対話のために上記マスタ・ユニットに対して(不図示の)コンソール画面が接続される。
【００３１】
好適実施例において、上記スタック型スィッチング・システムのユーザは、各ユニットの優先順位インデックスを指定する。各ユニットの優先順位インデックスを設定することにより、上記システムの初期ブートアップの間においては指定された各優先順位インデックスに基づきマスタ／スレーブ指定が割当てられる。
【００３２】
本発明の固定トポロジ設計態様に依れば、機能しているスタック型スィッチング・システムにおいて一個以上のユニットから電力が落とされたとすれば、残る各ユニットはマスタ選定プロセスが実施される前にリセット且つリブートされる。もし後で別のユニットが上記スタック型システムに再接続されたなら、上記システムは再び自動的にリセットされることから、上記システム内の全てのユニットは再び該システムの新マスタ・ユニットを選定する。この新マスタ・ユニット選定プロセスは“自動トポロジ(auto-toplogy)”設計とも称され得ると共に、以下の段落で詳述される。
【００３３】
本発明に係る動的トポロジ設計態様においても、(1)スタック型システムに新ユニットが接続され；且つ、(2)既存ユニットがスタック型システムから除去されたときには、同様の新マスタ・ユニット選定プロセスが実施される。但し上記動的トポロジ設計態様に依れば、上記新マスタ・ユニット選定プロセスはシステムのリブートを必要とせずに“処理継続中に”実施される。これが、本発明の固定トポロジ設計態様および動的トポロジ設計態様の間の主な相違である。
【００３４】
先行段落において述べられた如く、本発明の別の特徴は、マスタ・ユニット選定プロセス設計態様である(又は、自動トポロジ設計態様と称される)。本発明のこの見地は、相互に接続された任意数のスィッチング・ユニットを有するスタック型スィッチング・システムをサポートする。好適実施例のマスタ・ユニット選定プロセスにおいて、最高の優先順位インデックスを有するユニットは、現在マスタ・ユニットとして選定される。その現在マスタ・ユニットに対しては、上記システムの全てのマスタ機能が割当てられる。先行段落において記述された如く、各ユニットに対してはシステムのブートアップの前に固有の優先順位インデックスが割当てられる。好適実施例において各優先順位インデックスは、該当する特定ユニットに関して期待されるネットワーク・トラフィックなどの目的用件に基づき、または、システムにおける各ユニット間の物理的接続に基づき、ユーザにより割当てられ得る。
【００３５】
システム・ブートアップの間において上記スタック型スィッチング・システムの全てのユニットはマスタ・ユニット選定プロセスに入り、マスタおよびスレーブ・ユニットの割当てを決定する。本発明の一実施例において、上記選定プロセスは定期的に、且つ／又は、システムにおけるユニットの付加もしくは除去が行われる毎に、実行される。たとえば現在マスタ・ユニットが電力を喪失しもしくはスタックから除去されたときには、残る全てのユニットの中から新マスタ・ユニットが選定される。一方、システムに対して新ユニットが接続されたとき、もし該新ユニットが現在マスタ・ユニットより高い優先順位インデックスを有するならば該新ユニットが現在マスタ・ユニットに代わり新マスタ・ユニットとなる。尚、上記動的トポロジ設計態様においてはこれらのトポロジ変更の全てはシステム全体のリブートを必要とせずに“処理継続中に”実施される。
【００３６】
図２は、本発明に係る動的トポロジ設計態様を採用したスタック型スィッチング・システムの別の好適実施例200を示している。示されたスタック型スィッチング・システム200は２個のスタック・ユニットを備える：ユニット１ 210およびユニット２ 220。図２に示された如く２個のスタック型スィッチング・ユニット210、220の配置は、ユニット１ 210およびユニット２ 220の間の各スタック用リンクが別様に接続された以外は、図１に示された実施例と同様であることを銘記されたい。図２に示された好適実施例においては、ユニット１ 210が現在マスタ・ユニットであり、ユニット２ 220はスレーブ・ユニットである。この動的トポロジ設計態様と図１に示された上記固定トポロジ設計態様との間の差は、該動的トポロジ設計態様に依ると(不図示の)新マスタ・ユニットがスタック型スィッチング・システム200に接続されたときに上記現在マスタ・ユニット(すなわちユニット１ 210)により現在において保持されているマスタ機能が上記新マスタ・ユニットに対して自動的に移転されることである。
【００３７】
図２に示された好適実施例は、本発明に係る固定トポロジ設計態様および動的トポロジ設計態様の両者に対して使用され得ることを銘記されたい。
【００３８】
上記動的トポロジ設計態様において、新マスタ・ユニットに対するマスタ機能の再割当ては、上記スタック型スィッチング・システムのリブートを必要とせずに該システムにより実施される。特に、新マスタ・ユニットの付加を検出すると同時に、上記システム内で接続された全てのスィッチング・ユニット(すなわちユニット１、ユニット２および図示されない新マスタ・ユニット)は、上記マスタ・ユニット選定手順を実施し、上記新マスタ・ユニットが選定される。上記マスタ・ユニット選定手順の全体および引き続く新マスタ・ユニットの再割当ては、“処理継続中に”実施される。上記割当てプロセスの間においては、上記新マスタ・ユニットが新トポロジ・テーブルを生成して他の種々の動作を実施することも銘記されたい。
【００３９】
一方、上記固定トポロジ設計態様においては、システム全体をリブートした後においてのみ、同一のマスタ機能再割当プロセスが実施され得る。
【００４０】
図３は、本発明に係る別実施例を示している。示されたスタック型スィッチング・システム300は、３個のスタック型スィッチング・ユニット(すなわちユニット１、ユニット２およびユニット３)を備える。図示された如く、ユニット１ 310は最高の優先順位番号(すなわち１)を有するスィッチング・ユニットであり、ユニット２ 320およびユニット３ 330は２番目および３番目に高い優先順位番号(すなわち２、３)を有する。故に、マスタ・ユニット選定プロセスの後で、ユニット１ 310はシステムの現在マスタ・ユニットとして指定される。ユニット２ 320およびユニット３ 330はシステムの各スレーブ・ユニット(すなわち第1スレーブ・ユニットおよび第2スレーブ・ユニット)として指定される。図３は、上記マスタ・ユニット(すなわちユニット１ 310)と第1スレーブ・ユニット(すなわちユニット２ 320)とを接続する２本のスタック用リンク340a、340bが在ることを示している。これに加え、上記マスタ・ユニット(すなわちユニット１ 310)と上記第2スレーブ・ユニット(すなわちユニット３ 330)とを接続する１本のスタック用リンク340cも在る。尚、不図示の別実施例においては、第1スレーブ・ユニット(すなわちユニット２ 320)のポート3と第2スレーブ・ユニット(すなわちユニット３ 330)のポート2もしくは3との間に別のスタック用リンクが存在し得ることも銘記されたい。これらの２本の冗長接続は、２個のスレーブ・ユニット間の付加的データ通信を処理すべく使用され得る。
【００４１】
再び、図３に示された好適実施例は上記固定トポロジ設計態様および動的トポロジ設計態様の両者に対して使用され得ることを銘記されたい。
【００４２】
図４は、本発明に係る上記固定トポロジ設計態様または動的トポロジ設計態様のいずれかを採用する本発明の更なる別実施例を示している。示されたスタック型スィッチング・システム400は、４個のスタック型スィッチング・ユニット(すなわちユニット１ 410、ユニット２ 420、ユニット３ 430およびユニット４ 440)を備える。該実施例においてこれらの４個のユニットには、優先順位番号１、２、３、４が夫々割当てられる。マスタ選定プロセスにおいては割当てられた各優先順位番号に基づき、ユニット１ 410は該スタック型システムのマスタとして指定され、且つ、ユニット２ 420、ユニット３ 430およびユニット４ 440は該システムの各スレーブとして指定される。図示された如く、上記マスタ・ユニット(すなわちユニット１ 410)はユニット２ 420のポート3に接続される。マスタ・ユニット(すなわちユニット１ 410)のポート2は、ユニット３ 430のポート2に接続される。最後に、マスタ・ユニット(すなわちユニット１ 410)のポート3はユニット４ 440のポート1に接続される。このスタック接続は基本的に、マスタ・ユニット(すなわちユニット１ 410)が当該スタック型スィッチング・システムの中心の役割を果たすという“スター型”ネットワーク・システムを確立することを銘記されたい。但しネットワーク性能と冗長目的の為に、図示された各スレーブ・ユニットは(たとえばユニット２ 420のポート1および2、ユニット３ 430のポート1および3、ならびに、ユニット４ 440のポート2および3などの)未使用ポート間でも接続され得る。これらの３個のスレーブ・ユニット(すなわちユニット２ 420、ユニット３ 430およびユニット４ 440)を接続することにより、これらの３個のユニットの内の１個は、現在マスタ・ユニット(すなわちユニット１ 410)が上記システムから除去されたときまたはダウンしたときに、新マスタ・ユニットを引き継ぎ得る。この場合には、ユニット２ 420が残る全てのユニットの中で最高の優先順位割当てを有することから、現在マスタ・ユニット(すなわちユニット１ 410)がスタック型スィッチング・システム400から除去されたときにユニット２ 420が新マスタ・ユニットを引き継ぐ。示されたスタック型スィッチング・システム400は本発明に係る動的トポロジの下で設計されることから、上記マスタ制御は処理継続中に(すなわちシステムのリブートを要さずに)、去り行く現在マスタ・ユニット(すなわちユニット１ 410)から新マスタ・ユニット(すなわちユニット２ 420)へとシフトされる。このことは特に、現在マスタ・ユニット(すなわちユニット１ 410)から新マスタ・ユニット(すなわちユニット２ 420)への制御の移転が各接続ポートの全てに対してトランスペアレントであることを意味する、と言うのも、マスタ機能の移転の間においてスタック型システム400の機能性は維持されるからである。
【００４３】
先行段落において述べられた如くこの動的トポロジ設計態様の主な利点は、リブートの為にシステムのシャットダウンを要さずにシステムに対してスィッチング・ユニットを付加しまたはシステムからスィッチング・ユニットを除去するのを許容することである。これにより、ユーザに対してはシステム設計態様の相当の融通性が与えられる。
【００４４】
図５は、本発明に係るスタック型スィッチング・システムにおいて使用されるファームウェア・アーキテクチャ500の好適実施例のブロック図である。図示された如く、上記ソフトウェア・システムは３つのレベルを備えている：スィッチ空間SWITCH 510、インタフェース空間API 520およびハードウェア／OS空間530である。
【００４５】
第1レベルにおいて上記ファームウェア・システムは、各スィッチング・ユニットにおける基本的なスィッチング機能(switching function)を処理するスィッチ空間SWITCH 510を備える。このレベルは、標準的なSNMP管理情報ベース(“MIB”)をサポートするとともに付加的な標準およびエンタープライズMIBもサポートし得るSNMPエージェント511と；RMONを維持する遠隔監視グループMIBエンジンRMON 512と；TCP/IP、IP、UDP、APR、ICMPおよび他のプロトコルをサポートするBSDライト派生モジュールBSD 513であって、この完全に機能的なBSDスタックが完全に埋設されたネットワーク開発環境に対する完全なBSDランタイム・ライブラリ・サポートを含む、BSDライト派生モジュールBSD 513と；ブリッジMIBスパンニング・ツリー・プロトコルをサポートするスパンニング・ツリー・モジュールSPAN 514と；GARP、GVRPおよびGMRPプロトコルならびに習用のポート式VLANをサポートする802.1Q VLANモジュールVLAN 515と；起動時自己試験、プロセッサ診断およびスタッキング・ファームウェアなどをサポートするブートストラップ・モジュールBOOT 516と；全画面拡張可能ASCII形式インタフェースを処理するユーザ・インタフェース・モジュールUI 517と；上記スィッチにアクセスして該スィッチを制御するための完全なHTMLページ群をサポートするウェブ・モジュールWEB 518と；を備える。
【００４６】
第2レベルAPI 520は、オペレーティング・システムおよびハードウェアに依存しない、上記スタック型システム用のリアルタイムのアプリケーション・インタフェースである。このレベルは、全てのハードウェアおよびオペレーティング・システムからのコール(call)を抽象化する。該レベルは基本的に、第1レベル510および第3レベル530の間のインタフェースの役割を果たす。
【００４７】
上記第3レベルはハードウェア／OS空間530である。このレベルは主に２個のモジュールから成る：オペレーティング・システム・モジュール532および制御モジュール531である。該好適実施例において、オペレーティング・システム・モジュール532は上記スィッチング・ユニットの各々における基本的ハードウェア機能を制御すべく使用される一方、制御モジュール531は上記第2レベルとの通信と、上記ユニットの各々における全ての９個のポートのシステム制御とを行わねばならない。
【００４８】
図６は、本発明に係るスィッチの各々の好適実施例のブロック図を示している。
【００４９】
図示される如く、本発明に係る各スィッチング・ユニット600は、８個のバス・ポート611a、b、c、d、e、f、g、hを有するスィッチング・マトリクス610を備える。示された好適実施例においては、８個のバス・ポートの内の３個がイーサネット（登録商標）・ポート611a、b、cであり且つ８個のバス・ポートの内の２個がギガビット・アップリンク・ポート611d、eである。残りの３個のバス・ポート611f、g、hは、各スィッチング・ユニット間のスタック用リンクに対して確保されている。
【００５０】
上記好適実施例において３個のイーサネット（登録商標）・ポート611a、b、cは、８個のイーサネット（登録商標）・ポートすなわち10Base-T／100Base-TXイーサネット（登録商標）・ポートをサポートする。それらの各々は、８個のMII高速インターネット・ポートを有すると共に、２個のカッド磁気デバイス(quad magnetic device)に接続される。これらのカッド磁気デバイスは、各インターネット・ポートをRJ45コネクタから分離するために使用される。これに加え、これらのイーサネット（登録商標）・ポート用制御器の各々は、アドレス検索データおよびバッファされた入力／出力データなどのデータ管理情報を記憶する２個の別体のメモリ・ポートにより支援される。個々のユーザは、これらの２４個のイーサネット（登録商標）・ポートの任意のポートを介して上記スィッチング・ユニットに接続し得る。尚、本発明は半二重もしくは全二重接続のいずれにおいても使用され得ることを銘記されたい。更に、示された好適実施例において、２個のギガビット・アップリンク・ポート611d、eの各々は、ギガビット・アップリンクを行わねばならない。図示される如く、これらの２個のギガビット・アップリンク・ポート611d、eの各々は、アドレス検索データおよびバッファされたデータ・パケットを記憶する３個のメモリ・モジュールにより支援される。
【００５１】
上述の如く、スィッチング・マトリクス610の残る３個のポート611f、g、hは、特にスタック目的で確保される。これらのポート611f、g、hの一個以上を同様のスィッチング・ユニットのスィッチング・ポートに接続することにより、本発明に係るスタック型スィッチング・システムが形成される。示された本設計態様は並列のスタック用リンクもサポートすることから、２個のスィッチング・ユニット間のスタック用リンクの集束も可能である。２個のスィッチング・ユニット間の複数のスタック用リンクを集束することにより、２個のユニット間の全体的ネットワーク容量は増大され得る。たとえば２個のスィッチング・ユニット間の２本のスタック用リンクを組合せることにより、これらの２個のユニット間のネットワーク容量は倍増され得る。本設計態様においては残存ポートの個数(すなわち3)の制限の故に、２個のポート間におけるスタック用リンクの最大の集束度(aggregation)は３である。但し、３個以上の残存ポートを有する他の設計態様においては、全体的ネットワーク容量は相当に増大され得る。
【００５２】
図７は、本発明に係るスィッチング・ユニットの各々におけるブートアップ・プロセスの好適実施例を示すフローチャートである。ステップ701は、上記ブートアップ・プロセスの開始を示している。上記プロセスは通常は、該当スィッチング・ユニット(present switching unit)が起動されて開始する。次にステップ702において、該当スィッチング・ユニットは10秒の内部タイマを開始する。ステップ703において該当スィッチング・ユニットは、該ユニットが利用可能であり且つ活動状態であることを他の全てのユニットに通知すべく“活動(ALIVE)”メッセージを送信することにより、該当スィッチング・ユニットに他のスィッチング・ユニットが接続されているか否かを決定するためのチェックを実施する。上記好適実施例に依れば、この活動メッセージは該当スィッチング・ユニットのユニットIDも含んでいる。上記活動メッセージは、全ての他ユニットが該メッセージおよび付随するユニットIDを受信するまで、2秒毎に継続的に送信される。この10秒の時間間隔の間において、該当ユニットに接続された各スィッチング・ユニットはネットワークも受聴(listen)し、システムに対して接続された他の任意のユニットが在るか否かを決定する。該当スィッチング・ユニットは次に、他の各スィッチング・ユニットから送信された活動メッセージ(alive message)から各ユニットIDを抽出する。この“送信および受聴”プロセスを実施することにより、上記システムに接続された各スィッチング・ユニットは該システムに接続された他の全てのユニットの完全なプロフィルを有することになる。示された好適実施例において、この“送信および受聴”プロセスは10秒間継続する。故に、ステップ704においては、上記10秒間隔が終了したか否かを決定する為にブートアップ・タイマがチェックされる。
【００５３】
上記10秒ブートアップ時間が終了したとき、上記システムに接続された他の各ユニットに関する全ての情報に基づいて各ユニットはトポロジ・テーブルを生成する(ステップ705)。次にステップ706において上記スィッチの各々は、自身の優先順位インデックスを他のユニットの優先順位インデックスと比較する。最後に、最高の優先順位番号を有するスィッチング・ユニットがマスタ・ユニットとして覚醒(wake up)する(ステップ707)。一方、残りの各ユニットはスレーブ・ユニットとして覚醒する(ステップ708)。
【００５４】
図８および図９は、本発明に係る固定トポロジ設計態様に関している。特に、図８は固定トポロジ設計態様においてマスタ・ユニットとして覚醒するためのプロセスを示し、図９は固定トポロジ設計態様においてスレーブ・ユニットとして覚醒するためのプロセスを示している。
【００５５】
図８は、本発明に係る固定トポロジ・システムにおけるマスタ・ユニットに対する覚醒プロセスにおける各ステップを示すフローチャートである。ステップ801は、覚醒プロセスの開始を示している。ステップ802においてマスタ・ユニットは、上記スタック型システムにおける各ユニットが同一バージョンのファームウェアを具備するか否かをチェックして決定する。もし各スレーブ・ユニットのいずれかが上記マスタ・ユニットと同一バージョンのファームウェアを保有しなければ、ステップ802においてマスタ・ユニットは該マスタ・ユニット自身のバージョンのファームウェアをそのスレーブ・ユニットにダウンロードする。ステップ803においては、上記マスタ・ユニットによりトポロジ・テーブルが生成された後、マスタ・ユニットは該トポロジ・テーブルを、接続された各スレーブ・ユニットに対してダウンロードする。上記トポロジ・テーブルは、マスタ・ユニットと各スレーブ・ユニットとの間のトポロジ配置構成を具備している。ステップ804において上記マスタ・ユニットは、機器構成データ(configuration data)を設定すると共に該機器構成データをマスタ・ユニット自身のメモリ(好適には不揮発フラッシュ・メモリ)内に記憶する。上記機器構成データとしては、限定的なものとしてで無く：各スタック型スィッチング・ユニットの各ポートのポート・ステータス；各スタック・ユニットのスパンニング・ツリー・プロトコル(“STP”)；各ユニットのVLAN情報；および、QOSデータ、COSデータ、および中継方式データ(trunking data)などの他の情報；が挙げられる。上記機器構成データが上記マスタ・ユニットにより設定された後、該マスタは該機器構成データをバックアップ目的で各スレーブ・ユニットに対してダウンロードする(ステップ805)。
【００５６】
これらの初期化ステップ(すなわちステップ801〜805)が終了した後、上記マスタ・ユニットは検出処理に入り、上記スタック型スィッチング・システムにおける一切のトポロジ変更を検出する。特にステップ806において上記マスタ・ユニットは定期的に、ネットワークを受聴することによりユニットの付加もしくは除去が在るか否かを決定する。この決定は、接続された各スィッチング・ユニットにより送信された活動メッセージを検出することで実施され得る。たとえば活動メッセージを送信するスレーブ・ユニットがもはや存在しなければ、上記マスタ・ユニットは、上記スタック型スィッチング・システムにはスレーブ・ユニットがもはや接続されていないと仮定する。一方、もし新ユニットIDとともに受信された活動メッセージが在るなら、上記マスタは上記システムに対して新たなスィッチング・ユニットが取付けられたと結論づけ得る。いずれの場合にも、上記スタック型スィッチング・システムに対する新たなトポロジが必要とされる。
【００５７】
本発明に係る上記固定トポロジ設計態様において上記スタック型システムは、トポロジの変更(すなわちユニットの付加もしくは除去)がある毎に、上記リセット／ブートアップ段階(図７におけるステップ701)に戻る。
【００５８】
図９は、本発明に係る上記固定トポロジ設計態様のスレーブ・ユニットに対する覚醒プロセスの各ステップを示すフローチャートである。ステップ901は、スレーブ・ユニット覚醒プロセスの開始を示している。次に上記スレーブ・ユニットは、上記システムにおいて上記現在マスタ・ユニットが依然として存在するか否かを決定するループに入る。ステップ902に示された如く、この決定は２秒毎に実施される。上記スレーブ・ユニットが、現在マスタ・ユニットが上記システムから除去されたことを検出したとき、該スレーブ・ユニットは図７のステップ701に戻る。一方、もしマスタ・ユニットが依然として上記システムに存在するなら、上記スレーブ・ユニットはこの２秒毎のチェックを継続する。図９に示されたマスタ・ユニットと同様に、固定トポロジ設計態様のスレーブ・ユニットは、上記スタック型スィッチング・システムにおいてユニットの付加もしくは除去が行われる毎に、上記リセット／ブートアップ段階に戻る。尚、上記スレーブ・ユニットは図８に示された上記マスタ・ユニットの覚醒プロセスに対して(当該フローチャートには示されない)相補的ステップ(complementary step)も実施することを銘記されたい。これらの相補的ステップとしては、限定的なものとしてでなく、ファームウェアの受信および更新、上記トポロジ・テーブルの受信および更新、上記機器構成データの受信および維持、ならびに、一切のマスタ・ユニット・コマンドなどへの応答が挙げられる。
【００５９】
図１０および図１１は、本発明に係る上記動的トポロジ設計態様に関している。特に図１０は上記動的トポロジ設計態様に対するマスタ・ユニットとして覚醒するためのプロセスを示す一方、図１１は上記動的トポロジ設計態様においてスレーブ・ユニットとして覚醒するためのプロセスを示している。
【００６０】
図１０は、本発明に係る動的トポロジ・システムにおけるマスタ・ユニットに対する覚醒プロセスにおける各ステップを示すフローチャートである。ステップ1001は、上記覚醒プロセスの開始を示している。ステップ1002において上記マスタ・ユニットは、接続された各スレーブ・ユニットが最近に更新されたバージョンのファームウェアを有するか否かをチェックして決定する。もし各スレーブ・ユニットのいずれかがマスタ・ユニットと同一バージョンのファームウェアを所有しなければ、ステップ1002においてマスタ・ユニットは該マスタ・ユニット自身のバージョンのファームウェアをそのスレーブ・ユニットにダウンロードする。次にステップ1003において上記マスタ・ユニットは、各スレーブ・ユニットの全てに対して上記トポロジ・テーブルをダウンロードする。上記トポロジ・テーブルは、マスタ・ユニットと各スレーブ・ユニットとの間のトポロジ配置構成を具備している。ステップ1004において上記マスタ・ユニットは機器構成データを設定すると共に、該機器構成データを自身のメモリ(好適には不揮発フラッシュ・メモリ)内に記憶する。上記機器構成情報は、限定的なものとしてで無く：各スタック型スィッチング・ユニットの各ポートのポート・ステータス；各スタック・ユニットのスパンニング・ツリー・プロトコル(“STP”)；各ユニットのVLAN情報；および、QOSデータ、COSデータ、および中継方式データ(trunking data)などの他の情報；を含む。上記機器構成データが上記マスタ・ユニットにより設定された後、該マスタは該機器構成データをバックアップ目的で各スレーブ・ユニットに対してダウンロードする(ステップ1005)。
【００６１】
これらの初期化ステップ(すなわちステップ1001〜1005)が終了した後、上記マスタ・ユニットは検出処理に入り、上記スタック型スィッチング・システムにおける一切のトポロジ変更を検出する。特にステップ1006において上記マスタ・ユニットは定期的に、ネットワークを受聴することにより上記システムにおけるユニットの付加もしくは除去が在るか否かを決定する。この決定は、接続された各スィッチング・ユニットにより送信された活動メッセージを検出することで実施され得る。たとえば活動メッセージを送信する所定スレーブ・ユニットが存在しなければ、上記マスタ・ユニットは、上記スタック型システムには対応スレーブ・ユニットがもはや接続されていないと仮定する。一方、もし新ユニットIDとともに受信された活動メッセージが在るなら、上記マスタ・ユニットは上記システムに対して新たなスィッチング・ユニットが取付けられたと結論づけ得る。いずれの場合にも、上記スタック型スィッチング・システムに対する新たなトポロジが必要とされる。
【００６２】
本発明に係る上記動的トポロジ設計態様において上記マスタ・ユニットは次に、上記システムに新スレーブ・ユニットが付加されたか否かを判断する(ステップ1007)。この検出は、先ず何らかの新ユニットIDを検出することで行われ得る。もし受信された新ユニットIDが在るなら、上記マスタ・ユニットは、付加されたユニットの対応優先順位インデックスを現在マスタ・ユニットの優先順位インデックスと比較する。もし、付加されたシステムの優先順位インデックスが現在マスタ・ユニットの優先順位インデックスより低ければ、付加されたスィッチング・ユニットはスレーブ・ユニットである。もし付加されたシステムがスレーブ・ユニットなら、ステップ1008において上記マスタ・ユニットは(必要なら)この付加されたユニットのファームウェアを更新する。次にステップ1010において、上記トポロジ・テーブルは該スレーブ・ユニットの付加を反映すべく更新される。一方、もし上記マスタ・ユニットが所定スレーブ・ユニットから活動メッセージを受信できなければ、該マスタ・ユニットは対応スレーブ・ユニットが上記スタック型システムから除去されたと仮定する。この場合に上記マスタ・ユニットは、この喪失スレーブ・ユニットを除去することで自身のトポロジ・テーブルを更新する。上記トポロジ・テーブルを更新した後、上記マスタ・ユニットはステップ1003に戻る。最後に、もしスレーブ・ユニットの付加も除去も無ければ、上記システムに対しては更に高い優先順位インデックスを有する新ユニットが付加されたことになる。この場合に上記新ユニットが新マスタ・ユニットであり、現在マスタ・ユニットは図１１に示された手順を辿り、スレーブ・ユニットとして覚醒する。
【００６３】
図１１は、本発明の動的トポロジに依るスレーブ・ユニットに対する覚醒プロセスにおける各ステップを示すフローチャートである。ステップ1101は、スレーブ・ユニット覚醒プロセスの開始を示している。次に上記スレーブ・ユニットは、現在マスタ・ユニットが依然として上記システムに接続されているか否かを決定するループに入る。ステップ1102に示された該決定は、２秒毎に実施される。上記システムから現在マスタ・ユニットが除去されたことを上記スレーブ・ユニットが検出したとき、上記スレーブ・ユニットは図７に示された上記ブートアップ処置の接続点“１”に戻る。一方、もしマスタ・ユニットが依然としてシステム内に存在するなら、上記スレーブ・システムはこのチェックを２秒毎に継続する。上記マスタ・ユニットが上記スタック型スィッチング・システムから除去されたとき、残る各スレーブ・ユニットのどのスレーブ・ユニットが新マスタ・ユニットであるかを見出すために、これらの各スレーブ・ユニット間での新たな決定が必要とされる。この場合、残存スレーブ・ユニットの全ては図７に示されたフローチャートの接続点１にて再スタートする。尚、上記スレーブ・ユニットは図１０に示された上記マスタ・ユニットの覚醒プロセスに対して(当該フローチャートには示されない)相補的ステップも実施することを銘記されたい。先行段落において述べられた如く、これらの相補的ステップとしては、限定的なものとしてでなく、ファームウェアの受信および更新、上記トポロジ・テーブルの受信および更新、上記機器構成データの受信および維持、ならびに、一切のマスタ・ユニット・コマンドなどへの応答が挙げられる。
【００６４】
本発明は特定の好適実施例に関して上述されたが、上記記述および各例は、添付の請求の範囲の有効範囲により定義された本発明の有効範囲の制限を意図するのではなく例示することを意図している。
【図面の簡単な説明】
【００６５】
【図１】図１は、本発明に係るスタック型スィッチング・システムの一実施例を示す図である。
【図２】図２は、本発明に係る動的トポロジ設計態様を採用したスィッチング・ユニットの好適実施例を示す図である。
【図３】図３は、上記システム内に３個のスタック型スィッチング・ユニットを有する本発明の他の実施例を示す図である。
【図４】図４は、上記動的トポロジ設計態様を採用した本発明の更に別の実施例を示す図である。
【図５】図５は、本発明に係るスタック型スィッチング・システムで使用されるファームウェア・アーキテクチャの好適実施例のブロック図である。
【図６】図６は、本発明に係る各スィッチの好適実施例のブロック図である。
【図７】図７は、本発明に係るスィッチング・ユニットにおけるブートアップ・プロセスの好適実施例を示すフローチャートである。
【図８】図８は、本発明に係る固定トポロジ・システムにおけるマスタ・ユニットに対する覚醒プロセスの各ステップを示すフローチャートである。
【図９】図９は、本発明に係る固定トポロジ・システムにおけるスレーブ・ユニットに対する覚醒プロセスの各ステップを示すフローチャートである。
【図１０】図１０は、本発明に係る動的トポロジ・システムにおけるマスタ・ユニットに対する覚醒プロセスの各ステップを示すフローチャートである。
【図１１】図１１は、本発明に係る動的トポロジ・システムにおけるスレーブ・ユニットに対する覚醒プロセスの各ステップを示すフローチャートである。
【図１】
2007124673.tif 000003
【図２】
2007124673.tif 000004
【図３】
2007124673.tif 000005
【図４】
2007124673.tif 000006
【図５】
2007124673.tif 000007
【図６】
2007124673.tif 000008
【図７】
2007124673.tif 000009
【図８】
2007124673.tif 000010
【図９】
2007124673.tif 000011
【図１０】
2007124673.tif 000012
【図１１】
2007124673.tif 000013