(57)【要約】　　【課題】　輻輳発生の確率を下げ、輻輳によるフレームの到着遅れや欠落が発生する頻度を減らすことができるネットワークシステム、スパニングツリー構成方法を提案する。　　【解決手段】　複数のノードを接続したネットワーク上でスパニングツリーを構成するノードが、変更前のツリーを運用したまま、別のＶＬＡＮを用いてコスト変更後のツリーを生成し、新規ツリーの安定後に転送に利用するツリーを切り替える。【選択図】　　図７
2004104834.tif 000002
【特許請求の範囲】
【請求項１】
　複数のノードを接続したネットワーク上でスパニングツリーを構成するノードにおいて、
　ネットワークの構成変更前のスパニングツリーを運用したまま、構成変更後の新たなスパニングツリーを生成し、前記新たなスパニングツリーの安定後に、転送に利用するスパニングツリーを前記新たなスパニングツリーに切り替えることを特徴とするノード。
【請求項２】
　前記ネットワークの構成変更が、ノードの追加又は削除やリンクトポロジの変化であることを特徴とする請求項１に記載のノード。
【請求項３】
　複数のノードを接続したネットワーク上でスパニングツリーを構成するノードにおいて、
　ネットワークのコスト変更時に、現スパニングツリーを運用したまま、リンクコスト変更後の新たなスパニングツリーを生成し、前記新たなスパニングツリーの安定後に、転送に利用するスパニングツリーを前記新たなスパニングツリーに切り替えることを特徴とするノード。
【請求項４】
　複数のノードを接続したネットワーク上でスパニングツリーを構成するノードにおいて、
　独立して動作する複数のスパニングツリーを生成する複数のツリーマネージャと、
　転送に利用しているスパニングツリーに対応したタグを返答するタグテーブルと、
　前記タグテーブルより返答のあったタグをフレームに挿入するタグ挿入器と、
　転送に利用するスパニングツリーを決定するツリーセレクタと、
　宛先ごとのフレームの転送出力先を記録するフォワーディングテーブルと、
　前記フォワーディングテーブルで指定された転送出力先にフレームを転送するフレーム転送器と、
　前記タグに従って前記フレームの転送先のツリーマネージャを決定する分別器とを備えることを特徴とするノード。
【請求項５】
　前記ツリーセレクタが、
　転送に利用するスパニングツリーの切り替えを行うメインコントローラと、
　スパニングツリーの安定を示す指定した時間のタイマ満了を知らせる安定タイマと、
　フレームに付加されたタグを削除するタグ削除器と、
　スパニングツリーの切り替えのための制御フレームを送信するＧＶＲＰ送受信器と、
　フレームにタグを付加するタグ挿入器とを備えることを特徴とする請求項４に記載のノード。
【請求項６】
　前記ツリーセレクタは、
　スパニングツリーの安定を示すフレームの到着間隔を判別するため、一定時間が経過するとタイマ満了通知を送信する到着間隔タイマを備えることを特徴とする請求項５に記載のノード。
【請求項７】
　前記ツリーセレクタは、
　リンクコストの算出に利用する指定時間のタイマ満了を知らせるコスト参照タイマを備えることを特徴とする請求項４から請求項６の何れか１項に記載のノード。
【請求項８】
　前記ツリーマネージャが、
　フレームに付加されたタグを削除するタグ削除器と、
　ＢＰＤＵを送受信するＢＰＤＵ送受信器と、
　フレームにタグを付加するタグ挿入器と、
　スパニングツリープロトコルに従ってスパニングツリーを作成するツリーコントローラと、
　前記スパニングツリープロトコルで使用するパラメータを保持するツリーテーブルとを備えることを特徴とする請求項４から請求項７の何れか１項に記載のノード。
【請求項９】
　前記ツリーマネージャは、
　通知されたリンクコストに所定の設定値を加算して返答するコスト操作器を備えることを特徴とする請求項８に記載のノード。
【請求項１０】
　リンクの接続状況や空き帯域を含むリソース情報を計測するリソースモニタを備えることを特徴とする請求項４から請求項９の何れか１項に記載のノード。
【請求項１１】
　前記リンクコストを、利用状況に基づいて計算することを特徴とする請求項３に記載のノード。
【請求項１２】
　前記利用状況を、空き帯域と定義することを特徴とする請求項１１に記載のノード。
【請求項１３】
　前記利用状況を、ＣＰＵ負荷と定義することを特徴とする請求項１１に記載のノード。
【請求項１４】
　複数のノードを接続したネットワーク上でスパニングツリーを構成するノードにおいて、
　ネットワーク内の各ノードがルートノードとなるスパニングツリーを生成し、宛先がルートノードとなるスパニングツリーを用いてフレームを転送する
　ことを特徴とするノード。
【請求項１５】
　複数のノードを接続したネットワーク上でスパニングツリーを構成するノードにおいて、
　独立して動作する複数のスパニングツリーを生成する複数のツリーマネージャと、
　転送に利用しているスパニングツリーに対応したタグを返答するタグテーブルと、
　前記タグテーブルより返答のあったタグをフレームに挿入するタグ挿入器と、
　ネットワークに存在するルートノード数と同数のツリーマネージャを生成するツリーセレクタと、
　宛先ごとのフレームの転送出力先を記録するフォワーディングテーブルと、
　前記フォワーディングテーブルで指定された転送出力先にフレームを転送するフレーム転送器と、
　前記タグに従って前記フレームの転送先のツリーマネージャを決定する分別器
　とを備えることを特徴とするノード。
【請求項１６】
　前記ツリーセレクタが、
　ツリーマネージャの作成もしくは削除を行うメインコントローラと、
　フレームに付加されたタグを削除するタグ削除器と、
　スパニングツリーの切り替えのための制御フレームを送信するＧＶＲＰ送受信器と、
　フレームにタグを付加するタグ挿入器とを備えることを特徴とする請求項１５に記載のノード。
【請求項１７】
　前記ツリーマネージャが、
　フレームに付加されたタグを削除するタグ削除器と、
　ＢＰＤＵを送受信するＢＰＤＵ送受信器と、
　フレームにタグを付加するタグ挿入器と、
　スパニングツリープロトコルに従ってスパニングツリーを作成するツリーコントローラと、
　前記スパニングツリープロトコルで使用するパラメータを保持するツリーテーブルとを備えることを特徴とする請求項１５または請求項１６に記載のノード。
【請求項１８】
　リンクの接続状況や空き帯域を含むリソース情報を計測するリソースモニタを備えることを特徴とする請求項１５から請求項１７の何れか１項に記載のノード。
【請求項１９】
　複数のノードを接続したネットワーク上でスパニングツリーを構成するノードにおいて、
　スパニングツリーを生成するツリーマネージャが、
　スパニングツリープロトコルの種類およびバージョンにより、コスト値を調整するコスト操作器を備えることを特徴とするノード。
【請求項２０】
　前記コスト操作器は、
　障害回復処理が遅いプロトコルを利用しているリンクに対して、大きなコストを割り振ることを特徴とする請求項１９に記載のノード。
【請求項２１】
　複数のノードを接続したネットワーク上でスパニングツリーを構成するノードにおいて、
　ネットワーク内の動作の遅いプロトコルを使用中のリンクのそれぞれについて、前記各リンクのコストが最大となるスパニングツリーを生成し、前記各リンクに障害が発生した際に、前記リンクのコストが最大となっているツリーを利用してフレーム転送を行うことを特徴とするノード。
【請求項２２】
　複数のノードを接続したネットワーク上でスパニングツリーを構成するノードにおいて、
　独立して動作する複数のスパニングツリーを生成する複数のツリーマネージャと、
　転送用ツリーに対応したタグを返答するタグテーブルと、
　前記タグテーブルより返答のあったタグをフレームに挿入するタグ挿入器と、
　ネットワークに存在する動作の遅いプロトコルを使用中のリンク数と同数のツリーマネージャを生成するツリーセレクタと、
　宛先ごとのフレーム転送出力先を記録するフォワーディングテーブルと、
　前記フォワーディングテーブルで指定された転送出力先にフレームを転送するフレーム転送器と、
　前記タグに従って転送先のツリーマネージャを決定する分別器
　とを備えることを特徴とするノード。
【請求項２３】
　前記ツリーセレクタが、
　ツリーマネージャの作成もしくは削除を行うツリーセレクタ内のメインコントローラと、
　フレームに付加されたタグを削除するタグ削除器と、
　制御フレームを送信するＧＶＲＰ送受信器と、
　フレームにタグを付加するタグ挿入器とを備えることを特徴とする請求項２２に記載のノード。
【請求項２４】
　前記ツリーマネージャが、
　フレームに付加されたタグを削除するタグ削除器と、
　ＢＰＤＵを送受信するＢＰＤＵ送受信器と、
　フレームにタグを付加するタグ挿入器と、
　スパニングツリープロトコルにしたがってスパニングツリーを作成するツリーコントローラと、
　スパニングツリープロトコルで使用するパラメータを保持するツリーテーブルとを備えることを特徴とする請求項２２または請求項２３に記載のノード。
【請求項２５】
　リンクの接続状況や空き帯域を含むリソース情報を計測するリソースモニタを備えることを特徴とする請求項２２から請求項２４の何れか１項に記載のノード。
【請求項２６】
　スパニングツリープロトコルで利用されているＨＥＬＬＯフレームより、短い間隔で障害検出用フレームを送受信して障害を検出する障害検出器を備えることを特徴とする請求項４から請求項２５の何れか１項に記載のノード。
【請求項２７】
　前記フォワーディングテーブルが、ブロードキャスト出力ポートフィールドを有することを特徴とする、請求項４、１５、もしくは２２に記載のノード。
【請求項２８】
　前記フォワーディングテーブルが、予備出力ポートフィールドを有することを特徴とする、請求項４、１５、もしくは２２に記載のノード。
【請求項２９】
　スパニングツリーによって決定されるポート種別を用いて、出力先ポートを決定することを特徴とする、請求項４、１５，もしくは２２に記載のノード。
【請求項３０】
　前記スパニングツリーによって決定されるポート種別が、ルートポート及びディジグネイテッドポートの何れかであることを特徴とする請求項２９に記載のノード。
【請求項３１】
　複数のノードを接続したネットワーク上でスパニングツリーを構成する各ノード上で動作するスパニングツリー構成プログラムにおいて、
　ネットワークの構成変更前のスパニングツリーを運用したまま、構成変更後の新たなスパニングツリーを生成し、前記新たなスパニングツリーの安定後に、転送に利用するスパニングツリーを前記新たなスパニングツリーに切り替える処理を実行することを特徴とするスパニングツリー構成プログラム。
【請求項３２】
　前記ネットワークの構成変更が、ノードの追加又は削除やリンクトポロジの変化であることを特徴とする請求項３１に記載のスパニングツリー構成プログラム。
【請求項３３】
　複数のノードを接続したネットワーク上でスパニングツリーを構成する各ノード上で動作するスパニングツリー構成プログラムにおいて、
　ネットワークのコスト変更時に、現スパニングツリーを運用したまま、リンクコスト変更後の新たなスパニングツリーを生成し、前記新たなスパニングツリーの安定後に、転送に利用するスパニングツリーを前記新たなスパニングツリーに切り替える処理を実行することを特徴とするスパニングツリー構成プログラム。
【請求項３４】
　複数のノードを接続したネットワーク上でスパニングツリーを構成する各ノード上で動作するスパニングツリー構成プログラムにおいて、
　複数のツリーマネージャによる独立して動作する複数のスパニングツリーを生成する処理と、
　転送に利用しているスパニングツリーに対応したタグを返答する処理と、
　返答のあった前記タグをフレームに挿入するタグ挿入処理と、
　転送に利用するツリーを決定するツリーセレクタ処理と、
　宛先ごとのフレームの転送出力先を記録するフォワーディングテーブル処理と、
　前記フォワーディングテーブルで指定された転送出力先にフレームを転送するフレーム転送処理と、
　前記タグに従って転送先のツリーマネージャを決定する分別処理
　とを実行することを特徴とするスパニングツリー構成プログラム。
【請求項３５】
　前記ツリーセレクタ処理において、
　転送に利用するスパニングツリーの切り替えを行うコントローラ処理と、
　スパニングツリーの安定を示す指定した時間のタイマ満了を知らせる安定タイマ処理と、
　フレームに付加されたタグを削除するタグ削除処理と、
　スパニングツリーの切り替えのための制御フレームを送信するＧＶＲＰ送受信処理と、
　フレームにタグを付加するタグ挿入処理
　とを実行することを特徴とする請求項３４に記載のスパニングツリー構成プログラム。
【請求項３６】
　前記ツリーセレクタ処理において、
　スパニングツリーの安定を示すフレームの到着間隔を判別するため、一定時間が経過すると、タイマ満了通知を送信する到着間隔タイマ処理を実行することを特徴とする請求項３５に記載のスパニングツリー構成プログラム。
【請求項３７】
　前記ツリーセレクタ処理は、
　リンクコストの算出に利用する指定時間のタイマ満了を知らせるコスト参照タイマ処理を実行することを特徴とする請求項３４から請求項３６に記載のスパニングツリー構成プログラム。
【請求項３８】
　前記ツリーマネージャ処理が、
　フレームに付加されたタグを削除するタグ削除処理と、
　ＢＰＤＵを送受信するＢＰＤＵ送受信処理と、
　フレームにタグを付加するタグ挿入処理と、
　スパニングツリープロトコルに従ってスパニングツリーを作成するツリーコントローラ処理と、
　前記スパニングツリープロトコルで使用するパラメータを保持するツリーテーブル処理とを実行することを特徴とする請求項３４から請求項３７の何れか１項に記載のスパニングツリー構成プログラム。
【請求項３９】
　前記ツリーマネージャ処理は、
　通知されたリンクコストに所定の設定値を加算して返答するコスト操作処理を実行することを特徴とする請求項３８に記載のスパニングツリー構成プログラム。
【請求項４０】
　リンクの接続状況や空き帯域を含むリソース情報を計測するリソースモニタ処理を実行することを特徴とする請求項３４から請求項３９の何れか１項に記載のスパニングツリー構成プログラム。
【請求項４１】
　リンクコストを、利用状況により計算する処理を実行することを特徴とする請求項３３に記載のスパニングツリー構成プログラム。
【請求項４２】
　前記利用状況を、空き帯域と定義することを特徴とする請求項４１に記載のスパニングツリー構成プログラム。
【請求項４３】
　前記利用状況を、ＣＰＵ負荷と定義することを特徴とする請求項４１に記載のスパニングツリー構成プログラム。
【請求項４４】
　複数のノードを接続したネットワーク上でスパニングツリーを構成する各ノード上で動作するスパニングツリー構成プログラムにおいて、
　ネットワーク内の各ノードがルートノードとなるスパニングツリーを生成し、宛先がルートノードとなるツリーを用いてフレームを転送する
　ことを特徴とするスパニングツリー構成プログラム。
【請求項４５】
　複数のノードを接続したネットワーク上でスパニングツリーを構成する各ノード上で動作するスパニングツリー構成プログラムにおいて、
　独立して動作する複数のスパニングツリーを生成する複数のツリーマネージャ処理と、
　転送に利用しているスパニングツリーに対応したタグを返答するタグテーブル処理と、
　前記タグテーブルより返答のあったタグをフレームに挿入するタグ挿入処理と、
　ネットワークに存在するルートノード数と同数のツリーマネージャを生成するツリーセレクタ処理と、
　宛先ごとのフレーム転送出力先を記録するフォワーディングテーブル処理と、
　前記フォワーディングテーブルで指定された転送出力先にフレームを転送するフレーム転送処理と、
　前記タグに従って前記フレームの転送先のツリーマネージャを決定する分別処理
　とを備えることを特徴とするスパニングツリー構成プログラム。
【請求項４６】
　前記ツリーセレクタ処理が、
　ツリーマネージャの作成もしくは削除を行うツリーセレクタ内のメインコントローラ処理と、
　フレームに付加されたタグを削除するタグ削除処理と、
　スパニングツリーの切り替えのための制御フレームを送信するＧＶＲＰ送受信処理と、
　フレームにタグを付加するタグ挿入処理
　とを実行することを特徴とする請求項４５に記載のスパニングツリー構成プログラム。
【請求項４７】
　前記ツリーマネージャ処理が、
　フレームに付加されたタグを削除するタグ削除処理と、
　ＢＰＤＵを送受信するＢＰＤＵ送受信処理と、
　フレームにタグを付加するタグ挿入処理と、
　スパニングツリープロトコルに従ってスパニングツリーを作成するツリーコントローラ処理と、
　前記スパニングツリープロトコルで使用するパラメータを保持するツリーテーブル処理とを実行することを特徴とする請求項４５または請求項４６に記載のスパニングツリー構成プログラム。
【請求項４８】
　各前記ノードは、リンクの接続状況や空き帯域を含むリソース情報を計測するリソースモニタ処理を実行することを特徴とする請求項４５から請求項４７の何れか１項に記載のスパニングツリー構成プログラム。
【請求項４９】
　複数のノードを接続したネットワーク上でスパニングツリーを構成する各ノードで動作するスパニングツリー構成プログラムにおいて、
　ネットワーク内の動作の遅いプロトコルを使用中のリンクのそれぞれについて、前記各リンクのコストが最大となるスパニングツリーを生成し、前記各リンクに障害が発生した際に、前記リンクのコストが最大となっているツリーを利用してフレーム転送を行うことを特徴とするスパニングツリー構成プログラム。
【請求項５０】
　複数のノードを接続したネットワーク上でスパニングツリーを構成する各ノードで動作するスパニングツリー構成プログラムにおいて、
　独立して動作する複数のスパニングツリーを生成する複数のツリーマネージャ処理と、
　転送用ツリーに対応したタグを返答するタグテーブル処理と、
　前記タグテーブルより返答のあったタグをフレームに挿入するタグ挿入処理と、
　ネットワークに存在する動作の遅いプロトコルを使用中のリンク数と同数のツリーマネージャを生成するツリーセレクタ処理と、
　宛先ごとのフレームの転送出力先を記録するフォワーディングテーブル処理と、
　前記フォワーディングテーブルで指定された転送出力先にフレームを転送するフレーム転送処理と、
　前記タグに従ってフレームの転送先のツリーマネージャを決定する分別処理
　とを備えることを特徴とするスパニングツリー構成プログラム。
【請求項５１】
　前記ツリーセレクタ処理が、
　ツリーマネージャの作成もしくは削除を行うツリーセレクタ内のメインコントローラ処理と、
　フレームに付加されたタグを削除するタグ削除処理と、
　制御フレームを送信するＧＶＲＰ送受信処理と、
　フレームにタグを付加するタグ挿入処理
　とを備えることを特徴とする請求項５０に記載のスパニングツリー構成プログラム。
【請求項５２】
　前記ツリーマネージャ処理が、
　フレームに付加されたタグを削除するタグ削除処理と、
　ＢＰＤＵを送受信するＢＰＤＵ送受信処理と、
　フレームにタグを付加するタグ挿入処理と、
　スパニングツリープロトコルにしたがってスパニングツリーを作成するツリーコントローラ処理と、
　スパニングツリープロトコルで使用するパラメータを保持するツリーテーブル処理とを備えることを特徴とする請求項５０または請求項５１に記載のスパニングツリー構成プログラム。
【請求項５３】
　各前記ノードは、リンクの接続状況や空き帯域を含むリソース情報を計測するリソースモニタ処理を実行することを特徴とする請求項５０から請求項５２の何れか１項に記載のスパニングツリー構成プログラム。
【請求項５４】
　前記フォワーディングテーブルが、ブロードキャスト出力ポートフィールドを有することを特徴とする、請求項３４、４５、もしくは５０に記載のスパニングツリー構成プログラム。
【請求項５５】
　前記フォワーディングテーブルが、予備出力ポートフィールドを有することを特徴とする、請求項３４、４５、もしくは５０に記載のスパニングツリー構成プログラム。
【請求項５６】
　スパニングツリーによって決定されるポート種別を用いて、出力先ポートを決定することを特徴とする、請求項３４、４５，もしくは５０に記載のスパニングツリー構成プログラム。
【請求項５７】
　前記スパニングツリーによって決定されるポート種別が、ルートポート及びディジグネイテッドポートの何れかであることを特徴とする請求項５６に記載のスパニングツリー構成プログラム。
【請求項５８】
　複数のノードを接続したネットワーク上でスパニングツリーによって転送経路を設定するネットワークシステムにおいて、
　各前記ノードが、
　ネットワークの構成変更前のスパニングツリーを運用したまま、構成変更後の新たなスパニングツリーを生成し、前記新たなスパニングツリーの安定後に、転送に利用するスパニングツリーを前記新たなスパニングツリーに切り替えることを特徴とするネットワークシステム。
【請求項５９】
　複数のノードを接続したネットワーク上でスパニングツリーによって転送経路を設定するネットワークシステムにおいて、
　各前記ノードが、
　ネットワークのコスト変更時に、現スパニングツリーを運用したまま、リンクコスト変更後の新たなスパニングツリーを生成し、前記新たなスパニングツリーの安定後に、転送に利用するスパニングツリーを前記新たなスパニングツリーに切り替えることを特徴とするネットワークシステム。
【請求項６０】
　複数のノードを接続したネットワーク上でスパニングツリーによって転送経路を設定するネットワークシステムにおいて、
　各前記ノードが、
　独立して動作する複数のスパニングツリーを生成する複数のツリーマネージャと、
　転送に利用しているスパニングツリーに対応したタグを返答するタグテーブルと、
　前記タグテーブルより返答のあったタグをフレームに挿入するタグ挿入器と、
　転送に利用するスパニングツリーを決定するツリーセレクタと、
　宛先ごとのフレームの転送出力先を記録するフォワーディングテーブルと、
　前記フォワーディングテーブルで指定された転送出力先にフレームを転送するフレーム転送器と、
　前記タグに従って前記フレームの転送先のツリーマネージャを決定する分別器とを備えることを特徴とするネットワークシステム。
【請求項６１】
　リンクコストを、利用状況により計算することを特徴とする請求項５３に記載のネットワークシステム。
【請求項６２】
　複数のノードを接続したネットワーク上でスパニングツリーによって転送経路を設定するネットワークシステムにおいて、
　ネットワーク内の各ノードがルートノードとなるスパニングツリーを生成し、宛先がルートノードとなるツリーを用いてフレームを転送する
　ことを特徴とするネットワークシステム。
【請求項６３】
　複数のノードを接続したネットワーク上でスパニングツリーによって転送経路を設定するネットワークシステムにおいて、
　独立して動作する複数のスパニングツリーを生成する複数のツリーマネージャと、
　転送用ツリーに対応したタグを返答するタグテーブルと、
　前記タグテーブルより返答のあったタグをフレームに挿入するタグ挿入器と、
　ネットワークに存在するノード数と同数のツリーマネージャを生成するツリーセレクタと、
　宛先ごとのフレーム転送出力先を記録するフォワーディングテーブルと、
　前記フォワーディングテーブルで指定された転送出力先にフレームを転送するフレーム転送器と、
　前記タグに従って前記フレームの転送先のツリーマネージャを決定する分別器
　とを備えることを特徴とするネットワークシステム。
【請求項６４】
　複数のノードを接続したネットワーク上でスパニングツリーによって転送経路を設定するネットワークシステムにおいて、
　スパニングツリーを生成するツリーマネージャが、
　スパニングツリープロトコルの種類およびバージョンにより、コスト値を調整するコスト操作処理
　を実行することを特徴とするネットワークシステム。
【請求項６５】
　複数のノードを接続したネットワーク上でスパニングツリーによって転送経路を設定するネットワークシステムにおいて、
　スパニングツリーを生成するツリーマネージャが、
　スパニングツリープロトコルの種類およびバージョンにより、コスト値を調整するコスト操作器
　を備えることを特徴とするネットワークシステム。
【請求項６６】
　複数のノードを接続したネットワーク上でスパニングツリーによって転送経路を設定するネットワークシステムにおいて、
　ネットワーク内の動作の遅いプロトコルを使用中のリンクのそれぞれについて、前記各リンクのコストが最大となるスパニングツリーを生成し、前記各リンクに障害が発生した際に、前記リンクのコストが最大となっているツリーを利用してフレーム転送を行う
　ことを特徴とするネットワークシステム。
【請求項６７】
　複数のノードを接続したネットワーク上でスパニングツリーによって転送経路を設定するネットワークシステムにおいて、
　独立して動作する複数のスパニングツリーを生成する複数のツリーマネージャと、
　転送用ツリーに対応したタグを返答するタグテーブルと、
　前記タグテーブルより返答のあったタグをフレームに挿入するタグ挿入器と、
　ネットワークに存在する動作の遅いプロトコルを使用中のリンク数と同数のツリーマネージャを生成するツリーセレクタと、
　宛先ごとのフレーム転送出力先を記録するフォワーディングテーブルと、
　前記フォワーディングテーブルで指定された転送出力先にフレームを転送するフレーム転送器と、
　前記タグに従って前記フレームの転送先のツリーマネージャを決定する分別器
　とを備えることを特徴とするネットワークシステム。
【請求項６８】
　前記フォワーディングテーブルが、ブロードキャスト出力ポートフィールドを有することを特徴とする、請求項６０、６３、もしくは６７に記載のネットワークシステム。
【請求項６９】
　前記フォワーディングテーブルが、予備出力ポートフィールドを有することを特徴とする、請求項６０、６３、もしくは６７に記載のネットワークシステム。
【請求項７０】
　スパニングツリーによって決定されるポート種別を用いて、出力先ポートを決定することを特徴とする、請求項６０、６３，もしくは６７に記載のネットワークシステム。
【請求項７１】
　前記スパニングツリーによって決定されるポート種別が、ルートポート及びディジグネイテッドポートの何れかであることを特徴とする請求項７０に記載のネットワークシステム。
【請求項７２】
　複数のノードを接続したネットワークにおけるスパニングツリー構成方法であって、
　ネットワークの構成変更前のスパニングツリーを運用したまま、構成変更後の新たなスパニングツリーを生成し、前記新たなスパニングツリーの安定後に、転送に利用するスパニングツリーを前記新たなスパニングツリーに切り替えることを特徴とするスパニングツリー構成方法。
【請求項７３】
　複数のノードを接続したネットワークにおけるスパニングツリー構成方法であって、
　ネットワークのコスト変更時に、現スパニングツリーを運用したまま、リンクコスト変更後の新たなスパニングツリーを生成し、前記新たなスパニングツリーの安定後に、転送に利用するスパニングツリーを前記新たなスパニングツリーに切り替えることを特徴とするスパニングツリー構成方法。
【請求項７４】
　複数のノードを接続したネットワークにおけるスパニングツリー構成方法であって、
　新規ノードを追加する際に、新規ノードを既存スパニングツリーに参加させず、予備スパニングツリーにのみ参加させることを特徴とするスパニングツリー構成方法。
【請求項７５】
　複数のノードを接続したネットワークにおけるスパニングツリー構成方法であって、
　ノードを削除する際に、削除ノードを予備スパニングツリーに参加させず、既存スパニングツリーのみに参加させることを特徴とするスパニングツリー構成方法。
【請求項７６】
　複数のノードを接続したネットワークにおけるスパニングツリー構成方法であって、
　ネットワーク構成が変更された時、予備系を用いて変更後のツリー作成を行うことを特徴とするスパニングツリー構成方法。
【請求項７７】
　複数のノードを接続したネットワークにおけるスパニングツリー構成方法であって、
　コスト算出に、リンクの空き帯域を利用することを特徴とするスパニングツリー構成方法。
【請求項７８】
　複数のノードを接続したネットワークにおけるスパニングツリー構成方法であって、
　ネットワーク内の全ノードが、全ノードをメンバに持つスパニングツリーのうち、どれか１つのルートノードとなるよう、複数のスパニングツリーを作成することを特徴とするスパニングツリー構成方法。
【請求項７９】
　複数のノードを接続したネットワークにおけるスパニングツリー構成方法であって、
　ネットワーク内に存在する全ノードをメンバに持つスパニングツリーを作成し、うち、障害復旧の遅いプロトコルを使用しているリンクごとに複数のスパニングツリーを作成することを特徴とするスパニングツリー構成方法。
【請求項８０】
　複数のノードを接続したネットワークにおいて信号伝送に用いる論理トポロジを形成する方法であって、
　ネットワークの構成変更前の論理トポロジを用いて信号伝送を行っている状態で、ネットワークの構成変更後の論理トポロジを生成し、
　前記構成変更後の論理トポロジ安定後に、信号伝送に用いる論理トポロジを前記構成変更後の論理トポロジに切り替えることを特徴とする論理トポロジ形成方法。
【請求項８１】
　自らが属するネットワークにおいて信号伝送に用いる論理トポロジを用いて信号伝送を行っている状態で、前記ネットワークの構成変更時に、ネットワークの構成変更後の論理トポロジを生成する手段と、
　前記構成変更後の論理トポロジ安定後に、信号伝送に用いる論理トポロジを前記構成変更後の論理トポロジに切り替える手段とを有するノード。
【請求項８２】
　自らが属するネットワークにおいて信号伝送に用いる論理トポロジを用いて信号伝送を行っている状態で、前記ネットワークの構成変更時に、ネットワークの構成変更後の論理トポロジを生成する処理と、
　前記構成変更後の論理トポロジ安定後に、信号伝送に用いる論理トポロジを前記構成変更後の論理トポロジに切り替える処理とを実行することを特徴とするプログラム。
【請求項８３】
　複数のノードを接続したネットワークシステムであって、
　ネットワークの構成変更前の論理トポロジを用いて信号伝送を行っている状態で、ネットワークの構成変更後の論理トポロジを生成し、
　前記構成変更後の論理トポロジ安定後に、信号伝送に用いる論理トポロジを前記構成変更後の論理トポロジに切り替えることを特徴とするネットワークシステム。
【請求項８４】
　入力されるフレームが保持する宛先に関する情報と当該フレームの転送先との対応関係をスパニングツリープロトコルを用いて作成する手段と、
　前記対応関係を参照し、入力されたフレームの転送先を決定する手段とを有するノード。
【発明の詳細な説明】
【技術分野】
【０００１】
　本発明は、ネットワークシステムに関し、特にスパニングツリーの再構成時にネットワークを停止させることが無く、さらに負荷分散機能を有するネットワークシステム、スパニングツリー構成方法及びスパニングツリー構成ノードに関する。
【背景技術】
【０００２】
　従来、この種のスパニングツリーは、ループ(円環)状に形成されたネットワークにおいて、データが永遠に循環するのを防止するために用いられている。
【０００３】
　例えば「１９９８年、アイトリプルイー・スタンダード・８０２．１ディー（IEEE Std 802.1D）」と題するＩＥＥＥ発行の標準化文書では、ループ(円環)状に形成されたネットワーク内で、データが永遠に循環するのを防止するため、ノード間でBridge Protocol Data Unit(BPDU)と呼ばれる制御情報をやり取りし、物理的にループ状になっているネットワークの一部を論理的に使用不能にして、論理的にツリー状のトポロジを形成する、スパニングツリーと呼ばれる制御手法が規定されている。これを従来技術１とする。
【０００４】
　また、「２００１年、アイトリプルイー・スタンダード・８０２．１ダブリュ（IEEE Std 802.1ｗ）」と題するＩＥＥＥ発行の標準化文書では、制御情報の交換方法を拡張することにより、従来技術１におけるツリー作成を高速化し、さらに、あらかじめ迂回経路を設定しておくことにより、障害発生時の高速な迂回経路の設定を行う、高速スパニングツリーと呼ばれる制御手法が規定されている。これを従来技術２とする。
【０００５】
【非特許文献１】「１９９８年、アイトリプルイー・スタンダード・８０２．１ディー（IEEE Std 802.1D）」と題するＩＥＥＥ発行の標準化文書
【非特許文献２】「２００１年、アイトリプルイー・スタンダード・８０２．１ダブリュ（IEEE Std 802.1ｗ）」と題するＩＥＥＥ発行の標準化文書
【発明の開示】
【発明が解決しようとする課題】
【０００６】
　上述した従来の技術では、以下に述べるような問題点があった。
【０００７】
　第１に、輻輳により、フレームの到着遅れや、欠落が発生するという問題があった。
【０００８】
　従来技術１では、スパニングツリーに属するノードおよびリンクの追加および削除時に、スパニングツリーを停止させて最初から構築しなおすため、再構築中に長時間ネットワーク全体が停止して輻輳が発生することにより、フレームの到着が遅れたり、欠落する場合があった。
【０００９】
　従来技術２では、スパニングツリーに属するノードおよびリンクの追加および削除時に、局所的にデータフレームの転送を停止させながら、徐々にスパニングツリーを構築しなおすため、再構築中にネットワークの一部が停止して輻輳し、フレームの到着が遅れたり、欠落する場合があった。
【００１０】
　第２に、スパニングツリーに属するノードの追加および削除等のスパニングツリー再構成時に、ネットワークが停止するという問題点があった。
【００１１】
　従来技術１では、スパニングツリーに属するノードの追加および削除時に、スパニングツリーを停止させて最初から構築しなおすため、再構築中に長時間ネットワーク全体が停止する場合があった。
【００１２】
　従来技術２では、スパニングツリーに属するノードの追加および削除時に、局所的にデータフレームの転送を停止させながら、徐々にスパニングツリーを構築しなおすため、再構築中にネットワークの一部が停止する場合があった。
【００１３】
　第３に、トラフィックの負荷分散ができないという問題点があった。
【００１４】
　従来技術１および従来技術２では、リンク容量を用いてコストを計算し、スパニングツリー構築時の経路選択に利用しているため、トラフィックに応じた動的な負荷分散のための経路変更ができなかった。
【００１５】
　第４に、負荷分散しようとすると、スパニングツリー再構成のために、ネットワークが停止するという問題点があった。
【００１６】
　従来技術１では、コストをトラフィック状況に応じて動的に変化させようとすると、スパニングツリーを一旦停止させてから構築しなおすことで経路を変更するため、再構築中に長時間ネットワーク全体が停止する場合があった。
【００１７】
　従来技術２では、コストをトラフィック状況に応じて動的に変化させようとすると、局所的にデータフレームの転送を停止させながら、スパニングツリーの一部を徐々に構築しなおして経路を変更するため、再構築中にネットワークの一部が停止する場合があった。
【００１８】
　第５に、宛先への最低コスト経路が必ずしも選択されるとは限らないという問題があった。
【００１９】
　従来技術１および従来技術２では、スパニングツリーをネットワーク上で１系統のみ設定し、各ノード毎に予め設定されたプライオリティ値およびＭＡＣアドレスより、ネットワーク上で唯一のルートノードを決定し、単一のツリーを作成するため、ツリーの末端に位置するノード同士が通信する場合は、最短経路が別にあったとしてもブロッキングされてしまい、冗長な経路を通過する場合があった。
【００２０】
　第６に、リンク利用率が低い一方、ルートノード付近に負荷が集中するという問題があった。
【００２１】
　従来技術１および従来技術２では、スパニングツリーをネットワーク上で１系統のみ設定し、各ノードに設定されたプライオリティ値およびＭＡＣアドレスより、ネットワーク上で唯一のルートノードを決定し、単一のツリーを作成するため、ツリーの末端では設置されていても利用されないリンクが出現してリンク利用率が低下した。逆に、ルートノード付近では、トラフィックが集中し、輻輳発生の可能性が高まる場合があった。
【００２２】
　第７に、ルートノード障害時のツリー構築に時間がかかり、その間ネットワークが停止するという問題があった。
【００２３】
　従来技術１では、スパニングツリーをネットワーク上で１系統のみ設定し、ルートノードを１つだけしか持たないため、ルートノードにおいて障害が発生すると、スパニングツリーを停止させて最初から構築しなおすため、再構築中に長時間ネットワーク全体が停止する場合があった。
【００２４】
　従来技術２では、ルートノードにおいて障害が発生すると、局所的にデータフレームの転送を停止させながら、徐々にスパニングツリーを構築しなおすため、再構築中にネットワークの一部が停止する場合があった。
【００２５】
　第８に、ＩＥＥＥ８０２．１Ｄを利用する区間は、障害時のルート切り替えが遅く、スパニングツリーの再構成にも時間がかかるという問題があった。
【００２６】
　従来技術１では、ツリーの構築時においてデータの交換が可能となるまで、数十秒の時間がかかる場合があるからである。
【００２７】
　さらに、第９に、従来技術１及び従来技術２の何れにおいても、単一のツリーしか持たないために、トラフィックがルートノード付近に集中して輻輳し、フレームの到着が遅れたり、欠落する場合があった。
【００２８】
　本発明の第１の目的は、輻輳発生の確率を下げ、輻輳によるフレームの到着遅れや欠落が発生する頻度を減らすことができる、ネットワークシステム、スパニングツリー構成方法、スパニングツリー構成ノード、及びスパニングツリー構成プログラムを提供することにある。
【００２９】
　本発明の第２の目的は、ネットワークを停止させずに、スパニングツリーに属するノードの追加および削除等のスパニングツリー再構成ができる、ネットワークシステム、スパニングツリー構成方法、スパニングツリー構成ノード、及びスパニングツリー構成プログラムを提供することにある。
【００３０】
　本発明の第３の目的は、トラフィックの負荷分散ができる、ネットワークシステム、スパニングツリー構成方法、スパニングツリー構成ノード、及びスパニングツリー構成プログラムを提供することにある。
【００３１】
　本発明の第４の目的は、経路変更にともなうスパニングツリー再構成のために、ネットワークを停止させることなく負荷分散ができる、ネットワークシステム、スパニングツリー構成方法、スパニングツリー構成ノード、及びスパニングツリー構成プログラムを提供することにある。
【００３２】
　本発明の第５の目的は、宛先への最低コスト経路が選択される、ネットワークシステム、スパニングツリー構成方法、スパニングツリー構成ノード、及びスパニングツリー構成プログラムを提供することにある。
【００３３】
　本発明の第６の目的は、リンク利用率を高め、ルートノード付近に負荷を集中させずに分散可能な、ネットワークシステム、スパニングツリー構成方法、スパニングツリー構成ノード、及びスパニングツリー構成プログラムを提供することにある。
【００３４】
　本発明の第７の目的は、ルートノード障害によるネットワーク停止を回避可能な、ネットワークシステム、スパニングツリー構成方法、スパニングツリー構成ノード、及びスパニングツリー構成プログラムを提供することにある。
【００３５】
　本発明の第８の目的は、スパニングツリーがＩＥＥＥ８０２．１Ｄ利用区間を通過して設定されるのを防ぎ、障害時の切替やルート変更を高速化し、輻輳発生の可能性やフレームの欠落の可能性を低下させることが可能な、ネットワークシステム、スパニングツリー構成方法、スパニングツリー構成ノード、及びスパニングツリー構成プログラムを提供することにある。
【課題を解決するための手段】
【００３６】
　請求項１の本発明は、複数のノードを接続したネットワーク上でスパニングツリーを構成するノードにおいて、ネットワークの構成変更前のスパニングツリーを運用したまま、構成変更後の新たなスパニングツリーを生成し、前記新たなスパニングツリーの安定後に、転送に利用するスパニングツリーを前記新たなスパニングツリーに切り替えることを特徴とする。
【００３７】
　請求項２の本発明のノードは、前記ネットワークの構成変更が、ノードの追加又は削除やリンクトポロジの変化であることを特徴とする。
【００３８】
　請求項３の本発明は、複数のノードを接続したネットワーク上でスパニングツリーを構成するノードにおいて、ネットワークのコスト変更時に、現スパニングツリーを運用したまま、リンクコスト変更後の新たなスパニングツリーを生成し、前記新たなスパニングツリーの安定後に、転送に利用するスパニングツリーを前記新たなスパニングツリーに切り替えることを特徴とする。
【００３９】
　請求項４の本発明は、複数のノードを接続したネットワーク上でスパニングツリーを構成するノードにおいて、独立して動作する複数のスパニングツリーを生成する複数のツリーマネージャと、転送に利用しているスパニングツリーに対応したタグを返答するタグテーブルと、前記タグテーブルより返答のあったタグをフレームに挿入するタグ挿入器と、転送に利用するスパニングツリーを決定するツリーセレクタと、宛先ごとのフレームの転送出力先を記録するフォワーディングテーブルと、前記フォワーディングテーブルで指定された転送出力先にフレームを転送するフレーム転送器と、前記タグに従って前記フレームの転送先のツリーマネージャを決定する分別器とを備えることを特徴とする。
【００４０】
　請求項５の本発明のノードは、前記ツリーセレクタが、転送に利用するスパニングツリーの切り替えを行うメインコントローラと、スパニングツリーの安定を示す指定した時間のタイマ満了を知らせる安定タイマと、フレームに付加されたタグを削除するタグ削除器と、スパニングツリーの切り替えのための制御フレームを送信するＧＶＲＰ送受信器と、フレームにタグを付加するタグ挿入器とを備えることを特徴とする。
【００４１】
　請求項６の本発明のノードは、前記ツリーセレクタは、スパニングツリーの安定を示すフレームの到着間隔を判別するため、一定時間が経過するとタイマ満了通知を送信する到着間隔タイマを備えることを特徴とする。
【００４２】
　請求項７の本発明のノードは、前記ツリーセレクタは、リンクコストの算出に利用する指定時間のタイマ満了を知らせるコスト参照タイマを備えることを特徴とする。
【００４３】
　請求項８の本発明のノードは、前記ツリーマネージャが、フレームに付加されたタグを削除するタグ削除器と、ＢＰＤＵを送受信するＢＰＤＵ送受信器と、フレームにタグを付加するタグ挿入器と、スパニングツリープロトコルに従ってスパニングツリーを作成するツリーコントローラと、前記スパニングツリープロトコルで使用するパラメータを保持するツリーテーブルとを備えることを特徴とする。
【００４４】
　請求項９の本発明のノードは、前記ツリーマネージャは、通知されたリンクコストに所定の設定値を加算して返答するコスト操作器を備えることを特徴とする。
【００４５】
　請求項１０の本発明のノードは、リンクの接続状況や空き帯域を含むリソース情報を計測するリソースモニタを備えることを特徴とする。
【００４６】
　請求項１１の本発明のノードは、前記リンクコストを、利用状況に基づいて計算することを特徴とする。
【００４７】
　請求項１２の本発明のノードは、前記利用状況を、空き帯域と定義することを特徴とする。
【００４８】
　請求項１３の本発明のノードは、前記利用状況を、ＣＰＵ負荷と定義することを特徴とする。
【００４９】
　請求項１４の本発明は、複数のノードを接続したネットワーク上でスパニングツリーを構成するノードにおいて、ネットワーク内の各ノードがルートノードとなるスパニングツリーを生成し、宛先がルートノードとなるスパニングツリーを用いてフレームを転送することを特徴とする。
【００５０】
　請求項１５の本発明は、複数のノードを接続したネットワーク上でスパニングツリーを構成するノードにおいて、独立して動作する複数のスパニングツリーを生成する複数のツリーマネージャと、転送に利用しているスパニングツリーに対応したタグを返答するタグテーブルと、前記タグテーブルより返答のあったタグをフレームに挿入するタグ挿入器と、ネットワークに存在するルートノード数と同数のツリーマネージャを生成するツリーセレクタと、宛先ごとのフレームの転送出力先を記録するフォワーディングテーブルと、前記フォワーディングテーブルで指定された転送出力先にフレームを転送するフレーム転送器と、前記タグに従って前記フレームの転送先のツリーマネージャを決定する分別器とを備えることを特徴とする。
【００５１】
　請求項１６の本発明のノードは、前記ツリーセレクタが、ツリーマネージャの作成もしくは削除を行うメインコントローラと、フレームに付加されたタグを削除するタグ削除器と、スパニングツリーの切り替えのための制御フレームを送信するＧＶＲＰ送受信器と、フレームにタグを付加するタグ挿入器とを備えることを特徴とする。
【００５２】
　請求項１７の本発明のノードは、前記ツリーマネージャが、フレームに付加されたタグを削除するタグ削除器と、ＢＰＤＵを送受信するＢＰＤＵ送受信器と、フレームにタグを付加するタグ挿入器と、スパニングツリープロトコルに従ってスパニングツリーを作成するツリーコントローラと、前記スパニングツリープロトコルで使用するパラメータを保持するツリーテーブルとを備えることを特徴とする。
【００５３】
　請求項１８の本発明のノードは、リンクの接続状況や空き帯域を含むリソース情報を計測するリソースモニタを備えることを特徴とする。
【００５４】
　請求項１９の本発明は、複数のノードを接続したネットワーク上でスパニングツリーを構成するノードにおいて、スパニングツリーを生成するツリーマネージャが、スパニングツリープロトコルの種類およびバージョンにより、コスト値を調整するコスト操作器を備えることを特徴とする。
【００５５】
　請求項２０の本発明のノードは、前記コスト操作器は、障害回復処理が遅いプロトコルを利用しているリンクに対して、大きなコストを割り振ることを特徴とする。
【００５６】
　請求項２１の本発明は、複数のノードを接続したネットワーク上でスパニングツリーを構成するノードにおいて、ネットワーク内の動作の遅いプロトコルを使用中のリンクのそれぞれについて、前記各リンクのコストが最大となるスパニングツリーを生成し、前記各リンクに障害が発生した際に、前記リンクのコストが最大となっているツリーを利用してフレーム転送を行うことを特徴とする。
【００５７】
　請求項２２の本発明は、複数のノードを接続したネットワーク上でスパニングツリーを構成するノードにおいて、独立して動作する複数のスパニングツリーを生成する複数のツリーマネージャと、転送用ツリーに対応したタグを返答するタグテーブルと、前記タグテーブルより返答のあったタグをフレームに挿入するタグ挿入器と、ネットワークに存在する動作の遅いプロトコルを使用中のリンク数と同数のツリーマネージャを生成するツリーセレクタと、宛先ごとのフレーム転送出力先を記録するフォワーディングテーブルと、前記フォワーディングテーブルで指定された転送出力先にフレームを転送するフレーム転送器と、前記タグに従って転送先のツリーマネージャを決定する分別器とを備えることを特徴とする。
【００５８】
　請求項２３の本発明のノードは、前記ツリーセレクタが、ツリーマネージャの作成もしくは削除を行うツリーセレクタ内のメインコントローラと、フレームに付加されたタグを削除するタグ削除器と、制御フレームを送信するＧＶＲＰ送受信器と、フレームにタグを付加するタグ挿入器とを備えることを特徴とする。
【００５９】
　請求項２４の本発明のノードは、前記ツリーマネージャが、フレームに付加されたタグを削除するタグ削除器と、ＢＰＤＵを送受信するＢＰＤＵ送受信器と、フレームにタグを付加するタグ挿入器と、スパニングツリープロトコルにしたがってスパニングツリーを作成するツリーコントローラと、スパニングツリープロトコルで使用するパラメータを保持するツリーテーブルとを備えることを特徴とする。
【００６０】
　請求項２５の本発明のノードは、リンクの接続状況や空き帯域を含むリソース情報を計測するリソースモニタを備えることを特徴とする。
【００６１】
　請求項２６の本発明のノードは、スパニングツリープロトコルで利用されているＨＥＬＬＯフレームより、短い間隔で障害検出用フレームを送受信して障害を検出する障害検出器を備えることを特徴とする。
【００６２】
　請求項２７の本発明のノードは、前記フォワーディングテーブルが、ブロードキャスト出力ポートフィールドを有することを特徴とする。
【００６３】
　請求項２８の本発明のノードは、前記フォワーディングテーブルが、予備出力ポートフィールドを有することを特徴とする。
【００６４】
　請求項２９の本発明のノードは、スパニングツリーによって決定されるポート種別を用いて、出力先ポートを決定することを特徴とする。
【００６５】
　請求項３０の本発明のノードは、前記スパニングツリーによって決定されるポート種別が、ルートポート及びディジグネイテッドポートの何れかであることを特徴とする。
【００６６】
　請求項３１の本発明は、複数のノードを接続したネットワーク上でスパニングツリーを構成する各ノード上で動作するスパニングツリー構成プログラムにおいて、ネットワークの構成変更前のスパニングツリーを運用したまま、構成変更後の新たなスパニングツリーを生成し、前記新たなスパニングツリーの安定後に、転送に利用するスパニングツリーを前記新たなスパニングツリーに切り替える処理を実行することを特徴とする。
【００６７】
　請求項３２の本発明のスパニングツリー構成プログラムは、前記ネットワークの構成変更が、ノードの追加又は削除やリンクトポロジの変化であることを特徴とする。
【００６８】
　請求項３３の本発明は、複数のノードを接続したネットワーク上でスパニングツリーを構成する各ノード上で動作するスパニングツリー構成プログラムにおいて、ネットワークのコスト変更時に、現スパニングツリーを運用したまま、リンクコスト変更後の新たなスパニングツリーを生成し、前記新たなスパニングツリーの安定後に、転送に利用するスパニングツリーを前記新たなスパニングツリーに切り替える処理を実行することを特徴とする。
【００６９】
　請求項３４の本発明は、複数のノードを接続したネットワーク上でスパニングツリーを構成する各ノード上で動作するスパニングツリー構成プログラムにおいて、複数のツリーマネージャによる独立して動作する複数のスパニングツリーを生成する処理と、転送に利用しているスパニングツリーに対応したタグを返答する処理と、返答のあった前記タグをフレームに挿入するタグ挿入処理と、転送に利用するツリーを決定するツリーセレクタ処理と、宛先ごとのフレームの転送出力先を記録するフォワーディングテーブル処理と、前記フォワーディングテーブルで指定された転送出力先にフレームを転送するフレーム転送処理と、前記タグに従って転送先のツリーマネージャを決定する分別処理とを実行することを特徴とする。
【００７０】
　請求項３５の本発明のスパニングツリー構成プログラムは、前記ツリーセレクタ処理において、転送に利用するスパニングツリーの切り替えを行うコントローラ処理と、スパニングツリーの安定を示す指定した時間のタイマ満了を知らせる安定タイマ処理と、フレームに付加されたタグを削除するタグ削除処理と、スパニングツリーの切り替えのための制御フレームを送信するＧＶＲＰ送受信処理と、フレームにタグを付加するタグ挿入処理とを実行することを特徴とする。
【００７１】
　請求項３６の本発明のスパニングツリー構成プログラムは、前記ツリーセレクタ処理において、スパニングツリーの安定を示すフレームの到着間隔を判別するため、一定時間が経過すると、タイマ満了通知を送信する到着間隔タイマ処理を実行することを特徴とする。
【００７２】
　請求項３７の本発明のスパニングツリー構成プログラムは、前記ツリーセレクタ処理は、リンクコストの算出に利用する指定時間のタイマ満了を知らせるコスト参照タイマ処理を実行することを特徴とする。
【００７３】
　請求項３８の本発明のスパニングツリー構成プログラムは、前記ツリーマネージャ処理が、フレームに付加されたタグを削除するタグ削除処理と、ＢＰＤＵを送受信するＢＰＤＵ送受信処理と、フレームにタグを付加するタグ挿入処理と、スパニングツリープロトコルに従ってスパニングツリーを作成するツリーコントローラ処理と、前記スパニングツリープロトコルで使用するパラメータを保持するツリーテーブル処理とを実行することを特徴とする。
【００７４】
　請求項３９の本発明のスパニングツリー構成プログラムは、前記ツリーマネージャ処理は、通知されたリンクコストに所定の設定値を加算して返答するコスト操作処理を実行することを特徴とする。
【００７５】
　請求項４０の本発明のスパニングツリー構成プログラムは、リンクの接続状況や空き帯域を含むリソース情報を計測するリソースモニタ処理を実行することを特徴とする。
【００７６】
　請求項４１の本発明のスパニングツリー構成プログラムは、リンクコストを、利用状況により計算する処理を実行することを特徴とする。
【００７７】
　請求項４２の本発明のスパニングツリー構成プログラムは、前記利用状況を、空き帯域と定義することを特徴とする。
【００７８】
　請求項４３の本発明のスパニングツリー構成プログラムは、前記利用状況を、ＣＰＵ負荷と定義することを特徴とする。
【００７９】
　請求項４４の本発明は、複数のノードを接続したネットワーク上でスパニングツリーを構成する各ノード上で動作するスパニングツリー構成プログラムにおいて、ネットワーク内の各ノードがルートノードとなるスパニングツリーを生成し、宛先がルートノードとなるツリーを用いてフレームを転送することを特徴とする。
【００８０】
　請求項４５の本発明は、複数のノードを接続したネットワーク上でスパニングツリーを構成する各ノード上で動作するスパニングツリー構成プログラムにおいて、独立して動作する複数のスパニングツリーを生成する複数のツリーマネージャ処理と、転送に利用しているスパニングツリーに対応したタグを返答するタグテーブル処理と、前記タグテーブルより返答のあったタグをフレームに挿入するタグ挿入処理と、ネットワークに存在するルートノード数と同数のツリーマネージャを生成するツリーセレクタ処理と、宛先ごとのフレーム転送出力先を記録するフォワーディングテーブル処理と、前記フォワーディングテーブルで指定された転送出力先にフレームを転送するフレーム転送処理と、前記タグに従って前記フレームの転送先のツリーマネージャを決定する分別処理とを備えることを特徴とする。
【００８１】
　請求項４６の本発明のスパニングツリー構成プログラムは、前記ツリーセレクタ処理が、ツリーマネージャの作成もしくは削除を行うツリーセレクタ内のメインコントローラ処理と、フレームに付加されたタグを削除するタグ削除処理と、スパニングツリーの切り替えのための制御フレームを送信するＧＶＲＰ送受信処理と、フレームにタグを付加するタグ挿入処理とを実行することを特徴とする。
【００８２】
　請求項４７の本発明のスパニングツリー構成プログラムは、前記ツリーマネージャ処理が、フレームに付加されたタグを削除するタグ削除処理と、ＢＰＤＵを送受信するＢＰＤＵ送受信処理と、フレームにタグを付加するタグ挿入処理と、スパニングツリープロトコルに従ってスパニングツリーを作成するツリーコントローラ処理と、前記スパニングツリープロトコルで使用するパラメータを保持するツリーテーブル処理とを実行することを特徴とする。
【００８３】
　請求項４８の本発明のスパニングツリー構成プログラムは、各前記ノードは、リンクの接続状況や空き帯域を含むリソース情報を計測するリソースモニタ処理を実行することを特徴とする。
【００８４】
　請求項４９の本発明は、複数のノードを接続したネットワーク上でスパニングツリーを構成する各ノードで動作するスパニングツリー構成プログラムにおいて、ネットワーク内の動作の遅いプロトコルを使用中のリンクのそれぞれについて、前記各リンクのコストが最大となるスパニングツリーを生成し、前記各リンクに障害が発生した際に、前記リンクのコストが最大となっているツリーを利用してフレーム転送を行うことを特徴とする。
【００８５】
　請求項５０の本発明は、複数のノードを接続したネットワーク上でスパニングツリーを構成する各ノードで動作するスパニングツリー構成プログラムにおいて、独立して動作する複数のスパニングツリーを生成する複数のツリーマネージャ処理と、転送用ツリーに対応したタグを返答するタグテーブル処理と、前記タグテーブルより返答のあったタグをフレームに挿入するタグ挿入処理と、ネットワークに存在する動作の遅いプロトコルを使用中のリンク数と同数のツリーマネージャを生成するツリーセレクタ処理と、宛先ごとのフレームの転送出力先を記録するフォワーディングテーブル処理と、前記フォワーディングテーブルで指定された転送出力先にフレームを転送するフレーム転送処理と、前記タグに従ってフレームの転送先のツリーマネージャを決定する分別処理とを備えることを特徴とする。
【００８６】
　請求項５１の本発明のスパニングツリー構成プログラムは、前記ツリーセレクタ処理が、ツリーマネージャの作成もしくは削除を行うツリーセレクタ内のメインコントローラ処理と、フレームに付加されたタグを削除するタグ削除処理と、制御フレームを送信するＧＶＲＰ送受信処理と、フレームにタグを付加するタグ挿入処理とを備えることを特徴とする。
【００８７】
　請求項５２の本発明のスパニングツリー構成プログラムは、前記ツリーマネージャ処理が、フレームに付加されたタグを削除するタグ削除処理と、ＢＰＤＵを送受信するＢＰＤＵ送受信処理と、フレームにタグを付加するタグ挿入処理と、スパニングツリープロトコルにしたがってスパニングツリーを作成するツリーコントローラ処理と、スパニングツリープロトコルで使用するパラメータを保持するツリーテーブル処理とを備えることを特徴とする。
【００８８】
　請求項５３の本発明のスパニングツリー構成プログラムは、各前記ノードは、リンクの接続状況や空き帯域を含むリソース情報を計測するリソースモニタ処理を実行することを特徴とする。
【００８９】
　請求項５４の本発明のスパニングツリー構成プログラムは、前記フォワーディングテーブルが、ブロードキャスト出力ポートフィールドを有することを特徴とする。
【００９０】
　請求項５５の本発明のスパニングツリー構成プログラムは、前記フォワーディングテーブルが、予備出力ポートフィールドを有することを特徴とする。
【００９１】
　請求項５６の本発明のスパニングツリー構成プログラムは、スパニングツリーによって決定されるポート種別を用いて、出力先ポートを決定することを特徴とする。
【００９２】
　請求項５７の本発明のスパニングツリー構成プログラムは、前記スパニングツリーによって決定されるポート種別が、ルートポート及びディジグネイテッドポートの何れかであることを特徴とする。
【００９３】
　請求項５８の本発明は、複数のノードを接続したネットワーク上でスパニングツリーによって転送経路を設定するネットワークシステムにおいて、各前記ノードが、ネットワークの構成変更前のスパニングツリーを運用したまま、構成変更後の新たなスパニングツリーを生成し、前記新たなスパニングツリーの安定後に、転送に利用するスパニングツリーを前記新たなスパニングツリーに切り替えることを特徴とする。
【００９４】
　請求項５９の本発明は、複数のノードを接続したネットワーク上でスパニングツリーによって転送経路を設定するネットワークシステムにおいて、各前記ノードが、ネットワークのコスト変更時に、現スパニングツリーを運用したまま、リンクコスト変更後の新たなスパニングツリーを生成し、前記新たなスパニングツリーの安定後に、転送に利用するスパニングツリーを前記新たなスパニングツリーに切り替えることを特徴とする。
【００９５】
　請求項６０の本発明は、複数のノードを接続したネットワーク上でスパニングツリーによって転送経路を設定するネットワークシステムにおいて、各前記ノードが、独立して動作する複数のスパニングツリーを生成する複数のツリーマネージャと、転送に利用しているスパニングツリーに対応したタグを返答するタグテーブルと、前記タグテーブルより返答のあったタグをフレームに挿入するタグ挿入器と、転送に利用するスパニングツリーを決定するツリーセレクタと、宛先ごとのフレームの転送出力先を記録するフォワーディングテーブルと、前記フォワーディングテーブルで指定された転送出力先にフレームを転送するフレーム転送器と、前記タグに従って前記フレームの転送先のツリーマネージャを決定する分別器とを備えることを特徴とする。
【００９６】
　請求項６１の本発明のネットワークシステムは、リンクコストを、利用状況により計算することを特徴とする。
【００９７】
　請求項６２の本発明は、複数のノードを接続したネットワーク上でスパニングツリーによって転送経路を設定するネットワークシステムにおいて、ネットワーク内の各ノードがルートノードとなるスパニングツリーを生成し、宛先がルートノードとなるツリーを用いてフレームを転送することを特徴とする。
【００９８】
　請求項６３の本発明は、複数のノードを接続したネットワーク上でスパニングツリーによって転送経路を設定するネットワークシステムにおいて、独立して動作する複数のスパニングツリーを生成する複数のツリーマネージャと、転送用ツリーに対応したタグを返答するタグテーブルと、前記タグテーブルより返答のあったタグをフレームに挿入するタグ挿入器と、ネットワークに存在するノード数と同数のツリーマネージャを生成するツリーセレクタと、宛先ごとのフレーム転送出力先を記録するフォワーディングテーブルと、前記フォワーディングテーブルで指定された転送出力先にフレームを転送するフレーム転送器と、前記タグに従って前記フレームの転送先のツリーマネージャを決定する分別器とを備えることを特徴とする。
【００９９】
　請求項６４の本発明は、複数のノードを接続したネットワーク上でスパニングツリーによって転送経路を設定するネットワークシステムにおいて、スパニングツリーを生成するツリーマネージャが、スパニングツリープロトコルの種類およびバージョンにより、コスト値を調整するコスト操作処理を実行することを特徴とする。
【０１００】
　請求項６５の本発明は、複数のノードを接続したネットワーク上でスパニングツリーによって転送経路を設定するネットワークシステムにおいて、スパニングツリーを生成するツリーマネージャが、スパニングツリープロトコルの種類およびバージョンにより、コスト値を調整するコスト操作器を備えることを特徴とする。
【０１０１】
　請求項６６の本発明は、複数のノードを接続したネットワーク上でスパニングツリーによって転送経路を設定するネットワークシステムにおいて、ネットワーク内の動作の遅いプロトコルを使用中のリンクのそれぞれについて、前記各リンクのコストが最大となるスパニングツリーを生成し、前記各リンクに障害が発生した際に、前記リンクのコストが最大となっているツリーを利用してフレーム転送を行うことを特徴とする。
【０１０２】
　請求項６７の本発明は、複数のノードを接続したネットワーク上でスパニングツリーによって転送経路を設定するネットワークシステムにおいて、独立して動作する複数のスパニングツリーを生成する複数のツリーマネージャと、転送用ツリーに対応したタグを返答するタグテーブルと、前記タグテーブルより返答のあったタグをフレームに挿入するタグ挿入器と、ネットワークに存在する動作の遅いプロトコルを使用中のリンク数と同数のツリーマネージャを生成するツリーセレクタと、宛先ごとのフレーム転送出力先を記録するフォワーディングテーブルと、前記フォワーディングテーブルで指定された転送出力先にフレームを転送するフレーム転送器と、前記タグに従って前記フレームの転送先のツリーマネージャを決定する分別器とを備えることを特徴とする。
【０１０３】
　請求項６８の本発明のネットワークシステムは、前記フォワーディングテーブルが、ブロードキャスト出力ポートフィールドを有することを特徴とする。
【０１０４】
　請求項６９の本発明のネットワークシステムは、前記フォワーディングテーブルが、予備出力ポートフィールドを有することを特徴とする。
【０１０５】
　請求項７０の本発明のネットワークシステムは、スパニングツリーによって決定されるポート種別を用いて、出力先ポートを決定することを特徴とする。
【０１０６】
　請求項７１の本発明のネットワークシステムは、前記スパニングツリーによって決定されるポート種別が、ルートポート及びディジグネイテッドポートの何れかであることを特徴とする。
【０１０７】
　請求項７２の本発明は、複数のノードを接続したネットワークにおけるスパニングツリー構成方法であって、ネットワークの構成変更前のスパニングツリーを運用したまま、構成変更後の新たなスパニングツリーを生成し、前記新たなスパニングツリーの安定後に、転送に利用するスパニングツリーを前記新たなスパニングツリーに切り替えることを特徴とする。
【０１０８】
　請求項７３の本発明は、複数のノードを接続したネットワークにおけるスパニングツリー構成方法であって、ネットワークのコスト変更時に、現スパニングツリーを運用したまま、リンクコスト変更後の新たなスパニングツリーを生成し、前記新たなスパニングツリーの安定後に、転送に利用するスパニングツリーを前記新たなスパニングツリーに切り替えることを特徴とする。
【０１０９】
　請求項７４の本発明は、複数のノードを接続したネットワークにおけるスパニングツリー構成方法であって、新規ノードを追加する際に、新規ノードを既存スパニングツリーに参加させず、予備スパニングツリーにのみ参加させることを特徴とする。
【０１１０】
　請求項７５の本発明は、複数のノードを接続したネットワークにおけるスパニングツリー構成方法であって、ノードを削除する際に、削除ノードを予備スパニングツリーに参加させず、既存スパニングツリーのみに参加させることを特徴とする。
【０１１１】
　請求項７６の本発明は、複数のノードを接続したネットワークにおけるスパニングツリー構成方法であって、ネットワーク構成が変更された時、予備系を用いて変更後のツリー作成を行うことを特徴とする。
【０１１２】
　請求項７７の本発明は、複数のノードを接続したネットワークにおけるスパニングツリー構成方法であって、コスト算出に、リンクの空き帯域を利用することを特徴とする。
【０１１３】
　請求項７８の本発明は、複数のノードを接続したネットワークにおけるスパニングツリー構成方法であって、ネットワーク内の全ノードが、全ノードをメンバに持つスパニングツリーのうち、どれか１つのルートノードとなるよう、複数のスパニングツリーを作成することを特徴とする。
【０１１４】
　請求項７９の本発明は、複数のノードを接続したネットワークにおけるスパニングツリー構成方法であって、ネットワーク内に存在する全ノードをメンバに持つスパニングツリーを作成し、うち、障害復旧の遅いプロトコルを使用しているリンクごとに複数のスパニングツリーを作成することを特徴とする。
【０１１５】
　請求項８０の本発明は、複数のノードを接続したネットワークにおいて信号伝送に用いる論理トポロジを形成する方法であって、ネットワークの構成変更前の論理トポロジを用いて信号伝送を行っている状態で、ネットワークの構成変更後の論理トポロジを生成し、前記構成変更後の論理トポロジ安定後に、信号伝送に用いる論理トポロジを前記構成変更後の論理トポロジに切り替えることを特徴とする。
【０１１６】
　請求項８１の本発明のノードは、、自らが属するネットワークにおいて信号伝送に用いる論理トポロジを用いて信号伝送を行っている状態で、前記ネットワークの構成変更時に、ネットワークの構成変更後の論理トポロジを生成する手段と、前記構成変更後の論理トポロジ安定後に、信号伝送に用いる論理トポロジを前記構成変更後の論理トポロジに切り替える手段とを有する。
【０１１７】
　請求項８２の本発明のプログラムは、自らが属するネットワークにおいて信号伝送に用いる論理トポロジを用いて信号伝送を行っている状態で、前記ネットワークの構成変更時に、ネットワークの構成変更後の論理トポロジを生成する処理と、前記構成変更後の論理トポロジ安定後に、信号伝送に用いる論理トポロジを前記構成変更後の論理トポロジに切り替える処理とを実行することを特徴とする。
【０１１８】
　請求項８３の本発明は、複数のノードを接続したネットワークシステムであって、ネットワークの構成変更前の論理トポロジを用いて信号伝送を行っている状態で、ネットワークの構成変更後の論理トポロジを生成し、前記構成変更後の論理トポロジ安定後に、信号伝送に用いる論理トポロジを前記構成変更後の論理トポロジに切り替えることを特徴とする。
【０１１９】
　請求項８４の本発明のノードは、入力されるフレームが保持する宛先に関する情報と当該フレームの転送先との対応関係をスパニングツリープロトコルを用いて作成する手段と、前記対応関係を参照し、入力されたフレームの転送先を決定する手段とを有する。
【発明の効果】
【０１２０】
　本発明によれば、以下のような効果が達成される。
【０１２１】
　第１に、輻輳発生の確率を下げ、輻輳によるフレームの到着遅れや欠落が発生する頻度を減らすことができる。その理由は、構成変更前のスパニングツリーを運用したまま、新規追加ノードを含めたスパニングツリーを生成し、新規スパニングツリーの安定後に利用するスパニングツリーを切り替え、さらに、ルートノードの異なるスパニングツリーを複数系統設定するからである。
【０１２２】
　第２に、ネットワークを停止させずに、スパニングツリーに属するノードの追加および削除等のスパニングツリー再構成できる。その理由は、構成変更前のスパニングツリーを運用したまま、新規追加ノードを含めたスパニングツリーを生成し、新規スパニングツリーの安定後に利用するスパニングツリーを切り替えるからである。
【０１２３】
　第３に、トラフィックの負荷分散ができる。その理由は、リンクコストを、空き帯域やサーバ負荷等の動的情報によって計算するからである。
【０１２４】
　第４に、経路変更にともなうスパニングツリー再構成のために、ネットワークを停止させることなく負荷分散ができる。その理由は、変更前のツリーを運用したまま、コスト変更後のツリーを生成し、新規ツリーの安定後に利用するツリーを切り替えるからである。
【０１２５】
　第５に、宛先への最低コスト経路を選択することができる。その理由は、宛先がルートノードとなるツリーを用いてフレームを転送するからである。
【０１２６】
　第６に、リンク利用率を高め、ルートノード付近に負荷を集中させずに分散可能である。その理由は、ルートノードの異なるスパニングツリーを複数系統設定するからである。
【０１２７】
　第７に、ルートノード障害によるネットワーク停止を回避可能である。その理由は、宛先がルートノードとなるツリーを用いてフレームを転送することにより、ルートノードが宛先となるフレーム以外のフレームが、ルートノード障害の影響により長時間転送不能となることがないからである。
【０１２８】
　第８に、スパニングツリーがＩＥＥＥ８０２．１Ｄ利用区間を通過して設定されるのを防ぎ、障害時の切替やルート変更を高速化し、輻輳発生の可能性やフレームの欠落の可能性を低下させることが可能である。その理由は、ＩＥＥＥ８０２．１Ｄ利用区間のコストを大きく設定し、スパニングツリーがＩＥＥＥ８０２．１Ｄ利用区間を通過して設定されるのを防ぐからである。
【０１２９】
　第９に、迂回操作を高速に行い、輻輳の発生やフレームの欠落を防止できる。その理由は、ＩＥＥＥ８０２．１Ｄ利用区間の数だけツリーマネージャを作成し、相異なる１つのＩＥＥＥ８０２．１Ｄ利用区間のコストを大きく設定したツリーをＩＥＥＥ８０２．１Ｄ利用区間分作成し、障害等により前記区間を迂回する必要が生じた場合は、前記区間に対して大きなコストを振ったツリーを利用するよう切り替えるからである。
【０１３０】
　第１０に、従来、スパニングツリープロトコルで利用されているＨＥＬＬＯフレームの送信間隔が長かったため、高速な障害検出ができなかったが、短い間隔で障害検出用フレームを送受信する障害検出器を追加することにより、ＨＥＬＬＯフレームよりも高速な障害検出が可能となる。また、この結果、輻輳発生およびフレーム欠落の可能性を下げることが可能となる。
【０１３１】
　第１１に、従来、ブロードキャスト時に、宛先への最低コスト経路が必ずしも選択されるとは限らなかったが、本発明では、送信元ノードがルートノードとなるツリーを用いてブロードキャストフレームを転送することにより、全ノードへの最低コスト経路を選択してブロードキャストフレームを転送することができる。
【０１３２】
　第１２に、送信元ノードがルートノードとなるツリーを用いてブロードキャストフレームを転送することにより、ルートノードが送信元ノードとなるフレーム以外のブロードキャストフレームが、ルートノード障害の影響により長時間転送不能となることがないため、ルートノード障害によるネットワーク停止を回避可能である。また、この結果、輻輳発生の可能性を下げることが可能である。
【０１３３】
　第１３に、従来、宛先への最低コスト経路が必ずしも選択されるとは限らなかったが、宛先がルートノードとなるツリーを用いてユニキャストフレームを転送することにより、宛先への最低コスト経路を選択することができる。
【０１３４】
　第１４に、従来、ルートポート側リンク障害時の出力先ポートの切替に時間がかかり、その間、フレーム転送が停止するという問題があったが、本発明では、あらかじめ出力リンク障害時のための予備出力リンクをフォワーディングテーブルに設定しておくことで、ルートポート側リンク、すなわち出力リンクの障害時において、高速な経路変更が可能である。この結果、輻輳発生の可能性を下げることが可能である。
【実施例】
【０１３５】
　以降の説明の中で、複数のスパニングツリーおよび複数のノード群を識別する識別子としてタグを用いた説明を行うが、このタグは、ＶＬＡＮタグのほかに、本特許出願人による特願２００２−２０４６７３号に開示される拡張タグ及び他のタグもしくは識別手段のうち、単独もしくは何れか１つ以上の組み合わせを意味する。
【０１３６】
　ここで、本発明において用いるタグのうち、上記特願２００２−２０４６７３号に開示される拡張タグ付きフレームのフォーマットについて説明する。
【０１３７】
　図１は、ＩＥＥＥ８０２．１Ｑで規定されているＶＬＡＮタグ付きのイーサネット(R)フレームのフォーマットである。ＶＬＡＮタグ付きイーサネット(R)フレーム３２００は、送信先ＭＡＣアドレス３２０１と、送信元ＭＡＣアドレス３２０２と、ＶＬＡＮタグ３２０３と、イーサネット(R)属性情報３２０４と、ペイロード３２０５と、ＦＣＳ３２０６とから構成される。
【０１３８】
　これに対して、図２は、本発明の拡張タグ付きイーサネット(R)フレームのフォーマットである。拡張タグ付きイーサネット(R)フレーム３３００は、送信先ＭＡＣアドレス３２０１と、送信元ＭＡＣアドレス３２０２と、拡張タグ格納領域３３０１と、イーサネット(R)属性情報３２０４と、ペイロード３２０５と、ＦＣＳ３２０６とから構成され、既存のＶＬＡＮタグ付きイーサネット(R)フレーム３２００のＶＬＡＮタグ３２０３が拡張タグ格納領域３３０１に置き換わる。
【０１３９】
　また図３に示すように別の構成の拡張タグ付きイーサネット(R)フレーム３４００も存在し、これは送信先ＭＡＣアドレス３２０１と、送信元ＭＡＣアドレス３２０２と、拡張タグ格納領域３３０１と、ＶＬＡＮタグ３２０３と、イーサネット(R)属性情報３２０４と、ペイロード３２０５と、ＦＣＳ３２０６とから構成され、拡張タグ格納領域３３０１は送信元ＭＡＣアドレス３２０２の後に挿入される。
【０１４０】
　拡張タグ格納領域３３０１には１つまたは複数の拡張タグを格納可能である。拡張タグのサイズは４バイトであり、ＶＬＡＮタグ３２０３と同一サイズとなっている。拡張タグ付きイーサネット(R)フレーム３３００、３４００の最上段の拡張タグとＶＬＡＮタグ付きイーサネット(R)フレーム３２００のＶＬＡＮタグは同一の位置に同一のサイズで格納されており、その区別は各々のタグの上位２バイトに格納される値を変更することにより区別する（詳細については後述する）。
【０１４１】
　これにより、拡張タグ付きイーサネット(R)フレーム３３００、３４００は、ＶＬＡＮタグ付きイーサネット(R)フレーム３２００と互換性を有しており、既存ノード、拡張タグ対応ノードの双方においてどちらのフレームも処理可能である。
【０１４２】
　図４は、拡張タグ格納領域３３０１を示している。図４に示す格納例では、８個の拡張タグ３５００〜３５０７が格納されている。
【０１４３】
　フォワーディングタグ３５００には宛先ノードの識別子や宛先までのラベル（例えばＭＰＬＳラベル）が格納される。また、宛先ノードの識別子を格納したフォワーディングタグ３５００に加えて、送信元ノードの識別子を格納する場合もある。各ノードはこのフォワーディングタグを参照してフレーム転送先を決定する。このフォワーディングタグ３５００は拡張タグ付きイーサネット(R)フレーム３３００、３４００において必ず格納される。
【０１４４】
　拡張タグの種類としては、カスタマ分離タグ３５０１、プロテクションタグ３５０２、ＯＡＭ＆Ｐタグ３５０３、品質情報タグ３５０４、フレーム制御タグ３５０５、セキュリティタグ３５０６、ユーザ拡張タグ３５０７が格納されている。
【０１４５】
　カスタマ分離タグ３５０２には、各ノードに収容されるカスタマ毎に情報を分離するための識別子が格納される。カスタマとしては、同一のＶＬＡＮの所属するカスタマを同一カスタマとする場合や、２つ以上のノードの特定のポートに収容されるカスタマを同一カスタマとする場合や、網内のノードに接続する２つ以上のホストを同一カスタマとする場合などがある。これらのカスタマに対して分離識別子が割り当てられ、各カスタマからのフレームにはカスタマ分離タグ３５０２内にこの分離識別子が格納される。カスタマ分離タグ３５０２によってカスタマを識別することにより、カスタマ単位の付加サービス（例えば、特定カスタマに対する優先制御など）の提供が可能となる。また、カスタマ分離タグ３５０２は複数スタックして使うことも可能である。この場合、分離可能なカスタマ数を大幅に増やすことができる。なお、カスタマ分離タグ３５０２をスタックする場合には、スタックした最終段のカスタマ分離タグ３５０２は最終段であることを示す特別なカスタマ分離タグを使用する。
【０１４６】
　プロテクションタグ３５０３には、障害発生時の障害情報や障害復旧のための迂回経路情報が格納される。ＯＡＭ＆Ｐタグ３５０４には、運用／管理情報が格納される。
【０１４７】
　品質情報タグ３５０５には、遅延、ジッタ、パケットロス率やフレームのネットワーク内への流入時間を示すタイムスタンプ、帯域制御情報等の品質情報が格納される。品質情報タグ３５０５にタイムスタンプ値が格納されている場合、フレームを受信したノードは現在の時刻とタイムスタンプ値よりそのフレームの網内遅延（ネットワーク内での滞在時間）を算出することができる。網内遅延の保証値が定められている場合には、保証値を実現できるよう優先処理を実施することができる。また、品質情報タグ３５０５に要求帯域や蓄積データ量やトラヒッククラス等の帯域制御情報が格納されている場合、そのフローの蓄積データ量やトラヒッククラスと他のフローのトラヒック状況を考慮して、要求帯域を確保するための帯域制御を実施することができる。
【０１４８】
　フレーム制御タグ３５０６には、フレームのネットワーク内での生存時間を制限するホップカウンタ（ＴＴＬ　：　Ｔｉｍｅ　Ｔｏ　Ｌｉｖｅ）や誤り検出のためのＣＲＣなどの情報が格納される。ＴＴＬが格納される場合には、経由するノード毎にＴＴＬ値が減算され、ＴＴＬ＝０となったところでこのフレームは廃棄される。これにより、ループ経路になった場合でもフレームが循環し続けるのを防ぐことができる。またＣＲＣが格納される場合には、入口側ノードにおける拡張タグ格納領域３３０１のＣＲＣ演算結果が格納されており、出口側ノードにおいて再度ＣＲＣ演算を実施して格納値と比較することにより、拡張タグ格納領域３３０１の誤りを検出可能である。
【０１４９】
　セキュリティタグ３５０７には、フレームの信頼性、ネットワーク構築時やネットワーク構成変更時の秘匿性を確保するための情報が格納される。セキュリティタグ３５０７の利用例としては以下の例があげられる。ネットワーク内で通信するカスタマにはカスタマ毎のセキュリティ識別子が予め設定され、その識別子はカスタマが接続する各ノードで保持される。各カスタマはフレーム転送の際に、設定されたセキュリティ識別子を常にセキュリティタグ３５０７に格納することにより、カスタマ分離タグ３５０１の情報を改ざんした悪意のあるカスタマからのフレーム送受信を防ぐことができる。また、ネットワーク構築時やネットワーク構成変更時において、ノード間でネゴシエートして共通のセキュリティ識別子を設定する。当該ノード間のフレーム転送の際に、設定したセキュリティ識別子を常にセキュリティタグ３５０７に格納することにより、悪意のあるノードをネットワークに接続するのを防ぐことができる。
【０１５０】
　ユーザ拡張タグ３５０７には、ユーザが独自に定義する任意の情報が格納される。ユーザが独自にタグのフォーマット及び格納情報を定義し、その処理内容を定義することにより、ユーザ独自の機能拡張を図ることができ、ネットワークの柔軟性を高められる。
【０１５１】
　フォワーディングタグ３５００以外の拡張タグ３５０１〜３５０７は、必要に応じて格納される。フォワーディングタグ３５００は、拡張タグ格納領域３３０１の先頭に格納され、その他の拡張タグ３５０１〜３５０７はその後方に格納される。フォワーディングタグ３５００よりも後方であれば、予め決められた固定位置でも、任意の位置でも良い。
【０１５２】
　以降、２系統存在するスパニングツリーのうち、新しくネットワークに侵入するデータフレームの転送に利用しているスパニングツリーを現用ツリーもしくは現用系ツリー、現用ツリーとなっていないツリーを予備用ツリーもしくは予備系ツリーと表現する。
【０１５３】
　また、現用系ツリーの生成を行うツリーマネージャを現用系ツリーマネージャ、予備系ツリーの生成を行うツリーマネージャを、予備系ツリーマネージャと呼ぶ。
【０１５４】
　タググループとは、タグおよびその他の識別子を利用して識別されるノード群、すなわち複数のノードの集合体をいう。タググループをＶＬＡＮタグを識別子として形成した場合は、前記タググループをＶＬＡＮと呼ぶ。
【０１５５】
　ＢＰＤＵ(Bridge Protocol Data Unit)とは、スパニングツリー生成のために交換されるＩＥＥＥ８０２．１Ｄ（従来技術１）およびＩＥＥＥ８０２．１ｗ（従来技術２）に記載される制御データおよび、本発明の現用系と予備系の識別情報等を含む制御フレームのことをいう。
【０１５６】
　図５は、ＩＥＥＥ８０２．１Ｄ（従来技術１）およびＩＥＥＥ８０２．１ｗ（従来技術２）に記載の、Ｃｏｎｆｉｇｕｒａｔｉｏｎ　ＢＰＤＵフレーム２２０５の構造を示すフォーマット図である。
【０１５７】
　ＭＡＣ　ＤＡ２２０１は、宛先ＭＡＣアドレスを格納する領域である。
【０１５８】
　ＭＡＣ　ＳＡ２２０２は、送信元ＭＡＣアドレスを格納する領域である。
【０１５９】
　タグ領域２２０３は、複数のスパニングツリーを識別する識別子としてのタグを挿入する領域である。また、従来技術には記載されていないが、前記タグは、ＶＬＡＮタグのほかに、本特許出願人による特願２００２−２０４６７３号に開示される拡張タグ、及び他のタグもしくは識別手段の何れか１つ以上の組み合わせたタグでもよい。
【０１６０】
　Ｔｙｐｅ２２０４は、フレームのタイプ識別子を格納する領域である。
【０１６１】
　ＢＰＤＵ領域２２０５は、ＩＥＥＥ８０２．１Ｄ（従来技術１）およびＩＥＥＥ８０２．１ｗ（従来技術２）に記載の、Ｃｏｎｆｉｇｕｒａｔｉｏｎ　ＢＰＤＵ　ｐａｒａｍｅｔｅｒｓに相当する情報を格納する領域である。
【０１６２】
　ＦＣＳ２２０６は、フレームチェックシーケンスを格納する領域である。
【０１６３】
　Ｐｒｏｔｏｃｏｌ　Ｉｄｅｎｔｉｆｉｅｒ２２０５１は、ＩＥＥＥ８０２．１Ｄ（従来技術１）もしくはＩＥＥＥ８０２．１ｗ（従来技術２）に記載の、Ｐｒｏｔｏｃｏｌ　Ｉｄｅｎｔｉｆｉｅｒと等しい情報を格納する領域である。
【０１６４】
　Ｐｒｏｔｏｃｏｌ　Ｖｅｒｓｉｏｎ　Ｉｄｅｎｔｉｆｉｅｒ２２０５２は、ＩＥＥＥ８０２．１Ｄ（従来技術１）もしくはＩＥＥＥ８０２．１ｗ（従来技術２）に記載の、Ｐｒｏｔｏｃｏｌ　Ｖｅｒｓｉｏｎ　Ｉｄｅｎｔｉｆｉｅｒと等しい情報を格納する領域である。
【０１６５】
　ＢＰＤＵ　Ｔｙｐｅ２２０５３は、ＩＥＥＥ８０２．１Ｄ（従来技術１）もしくはＩＥＥＥ８０２．１ｗ（従来技術２）に記載の、ＢＰＤＵ　Ｔｙｐｅと等しい情報を格納する領域である。
【０１６６】
　Ｆｌａｇｓ２２０５４は、ＩＥＥＥ８０２．１Ｄ（従来技術１）もしくはＩＥＥＥ８０２．１ｗ（従来技術２）に記載の、Ｆｌａｇｓと等しい情報を格納する領域である。
【０１６７】
　Ｒｏｏｔ　Ｉｄｅｎｔｉｆｉｅｒ２２０５５は、ＩＥＥＥ８０２．１Ｄ（従来技術１）もしくはＩＥＥＥ８０２．１ｗ（従来技術２）に記載の、Ｒｏｏｔ　Ｉｄｅｎｔｉｆｉｅｒと等しい情報を格納する領域である。
【０１６８】
　Ｒｏｏｔ　Ｐａｔｈ　Ｃｏｓｔ２２０５６は、ＩＥＥＥ８０２．１Ｄ（従来技術１）もしくはＩＥＥＥ８０２．１ｗ（従来技術２）に記載の、Ｒｏｏｔ　Ｐａｔｈ　Ｃｏｓｔと等しい情報を格納する領域である。
【０１６９】
　Ｂｒｉｄｇｅ　Ｉｄｅｎｔｉｆｉｅｒ２２０５７は、ＩＥＥＥ８０２．１Ｄ（従来技術１）もしくはＩＥＥＥ８０２．１ｗ（従来技術２）に記載の、Ｂｒｉｄｇｅ　Ｉｄｅｎｔｉｆｉｅｒと等しい情報を格納する領域である。
【０１７０】
　Ｐｏｒｔ　Ｉｄｅｎｔｉｆｉｅｒ２２０５８は、ＩＥＥＥ８０２．１Ｄ（従来技術１）もしくはＩＥＥＥ８０２．１ｗ（従来技術２）に記載の、Ｐｏｒｔ　Ｉｄｅｎｔｉｆｉｅｒと等しい情報を格納する領域である。
【０１７１】
　Ｍｅｓｓａｇｅ　Ａｇｅ２２０５９は、ＩＥＥＥ８０２．１Ｄ（従来技術１）もしくはＩＥＥＥ８０２．１ｗ（従来技術２）に記載の、Ｍｅｓｓａｇｅ　Ａｇｅと等しい情報を格納する領域である。
【０１７２】
　ＭＡＸ　Ａｇｅ２２０５Ａは、ＩＥＥＥ８０２．１Ｄ（従来技術１）もしくはＩＥＥＥ８０２．１ｗ（従来技術２）に記載の、ＭＡＸ　Ａｇｅと等しい情報を格納する領域である。
【０１７３】
　Ｈｅｌｌｏ　Ｔｉｍｅ２２０５Ｂは、ＩＥＥＥ８０２．１Ｄ（従来技術１）もしくはＩＥＥＥ８０２．１ｗ（従来技術２）に記載の、Ｈｅｌｌｏ　Ｔｉｍｅと等しい情報を格納する領域である。
【０１７４】
　Ｆｏｒｗａｒｄ　Ｄｅｌａｙ２２０５Ｃは、ＩＥＥＥ８０２．１Ｄ（従来技術１）もしくはＩＥＥＥ８０２．１ｗ（従来技術２）に記載の、Ｆｏｒｗａｒｄ　Ｄｅｌａｙと等しい情報を格納する領域である。
【０１７５】
　図６は、ＩＥＥＥ８０２．１Ｄ（従来技術１）およびＩＥＥＥ８０２．１ｗ（従来技術２）に記載の、Ｔｏｐｏｌｏｇｙ　Ｃｈａｎｇｅ　Ｎｏｔｉｆｉｃａｔｉｏｎ　ＢＰＤＵフレームの構造を示すフォーマット図である。
【０１７６】
　ＭＡＣ　ＤＡ２２０１は、宛先ＭＡＣアドレスを格納する領域である。
【０１７７】
　ＭＡＣ　ＳＡ２２０２は、送信元ＭＡＣアドレスを格納する領域である。
【０１７８】
　タグ領域２２０３は、従来技術には記載されていないが、複数のスパニングツリーを識別する識別子としてのタグを挿入する領域である。前記タグは、ＶＬＡＮタグのほかに、上記特願２００２−２０４６７３号に開示される拡張タグ、及び他のタグもしくは識別手段の何れか１つ以上の組み合わせたタグでもよい。
【０１７９】
　Ｔｙｐｅ２２０４は、フレームのタイプ識別子を格納する領域である。
【０１８０】
　ＢＰＤＵ領域２２０５は、ＩＥＥＥ８０２．１Ｄ（従来技術１）およびＩＥＥＥ８０２．１ｗ（従来技術２）に記載の、Ｔｏｐｏｌｏｇｙ　Ｃｈａｎｇｅ　Ｎｏｔｉｆｉｃａｔｉｏｎ　ＢＰＤＵ　ｐａｒａｍｅｔｅｒｓに相当する情報を格納する領域である。
【０１８１】
　ＦＣＳ２２０６は、フレームチェックシーケンスを格納する領域である。
【０１８２】
　ＧＶＲＰとは、タググループの管理および、現用系と予備系の識別、および、ノード間での各種設定情報の交換のために送受信される、制御フレームのことをいう。
【０１８３】
　図５３において、拡張タグフレーム３３００および３４００の他のフレームフォーマットについて説明する。なお、以降では図４で説明した拡張タグフレーム３５００〜３５０８のフレームフォーマットを拡張タグフレームフォーマット（１）と記し、以降で図５３において説明するフレームフォーマットを拡張タグフレームフォーマット（２）と記すこととする。
【０１８４】
　図５３の上部はＶＬＡＮタグ３２０３の詳細なフレームフォーマットである。ＴＰＩＤ（Ｔａｇ　Ｐｒｏｔｏｃｏｌ　Ｉｄｅｎｔｉｆｉｅｒ）２８００には、値「０ｘ８１００」が設定されている。なお、標準規格外ではあるが値「０ｘ９１００」が使用される場合もある。また、ＴＣＩ２８０１はＰｒｉｏｒｉｔｙフィールド２８０２とＣＦＩ２８０３とＶＬＡＮ−ＩＤフィールド２８０４から構成される。
【０１８５】
　Ｐｒｉｏｒｉｔｙフィールド２８０２にはフレームの優先度が格納され、その優先度の値はＩＥＥＥ８０２．１ｐにおいて規定されている。また、ＣＦＩには特殊ルーティング情報の有無またはＭＡＣアドレスのフォーマットの種別を示す値が格納され、ＶＬＡＮ−ＩＤフィールド２８０４にはＶＬＡＮ−ＩＤが格納される。
【０１８６】
　これに対して、図５０の下部に示す拡張タグフレームフォーマット（２）では、ＴＰＩＤ２８００及びＴＣＩ２８０１の中のＣＦＩ２８０３はＶＬＡＮタグ３２０３と同様であり、Ｐｒｉｏｒｉｔｙフィールド２８０２がＰｒｉｏｒｉｔｙ／タグＴｙｐｅフィールド５００３に、ＶＬＡＮ−ＩＤフィールド２８０４が拡張タグ情報フィールド５００４に変更される。なお、対応するフィールドのサイズは同様である。
【０１８７】
　本拡張タグフレームフォーマット（２）では、Ｐｒｉｏｒｉｔｙ／タグＴｙｐｅフィールド５００３において、拡張タグ３５００〜３５０８の種別を格納する。拡張タグ３５００〜２３０７使用時にもＩＥＥＥ８０２．１ｐをサポートできるように、既存のＶＬＡＮタグ３２０３のＰｒｉｏｒｉｔｙフィールド２８０２（ＩＥＥＥ８０２．１ｐ）におけるＰｒｉｏｒｉｔｙ値の一部を拡張タグ３５００〜３５０８の種別として用いる。
【０１８８】
　具体的には１１０、１００、００１、０００を拡張タグ３５００〜３５０８用として用いることとし、１１１（予約用）、１０１（会話型マルチメディア用）、０１１（クリティカルアプリケーション用）、０１０（標準的ストリーム用）についてはＩＥＥＥ８０２．１ｐ互換とする。
【０１８９】
　そのため、使用できる拡張タグ３５００〜３５０８は４つに制限しており、例えばフォワーディングタグ３５００、ブロードキャストフォワーディングタグ３５０８、カスタマ分離タグ３５０１、ＯＡＭ＆Ｐタグ３５０３を使用し、Ｐｒｉｏｒｉｔｙ値との対応を００１＝フォワーディングタグ３５００、０００＝ブロードキャストフォワーディングタグ３５０８、１１０＝カスタマ分離タグ３５０１、１００＝ＯＡＭ＆Ｐタグ３５０３とする。これにより、上記４種類の拡張タグを識別できると共に、ＩＥＥＥ８０２．１ｐの中の４つの優先度をサポートできる。なお、使用する拡張タグの選択とそれに対応するＰｒｉｏｒｉｔｙ値の設定についてはこの例に限定されるわけではない。
【０１９０】
　また拡張タグフレームフォーマット（２）では、拡張タグ情報フィールド５００４において、拡張タグ３５００〜３５０８のタグ種別に応じたアドレス情報などの情報が格納される。例えば、フォワーディングタグ３５００の場合、宛先ノードのアドレス情報が格納され、ブロードキャストフォワーディングタグ３５０８の場合、送信元ノードのアドレス情報が格納され、カスタマ分離タグ３５０１の場合、カスタマの識別情報が格納される。
【０１９１】
（第１の実施の形態）
　以下、本発明の第１の実施の形態について、図面を参照して詳細に説明する。
【０１９２】
　図７を参照すると、本発明の第１の実施の形態は、ノード１１〜１６、クライアント９１〜９６、リンク８１〜８６、リンク２１〜２８を含む。
【０１９３】
　ノード１１は、プログラム制御されるＣＰＵ等で実現され、以下に挙げる機能を有する。
【０１９４】
　（１）リンク２１もしくはリンク２４より到着したフレームを、リンク２４もしくはリンク２１に転送する。
【０１９５】
　（２）リンク８１より到着したフレームに、転送に必要なタグを付加した上で、リンク２１もしくはリンク２４に転送する。
【０１９６】
　（３）リンク２１もしくはリンク２４より到着したフレームを、転送に必要なタグを削除した上で、リンク８１に転送する。
【０１９７】
　（４）スパニングツリーを構成するために、他のノードとの間で制御フレームのを行い、必要に応じてリンクのポートを閉鎖する。
【０１９８】
　（５）リンクを流れるフレームの流量をモニタする。
【０１９９】
　ノード１２〜１６は、ノード１１と同様のノードである。以後、ノード１１〜１６を代表して、ノード１１を用いて記述を行うが、これらノード１１についての記述は、特に断りのない限り他のノード１２〜１６においても同様に実現可能である。
【０２００】
　クライアント９１は、１つ以上のクライアントの集合であり、リンク８１を通じて、ノード１１との間でフレームの送受信を行う機能を有する。
【０２０１】
　クライアント９２〜９６は、クライアント９１と同様のクライアント群である。以後、クライアント９１〜９６を代表してクライアント９１を用いて記述を行うが、クライアント９１についての記述は、特に断りのない限り他のクライアント９２〜９６においても同様に適用可能である。
【０２０２】
　リンク８１は、クライアント９１からノード１１、及び、ノード１１からクライアント９１を結ぶ双方向リンクである。
【０２０３】
　リンク８２〜８６は、リンク８１と同様のリンクである。以後、リンク８１〜８６を代表してリンク８１を用いて記述を行うが、リンク８１についての記述は、特に断りのない限り他のリンク８２〜８６においても同様に適用可能である。
【０２０４】
　リンク２１は、ノード１１からノード１２、及び、ノード１２からノード１１を結ぶ、双方向リンクである。
【０２０５】
　リンク２２〜２６は、リンク２１と同様のリンクである。以後、リンク２２〜２６を代表してリンク２１を用いて記述を行うが、リンク２１についての記述は、特に断りのない限り他のリンク２２〜２６においても同様に適用可能である。
【０２０６】
　図８は、ノード１１の構成を詳細に示した図である。ノード１１は、フレーム転送器１１１と、タグ挿入器１１２と、タグ削除器１１３と、フォワーディングテーブル１１４と、分別器１１５０と、ツリーマネージャ１１５１と、ツリーマネージャ１１５２と、ツリーセレクタ１１６と、タグテーブル１１７と、設定インタフェース１１８を含む。
【０２０７】
　フレーム転送器１１１は、リンク２１もしくはリンク２４、およびタグ挿入器１１２より受信したフレームを、フォワーディングテーブル１１４の記述に従い、リンク２１もしくはリンク２４、および、タグ削除器１１３もしくはもしくはツリーセレクタ１１６に転送する。
【０２０８】
　タグ挿入器１１２は、リンク８１より受信したフレームに対し、タグテーブル１１７の記述に従いタグを挿入し、フレーム転送器１１１に転送する。なお、タグテーブル１１７の記述によっては、タグを挿入せずに、受信したフレームをそのままフレーム転送器１１１に転送することもできるほか、同一フレームに０個以上の複数のタグを挿入し、もしくは、到着したフレームをコピーし、コピーしたそれぞれのフレームに対して、同一もしくは異なるタグを、０個以上の複数個挿入することも可能である。
【０２０９】
　タグ削除器１１３は、フレーム転送器１１１より受信したフレームに付加されているタグを外し、リンク８１に転送する。なお、設定によって、タグを外さずに、受信したフレームをそのままリンク８１に転送することもできる。
【０２１０】
　フォワーディングテーブル１１４は、フレーム転送器１１１からの問い合わせに対し、ＭＡＣアドレス、タグ、もしくは入力ポートの他、１つ以上の組み合わせをキーとして、1つ以上のフレーム転送先ポートをフレーム転送器１１１に返答する。キーおよび転送先ポートは、ツリーマネージャ１１５１もしくはツリーマネージャ１１５２により設定される。
【０２１１】
　分別器１１５０は、受信したフレームのタグに従い出力先ポートを決定し、前記フレームをツリーマネージャ１１５１、または、ツリーマネージャ１１５２に転送する。どのタグが付加されたフレームをツリーマネージャ１１５１もしくはツリーマネージャ１１５２に転送するかは、ツリーセレクタ１１６より設定することができる。
【０２１２】
　ツリーマネージャ１１５１は、ツリーセレクタ１１６の指示に従い、スパニングツリーアルゴリズムを利用して、分別器１１５０よりＢＰＤＵを受信し、またフレーム転送器１１１に対してＢＰＤＵを送信し、フォワーディングテーブル１１４を設定する。さらに、ツリーセレクタ１１６から設定情報を受信し、ＢＰＤＵのパラメータとして利用する。また、ＢＰＤＵに含まれる制御情報を抽出し、ツリーセレクタ１１６に通知する。
【０２１３】
　ツリーマネージャ１１５２は、ツリーマネージャ１１５１と同様のツリーマネージャである。以後、ツリーマネージャ１１５１〜ツリーマネージャ１１５２を代表してツリーマネージャ１１５１を用いて記述を行うが、ツリーマネージャ１１５１についての記述は、特に断りのない限りツリーマネージャ１１５２においても同様に適用可能である。
【０２１４】
　ツリーセレクタ１１６は、フレーム転送器１１１よりＧＶＲＰ等の設定フレームを受信し、ツリーマネージャ１１５１もしくは１１５２よりＢＰＤＵに含まれる制御情報を受信し、リソースモニタ１１９よりリンク情報の通知を受け、または、設定インタフェース１１８からの設定通知を受け、設定フレームもしくは通知に含まれる情報に沿って、ツリーマネージャ１１５１、ツリーマネージャ１１５２、タグテーブル１１７の設定を行う。また、設定フレームをフレーム転送器１１１に送信する。
【０２１５】
　タグテーブル１１７は、タグ挿入器１１２からの問い合わせに対し、挿入すべきタグの情報、もしくは、タグを追加しないで転送する命令をタグ挿入器１１２に返答する。挿入するタグもしくは、タグ挿入なしで転送命令は、ツリーセレクタ１１６より設定される。同一フレームに０個以上の複数のタグを挿入する設定や、到着したフレームをコピーし、コピーしたそれぞれのフレームに対して、同一もしくは異なるタグを、０個以上の複数個挿入する設定も可能である。
【０２１６】
　設定インタフェース１１８は、シリアル接続もしくはＴＥＬＮＥＴ等のコマンドラインインタフェース、もしくはＷＥＢサーバ等を通じて、ユーザからのツリー選択命令や、ノード削除要求、リンクコスト、スパニングツリーパラメータ値等を、ツリーセレクタ１１６に伝達する。
【０２１７】
　リソースモニタ１１９は、ノードの各リンクポートの状況を監視し、リンクの接続を検出した場合には、ツリーセレクタ１１６にリンクアップ通知を送信する。また、リンクを通過するフレームの累積バイト数、通過TCPセッション数、HTTPリクエスト数のうち１つ以上の値をカウントして保持し、ツリーセレクタ１１６の要求により、保持している値をツリーセレクタ１１６に通知するほか、ツリーセレクタ１１６からの命令により、保持している値を０にリセットする。さらに、ツリーセレクタ１１６よりあらかじめ指定された種類のフレーム通過を監視し、前記監視対象フレームが通過すると、ツリーセレクタ１１６に通知する。
【０２１８】
　図９は、本実施の形態の図８における、タグをキーとして出力ポートを決定する、フォワーディングテーブル１１４の構成例である。
【０２１９】
　タグフィールド１１４１は、サーチのインデックスになるフィールドであり、このフィールドの情報と、受信したフレームのタグに書かれている内容が一致するかどうかを調べる。
【０２２０】
　出力ポート１１４２は、受信したフレームのタグに書かれている内容とタグにフィールド１１４１の内容が一致した場合に、前記フレームをどのポートに転送すべきか記述するフィールドである。
【０２２１】
　なお、本実施の形態は、本動作例に示すような、タグの内容によって転送先ポートを決定するタグフォワーディングを行う場合のみならず、従来より行われている、ＭＡＣアドレスによって転送先を決定する通常のＭＡＣアドレス転送においても、同様に適用可能である。この場合は、出力ポートフィールド１１４２に、複数のポートが記載される。
【０２２２】
　図１０は、本発明の第１の実施の形態の図８における、ツリーマネージャ１１５１の構成を詳細に示した図である。ツリーマネージャ１１５１は、タグ削除器１１５１１と、ＢＰＤＵ送受信器１１５１２と、タグ挿入器１１５１３と、ツリーコントローラ１１５１４と、ツリーテーブル１１５１５含む。
【０２２３】
　タグ削除器１１５１１は、分別器１１５０より入力されたフレームに挿入されているタグを削除し、ＢＰＤＵ送受信機１１５１２に転送する。もし分別器１１５０より受信したフレームにタグが添付されていない場合には、受信したフレームをそのままＢＰＤＵ送受信機１１５１２に転送する。
【０２２４】
　ＢＰＤＵ送受信器１１５１２は、タグ削除器１１５１１よりＢＰＤＵを受信し、フレームに含まれる情報を、ＢＰＤＵ受信通知によりツリーコントローラ１１５１４に通知する。また、ツリーコントローラ１１５１４よりＢＰＤＵ送信通知を受け、フレームを生成してタグ挿入器１１５１３に送信する。
【０２２５】
　タグ挿入器１１５１３は、ＢＰＤＵ送受信機１１５１２よりフレームを受信し、あらかじめ設定されているタグを挿入し、フレーム転送器１１１に送信する。なお、タグを挿入せずに、フレームをそのまま転送する設定も可能である。
【０２２６】
　ツリーコントローラ１１５１４は、以下に示す４つの機能を有する。
【０２２７】
　（１）停止動作（初期状態）：ツリーセレクタ１１６からの停止命令にしたがい、ＢＰＤＵ送受信機１１５１２へのＢＰＤＵ送信通知を停止する。また、ツリーテーブル１１５１５に対して、すべてのリンクがdownしているとして、ポートの状態を登録する。
【０２２８】
　（２）開始動作：ツリーセレクタ１１６からの開始命令にしたがい、ＢＰＤＵ送受信機１１５１２へのＢＰＤＵ送信通知を開始する。また、開始命令に含まれる情報を元に、ツリーテーブル１１５１５に対して、アップ状態のポートを登録する。
【０２２９】
　（３）ＢＰＤＵ受信動作：ＢＰＤＵ送受信機１１５１２からのＢＰＤＵ受信通知を受け取り、ツリーテーブル１１５１５を更新する。また、ＢＰＤＵ受信通知に含まれる現用系ツリーおよび予備系ツリーの識別情報を抽出し、ツリーセレクタ１１６内のメインコントローラ１１６４に通知する。
【０２３０】
　（４）トポロジ更新動作：前記停止動作、前記開始動作、および前記ＢＰＤＵ受信動作後に、従来技術１もしくは従来技術２に示すスパニングツリープロトコルに従い、ツリーテーブル１１５１５を参照し、必要であれば、ツリーテーブル１１５１５の設定、フォワーディングテーブル１１４の設定および、ＢＰＤＵの送信を行う。送信するＢＰＤＵには、現用系ツリーおよび予備系ツリーの識別情報も含まれる。また、ツリーセレクタ１１６に対し、ツリーの再計算の結果、トポロジに変更が生じるか生じないかを通知する動作を行う。
【０２３１】
　ツリーテーブル１１５１５は、従来技術１もしくは従来技術２に示すスパニングツリープロトコルに必要な、ポートの状態およびノードの状態に関するパラメータが記述されているテーブルである。各ポートもしくはリンクの優先度並びにリンクコストも、このテーブルに記述されている。第１の実施の形態では、リンクコストとして、リンク帯域の太さを用いる場合を想定して説明する。
【０２３２】
　図１１は、本発明の第１の実施の形態の図８における、ツリーセレクタ１１６の構成を詳細に示した図である。ツリーセレクタ１１６は、タグ削除器１１６１と、ＧＶＲＰ送受信器１１６２と、タグ挿入器１１６３と、メインコントローラ１１６４と、安定タイマ１１６５と、到着間隔タイマ１１６６とを含む。
【０２３３】
　タグ削除器１１６１は、フレーム転送器１１１より入力されたフレームに挿入されているタグを削除し、ＧＶＲＰ送受信機１１６２に転送する。もしフレーム転送器１１１より受信したフレームにタグが添付されていない場合には、受信したフレームをそのままＧＶＲＰ送受信機１１６２に転送する。
【０２３４】
　ＧＶＲＰ送受信器１１６２は、タグ削除器１１６１より制御フレームを受信し、フレームに含まれる情報を、ＧＶＲＰフレーム受信通知によりメインコントローラ１１６４に通知する。また、メインコントローラ１１６４よりＧＶＲＰフレーム送信通知を受け、フレームを生成してタグ挿入器１１６３に送信する。
【０２３５】
　タグ挿入器１１６３は、ＧＶＲＰ送受信機１１６２よりフレームを受信し、あらかじめ設定されているタグを挿入し、フレーム転送器１１１に送信する。なお、タグを挿入せずに、フレームをそのまま転送する設定も可能である。
【０２３６】
　メインコントローラ１１６４は、以下に示す４つの機能を有する。
【０２３７】
　（１）リンクアップ検出：メインコントローラ１１６４は、リソースモニタ１１９よりリンクアップ通知を受け、現在予備系となっているツリーマネージャに対して、リンクアップ（開始命令）を通知する。開始命令には、アップしているリンクの情報が格納される。また、開始命令送信後に、安定タイマ１１６５をセットする。安定タイマ１１６５の満了通知を受信すると、タグテーブル１１７に対して挿入タグの変更命令を通知し、さらに、予備系と現用系の登録を逆転させるよう、ＧＶＲＰ送受信機１１６２に対して、新ツリーのルートノードに対してツリー切り替え要求フレームを送信するよう命令する。さらに、安定タイマ１１６５をセットし、タイマ満了後に自ノードを旧ツリーに追加する。
【０２３８】
　（２）ノード削除要求受信：設定インタフェース１１８よりノード削除要求通知を受信すると、現在予備系となっているツリーマネージャに対して停止命令を送信する。また停止命令の送信後に、安定タイマ１１６５をセットし、安定タイマ１１６５の満了通知を受信すると、タグテーブル１１７に対して挿入タグの変更命令を通知し、さらに、予備系と現用系の登録を逆転させるよう、ＧＶＲＰ送受信機１１６２に対して、新ツリーのルートノードに対して利用タググループ変更ＧＶＲＰフレームを送信するよう命令する。さらに、安定タイマ１１６５をセットし、タイマ満了後に設定インタフェース１１８に対して、自ノード削除許可の表示を行う。
【０２３９】
　（３）利用タググループ変更ＧＶＲＰ受信：自ノードが新ツリーのルートノードである場合、利用タググループ変更ＧＶＲＰフレームを受信すると、自ノードから送信するＢＰＤＵに、現用系フラグを付加して送信するよう、ツリーマネージャ１１５１もしくはツリーマネージャ１１５２に対して命令する。さらに、ＧＶＲＰ送受信機１１６２に対して、旧ツリーのルートノードに対して、現用系フラグの添付を取り消すよう命令する。
【０２４０】
　（４）現用系ビット変更通知受信：ツリーマネージャ１１５１もしくはツリーマネージャ１１５２は、ＢＰＤＵの受信時にＢＰＤＵに付加された現用系フラグを確認し、自グループが現用系であるか予備系であるか確認し、メインコントローラに通知する。通知を受けた結果、もし、現用系と予備系に変更がある場合には、タグテーブル１１７に対して挿入タグ変更通知を送信して、現用系と予備系の登録を逆転させる。
【０２４１】
　（５）指定フレームの通過通知受信：リソースモニタ１１９より、あらかじめ設定した監視対象フレームが通過したことの通知を受信すると、到着間隔タイマ１１６６に対してセット通知を送信する。到着間隔タイマ１１６６から、タイマ満了通知が到着した場合は、監視対象フレームの到着間隔がセット通知によって設定した時間より長いことがわかる。これによりＢＰＤＵの到着間隔が長くなったことや、予備系を流れるフレームの到着間隔が長くなったことなどを検出できる。
【０２４２】
　安定タイマ１１６５は、メインコントローラ１１６４より送信されたセット通知の受信から、あらかじめ設定された時間が経過すると、メインコントローラ１１６４に対してタイマ満了通知を送信する。
【０２４３】
　到着間隔タイマ１１６６は、メインコントローラ１１６４からセット命令を受信すると、現在保持している時間を０にリセットしてタイマを作動させ、セット命令によって指定された時間が経過すると、メインコントローラ１１６４に対してタイマ満了通知を送信する。
【０２４４】
　図１２は、本発明の第１の実施の形態の図１１における、メインコントローラ１１６４の状態遷移を詳細に示した流れ図である。
【０２４５】
　以降、２系統存在するスパニングツリーのうち、新しくネットワークに侵入するデータフレームの転送に利用しているスパニングツリーを現用ツリーもしくは現用系ツリー、現用ツリーとなっていないツリーを予備用ツリーもしくは予備系ツリーと表現する。
【０２４６】
　また、現用系ツリーの生成を行うツリーマネージャを現用系ツリーマネージャ、予備系ツリーの生成を行うツリーマネージャを、予備系ツリーマネージャと呼ぶ。
【０２４７】
　状態１１６４１は、現用系ツリーマネージャが、ツリーマネージャ１１５１であるか、ツリーマネージャ１１５２であるか判別できていない状態であり、かつ、ツリーマネージャ１１５１内のＢＰＤＵ送受信機１１５１２および、ツリーマネージャ１１５２内のＢＰＤＵ送受信機１１５２２のＢＰＤＵ送信機能は無効にされ、ＢＰＤＵ受信機能のみが有効になっている状態である。
【０２４８】
　状態１１６４２は、現用系ツリーマネージャが、ツリーマネージャ１１５１であり、予備系ツリーマネージャがツリーマネージャ１１５２であり、ツリーマネージャ１１５１内のＢＰＤＵ送受信機１１５１２のＢＰＤＵ送信機能が無効にされ、ツリーマネージャ１１５２内のＢＰＤＵ送受信機１１５２２のＢＰＤＵ送信機能も無効にされている状態である。なお、ＢＰＤＵ送受信機１１５１２およびＢＰＤＵ送受信機１１５２２のＢＰＤＵ受信機能は、送信機能の有効もしくは無効に関わらず、常に有効である。
【０２４９】
　状態１１６４３は、現用系ツリーマネージャが、ツリーマネージャ１１５１であり、予備系ツリーマネージャがツリーマネージャ１１５２であり、ツリーマネージャ１１５１内のＢＰＤＵ送受信機１１５１２のＢＰＤＵ送信機能が無効にされ、ツリーマネージャ１１５２内のＢＰＤＵ送受信機１１５２２のＢＰＤＵ送信機能は有効にされている状態である。なお、ＢＰＤＵ送受信機１１５１２およびＢＰＤＵ送受信機１１５２２のＢＰＤＵ受信機能は、送信機能の有効もしくは無効に関わらず、常に有効である。
【０２５０】
　状態１１６４４は、現用系ツリーマネージャが、ツリーマネージャ１１５２であり、予備系ツリーマネージャがツリーマネージャ１１５１であり、ツリーマネージャ１１５２内のＢＰＤＵ送受信機１１５２２のＢＰＤＵ送信機能が有効にされ、ツリーマネージャ１１５１内のＢＰＤＵ送受信機１１５１２のＢＰＤＵ送信機能は無効にされている状態である。なお、ＢＰＤＵ送受信機１１５１２およびＢＰＤＵ送受信機１１５２２のＢＰＤＵ受信機能は、送信機能の有効もしくは無効に関わらず、常に有効である。
【０２５１】
　状態１１６４５は、現用系ツリーマネージャが、ツリーマネージャ１１５２であり、予備系ツリーマネージャがツリーマネージャ１１５１であり、ツリーマネージャ１１５２内のＢＰＤＵ送受信機１１５２２のＢＰＤＵ送信機能が有効にされ、ツリーマネージャ１１５１内のＢＰＤＵ送受信機１１５１２のＢＰＤＵ送信機能も有効にされている状態である。なお、ＢＰＤＵ送受信機１１５１２およびＢＰＤＵ送受信機１１５２２のＢＰＤＵ受信機能は、送信機能の有効もしくは無効に関わらず、常に有効である。
【０２５２】
　状態１１６４６は、現用系ツリーマネージャが、ツリーマネージャ１１５１であり、予備系ツリーマネージャがツリーマネージャ１１５２であり、ツリーマネージャ１１５１内のＢＰＤＵ送受信機１１５１２のＢＰＤＵ送信機能が有効にされ、ツリーマネージャ１１５２内のＢＰＤＵ送受信機１１５２２のＢＰＤＵ送信機能も有効にされている状態である。なお、ＢＰＤＵ送受信機１１５１２およびＢＰＤＵ送受信機１１５２２のＢＰＤＵ受信機能は、送信機能の有効もしくは無効に関わらず、常に有効である。
【０２５３】
　状態１１６４７は、現用系ツリーマネージャが、ツリーマネージャ１１５１であり、予備系ツリーマネージャがツリーマネージャ１１５２であり、ツリーマネージャ１１５１内のＢＰＤＵ送受信機１１５１２のＢＰＤＵ送信機能が有効にされ、ツリーマネージャ１１５２内のＢＰＤＵ送受信機１１５２２のＢＰＤＵ送信機能が無効にされている状態である。なお、ＢＰＤＵ送受信機１１５１２およびＢＰＤＵ送受信機１１５２２のＢＰＤＵ受信機能は、送信機能の有効もしくは無効に関わらず、常に有効である。
【０２５４】
　状態１１６４８は、現用系ツリーマネージャが、ツリーマネージャ１１５２であり、予備系ツリーマネージャがツリーマネージャ１１５１であり、ツリーマネージャ１１５２内のＢＰＤＵ送受信機１１５２２のＢＰＤＵ送信機能が無効にされ、ツリーマネージャ１１５１内のＢＰＤＵ送受信機１１５１２のＢＰＤＵ送信機能が有効にされている状態である。なお、ＢＰＤＵ送受信機１１５１２およびＢＰＤＵ送受信機１１５２２のＢＰＤＵ受信機能は、送信機能の有効もしくは無効に関わらず、常に有効である。
【０２５５】
　状態１１６４９は、現用系ツリーマネージャが、ツリーマネージャ１１５２であり、予備系ツリーマネージャがツリーマネージャ１１５１であり、ツリーマネージャ１１５２内のＢＰＤＵ送受信機１１５２２のＢＰＤＵ送信機能が無効にされ、ツリーマネージャ１１５１内のＢＰＤＵ送受信機１１５１２のＢＰＤＵ送信機能が無効にされている状態である。なお、ＢＰＤＵ送受信機１１５１２およびＢＰＤＵ送受信機１１５２２のＢＰＤＵ受信機能は、送信機能の有効もしくは無効に関わらず、常に有効である。
【０２５６】
　次に、図１２を参照して、メインコントローラ１１６４の動作について説明する。
【０２５７】
　メインコントローラ１１６４は、リソースモニタ１１９より新たにネットワークに接続されたことの通知を受信すると、ツリーマネージャ１１５１もしくはツリーマネージャ１１５２からの現用系通知の到着を待つ。ツリーマネージャ１１５１もしくはツリーマネージャ１１５２よりＢＰＤＵに含まれる現用系通知を受信すると、前記通知において指定されたツリーマネージャ１１５１もしくはツリーマネージャ１１５２を現用、予備用に指定されたツリーマネージャ１１５１もしくは１１５２を予備用に設定し、状態１１６４２もしくは状態１１６４９に遷移する。ここでは、状態１１６４２に遷移した場合を例に解説するが、以後の解説は状態１１６４９に遷移した場合においても同様である。（状態１１６４１）
【０２５８】
　メインコントローラ１１６４は、ツリーマネージャ１１５１を現用、ツリーマネージャ１１５２を予備用に設定する。さらに、前記各ツリーマネージャ１１５１および１１５２に対して、ＢＰＤＵ送信停止命令を出す。（状態１１６４２）
【０２５９】
　メインコントローラ１１６４は、状態１１６４２において、もし設定インタフェース１１８よりノードの追加要求を受信した場合は、状態１１６４３に遷移する。また、もしツリーマネージャ１１５１もしくはツリーマネージャ１１５２より現用系通知を受信し、現用系と予備系の関係に変更があった場合には、状態１１６４９に遷移する。（状態１１６４２）
【０２６０】
　メインコントローラ１１６４は、ツリーマネージャ１１５２に対してリンクｕｐの通知を行い、同時に、ツリーマネージャ１１５２に対してＢＰＤＵの送信許可を行う。さらに、安定タイマ１１６５を作動させる。（状態１１６４３）
【０２６１】
　メインコントローラ１１６４は、安定タイマ１１６５よりタイマ満了通知を受信すると、現用に登録されているツリーマネージャ１１５１と、予備用に登録されているツリーマネージャ１１５２を入れ替え、新しく現用をツリーマネージャ１１５２、予備用をツリーマネージャ１１５１とする。さらに、ＧＶＲＰ送受信機１１６２を通じて、新ツリーのルートノードに対して、利用タググループ変更通知を送信する。この利用タググループ変更通知の内容は、ＢＰＤＵに反映され、全ノードに伝達される。その後、安定タイマ１１６５を作動させる。（状態１１６４４）
【０２６２】
　メインコントローラ１１６４は、安定タイマ１１６５よりタイマ満了通知を受信すると、ツリーマネージャ１１５１に対してリンクｕｐの通知を行い、同時に、ツリーマネージャ１１５２に対してＢＰＤＵの送信許可を行う。通常は、この状態で安定する。（状態１１６４５）
【０２６３】
　メインコントローラ１１６４は、状態１１６４５において、ツリーマネージャ１１５１もしくはツリーマネージャ１１５２よりＢＰＤＵに含まれる現用系通知を受信し、もし現用系と予備系の関係に変更が生じた場合には、状態１１６４６に遷移する。そして、現用に登録されているツリーマネージャ１１５２と、予備用に登録されているツリーマネージャ１１５１を入れ替え、新しく現用をツリーマネージャ１１５１、予備用をツリーマネージャ１１５２とする。（状態１１６４５）
【０２６４】
　メインコントローラ１１６４は、状態１１６４５において、もし設定インタフェース１１８より、ノード削除要求を受信した場合は、状態１１６４４に遷移する。（状態１１６４５）
【０２６５】
　メインコントローラ１１６４は、ツリーマネージャ１１５１に対して、接続されている全リンクリンクｄｏｗｎの通知を行い、同時に、ツリーマネージャ１１５１に対してＢＰＤＵの送信停止命令を出す。さらに、安定タイマ１１６５を作動させる。（状態１１６４４）
【０２６６】
　メインコントローラ１１６４は、安定タイマ１１６５よりタイマ満了通知を受信すると、現用に登録されているツリーマネージャ１１５２と、予備用に登録されているツリーマネージャ１１５１を入れ替え、新しく現用をツリーマネージャ１１５１、予備用をツリーマネージャ１１５２とする。さらに、ＧＶＲＰ送受信機１１６２を通じて、新ツリーのルートノードに対して、利用タググループ変更通知を送信する。この、利用タググループ変更通知の内容は、ＢＰＤＵに反映され、全ノードに伝達される。その後、安定タイマ１１６５を作動させる。（状態１１６４３）
【０２６７】
　メインコントローラ１１６４は、安定タイマ１１６５よりタイマ満了通知を受信すると、ツリーマネージャ１１５１に対してリンクｄｏｗｎの通知を行い、同時に、ツリーマネージャ１１５１に対してＢＰＤＵの受信停止命令を出す。さらに、無条件で状態１１６４１に遷移し、ノード切離しまで待機する。（状態１１６４２）
　図１３は、本実施の形態の図８における、宛先ＭＡＣアドレスをキーとして挿入するタグを決定する、タグテーブル１１７の構成例である。
【０２６８】
　宛先ＭＡＣアドレス１１７１は、サーチのインデックスになるフィールドであり、このフィールドの情報と、受信したフレームの宛先ＭＡＣアドレスフィールド、すなわち、ＭＡＣ　ＤＡフィールドに書かれている内容が一致するかどうか調べ、一致した場合には、前記受信フレームに対して、挿入タグフィールド１１７２に記載のタグを挿入する。
【０２６９】
　挿入タグフィールド１１７２は、宛先ＭＡＣアドレスフィールド１１７１に対する、挿入すべきタグが記載されるフィールドである。本実施の形態では、現在において現用系となっているタググループのタグが挿入される。この挿入タグフィールド１１７２は、ツリーセレクタ１１６によって、現在現用系となっているタグに書き換えられる。
【０２７０】
　図８、図１４、図１５及び図１６を参照して、本実施の形態において、ノード１７を追加する場合の動作について、具体例を用いて詳細に説明する。
【０２７１】
　初期状態（ノード１７がリンク２９、３０に接続される前の状態）における、２系統のスパニングツリーは、同じ接続関係となる。これは、スパニングツリーを設定するプロトコルは、ノード、リンクのプライオリティ値等の情報に基づいてスパニングツリーを設定するため、同一のネットワークについてスパニングツリーを２つ設定すると結果として同じ接続関係となるものである。この初期状態で、何れか一方のスパニングツリーを現用、他方を予備として設定し（具体的には、ツリーマネージャ１１５１、１１５２がツリーテーブル１１５１５を書き換え、ツリーセレクタ１１６がタグテーブル１１７を書き換えることで各設定を行う）、このネットワークは現用のスパニングツリーを用いて運用される。
【０２７２】
　図１０に示すネットワークにおいて、初期状態で、太線で示すスパニングツリー５１が２つ設定されている場合を想定する。
【０２７３】
　図１４を参照すると、本動作例では、ノード１１〜１７、リンク２１〜３０、およびツリー５１を有する。ただし、ノード１７、リンク２９およびリンク３０は、初期状態では接続されていない。
【０２７４】
　また、図１５は、本動作例において、ノード１７が追加された後のスパニングツリー５２の状態を示す。ツリー５２は図１１において太線で示されている。
【０２７５】
　ノード１１〜１６の全ノード、全ポートが所属するタググループが２つすでに設定されており、１つめのタググループをタググループ４１、２つめのタググループをタググループ４２と呼ぶ。
【０２７６】
　なお、基本的には全ノード、全ポートを２つのタググループに加入させるが、一部のポートもしくはノードのみで構成させるタググループを作成しても良い。以降、全ノード、全ポートが２つのタググループに加入するものとして説明する。
【０２７７】
　ノード１１〜１６には、独立して動作するスパニングツリー回路が２つ存在し、タググループ４１上で動作するスパニングツリーをツリー５１、タググループ４２上で動作するスパニングツリーをツリー５２と呼ぶ。
【０２７８】
　スパニングツリーは必ず２系統作成するが、タググループは必ずしも２つ作成する必要は無い。前記タググループ４１のみ設定してタググループ４２を利用せず、タググループ４１上で動作するスパニングツリーをツリー５１、タググループに属さないで動作するスパニングツリーをツリー５２と呼ぶこともできる。また逆に、前記タググループ４２のみ設定してタググループ４１を利用せず、タググループに属さないで動作するスパニングツリーをツリー５１、タググループ４２上で動作するスパニングツリーをツリー５２と呼ぶこともできる。
【０２７９】
　ここでは、特にタググループ４１とタググループ４２の両方を用いた場合について説明を行うが、タググループ４１及びタググループ４２の両方を用いた場合の動作は、タググループ４１のみ、もしくはタググループ４２のみを用いた場合においても、同様に適用可能である。
【０２８０】
　このネットワークでは、設定インタフェース１１８からの初期設定によって、ツリー５１が現用系のスパニングツリーとなり、ツリー５２が予備系のスパニングツリーとなるように設定されており、ツリー５１のＢＰＤＵには現用系フラグおよびタググループ４１のタグが付き、ツリー５２のＢＰＤＵには予備系フラグおよびタググループ４２のタグが付く。
【０２８１】
　全ノードが、現用系フラグ又は予備系フラグが付されたＢＰＤＵフレームをIEEE Std 802.1DやIEEE Std 802.1ｗで規定される一定の周期で互いに送信し合うことにより、ツリー５１である現用系のスパニングツリー又はツリー５２である予備系のスパニングツリーが構築される。
【０２８２】
　上記現用系フラグ又は予備系フラグは、図５に示したＢＰＤＵフレームのフィールドのうち、例えばタグ領域２２０３、Ｔｙｐｅ２２０４、ＢＰＤＵ　Ｔｙｐｅ２２０５３等のフィールドを使用することによって表すことができる。
【０２８３】
　現在、ネットワークの開始から十分に時間が経過し、ツリー５１およびツリー５２の各ツリーは、タググループ４１およびタググループ４２のタグが付加されたＢＰＤＵフレームの交換が十分に行われた結果、共にノード１１をルートノードとして安定しているとする。
【０２８４】
　安定とは、スパニングツリーのツリー構造が、十分に長い時間変化しない状態になっている状態のことを言う。
【０２８５】
　ツリー５１のＢＰＤＵにはタググループ４１のタグが、ツリー５２のＢＰＤＵにはタググループ４２のタグが付く。具体的には、ツリー５１を用いて伝送されるＢＰＤＵのタグ領域２２０３には、このＢＰＤＵがタググループ４１に属することを示す値が記載され、ツリー５２を用いて伝送されるＢＰＤＵのタグ領域２２０３には、このＢＰＤＵがタググループ４２に属することを示す値が記載される。
【０２８６】
　また、現時点では、ツリー５１が現用系として設定されているので、クライアントからノード１１〜１６に送信されたデータには、タグ挿入器１１２によって、タググループ４１のタグが付加されている。具体的には、データ信号のタグ領域に、タググループ４１に属することを示す値が記載される。そして、このタグが付加されたデータは、フレーム転送器１１１によって、現時点で、現用系として設定されているツリー５１に沿って転送されている。
【０２８７】
　ノード１７は、リンク２９およびリンク３０と接続されると、どのタググループにも加入せず、ＢＰＤＵの受信を開始する。（このときのノード１７のメインコントローラ１１６４の状態は、図１２の状態１１６４１となる。）
【０２８８】
　ノード１７は、各タググループのＢＰＤＵを受信すると、現時点での現用系がタググループ４１で、現時点での予備系がタググループ４２であると確認する。（このときのノード１７のメインコントローラ１１６４の状態は、図１２の状態１１６４２である。）そして、自ノードをタググループ４２にのみ参加させてＢＰＤＵの送受信を行い、タググループ４１ではＢＰＤＵは受信のみ行い、送信を行わないように設定する。（このときのノード１７のメインコントローラ１１６４の状態は、図１２の状態１１６４３である。）
【０２８９】
　ノード１７が追加されると、タググループ４２のメンバに変更が発生するため、スパニングツリープロトコルにより、ツリー５２を更新する動作が開始される。すなわち、ノード１７がＢＰＤＵを送信して、それを隣接ノードが受信すると、隣接ノードはトポロジ状況に変更があったと認識し、ツリー５２の更新動作を開始する。タググループ４１のメンバには変更が無いため、ツリー５１は更新されない。
【０２９０】
　クライアントから送信されるフレームには、各ノード１１〜１６によって、今までどおりタググループ４１のタグが付加され、ツリー５１に沿って転送され続ける。
【０２９１】
　ここで、段落０１３５に記載したツリー５２の更新動作によって、ツリー５２がルートノードをノード１１として、安定したとする。このときのツリー５２の構成を図１５に示す。
【０２９２】
　ノード１７は、ネットワークに接続されてから一定時間経過後に、ツリー５２が安定したと判断し、利用タググループ変更通知を、ツリー５２のルートノードである、ノード１１に送信し、ツリー５２を予備系から現用系に遷移させるよう命令する。この命令には、例えば制御フレーム（ＧＶＲＰ）を利用する。（このときのノード１７のメインコントローラ１１６４の状態は、図１２の状態１１６４４である。）
【０２９３】
　なお、ツリー５２が安定したことの検出は、ノード１７がネットワークに接続されてから一定時間経過することで検出するほか、ノード１７におけるツリー５２のＢＰＤＵ到着間隔が一定時間以上となることで検出することもできる。
【０２９４】
　利用タググループ変更通知を受信したノード１１は、ツリー５１のルートノードであるノード１１に対して利用タググループ変更通知を送信し、ツリー５１を予備系に遷移させるよう命令する。この利用タググループ変更通知には、例えば制御フレーム（ＧＶＲＰ）を利用する。そして、タググループ４２のタグを付け、ツリー５２のために送信するＢＰＤＵに、現用系フラグを立てる。ＢＰＤＵは、各ノードで転送されながら、全ノードに伝播する。
【０２９５】
　ツリー５１のノード１１は、利用タググループ変更通知を受信し、ツリー５１を予備系に遷移させ、タググループ４１のフラグを付け、ツリー５１のために送信するＢＰＤＵに、予備系フラグを立てる。この予備系フラグは、例えば、図１のＢＰＤＵのうちの予め決めてあるフィールドに設定される。設定は、ツリーマネージャ１１５１、１１５２がツリーテーブル１１５１５を書き換え、ツリーセレクタ１１６がタグテーブル１１７を書き換えることで実行される。ＢＰＤＵは、各ノードで転送されながら、全ノードに伝播する。
【０２９６】
　ノード１１〜１７は、タググループ４２のタグが付いたＢＰＤＵに現用系フラグが付加させたのを確認し、クライアントより転送されてくるフレームに付加するタグを、タググループ４１からタググループ４２に切り替える。このとき、タグテーブル１１７内の、挿入タグフィールド１１７２を書き換えられる。このタグが付加されたフレームは、ツリー５２に沿って転送される。
【０２９７】
　以上の切り替えが完了してしばらく経つと、ツリー５１を流れるフレームはなくなる。
【０２９８】
　ノード１７は、利用タググループ変更通知の送信から一定時間経過後に、タググループ４１のタグを付加するノードが存在しなくなったと判断し、自ノードをタググループ４１に加入させ、次のトポロジ変更に備える。自ノードをタググループ４１に加入させるために、ノード１７は、ツリーマネージャ１１５１内のツリーコントローラに対して、ＢＰＤＵ送信を許可し、ＢＰＤＵ送受信機１１５１２からのＢＰＤＵ送信を許可する。（このときのノード１７のメインコントローラ１１６４の状態は、図１２の状態１１６４５となる。）
　このとき、スパニングツリー５１について、再構成が行われるので、スパニングツリー５１に着目してネットワークを見ると、ネットワークは停止する。しかし、この間もネットワークにおける通信は、スパニングツリー５２を用いて行われているので、ノード１７の追加に伴って、輻輳、フレームの到着遅延等の問題は発生しない。
【０２９９】
　なお、ノード１７をタググループ４１に加入させる動作は、ツリー５２のルートノードであるノード１１、もしくは、ツリー５１のルートノードであるノード１１が行っても良い。
【０３００】
　ツリー５２のルートノードであるノード１１が、ノード１７をタググループ４１に加入させる場合は、ノード１１がノード１７から利用タググループ変更通知を受信してから一定時間経過後に、タググループ４１のタグを付加するノードが存在しなくなったと判断し、ノード１７に対してＧＶＲＰフレームを送信し、タググループ４１に加入するよう命令する。
【０３０１】
　ツリー５１のルートノードであるノード１１が、ノード１７をタググループ４１に加入させる場合は、ノード１１がノード１１から利用タググループ変更通知を受信してから一定時間経過後に、タググループ４１のタグを付加するノードが存在しなくなったと判断し、ノード１７に対してＧＶＲＰフレームを送信し、タググループ４１に加入するよう命令する。この場合は、ツリー５１のノード１１は、直接（ツリー５２のノード１１を介さずに）、ノード１７に対してＧＶＲＰフレームを送信する。ノード１７をタググループ４１に加入させる動作では、ＢＰＤＵに挿入するフラグに変更が生じないので、ルートノードを介す必要はないからである。
【０３０２】
　以上のようにして、ネットワークを停止させることなく、ノード１７を追加することができた。以降ノードの追加の際は、同様の動作を繰り返す。ただし、上記説明文中のタググループ４１とタググループ４２は適宜入れ替わる。
【０３０３】
　図１６は、以上に述べたノード１７の追加動作を表すシーケンス図である。
【０３０４】
　矢印３１は、タググループ４１を示すタグが挿入された、現用系フラグ付きＢＰＤＵの流れを示す。
【０３０５】
　矢印３２は、タググループ４２を示すタグが挿入された、予備系フラグ付きＢＰＤＵの流れを示す。
【０３０６】
　矢印３３は、タググループ４２を示すタグが挿入された、現用系フラグ付きＢＰＤＵの流れを示す。
【０３０７】
　矢印３４は、タググループ４１を示すタグが挿入された、予備系フラグ付きＢＰＤＵの流れを示す。
【０３０８】
　矢印３５は、タググループを示すタグが挿入されていない、ＧＶＲＰフレーム等による利用タググループ変更通知の流れを示す。
【０３０９】
　次に、図１５および図１４を参照して、本実施の形態において、ノード１７を削除する場合の動作について、具体例を用いて詳細に説明する。
【０３１０】
　図１５および図１４を参照すると、本動作例では、ノード１１〜１７、およびリンク２１〜３０を有する。
【０３１１】
　ノード１１〜１７の全ポートが所属するタググループが２つすでに設定されており、１つめのタググループをタググループ４１、２つめのタググループをタググループ４２と呼ぶ。
【０３１２】
　ノード１１〜１７には、独立して動作するスパニングツリー経路が２つ存在し、タググループ４１上で動作するスパニングツリーをツリー５１、タググループ４２上で動作するスパニングツリーをツリー５２と呼ぶ。
【０３１３】
　図１５では、ツリー５２は太線で表され、ノード１１をルートノードとして安定しているとする。
【０３１４】
　ツリー５１のＢＰＤＵにはタググループ４１のタグが、ツリー５２のＢＰＤＵにはタググループ４２のタグがつく。
【０３１５】
　現在、クライアントからノード１１〜１７に送信されたデータには、ツリー５２が現用系であるので、タググループ４２のタグが付加されている。このタグが付加されたデータは、ツリー５２に沿って転送されている。
【０３１６】
　ノード１７は、各タググループのＢＰＤＵを受信しており、現時点での現用系がタググループ４２で、現時点での予備系がタググループ４１であるとすでに確認しているとする。
【０３１７】
　ノード１７は、設定インタフェースもしくはその他の手段により削除要求を受けると、自ノード１７を現用系であるタググループ４２にのみ参加させ、タググループ４１には参加させないように設定する。このとき、ノード１７は、タググループ４１のＢＰＤＵ送信を停止する。
【０３１８】
　この設定により、ノード１７の隣接ノードにおいてＢＰＤＵを受信しなくなることでノード１７が削除されたことが認識され、タググループ４１のメンバに変更が発生するため、ツリー５１を更新する動作が開始される。タググループ４２のメンバには変更が無いため、ツリー５２は更新されない。
【０３１９】
　クライアントからのフレームは、ノード１１〜ノード１７で、今までどおりタググループ４２のタグが付加され、ツリー５２に沿って転送され続ける。
【０３２０】
　ここで、ツリー５１はルートノードをノード１１として、ノード１７を参加させないで安定した状態を示している。ツリー５１の構成を図１４に示す。
【０３２１】
　なお、ここでいう安定とは、スパニングツリーのツリー構造が、十分に長い時間変化しない状態になっている状態のことを言う。
【０３２２】
　ノード１７は、タググループ４１不参加の設定から一定時間経過後に、ツリー５１が安定したと判断し、利用タググループ変更通知を、ツリー５１のルートノードである、ノード１１に送信し、ツリー５１を予備系から現用系に遷移させるよう命令する。（このときのノード１７のメインコントローラ１１６４の状態は、図１２の状態１１６４４である。）
【０３２３】
　利用タググループ変更通知を受信したノード１１は、ツリー５２のルートノードであるノード１１に対して利用タググループ変更通知を送信し、ツリー５２を予備系に遷移させるよう命令する。そして、タググループ４１のフラグを付け、ツリー５１のために送信するＢＰＤＵに、現用系フラグを立てる。ＢＰＤＵは、各ノードで転送されながら、全ノードに伝播する。
【０３２４】
　ツリー５１のノード１１は、利用タググループ変更通知を受信し、ツリー５２を予備系に遷移させ、タググループ４２のフラグを付け、ツリー５２のために送信するＢＰＤＵに、予備系フラグを立てる。ＢＰＤＵは、各ノードで転送されながら、全ノードに伝播する。
【０３２５】
　ノード１１〜１７は、タググループ４１のタグが付いたＢＰＤＵに現用系フラグが付加させたのを確認し、クライアントより転送されてくるフレームに付加するタグを、タググループ４２からタググループ４１に切り替える。このタグが付加されたフレームは、ツリー５１に沿って転送される。
【０３２６】
　以上の切り替えが完了してしばらく経つと、ツリー５２を流れるフレームはなくなる。
【０３２７】
　ノード１７は、利用タググループ変更通知の送信から一定時間経過後に、タググループ４２のタグを付加するノードが存在しなくなったと判断し、自ノードをネットワークから削除しても良いという、削除許可の通知を、設定インタフェース１１８に出力する。（このときのノード１７のメインコントローラ１１６４の状態は、図１２の状態１１６４３である。）
【０３２８】
　以降ノードの削除の際は、同様の動作を繰り返す。ただし、上記説明文中のタググループ４１とタググループ４２は適宜入れ替わる形となる。
【０３２９】
　図１４および図１５を参照して、本実施の形態において、タグをＢＰＤＵのみに付加し、データにはタグを付加しない場合における、ノード１７を追加する場合の動作について、具体例を用いて詳細に説明する。
【０３３０】
　図１４では、ツリー５１は太線で表され、ノード１１をルートノードとして安定しているとする。安定とは、スパニングツリーのツリー構造が、十分に長い時間変化しない状態になっている状態のことを言う。
【０３３１】
　ツリー５１のＢＰＤＵにはタググループ４１のタグが、ツリー５２のＢＰＤＵにはタググループ４２のタグがつく。
【０３３２】
　現在、クライアントからノード１１〜１６に送信されたデータには、何もタグは付加されない。データは、各ノードのフォワーディングテーブルにおける設定にしたがって、ツリー５１に沿って転送されている。
【０３３３】
　ノード１７は、リンク２９およびリンク３０と接続されると、どのタググループにも加入せず、ＢＰＤＵの受信を開始する。（このときのノード１７のメインコントローラ１１６４の状態は、図１２の状態１１６４１である。）
【０３３４】
　ノード１７は、各タググループのＢＰＤＵを受信すると、ＢＰＤＵに付加されたタグ内のフラグにより、現時点での現用系がタググループ４１で、現時点での予備系がタググループ４２であると確認する。そして、タググループ４２でのみＢＰＤＵの送受信を行い、タググループ４１ではＢＰＤＵは受信のみ行い、送信を行わないように設定する。（このときのノード１７のメインコントローラ１１６４の状態は、図１２の状態１１６４２である。）
【０３３５】
　ノード１７が追加されると、タググループ４２のメンバに変更が発生するため、スパニングツリープロトコルにより、ツリー５２を更新する動作が開始される。タググループ４１のメンバには変更が無いため、ツリー５１は更新されない。（このときのノード１７のメインコントローラ１１６４の状態は、図１２の状態１１６４３である。）
【０３３６】
　クライアントから送信されるフレームには、今までどおりタグは付加されず、ツリー５１に沿って転送され続ける。
【０３３７】
　ここで、ツリー５２はルートノードをノード１１として、安定したとする。ツリー５２の構成を図１５に示す。
【０３３８】
　ノード１７は、ネットワークに接続されてから一定時間経過後に、ツリー５２が安定したと判断し、利用タググループ変更通知を、ツリー５２のルートノードである、ノード１１に送信し、ツリー５２を予備系から現用系に遷移させるよう命令する。（このときのノード１７のメインコントローラ１１６４の状態は、図１２の状態１１６４４である。）
【０３３９】
　利用タググループ変更通知を受信したツリー５２のノード１１は、ツリー５１のルートノードであるノード１１に対して利用タググループ変更通知を送信し、ツリー５１を予備系に遷移させるよう命令する。そして、タググループ４２のフラグを付け、ツリー５２のために送信するＢＰＤＵに、現用系フラグを立てる。ＢＰＤＵは、各ノードで転送されながら、全ノードに伝播する。
【０３４０】
　ツリー５１のノード１１は、利用タググループ変更通知を受信し、ツリー５１を予備系に遷移させ、タググループ４１のフラグを付け、ツリー５１のために送信するＢＰＤＵに、予備系フラグを立てる。ＢＰＤＵは、各ノードで転送されながら、全ノードに伝播する。
【０３４１】
　ノード１１〜１７は、タググループ４２のタグが付いたＢＰＤＵに現用系フラグが付加させたのを確認し、ルーティングテーブルを、ツリー５２に従った設定に変更する。これにより、前記ノードにおいて転送されるフレームは、ツリー５２に沿って転送されるようになる。
【０３４２】
　すべてのノードのルーティングテーブルが、ツリー５２利用のものに切り替わると、ツリー５１を流れるフレームはなくなる。
【０３４３】
　ノード１７は、利用タググループ変更通知の送信から一定時間経過後に、タググループ４１に従ったテーブル設定を行うノードが存在しなくなったと判断し、自ノードをタググループ４１に加入させ、次のトポロジ変更に備える。（このときのノード１７のメインコントローラ１１６４の状態は、図１２の状態１１６４４である。）
【０３４４】
　以上のようにして、ネットワークを停止させることなく、ノード１７を追加することができた。以降ノードの追加の際は、同様の動作を繰り返す。ただし、上記説明文中のタググループ４１とタググループ４２は適宜入れ替わる。
【０３４５】
　以上の説明では、タイマーを用いて、ツリーの安定状態を確認していたが、安定状態の確認方法はこれに限らず、以下に示すように、ＢＰＤＵまたはフレームの到着間隔を計測し、それによって安定状態を確認することも可能である。
【０３４６】
　図１４では、ツリー５１は太線で表され、ノード１１をルートノードとして安定しているとする。
【０３４７】
　ツリー５１のＢＰＤＵにはタググループ４１のタグが、ツリー５２のＢＰＤＵにはタググループ４２のタグがつく。
【０３４８】
　現在、クライアントからノード１１〜１６に送信されたデータには、タググループ４１のタグが付加されている。このタグが付加されたデータは、ツリー５１に沿って転送されている。
【０３４９】
　ノード１７は、リンク２９およびリンク３０と接続されると、どのタググループにも加入せず、ＢＰＤＵの受信を開始する。
【０３５０】
　ノード１７は、各タググループのＢＰＤＵを受信すると、現時点での現用系がタググループ４１で、現時点での予備系がタググループ４２であると確認する。そして、自ノードをタググループ４２にのみ加入させてＢＰＤＵの送受信を行い、タググループ４１ではＢＰＤＵは受信のみ行い、送信を行わないように設定する。そして、タググループ４２のルートノードであるノード１１および、タググループ４１のルートノードであるノード１１のそれぞれに対して、ノード１７が追加されたことを通知するフレームを送信する。
【０３５１】
　ノード１７が追加されると、タググループ４２のメンバに変更が発生するため、スパニングツリープロトコルにより、ツリー５２を更新する動作が開始される。タググループ４１のメンバには変更が無いため、ツリー５１は更新されない。
【０３５２】
　クライアントから送信されるフレームには、今までどおりタググループ４１のタグが付加され、ツリー５１に沿って転送され続ける。
【０３５３】
　ここで、ツリー５２はルートノードをノード１１として、安定したとする。ツリー５２の構成を図１５に示す。
【０３５４】
　ツリー５２のルートノードであるノード１１は、ツリー５２のＢＰＤＵ到着間隔が一定時間以上となることを検出すると、ツリー５２が安定したと判断し、ツリー５１のルートノードであるノード１１に対して利用タググループ変更通知を送信し、ツリー５１を予備系に遷移させるよう命令する。そして、タググループ４２のフラグを付け、ツリー５２のために送信するＢＰＤＵに、現用系フラグを立てる。ＢＰＤＵは、各ノードで転送されながら、全ノードに伝播する。
【０３５５】
　なお、ツリー５２の安定検出は、ツリー５１のルートノードであるノード１１が行っても良い。この場合、ツリー５１のルートノードであるノード１１は、ツリー５２のＢＰＤＵ到着間隔が一定時間以上となることを検出すると、ツリー５２が安定したと判断し、ツリー５２のルートノードであるノード１１に対して利用タググループ変更通知を送信し、ツリー５２を予備系に遷移させるよう命令する。ツリー５１のルートノードであるノード１１は、タググループ４２のフラグを付け、ツリー５２のために送信するＢＰＤＵに、現用系フラグを立てる。ＢＰＤＵは、各ノードで転送されながら、全ノードに伝播する。
【０３５６】
　ノード１１は、利用タググループ変更通知を受信し、ツリー５１を予備系に遷移させ、タググループ４１のフラグを付け、ツリー５１のために送信するＢＰＤＵに、予備系フラグを立てる。ＢＰＤＵは、各ノードで転送されながら、全ノードに伝播する。
【０３５７】
　ノード１１〜１７は、タググループ４２のタグが付いたＢＰＤＵに現用系フラグが付加させたのを確認し、クライアントより転送されてくるフレームに付加するタグを、タググループ４１からタググループ４２に切り替える。このタグが付加されたフレームは、ツリー５２に沿って転送される。
【０３５８】
　以上の切り替えが完了してしばらく経つと、ツリー５１を流れるフレームはなくなる。
【０３５９】
　タググループ４１のルートノードであるノード１１は、タググループ４１のタグを付加してツリー５１を流れるフレームの到着間隔が一定時間以上になると、タググループ４１のタグを付加するノードが存在しなくなったと判断し、ノード１７に対してＧＶＲＰフレームを送信し、タググループ４１に加入するよう命令し、次のトポロジ変更に備える。
【０３６０】
　なお、ノード１７をタググループ４１に加入させる動作は、ツリー５２のルートノードであるノード１１が行っても良い。
【０３６１】
　ツリー５２のルートノードであるノード１１が、ノード１７をタググループ４１に加入させる場合は、タググループ４１のタグを付加してツリー５１を流れるフレームの到着間隔が一定時間以上になると、タググループ４１のタグを付加するノードが存在しなくなったと判断し、ノード１７に対してＧＶＲＰフレームを送信し、タググループ４１に加入するよう命令し、次のトポロジ変更に備える。
【０３６２】
　以上のようにして、ネットワークを停止させることなく、ノード１７を追加することができた。以降ノードの追加の際は、同様の動作を繰り返す。ただし、上記説明文中のタググループ４１とタググループ４２は適宜入れ替わる。
【０３６３】
　図１４および図１５を参照して、本実施の形態において、予備系への移行完了通知を受信することによって、予備系に遷移したことを検知する場合における、ノード１７を追加する場合の動作について、具体例を用いて詳細に説明する。
【０３６４】
　図１４では、ツリー５１は太線で表され、ノード１１をルートノードとして安定しているとする。
【０３６５】
　ツリー５１のＢＰＤＵにはタググループ４１のタグが、ツリー５２のＢＰＤＵにはタググループ４２のタグがつく。
【０３６６】
　現在、クライアントからノード１１〜１６に送信されたデータには、タググループ４１のタグが付加されている。このタグが付加されたデータは、ツリー５１に沿って転送されている。
【０３６７】
　ノード１７は、リンク２９およびリンク３０と接続されると、どのタググループにも加入せず、ＢＰＤＵの受信を開始する。
【０３６８】
　ノード１７は、各タググループのＢＰＤＵを受信すると、現時点での現用系がタググループ４１で、現時点での予備系がタググループ４２であると確認する。そして、自ノードをタググループ４２にのみＢＰＤＵの送受信を行い、タググループ４１ではＢＰＤＵは受信のみ行い、送信を行わないように設定する。
【０３６９】
　ノード１７が追加されると、タググループ４２のメンバに変更が発生するため、スパニングツリープロトコルにより、ツリー５２を更新する動作が開始される。タググループ４１のメンバには変更が無いため、ツリー５１は更新されない。
【０３７０】
　クライアントから送信されるフレームには、今までどおりタググループ４１のタグが付加され、ツリー５１に沿って転送され続ける。
【０３７１】
　ここで、ツリー５２はルートノードをノード１１として、安定したとする。ツリー５２の構成を図１５に示す。
【０３７２】
　ノード１７は、ネットワークに接続されてから一定時間経過後に、ツリー５２が安定したと判断し、利用タググループ変更通知を、ツリー５２のルートノードである、ノード１１に送信し、ツリー５２を予備系から現用系に遷移させるよう命令する。
【０３７３】
　利用タググループ変更通知を受信したノード１１は、ツリー５１のルートノードであるノード１１に対して利用タググループ変更通知を送信し、ツリー５１を予備系に遷移させるよう命令する。そして、タググループ４２のフラグを付け、ツリー５２のために送信するＢＰＤＵに、現用系フラグを立てる。ＢＰＤＵは、各ノードで転送されながら、全ノードに伝播する。
【０３７４】
　ノード１１は、利用タググループ変更通知を受信し、ツリー５１を予備系に遷移させ、タググループ４１のフラグを付け、ツリー５１のために送信するＢＰＤＵに、予備系フラグを立てる。ＢＰＤＵは、各ノードで転送されながら、全ノードに伝播する。
【０３７５】
　ノード１１〜１７は、タググループ４２のタグが付いたＢＰＤＵに現用系フラグが付加させたのを確認し、クライアントより転送されてくるフレームに付加するタグを、タググループ４１からタググループ４２に切り替え、さらに切替完了通知をツリー５２のルートノードであるノード１１に対して送信する。
【０３７６】
　以上の切り替えが完了してしばらく経つと、ツリー５１を流れるフレームはなくなる。
【０３７７】
　ノード１１は、ノード１１〜１７のすべてのノードから切替完了通知を受信すると、タググループ４１のタグを付加するノードが存在しなくなったと判断し、ノード１７に対してＧＶＲＰフレームを送信し、タググループ４１に加入するよう命令する。
【０３７８】
　なお、ノード１７をタググループ４１に加入させる動作は、新規に追加されたノードであるノード１７、もしくは、ツリー５１のルートノードであるノード１１が行っても良い。
【０３７９】
　新規に追加されたノードであるノード１７が、ノード１７自身をタググループ４１に加入させる場合は、ノード１１〜１６が、タググループ４２のタグが付いたＢＰＤＵに現用系フラグが付加させたのを確認し、クライアントより転送されてくるフレームに付加するタグを、タググループ４１からタググループ４２に切り替える際に、切替完了通知を新規に追加されたノードであるノード１７に対して送信し、ノード１７が、ノード１１〜１６のすべてのノードから切替完了通知を受信すると、タググループ４１のタグを付加するノードが存在しなくなったと判断し、ノード１７自身をタググループ４１に加入させる。
【０３８０】
　ツリー５１のルートノードであるノード１１が、ノード１７をタググループ４１に加入させる場合は、ノード１１〜１７が、タググループ４２のタグが付いたＢＰＤＵに現用系フラグが付加させたのを確認し、クライアントより転送されてくるフレームに付加するタグを、タググループ４１からタググループ４２に切り替える際に、切替完了通知をツリー５１のルートノードであるノード１１に対して送信し、ノード１１が、ノード１１〜１７のすべてのノードから切替完了通知を受信すると、タググループ４１のタグを付加するノードが存在しなくなったと判断し、ノード１７に対してＧＶＲＰフレームを送信し、タググループ４１に加入するよう命令する。
【０３８１】
　以上のようにして、ネットワークを停止させることなく、ノード１７を追加することができる。以降ノードの追加の際は、同様の動作を繰り返す。ただし、上記説明文中のタググループ４１とタググループ４２は適宜入れ替わる。
【０３８２】
　次に、本実施の形態の効果について説明する。
【０３８３】
　従来、スパニングツリーに属するノードの追加および削除時は、全体もしくは一部のデータフレームの転送を停止させて、スパニングツリーを構築しなおすため、再構築中にネットワークが停止する場合があった。
【０３８４】
　本実施の形態では、構成変更前のスパニングツリーを運用したまま、新規追加ノードを含めたスパニングツリーを生成し、新規スパニングツリーの安定後に利用するスパニングツリーを切り替えることにより、ネットワークを停止させずに、スパニングツリーに属するノードの追加および削除等のスパニングツリー再構成が可能である。
【０３８５】
　またこの結果、輻輳発生の可能性を下げることが可能である。
【０３８６】
（第２の実施の形態）
　以下、本発明の第２の実施の形態について、図面を参照して詳細に説明する。
【０３８７】
　本発明の第２の実施の形態は、第１の実施の形態において、コストの計算時にリンク帯域の太さの代わりに、空き帯域の容量もしくは通過TCPフロー数、HTTPリクエスト数等を利用し、さらに、コストが変更された場合には、ノードの追加・削除の場合と同様に、現用系と予備系の遷移を行う点が異なる。なお、以降は空き帯域の容量をコストとして用いた場合について記述するが、通過TCPフロー数およびHTTPリクエスト数についても、特に断りのない限り同様に実現可能である。
【０３８８】
　ＩＥＥＥ８０２．１ＤおよびＩＥＥＥ８０２．１ｗでは、リンクのコストはリンク帯域の太さの逆数で決定されていた。つまり、負荷に応じて動的にコストを変化させることができなかった。
【０３８９】
　本実施の形態においては、リンクのコストをリンクの空き帯域の逆数で決定することで、負荷に応じた動的なコスト変更を行う。
【０３９０】
　図１７は、第２の実施の形態におけるツリーセレクタ１１６の構成を示している。図１７を参照すると、本発明の第２の実施の形態は、第１の実施の形態における図１１のツリーセレクタにおいて、コスト参照タイマ１１６７、関数演算器１１６８、および、平滑化回路１１６９が追加されている点において異なる。
【０３９１】
　メインコントローラ１１６４αは、第１の実施における動作のほか、コスト参照タイマ１１６７より満了通知を受信すると、リソースモニタから、前回のコスト参照タイマ満了以降にリンクを流れたフレームの流量情報もしくはＴＣＰフロー数またはＨＴＴＰリクエスト数を取得し、その流量、フロー数、もしくはリクエスト数を元にコストを計算し、予備用に登録されているツリーマネージャ（以下、予備系のツリーマネージャという）に通知する動作を行う。流量の場合は、流量およびリンク帯域の太さより、リンクの空き帯域を求め、前記リングの空き帯域の逆数をコストとして利用する。ＴＣＰフロー数およびＨＴＴＰリクエスト数の場合は、あらかじめ設定してある最大許容フロー数および最大許容リクエスト数と、実際にリンクを通過するＴＣＰフロー数もしくはリクエスト数との差を取り、この差の逆数をコストとして利用する。
【０３９２】
　メインコントローラ１１６４αは、前記手段によりコストを算出した後、関数演算器１１６８にコストを渡して評価し、さらに関数演算器の評価結果を平滑化回路１１６９に渡して平滑化し、平滑化された結果の値を、予備系のツリーマネージャに対して送信する。
【０３９３】
　関数演算器１１６８は、メインコントローラ１１６４αより入力されたコスト値をパラメータとして、比例関数、ヒステリシス関数、および階段関数等、あらかじめ指定されている任意の関数を用いて、出力コスト値を決定し、メインコントローラ１１６４に返す、関数演算器１１６８の働きにより、状態遷移の振動を防止することが可能となる。コスト値の急激な変動を抑えコストを滑らかに変化させるためである。
【０３９４】
　平滑化回路１１６９は、ローパスフィルタ等を用いて、あらかじめ保存してある前回の入力パラメータと、メインコントローラ１１６４αより新たに渡された入力パラメータの平滑化を行い、結果をメインコントローラ１１６４αに通知する。平滑化回路１１６９の働きにより、コストの急激な変動や、状態遷移の振動を防止することが可能となる。
【０３９５】
　コスト参照タイマ１１６７は、メインコントローラ１１６４αより送信されたセット通知の受信から、あらかじめ設定された時間が経過すると、メインコントローラ１１６４αに対してタイマ満了通知を送信する。
【０３９６】
　図１８は、本発明の第２の実施の形態の図１７における、メインコントローラ１１６４Ａの状態遷移を詳細に示した流れ図である。図１８を参照すると、本発明の第２の実施の形態は、第１の実施の形態における図１２において、状態１１６４Ａおよび状態１１６４Ｂが追加されている点において異なる。
【０３９７】
　状態１１６４Ａは、現用系ツリーマネージャが、ツリーマネージャ１１５２であり、予備系ツリーマネージャがツリーマネージャ１１５１であり、ツリーマネージャ１１５２内のＢＰＤＵ送受信機１１５２２のＢＰＤＵ送信機能が有効にされ、ツリーマネージャ１１５１内のＢＰＤＵ送受信機１１５１２のＢＰＤＵ送信機能も有効にされている状態である。なお、ＢＰＤＵ送受信機１１５１２およびＢＰＤＵ送受信機１１５２２のＢＰＤＵ受信機能は、送信機能の有効もしくは無効に関わらず、常に有効である。
【０３９８】
　状態１１６４Ｂは、現用系ツリーマネージャが、ツリーマネージャ１１５１であり、予備系ツリーマネージャがツリーマネージャ１１５２であり、ツリーマネージャ１１５１内のＢＰＤＵ送受信機１１５１２のＢＰＤＵ送信機能が有効にされ、ツリーマネージャ１１５２内のＢＰＤＵ送受信機１１５２２のＢＰＤＵ送信機能も有効にされている状態である。なお、ＢＰＤＵ送受信機１１５１２およびＢＰＤＵ送受信機１１５２２のＢＰＤＵ受信機能は、送信機能の有効もしくは無効に関わらず、常に有効である。
【０３９９】
　以下、図１８を参照にして、状態１１６４５を基点としてコスト計算の流れを示すが、この動作は状態１１６４６を基点とした場合においても、同様に適用可能である。
【０４００】
　メインコントローラ１１６４αは、状態１１６４５に遷移した際、設定インタフェース１１８もしくはＧＶＲＰ送受信機１１６２より、動的なコスト計算を利用する指定を受けた場合に、コスト参照タイマ１１６７をセットする。（状態１１６４５）
　メインコントローラ１１６４αは、コスト参照タイマ１１６７からタイマ満了の通知を受信すると、リソースモニタ１１９より累積通過バイト数の情報を受信すると同時に、カウンタリセット通知を出して、リソースモニタ１１９の累積通過バイト数を０にリセットさせる。さらに、前記累積通過バイト数もしくはＴＣＰフロー数またはＨＴＴＰリクエスト数よりコストを計算し、結果を関数演算器１１６８に渡す。
【０４０１】
　関数演算器１１６８は、メインコントローラ１１６４αより入力された値を、設定された関数により評価し、結果をメインコントローラ１１６４αに返却する。ここでは、比例関数が設定されており、ある入力値に対する出力値が同一になる例をとって解説する。
【０４０２】
　メインコントローラ１１６４αは、関数演算器１１６８よりコストの評価結果を受け取ると、その値を平滑化回路１１６９に通知する。
【０４０３】
　平滑化回路１１６９は、設定にしたがって入力値をローパスフィルタ等によって平滑化し、結果をメインコントローラ１１６４αに返却する。
【０４０４】
　メインコントローラ１１６４αは、平滑化回路１１６９より平滑化完了後のコスト値を受信すると、このコスト値を予備系のツリーマネージャ１１５１に通知する。ツリーマネージャ１１５１は、このコスト情報を元に、スパニングツリーを再計算し、計算の結果、トポロジに変更があるか、ないかを、メインコントローラ１１６４αに通知する。（図１８の状態１１６４Ａ）
【０４０５】
　メインコントローラ１１６４αは、状態１１６４Ａにおいて、再計算後のツリーが計算前のツリーと同一もしくは、あらかじめ設定された変化よりも変化の度合いが小さい場合は、状態１１６４５に遷移し、コスト参照タイマを再セットする。図１８の状態遷移図では、一例として、わずかでも変化がある場合は、状態１１６４５には遷移しない設定であるとして説明している。（状態１１６４Ａ）
【０４０６】
　メインコントローラ１１６４αは、状態１１６４Ａにおいて、再計算後のツリーが計算前のツリーと異なる場合で、かつ、その変化があらかじめ設定された変化より大きいものであるとき、安定タイマ１１６５をセットし、タイマ満了後に状態１１６４Ｂに遷移する。図１８の状態遷移図では、わずかでも変化がある場合には、１１６４Ｂに遷移する設定であるとして説明している。（状態１１６４Ａ）
【０４０７】
　メインコントローラ１１６４αは、安定タイマ１１６５の満了通知を受信すると、現用に登録されているツリーマネージャ１１５２と、予備用に登録されているツリーマネージャ１１５１を入れ替え、新しく現用をツリーマネージャ１１５１、予備用をツリーマネージャ１１５２とする。さらに、ＧＶＲＰ送受信機１１６２を通じて、新ツリーのルートノードに対して、利用タググループ変更通知を送信する。この利用タググループ変更通知の内容は、ＢＰＤＵに反映され、全ノードに伝達される。その後、安定タイマ１１６５を作動させ、状態１１６４６に遷移する。（状態１１６４Ｂ）
【０４０８】
　メインコントローラ１１６４αは、安定タイマ１１６５の満了通知を受信すると、ツリーマネージャ１１５２に対して新規コストの通知を行い、新たに計算したコスト情報を元に、スパニングツリーを再計算させる。また、コスト参照タイマ１１６７をスケジュールする。（状態１１６４６）
【０４０９】
　次に図７を利用して、本実施の形態において、ノード１５からノード１３への転送経路が変更される場合の、スパニングツリー切り替え動作について、具体例を用いて詳細に説明する。
【０４１０】
　図７を参照すると、本動作例では、ノード１１〜１６、クライアント９１〜９６、双方向リンク８１〜８６、および、双方向リンク２１〜２８を含む。
【０４１１】
　ノード１１にはリンク８１によりクライアント９１が、ノード１２にはリンク８２によりクライアント９２が、ノード１３にはリンク８３によりクライアント９３が、ノード１４にはリンク８４によりクライアント９４が、ノード１５にはリンク８５によりクライアント９５が、ノード１６にはリンク２６によりクライアント９６が、それぞれ接続されている。
【０４１２】
　ノード１１とノード１２の間はリンク２１で、ノード１２とノード１３の間はリンク２２で、ノード１３とノード１４の間はリンク２３で、ノード１１とノード１５の間はリンク２４で、ノード１５とノード１６の間はリンク２５で、ノード１６とノード１４の間はリンク２６で、ノード１２とノード１５の間はリンク２７で、ノード１３とノード１６の間はリンク２８で、それぞれ接続されている。
【０４１３】
　ノード１１〜１６の全ポートが所属するタググループが２つすでに設定されており、１つめのタググループをタググループ４１、２つめのタググループをタググループ４２と呼ぶ。
【０４１４】
　ノード１１〜１６には、独立して動作するスパニングツリー回路が２つ存在し、タググループ４１上で動作するスパニングツリーをツリー５１、タググループ４２上で動作するスパニングツリーをツリー５２と呼ぶ。
【０４１５】
　図７において、ツリー４１は、ノード１３をルートノードとし、すべてのリンクに等しく１０に設定された初期コストを用いて、すでに安定しているとする。ツリー５１のＢＰＤＵにはタググループ４１のタグが、ツリー５２のＢＰＤＵにはタググループ４２のタグがつく。
【０４１６】
　現在、クライアントからノード１１〜１６に送信されたデータには、現用系であるタググループ４１のタグが付加されている。このタグが付加されたデータは、ツリー５１に沿って転送されている。
【０４１７】
　初期状態では、クライアント９１〜９６のうち、どのクライアントもデータ転送を行っていない。
【０４１８】
　各ノードは、一定時間ごとに、Ｈｅｌｌｏ　Ｔｉｍｅで規定される周期でＢＰＤＵを送受信することにより、ＢＰＤＵの状態を確認している。このフレームには、現用系と予備系の識別フラグがあり、現在は現用系であるタググループ４１のタグが付加されたＢＰＤＵのみに、現用系のフラグがつき、予備系であるタググループ４２のタグが付加されたＢＰＤＵには、現用系を示すフラグは付加されない。
【０４１９】
　各ノードは、設定インタフェース１１８もしくはＧＶＲＰ送受信機１１６２より、すでに動的なコスト計算を利用する指定を受けているため、コスト参照タイマが満了するごとに、前回のタイマ満了以降にリンクを流れたフレームの流量を参照し、コストの再計算および、予備系ツリーを用いたスパニングツリーの再計算を行う。
【０４２０】
　ここで、クライアント９５からクライアント９３、および、クライアント９６からクライアント９３との間で、データ転送を開始したとする。
【０４２１】
　転送初期においては、クライアント９５からクライアント９３へのデータは、ツリー５１を利用し、リンク８５、２５、２８、８３を経由して転送される。また、クライアント９６からクライアント９３へのデータも、ツリー５１を利用し、リンク８６、２８、８３を経由して転送される。
【０４２２】
　データ転送から一定時間が経過すると（各ノードのコスト参照タイマ１１６７が満了すると）、リンク２１〜２８の空き容量をもとに、ツリー５２におけるリンク２１〜２８のコストが再計算され、関数演算器および平滑化回路にかけられる。ここで、リンク２８の空き帯域は少なくなっているため、ノード１６によりツリー５２のリンク２８のコストは１５に、リンク２５の空き帯域は、リンク２８ほどではないが少なくなっているため、ノード１５によりツリー５２のリンク２５のコストは１２に、それぞれ変更されたとする。このとき、現在使用している、ツリー５１のコストは変更されない。
【０４２３】
　ノード１６は、コスト変更を検知し、変更後のコストを利用して作成したＢＰＤＵ（図５のRoot path Cost 22056の値が変更される）を、隣接するノード１３、ノード１４、ノード１５に対して、それぞれ送信する。このＢＰＤＵにはタググループ４２のタグが付加される。
【０４２４】
　ノード１５も同様に、コスト変更を検知し、変更後のコストを利用して作成したＢＰＤＵを、隣接するノード１１、ノード１２、ノード１６に対して、それぞれ送信する。
【０４２５】
　ノード１５は、ノード１６からコスト１５が付加されたＢＰＤＵを受信すると、リンク２５のコストも加算し、リンク２５、リンク２８経由でノード１３に到達するために、コスト２７がかかることを認識する。
【０４２６】
　その後ノード１５は、ノード１２から、コスト１０が付加されたＢＰＤＵを受信すると（ノード１２は、ルートノード（ノード１３）までのコストを、定期的に隣接ノード（ノード１１、およびノード１５）に送信する）、リンク２７のコストも加算し、リンク２７、リンク２２経由でノード１３に到達するために、コスト２０がかかることを認識する。このコストは、リンク２５経由のコストよりも小さいため、ノード１５は停止ポートをリンク２７側からリンク２５側に切り替え、リンク２７およびリンク２２を利用して、リンク１３に到達するツリーを形成する。リンク２７、２２経由のツリーを作成するときにもスパニングツリープロトコルが使用される。そして、安定タイマ１１６５を起動し、ツリーが安定するのを待つ。
【０４２７】
　ここで、ツリー５２が、ノード１３をルートノードとして安定したとする。
【０４２８】
　ツリー５１のルートノードであるノード１３は、図１３の安定タイマ１１６５が満了すると、ツリー形成が安定したと判断し、新ツリーとなるツリー５２のルートノードであるノード１３に対して、転送に利用する現用系ツリーをツリー５１からツリー５２に切り替えるよう命令する、タググループ変更メッセージを送信する。その後、安定タイマ１１６５を作動させる。
【０４２９】
　ツリー５２のルートノードであるノード１３は、ツリー切替メッセージを受信すると、旧現用系ツリーであるツリー４１のルートであるノード１３に対して、転送に利用する現用系ツリーをツリー５１からツリー５２に切り替えるよう命令する、タググループ変更メッセージを送信する。この利用タググループ変更通知の内容は、ノード１３から送信される、ツリー５１およびツリー５２の各ＢＰＤＵに反映され、全ノードに伝達される。
【０４３０】
　ノード１３は、旧現用系ルートノードへのタググループ変更メッセージの送信を完了させると、自ノードがクライアント９３より受信して、ネットワーク内に送信するフレームの転送に利用するツリーを、今まで利用していたツリー５１からツリー５２へ切り替える。切り替えが完了すると、クライアント９３からクライアント９５に向けて送信されていたフレームは、リンク８３、リンク２２、リンク２７、リンク８５を経由して、クライアント９５に転送されるようになる。
【０４３１】
　このようにして、クライアント９３からクライアント９５、および、クライアント９３からクライアント９６に向けて送信されるフレームの転送経路は分散され、リンク２８の混雑が解消される。
【０４３２】
　以降、コスト参照タイマが満了するごとに、リンクの空き帯域に基づくコスト計算によってスパニングツリーが再計算され、周期的に空き帯域をコストに反映する動的な経路変更が行われる。この結果、各リンクのトラフィックが分散され、リンクの負荷を分散し、輻輳を防止することができる。
【０４３３】
　次に、本実施の形態の効果について説明する。
【０４３４】
　従来、リンク容量を用いてコストを計算し、スパニングツリー構築時の経路選択に利用しているため、トラフィックに応じた動的な負荷分散のための経路変更ができなかった。
【０４３５】
　本実施の形態では、リンクコストを、空き帯域やサーバ負荷等の動的情報によって計算することにより、トラフィックの負荷分散が可能である。
【０４３６】
　また従来、コストをトラフィック状況に応じて動的に変化させようとすると、局所的もしくはネットワーク全体で、データフレームの転送を停止させてスパニングツリーを構築しなおして経路を変更するため、再構築中にネットワークが停止する場合があった。
【０４３７】
　本実施の形態では、変更前のツリーを運用したまま、コスト変更後のツリーを生成し、新規ツリーの安定後に利用するツリーを切り替えることにより、経路変更にともなうスパニングツリー再構成のために、ネットワークを停止させることなく負荷分散が可能である。
またこの結果、輻輳発生の可能性を下げることが可能である。
【０４３８】
（第３の実施の形態）
　以下、本発明の第３の実施の形態について、図面を参照して詳細に説明する。
【０４３９】
　本発明の第３の実施の形態は、第２の実施の形態において、コストが変更されたかされなかったかに関わらず、現用系と予備系の遷移を行う点が異なる。なお、以降は空き帯域の容量をコストとして用いた場合について記述するが、通過TCPフロー数およびHTTPリクエスト数についても、特に断りのない限り同様に実現可能である。
【０４４０】
　図１９を参照すると、本発明の第３の実施の形態は、第２の実施の形態における図１８において、状態１１６４Ａと状態１１６４Ｂの間の遷移が発生しないこと、ならびに、状態１１６４３と状態１１６４４の間の遷移および、状態１１６４７と状態１１６４８の間の遷移が、安定タイマ１１６５の満了によって起こるのではなく、ＢＰＤＵ中の現用系フラグの切り替え検出によって発生する点が異なる。
【０４４１】
　第３の実施の形態におけるメインコントローラ１１６４βは、リソースモニタ１１９より新たにネットワークに接続されたことの通知を受信すると、ツリーマネージャ１１５１もしくはツリーマネージャ１１５２からの現用系通知の到着を待つ。ツリーマネージャ１１５１もしくはツリーマネージャ１１５２よりＢＰＤＵに含まれる現用系通知を受信すると、前記通知において指定されたツリーマネージャ１１５１もしくはツリーマネージャ１１５２を現用に、予備用に指定されたツリーマネージャ１１５１もしくは１１５２を予備用に設定し、状態１１６４２もしくは状態１１６４９に遷移する。ここでは、状態１１６４２に遷移した場合を例に解説するが、以後の解説は状態１１６４９に遷移した場合においても同様である。（図１９の状態１１６４１）
【０４４２】
　メインコントローラ１１６４βは、ツリーマネージャ１１５１を現用、ツリーマネージャ１１５２を予備用に設定する。さらに、前記各ツリーマネージャ１１５１および１１５２に対して、ＢＰＤＵ送信停止命令を出す。（図１９の状態１１６４２）
【０４４３】
　メインコントローラ１１６４βは、状態１１６４２において、もし設定インタフェース１１８よりノードの追加要求を受信した場合は、状態１１６４３に遷移する。また、もしツリーマネージャ１１５１もしくはツリーマネージャ１１５２より現用系通知を受信し、現用系と予備系の関係に変更があった場合には、状態１１６４９に遷移する。（図１９の状態１１６４２）
【０４４４】
　メインコントローラ１１６４βは、ツリーマネージャ１１５２に対してリンクｕｐの通知を行い、同時に、ツリーマネージャ１１５２に対してＢＰＤＵの送信許可を行う。さらに、安定タイマ１１６５を作動させる。（図１９の状態１１６４３）
　メインコントローラ１１６４βは、状態１１６４３において、ツリーマネージャ１１５１もしくはツリーマネージャ１１５２よりＢＰＤＵに含まれる現用系通知を受信し、もし現用系と予備系の関係に変更が生じた場合には、現用に登録されているツリーマネージャ１１５１と、予備用に登録されているツリーマネージャ１１５２を入れ替え、新しく現用をツリーマネージャ１１５２、予備用をツリーマネージャ１１５１とする。その後、安定タイマ１１６５を作動させる。（図１９の状態１１６４４）
【０４４５】
　メインコントローラ１１６４βは、安定タイマ１１６５よりタイマ満了通知を受信すると、ツリーマネージャ１１５１に対してリンクｕｐの通知を行い、同時に、ツリーマネージャ１１５２に対してＢＰＤＵの送信許可を行う。通常は、この状態で安定する。（図１９の状態１１６４５）
【０４４６】
　状態１１６４５において、もし現用であるツリーマネージャ１１５２がルートノードとなっている場合、このノードのメインコントローラ１１６４βは、安定タイマ１１６５を動作させ、安定タイマ１１６５よりタイマ満了通知を受信すると、現用に登録されているツリーマネージャ１１５２と、予備用に登録されているツリーマネージャ１１５１を入れ替え、新しく現用をツリーマネージャ１１５１、予備用をツリーマネージャ１１５２とする。さらに、ＧＶＲＰ送受信機１１６２を通じて、新ツリーのルートノードに対して、利用タググループ変更通知を送信する。この利用タググループ変更通知の内容は、ＢＰＤＵに反映され、全ノードに伝達される。（図１９の状態１１６４５）
【０４４７】
　前記ツリーマネージャの入れ替えは、予備用であるツリーマネージャ１１５１が行っても良い。この場合、状態１１６４５において、もし予備用であるツリーマネージャ１１５１がルートノードとなっている場合、ノードのメインコントローラ１１６４は、安定タイマ１１６５を動作させ、安定タイマ１１６５よりタイマ満了通知を受信すると、現用に登録されているツリーマネージャ１１５２と、予備用に登録されているツリーマネージャ１１５１を入れ替え、新しく現用をツリーマネージャ１１５１、予備用をツリーマネージャ１１５２とする。さらに、ＧＶＲＰ送受信機１１６２を通じて、旧現用ツリーのルートノードに対して、利用タググループ変更通知を送信する。この利用タググループ変更通知の内容は、ＢＰＤＵに反映され、全ノードに伝達される。（図１９の状態１１６４５）
【０４４８】
　メインコントローラ１１６４βは、状態１１６４５において、ツリーマネージャ１１５１もしくはツリーマネージャ１１５２よりＢＰＤＵに含まれる現用系通知を受信し、もし現用系と予備系の関係に変更が生じた場合には、状態１１６４６に遷移する。そして、現用に登録されているツリーマネージャ１１５２と、予備用に登録されているツリーマネージャ１１５１を入れ替え、新しく現用をツリーマネージャ１１５１、予備用をツリーマネージャ１１５２とする。（図１９の状態１１６４５）
【０４４９】
　メインコントローラ１１６４βは、状態１１６４５において、もし設定インタフェース１１８より、ノード削除要求を受信した場合は、状態１１６４４に遷移する。（図１９の状態１１６４５）
【０４５０】
　メインコントローラ１１６４βは、ツリーマネージャ１１５１に対して、接続されている全リンクリンクｄｏｗｎの通知を行い、同時に、ツリーマネージャ１１５１に対してＢＰＤＵの送信停止命令を出す。（図１９の状態１１６４４）
【０４５１】
　メインコントローラ１１６４βは、状態１１６４４において、ツリーマネージャ１１５１もしくはツリーマネージャ１１５２よりＢＰＤＵに含まれる現用系通知を受信し、もし現用系と予備系の関係に変更が生じた場合には、状態１１６４３に遷移し、現用に登録されているツリーマネージャ１１５２と、予備用に登録されているツリーマネージャ１１５１を入れ替え、新しく現用をツリーマネージャ１１５１、予備用をツリーマネージャ１１５２とする。その後、安定タイマ１１６５を作動させる。（図１９の状態１１６４３）
【０４５２】
　メインコントローラ１１６４βは、安定タイマ１１６５よりタイマ満了通知を受信すると、ツリーマネージャ１１５１に対してリンクｄｏｗｎの通知を行い、同時に、ツリーマネージャ１１５１に対してＢＰＤＵの受信停止命令を出す。さらに、無条件で状態１１６４１に遷移し、ノード切離しまで待機する。（図１９の状態１１６４２）
【０４５３】
　メインコントローラ１１６４βは、設定インタフェース１１８もしくはＧＶＲＰ送受信機１１６２より、動的なコスト計算を利用する指定を受けた場合には、利用タググループ変更通知の受信から一定時間経過後に満了となるよう、コスト参照タイマ１１６７をセットする。（図１９の状態１１６４５）
【０４５４】
　メインコントローラ１１６４βは、コスト参照タイマ１１６７からタイマ満了の通知を受信すると、リソースモニタ１１９より累積通過バイト数の情報を受信すると同時に、カウンタリセット通知を出して、リソースモニタ１１９の累積通過バイト数を０にリセットさせる。さらに、前記累積通過バイト数もしくはＴＣＰフロー数またはＨＴＴＰリクエスト数よりコストを計算し、予備系であるツリーマネージャ１１５１通知する。ツリーマネージャ１１５１は、新たに計算したコスト情報を元に、スパニングツリーを再計算し、計算の結果、トポロジに変更があるか、ないかを、メインコントローラ１１６４βに通知する。そして、無条件で状態１１６４５に遷移する。（図１９の状態１１６４Ａ）
【０４５５】
　図１４および図１５を参照して、本実施の形態において、ノード１７を追加する場合の動作について、具体例を用いて詳細に説明する。
【０４５６】
　図１４を参照すると、本動作例では、ノード１１〜１７、およびリンク２１〜３０を有する。ただし、ノード１７、リンク２９およびリンク３０は、初期状態では接続されていない。
【０４５７】
　図１５を参照すると、本動作例では、ノード１１〜１７、およびリンク２１〜３０を有する。
【０４５８】
　初期状態でノード１１〜１６の全ノード、全ポートが所属するタググループが２つすでに設定されており、１つめのタググループをタググループ４１、２つめのタググループをタググループ４２と呼ぶ。
【０４５９】
　なお、基本的には全ノード、全ポートを２つのタググループに加入させるが、一部のポートもしくはノードのみで構成させるタググループを作成しても良い。以降、全ノード、全ポートが２つのタググループに加入するものとして説明する。
【０４６０】
　ノード１１〜１６には、独立して動作するスパニングツリー回路が２つ存在し、タググループ４１上で動作するスパニングツリーをツリー５１、タググループ４２上で動作するスパニングツリーをツリー５２と呼ぶ。
【０４６１】
　スパニングツリーは必ず２系統作成するが、タググループは必ずしも２つ作成する必要は無い。前記タググループ４１のみ設定してタググループ４２を利用せず、タググループ４１上で動作するスパニングツリーをツリー５１、タググループに属さないで動作するスパニングツリーをツリー５２と呼ぶこともできる。また逆に、前記タググループ４２のみ設定してタググループ４１を利用せず、タググループに属さないで動作するスパニングツリーをツリー５１、タググループ４２上で動作するスパニングツリーをツリー５２と呼ぶこともできる。
【０４６２】
　ここでは、特にタググループ４１とタググループ４２の両方を用いた場合について説明を行うが、タググループ４１及びタググループ４２の両方を用いた場合の動作は、タググループ４１のみ、もしくはタググループ４２のみを用いた場合においても、同様に適用可能である。
【０４６３】
　図１４では、ツリー５１は太線で表され、ノード１１をルートノードとして安定しているとする。
【０４６４】
　ツリー５１のＢＰＤＵにはタググループ４１のタグが、ツリー５２のＢＰＤＵにはタググループ４２のタグがつく。
【０４６５】
　現在、クライアントからノード１１〜１６に送信されたデータには、タググループ４１のタグが付加されている。このタグが付加されたデータは、ツリー５１に沿って転送されている。
【０４６６】
　ノード１７は、リンク２９およびリンク３０と接続されると、どのタググループにも加入せず、ＢＰＤＵの受信を開始する。
【０４６７】
　ノード１７は、各タググループのＢＰＤＵを受信すると、現時点での現用系がタググループ４１で、現時点での予備系がタググループ４２であると確認する。そして、自ノードをタググループ４２にのみ参加させてＢＰＤＵの送受信を行い、タググループ４１ではＢＰＤＵは受信のみ行い、送信を行わないように設定する。
【０４６８】
　ノード１７が追加されると、タググループ４２のメンバに変更が発生するため、スパニングツリープロトコルにより、ツリー５２を更新する動作が開始される。タググループ４１のメンバには変更が無いため、ツリー５１は更新されない。
【０４６９】
　クライアントから送信されるフレームには、今までどおりタググループ４１のタグが付加され、ツリー５１に沿って転送され続ける。
【０４７０】
　現用系ツリーであるツリー５１のルートノードとなっているノード１１は、安定タイマが満了すると、ツリー５１のルートノードであるノード１１に対して利用タググループ変更通知を送信し、ツリー５１を予備系に遷移させるよう命令する。そして、タググループ４２のフラグを付け、ツリー５２のために送信するＢＰＤＵに、現用系フラグを立てる。ＢＰＤＵは、各ノードで転送されながら、全ノードに伝播する。
【０４７１】
　ノード１１は、現用系フラグの付加状況の変更を感知し、ツリー５１を予備系に遷移させ、タググループ４１のフラグを付け、ツリー５１のために送信するＢＰＤＵに、予備系フラグを立てる。ＢＰＤＵは、各ノードで転送されながら、全ノードに伝播する。
【０４７２】
　ノード１１〜１７は、タググループ４２のタグが付いたＢＰＤＵに現用系フラグが付加させたのを確認し、クライアントより転送されてくるフレームに付加するタグを、タググループ４１からタググループ４２に切り替える。このタグが付加されたフレームは、ツリー５２に沿って転送される。
【０４７３】
　以上の切り替えが完了してしばらく経つと、ツリー５１を流れるフレームはなくなる。
【０４７４】
　ノード１７は、利用タググループ変更通知の送信から一定時間経過後に、タググループ４１のタグを付加するノードが存在しなくなったと判断し、自ノードをタググループ４１に加入させ、次のトポロジ変更に備える。
【０４７５】
　以上のようにして、ネットワークを停止させることなく、ノード１７を追加することができた。以降ノードの追加の際は、同様の動作を繰り返す。ただし、上記説明文中のタググループ４１とタググループ４２は入れ替わる。
【０４７６】
　次に図７を利用して、本実施の形態において、ノード１５からノード１３への転送経路が変更される場合の、スパニングツリー切り替え動作について、具体例を用いて詳細に説明する。
【０４７７】
　図７を参照すると、本動作例では、ノード１１〜１６、クライアント９１〜９６、双方向リンク８１〜８６、および、双方向リンク２１〜２８を含む。
【０４７８】
　ノード１１にはリンク８１によりクライアント９１が、ノード１２にはリンク８２によりクライアント９２が、ノード１３にはリンク８３によりクライアント９３が、ノード１４にはリンク８４によりクライアント９４が、ノード１５にはリンク８５によりクライアント９５が、ノード１６にはリンク２６によりクライアント９６が、それぞれ接続されている。
【０４７９】
　ノード１１とノード１２の間はリンク２１で、ノード１２とノード１３の間はリンク２２で、ノード１３とノード１４の間はリンク２３で、ノード１１とノード１５の間はリンク２４で、ノード１５とノード１６の間はリンク２５で、ノード１６とノード１４の間はリンク２６で、ノード１２とノード１５の間はリンク２７で、ノード１３とノード１６の間はリンク２８で、それぞれ接続されている。
【０４８０】
　ノード１１〜１６の全ポートが所属するタググループが２つすでに設定されており、１つめのタググループをタググループ４１、２つめのタググループをタググループ４２と呼ぶ。
【０４８１】
　ノード１１〜１６には、独立して動作するスパニングツリー回路が２つ存在し、タググループ４１上で動作するスパニングツリーをツリー５１、タググループ４２上で動作するスパニングツリーをツリー５２と呼ぶ。
【０４８２】
　ツリー４１は太線で表され、ノード１３をルートノードとし、すべてのリンクに等しく１０に設定された初期コストを用いて、すでに安定しているとする。ツリー５１のＢＰＤＵにはタググループ４１のタグが、ツリー５２のＢＰＤＵにはタググループ４２のタグがつく。
【０４８３】
　現在、クライアントからノード１１〜１６に送信されたデータには、現用系であるタググループ４１のタグが付加されている。このタグが付加されたデータは、ツリー５１に沿って転送されている。
【０４８４】
　初期状態では、クライアント９１〜９６のうち、どのクライアントもデータ転送を行っていない。
【０４８５】
　各ノードは、一定時間ごとに、ＨＥＬＬＯフレームを送信し、ＢＰＤＵの状態を確認している。このフレームには、現用系と予備系の識別フラグがあり、現在は現用系であるタググループ４１のタグが付加されたＢＰＤＵのみに、現用系のフラグがつき、予備系であるタググループ４２のタグが付加されたＢＰＤＵには、現用系を示すフラグは付加されない。
【０４８６】
　各ノードは、設定インタフェース１１８もしくはＧＶＲＰ送受信機１１６２より、すでに動的なコスト計算を利用する指定を受けているため、コスト参照タイマが満了するごとに、前回のタイマ満了以降にリンクを流れたフレームの流量を参照し、コストの再計算および、予備系ツリーを用いたスパニングツリーの再計算を行う。
【０４８７】
　ここで、クライアント９５からクライアント９３、および、クライアント９６からクライアント９３との間で、データ転送を開始したとする。
【０４８８】
　転送初期においては、クライアント９５からクライアント９３へのデータは、ツリー５１を利用し、リンク８５、２５、２８、８３を経由して転送される。また、クライアント９６からクライアント９３へのデータも、ツリー５１を利用し、リンク８６、２８、８３を経由して転送される。
【０４８９】
　データ転送から一定時間が経過すると、リンク２１〜２８の空き容量をもとに、ツリー５２におけるリンク２１〜２８のコストが片側ずつ再計算される。ここで、リンク２８の空き帯域は少なくなっているため、ノード１６によりツリー５２のリンク２８のコストは１５に、リンク２５の空き帯域は、リンク２８ほどではないが少なくなっているため、ノード１５によりツリー５２のリンク２５のコストは１２に、それぞれ変更されたとする。このとき、現在使用している、ツリー５１のコストは変更されない。
【０４９０】
　ノード１６は、コスト変更を検知し、変更後のコストを利用して作成したＢＰＤＵを、隣接するノード１３、ノード１４、ノード１５に対して、それぞれ送信する。
【０４９１】
　ノード１５も同様に、コスト変更を検知し、変更後のコストを利用して作成したＢＰＤＵを、隣接するノード１１、ノード１２、ノード１６に対して、それぞれ送信する。
【０４９２】
　ノード１５は、ノード１６からコスト１５が付加されたＢＰＤＵを受信すると、リンク２５のコストも加算し、リンク２５、リンク２８経由でノード１３に到達するために、コスト２７がかかることを認識する。
【０４９３】
　その後ノード１５は、ノード１２から、コスト１０が付加されたＢＰＤＵを受信すると、リンク２７のコストも加算し、リンク２７、リンク２２経由でノード１３に到達するために、コスト２０がかかることを認識する。このコストは、リンク２５経由のコストよりも小さいため、ノード１５は停止ポートをリンク２７側からリンク２５側に切り替え、リンク２７およびリンク２２を利用して、リンク１３に到達するツリーを形成する。
【０４９４】
　ツリー５１のルートノードであるノード１３において起動していたトポロジ安定タイマが満了すると、旧現用系ツリーであるツリー４１のルートであるノード１３に対して、転送に利用する現用系ツリーをツリー５１からツリー５２に切り替えるよう命令する、タググループ変更メッセージを送信する。この利用タググループ変更通知の内容は、ノード１３から送信される、ツリー５１およびツリー５２の各ＢＰＤＵに反映され、全ノードに伝達される。
【０４９５】
　ノード１３は、旧現用系ルートノードへのタググループ変更メッセージの送信を完了させると、自ノードがクライアント９３より受信して、ネットワーク内に送信するフレームの転送に利用するツリーを、今まで利用していたツリー５１からツリー５２へ切り替える。切り替えが完了すると、クライアント９３からクライアント９５に向けて送信されていたフレームは、リンク８３、リンク２２、リンク２７、リンク８５を経由して、クライアント９５に転送されるようになる。
【０４９６】
　このようにして、クライアント９３からクライアント９５、および、クライアント９３からクライアント９６に向けて送信されるフレームの転送経路は分散され、リンク２８の混雑が解消される。
【０４９７】
　以降、コスト参照タイマが満了するごとに、リンクの空き帯域に基づくコスト計算によってスパニングツリーが再計算され、周期的に空き帯域をコストに反映する動的な経路変更が行われる。この結果、各リンクのトラフィックが分散され、リンクの負荷を分散し、輻輳を防止することができる。
【０４９８】
　次に、本実施の形態の効果について説明する。
【０４９９】
　従来、リンク容量を用いてコストを計算し、スパニングツリー構築時の経路選択に利用しているため、トラフィックに応じた動的な負荷分散のための経路変更ができなかった。
【０５００】
　本実施の形態では、リンクコストを、空き帯域やサーバ負荷等の動的情報によって計算することにより、トラフィックの負荷分散が可能である。
【０５０１】
　また従来、コストをトラフィック状況に応じて動的に変化させるたびに、局所的もしくはネットワーク全体で、データフレームの転送を停止させてスパニングツリーを構築しなおして経路を変更するため、再構築中にネットワークが停止する場合があった。
【０５０２】
　本実施の形態では、変更前のツリーを運用したまま、コスト変更後のツリーを生成し、新規ツリーの安定後に利用するツリーを切り替えることにより、経路変更にともなうスパニングツリー再構成のために、ネットワークを停止させることなく負荷分散が可能である。
またこの結果、輻輳発生の可能性を下げることが可能である。
【０５０３】
（第４の実施の形態）
　以下、本発明の第４の実施の形態について、図面を参照して詳細に説明する。
【０５０４】
　本発明の第４の実施の形態は、第１の実施の形態において、宛先ノード別に利用するタグおよびスパニングツリーを切り替え、さらに、宛先のノードをルートノードに設定する場合に対応する。
【０５０５】
　ＩＥＥＥ８０２．１ＤおよびＩＥＥＥ８０２．１ｗが動作しているネットワークにおいてフレームを送信した場合、宛先への最低コスト経路が必ずしも選択されるとは限らず、使用されないリンクが出現するほか、ルートノードに負荷が集中する、ルートノード障害時に長時間ネットワークが停止するなどの問題があった。
【０５０６】
　本実施の形態においては、宛先がルートノードとなるツリーを用いてフレームを転送することで、宛先への最低コストによるフレーム伝送のほか、リンク利用率の向上、さらにはルートノード障害への耐性強化を行う。
【０５０７】
　図２０を参照すると、本発明の第４の実施の形態は、第１の実施の形態における図８において、ツリーマネージャ１１５１が、ネットワークに存在するノードの数だけ設置されている点において異なる。
【０５０８】
　ツリーマネージャ１１５１は、本発明の第１の実施の形態における図８に示すツリーマネージャ１１５１と同様の機能を有する。
【０５０９】
　ツリーマネージャ１１５２および、ツリーマネージャ１１５３は、ツリーマネージャ１１５１と同様のツリーマネージャである。以後、ツリーマネージャ１１５１〜ツリーマネージャ１１５３を代表してツリーマネージャ１１５１を用いて記述を行うが、ツリーマネージャ１１５１についての記述は、特に断りのない限りツリーマネージャ１１５２〜ツリーマネージャ１１５３においても同様に適用可能である。
【０５１０】
　ツリーマネージャはツリーセレクタ１１６によって、ネットワーク内に存在するノードの数、もしくは、サブネット等を区切り階層化している場合は、同一階層内に存在するノードの数だけ作成される。したがって、ツリーマネージャは、１個以上無限大まで増える可能性があるが、図２０においては前記ツリーマネージャを、ツリーマネージャ１１５１〜１１５３としてまとめて表現する。
【０５１１】
　図２０のツリーセレクタ１１６は、本発明の第１の実施の形態における図８に示すツリーセレクタ１１６の機能のほか、ネットワークもしくは階層内に新規ノードの存在を検出した場合に、新規のツリーマネージャを生成する機能を有する。また、前記新規ノードの検出を、他のノードに対して通知する機能、および、他のノードから新規ノードの検出通知を受信し、ツリーマネージャを生成する機能を有する。さらに、ノードの削除を検出して、ツリーマネージャを削除する機能、前記削除ノードの検出を他のノードに対して通知する機能、および、他のノードからノードの削除通知を受信し、ツリーマネージャを削除する機能を有する。
【０５１２】
　図２１は、本実施の形態の図２０における、タグをキーとして出力ポートを決定する、フォワーディングテーブル１１４の構成例である。
【０５１３】
　タグフィールド１１４１は、サーチのインデックスになるフィールドであり、このフィールドの情報と、受信したフレームのタグに書かれている内容が一致するかどうかを調べる。
【０５１４】
　出力ポート１１４２は、受信したフレームのタグに書かれている内容とタグにフィールド１１４１の内容が一致した場合に、前記フレームをどのポートに転送すべきか記述するフィールドである。
【０５１５】
　なお、本実施の形態は、本動作例に示すような、タグの内容によって転送先ポートを決定するタグフォワーディングを行う場合のみならず、従来より行われている、ＭＡＣアドレスによって転送先を決定する通常のＭＡＣアドレス転送においても、同様に適用可能である。この場合は、出力ポートフィールド１１４２に、対応するＭＡＣアドレスに対応する複数のポートが記載される場合もある。
【０５１６】
　図２２は、本実施の形態の図２０における、宛先ＭＡＣアドレスをキーとして挿入するタグを決定する、タグテーブル１１７の構成例である。
【０５１７】
　宛先ＭＡＣアドレス１１７１は、サーチのインデックスになるフィールドであり、このフィールドの情報と、受信したフレームの宛先ＭＡＣアドレスフィールド、すなわち、ＭＡＣ　ＤＡフィールドに書かれている内容が一致するかどうか調べ、一致した場合には、前記受信フレームに対して、挿入タグフィールド１１７２に記載のタグを挿入する。
【０５１８】
　挿入タグフィールド１１７２は、宛先ＭＡＣアドレスフィールド１１７１に対する、挿入すべきタグが記載されるフィールドである。本実施例では、宛先ノードＩＤが記載されており、このＩＤが、タグとしてフレームに挿入される。
【０５１９】
　図２３は、ノード１１をルートノードとするスパニングツリーの構成図である、ツリー６１の構成図である。ツリー６１は、ノード１１のプライオリティ値を、ノード１２〜ノード１６の各ノードよりも小さい値に設定して作成される。ツリー６１は、ノード１１に向かうフレームの送信および、ノード１１よりノード１２〜ノード１６の各ノードに対して、ブロードキャストフレームを送信する場合に利用される。
【０５２０】
　図２４は、ノード１２をルートノードとするスパニングツリーの構成図である、ツリー６２の構成図である。ツリー６２は、ノード１２のプライオリティ値を、ノード１１およびノード１３〜ノード１６の各ノードよりも小さい値に設定して作成される。ツリー６２は、ノード１２に向かうフレームの送信および、ノード１２よりノード１１およびノード１３〜ノード１６の各ノードに対して、ブロードキャストフレームを送信する場合に利用される。
【０５２１】
　図２５は、ノード１３をルートノードとするスパニングツリーの構成図である、ツリー６３の構成図である。ツリー６３は、ノード１３のプライオリティ値を、ノード１１〜ノード１２およびノード１４〜ノード１６の各ノードよりも小さい値に設定して作成される。ツリー６３は、ノード１３に向かうフレームの送信および、ノード１３よりノード１１〜ノード１２およびノード１４〜ノード１６の各ノードに対して、ブロードキャストフレームを送信する場合に利用される。
【０５２２】
　図２６は、ノード１４をルートノードとするスパニングツリーの構成図である、ツリー６４の構成図である。ツリー６４は、ノード１４のプライオリティ値を、ノード１１〜ノード１３およびノード１５〜ノード１６の各ノードよりも小さい値に設定して作成される。ツリー６４は、ノード１４に向かうフレームの送信および、ノード１４よりノード１１〜ノード１３およびノード１５〜ノード１６の各ノードに対して、ブロードキャストフレームを送信する場合に利用される。
【０５２３】
　図２７は、ノード１５をルートノードとするスパニングツリーの構成図である、ツリー６５の構成図である。ツリー６５は、ノード１５のプライオリティ値を、ノード１１〜ノード１４およびノード１６の各ノードよりも小さい値に設定して作成される。ツリー６５は、ノード１５に向かうフレームの送信および、ノード１５よりノード１１〜ノード１４およびノード１６の各ノードに対して、ブロードキャストフレームを送信する場合に利用される。
【０５２４】
　図２８は、ノード１６をルートノードとするスパニングツリーの構成図である、ツリー６６の構成図である。ツリー６６は、ノード１６のプライオリティ値を、ノード１１〜ノード１５よりも小さい値に設定して作成される。ツリー６６は、ノード１６に向かうフレームの送信および、ノード１６よりノード１１〜ノード１５の各ノードに対して、ブロードキャストフレームを送信する場合に利用される。
【０５２５】
　次に、図２３〜図２８を利用して、ノード１３が、ノード１１〜１２およびノード１４〜１６ですでに構成されているネットワークに、新たに追加された場合の、ツリー６３の作成動作について説明する。
【０５２６】
　前記ネットワークにノード１３が追加されると、ノード１３は隣接ノードより送信されるＢＰＤＵフレームを受信して、新たに検出した識別タグごとにツリーマネージャを生成する。この例では、ノード１１〜１２およびノード１４〜１６の各ノードをルートノードとする、５個のツリーマネージャが生成される。
【０５２７】
　次に、ノード１３は、ノードＩＤよりタグＩＤを生成し、自ノードのプライオリティ値を低く設定したツリーマネージャを生成し、そのツリーマネージャから出力されるＢＰＤＵフレームに対して、前記タグＩＤを付加して送信する。ここで、タグＩＤは４３であったとする。
【０５２８】
　ノード１２およびノード１６は、タグＩＤが４３のＢＰＤＵを新たに受信し、ツリーマネージャを生成してから、タグＩＤ４３を付加したＢＰＤＵを隣接ノードに対して送信する。
【０５２９】
　以上のＢＰＤＵ送信動作が繰り返されることにより、ツリー６３が完成する。
【０５３０】
　次に、図２３〜図２８を参照して、前記の各図におけるノード１１〜ノード１６の各ノードが、ノード１１〜ノード１６の各ノードにフレームを送信する場合の手順について述べ、送信したフレームが最低コスト経路で宛先へ届けられること、並びに、リンク資源の負荷分散が行われていることを示す。なお、各リンクのコストは等しく、すでに各図におけるツリー６１〜ツリー６６の各ツリーは構成が完了し、トポロジが安定しているとする。
【０５３１】
　ノード１２〜ノード１６の各ノードから、ノード１１へフレームを送信する場合は、ツリー６１を使用する。例えば、ノード１５からノード１１へフレームを送信する場合は、ノード１５は、データフレームにツリー６１の識別タグであるタグＩＤ４１を付加して送信する。
【０５３２】
　ノード１１およびノード１３〜ノード１６の各ノードから、ノード１２へフレームを送信する場合は、ツリー６２を使用する。例えば、ノード１４からノード１２へフレームを送信する場合は、ノード１４は、データフレームにツリー６２の識別タグであるタグＩＤ４２を付加して送信する。
【０５３３】
　ノード１１〜ノード１２およびノード１４〜ノード１６の各ノードから、ノード１３へフレームを送信する場合は、ツリー６３を使用する。例えば、ノード１１からノード１３へフレームを送信する場合は、ノード１１は、データフレームにツリー６３の識別タグであるタグＩＤ４３を付加して送信する。
【０５３４】
　ノード１１〜ノード１３およびノード１５〜ノード１６の各ノードから、ノード１４へフレームを送信する場合は、ツリー６４を使用する。例えば、ノード１２からノード１４へフレームを送信する場合は、ノード１２は、データフレームにツリー６４の識別タグであるタグＩＤ４４を付加して送信する。
【０５３５】
　ノード１１〜ノード１４およびノード１６の各ノードから、ノード１５へフレームを送信する場合は、ツリー６５を使用する。例えば、ノード１６からノード１５へフレームを送信する場合は、ノード１６は、データフレームにツリー６５の識別タグであるタグＩＤ４５を付加して送信する。
【０５３６】
　ノード１１〜ノード１５の各ノードから、ノード１６へフレームを送信する場合は、ツリー６６を使用する。例えば、ノード１４からノード１６へフレームを送信する場合は、ノード１４は、データフレームにツリー６６の識別タグであるタグＩＤ４６を付加して送信する。
【０５３７】
　ノード１１が、フレームをネットワーク内の全ノードにブロードキャスト送信する場合は、ツリー６１を使用する。例えば、ノード１１は、宛先がブロードキャストとなるデータフレームに対して、ツリー６１の識別タグであるタグＩＤ４１を付加して送信する。
【０５３８】
　ノード１２が、フレームをネットワーク内の全ノードにブロードキャスト送信する場合は、ツリー６２を使用する。例えば、ノード１２は、宛先がブロードキャストとなるデータフレームに対して、ツリー６２の識別タグであるタグＩＤ４２を付加して送信する。
【０５３９】
　ノード１３が、フレームをネットワーク内の全ノードにブロードキャスト送信する場合は、ツリー６３を使用する。例えば、ノード１３は、宛先がブロードキャストとなるデータフレームに対して、ツリー６３の識別タグであるタグＩＤ４３を付加して送信する。
【０５４０】
　ノード１４が、フレームをネットワーク内の全ノードにブロードキャスト送信する場合は、ツリー６４を使用する。例えば、ノード１４は、宛先がブロードキャストとなるデータフレームに対して、ツリー６４の識別タグであるタグＩＤ４４を付加して送信する。
【０５４１】
　ノード１５が、フレームをネットワーク内の全ノードにブロードキャスト送信する場合は、ツリー６５を使用する。例えば、ノード１５は、宛先がブロードキャストとなるデータフレームに対して、ツリー６５の識別タグであるタグＩＤ４５を付加して送信する。
【０５４２】
　ノード１６が、フレームをネットワーク内の全ノードにブロードキャスト送信する場合は、ツリー６６を使用する。例えば、ノード１６は、宛先がブロードキャストとなるデータフレームに対して、ツリー６６の識別タグであるタグＩＤ４６を付加して送信する。
【０５４３】
　以上に示す方法で送信時タグを付加してデータフレームを転送することで、前記データフレームを最低コスト経路で転送することができる。また、ルートノードが異なる複数のツリーを利用してフレームを転送するため、従来技術１および従来技術２に示したスパニングツリーのように、ルートノード付近にトラフィックが集中し、ルートノードから遠ざかるほどリンクの使用率が減るという現象が発生せず、トラフィックの付加を分散できることがわかる。
【０５４４】
　次に、図２３〜図２８において、ノードに障害が発生した場合の動作について、ノード１２に障害が発生した場合を例にして説明する。なお、最初の状態では、ツリー６１〜ツリー６６は、すでに構築されて安定しているとする。
【０５４５】
　ツリー６１は、ノード１２が障害によって停止すると、ＩＥＥＥ８０２．１ｗで規定されるラピッドスパニングツリー方式により、ノード１３からノード１１へのルートとして、リンク２５、リンク２７、リンク２６、リンク２３を経由するルートが選ばれ、ノード１１へのフレーム及び、ノード１１から各ノードへブロードキャストされるフレームの転送が継続される。
【０５４６】
　ツリー６２は、ノード１２が障害によって停止すると、ノード１２がルートノードであるので、ツリーを再構成しなくてはならない。ノード１２以外の別のノードがルートノードとなり、ノード１２の回復前にツリー６２の再構成が行われる。この再構成には、ＩＥＥＥ８０２．１Ｄでは数十秒、ＩＥＥＥ８０２．１ｗでは数秒間かかるが、そもそもツリー６２は、各ノードからルート１２へ向けて送信されるフレーム、および、ルート１２から各ノードに向けてブロードキャスト送信されるフレームのためのツリーなので、再構成に時間がかかっても、ノード１２以外の他のノード間で行われる通信には影響を与えない。
【０５４７】
　ツリー６３は、ノード１２が障害によって停止すると、ＩＥＥＥ８０２．１ｗで規定されるラピッドスパニングツリー方式により、ノード１１からノード１３へのルートとして、リンク２３、リンク２６、リンク２７、リンク２５を経由するルートが選ばれ、ノード１３へのフレーム及び、ノード１３から各ノードへブロードキャストされるフレームの転送が継続される。
【０５４８】
　ツリー６４は、ノード１２が障害によって停止すると、ＩＥＥＥ８０２．１ｗで規定されるラピッドスパニングツリー方式により、ツリーが再構成され、各ノードからノード１４へ送信されるフレーム及び、ノード１４から各ノードへブロードキャストされるフレームの転送が継続される。
【０５４９】
　ツリー６５は、ノード１２が障害によって停止すると、ＩＥＥＥ８０２．１ｗで規定されるラピッドスパニングツリー方式により、ツリーが再構成され、各ノードからノード１５へのフレーム及び、ノード１５から各ノードへブロードキャストされるフレームの転送が継続される。
【０５５０】
　ツリー６６は、ノード１２が障害によって停止すると、ＩＥＥＥ８０２．１ｗで規定されるラピッドスパニングツリー方式により、ノード１１からノード１６へのルートとして、リンク２３、リンク２６、リンク２７を経由するルートが選ばれ、ノード１６へのフレーム及び、ノード１６から各ノードへブロードキャストされるフレームの転送が継続される。
【０５５１】
　次に、図２９と図３０を参照して、第１の実施の形態の図７におけるクライアントの一部が、デュアルホーミングによって、複数のノードと接続されている場合の、スパニングツリーの構成方法について述べる。
【０５５２】
　図２９において、クライアント９７は、１つ以上のクライアントの集合であり、リンク８７およびリンク８８を通じて、ノード１１およびノード１６との間でフレームの送受信を行う機能を有する。
【０５５３】
　リンク８７は、クライアント９７からノード１５、及び、ノード１５からクライアント９７を結ぶ双方向リンクである。
【０５５４】
　リンク８８は、クライアント９７からノード１６、及び、ノード１６からクライアント９７を結ぶ双方向リンクである。
【０５５５】
　図２９におけるクライアント９７のように、複数のノードと接続されたクライアント群が存在する場合は、前記クライアントを仮想的なノードとみなして、スパニングツリーの設定を行う。
【０５５６】
　図３０は、図２９において、クライアント９７を仮想ノード１８と見立てた場合のネットワーク構成図である。
【０５５７】
　スパニングツリー７４は、ノード１８をルートノードとするスパニングツリーである。ノード１１〜ノード１６の各ノードから、ノード１８へ送信されたフレームは、スパニングツリー７４を利用してノード１８、つまりクライアント９７に到着する。また、クライアント９７、すなわちノード１８から送信されたブロードキャストフレームも、スパニングツリー７４に沿って、ノード１１〜ノード１６の各ノードにブロードキャストされる。
【０５５８】
　なお、ノード１８は仮想的なノードであり、ノード１８の実際の動作は、ノード１５もしくは１６が代行して行う。ノード１５とノード１６のどちらがノード１８の動作を代行するかは、設定インタフェース１１８による手動設定のほか、ノードＩＤの小さい方に自動設定、ノードＩＤの大きい方に自動設定するなどの方法で決定される。
【０５５９】
　次に、図２９を参照して、クライアント９７が、リンク８７およびリンク８８を通じて、ノード１５およびノード１６とデュアルホーミング接続されている場合において、仮想ノードを設置することなく通信を行う方法について説明する。
【０５６０】
　図２９において、ノード１５およびノード１６は、設定インタフェースでの設定、もしくは、ラーニングによって、クライアント９７が複数のノードに接続されていることを検知する。ノード１５は、ノード１６にクライアント９７が接続されていることを検知する。ノード１６は、ノード１５にクライアント９７が接続されていることを検知する。
【０５６１】
　ノード１５およびノード１６は、相互で制御メッセージの交換を行い、クライアント９７へのフレームを、ノード１５もしくはノード１６のどちらが転送するかを決定する。この転送ノードは、ノードＩＤの小さいノード、ノードＩＤの大きいノード、もしくは、設定で定められたノード等に決定される。
【０５６２】
　転送ノードが決定すると、クライアント９７はノード１６のみに接続されているとみなされ、フレーム転送が開始される。ノード１１〜ノード１６は、クライアント９７がノード１６に接続されていると学習等で認識し、クライアント９７宛のフレームを、ノード１６をルートノードとするツリーの識別タグを付加して送信する。
【０５６３】
　ノード１５およびノード１６は、常にKeep Alive等により相互に状況を監視しあう。もし、ノード１５がノード１６の動作を確認できないときは、ノード１５はクライアント９７からのフレームを、ノード１１〜１６に転送するようになる。すると、ノード１１〜ノード１６は、クライアント９７から送信されたフレームに、ノードＩＤとして１５が付加されていることを学習し、クライアント９７宛のフレームをノード１５に向けて送信するようになる。
【０５６４】
　以上の動作により、クライアント９７は、フレームを送受信することができる。以上の動作は、ノード１５とノード１６が入れ替わった場合においても、同様に適用可能である。
【０５６５】
　次に、図２９を参照して、クライアント９７が、リンク８７およびリンク８８を通じて、ノード１５およびノード１６とデュアルホーミング接続されている場合において、仮想ノードを設置することなく通信を行い、また、障害検出ノードがネットワーク内の全ノードに対して切替通知を送信することで、クライアント９７の接続先が変更されたことを高速に通知する方法について説明する。
【０５６６】
　図２９において、ノード１５およびノード１６は、設定インタフェース１１８での設定、もしくは、ラーニングによって、クライアント９７が複数のノードに接続されていることを検知する。ノード１５は、ノード１６にクライアント９７が接続されていることを検知する。ノード１６は、ノード１５にクライアント９７が接続されていることを検知する。
【０５６７】
　ノード１５およびノード１６は、相互で制御メッセージの交換を行い、クライアント９７へのフレームを、ノード１５もしくはノード１６のどちらが転送するかを決定する。この転送ノードは、ノードＩＤの小さいノード、ノードＩＤの大きいノード、もしくは、設定で定められたノード等に決定される。
【０５６８】
　転送ノードが決定すると、クライアント９７はノード１６のみに接続されているとみなされ、フレーム転送が開始される。ノード１１〜ノード１６は、クライアント９７がノード１６に接続されていると学習等で認識し、クライアント９７宛のフレームを、ノード１６をルートノードとするツリーの識別タグを付加して送信する。
【０５６９】
　ノード１５およびノード１６は、常にKeep Alive等により相互に状況を監視しあう。もし、ノード１５がノード１６の動作を確認できないときは、ノード１５はクライアント９７からのフレームを、ノード１１〜１６に転送するようになる。さらに、ノード１５は、クライアント９７宛のフレーム転送を、ノード１６に代わってノード１５が受け持つようになったことを、ネットワーク内の全ノードに通知する。
【０５７０】
　ノード１１〜ノード１６は、前記通知を受け取り、クライアント９７宛てのフレームに対してノード１５宛のタグを挿入し、クライアント９７宛のフレームをノード１５に向けて送信するようになる。
【０５７１】
　以上の動作により、クライアント９７は、フレームを送受信することができる。以上の動作は、ノード１５とノード１６が入れ替わった場合においても、同様に適用可能である。
【０５７２】
　次に、本実施の形態の効果について説明する。
【０５７３】
　従来、宛先への最低コスト経路が必ずしも選択されるとは限らなかった。
【０５７４】
　本実施の形態では、宛先がルートノードとなるツリーを用いてフレームを転送することにより、宛先への最低コスト経路を選択することができる。
【０５７５】
　また従来、リンク利用率が低い一方、ルートノード付近に負荷が集中するという問題があった。
【０５７６】
　本実施の形態では、ルートノードの異なるスパニングツリーを複数系統設定することにより、リンク利用率を高め、ルートノード付近に負荷を集中させずに分散させることが可能である。
【０５７７】
　さらに従来、ルートノード障害時のツリー構築に時間がかかり、その間ネットワークが停止するという問題があった。
【０５７８】
　本実施の形態では、宛先がルートノードとなるツリーを用いてフレームを転送することにより、ルートノードが宛先となるフレーム以外のフレームが、ルートノード障害の影響により長時間転送不能となることがないため、ルートノード障害によるネットワーク停止を回避可能である。
【０５７９】
　またこの結果、輻輳発生の可能性を下げることが可能である。
【０５８０】
（第５の実施の形態）
　以下、本発明の第５の実施の形態について、図面を参照して詳細に説明する。
【０５８１】
　本発明の第５の実施の形態は、第１の実施の形態において、ＢＰＤＵのバージョンを識別し、低速なＩＥＥＥ８０２．１Ｄすなわち従来技術１を用いている区間についてはコストを大きく設定し、高速なＩＥＥＥ８０２．１ｗすなわち従来技術２を用いている区間についてはコストを小さく設定したスパニングツリーを生成する場合に対応する。
【０５８２】
　ＩＥＥＥ８０２．１Ｄを利用する区間は、障害時のルート切り替えが遅く、スパニングツリーの再構成にも時間がかかるため、この区間を通過するようなツリーを設定すると、障害発生時やルート変更に時間がかかり、輻輳が発生してフレームが欠落する問題があった。
【０５８３】
　本実施の形態においては、ＩＥＥＥ８０２．１Ｄ利用区間のコストを大きく設定することで、スパニングツリーがＩＥＥＥ８０２．１Ｄ利用区間を通過して設定されるのを防ぎ、障害時の切替やルート変更を高速化し、輻輳の発生やフレームの欠落を防止する。
【０５８４】
　図３１を参照すると、本発明の第５の実施の形態は、第１の実施の形態における図１０において、コスト操作器１１５１６が追加されている点において異なる。
【０５８５】
　ツリーコントローラ１１５１４は、本発明の第１の実施の形態におけるツリーコントローラ１１５１４の動作のほかに、受信したＢＰＤＵのバージョンを判別し、もし設定されたバージョンより低いバージョンのＢＰＤＵが到着した場合は、前記ＢＰＤＵを送信したノードが接続されているリンクのコストを、コスト操作器１１５１６によって再設定し、ツリーテーブル１１５１５に書き込む。なおこの動作は、ツリーセレクタ１１６よりコスト変更の通知を受信するごとに、１度のみ行う。
【０５８６】
　コスト操作器１１５１６は、ツリーコントローラ１１５１４より入力された値に、あらかじめ設定された値を加算し、ツリーコントローラ１１５１４に返答する。
【０５８７】
　ツリーコントローラ１１５１４は、ＢＰＤＵ送受信機１１５１２よりをＢＰＤＵ受信通知を受けると、通知の内容に従ってツリーテーブル１１５１５に値を設定していく。ＰＤＵ受信通知には、受信したＢＰＤＵのバージョンおよび受信ポートに関する情報も含まれ、前記情報もツリーテーブル１１５１５において保持される。
【０５８８】
　ツリーコントローラ１１５１４は、ツリーセレクタ１１６より、コスト情報が通知されると、通知された情報に従ってテーブルにコスト値を設定する。このとき、あらかじめ設定されたバージョンより古いバージョンのＢＰＤＵを受信したポートに対してコストを設定する場合は、ツリーセレクタ１１６より通知されたコストをコスト操作器１１５１６に通知する。
【０５８９】
　コスト操作器１１５１６は、ツリーコントローラ１１５１４より入力された値に、あらかじめ設定された値を加算し、ツリーコントローラ１１５１４に返答する。
【０５９０】
　ツリーコントローラ１１５１４は、コスト操作器１１５１６より返答されたコストを、該当ポートのコストとして、ツリーテーブル１１５１５に通知する。
【０５９１】
　ツリーコントローラ１１５１４は、すべてのポートに対するコスト更新が完了した後で、スパニングツリーアルゴリズムにしたがってツリーを再構成する。
【０５９２】
　次に、図３２〜図３４を参照して、本実施の形態におけるスパニングツリー作成動作について述べる。
【０５９３】
　図３２〜図３４において、ノード１２がＩＥＥＥ８０２．１ｗ非対応のノードであり、ＩＥＥＥ８０２．１Ｄにのみ対応するとする。ノード１２以外のノード、すなわち、ノード１１、ノード１３、ノード１４、ノード１５およびノード１６は、ＩＥＥＥ８０２．１ｗに対応するとする。
【０５９４】
　ノード１１、ノード１５、ノード１３の各ノードは、ノード１２から送信されるＢＰＤＵフレーム内のバージョン情報もしくはプロトコルＩＤにより、ノード１２が８０２．１Ｄのみに対応するノードであると認識する。
【０５９５】
　ノード１１、ノード１５、ノード１３の各ノードは、リンク２１、リンク２２およびリンク２４の各リンクのコストを、他のリンクのコストよりも十分大きく設定する。ここでは、リンク２１、リンク２２、リンク２４のコストが１０に設定され、他のリンク、すなわち、リンク２３、リンク２６、リンク２７、リンク２５のコストが１に設定されるとする。
【０５９６】
　図３２は、前記コスト設定の状態において、ノード１１もしくはノード１４がルートノードとなる場合の、スパニングツリーの構成図である。
【０５９７】
　図３３は、前記コスト設定の状態において、ノード１５、ノード１６もしくはノード１４がルートノードとなる場合の、スパニングツリーの構成図である。
【０５９８】
　図３４は、前記コスト設定の状態において、ノード１３もしくはノード１６がルートノードとなる場合の、スパニングツリーの構成図である。
【０５９９】
　図３２〜図３４に示すように、本実施の形態では、障害回復に時間がかかるＩＥＥＥ８０２．１Ｄ利用区間を避けるようにしてツリーを構成することが可能であり、障害時にネットワーク全体が受ける影響を小さくし、高速な障害回復ができる。
【０６００】
　次に、本実施の形態の効果について説明する。
【０６０１】
　従来、ＩＥＥＥ８０２．１Ｄを利用する区間は、障害時のルート切り替えが遅く、スパニングツリーの再構成にも時間がかかった。
【０６０２】
　本実施の形態では、ＩＥＥＥ８０２．１Ｄ利用区間のコストを大きく設定することにより、スパニングツリーがＩＥＥＥ８０２．１Ｄ利用区間を通過して設定されるのを防ぎ、障害時の切替やルート変更を高速化し、輻輳発生の可能性やフレームの欠落の可能性を低下させることができる。
【０６０３】
（第６の実施の形態）
　以下、本発明の第６の実施の形態について、図面を参照して詳細に説明する。
【０６０４】
　本発明の第６の実施の形態は、第１の実施の形態において、分別器がＢＰＤＵのバージョンを識別し、ツリーセレクタを通じて、ツリーマネージャを低速なＩＥＥＥ８０２．１Ｄ利用区間の数だけ作成することで、ＩＥＥＥ８０２．１Ｄ利用区間で障害が発生した場合に、前記区間を迂回する経路を高速に提供する場合に対応する。
【０６０５】
　ＩＥＥＥ８０２．１Ｄを利用する区間は、障害時のルート切り替えが遅く、スパニングツリーの再構成にも時間がかかるため、この区間において障害が発生すると、障害発生時やルート変更に時間がかかり、輻輳が発生してフレームが欠落する問題があった。
【０６０６】
　本実施の形態においては、ＩＥＥＥ８０２．１Ｄ利用区間の数だけツリーマネージャを作成し、相異なる１つのＩＥＥＥ８０２．１Ｄ利用区間のコストを大きく設定したツリーをＩＥＥＥ８０２．１Ｄ利用区間分作成し、障害等により前記区間を迂回する必要が生じた場合は、前記区間に対して大きなコストを振ったツリーを利用することで、迂回操作を高速に行い、輻輳の発生やフレームの欠落を防止できる。
【０６０７】
　図３５を参照すると、本発明の第６の実施の形態は、本発明の第１の実施の形態における図８において、ツリーマネージャ１１５１がＩＥＥＥ８０２．１Ｄ利用区間の数だけ存在する点において異なる。
【０６０８】
　ツリーマネージャ１１５１は、本発明の第１の実施の形態における図８に示すツリーマネージャ１１５１の機能のほか、受信したＢＰＤＵフレームが、バージョンフィールドもしくはその他の手段によりＩＥＥＥ８０２．１Ｄに準拠したＢＰＤＵフレームであると確認できた場合は、ツリーセレクタ１１６に対して、前記ＢＰＤＵフレームに対して８０２．１Ｄフレーム受信通知を送信する。８０２．１Ｄフレーム受信通知には、８０２．１Ｄ準拠のＢＰＤＵフレームを送信したノードのノードＩＤが記入される。
【０６０９】
　ツリーマネージャ１１５２および、ツリーマネージャ１１５３は、ツリーマネージャ１１５１と同様のツリーマネージャである。以後、ツリーマネージャ１１５１〜ツリーマネージャ１１５３を代表してツリーマネージャ１１５１を用いて記述を行うが、ツリーマネージャ１１５１についての記述は、特に断りのない限りツリーマネージャ１１５２〜ツリーマネージャ１１５３においても同様に適用可能である。
【０６１０】
　ツリーマネージャはツリーセレクタ１１６によってＩＥＥＥ８０２．１Ｄ利用区間の数だけ作成される。したがって、ツリーマネージャは、１個以上無限大まで増える可能性があるが、図３５においては前記ツリーマネージャを、ツリーマネージャ１１５１〜１１５３としてまとめて表現する。
【０６１１】
　ツリーセレクタ１１６は、本発明の第１の実施の形態における図８に示すツリーセレクタ１１６の機能のほか、ツリーマネージャ１１５１〜ツリーマネージャ１１５３の何れかのツリーマネージャより８０２．１Ｄフレーム受信通知を受けた場合は、新規のツリーマネージャを生成する機能、８０２．１１Ｄ利用ノードをネットワーク内の他のノードに通知する機能、および、他のノードより送信された、８０２．１Ｄ利用ノードの通知に基づき、ツリーマネージャを生成する機能を有する。
【０６１２】
　ツリーセレクタ１１６は、前記機能のほか、８０２．１Ｄ利用ノードがバージョンアップ等の何らかの原因により８０２．１ｗが利用可能になったことを検知し、ツリーマネージャを削除する機能、そして、前記削除に関する情報を、ネットワーク内の他のノードに伝達する機能、および、他のノードより通知された前記削除情報に基づき、ツリーマネージャを削除する機能を有する。
【０６１３】
　図３６は、ノード１１をルートノードとし、ＩＥＥＥ８０２．１ｗの通常の手順によって作成される、ツリー６７の構成図である。
【０６１４】
　図３７は、ノード１１をルートノードとし、ツリー２１のコストを大きくして作成される、ツリー６８の構成図である。このツリーは、リンク２１に障害が発生した際にも利用される。
【０６１５】
　図３８は、ノード１１をルートノードとし、ツリー２２のコストを大きくして作成される、ツリー６９の構成図である。このツリーは、リンク２２に障害が発生した際にも利用される。
【０６１６】
　図３９は、ノード１１をルートノードとし、ツリー２４のコストを大きくして作成される、ツリー７０の構成図である。このツリーは、リンク２４に障害が発生した際にも利用される。
【０６１７】
　次に、図３６〜図３９を参照して、図３６〜図３９におけるノード１２がＩＥＥＥ８０２．１ｗ未対応のノードであり、リンク２１とリンク２２とリンク２４において、ＩＥＥＥ８０２．１Ｄが利用されている場合の動作について述べる。なお、ルートノードは、ノード１１とする。
【０６１８】
　まず、ＩＥＥＥ８０２．１ｗに従った通常の手順によって、図３６に示すスパニングツリー６７が形成される。このとき、ノード１２は８０２．１ｗ未対応のノードであるため、ノード１２からは、ＩＥＥＥ８０２．１ＤのプロトコルＩＤが付加されたＢＰＤＵフレームが送信される。
【０６１９】
　ノード１１は、ノード１２よりＩＥＥＥ８０２．１ＤのプロトコルＩＤが付加されたＢＰＤＵを受信すると、新規のツリーマネージャを生成して、前記ツリーマネージャに対して、リンクＩＤおよびノードＩＤ等から算出する固有のタグＩＤを割り当て、ＧＶＲＰフレームもしくはその他のフレームによって、全ノードに対して新規グループの作成をブロードキャスト通知する。ここでは新規のタグＩＤとして、タグＩＤ４８が割り当てられたとする。このとき、リンク２１のコストは大きく設定する。
【０６２０】
　ノード１２〜ノード１６は、ノード１１より送信された新規グループ作成通知を受信転送し、ツリーマネージャを生成してＢＰＤＵの交換を開始する。新規に作成されたツリーマネージャの間で交換されるＢＰＤＵには、タグＩＤ４８のタグが付加される。ここで作成されるスパニングツリーを、ツリー６８とする。
【０６２１】
　ノード１３は、ノード１２よりＩＥＥＥ８０２．１ＤのプロトコルＩＤが付加されたＢＰＤＵを受信すると、新規のツリーマネージャを生成して、前記ツリーマネージャに対して、リンクＩＤおよびノードＩＤ等から算出する固有のタグＩＤを割り当て、ＧＶＲＰフレームもしくはその他のフレームによって、全ノードに対して新規グループの作成をブロードキャスト通知する。ここでは新規のタグＩＤとして、タグＩＤ４９が割り当てられたとする。このとき、リンク２２のコストは大きく設定する。
【０６２２】
　ノード１１〜ノード１２およびノード１４〜ノード１６は、ノード１３より送信された新規グループ作成通知を受信転送し、ツリーマネージャを生成してＢＰＤＵの交換を開始する。新規に作成されたツリーマネージャの間で交換されるＢＰＤＵには、タグＩＤ４９のタグが付加される。ここで作成されるスパニングツリーを、ツリー６９とする。
【０６２３】
　ノード１５は、ノード１２よりＩＥＥＥ８０２．１ＤのプロトコルＩＤが付加されたＢＰＤＵを受信し、新規のツリーマネージャを生成して、前記ツリーマネージャに対して、リンクＩＤおよびノードＩＤ等から算出する固有のタグＩＤを割り当て、ＧＶＲＰフレームもしくはその他のフレームによって、全ノードに対して新規グループの作成をブロードキャスト通知する。ここでは新規のタグＩＤとして、タグＩＤ５０が割り当てられたとする。このとき、リンク２４のコストは大きく設定する。
【０６２４】
　ノード１１〜ノード１４およびノード１６は、ノード１５より送信された新規グループ作成通知を受信転送し、ツリーマネージャを生成してＢＰＤＵの交換を開始する。新規に作成されたツリーマネージャの間で交換されるＢＰＤＵには、タグＩＤ５０のタグが付加される。ここで作成されるスパニングツリーを、ツリー７０とする。
【０６２５】
　平常時においては、各ノード間の通信はツリー６７を用いて行われ、ツリー６８〜ツリー７０は利用されない。
【０６２６】
　ここで、もしリンク２１に障害が発生したとすると、ノード１１は、リンク２１の障害を検知して、直ちに転送に使用するツリーを、ツリー６７からツリー６８に切り替える。また、利用タググループ変更通知を全ノードに対してブロードキャスト送信し、転送に使用するタグをタグＩＤ４８に切り替えるように通知する。
【０６２７】
　ノード１２〜ノード１６の各ノードは、ノード１１より送信された利用タググループ変更通知を受信し、自ノードから送信するフレームに対してタグＩＤ４８のタグを挿入し、転送に使用するツリーを、ツリー６７からツリー６８に切り替える。
【０６２８】
　なお、リンク２１に障害が発生した場合の、ツリー６８への切替は、ノード１１ではなくノード１２が行ってもかまわない。もしノード１２がリンク２１の障害を検出した場合は、直ちに転送に使用するツリーを、ツリー６７からツリー６８に切り替える。また、利用タググループ変更通知を全ノードに対してブロードキャスト送信し、転送に使用するタグをタグＩＤ４８に切り替えるように通知する。以降の動作は、ノード１１が障害を検出した場合と同様である。
【０６２９】
　ツリー６７は、リンク２１の障害によって再構成されるが、リンク２１では８０２．１Ｄに従った再構成が行われるために、再構成が完了するまでに時間がかかる可能性がある。
【０６３０】
　本実施の形態では、、リンク２１の障害時に、転送に利用されるツリーを、ツリー６７からツリー６８にただちに切り替えることで、ツリー６７の再構成を待たずに、フレームの転送を継続することができる。
【０６３１】
　以上、リンク２１に障害が発生した場合の動作について述べたが、前記動作はリンク２２もしくはリンク２４に障害が発生した場合においても、同様に適用可能である。
【０６３２】
　次に、本実施の形態の効果について説明する。
【０６３３】
　従来、ＩＥＥＥ８０２．１Ｄを利用する区間は、障害時のルート切り替えが遅く、スパニングツリーの再構成にも時間がかかった。
【０６３４】
　本実施の形態では、ＩＥＥＥ８０２．１Ｄ利用区間の数だけツリーマネージャを作成し、相異なる１つのＩＥＥＥ８０２．１Ｄ利用区間のコストを大きく設定したツリーをＩＥＥＥ８０２．１Ｄ利用区間分作成し、障害等により前記区間を迂回する必要が生じた場合は、前記区間に対して大きなコストを振ったツリーを利用するよう切り替えることで、迂回操作を高速に行い、輻輳発生の可能性やフレームの欠落の可能性を低下させることができる。
【０６３５】
（第７の実施の形態）
　次いで、本発明の第７の実施の形態について、図面を参照して詳細に説明する。
【０６３６】
　本発明の第７の実施の形態は、第１の実施の形態において、障害検出器を用いて定期的に短い間隔で障害検出用フレームを送信し、前記障害検出用フレームが到着しなくなったことにより、障害検出を行い、障害情報をリソースモニタおよびツリーセレクタを通じて、ツリーマネージャに通知する点が異なる。
【０６３７】
　ＩＥＥＥ８０２．１ＤおよびＩＥＥＥ８０２．１ｗでは、定期的に送信されるＨＥＬＬＯフレームの未着により、障害を検出していた。しかしながら、ＨＥＬＬＯフレームの送信間隔は長いため、障害を検出するまでに長い時間がかかった。
【０６３８】
　本実施の形態では、障害検出器から定期的に短い間隔で障害検出用フレームを送信し、前記障害検出用フレームの一定個数もしくは一定時間以上の未着により、高速な障害検出を行う。
【０６３９】
　図４０を参照すると、本発明の第７の実施の形態は、第１の実施の形態におけるおける図４において、障害検出用フレームを送受信して障害を検出する、障害検出器１２０が追加されている点において異なる。
【０６４０】
　障害検出器１２０は、障害検出用フレームをフレーム転送器１１１を通じて隣接ノードに対して定期的に送信し、また、隣接ノードより送信された障害検出用フレームを、フレーム転送器１１１より受信し、隣接ノードから送られる障害検出用フレームが一定時間以上受信できない場合、および、一定個数以上の障害検出用フレームの未着を検出した場合に、リソースモニタ１１９に対して障害検出通知を送信する。
【０６４１】
　リソースモニタ１１９は、第１の実施の形態におけるリソースモニタ１１９の機能のほか、障害検出器１２０より障害通知を受信し、前記障害通知をツリーセレクタ１１６に転送する機能を有する。
【０６４２】
　ツリーセレクタ１１６は、第１の実施の形態におけるツリーセレクタ１１６の機能のほか、リソースモニタ１１９より障害通知を受信し、これをツリーマネージャ１１５１および１１５２に転送する機能を有する。
【０６４３】
　ツリーマネージャ１１５１および１１５２は、本発明の第１の実施の形態におけるツリーマネージャ１１５１および１１５２の機能のほか、ツリーセレクタ１１６より障害通知を受信し、ＩＥＥＥ８０２．１ｗもしくはＩＥＥＥ８０２．１Ｄに従い、スパニングツリーの再構成を行う。
【０６４４】
　次に、図４０を参照して、本実施の形態においてノード１１がリンク２１の障害を検知する場合の動作例について述べる。
【０６４５】
　障害検出器１２０は、定期的に、フレーム転送器１１１およびリンク２１もしくはリンク２４を経由して、隣接ノードであるノード１２およびノード１５に障害検出用フレームを送信する。
【０６４６】
　障害検出器１２０は、また、隣接しているノード１２およびノード１５より、リンク２１もしくはリンク２４と、フレーム転送器１１１を経由して送信された障害検出用フレームを受信する。このとき、障害検出器１２０は、前記障害検出用フレームが到着したポートのＩＤも、識別することができる。
【０６４７】
　障害検出器１２０は、障害検出用フレームが到着すると、前記障害検出用フレームが到着したポートのタイマを動作させ、一定時間が経過すると、通知を発信するように設定する。
【０６４８】
　障害検出器１２０は、障害検出用フレームを受信すると、ポートごとに設置されたタイマをリセットする。例えば、リンク２１より障害検出用フレームを受信した場合は、リンク２１が接続されているポートのタイマがリセットされる。また、リンク２４より障害検出用フレームを受信した場合は、リンク２４が接続されているポートのタイマがリセットされる。
【０６４９】
　ここで、障害検出器１２０において、もしリンク障害等により、障害検出用フレームが一定時間以上到着しない場合は、タイマがリセットされないためタイムアウトが起こる。障害検出器１２０は、タイムアウトが発生すると、何らかの障害が発生していると認識し、リソースモニタ１１９およびツリーセレクタ１１６を通じて、ツリーマネージャ１１５１およびツリーマネージャ１１５２に将棋ア発生を通知する。
【０６５０】
　通知を受けたツリーマネージャ１１５１およびツリーマネージャ１１５２は、障害発生ポートが使用不可能なものとして、直ちにスパニングツリーを再構成し、障害回避を行う。
【０６５１】
　次に、本実施の形態の効果について説明する。
【０６５２】
　従来、スパニングツリープロトコルで利用されているＨＥＬＬＯフレームの送信間隔が長かったため、高速な障害検出ができなかった。
【０６５３】
　本実施の形態では、短い間隔で障害検出用フレームを送受信する障害検出器を追加することにより、ＨＥＬＬＯフレームよりも高速な障害検出が可能である。
【０６５４】
　また、この結果、輻輳発生およびフレーム欠落の可能性を下げることが可能である。
【０６５５】
（実施の形態８）
　以下、本発明の第８の実施の形態について、図面を参照して詳細に説明する。
【０６５６】
　本発明の第８の実施の形態は、第１の実施の形態において、宛先ノード別に利用するタグおよびスパニングツリーを切り替え、さらに、宛先のノードをルートノードに設定することができる構成となっている。
【０６５７】
　ＩＥＥＥ８０２．１ＤおよびＩＥＥＥ８０２．１ｗが動作しているネットワークにおいてフレームを送信した場合、宛先への最低コスト経路が必ずしも選択されるとは限らず、使用されないリンクが出現するほか、ルートノードに負荷が集中する、ルートノード障害時に長時間ネットワークが停止するなどの問題があった。
【０６５８】
　本実施の形態においては、宛先がルートノードとなるツリーを用いてフレームを転送することで、宛先への最低コストによるフレーム伝送のほか、リンク利用率の向上、さらにはルートノード障害への耐性強化を実現する。
【０６５９】
　図４１を参照すると、本発明の第８の実施の形態は、第１の実施の形態における図８において、フレーム転送器１１１がフレーム転送器１１１γに、フォワーディングテーブル１１４がフォワーディングテーブル１１４γになり、さらにツリーマネージャ１１５１が、動作を変更した上でネットワークに存在するノードの数だけ設置され、ツリーマネージャ１１５１γ〜１１５３γになっている点において異なる。
【０６６０】
　図４１においては、本実施の形態を図２３に示すノード１１に適用した場合を示している。
【０６６１】
　フレーム転送器１１１γは、リンク２１もしくはリンク２３、およびタグ挿入器１１２より受信したフレームを、フォワーディングテーブル１１４γの出力ポート１１４２の記述に従い、リンク２１もしくはリンク２３、および、タグ削除器１１３もしくはツリーセレクタ１１６に転送する。この際、もし出力ポート１１４２の記述が初期値である場合は、前記受信フレームを廃棄する。
【０６６２】
　フォワーディングテーブル１１４γは、フォワーディングテーブル１１４と同様のフォワーディングテーブルである。
【０６６３】
　ツリーマネージャ１１５１γは、ツリーマネージャ１１５１と構成は同じであるが、その機能と動作において異なっている。以後、ツリーマネージャ１１５１γ〜ツリーマネージャ１１５３γを代表して、ツリーマネージャ１１５１γを用いて記述を行うが、ツリーマネージャ１１５１γについての記述は、特に断りのない限りツリーマネージャ１１５２γ〜ツリーマネージャ１１５３γにおいても同様に適用可能である。
【０６６４】
　図４２は、フォワーディングタグをキーとして出力ポートを決定する、フォワーディングテーブル１１４γの構成例である。
【０６６５】
　タグフィールド１１４１は、フォワーディングテーブル１１４内のタグフィールドと同様のタグフィールドである。
【０６６６】
　出力ポート１１４２は、フォワーディングテーブル１１４内の出力ポートと同様の出力ポートであり、ユニキャストフレームの転送時にフレーム転送器１１１γによって参照される。
【０６６７】
　図４２において、出力ポート１１４２の「ＥＮＤ」は、エッジノードにおいて宛先ノードＩＤに対する出力ポートエントリが自ノードであることを示す識別子であり、例えば自ノードＩＤと等しいノード識別子エントリに対して出力ポートフィールドに記述される。
【０６６８】
　図４３は、ツリーマネージャ１１５１γの構成を示す、ブロック図である。
【０６６９】
　図２３に示すようにスパニングツリーが構成されている場合、各ノードのポートは、そのスパニングツリーの構成に応じて、図５４のようにルートポート（Ｒｏｏｔ　Ｐｏｒｔ）、ディジグネイテッドポート（Ｄｅｓｉｇｎａｔｅｄ　Ｐｏｒｔ）又はオルタネートポート（Ａｌｔｅｒｎａｔｅ　Ｐｏｒｔ）として決定される。図５４においては、ルートポートを（Ｒ）、ディジグネイテッドポートを（Ｄ）、オルタネートポートを（ＡＬＴ）として示している。もちろん、上記ポートの種別は、スパニングツリーの構成（ルートノードの位置）によって変化する。
【０６７０】
　ツリーマネージャ１１５１γが送受信するＢＰＤＵフレームに、タググループ４１のタグが付加されている場合、ツリーコントローラ１１５１４γは、ＩＥＥＥ８０２．１ｗもしくはＩＥＥＥ８０２．１Ｄプロトコルによりルートポート（Ｒｏｏｔ　Ｐｏｒｔ）を決定する。本実施の形態においてはフォワーディングテーブル１１４γの、タググループ４１のエントリに、出力ポート１１４２として決定したルートポートを設定する。この場合、最低６個のＢＰＤＵフレームが送受信される。
【０６７１】
　ここで、もしルートポートが存在しない場合（図５４のノード１１）には、出力ポート１１４２の欄は、自ノード宛ポートに設定し、フレーム転送器に入力されたタググループ４１のタグつきフレームを、タグ削除器１１３に転送する。
【０６７２】
　次に、図２３および図４４を用いて、ユニキャストフレーム転送動作について、ノード１３からノード１１へのユニキャストフレーム転送を例に説明する。
図４４は、スパニングツリー６１における各ノードのポート設定およびフォワーディングテーブルの設定の状況示す表である。なお、この図４４は、実際のテーブル内容を示すものではなく、あくまで設定状況を示すものである。
【０６７３】
　図２３に示す状態において、タググループ４１のツリーであるツリー６１は、すでに構築されて安定しており、ノード１１〜ノード１６の各ノードにおけるルートポートは、図４４におけるルートポート６１０２に示すように決定されており、この結果より、各ノードのフォワーディングテーブル１１４における出力ポートは、図４４における出力ポート１１４２に示すように決定されているものとする。
【０６７４】
　ここで、ツリー６１は、ノード１１をルートノードとするツリーを表している。また、タグ４１は、ツリー６１を示すタグのＩＤ(値)を表している。すなわち、タグ４１をフレームに付加するということは、ツリー６１を用いてフレーム転送することを意味する。このように、ツリーの番号とノードの番号とタグの番号とのそれぞれは、一の位の数字がそれぞれ対応することを示している。例えばツリー６２は、ノード１２をルートとするツリーを示しており、タグ４２は、ツリー６２を示すタグのＩＤ(値)を表している、この点は、以下の説明においても同様である。
【０６７５】
　また、ここでは一例として上述のように、ツリー、ノード、タグにそれぞれ異なる番号を付した場合について説明をしたが、これ以外に、それぞれ対応するツリー、ノード、タグに同一の番号(ＩＤ)を付して、それぞれの対応関係を単純明確化して管理することも可能である。
【０６７６】
　まず、ノード１３がノード１１宛のユニキャストフレームに、タググループ４１のタグを付加してフレームを送信する。この際、ノード１３におけるタググループ４１のフレームの出力先ポートは、ツリー６１のルートポートであるリンク２２側のポートが指定されている。したがって、前記フレームはリンク２２側に出力される。
【０６７７】
　ノード１２は、リンク２２よりフレームを受信すると、タググループ４１をキーとしてフォワーディングテーブルを検索し、出力ポートとしてリンク２１側のポートを得る。そして、リンク２１側に前記受信フレームを出力する。
【０６７８】
　ノード１１は、リンク２１よりフレームを受信すると、自ノード宛であることを確認し、タグ削除器１１３にフレームを転送する。
【０６７９】
　以上の動作により、タググループ４１のタグおよびスパニングツリー６１を用いて、最低コスト経路によって、ノード１３からノード１１へのユニキャストフレームを転送することが可能となる。
【０６８０】
　次に、上述した第８の実施の形態の効果について説明する。
【０６８１】
　従来、宛先への最低コスト経路が必ずしも選択されるとは限らなかったが、本実施の形態では、宛先がルートノードとなるツリーを用いてフレームを転送することにより、宛先への最低コスト経路を選択することができる。
【０６８２】
　また従来、リンク利用率が低い一方、ルートノード付近に負荷が集中するという問題があったが、本実施の形態では、ルートノードの異なるスパニングツリーを複数系統設定することにより、リンク利用率を高め、ルートノード付近に負荷を集中させずに分散させることが可能である。
【０６８３】
　さらに従来、ルートノード障害時のツリー構築に時間がかかり、その間ネットワークが停止するという問題があったが、本実施の形態では、宛先がルートノードとなるツリーを用いてフレームを転送することにより、ルートノードが宛先となるフレーム以外のフレームが、ルートノード障害の影響により長時間転送不能となることがないため、ルートノード障害によるネットワーク停止を回避可能である。また、この結果、輻輳発生の可能性を下げることが可能である。
（実施の形態９）
　以下、本発明の第９の実施の形態について、図面を参照して詳細に説明する。
【０６８４】
　本発明の第９の実施の形態は、第８の実施の形態において、フォワーディングテーブルに、通常のユニキャスト用出力ポートのほかに、複数のブロードキャスト用出力ポートを記載し、ブロードキャストフレームを転送することができる構成となっている。
【０６８５】
　本実施の形態においては、ブロードキャストフレームの送信元ノードがルートノードとなるツリーを用いてブロードキャストフレームを転送することで、ブロードキャストフレームを各ノードに最短経路で送信することができ、高速な転送が可能になる。
【０６８６】
　図４５を参照すると、本発明の第９の実施の形態は、第８の実施の形態における図４１において、フレーム転送器１１１がフレーム転送器１１１βに、フォワーディングテーブル１１４がフォワーディングテーブル１１４βに、ツリーマネージャ１１５１〜１１５３がツリーマネージャ１１５１β〜１１５３βになっている点において異なる。
【０６８７】
　図４５においては、本実施の形態を図２３に示すノード１１に適用した場合を示している。
【０６８８】
　フレーム転送器１１１βは、リンク２１もしくはリンク２４、およびタグ挿入器１１２より受信したフレームを、フォワーディングテーブル１１４βの記述に従い、リンク２１もしくはリンク２４、および、タグ削除器１１３もしくはツリーセレクタ１１６に転送する。
【０６８９】
　この際、もし入力されたフレームがユニキャストフレームである場合は、前記受信フレームをフォワーディングテーブル１１４βの出力ポート１１４２に記述されたポートに転送する。
【０６９０】
　もし、入力されたフレームがブロードキャストフレームである場合は、フォワーディングテーブル１１４βのブロードキャスト出力ポート１１４４に記述された複数のポートおよびタグ削除器に、前記受信フレームをコピーして転送する。さらにもし、ブロードキャスト出力ポートに初期値が設定されていた場合は、前記受信フレームをタグ削除器のみに転送する。
【０６９１】
　ブロードキャストフレームとユニキャストフレームの判別は、送信先ＭＡＣアドレス３２０１、もしくは拡張タグのプライオリティ５００３、もしくは拡張タグ情報フィールド５００４によって行う。
【０６９２】
　フォワーディングテーブル１１４βは、フォワーディングテーブル１１４に、ブロードキャスト出力ポート１１４４欄が付加されたフォワーディングテーブルである。ブロードキャスト出力ポート１１４４欄は、対応するタグＩＤが示すノードから送信されたブロードキャスト信号を受信したときに、転送先となるポートを示している。本実施形態におけるフォワーディングテーブルの一例を図４６に示す。図４６では、転送先ポートを示すものとして、リンク名を用いている。図４６は、図２３〜２８に記載の物理トポロジからなるネットワークにおけるノード１１のフォワーディングテーブル１１４βを示している。上述の通り、本発明では、宛先ノード毎に、フレーム転送に用いるツリーが異なっている。例えば、ノード１１宛のフレームは、図２３のツリーを用い、ノード１２宛のフレームは図２４のツリーを用いてフレーム転送を行う。
【０６９３】
　ここで、タグ４２が付加されたフレームのブロードキャストの場合を例として以下に図４６の見方を説明する。タグ４２が付加されているということは、ノード１２から発信されたブロードキャストフレームであることを示している。そして、ノード１２から発信されたブロードキャストフレームは、本発明では、図２４のツリーを用いて転送される。従って、ノード１１では、このブロードキャストフレームを受信すると、リンク２３側に転送する必要がある。このような考え方に基づいて、図４６は作成される。
【０６９４】
　ツリーマネージャ１１５１βは、ツリーマネージャ１１５１と構成は同じであるが、その機能と動作において異なっている。以後、ツリーマネージャ１１５１β〜ツリーマネージャ１１５３βを代表して、ツリーマネージャ１１５１βを用いて記述を行うが、ツリーマネージャ１１５１βについての記述は、特に断りのない限りツリーマネージャ１１５２β〜ツリーマネージャ１１５３βにおいても同様に適用可能である。
【０６９５】
　図４６は、タグをキーとして出力ポートを決定する、フォワーディングテーブル１１４βの構成例である。
【０６９６】
　タグフィールド１１４１は、フォワーディングテーブル１１４内のタグフィールドと同様のタグフィールドである。
【０６９７】
　出力ポート１１４２は、フォワーディングテーブル１１４内の出力ポートと同様の出力ポートであり、ユニキャストフレームの転送時にフレーム転送器１１１βによって参照される。
【０６９８】
　ブロードキャスト出力ポート１１４４は、ブロードキャストフレームの転送時に、フレーム転送器１１１βによって参照される出力ポートである。この欄には複数のポートが記載され、もし２つ以上のポートが記載された場合は、記載されたポートの数だけフレームをコピーしてから転送する。もし、フレーム転送器１１１βによって参照されたときに、この欄に設定された値が初期値のままである場合は、フレーム転送器１１１βは、フレームをタグ削除器のみに転送する。
【０６９９】
　なお、図４６中の（ＥＮＤ）とあるのは、ノードがエッジノードである場合に識別子「ＥＮＤ」が記述されることを示している。
【０７００】
　図４７は、ツリーマネージャ１１５１βの構成を示す、ブロック図である。
【０７０１】
　ツリーマネージャ１１５１βが送受信するＢＰＤＵフレームに、タググループ４１のタグが付加されている場合、ツリーコントローラ１１５１４βは、ＩＥＥＥ８０２．１ｗもしくはＩＥＥＥ８０２．１Ｄプロトコルによりルートポート（Ｒｏｏｔ　Ｐｏｒｔ）およびディジグネイテッドポート（Ｄｅｓｉｇｎａｔｅｄ　Ｐｏｒｔ）を決定する。本実施の形態では、フォワーディングテーブル１１４βの、タググループ４１のエントリに、出力ポート１１４２として決定したルートポートを、ブロードキャスト出力ポート１１４４として、１つまたは複数の決定したディジグネイテッドポートを、それぞれ設定する。
【０７０２】
　ここで、もしルートポートが存在しない場合には、出力ポート１１４２の欄は、自ノード宛ポートに設定し、フレーム転送器に入力されたタググループ４１のタグつきフレームを、タグ削除器１１３に転送する。
【０７０３】
　また、もしディジグネイテッドポートが１つも存在しない場合には、ブロードキャスト出力ポート１１４４の欄は、テーブルの初期値に設定する。
【０７０４】
　次に、図２３および図４８を用いて、ブロードキャストフレーム転送動作について説明する。
【０７０５】
　図４８は、スパニングツリー６１における各ノードのポート設定およびフォワーディングテーブルの設定を示す表である。
【０７０６】
　最初の状態では、タググループ４１のツリーであるツリー６１は、すでに構築されて安定しており、ノード１１〜ノード１６の各ノードにおけるルートポートおよびディジグネイテッドポートは、図４８におけるルートポート６１０２およびディジグネイテッドポート６１０４に示すように決定されており、この結果より、各ノードのフォワーディングテーブル１１４βにおける出力ポートおよび予備出力ポートは、図４８における出力ポート１１４２およびブロードキャスト出力ポート１１４４に示すように決定されているものとする。
【０７０７】
　まず、ノード１１がブロードキャストフレームに、タググループ４１のタグを付加して送信する。この際、ノード１１におけるタググループ４１のブロードキャストフレームの出力先ポートは、ツリー６１のディジグネイテッドポートであるリンク２１側およびリンク２３側のポートが指定されている。したがって、前記フレームはリンク２１側およびリンク２３側、さらにタグ削除器宛に、コピーされてから出力される。
【０７０８】
　ノード１２は、リンク２１よりブロードキャストフレームを受信すると、タググループ４１をキーとしてフォワーディングテーブルを検索し、ブロードキャスト出力ポートとしてリンク２２側のポートを得る。そして、リンク２２側およびタグ削除器に、前記受信ブロードキャストフレームを出力する。
【０７０９】
　ノード１３は、リンク２２よりブロードキャストフレームを受信すると、タググループ４１をキーとしてフォワーディングテーブルを検索し、ブロードキャスト出力ポートとして初期値を得る。そして、タグ削除器に前記受信フレームを出力する。
【０７１０】
　ノード１４は、リンク２３よりブロードキャストフレームを受信すると、タググループ４１をキーとしてフォワーディングテーブルを検索し、ブロードキャスト出力ポートとしてリンク２６側のポートを得る。そして、リンク２６側およびタグ削除器に、前記受信フレームを出力する。
【０７１１】
　ノード１５は、リンク２６よりブロードキャストフレームを受信すると、タググループ４１をキーとしてフォワーディングテーブルを検索し、ブロードキャスト出力ポートとしてリンク２７側のポートを得る。そして、リンク２７側およびタグ削除器に、前記受信フレームを出力する。
【０７１２】
　ノード１６は、リンク２７よりブロードキャストフレームを受信すると、タググループ４１をキーとしてフォワーディングテーブルを検索し、ブロードキャスト出力ポートとして初期値を得る。そして、タグ削除器に前記受信フレームを出力する。
【０７１３】
　以上の動作により、ノード１１から出力されたブロードキャストフレームは、最低コスト経路によって、ネットワーク上の各ノードに転送される。
【０７１４】
　次に、上述した第９の実施の形態の効果について説明する。
【０７１５】
　従来、ブロードキャスト時に、宛先への最低コスト経路が必ずしも選択されるとは限らなかったが、本実施の形態では、送信元ノードがルートノードとなるツリーを用いてブロードキャストフレームを転送することにより、全ノードへの最低コスト経路を選択してブロードキャストフレームを転送することができる。
【０７１６】
　また従来、リンク利用率が低い一方、ルートノード付近に負荷が集中するという問題があったが、本実施の形態では、ルートノードの異なるスパニングツリーを複数系統設定することにより、リンク利用率を高め、ルートノード付近に負荷を集中させずに分散させることが可能である。
【０７１７】
　さらに従来、ルートノード障害時のツリー構築に時間がかかり、その間ネットワークが停止するという問題があったが、本実施の形態では、送信元ノードがルートノードとなるツリーを用いてブロードキャストフレームを転送することにより、ルートノードが送信元ノードとなるフレーム以外のブロードキャストフレームが、ルートノード障害の影響により長時間転送不能となることがないため、ルートノード障害によるネットワーク停止を回避可能である。また、この結果、輻輳発生の可能性を下げることが可能である。
【０７１８】
（実施の形態１０）
　以下、本発明の第１０の実施の形態について、図面を参照して詳細に説明する。
【０７１９】
　本発明の第１０の実施の形態は、第８の実施の形態において、フォワーディングテーブルに出力ポートを２つ記載し、１つの出力ポートが障害等で利用できない場合に、もう一方のポートを利用できるようにし、さらに、第７の実施の形態における障害検出器を利用し、高速な障害検出を行うことができる構成となっている。
【０７２０】
　本実施の形態においては、宛先がルートノードとなるツリーを用いてユニキャストフレームを転送し、さらにスパニングツリーによって決定される代替出力ポートをあらかじめフォワーディングテーブルに登録することで、高速な障害回復を行う。
【０７２１】
　図４９を参照すると、本発明の第８の実施の形態は、第４の実施の形態における図４１において、フレーム転送器１１１がフレーム転送器１１１αに、フォワーディングテーブル１１４がフォワーディングテーブル１１４αに、ツリーマネージャ１１５１〜１１５３がツリーマネージャ１１５１α〜１１５３αになり、さらに、第７の実施の形態に記した障害検出器１２０が追加されている点において異なる。
【０７２２】
　図４９においては、本実施の形態を図２３に示すノード１１に適用した場合を示している。
【０７２３】
　フレーム転送器１１１αは、リンク２１もしくはリンク２３、およびタグ挿入器１１２より受信したフレームを、フォワーディングテーブル１１４αの記述に従い、リンク２１もしくはリンク２３、および、タグ削除器１１３もしくはツリーセレクタ１１６に転送する。
【０７２４】
　この際、もしリソースモニタ１１９より、フォワーディングテーブル１１４αの出力ポート１１４２に記述されたポートに障害があることを検知している場合は、前記受信フレームを予備出力ポート１１４３に記述されたポートに転送する。もし、出力ポート１１４２に記述されたポートの障害を検知しているが、予備出力ポートの記述が初期値（又は未設定）である場合は、前記受信フレームを廃棄する。
【０７２５】
　フォワーディングテーブル１１４αは、フォワーディングテーブル１１４に、予備出力ポート１１４３欄が付加されたフォワーディングテーブルである。
【０７２６】
　ツリーマネージャ１１５１αは、ツリーマネージャ１１５１と構成は同じであるが、その機能と動作において異なっている。以後、ツリーマネージャ１１５１α〜ツリーマネージャ１１５３αを代表して、ツリーマネージャ１１５１αを用いて記述を行うが、ツリーマネージャ１１５１αについての記述は、特に断りのない限りツリーマネージャ１１５２α〜ツリーマネージャ１１５３αにおいても同様に適用可能である。
【０７２７】
　図５０は、タグをキーとして出力ポートを決定する、図２３におけるノード１２のフォワーディングテーブル１１４αの構成例である。
【０７２８】
　タグフィールド１１４１は、フォワーディングテーブル１１４内のタグフィールドと同様のタグフィールドである。
【０７２９】
　出力ポート１１４２は、フォワーディングテーブル１１４内の出力ポートと同様の出力ポートである。
【０７３０】
　予備出力ポート１１４３は、出力ポート１１４２に記載されたポートが利用できなくなった場合に使用する出力先ポートを記載するためのフィールドである。出力ポート１１４２に記載されたポートが利用不能であることをフレーム転送器１１１αが検知した場合、フレーム転送器１１１は当該エントリの予備出力ポート１１４３に記載されたポートにフレームを転送する。
【０７３１】
　図５１は、ツリーマネージャ１１５１αの構成を示す、ブロック図である。
【０７３２】
　ツリーマネージャ１１５１αが送受信するＢＰＤＵフレームに、タググループ４１のタグが付加されている場合、ツリーコントローラ１１５１４αは、ＩＥＥＥ８０２．１ｗプロトコルによりルートポート（Ｒｏｏｔ　Ｐｏｒｔ）およびオルタネートポート（Ａｌｔｅｒｎａｔｅ　Ｐｏｒｔ）を決定する。本実施の形態では、フォワーディングテーブル１１４αの、タググループ４１のエントリに、出力ポート１１４２として決定したルートポートを、予備出力ポート１１４３として決定したオルタネートポートを、それぞれ設定する。
【０７３３】
　ここで、もしルートポートが存在しない場合には、出力ポート１１４２の欄は、自ノード宛先ポートに設定し、フレーム転送器に入力されたタググループ４１のタグつきフレームを、タグ削除器１１３に転送する。
【０７３４】
　また、もしオルタネートポートが存在しない場合には、予備出力ポート１１４３の欄は、テーブルの初期値に設定する。
【０７３５】
　次に、図２３におよび図５２を用いて、リンクに障害が発生した場合のユニキャストフレーム転送動作について、リンク２１に障害が発生した場合を例にして説明する。
図５２は、スパニングツリー６１における各ノードのポート設定およびフォワーディングテーブルの設定を示す表である。
【０７３６】
　最初の状態では、タググループ４１のツリーであるツリー６１は、すでに構築されて安定しており、ノード１１〜ノード１６の各ノードにおけるルートポートおよびオルタネートポートは、図５２におけるルートポート６１０２およびオルタネートポート６１０３に示すように決定されており、この結果より、各ノードのフォワーディングテーブル１１４αにおける出力ポートおよび予備出力ポートは、図５２における出力ポート１１４２および予備出力ポート１１４３に示すように決定されているものとする。
【０７３７】
　まず、ノード１３がノード１１宛のユニキャストフレームに、タググループ４１のタグを付加してフレームを送信する。この際、ノード１３におけるタググループ４１のフレームの出力先ポートは、ツリー６１のルートポートであるリンク２２側のポートが指定されている。したがって、前記フレームはリンク２２側に出力される。
【０７３８】
　この状態で、リンク２１において障害が発生したとする。
【０７３９】
　ノード１２は、リンク２２よりフレームを受信すると、タググループ４１をキーとしてフォワーディングテーブルを検索し、出力ポートとしてリンク２１側のポート、予備出力ポートとしてリンク２４側のポートを得る。そして、リンク２１側に前記受信フレームを出力しようとするが、リソースモニタよりリンク２１の障害検出情報を受信しているため、予備出力ポートであるリンク２４側に前記受信フレームを出力する。
【０７４０】
　ノード１５は、リンク２４よりフレームを受信すると、タググループ４１をキーとしてフォワーディングテーブルを検索し、出力ポートとしてリンク２６側のポート、予備出力ポートとしてリンク２４側のポートを得る。そして、リンク２６側に障害が発生していないことを確認し、リンク２６側に前記受信フレームを出力する。
【０７４１】
　ノード１４は、リンク２６よりフレームを受信すると、タググループ４１をキーとしてフォワーディングテーブルを検索し、出力ポートとしてリンク２３側のポート、予備出力ポートとして初期値を得る。そして、リンク２３側に障害が発生していないことを確認し、リンク２３側に前記受信フレームを出力する。
【０７４２】
　ノード１１は、リンク２３よりフレームを受信すると、自ノード宛であることを確認し、タグ削除器１１３にフレームを転送する。
【０７４３】
　以上の動作により、リンク２１において障害が発生した場合、あらかじめ設定されている予備出力ポートを参照し、ノード１３からノード１１へのユニキャストフレームを転送する場合のルートとして、リンク２２、リンク２３、リンク２４、リンク２６、リンク２３を経由するルートがただちに選ばれ、ノード１１へのフレーム転送が継続される。したがって高速な障害時の迂回が可能であり、ネットワークの輻輳を回避できる。
【０７４４】
　次に、上述した第１０の実施の形態の効果について説明する。
【０７４５】
　従来、宛先への最低コスト経路が必ずしも選択されるとは限らなかったが、本実施の形態では、宛先がルートノードとなるツリーを用いてユニキャストフレームを転送することにより、宛先への最低コスト経路を選択することができる。
【０７４６】
　また従来、リンク利用率が低い一方、ルートノード付近に負荷が集中するという問題があったが、本実施の形態では、ルートノードの異なるスパニングツリーを複数系統設定することにより、リンク利用率を高め、ルートノード付近に負荷を集中させずに分散させることが可能である。
【０７４７】
　さらに従来、ルートノード障害時のツリー構築に時間がかかり、その間ネットワークが停止するという問題があったが、本実施の形態では、宛先がルートノードとなるツリーを用いてフレームを転送することにより、ルートノードが宛先となるフレーム以外のフレームが、ルートノード障害の影響により長時間転送不能となることがないため、ルートノード障害によるネットワーク停止を回避可能である。また、この結果、輻輳発生の可能性を下げることが可能である。
【０７４８】
　さらに従来、ルートポート側リンク障害時の出力先ポートの切替に時間がかかり、その間、フレーム転送が停止するという問題があったが、本実施の形態では、あらかじめ出力リンク障害時のための予備出力リンクをフォワーディングテーブルに設定しておくことで、ルートポート側リンク、すなわち出力リンクの障害時において、高速な経路変更が可能である。この結果、輻輳発生の可能性を下げることが可能である。
【０７４９】
　本発明のネットワークにおけるスパニングツリー構成ノードの構成要素である各手段の機能については、それをハードウェア的に実現することは勿論として、上記した各手段の機能を実行するスパニングツリー再構成プログラム（アプリケーションプログラム）９５０をコンピュータ処理装置のメモリにロードしてコンピュータ処理装置を制御することで実現することができる。このスパニングツリー再構成プログラム９５０は、磁気ディスク、半導体メモリその他の記録媒体に格納され、その記録媒体からコンピュータ処理装置にロードされ、コンピュータ処理装置の動作を制御することにより、上述した各機能を実現する。
【０７５０】
　以上好ましい実施の形態および実施例を挙げて本発明を説明したが、本発明は必ずしも上記実施の形態及び実施例に限定されるものではなく、その技術的思想の範囲内において様々に変形して実施することができる。
【図面の簡単な説明】
【０７５１】
【図１】従来のＶＬＡＮタグ付きイーサネット(R)フレームの構成例を示す図である。
【図２】本発明の拡張タグ付きイーサネット(R)フレームの構成例を示す図である。
【図３】本発明の拡張タグ付きイーサネット(R)フレームの他の構成例を示す図である。
【図４】本発明の拡張タグ格納領域の構成例を示す図である。
【図５】本発明におけるＣｏｎｆｉｇｕｒａｔｉｏｎ　ＢＰＤＵフレームのフレーム構成を示すフォーマット図である。
【図６】本発明におけるＴｏｐｏｌｏｇｙ　Ｃｈａｎｇｅ　Ｎｏｔｉｆｉｃａｔｉｏｎ　ＢＰＤＵフレームのフレーム構成を示すフォーマット図である。
【図７】本発明の第１の実施の形態の構成を示すブロック図である。
【図８】本発明の第１の実施の形態における、ノード１１の構成を示すブロック図である。
【図９】本発明の第１の実施の形態における、フォワーディングテーブル１１４の構成例を示す表である。
【図１０】本発明の第１の実施の形態における、ツリーマネージャ１１５１の構成を示すブロック図である。
【図１１】本発明の第１の実施の形態における、ツリーセレクタ１１６の構成を示すブロック図である。
【図１２】本発明の第１の実施の形態における、メインコントローラ１１６４の動作を示す流れ図である。
【図１３】本発明の第１の実施の形態における、タグテーブル１１７の構成例を示す表である。
【図１４】本発明の第１の実施の形態における、ノード７００が追加される前のスパニングツリー５１の構成を示すブロック図である。
【図１５】本発明の第１の実施の形態における、ノード７００が追加された後のスパニングツリー５２の構成を示すブロック図である。
【図１６】本発明の第１の実施の形態における、制御フレームのやりとりを示すシーケンス図である。
【図１７】本発明の第２の実施の形態における、ツリーセレクタ１１６の構成を示すブロック図である。
【図１８】本発明の第２の実施の形態における、メインコントローラ１１６４の動作を示す流れ図である。
【図１９】本発明の第３の実施の形態における、メインコントローラ１１６４の動作を示す流れ図である。
【図２０】本発明の第４の実施の形態における、ノード１１の構成を示すブロック図である。
【図２１】本発明の第４の実施の形態における、フォワーディングテーブル１１４の構成例を示す表である。
【図２２】本発明の第４の実施の形態における、タグテーブル１１７の構成例を示す表である。
【図２３】本発明の第４の実施の形態における、ツリー６１の構成を示すブロック図である。
【図２４】本発明の第４の実施の形態における、ツリー６２の構成を示すブロック図である。
【図２５】本発明の第４の実施の形態における、ツリー６３の構成を示すブロック図である。
【図２６】本発明の第４の実施の形態における、ツリー６４の構成を示すブロック図である。
【図２７】本発明の第４の実施の形態における、ツリー６５の構成を示すブロック図である。
【図２８】本発明の第４の実施の形態における、ツリー６６の構成を示すブロック図である。
【図２９】本発明の第４の実施の形態の構成を示すブロック図である。
【図３０】本発明の第４の実施の形態における、ツリー７４の構成を示すブロック図である。
【図３１】本発明の第５の実施の形態における、ツリーマネージャ１１５１の構成を示すブロック図である。
【図３２】本発明の第５の実施の形態における、ツリー７１の構成を示すブロック図である。
【図３３】本発明の第５の実施の形態における、ツリー７２の構成を示すブロック図である。
【図３４】本発明の第５の実施の形態における、ツリー７３の構成を示すブロック図である。
【図３５】本発明の第６の実施の形態における、ノード１１の構成を示すブロック図である。
【図３６】本発明の第６の実施の形態における、ツリー６７の構成を示すブロック図である。
【図３７】本発明の第６の実施の形態における、ツリー６８の構成を示すブロック図である。
【図３８】本発明の第６の実施の形態における、ツリー６９の構成を示すブロック図である。
【図３９】本発明の第６の実施の形態における、ツリー７０の構成を示すブロック図である。
【図４０】本発明の第７の実施の形態における、ノード１１の構成を示すブロック図である。
【図４１】本発明の第８の実施の形態における、ノード１１の構成を示すブロック図である。
【図４２】本発明の第８の実施の形態における、フォワーディングテーブル１１４γの構成例を示す表である。
【図４３】本発明の第８の実施の形態における、ツリーマネージャ１１５１γの構成を示すブロック図である。
【図４４】本発明の第８の実施の形態における、ツリー６１の設定状況例を示す表である。
【図４５】本発明の第９の実施の形態における、ノード１１の構成を示すブロック図である。
【図４６】本発明の第９の実施の形態における、フォワーディングテーブル１１４βの構成例を示す表である。
【図４７】本発明の第９の実施の形態における、ツリーマネージャ１１５１βの構成を示すブロック図である。
【図４８】本発明の第９の実施の形態における、ツリー６１の設定状況例を示す表である。
【図４９】本発明の第１０の実施の形態における、ノード１１の構成を示すブロック図である。
【図５０】本発明の第１０の実施の形態における、フォワーディングテーブル１１４αの構成例を示す表である。
【図５１】本発明の第１０の実施の形態における、ツリーマネージャ１１５１αの構成を示すブロック図である。
【図５２】本発明の第１０の実施の形態における、ツリー６１の設定状況例を示す表である。
【図５３】本発明における、拡張フレームの他の構成例を示す図である。
【図５４】図２３に示すスパニングツリーの構成における各ノードのポート状態を説明する図である。
【符号の説明】
【０７５２】
　　１１〜１８　ノード
　　２１〜３０　双方向リンク
　　３１　現用系ＢＰＤＵ（タググループ４１）
　　３２　予備系ＢＰＤＵ（タググループ４２）
　　３３　現用系ＢＰＤＵ（タググループ４２）
　　３４　予備系ＢＰＤＵ（タググループ４１）
　　３５　利用タググループ変更通知（ＧＶＲＰ等）
　　４１〜５０　タググループ
　　５１〜５２　スパニングツリー
　　６１〜７３　スパニングツリー]
　　８１〜８８　双方向リンク
　　９１〜９７　クライアント
　　１１１　フレーム転送器
　　１１１α　フレーム転送器
　　１１１β　フレーム転送器
　　１１１γ　フレーム転送器
　　１１２　タグ挿入器
　　１１３　タグ削除器
　　１１４　フォワーディングテーブル
　　１１４α　フォワーディングテーブル
　　１１４β　フォワーディングテーブル
　　１１４γ　フォワーディングテーブル
　　１１６　ツリーセレクタ
　　１１７　タグテーブル
　　１１８　設定インタフェース
　　１１９　リソースモニタ
　　１１４３　予備出力ポート
　　１１４４　ブロードキャスト出力ポート
　　１１５０　分別器
　　１１５１　ツリーマネージャ
　　１１５１α　ツリーマネージャ
　　１１５１β　ツリーマネージャ
　　１１５１γ　ツリーマネージャ
　　１１５２　ツリーマネージャ
　　１１５３　ツリーマネージャ
　　１１６１　タグ削除器
　　１１６２　ＧＶＲＰ送信機
　　１１６３　タグ挿入器
　　１１６４　メインコントローラ
　　１１６５　安定タイマ
　　１１６６　到着間隔タイマ
　　１１６７　コスト参照タイマ
　　１１６８　関数演算器
　　１１６９　平滑化回路
　　１１５１１　タグ削除器
　　１１５１２　ＢＰＤＵ送信機
　　１１５１３　タグ挿入器
　　１１５１４　ツリーコントローラ
　　１１５１４α　ツリーコントローラ
　　１１５１４β　ツリーコントローラ
　　１１５１４γ　ツリーコントローラ
　　１１５１５　ツリーテーブル
　　１１５１６　コスト操作器
　　１１６４１〜１１６４９　状態
　　１１６４Ａ　状態
　　１１６４Ｂ　状態
　　１２０　障害検出器
　　２８００　ＴＰＩＤ
　　２８０１　ＴＣＩ
　　２８０２　Ｐｒｉｏｒｉｔｙ（プライオリティ）
　　２８０３　ＣＦＩ
　　２８０４　ＶＬＡＮ　ＩＤ
　　３５０８　ブロードキャストタグ（拡張タグ）
　　５００１　拡張タグ識別領域
　　５００２　拡張タグ情報領域
　　５００３　Ｐｒｉｏｒｉｔｙ、タグタイプフィールド
　　５００４　拡張タグ情報フィールド
　　６１０１　ノード
　　６１０２　ルートポート
　　６１０３　オルタネートポート
　　６１０４　ディジグネイテッドポート
【図１】
2004104834.tif 000003
【図２】
2004104834.tif 000004
【図３】
2004104834.tif 000005
【図４】
2004104834.tif 000006
【図５】
2004104834.tif 000007
【図６】
2004104834.tif 000008
【図７】
2004104834.tif 000009
【図８】
2004104834.tif 000010
【図９】
2004104834.tif 000011
【図１０】
2004104834.tif 000012
【図１１】
2004104834.tif 000013
【図１２】
2004104834.tif 000014
【図１３】
2004104834.tif 000015
【図１４】
2004104834.tif 000016
【図１５】
2004104834.tif 000017
【図１６】
2004104834.tif 000018
【図１７】
2004104834.tif 000019
【図１８】
2004104834.tif 000020
【図１９】
2004104834.tif 000021
【図２０】
2004104834.tif 000022
【図２１】
2004104834.tif 000023
【図２２】
2004104834.tif 000024
【図２３】
2004104834.tif 000025
【図２４】
2004104834.tif 000026
【図２５】
2004104834.tif 000027
【図２６】
2004104834.tif 000028
【図２７】
2004104834.tif 000029
【図２８】
2004104834.tif 000030
【図２９】
2004104834.tif 000031
【図３０】
2004104834.tif 000032
【図３１】
2004104834.tif 000033
【図３２】
2004104834.tif 000034
【図３３】
2004104834.tif 000035
【図３４】
2004104834.tif 000036
【図３５】
2004104834.tif 000037
【図３６】
2004104834.tif 000038
【図３７】
2004104834.tif 000039
【図３８】
2004104834.tif 000040
【図３９】
2004104834.tif 000041
【図４０】
2004104834.tif 000042
【図４１】
2004104834.tif 000043
【図４２】
2004104834.tif 000044
【図４３】
2004104834.tif 000045
【図４４】
2004104834.tif 000046
【図４５】
2004104834.tif 000047
【図４６】
2004104834.tif 000048
【図４７】
2004104834.tif 000049
【図４８】
2004104834.tif 000050
【図４９】
2004104834.tif 000051
【図５０】
2004104834.tif 000052
【図５１】
2004104834.tif 000053
【図５２】
2004104834.tif 000054
【図５３】
2004104834.tif 000055
【図５４】
2004104834.tif 000056