JP3729265B2 - ネットワークシステム、スパニングツリー構成方法、スパニングツリー構成ノード、及びスパニングツリー構成プログラム - Google Patents

ネットワークシステム、スパニングツリー構成方法、スパニングツリー構成ノード、及びスパニングツリー構成プログラム Download PDF

Info

Publication number
JP3729265B2
JP3729265B2 JP2003041838A JP2003041838A JP3729265B2 JP 3729265 B2 JP3729265 B2 JP 3729265B2 JP 2003041838 A JP2003041838 A JP 2003041838A JP 2003041838 A JP2003041838 A JP 2003041838A JP 3729265 B2 JP3729265 B2 JP 3729265B2
Authority
JP
Japan
Prior art keywords
tree
node
tag
spanning tree
frame
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2003041838A
Other languages
English (en)
Other versions
JP2004140777A (ja
Inventor
敦之 榎本
正樹 厩橋
洋一 飛鷹
淳 岩田
真 渋谷
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Priority to JP2003041838A priority Critical patent/JP3729265B2/ja
Priority to AU2003255044A priority patent/AU2003255044A1/en
Priority to EP20030792691 priority patent/EP1542407A4/en
Priority to CNA03819872XA priority patent/CN1679279A/zh
Priority to KR1020057003039A priority patent/KR20050036977A/ko
Priority to PCT/JP2003/010370 priority patent/WO2004019560A1/ja
Priority to US10/642,480 priority patent/US7894374B2/en
Priority to TW92122644A priority patent/TWI242337B/zh
Priority to CA 2437673 priority patent/CA2437673A1/en
Publication of JP2004140777A publication Critical patent/JP2004140777A/ja
Application granted granted Critical
Publication of JP3729265B2 publication Critical patent/JP3729265B2/ja
Priority to US12/073,331 priority patent/US7855981B2/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/48—Routing tree calculation
    • H04L45/484—Routing tree calculation using multiple routing trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/48—Routing tree calculation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/462—LAN interconnection over a bridge based backbone
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • H04L12/4645—Details on frame tagging
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/28—Routing or path finding of packets in data switching networks using route fault recovery

Description

【０００１】
【発明の属する技術分野】
本発明は、ネットワークシステムに関し、特にスパニングツリーの再構成時にネットワークを停止させることが無く、さらに負荷分散機能を有するネットワークシステム、スパニングツリー構成方法及びスパニングツリー構成ノードに関する。
【０００２】
【従来の技術】
従来、この種のスパニングツリーは、ループ(円環)状に形成されたネットワークにおいて、データが永遠に循環するのを防止するために用いられている。
【０００３】
例えば「１９９８年、アイトリプルイー・スタンダード・８０２．１ディー（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)フレームの他の構成例を示す図である。
【図４】 本発明の拡張タグ格納領域の構成例を示す図である。
【図５】 本発明におけるＣｏｎｆｉｇｕｒａｔｉｏｎ ＢＰＤＵフレームのフレーム構成を示すフォーマット図である。
【図６】 本発明におけるＴｏｐｏｌｏｇｙ Ｃｈａｎｇｅ Ｎｏｔｉｆｉｃａｔｉｏｎ ＢＰＤＵフレームのフレーム構成を示すフォーマット図である。
【図７】 本発明の第１の実施の形態の構成を示すブロック図である。
【図８】 本発明の第１の実施の形態における、ノード１１の構成を示すブロック図である。
【図９】 本発明の第１の実施の形態における、フォワーディングテーブル１１４の構成例を示す表である。
【図１０】 本発明の第１の実施の形態における、ツリーマネージャ１１５１の構成を示すブロック図である。
【図１１】 本発明の第１の実施の形態における、ツリーセレクタ１１６の構成を示すブロック図である。
【図１２】 本発明の第１の実施の形態における、メインコントローラ１１６４の動作を示す流れ図である。
【図１３】 本発明の第１の実施の形態における、タグテーブル１１７の構成例を示す表である。
【図１４】 本発明の第１の実施の形態における、ノード７００が追加される前のスパニングツリー５１の構成を示すブロック図である。
【図１５】 本発明の第１の実施の形態における、ノード７００が追加された後のスパニングツリー５２の構成を示すブロック図である。
【図１６】 本発明の第１の実施の形態における、制御フレームのやりとりを示すシーケンス図である。
【図１７】 本発明の第２の実施の形態における、ツリーセレクタ１１６の構成を示すブロック図である。
【図１８】 本発明の第２の実施の形態における、メインコントローラ１１６４の動作を示す流れ図である。
【図１９】 本発明の第３の実施の形態における、メインコントローラ１１６４の動作を示す流れ図である。
【図２０】 本発明の第４の実施の形態における、ノード１１の構成を示すブロック図である。
【図２１】 本発明の第４の実施の形態における、フォワーディングテーブル１１４の構成例を示す表である。
【図２２】 本発明の第４の実施の形態における、タグテーブル１１７の構成例を示す表である。
【図２３】 本発明の第４の実施の形態における、ツリー６１の構成を示すブロック図である。
【図２４】 本発明の第４の実施の形態における、ツリー６２の構成を示すブロック図である。
【図２５】 本発明の第４の実施の形態における、ツリー６３の構成を示すブロック図である。
【図２６】 本発明の第４の実施の形態における、ツリー６４の構成を示すブロック図である。
【図２７】 本発明の第４の実施の形態における、ツリー６５の構成を示すブロック図である。
【図２８】 本発明の第４の実施の形態における、ツリー６６の構成を示すブロック図である。
【図２９】 本発明の第４の実施の形態の構成を示すブロック図である。
【図３０】 本発明の第４の実施の形態における、ツリー７４の構成を示すブロック図である。
【図３１】 本発明の第５の実施の形態における、ツリーマネージャ１１５１の構成を示すブロック図である。
【図３２】 本発明の第５の実施の形態における、ツリー７１の構成を示すブロック図である。
【図３３】 本発明の第５の実施の形態における、ツリー７２の構成を示すブロック図である。
【図３４】 本発明の第５の実施の形態における、ツリー７３の構成を示すブロック図である。
【図３５】 本発明の第６の実施の形態における、ノード１１の構成を示すブロック図である。
【図３６】 本発明の第６の実施の形態における、ツリー６７の構成を示すブロック図である。
【図３７】 本発明の第６の実施の形態における、ツリー６８の構成を示すブロック図である。
【図３８】 本発明の第６の実施の形態における、ツリー６９の構成を示すブロック図である。
【図３９】 本発明の第６の実施の形態における、ツリー７０の構成を示すブロック図である。
【図４０】 本発明の第７の実施の形態における、ノード１１の構成を示すブロック図である。
【図４１】 本発明の第８の実施の形態における、ノード１１の構成を示すブロック図である。
【図４２】 本発明の第８の実施の形態における、フォワーディングテーブル１１４γの構成例を示す表である。
【図４３】 本発明の第８の実施の形態における、ツリーマネージャ１１５１γの構成を示すブロック図である。
【図４４】 本発明の第８の実施の形態における、ツリー６１の設定状況例を示す表である。
【図４５】 本発明の第９の実施の形態における、ノード１１の構成を示すブロック図である。
【図４６】 本発明の第９の実施の形態における、フォワーディングテーブル１１４βの構成例を示す表である。
【図４７】 本発明の第９の実施の形態における、ツリーマネージャ１１５１βの構成を示すブロック図である。
【図４８】 本発明の第９の実施の形態における、ツリー６１の設定状況例を示す表である。
【図４９】 本発明の第１０の実施の形態における、ノード１１の構成を示すブロック図である。
【図５０】 本発明の第１０の実施の形態における、フォワーディングテーブル１１４αの構成例を示す表である。
【図５１】 本発明の第１０の実施の形態における、ツリーマネージャ１１５１αの構成を示すブロック図である。
【図５２】 本発明の第１０の実施の形態における、ツリー６１の設定状況例を示す表である。
【図５３】 本発明における、拡張フレームの他の構成例を示す図である。
【図５４】 図２３に示すスパニングツリーの構成における各ノードのポート状態を説明する図である。
【符号の説明】
１１〜１８ ノード
２１〜３０ 双方向リンク
３１ 現用系ＢＰＤＵ（タググループ４１）
３２ 予備系ＢＰＤＵ（タググループ４２）
３３ 現用系ＢＰＤＵ（タググループ４２）
３４ 予備系ＢＰＤＵ（タググループ４１）
３５ 利用タググループ変更通知（ＧＶＲＰ等）
４１〜５０ タググループ
５１〜５２ スパニングツリー
６１〜７３ スパニングツリー]
８１〜８８ 双方向リンク
９１〜９７ クライアント
１１１ フレーム転送器
１１１α フレーム転送器
１１１β フレーム転送器
１１１γ フレーム転送器
１１２ タグ挿入器
１１３ タグ削除器
１１４ フォワーディングテーブル
１１４α フォワーディングテーブル
１１４β フォワーディングテーブル
１１４γ フォワーディングテーブル
１１６ ツリーセレクタ
１１７ タグテーブル
１１８ 設定インタフェース
１１９ リソースモニタ
１１４３ 予備出力ポート
１１４４ ブロードキャスト出力ポート
１１５０ 分別器
１１５１ ツリーマネージャ
１１５１α ツリーマネージャ
１１５１β ツリーマネージャ
１１５１γ ツリーマネージャ
１１５２ ツリーマネージャ
１１５３ ツリーマネージャ
１１６１ タグ削除器
１１６２ ＧＶＲＰ送信機
１１６３ タグ挿入器
１１６４ メインコントローラ
１１６５ 安定タイマ
１１６６ 到着間隔タイマ
１１６７ コスト参照タイマ
１１６８ 関数演算器
１１６９ 平滑化回路
１１５１１ タグ削除器
１１５１２ ＢＰＤＵ送信機
１１５１３ タグ挿入器
１１５１４ ツリーコントローラ
１１５１４α ツリーコントローラ
１１５１４β ツリーコントローラ
１１５１４γ ツリーコントローラ
１１５１５ ツリーテーブル
１１５１６ コスト操作器
１１６４１〜１１６４９ 状態
１１６４Ａ 状態
１１６４Ｂ 状態
１２０ 障害検出器
２８００ ＴＰＩＤ
２８０１ ＴＣＩ
２８０２ Ｐｒｉｏｒｉｔｙ（プライオリティ）
２８０３ ＣＦＩ
２８０４ ＶＬＡＮ ＩＤ
３５０８ ブロードキャストタグ（拡張タグ）
５００１ 拡張タグ識別領域
５００２ 拡張タグ情報領域
５００３ Ｐｒｉｏｒｉｔｙ、タグタイプフィールド
５００４ 拡張タグ情報フィールド
６１０１ ノード
６１０２ ルートポート
６１０３ オルタネートポート
６１０４ ディジグネイテッドポート

Claims (39)

  1. 複数のノードを接続したネットワーク上でスパニングツリーを構成するノードにおいて、
    ネットワークの構成変更前のスパニングツリーを運用したまま、構成変更後の新たなスパニングツリーを生成し、前記新たなスパニングツリーの安定後に、転送に利用するスパニングツリーを前記新たなスパニングツリーに切り替えることを特徴とするノード。
  2. 前記ネットワークの構成変更が、ノードの追加又は削除やリンクトポロジの変化であることを特徴とする請求項１に記載のノード。
  3. 複数のノードを接続したネットワーク上でスパニングツリーを構成するノードにおいて、
    ネットワークのコスト変更時に、現スパニングツリーを運用したまま、リンクコスト変更後の新たなスパニングツリーを生成し、前記新たなスパニングツリーの安定後に、転送に利用するスパニングツリーを前記新たなスパニングツリーに切り替えることを特徴とするノード。
  4. 複数のノードを接続したネットワーク上でスパニングツリーを構成するノードにおいて、
    独立して動作する複数のスパニングツリーを生成する複数のツリーマネージャと、
    転送に利用するスパニングツリーに対応したタグを返答するタグテーブルと、
    前記タグテーブルより返答のあったタグをフレームに挿入するタグ挿入器と、
    転送に利用するスパニングツリーを決定するツリーセレクタと、
    宛先ごとのフレームの転送出力先を記録するフォワーディングテーブルと、
    前記フォワーディングテーブルで指定された転送出力先にフレームを転送するフレーム転送器と、
    前記タグに従って前記フレームの転送先のツリーマネージャを決定する分別器とを備えることを特徴とするノード。
  5. 前記ツリーセレクタが、
    転送に利用するスパニングツリーの切り替えを行うメインコントローラと、
    スパニングツリーの安定を示す指定した時間のタイマ満了を知らせる安定タイマと、
    フレームに付加されたタグを削除するタグ削除器と、
    スパニングツリーの切り替えのための制御フレームを送信するＧＶＲＰ送受信器と、
    フレームにタグを付加するタグ挿入器とを備えることを特徴とする請求項４に記載のノード。
  6. 前記ツリーセレクタは、
    スパニングツリーの安定を示すフレームの到着間隔を判別するため、一定時間が経過するとタイマ満了通知を送信する到着間隔タイマを備えることを特徴とする請求項５に記載のノード。
  7. 前記ツリーセレクタは、
    リンクコストの算出に利用する指定時間のタイマ満了を知らせるコスト参照タイマを備えることを特徴とする請求項４から請求項６の何れか１項に記載のノード。
  8. 前記ツリーマネージャが、
    フレームに付加されたタグを削除するタグ削除器と、
    ＢＰＤＵを送受信するＢＰＤＵ送受信器と、
    フレームにタグを付加するタグ挿入器と、
    スパニングツリープロトコルに従ってスパニングツリーを作成するツリーコントローラと、
    前記スパニングツリープロトコルで使用するパラメータを保持するツリーテーブルとを備えることを特徴とする請求項４から請求項７の何れか１項に記載のノード。
  9. 前記ツリーマネージャは、
    通知されたリンクコストに所定の設定値を加算して返答するコスト操作器を備えることを特徴とする請求項８に記載のノード。
  10. リンクの接続状況や空き帯域を含むリソース情報を計測するリソースモニタを備えることを特徴とする請求項４から請求項９の何れか１項に記載のノード。
  11. 前記リンクコストを、利用状況に基づいて計算することを特徴とする請求項３に記載のノード。
  12. 前記利用状況を、空き帯域と定義することを特徴とする請求項１１に記載のノード。
  13. 前記利用状況を、ＣＰＵ負荷と定義することを特徴とする請求項１１に記載のノード。
  14. 複数のノードを接続したネットワーク上でスパニングツリーを構成するノードにおいて、
    独立して動作する複数のスパニングツリーを生成する複数のツリーマネージャと、
    転送に利用するスパニングツリーに対応したタグを返答するタグテーブルと、
    前記タグテーブルより返答のあったタグをフレームに挿入するタグ挿入器と、
    ネットワークに存在するルートノード数と同数のツリーマネージャを生成するツリーセレクタと、
    宛先ごとのフレームの転送出力先を記録するフォワーディングテーブルと、
    前記フォワーディングテーブルで指定された転送出力先にフレームを転送するフレーム転送器と、
    前記タグに従って前記フレームの転送先のツリーマネージャを決定する分別器
    とを備えることを特徴とするノード。
  15. 前記ツリーセレクタが、
    ツリーマネージャの作成もしくは削除を行うメインコントローラと、
    フレームに付加されたタグを削除するタグ削除器と、
    スパニングツリーの切り替えのための制御フレームを送信するＧＶＲＰ送受信器と、
    フレームにタグを付加するタグ挿入器とを備えることを特徴とする請求項１４に記載のノード。
  16. 前記ツリーマネージャが、
    フレームに付加されたタグを削除するタグ削除器と、
    ＢＰＤＵを送受信するＢＰＤＵ送受信器と、
    フレームにタグを付加するタグ挿入器と、
    スパニングツリープロトコルに従ってスパニングツリーを作成するツリーコントローラと、
    前記スパニングツリープロトコルで使用するパラメータを保持するツリーテーブルとを備えることを特徴とする請求項１４または請求項１５に記載のノード。
  17. リンクの接続状況や空き帯域を含むリソース情報を計測するリソースモニタを備えることを特徴とする請求項１４から請求項１６の何れか１項に記載のノード。
  18. 複数のノードを接続したネットワーク上でスパニングツリーを構成する各ノード上で動作するスパニングツリー構成プログラムにおいて、
    ネットワークの構成変更前のスパニングツリーを運用したまま、構成変更後の新たなスパニングツリーを生成し、前記新たなスパニングツリーの安定後に、転送に利用するスパニングツリーを前記新たなスパニングツリーに切り替える処理を実行することを特徴とするスパニングツリー構成プログラム。
  19. 前記ネットワークの構成変更が、ノードの追加又は削除やリンクトポロジの変化であることを特徴とする請求項１８に記載のスパニングツリー構成プログラム。
  20. 複数のノードを接続したネットワーク上でスパニングツリーを構成する各ノード上で動作するスパニングツリー構成プログラムにおいて、
    ネットワークのコスト変更時に、現スパニングツリーを運用したまま、リンクコスト変更後の新たなスパニングツリーを生成し、前記新たなスパニングツリーの安定後に、転送に利用するスパニングツリーを前記新たなスパニングツリーに切り替える処理を実行することを特徴とするスパニングツリー構成プログラム。
  21. 複数のノードを接続したネットワーク上でスパニングツリーを構成する各ノード上で動作するスパニングツリー構成プログラムにおいて、
    複数のツリーマネージャによる独立して動作する複数のスパニングツリーを生成する処理と、
    転送に利用するスパニングツリーに対応したタグを返答する処理と、
    返答のあった前記タグをフレームに挿入するタグ挿入処理と、
    転送に利用するツリーを決定するツリーセレクタ処理と、
    宛先ごとのフレームの転送出力先を記録するフォワーディングテーブル処理と、
    前記フォワーディングテーブルで指定された転送出力先にフレームを転送するフレーム転送処理と、
    前記タグに従って転送先のツリーマネージャを決定する分別処理
    とを実行することを特徴とするスパニングツリー構成プログラム。
  22. 前記ツリーセレクタ処理において、
    転送に利用するスパニングツリーの切り替えを行うコントローラ処理と、
    スパニングツリーの安定を示す指定した時間のタイマ満了を知らせる安定タイマ処理と、
    フレームに付加されたタグを削除するタグ削除処理と、
    スパニングツリーの切り替えのための制御フレームを送信するＧＶＲＰ送受信処理と、
    フレームにタグを付加するタグ挿入処理
    とを実行することを特徴とする請求項２１に記載のスパニングツリー構成プログラム。
  23. 前記ツリーセレクタ処理において、
    スパニングツリーの安定を示すフレームの到着間隔を判別するため、一定時間が経過すると、タイマ満了通知を送信する到着間隔タイマ処理を実行することを特徴とする請求項２２に記載のスパニングツリー構成プログラム。
  24. 前記ツリーセレクタ処理は、
    リンクコストの算出に利用する指定時間のタイマ満了を知らせるコスト参照タイマ処理を実行することを特徴とする請求項２１から請求項２３に記載のスパニングツリー構成プログラム。
  25. 前記ツリーマネージャ処理が、
    フレームに付加されたタグを削除するタグ削除処理と、
    ＢＰＤＵを送受信するＢＰＤＵ送受信処理と、
    フレームにタグを付加するタグ挿入処理と、
    スパニングツリープロトコルに従ってスパニングツリーを作成するツリーコントローラ処理と、
    前記スパニングツリープロトコルで使用するパラメータを保持するツリーテーブル処理とを実行することを特徴とする請求項２１から請求項２４の何れか１項に記載のスパニングツリー構成プログラム。
  26. 前記ツリーマネージャ処理は、
    通知されたリンクコストに所定の設定値を加算して返答するコスト操作処理を実行することを特徴とする請求項２５に記載のスパニングツリー構成プログラム。
  27. リンクの接続状況や空き帯域を含むリソース情報を計測するリソースモニタ処理を実行することを特徴とする請求項２１から請求項２６の何れか１項に記載のスパニングツリー構成プログラム。
  28. リンクコストを、利用状況により計算する処理を実行することを特徴とする請求項２０に記載のスパニングツリー構成プログラム。
  29. 前記利用状況を、空き帯域と定義することを特徴とする請求項２８に記載のスパニングツリー構成プログラム。
  30. 前記利用状況を、ＣＰＵ負荷と定義することを特徴とする請求項２ ８に記載のスパニングツリー構成プログラム。
  31. 複数のノードを接続したネットワーク上でスパニングツリーによって転送経路を設定するネットワークシステムにおいて、
    各前記ノードが、
    ネットワークの構成変更前のスパニングツリーを運用したまま、構成変更後の新たなスパニングツリーを生成し、前記新たなスパニングツリーの安定後に、転送に利用するスパニングツリーを前記新たなスパニングツリーに切り替えることを特徴とするネットワークシステム。
  32. 複数のノードを接続したネットワーク上でスパニングツリーによって転送経路を設定するネットワークシステムにおいて、
    各前記ノードが、
    ネットワークのコスト変更時に、現スパニングツリーを運用したまま、リンクコスト変更後の新たなスパニングツリーを生成し、前記新たなスパニングツリーの安定後に、転送に利用するスパニングツリーを前記新たなスパニングツリーに切り替えることを特徴とするネットワークシステム。
  33. 複数のノードを接続したネットワーク上でスパニングツリーによって転送経路を設定するネットワークシステムにおいて、
    各前記ノードが、
    独立して動作する複数のスパニングツリーを生成する複数のツリーマネージャと、
    転送に利用するスパニングツリーに対応したタグを返答するタグテーブルと、
    前記タグテーブルより返答のあったタグをフレームに挿入するタグ挿入器と、
    転送に利用するスパニングツリーを決定するツリーセレクタと、
    宛先ごとのフレームの転送出力先を記録するフォワーディングテーブルと、
    前記フォワーディングテーブルで指定された転送出力先にフレームを転送するフレーム転送器と、
    前記タグに従って前記フレームの転送先のツリーマネージャを決定する分別器とを備えることを特徴とするネットワークシステム。
  34. 複数のノードを接続したネットワークにおけるスパニングツリー構成方法であって、
    ネットワークの構成変更前のスパニングツリーを運用したまま、構成変更後の新たなスパニングツリーを生成し、前記新たなスパニングツリーの安定後に、転送に利用するスパニングツリーを前記新たなスパニングツリーに切り替えることを特徴とするスパニングツリー構成方法。
  35. 複数のノードを接続したネットワークにおけるスパニングツリー構成方法であって、
    ネットワークのコスト変更時に、現スパニングツリーを運用したまま、リンクコスト変更後の新たなスパニングツリーを生成し、前記新たなスパニングツリーの安定後に、転送に利用するスパニングツリーを前記新たなスパニングツリーに切り替えることを特徴とするスパニングツリー構成方法。
  36. 複数のノードを接続したネットワークにおいて信号伝送に用いる論理トポロジを形成する方法であって、
    ネットワークの構成変更前の論理トポロジを用いて信号伝送を行っている状態で、ネットワークの構成変更後の論理トポロジを生成し、
    前記構成変更後の論理トポロジ安定後に、信号伝送に用いる論理トポロジを前記構成変更後の論理トポロジに切り替えることを特徴とする論理トポロジ形成方法。
  37. 自らが属するネットワークにおいて信号伝送に用いる論理トポロジを用いて信号伝送を行っている状態で、前記ネットワークの構成変更時に、ネットワークの構成変更後の論理トポロジを生成する手段と、
    前記構成変更後の論理トポロジ安定後に、信号伝送に用いる論理トポロジを前記構成変更後の論理トポロジに切り替える手段とを有するノード。
  38. 自らが属するネットワークにおいて信号伝送に用いる論理トポロジを用いて信号伝送を行っている状態で、前記ネットワークの構成変更時に、ネットワークの構成変更後の論理トポロジを生成する処理と、
    前記構成変更後の論理トポロジ安定後に、信号伝送に用いる論理トポロジを前記構成変更後の論理トポロジに切り替える処理とを実行することを特徴とするプログラム。
  39. 複数のノードを接続したネットワークシステムであって、
    ネットワークの構成変更前の論理トポロジを用いて信号伝送を行っている状態で、ネットワークの構成変更後の論理トポロジを生成し、
    前記構成変更後の論理トポロジ安定後に、信号伝送に用いる論理トポロジを前記構成変更後の論理トポロジに切り替えることを特徴とするネットワークシステム。
JP2003041838A 2002-08-22 2003-02-19 ネットワークシステム、スパニングツリー構成方法、スパニングツリー構成ノード、及びスパニングツリー構成プログラム Expired - Fee Related JP3729265B2 (ja)

Priority Applications (10)

Application Number Priority Date Filing Date Title
JP2003041838A JP3729265B2 (ja) 2002-08-22 2003-02-19 ネットワークシステム、スパニングツリー構成方法、スパニングツリー構成ノード、及びスパニングツリー構成プログラム
EP20030792691 EP1542407A4 (en) 2002-08-22 2003-08-15 NETWORK SYSTEM, SPANNING TREE STRUCTURING PROCESS, SPANNING TREE STRUCTURAL KNOT AND SPANNING TREE STRUCTURE PROGRAM
CNA03819872XA CN1679279A (zh) 2002-08-22 2003-08-15 网络系统、生成树构成方法、生成树构成节点和生成树构成程序
KR1020057003039A KR20050036977A (ko) 2002-08-22 2003-08-15 네트워크 시스템, 스패닝 트리 구성 방법, 스패닝 트리 구성 노드, 및 스패닝 트리 구성 프로그램
PCT/JP2003/010370 WO2004019560A1 (ja) 2002-08-22 2003-08-15 ネットワークシステム、スパニングツリー構成方法、スパニングツリー構成ノード、及びスパニングツリー構成プログラム
AU2003255044A AU2003255044A1 (en) 2002-08-22 2003-08-15 Network system, spanning tree structuring method, spanning tree structure node, and spanning tree structure program
US10/642,480 US7894374B2 (en) 2002-08-22 2003-08-18 Network system, spanning tree configuration method, spanning tree configuration node, and spanning tree configuration program
TW92122644A TWI242337B (en) 2002-08-22 2003-08-18 Network system, spanning tree configuration method, spanning tree configuration node, and spanning tree configuration program
CA 2437673 CA2437673A1 (en) 2002-08-22 2003-08-19 Network system, spanning tree configuration method, spanning tree configuration node and spanning tree configuration program
US12/073,331 US7855981B2 (en) 2002-08-22 2008-03-04 Network system, spanning tree configuration method, spanning tree configuration node, and spanning tree configuration program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2002242621 2002-08-22
JP2003041838A JP3729265B2 (ja) 2002-08-22 2003-02-19 ネットワークシステム、スパニングツリー構成方法、スパニングツリー構成ノード、及びスパニングツリー構成プログラム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2003430597A Division JP4123437B2 (ja) 2002-08-22 2003-12-25 ネットワークシステム、スパニングツリー構成方法、スパニングツリー構成ノード、及びスパニングツリー構成プログラム

Publications (2)

Publication Number Publication Date
JP2004140777A JP2004140777A (ja) 2004-05-13
JP3729265B2 true JP3729265B2 (ja) 2005-12-21

Family

ID=31949568

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2003041838A Expired - Fee Related JP3729265B2 (ja) 2002-08-22 2003-02-19 ネットワークシステム、スパニングツリー構成方法、スパニングツリー構成ノード、及びスパニングツリー構成プログラム

Country Status (9)

Country Link
US (2) US7894374B2 (ja)
EP (1) EP1542407A4 (ja)
JP (1) JP3729265B2 (ja)
KR (1) KR20050036977A (ja)
CN (1) CN1679279A (ja)
AU (1) AU2003255044A1 (ja)
CA (1) CA2437673A1 (ja)
TW (1) TWI242337B (ja)
WO (1) WO2004019560A1 (ja)

Families Citing this family (66)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4120356B2 (ja) * 2002-11-05 2008-07-16 日本電気株式会社 拡張ｖｌａｎタグｓｗａｐ方式
US7567510B2 (en) * 2003-02-13 2009-07-28 Cisco Technology, Inc. Security groups
US8099481B2 (en) * 2003-12-16 2012-01-17 Alcatel Lucent System and method for resolving hubs and like devices in network topology
JP4398263B2 (ja) * 2004-01-13 2010-01-13 富士通株式会社 経路設計方法
JP4017161B2 (ja) * 2004-01-22 2007-12-05 日本アイ・ビー・エム株式会社 区間特定システム、配電系統モニタリングシステム、その方法及びプログラム
US20050190758A1 (en) * 2004-03-01 2005-09-01 Cisco Technology, Inc. Security groups for VLANs
US7969863B2 (en) * 2004-03-29 2011-06-28 Hewlett-Packard Development Company, L.P. Directed cost protocol
US8218569B2 (en) * 2004-04-05 2012-07-10 Verizon Business Global Llc Apparatus and method for terminating service emulation instances
US20050220059A1 (en) * 2004-04-05 2005-10-06 Delregno Dick System and method for providing a multiple-protocol crossconnect
US7821929B2 (en) * 2004-04-05 2010-10-26 Verizon Business Global Llc System and method for controlling communication flow rates
US8289973B2 (en) 2004-04-05 2012-10-16 Verizon Business Global Llc System and method for indicating classification of a communications flow
US8340102B2 (en) * 2004-04-05 2012-12-25 Verizon Business Global Llc Apparatus and method for providing a network termination point
US7869450B2 (en) 2004-04-05 2011-01-11 Verizon Business Global Llc Method and apparatus for processing labeled flows in a communication access network
US8249082B2 (en) * 2004-04-05 2012-08-21 Verizon Business Global Llc System method for a communications access network
US8948207B2 (en) * 2004-04-05 2015-02-03 Verizon Patent And Licensing Inc. System and method for transporting time-division multiplexed communications through a packet-switched access network
US7920577B2 (en) * 2004-07-08 2011-04-05 Avaya Communication Israel Ltd. Power saving in wireless packet based networks
WO2006010113A2 (en) * 2004-07-09 2006-01-26 Network Foundation Technologies, Llc Systems for distributing data over a computer network and methods for arranging nodes for distribution of data over a computer network
US7391744B2 (en) * 2004-10-18 2008-06-24 Alcatel Lucent Allocating bridge priorities in bridged network
KR100645514B1 (ko) * 2004-10-19 2006-11-15 삼성전자주식회사 멀티 네트워크의 망 요소 관리 시스템 및 방법
JP4398356B2 (ja) 2004-12-24 2010-01-13 富士通株式会社 中継装置
US7889681B2 (en) * 2005-03-03 2011-02-15 Cisco Technology, Inc. Methods and devices for improving the multiple spanning tree protocol
US8565124B2 (en) * 2005-03-04 2013-10-22 Nec Corporation Node, network, correspondence relationship generation method and frame transfer program
CN101199165A (zh) * 2005-06-14 2008-06-11 艾利森电话股份有限公司 用于网络中的故障处理的方法和配置
KR100777614B1 (ko) * 2005-06-27 2007-11-21 학교법인 동의학원 최적 토플로지 엠에스티피 네트워크 장치 및 최적 토플로지엠에스티피 네트워크 구성방법
US7646733B2 (en) * 2005-09-16 2010-01-12 Cisco Technology, Inc. System and method for generating symmetrical spanning trees
DE602005010868D1 (de) * 2005-09-23 2008-12-18 Nokia Siemens Networks Gmbh Verfahren zur Erweiterung eines Netzes
CN100488169C (zh) * 2005-11-11 2009-05-13 华为技术有限公司 一种桥接网络中的数据处理方法及一种桥接网络
US7580357B2 (en) * 2005-12-01 2009-08-25 Via Technologies, Inc. Method for implementing varying grades of service quality in a network switch
IL177974A (en) * 2006-09-10 2011-06-30 Tejas Israel Ltd Method and system for relaying frames through an ethernet network and bridge therefor
US8184974B2 (en) 2006-09-11 2012-05-22 Lumexis Corporation Fiber-to-the-seat (FTTS) fiber distribution system
JP4751817B2 (ja) * 2006-12-04 2011-08-17 富士通株式会社 パケット転送装置およびネットワークシステム
US8125930B2 (en) * 2006-12-13 2012-02-28 Rockstar Bidco Lp Protocol for clock distribution and loop resolution
CN101206713B (zh) * 2006-12-18 2012-07-11 国际商业机器公司 标签识别系统和方法
US7962595B1 (en) * 2007-03-20 2011-06-14 Emc Corporation Method and apparatus for diagnosing host to storage data path loss due to FibreChannel switch fabric splits
US8509075B2 (en) * 2007-03-23 2013-08-13 Hewlett-Packard Development Company, Lp Data-type-based network path configuration
US8089882B2 (en) * 2007-03-23 2012-01-03 Hewlett-Packard Development Company, L.P. Load-aware network path configuration
US7839798B2 (en) * 2007-06-22 2010-11-23 Microsoft Corporation Seamlessly switching overlay network relay trees
US7886080B2 (en) * 2007-11-30 2011-02-08 Cisco Technology, Inc. Management of topology changes in layer two networks
KR100917299B1 (ko) * 2007-12-28 2009-09-11 엘지노텔 주식회사 스패닝 트리에서 링크집합과의 연동을 지원하는 루프 제거방법
CN101668025B (zh) * 2008-09-04 2013-02-13 北京启明星辰信息技术股份有限公司 一种链路层网络拓扑发现方法及装置
US9237034B2 (en) * 2008-10-21 2016-01-12 Iii Holdings 1, Llc Methods and systems for providing network access redundancy
US20100115415A1 (en) * 2008-10-31 2010-05-06 Hickey James P Graphic for network switches
US8169914B2 (en) 2009-03-16 2012-05-01 Sling Media Pvt. Ltd. Method and node for transmitting data over a communication network using negative acknowledgment
CN102576356B (zh) * 2009-08-06 2016-04-27 路美克斯公司 串联联网光纤到座位的机内娱乐系统
US8424045B2 (en) 2009-08-14 2013-04-16 Lumexis Corporation Video display unit docking assembly for fiber-to-the-screen inflight entertainment system
US8416698B2 (en) 2009-08-20 2013-04-09 Lumexis Corporation Serial networking fiber optic inflight entertainment system network configuration
CN101997735A (zh) * 2009-08-25 2011-03-30 中兴通讯股份有限公司 单环网络拓扑重建方法及系统
KR101222131B1 (ko) * 2009-10-08 2013-01-15 한국전자통신연구원 무선 센서 네트워크의 릴레이 노드 위치 결정 방법 및 시스템
US8743889B2 (en) 2010-07-06 2014-06-03 Nicira, Inc. Method and apparatus for using a network information base to control a plurality of shared network infrastructure switching elements
US9525647B2 (en) 2010-07-06 2016-12-20 Nicira, Inc. Network control apparatus and method for creating and modifying logical switching elements
US9077586B2 (en) * 2010-11-03 2015-07-07 Broadcom Corporation Unified vehicle network frame protocol
IL212191A0 (en) * 2011-04-07 2011-06-30 Eci Telecom Ltd Method for mac addresses withdrawal in telecommunication networks
US9094706B2 (en) 2011-10-21 2015-07-28 Sonos, Inc. Systems and methods for wireless music playback
KR101279500B1 (ko) * 2011-11-10 2013-06-27 한국기초과학지원연구원 노드의 동적 상태 변화에 따른 라우팅 경로 결정 방법
US20130148658A1 (en) * 2011-12-09 2013-06-13 Raytheon Bbn Technologies Corp Systems and methods for scalable multicast communication using self-rooted forwarding trees
US9306764B2 (en) * 2012-06-29 2016-04-05 Sonos, Inc. Dynamic spanning tree root selection
US9450775B1 (en) * 2012-07-19 2016-09-20 Google Inc. System and method for bouncing traffic in deadlock safe manner
US20140071885A1 (en) * 2012-09-10 2014-03-13 Qualcomm Incorporated Systems, apparatus, and methods for bridge learning in multi-hop networks
US20140153443A1 (en) * 2012-11-30 2014-06-05 International Business Machines Corporation Per-Address Spanning Tree Networks
JP6171434B2 (ja) * 2013-03-18 2017-08-02 富士通株式会社 ノード装置、通信方法、通信プログラム、および、ネットワークシステム
CN103414644B (zh) * 2013-07-31 2016-12-07 华为技术有限公司 表项下发的方法及控制器
US20150095980A1 (en) * 2013-09-29 2015-04-02 Nvidia Corporation Controlling sharing of content between data processing devices
TWI499787B (zh) * 2014-01-21 2015-09-11 Realtek Semiconductor Corp 多重故障診斷方法和機器可讀媒體
TWI607639B (zh) * 2016-06-27 2017-12-01 Chunghwa Telecom Co Ltd SDN sharing tree multicast streaming system and method
EP3831021A1 (en) 2018-07-27 2021-06-09 Gotenna Inc. VINEtm ZERO-CONTROL ROUTING USING DATA PACKET INSPECTION FOR WIRELESS MESH NETWORKS
US10735247B2 (en) * 2018-10-11 2020-08-04 Dell Products L.P. Spanning tree protocol traffic handling system

Family Cites Families (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4811337A (en) * 1988-01-15 1989-03-07 Vitalink Communications Corporation Distributed load sharing
GB2272310A (en) * 1992-11-07 1994-05-11 Ibm Method of operating a computer in a network.
EP0684716B1 (en) 1994-05-25 2002-02-27 International Business Machines Corporation A data communication network and method for operating said network
US6189043B1 (en) * 1997-06-09 2001-02-13 At&T Corp Dynamic cache replication in a internet environment through routers and servers utilizing a reverse tree generation
US6154463A (en) * 1997-08-26 2000-11-28 Lucent Technologies, Inc. System and method for multicast conferencing and online discussion groups
JPH11168491A (ja) * 1997-12-03 1999-06-22 Hitachi Cable Ltd ブリッジ装置
US6188694B1 (en) * 1997-12-23 2001-02-13 Cisco Technology, Inc. Shared spanning tree protocol
US6032194A (en) * 1997-12-24 2000-02-29 Cisco Technology, Inc. Method and apparatus for rapidly reconfiguring computer networks
US6105018A (en) * 1998-03-26 2000-08-15 Oracle Corporation Minimum leaf spanning tree
US6574197B1 (en) 1998-07-03 2003-06-03 Mitsubishi Denki Kabushiki Kaisha Network monitoring device
US6111673A (en) * 1998-07-17 2000-08-29 Telcordia Technologies, Inc. High-throughput, low-latency next generation internet networks using optical tag switching
US6628661B1 (en) * 1998-08-27 2003-09-30 Intel Corporation Spanning tree recovery in computer networks
US6262977B1 (en) * 1998-08-28 2001-07-17 3Com Corporation High availability spanning tree with rapid reconfiguration
US6938075B1 (en) * 1998-12-24 2005-08-30 Computer Associates Think, Inc. Method and apparatus for hierarchical software distribution packages including composite packages
US6771610B1 (en) * 1999-01-19 2004-08-03 3Com Corporation Spanning tree with protocol for bypassing port state transition timers
US7283463B2 (en) * 1999-03-30 2007-10-16 International Business Machines Corporation Non-disruptive reconfiguration of a publish/subscribe system
US6879588B1 (en) 1999-05-21 2005-04-12 Broadcom Corporation Address resolution snoop support for CPU
JP2001111616A (ja) * 1999-10-07 2001-04-20 Nec Corp 蓄積交換スイッチおよび蓄積交換方法
US6678241B1 (en) 1999-11-30 2004-01-13 Cisc Technology, Inc. Fast convergence with topology switching
JP3715501B2 (ja) * 2000-03-10 2005-11-09 アンリツ株式会社 スパニングツリー用ブリッジ及びそれを用いた経路変更方法
JP3664935B2 (ja) * 2000-03-17 2005-06-29 アンリツ株式会社 スパニングツリープロトコルを用いたブリッジ経路決定方法及びスパニングツリープロトコルを備えたブリッジ
US6868086B1 (en) 2000-03-29 2005-03-15 Intel Corporation Data packet routing
US6963575B1 (en) * 2000-06-07 2005-11-08 Yipes Enterprise Services, Inc. Enhanced data switching/routing for multi-regional IP over fiber network
US20020093954A1 (en) * 2000-07-05 2002-07-18 Jon Weil Failure protection in a communications network
DE60216571T2 (de) 2001-03-09 2007-09-20 Koninklijke Philips Electronics N.V. System von vorrichtungen die mittels einer bus-struktur kommunizieren
JP3614118B2 (ja) 2001-05-23 2005-01-26 日本電気株式会社 リングシステムのノード装置及びそれを用いたマルチスパニングツリー構築システム並びにその方法
JP2002353998A (ja) 2001-05-30 2002-12-06 Nec Corp 通信装置及びそれを用いたネットワークシステム並びにスパニングツリー構築方法
US7177946B1 (en) 2001-12-06 2007-02-13 Cisco Technology, Inc. Optimal sync for rapid spanning tree protocol
US7203743B2 (en) * 2001-12-28 2007-04-10 Nortel Networks Limited Hierarchical tree-based protection scheme for mesh networks
JP3956741B2 (ja) 2002-03-29 2007-08-08 富士通株式会社 マルチプル・スパニング・ツリー・プロトコル処理モジュール及びマルチプル・スパニング・ツリー設定方法
US7257086B2 (en) 2002-08-27 2007-08-14 Terabeam Corporation Method and system for effectuating network routing over primary and backup channels
JP3938582B2 (ja) 2003-02-19 2007-06-27 富士通株式会社 仮想ｌａｎ構築装置

Also Published As

Publication number Publication date
US20080159174A1 (en) 2008-07-03
AU2003255044A1 (en) 2004-03-11
KR20050036977A (ko) 2005-04-20
US7894374B2 (en) 2011-02-22
CA2437673A1 (en) 2004-02-22
EP1542407A4 (en) 2010-01-13
CN1679279A (zh) 2005-10-05
WO2004019560A1 (ja) 2004-03-04
EP1542407A1 (en) 2005-06-15
US7855981B2 (en) 2010-12-21
TWI242337B (en) 2005-10-21
TW200405694A (en) 2004-04-01
US20040047300A1 (en) 2004-03-11
JP2004140777A (ja) 2004-05-13

Similar Documents

Publication Publication Date Title
JP3729265B2 (ja) ネットワークシステム、スパニングツリー構成方法、スパニングツリー構成ノード、及びスパニングツリー構成プログラム
US7453888B2 (en) Stackable virtual local area network provisioning in bridged networks
US8472325B2 (en) Network availability enhancement technique for packet transport networks
EP1427152B1 (en) Virtual local area network auto-discovery methods
US7558194B2 (en) Virtual private network fault tolerance
US20150003232A1 (en) Scaling OAM for Point-to-Point Trunking
US20130287039A1 (en) Forwarding table minimisation in ethernet switches
US20100226377A1 (en) Communication System, Node, Terminal and Communication Method and Program
US20130242804A1 (en) Path calculation method
US8477600B2 (en) Composite transport functions
CN111935013A (zh) 流量转发控制方法及装置、流量转发方法及芯片、交换机
US20150172173A1 (en) Communication system, communication apparatus and path switching method
KR101664436B1 (ko) 이더넷 기반 이기종 패킷전달망간 연동을 위한 트랜스포트 sdn 컨트롤러 및 그 방법
EP1394998A2 (en) Improved virtual local area network provisioning in bridged networks
JP4089698B2 (ja) ネットワークシステム、ツリー再構成処理方法、ノード、ツリー再構成処理プログラム
JP4123437B2 (ja) ネットワークシステム、スパニングツリー構成方法、スパニングツリー構成ノード、及びスパニングツリー構成プログラム
JP2003143169A (ja) ルーティングブリッジシステム、ノード、接続ノード、及びルーティングプログラム
US8228823B2 (en) Avoiding high-speed network partitions in favor of low-speed links
JP2004214816A (ja) スパニングツリーシステム、スパニングツリー構成方法及び構成プログラム、スパニングツリー構成ノード
WO2022199276A1 (zh) 业务保护方法及网络节点
WO2023273941A1 (zh) 路径切换方法、控制器、节点以及存储介质
WO2006027824A1 (ja) 通信ネットワークシステムおよび障害検出装置
CN114531393A (zh) 分段路由策略下发方法、装置、设备、介质及程序产品
US7990945B1 (en) Method and apparatus for provisioning a label switched path across two or more networks
Nash Interconnecting data centers using VPLS

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20050307

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20050506

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20050914

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20050927

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20091014

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20091014

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20101014

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20111014

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20121014

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20131014

Year of fee payment: 8

LAPS Cancellation because of no payment of annual fees